from Network Computing Magazine March/April 2010The security class series in association with guidance software discusses prioritisation of security alerts
Practicality prevents organisations from dealing with every security event in a uniform way. This is a problem, so what can be done?
There are three recurring themes. Firstly, people naturally respond on an event-byevent basis. This is impossible and can't work. With tens of thousands of alerts streaming in, humans cannot keep pace.
This is why security vendors correlate and aggregate alerts, by putting them into a Security Event Monitor (SEM). SEMs are designed to take multiple queuing sensors and aggregate the data, allowing semiintelligent decisions, by correlating similar cues in an alerting mechanism. Events become an incident when a handler confirms that a response is required. When a sensor recognises an event inside of your DMZ, you will usually receive a report from the Perimeter Intrusion Detection System or Firewall sensors. As it moves into the soft inner middle of your network however, Host Based sensors, like Intrusion Prevention Systems or Anti Virus, will show signs of activity.
In order to elevate it to an incident, it requires multiple, correlated triggers, each verified by forensic validation in order to confirm that signs of compromise exist, and that this signals the existence of potentially malicious code, such as a root kit. (A root kit is a piece of malicious code, designed to sit between the computer user and the Operating System (OS). It intercepts function calls and removes anything it's programmed to strip out, hiding itself in a persistent state).
A forensic tool does not extract its information strictly from the OS as it is able to read data directly from disk and memory. This way it can compare it with what the OS is reporting, bypassing root kit attempts to circumvent OS controls. The second theme concerns following an alert 'down the rabbit hole'. Many people investigate an alert by trying to look into every single correlated alert. You must quickly prioritise against its potential for damage. Whether you're a bank or a hospital, you must consider the context of its operational impact.
If the signs of compromise pose no significant operational impact, then it is prudent to cast aside your inclination to rip into the artefacts, to find out what happened. For example, Distributed Denial of Service Attacks set out to inundate resources so that you can't communicate. If you're an eCommerce business relying on the web to provide your product or service, the impact is immense. If you're a hospital, your primary motivation may be protection of intellectual property, and you would be more inclined to focus on activity that indicates this. Is it the computer resources that are most important, or the data itself? The answer depends on your risk profile.
Incident handlers may be the defenders of the organisations network, but it is the owners and directors that are accountable. These people must be involved in the escalation process prior to declaring an incident. Allow them to make a Risk Assessment, helping handlers to assess operational impact. What may seem catastrophic may prove to be inconsequential, and vice-versa.
The third theme is summed up by the phrase, 'seeing is believing'. You will believe what your sensors have been conditioned to tell you. Stop looking so much at what's coming inbound and start to look at what's headed outbound. The really malicious activity is not likely to trigger your incoming sensors. In some cases, the only indication you're likely to get is when gigabytes of information are leaving your network.
What better way to get information out of a network than to walk out the door with it? Without monitoring outbound activity on your web traffic port, mail traffic port, or secure socket layer, for example, it can happen under your nose. Your direction of focus will determine where you think your efforts need to be placed. Look at your vulnerability assessments. Security is a continual process, not a destination.
In the next edition of this Security Class series, Guidance Software will look at how to handle classified spillage. Computing Security and Guidance Software invite readers comment and questions associated with this series at Ray.Smyth@BTC.CO.UK