In watching the media, conferences, etc talk about security one would think that all there is is a lot of fear. I can see how the conversation can be interesting, but it's very distracting and pointless when it comes to actually doing something about it. Kelly Higgin's post about a change (http://www.darkreading.com/insider-threat/167801100/security/attacks-breaches/228500103/cyberespionage-at-a-crossroads.html) is an important one. But like most the entire article is about the attacks and a paragraph is left to talk about a solution.
I agree with the premise that we need a new model to defend against these attacks we are seeing but, unfortunately, no one is really putting one forward. I've thought about this over the past year and have come up with a something that I will put forth in this blog.
- Threat Model
- Risk Management
- Cascading Bubbles (0-60)
- Targeted Attack Defenses
- Metrics and KPI's
From the top we need to change how we approach security. Over the past 20+ years we've defended our networks and data from a point problem to a point solution to a controls based one. However, not a lot of people have given thought to the basic theory of a controls based security model. There is an inherent failure in these models that needs to be resolved which is why I drive to a threats based model preceeding the controls.
By developing a threat taxonomy we are able to document up the premise of everything we do. "We are afraid of X happening" should be the start of the conversation. In a common taxonomy that I use I create a three tier system of categories. Starting with "external attack, external misuse, internal attack, internal misuse, acts of god, legal and compliance, people" we can then start to break down sub categories of threats. "External Attack -> Denial of Service -> Network Saturation". Where the break point is never perfect, the key I've found is getting detailed enough to structure a control but not too detailed.
Once we have the threats documented we then can incorporate the implementation of a controls structure. First, I take a segmented approach to the controls. I break them out to "Plan, Build and Run" ala ITIL structure. "Plan" stores the specific Policy and Standard mitigation for that threat. "Build" details the specific process that ensures the remediation of the threat in the overall companies lifecycle. "Run" identifies how the threat can be detected in a live environment if there is management drift, etc and how to remedy the issue.
Risk and Compliance
The last step we get to, once we have the controls established, is to perform proper assessments of their implementation to determine if the control is working effectively or as desired. From a security point of view, our purpose here is not to assess if the control is operational, rather answer the question "what has fallen through the cracks?". With this we need to strive for complete testing against our environment as frequently as possible. I try and strive for 100% testing of all systems at least once a month. From there we place the issues in context of our risk categories (value, brand and operations) in a qualitative sense.
In any failure of a control or incident we need to ensure that there is a tight integration back to the overall model. Incidents make us ask two questions. Is this a result of a control not working effectively or is this the result of it being an previously unknown threat? Assessments from audits are pretty simple where those are simply control effectiveness failures. If it's a new threat then this causes a cascading affect of new control segments being created as a result.
In the simplest sense this is the methodology in which we go through. Where not perfect it does make a complicated situation simple and sets us up for a much better predictive area than before. The rest of the sections will be discussed in later postings.