Comply with data protection requirements without giving away too much?

Question

I'm a contractor for a few companies. I build and host their systems on servers I rent from a popular international host. I store the system code on a popular, internationally hosted version control system. There are a mix of authentication techniques at various points, most of them near-best practices.

However, I also layer on some obscurity. SSH is hidden, some things are encrypted in non-obvious ways. Alone these wouldn't be valuable but alongside the real security, I fend off most serious threats.

One of my clients got a data protection process request from one of their clients today: a huge government organisation. They obviously take this red tape stuff pretty seriously and have sent us a long questionnaire that asks for specific security detail. Not just about the data we collect but also where it's secured, how it's secured, where the locks are and who has the keys.

The last few of those things are the sort of stuff I keep hidden from my clients, not to mention theirs. As the person with all the keys, I'm very conscious of this overused but accurate comic:

Currently my clients' clients don't know about me. Not really. But if we comply with their request, anybody with access to this request, suddenly knows who I am, where I am, what I have access to. If you wanted to break into their portion of this system, you come after me.

And you can go deeper. Part of this request mentions Access Control Policies and gives an example that explains where (exactly, geographically) a private key is stored. If you follow this through every system that tangentially touches the data they submit, they have a map of every system we use and know who to come to (or hack) to gain access to the whole thing. It unsettles me.

My question is, in your experience, is there a way to comply with security procedure requests that doesn't target specific people, computers or even ports?

Very little of this stuff is actual legal requirement. We already meet data protection act guidelines... But again, being a large government agency, their drive to tick boxes seems several powers greater than any other organisation.

---

Just a couple of clarifications.

• My client has details on the system. They have no direct access to server operations. They have access to the version control system and receive encrypted data backups on a very regular schedule and have a document (and encryption keys) that explains how to replace the system I run with one of their own in the event of my untimely demise. We have discussed the overview but the exact details are under physical lock and key.

• We aren't dealing with launch codes. Names, contact information and IP addresses. I didn't expect this would be relevant to the question but people are bringing up the two-man rule. That's way over the top here. This is technically sub-PCI-DSS.

• I am developer and operations for this small company (as well as others). Many of you are talking about me being the weak point. I am. One wrench and you have the data I have. That's why I'm asking.

  Please, rather than just pointing this out, some suggestions on what to do about these things on a small scale would be more useful. I can't be the only devop on the planet who tangentially deals with governments.

Answer 1

The request for this information may not only be for a security audit, but also a process audit, and it sounds like it might be well founded, since:

If you wanted to break into their portion of this system, you come after me.

What would happen if you were "hit by a truck" tomorrow? If you are the only one that knows the systems, your clients and theirs would certainly have a big problem. Ideally, someone else needs to have access also, and it should be documented who that is and how to contact them.

Depending on the requirements, it may be possible for the holder of the keys to be a company rather than a person, perhaps with a primary and secondary contact named. The primary contact could likely also be someone at your client, and they probably should have all the documentation for how to access their systems in an emergency if you are not available.

Also, you may be able to provide a report with certain things redacted. They likely are more interested in knowing that the non-redacted documentation exists somewhere and that the proper people have access to it when needed. They probably won't care that the port numbers, etc. are blacked out, as long as they can be sure that they exist in a document somewhere.

Answer 2

You said "Very little of this stuff is actual legal requirement" but depending on which government this concerns, this may be a very strict legal requirement. If that government requires their departments/agencies to follow NIST SP800-53 then they can't just answer "we have a guy." The answers to these security controls require detailed information giving who, what, where, when, why, and how. Failure to provide that information can keep that government entity from receiving authorization to operate that information system. Therefore, you can expect that you will have to let that government entity know who you are and what your processes are.

Answer 3

Not to pile on too much, but your question exposes a serious flaw in the system, which is you.

You are a single point of failure, and that's pretty far from best-practices.

Depending on the specifics of this government contract, having all the encryption keys with a single person may be a disqualifying violation, in addition to being poor practice. As well as the "hit by a bus" issue, some government regulations require an implementation of the two-man rule/four-eyes principle, frequently with a minimum bar of access to privileged systems being monitored or audited by someone other than the person accessing the system, which is not possible if you're the only one with the access.

As understandable as it is that you're unsettled by revealing personally identifiable information about yourself, along with the fact that you're probably the best point of attack on these systems, that cuts both ways, and should be unsettling. The proper approach is not to obscure this vulnerability, but to address it. If you have secure systems and processes, they're secure, whether someone knows about them or not, and that's what you should be focusing on. Getting your servers into a proper, secure data-center, implementing access monitoring/auditing and eliminating yourself as a single point of failure are all very possible, would improve the security of your system(s), and would making answering this questionnaire less problematic. As a silver-lining, this is probably an opportunity to up-sell this particular client (and maybe others) on those security enhancements.

Answer 4

Others have mentioned that you are a single point of failure in your client's client's systems/processes, so I won't repeat all that again.

What I will say is that you may not be required to explain everything to every last detail. You may actually be able to describe your systems much as you have in the question. All this depends on the questions you've been asked though, and what legal jurisdiction you're governed by.

For example, you may not need to say "I keep the keys and config on github", but may just need to say "I keep the keys and config in a 3rd party, private, managed version control service which is hosted in the US". The latter gives away the legal jurisdiction of the servers that host the data, but doesn't necessarily give away the exact location of it.

One other thing to note is that if someone's taking the red tape very seriously, it's possible they may, shall we say, have some unresolved superiority complexes. That is, they may be asking questions that are far too detailed or precise, for which there is no justification in the data protection legislation. Just because they've asked "What steps have you taken to secure SSH? Please detail alternative ports used, port knocking sequences or other details required for access", doesn't mean you actually have to disclose all of that to them.

Having said all of that, your direct client absolutely does have the right to ask for those sorts of things (because if you're hit by a bus, they're the ones left trying to run things without you). There is (probably) no law governing this, other than "if you don't do it, don't expect to get hired". It may be time to start talking about some sort of escrow solutions with them.