Plugging the gaps in your incident response
- Details
- Published: Wednesday, 12 April 2017 08:07
Professor Avishai Woo explains how two gaps may be holding back your cyber incident response strategy: and how filling them ensures that the response takes the needs of the wider business into account.
‘It’s not the problem that matters: it’s how you deal with it’ as the saying goes. So how well-prepared is your organization to respond to a cybersecurity incident such as an attack, data breach or unexpected outage? According to the 2016 SANS Incident Response Survey, 87 percent of organizations said they responded to at least once incident in the past year, and 59 percent of these resulted in a breach. As such, it’s critical to handle these incidents in a way that minimizes damage, recovery time and costs.
To help them do this, organizations have introduced a range of tools and processes to make incident response more intelligent and effective. But a gap still exists in many organization’s response processes, which is the ability to identify the business context of incidents. Let’s take a close look at what this means, and why it matters.
Business context
Most incident response processes are built around a SIEM (security information and event management) system, which collects alerts and logs from security sensors including anti-virus, firewall alerts and so on. This can amount to hundreds or even thousands of alerts per day in a large enterprise, which the SIEM system and associated tools filters to remove false alarms and low-level alerts, flagging only the events that merit closer investigation by the security operations center / centre (SOC).
For every relevant alert – let’s say 100 per day – that is classified as a genuine incident that needs closer scrutiny, the SOC then needs to take two key steps. The first is to triage the incident, gathering information on what is happening, what it affects and what the potential for real network damage it is; and second, to put together and implement a prioritized action plan.
Currently, most businesses do not have an automated process for handling these steps. Some may have documentation to guide the SOC engineers on what to do, or in other cases the entire process may be ‘free-form’, relying on the engineers’ experience and intuition. What’s frequently neglected is the business context of the incident.
Business context in incident response is all about connecting data regarding the security incident to the actual, real-life, business processes or critical applications that the incident may affect. The aim, ultimately, is to enrich the technical detail of the incident, such as ‘this server is affected by this piece of malware’, with the context of the business applications it affects, such as ‘this server is part of our European ecommerce system, and it connects to these core payment applications, and if we shut it down we will be unable to process any payments from European customers.’
As such, business context not only helps the SOC identify which security incidents need to be prioritized, but also which course of action is most appropriate and crucially, when it would be best to address them.
Let’s, for example, imagine that your SOC discovers that your European e-commerce system needs critical security patches. It’s a business priority – but does it absolutely need to take place during peak European shopping hours, with the risk of unexpected downtime and substantial lost revenues? Could it instead wait until 2am Central European Time? With the intelligence provided by the business context, your SOC can quickly weigh up the security risks versus the operational risks, and make the smartest incident response decisions from a business perspective.
Making the connections
Another process that can further enhance an organization’s incident response capability is connectivity analysis. This offers the SOC team an even deeper understanding of an incident’s potential impact by highlighting the connectivity between compromised assets. In other words, it shows how far the attack could potentially spread, and highlights the security risk.
So, turning again to the example of a server being infected by malware, a connectivity analysis process asks: what is that malware going to do next? One typical action might be an attempt to spread to and infect other systems on the network. Another might be to try to steal data from the infected server, and attempt to send that information out to an external controller. A third action might be to open the server to connections from external addresses to trigger a download of further malicious code (which is typical behaviour for ransomware).
The potential severity of these actions depends on the structure of the organization’s network and where in that structure the compromised machine is placed. Is that server able to make outbound connections to IP addresses on the Internet? If so, then malware on that machine is likely to be able to exfiltrate data – which makes resolving the infection a priority to avoid data breaches. However, if traffic from the compromised server is blocked by a perimeter firewall, then the risk of a breach is reduced.
Similarly, if the malware cannot move laterally to infect other systems that host critical data, because the network is robustly segmented, then security staff are in a better position to prioritize incident response.
As with business context, connectivity analysis helps categorize and prioritize incidents according to their risk and impact level. The analysis is done by using a security policy management solution to run automated ‘what if?’ traffic simulations, to identify which assets on the network have been compromised, and which other systems and resources those assets can connect to, both inside and outside the network. For example, the simulation may show that an infected machine is secured against external connections, but not properly segmented from internal servers hosting sensitive material. As such, infections on that machine should be prioritized for cleanup before the infection spreads laterally.
Together, business context and connectivity analysis help organizations to answer the ‘what if?’ questions: what could that incident lead to? What could its impact on the bottom line be? What’s the optimum approach to fixing it, and when? They enable more efficient incident response by helping IT teams to focus on what really matters to the business.
The author
Professor Avishai Wool is CTO and Co-Founder of AlgoSec.
