One of the frustrations - or challenges depending on your viewpoint - about responding to security incidents is that you spend a lot of time overturning rocks. Most people, when they turn over a rock, expect to see bugs, worms and a few unknown creepy crawlies scattering for cover. However, when a security person overturns a rock during a security incident, most often all they find are more rocks. Then those rocks are overturned, revealing more rocks, and so on. The endeavor turns into a battle of attrition until finally (usually under the most unexpected rock) the bugs, worms and creepy crawlies are discovered. For every security event, there are several rocks to be uncovered: What system is involved? What does the system do? What was the source system? What is that system used for? What protocol was used? What does the log or event mean? Who triggered the event? What is that person’s role? Was it a real business activity? Overturning each of these rocks reveals more rocks.
Something like this is typical for a security investigation today…Our perimeter defenses notify us that IP address 10.1.1.105, a nameless device, sent a zip file called really-important-secrets.zip to IP 192.168.1.234, an unknown destination. Many rocks uncovered later – we learn that zip file contained SecretSauce.doc and was sent from John Doe’s laptop to an FTP site at bad.place.net. More rocks and more digging reveal John Doe was previously spearphished into visiting a website last week at watering.hole.com and had malware R3@llyN@sty installed on his machine. And that’s the comforting scenario since I didn't even include some of the obfuscation that some of the attacks use for data transfer. An even worse scenario is law enforcement showing up telling us SecretSauce.doc was deposited on a warez site three months ago and evidence suggests it had been traded through multiple forums for a month or two before that.
In my experience, good security analysts like uncovering rocks. They don’t mind digging through the 1s and 0s relentlessly in pursuit of the creepy crawlies. The problem with all of these rocks is that they look alike. Wouldn't it be nice if some of them glowed bright green as to say “turn me over first”? Or once you overturn one rock, the subsequent rocks are neatly arranged to quickly ascertain the situation? This is why Context – adding dimensions to the incident to enable prioritization, clarify impact or provide insight that influences the response in a positive manner – is so important to today’s security threat management. There are many rocks that shouldn't be so hard to overturn. To deal with some of the opaque, obtuse, wildly sophisticated attacks today, we have to begin fusing this context into the security event equation right from the beginning.
Security analysts most often are presented with an IP address – a nameless, faceless string of numbers. This is much like a phone number. They don’t know who that phone number is for (owner), what the number is used for (personal or business), the type of phone (mobile or landline), where it is located (physical address), what calls were made, etc. Context is adding all of those things to the phone number turning it from “555-555-1212” to “John Doe’s mobile phone used for his financial advisory business and he is driving down I-435 right now talking with his business partner Bob”.
Some tactical – yet important – strategies for you to enhance Context:
Evaluate IT asset repositories to collapse and streamline the concept of “critical systems”. This will require a combination of input from business (what applications are truly important for business?) and IT (what infrastructure enables the key business processes?). The definition of critical may be fluid as well – so one time assignment of that indicator is not going to cut it. You need an ongoing process to identify what are key assets.
Don’t forget data. Owning a router or getting root on a server isn't the end game anymore. It might have been in the good old days of hacking for fun, but today’s dangerous adversaries are for-profit (or for-damage) driven. Understanding what data is important and relevant, where that data lives and when and how it is in transit is crucial.
Continuously add dimensions. Bringing this context will require some time. It won’t happen overnight but having a strategy to incrementally improve security’s understanding of IT assets and systems needs to be on the CISO’s plan.
For the security analyst, Context turns “10.1.1.101” into “The SPARC T4-1B server module running Solaris 10 located in the Boston data center which is part of the cluster hosting the Oracle database used in the SAP system that houses employee and customer information, subject to several breach notification laws and PCI, last accessed by John, Jane and Bad Guy Jack and scanned last week by Qualys which found a poorly configured RPC service.” Now this sounds like pie-in-the-sky but in reality this is the type of information that could be the difference between successfully defending a serious data breach or ending up on the front page news and an anecdote in a security vendor’s marketing presentation.