Security Governance: Defense In Depth
Thinking through the layers we need to create to fully protect our data, infrastructure, systems, and people
Imagine you’re in charge of security at a sophisticated technical organization, and you’ve just learned that six developers and architects who went to a conference last year may have been abducted and brainwashed while they were there. In theory, they could at any moment (while performing their normal day jobs) suddenly take any set of actions that their captors demand - willingly and with their full cooperation.
What would you do? Let’s keep it interesting by establishing that they do outstanding work, you don’t want to fire them, and you don’t want to put them in a room where they can’t work. Allow them to continue to perform their day jobs, although you can certainly add additional security protocols around their actions.
Here are the things that I would think about:
I would be very careful about their access. I would probably try to be exceptionally careful to ensure that they exact access they need, and no more. I would also carefully review what access they have to understand what kinds of mischief they might do if their brainwashed conditioning was triggered.
If their jobs required additional access, I would carefully review the new capabilities, to identify the “blast radius” if something goes wrong.
I would try very hard to log every single work-related action they performed - what data they sent and received, what commands they typed, the output from those commands, etc. So I could look for strange behaviors, and perhaps as a troubleshooting log if something went wrong.
I would probably try to carefully manage their network access - ensuring that they only had access to the systems they needed. This would probably require some form of proxying as well, as a further constraint.
I would almost certainly introduce zero-trust protocols for their network access.
I would attempt to rate limit their actions where possible, and create alarms if they started consuming an unusual amount of resources.
I would create more sophisticated access policy around their actions. For example, I would be much more concerned about what they might delete or erase, and set up special rules to ensure that anytime they wanted to erase or delete something, that these actions should be reviewed by a trusted third-party, and not allowed to proceed without that third-party authorization. I might also carefully segment their API access, so that they could only have limited forms of write access that could be “unwound” if something went wrong.
I would want all of this to be cryptographically secure, to significantly decrease the chances that these folks might be able to circumvent these restrictions.
What I wouldn’t do is “Write a document, describing what those people are not allowed to do, and have them agree to it under threat of job termination”. Because that would be dumb. If these folks are brainwashed, and no longer guaranteed to be in control of their own actions, signing a document accomplishes nothing. It’s a massive technical and business risk.
What are your ideas? Any options I missed? What other security measures would you consider in this scenario to help keep your systems, infrastructure and data safe? I’ve put a lot of time into trying to address these challenges, and I would love to talk about it with anyone who might be interested: johnbr@paclabs.io .