Research

It’s drilled into us as soon as we first cut our help-desk umbilical cords and don our information security diapers: C is for Confidentiality I is for Integrity A is for Availability We cite it like a tantric mantra. Include it in every presentation, as if anyone in the audience hasn’t heard it. Put it on security tests, when it’s the equivalent of awarding points for spell your name at the top. We even use it as the core of most of our risk management frameworks. Too bad it’s wrong. Think about this for a moment. If availability is as important as confidentiality or integrity, how is CIA even possibly internally consistent? Every time we ask for a password we reduce availability. Every time we put in a firewall, access control, encryption, or nearly anything else… we restrict availability. At least when we are talking about information security. When we talk about infrastructure security, I agree that availability is still very much in the mix. But then we aren’t really concerned with confidentiality, for example – although we might still include integrity. Keeping the bits flowing? That’s infrastructure rather than information security. (And yes, it’s still important). But I do think there is still a place for the “A”. I mean, who wants to ruin a perfectly good acronym? Especially one with a pathetically juvenile non-sexual double entendre. A doesn’t stand for Availability, it stands for Attribution. Logging, monitoring, auditing, and incident response? Knowing who did what and when? That’s all attribution. Who owns a piece of information? Who can modify and change it? All that relies on attribution. Pretty much all of identity management – every username, password, and token: attribution. Availability? When it comes to information, that’s really a usability issue… not security. If anything, more availability means less security. Changing A from Availability to Attribution solves that problem and makes security internally consistent. (This is a prelude to a series of deeper theoretical (nope, not pragmatic) posts based on my Quantum Datum work. Special thanks to the Securosis Contributors for helping me flesh it out – especially Gunnar). Share:

Now that the media has feasted on the Stuxnet carcass, it gives me a moment of pause. What of a different perspective? I know – madness, right? But seriously, we have seen the media in a lather over this story for some time now. Let’s be honest – to someone who has worked in the SCADA community, this really is nothing new. It’s just one incident that happened to come to light. An alternative angle to the story, which seems to have been shied away from, is under-financed but motivated agents. Technical ‘resources’ with too much free time and a wealth of knowledge. This is not a new idea – just look at the abundance of open source projects that rely heavily on this concept: smart people with free time on their hands. What happens when you combine a surfeit of technical competence with a criminal bent? This was well documented back in the 80’s, when a group of German hackers led by Karl Koch were arrested for selling source code they had purloined from US government and corporate computers to the KGB. In this case these hackers were receiving payments in the form of cocaine and cash. Nothing major, just enough to keep them happy (and awake during their coke-fueled coding sessions). At least that was the idea until they were caught and Karl met his untimely end in a German forest in 1989. The argument will invariably be: how could they have the knowledge required for some of these attacks? Ever worked for a power company? There are usually a good number of disgruntled workers and $1,000 US will go a long way in some countries. It was also not difficult to gain access to the documentation from most control system vendors until recently. To borrow from Rich Mogull: funding = resources – the biggest of which are time and knowledge. Looking back to my earlier statement, this is something that a lot of disaffected hackers in former eastern bloc countries have in droves. Throw in some cash and drugs and you could have a motivated crew. I don’t think this is the case, but you must admit it’s within the realm of possibility. After all, this is not without precedent. There’s a skeleton in a forest someplace to prove it. Share:

Rich makes the case that A Is Not for Availability in this week’s FireStarter. Basically his thinking is that the A in the CIA triad needs to be attribution, rather than availability. At least when thinking about security information (as opposed to infrastructure). Turns out that was a rather controversial position within the Securosis band. Yes, that’s right, we don’t always agree with each other. Some research firms gloss over these disagreements, forcing a measure of consensus, and then force every analyst to toe the line. Lord knows, you can never disagree in front of a client. Never. Well, Securosis is not your grandpappy’s research firm. Not only do we disagree with each other, but we call each other out, usually in a fairly public manner. Rich is not wrong that attribution is important – whether discussing information or infrastructure security. Knowing who is doing what is critical. We’ve done a ton of research about the importance of integrating identity information into your security program, and will continue. Especially now that Gunnar is around to teach us what we don’t know. But some of us are not ready to give up the ghost on availability. Not just yet, anyway. One of the core tenets of the Pragmatic CSO philosophy is a concept I called the Reasons to Secure. There are five, and #1 is Maintain Business System Availability. You see, if key business systems go down, you are out of business. Period. If it’s a security breach that took the systems down, you might as well dust off your resume – you’ll need it sooner rather than later. Again, I’m not going to dispute the importance of attribution, especially as data continues to spread to the four corners of the world and we continue to lose control of it. But not to the exclusion of availability as a core consideration for every decision we make. And I’m not alone in challenging this contention. James Arlen, one of our Canadian Wonder Twins, sent this succinct response to our internal mailing list this AM: As someone who is often found ranting that availability has to be the first member of the CIA triad instead of the last, I’m not sure that I can just walk away from it. I’m going to have to have some kind of support, perhaps a process to get from hugging availability to thinking about the problem more holistically. Is this ultimately about the maturation of the average CIO from superannuated VP of IT to a real information manager who is capable of paying attention to all the elements of attribution (as you so eloquently describe) and beginning the process of folding in the kind of information risk management that the CISOs have been carrying while the CIO plays with blinky lights? James makes an interesting point here, and it’s clearly something that is echoed in the P-CSO: the importance of thinking in business terms, which means it’s about ensuring everything is brought back to business impact. The concept of information risk management is still pretty nebulous, but ultimately any decision we make to restrict access or bolster defenses needs to be based on the economic impact on the business. So maybe the CIA acronym becomes CIA^2, so now you have availability and attribution as key aspects of security. But at least some of us believe you neglect availability at your peril. I’m pretty sure the CEO is a lot more interested in whether the systems that drive the business are running than who is doing what. At least at the highest level. Share: