You are currently browsing the monthly archive for March 2009.
(Needs Editing, but Im a bit stuck…so reviews and comments welcome.)
Years ago – in Mad Magazine – I saw an illustration of Alfred E. Newman sitting in a tire swing. At first glance everything seemed normal, but after a second if reflection I noticed that it was Alfred himself holding up the tire swing while sitting in it – a situation which obviously does not (heh) fly.
This is the image that came to mind when, after my last post on Data Visualization’s Lessons for Enterprise Security, I was asked questions like:
- What does Operational Risk Management have to do with IDS monitoring directly?
- What about better and more transparent auditing? Wouldn’t that help?
- I don’t see how SABSA really applies to MSSP’s or IDS monitoring
My short answer is that no matter how you make your security tire swing or what you do while you’re sitting in it, as a security practice you have to be bolted to something independent that holds it all up. That’s “The Business” in case it’s not clear.
I’d like to address the IDS example, in particular, because I think it is very illustrative of the connection between detailed technical and high level business realities. Please keep in mind that this is only a snapshot of the direct implications to a very small section of a much larger, very holistic process. There are many secondary dependencies and repercussions which I do not address here (like tactical technical responses, incorporating lessons learned, strategic business decision making, etc.)
So, first of all, at a process level, IDS monitoring is pretty simple:
Get data -> Evaluate nature of data -> Evaluate implications of activity represented by data ->Respond to and/or continue getting data
No matter what environment you’re in, if you’re looking at IDS data (or doing any other monitoring, really), you do these four things. If you look a little closer, though, you begin to see that they are (or should be) repeated iteratively. This is because there are really multiple levels – or layers – at which security data can be evaluated (which, incidentally, looks a lot like any other protocol stack). Let’s say, conceptually, that there are five of them:
- Universal Technical Standards: This layer would consist of measuring activity against RFC’s, Protocol Standards, etc. Things that -should- work the same everywhere.
- Environmental Configuration: Here, traffic is evaluated against local configurations that might change from network to network. This includes the configuration of OS’s, Web Servers, Infrastructure Devices, etc.
- Data and Information Control: What happens to data riding on your network and IT obviously falls in the area of concern for IDS analysis.
- Timing and Behavioral Thresholds: Are things happening more frequently than normal? Less frequently? Uptime? User logins? Memory Usage? etc.
- Business Rules: Is the IT actually doing something that directly affects the business? Are manufacturing robots shutting down? Are internal company secrets being sent to competitors? Are you spamming the military?
So what is the intersection between these layers and enterprise business architecture or operational risk management? It looks, initially, like the only direct overlap is in layer 5, right? Not true.
First, each of these layers requires some level of the business context provided by business security architectures to even be effectively evaluated.
- To evaluate security data against potential technical standards, analysts need to know what technologies are in place and deployed and in what manner. Exceptions and outliers are especially important.
- From an environmental perspective, analysts would be well served by knowing the security policies that the configuarations and environment are supporting. E.g., what actions the configurations trying to prevent or support (in terms of the other 5 layers)
- The need to know what data belongs to what data policies and what those policies say is also fundamental. Data policies are tied to conceptual business architecture, which is tied to contextual business assets and requirements.
- System behavior is evaluated in part by knowing things like business schedules and processes. Is payroll being run every 4th Thursday? Are people going to be logging in from all over the world, or just certain locations? Should lab systems pull data from production systems?
- Knowing what business functions are important to keep running, to what thresholds, and how IT systems support those is crucial when trying to understand the big picture and put “events” in terms of “incidents”. Additional, it should be kept in mind that things like “reputation” and “customer satisfaction” are also considered business assets to protect. Organizations have a need to protect those as well.
Secondly, and maybe more importantly, if you actually look at the process flow (below) you find that the analysis process always rolls up to an evaluation at layer 5 (the business rules) of the analysis stack.
From a process flow perspective, there are absolutely no analysis scenarios that do not terminate before completing a layer 5 business analysis (At the bottom of image).
(Click Image for Full Size View)
How does this work?
Analysis begins at one of these five layers – which one is first doesn’t really matter (they are often, in fact, done in parallel). Data is received and is evaluated against the criteria at the layer in question. If there are no exceptions, the same raw data is evaluated against the next layer in the chain. If an exception is found at any one of these layers, the impacts of that exception are then evaluated at all layers. So, for instance, if an analyst notices that there are “funny packets” that aren’t normal TCP/IP traffic while evaluating against “Technical Standards”, he or she then looks to see what the potential technical, environmental, data, behavioral, and business implications are of that traffic. For each of those, the analyst follows the process as if he’d just received new raw data.
This continues to happen until the original data has been run up the entire stack and a final business impact has been determined. Sometimes the path there is short because the answers are known or obvious, or complete data is unavailable to make a determination, or the entire process is followed at a very detailed level. Regardless, the logical process holds true in all cases and there is either a potential business impact or there isn’t.
Read that again: There is either a potential business impact or there isn’t. Without context, IDS monitoring can never be a security function.
The value of IDS monitoring never gets realized if exception events are not tied to business operating requirements and risk appetite (which only business stakeholders can determine). If that linkage is not formally made or that appetite not assessed, IDS monitoring fails. None of the five analysis layers are inherently worth evaluating if a business context for them does not exist and most can’t even be evaluated at all without that context.
What provides this context? Business Security Architecture and Risk Management.
What’s interesting, though, is that these things don’t work when isolated to security, as the original blog post (and others) pointed out. If you limit the scope of your activities to “security”, you end up with the tire swing with no tree. You have to account for and model your entire business formally to achieve security, What this says is that business security architectures are, at a very real level, just business architectures. There is no material difference between the two.
But why would you need a full fledged business-wide process to get this information to you (or your analysts)? Because it’s really hard and expensive to do without the practice and culture in place enterprise-wide. You might brute force it and get your answers once without it, but trying to keep that information up to date would be completely futile.
In closing, I’d like to reiterate that I’ve only discussed business security architecture and operational risk management’s impacts technical security operations (looking up). Of at least as much importance is its role in aiding executive or management decision makers in correctly assessing and responding to risk. This is accomplished by providing a very clear line of sight from the trenches to business assets and risk appetite (looking down).
If you’ve read some of my recent posts here, you’ll have seen that Im back working on creating data visualization pieces as art. In the process of making these, I was reminded again of the relationship between art and security and its practical implications for enterprise security efforts that literally dictate success of failure. Bear with me as I walk through the art piece first and then arrive at the security observations :)
First, to work, art has to have a solid concept. You might accidentally create a piece that’s appealing on some level if you just throw paint at canvas, but you probably won’t repeat that success often and observers will understand this.
Taking that into the realm of data visualization, you can make all the pretty graphs you like, but unless you do some leg-work ahead of time and massage the data into shape, they’ll be of little use and only may accidentally be visually appealing in a way that let’s you intuitively grok it. (I think this is philosophically similar to some of what Tufte teaches, but I don’t remember for sure.)
For example, if I wanted to (as I did) visually represent the stimulus bill in a meaningful way on screen at once, I could really just use a microscopic font…or turn the whole thing into a jpg and resize it to fit on screen. But what would that accomplish? It would just be mush. We wouldn’t have identified or accounted for inherent structural properties that we needed to keep to preserve order. We also wouldn’t have separated the wheat from the chaff – useless information would hide useful information. And we wouldn’t have manually added linkages between data points that would help us draw meaningful conclusions visually to account for a loss of resolution in individual words.
What would work, instead, is to turn (as I did) the Stimulus Bill into columns of useful information. You could convert the free form english structure of the Bill into a tabular format and add meta data about the text that I wanted to see in the visuals. You could add line numbers, position in sentences, group words by sections of the document and add word counts, etc. All this would show up visually and present a much more useful visualization that would also, because of the new more conscious conceptual structure, be more appealing to look at.
So what does this have to do with security? Everything.
Recently, much has been made of the new SANS CAG control list. Basically, this is a list of “best practice” security measures and controls that, if properly done, will make the most impact in securing organizations. Where’s the problem? The problem is that none of these are new (except WiFi). They’ve all been around longer than I’ve worked in the field (7ish years) and probably much longer than that. Everyone who works in security knows them. Most CTO’s, CIO’s, and CISO’s will probably not be unfamiliar with them. But yet, they’re either not implemented or, more often, they just don’t work.
If these really are best practices (and they are), but yet they’re not working, where’s the disconnect? I think it’s lack of structure. Most organizations do not operate their businesses in a manner that can be secured. There are inherent structural flaws (as in, there isnt any) in the enterprises themselves that conflict with and outright prevent security from happening – just like in art and visualizations. No matter how much effort or money you throw at the problem, cyber/IT/technical security controls will get you nowhere quickly (if anywhere ever) without a properly run and organized business. What failed cyber or IT security really is, ultimately, is a symptom of failed Operational Risk Management.
If you can’t track assests, if you haven’t identified your key data, if you don’t have clear and measurable business objectives for IT and cyber systems, if you don’t have a clear line of sight between the risk of technical failure to business impact, your security controls -will- fail.
Why? Because an organization run without these things will consistently make poor decisions based on incorrect, out of date, or conflicting information. In other words, you have to build break points into the business to be able to check, measure, and change the the organization at key junctures in order to make good risk-based decisions. “Risk-Based decision making” get’s bantered about like “moving forward” and “synergies” – but it’s not an empty phrase and it has real, concrete impacts and prerequisites.
Let’s look at a best-case scenario where everyone wants to do the right thing, but there isn’t an enterprise or business architecture in place. Everyone goes through an evaluation of need and risk, pick the right controls, put them in place. Hunky dory, yeah? Well, what happens when a new line of business is added? Nothing to do with security, right? What if the new line is taking critical data that wasn’t exposed by the other systems and making it public inadvertently? Would you know that? If you need to patch critical systems quickly to prevent a flaw, would you know which ones kept your business running? Would you have documented in an easily accessible manner the fact that your manufacturing systems depended on a feature that the new patch – which works just fine on desktops – disables? Etc. Not to mention that your IDS’s depend on this info, your firewalls, your SEMs, everything. There is relatively little happening on your network that is inherently bad outside of a business context. There are many more (and probably better) examples…but there are two take-home points:
- Everyone with the authority to make changes to your business needs to be aware of the secondary dependencies of those decisions and how they intersect with security and inform others of changes they make
- If you try and do this without managed processes and without maintaing and continuously updating the information about the business in an architecture, you’ll fail. It’s too hard, too expensive, and takes to long to keep doing it from scratch. It’ll never be accurate, timely, relevant, etc.
Business leadership at all levels and in many (most?) organizations simply are making bad decisions that affect security. It’s not that we don’t know, as security professionals, the right things to do. It’s that we can’t express it in terms of business risk and the business leaders typically don’t seem to have the structure built in to affect positive change throughout the organization. Build some good, clean structure with visible break points at critical junctures in your business flow and then security will start to become cheaper, easier, and more effective.
Originally uploaded by sintixerr
On the subject of these “data visualizations as art”, I’ve been trying to better articulate why I think they’re art and how I’m trying to evolve my process.
What it comes down to is that there seems to be two pieces to developing the visualizations:
- Choosing the right structure and things to measure about the text or data…what makes sense to compare to what. How do you reduce the noise and non-dependent variables? Each type of text you’re measuring and each circumstance has different relationships. There is a lot of science to this part, but it’s not completely predicatable. There is art.
- How do you visually best enhance and needle out the important details, contrast between points, etc so that they can be “seen” in the noise that doesnt matter? This is all art. Understanding how color, shape, contrast, etc all work together and how to use all of those to present a dense amount of information without being overwhelming is tricky and depends on the skill of the one creating it…
It’s my belief that playing to what we understand as people’s abilities to process and comprehend aesthetics in art involves exactly the same techniques and takes advantage of the same aspects of peoples brains/senses as good visual data analysis. So, if you’re doing data analysis, you start out figuring out #1, and then move to #2 based on #1.
What I was trying to do with these stimulus images – and the last of my security visualizations – was start out with concepts of what I’d like for #2 (how they would “feel”) and then figure out what I needed to do in #1 (massage the data) to get there…while still remaining true to the underlying information.
Next up (and once I learn more Objective C), I’m going to try and read in the stimulus bill to Quartz Composer and combine my recent interactive/music visualizations with the Bill. We’ll see if that goes anywhere interesting. :)
Also, Artomatic returns to DC this year. I very well may be displaying this stuff there when it comes around. This or the music/webcam visualizations.