This is an excerpt from an email I sent to a number of colleagues as we hash out what our various and competing mandates to “secure cyberspace” (in our own domains) actually involve and what we have to do about them. My position is that, first and foremost, we need a business security architecture to answer those questions, and that’s where this following conversation is leading. Various recent discussions I’ve been a part of outside of the job – just in the industry – also were on my mind when I wrote this. There seems to be this belief that “cyber security” is somehow a technical problem, and I couldnt disagree more. (Note: Im speaking generally below and am leaving out detail for the sake of brevity – I dont have time to write a dissertation. :) Note2: The fact that I dont discuss our complete and utter failure to universally define “identity” doesn’t mean I dont believe it significantly impacts our ability to secure “stuff”.)
Security really comes down to the identity of systems and people: Who needs to interact with who, what transactions they can perform between them (and in what direction), how long those transactions may last, how often they may occur, which side of the transaction “owns” the security of the transaction. Everything you do to secure your domain of control flows from this information. It allows us to (literally): place and configure the technical and process security controls which you have described as being a sector need.
If you wanted to describe a “secure” cyber system without this information, your answer necessarily would have to be: “the computer will be in an electromagnetic shielded room with hardware memory that cant be written to, no disk drives, no connection outside the room, and anyone who uses it must be x-rayed and without clothing to hide plastic or wooden tools.” That’s obviously silly, but we just said secure – we didnt define exceptions to “secure”. So how is the middle ground defined? What does “secure” mean to you? I’d suggest that it means that whatever controls are in place enable you to continue to operate in a way that supports your mission. In other words, since security is first defined as: “The system should not do anything more or less than I want it to”, you must define what you want it to do. Then, you go through a prioritization effort of what you want it to do so that your budget can support it.
One of the reasons that developing this business context of “what should my systems do” is important to the budget piece is because that information allows us to begin to create attack trees. Attrack trees help us understand the weak points in the system are *that we care about* (not just every and all possible attack). Few of those weak points are immediately apparent or obvious after an informal inspection, so a process is needed. From attack trees and control placement, we can then prioritize our efforts based on a combination of technical vulnerability, business risk, and available money and work out a budget. Otherwise you’re just making up numbers and -hoping- your investment pays off.
And, as far as using universal standards in this area, your requirements MAY look like someone else’s, but the exceptions to that become maliciously exploitable, so you still need to validate and manage your environment and business requirements.
Without this information defined, your security controls will have significant gaps in placement, they will be not be effectively auditable for malicious activity, their configurations will not accurately reflect the real security needs of the system, and you will most likely run out of a security budget before you’ve mitigated a significant amount of risk. On the macro level, these really are the areas which hackers and malicious actors exploit with consistently rich returns.
Technical vulnerabilities will always exist, and we do need to maintain awareness of them and processes to try and keep up with them, but these are largely well understood and we still fail (and we fail dramatically) to actually prevent intrusions, data exfilitration, denial of service, etc. – even when we have controls in place. It’s not for lack of technology, really. We have controls out the wazoo – firewalls, antivirus, IDS, etc. We’re just not using them rationally.
This business context (or at least the education and tools to develop it) – if you were to look at every company and stakeholder in the sector as being part of the same business (the business of ____) – is what I hope we in the working can begin to help provide. I really believe what might seem like fuzzy talk without a lot of action will ultimately result in a concrete way forward to reduce or mitigate the risk we all face.