“It’s not the problem that matters: it’s how you deal with it”, as the old saying goes. This accurately describes what incident response is all about: at some point, it’s inevitable that your network will experience an attack, breach or unexpected outage. According to the 2016 SANS Incident Response Survey, 87% of organizations polled said they responded to at least once incident within the past 12 months. Of these, 59% resulted in a breach – so being able to handle the situation in a way that minimizes damage, recovery time and costs is critical. Over the years, organizations have introduced a whole range of tools, technologies and processes to help make incident response as intelligent and effective as possible.
Nevertheless, we think there is still a major gap in many organizations’ incident response processes. That gap is called ‘business context.’ Here, I’m going to explain what business context means in terms of security incident response, and demonstrate why it matters.
The current state of incident response
At the heart of many organizations’ incident response processes is a SIEM (security information and event management) system which collects alerts and logs from a broad range of security sensors, such as anti-virus, firewall alerts, IDS and so on. Clearly, this involves a vast amount of data – tens or even hundreds of thousands of alerts per day. Some SIEM solutions may also include business logic or analytics engines to sift through this information, removing the false alarms and issues that will be automatically corrected by security tools, and flagging the events that merit extra investigation by IT or security teams.
Let’s suppose that of those many thousands of alerts per day, 100 deserve to be classified as ‘incidents’ – that is, a sign that something genuinely unusual or threatening is happening on the network. Maybe it’s nothing – but maybe it’s the first sign of a phishing attack, or a malware infection.
These incidents are passed on to a security operations center (SOC), staffed by IT security specialists. The SOC might be an in-house department, or it might be outsourced as part of a network monitoring service. Either way, for every relevant incident, the SOC needs to take two key steps:
Currently, the norm is that many organizations do not have an automated process to help them handle these steps. Some may have documents instructing SOC engineers what to do; in other cases, the process may be free-form and left to the knowledge and experience of the engineers. What is often neglected by organizations – because they may not have the appropriate solutions in place – is the business context of the incident.
Business context matters
Business context in incident response is all about connecting data regarding the security incident to the actual, real-life, business processes that the incident may affect. There are plenty of tools and technologies available for the SOC to analyze the technical aspects of an incident – they can identify the name, location, OS and associated software of a compromised server, or the type of malware that has infected the network, for example – but until now there have been very few tools available to link this technical information to the impact on the business.
At AlgoSec our goal is to bring the business process context into the incident response process. The aim is to enrich the technical detail of an incident with the context of the 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 prioritized, but also which course of action is most appropriate, and crucially, when it would be best to address it.
Following the scenario above, imagine that your SOC discovers that you need to apply critical security patches to your European e-commerce system. It’s a priority – but does it absolutely need to be done during peak European shopping hours, with the risk of unexpected downtime and lost revenues? Or could the patching process wait until 2am Central European Time, when the number of transactions will be much smaller (an issue that we covered in detail in an earlier blog on managing security on international networks)? With intelligent business context, your SOC can quickly weigh up the security risks versus the operational risks of potential downtime, and make the smartest decision from the business perspective.
Business context in incident response is all about ensuring a closer alignment of IT security with business strategy and operations: making security work with the business, not as an add-on to it, to ensure an optimal response is delivered to any kind of incident.
Receive notifications of new posts by email.