30

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:

enter image description here

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.

  • 27
    Currently my clients' clients don't know about me... If you wanted to break into their portion of this system, you come after me Sounds like the clients deserve to know that you're the weak link in their encryption. – Johnny Aug 2 '16 at 17:51
  • 1
    Better hope that your clients' clients are not Europeans, because it appears you're violating the EU Data Protection Directive. – MSalters Aug 3 '16 at 8:46
  • 5
    @MSalters That's pretty bold given you don't know what data I'm storing... But if you do have to accuse somebody of breaking a law, it might be helpful (to them and others) to point out what they're doing wrong. – Oli Aug 3 '16 at 9:29
  • 11
    @Oli: Well, names and IP addresses are classed as EU-protected data, and since you state that your clients have "no direct access to server operations" it appears that you are processing said data on behalf of your client. And the EU rule is that such processing is illegal unless you meet all requirements including registration with your national Data Protection Agency. – MSalters Aug 3 '16 at 10:00
  • 9
    @Oli there are only two options - either you are storing the data, or your customer is. If you are storing the data, then you are the right person to ask for that information. If they are storing the data and just outsourcing some maintenance to you, then they have all grounds to ask the most intimate about how low-grade data is stored and secured - if it is their system and not yours, it's quite weird to see how there could be any detail that shouldn't be known by them. – Peteris Aug 3 '16 at 11:08
53

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.

  • 20
    Make sure to actually blank it out, not just draw black rectangles over it on the next layer up. – wizzwizz4 Aug 2 '16 at 18:33
  • On the contrary, I am curious to know; how one can deduce the secondary layer? What are the steps involved? – Shritam Bhowmick Oct 20 '16 at 10:09
30

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.

  • I meant legal requirement for us. We could put "we have a chap for that" as every answer and they'd not renew their contract. They can't legally force us to answer anything. I'm looking for the line in the middle where we hand over enough information to keep them happy but not enough that they can knock on my door and tear the whole thing apart. – Oli Aug 2 '16 at 13:20
  • 32
    My answer still stands. If they have to follow something like NIST 800-53 then you have the choice of either answering all of their questions, to their satisfaction, or terminating your contract. There is no happy middle ground where you get to decide to not give them the information requested but keep the contract. If you're concerned about unique trade secrets or processes that you use, then have a lawyer draw up a Non-Disclosure Agreement that you have them sign. – LeoB Aug 2 '16 at 13:37
17

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.

  • 1
    To be clear, selected people in the company I contract for have an "Oli gets hit by a bus" contingency to rebuild the system from encrypted backups. But no access to operations. I don't deny that I am a weak point, but I'm developer and operations. I have to have access to everything. We aren't talking about launch codes or even "sensitive" data here. Names, emails and IPs but that seems to be enough for this government entity. – Oli Aug 3 '16 at 9:36
  • 1
    @Oli Having access to everything is a huge liability. Ever seen those bank heist movies when 2 employees have to turn 2 keys simultaneously to open the vault? You need digital equivalent of that, with your client holding the second password. Yes, it's an inconvenience in everyday work, but quite a good alternative to being abducted and tortured. – Agent_L Aug 3 '16 at 14:30
6

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.