Not All Intrusion Alerts and IT Incidents are Created Equal
With all the intrusion alerts received in a day, it is important for companies to define from their perspective – What exactly is a security incident? And more important, what can organizations do to improve their incident response approach? This article takes a look and offers a framework to help define and streamline cyber-attack incident response processes.
Not All Incidents are Created Equal
We recently participated in a valuable panel session at the SecureWorld Boston event. The participants represented a wide range of backgrounds and roles and led a lively conversation about the current and future trends in cyber-security.
One of the most interesting topics was initially posed as a question: “What exactly is a data breach or information security incident?”
Broadly speaking, a security “incident” is something that could be thought of as something unknown running through your environment. It can also be the presence of something unexpected in your environment, or conversely, something missing from it. All of this is true, and it all may result in an intrusion alert that from one or more of installed security tools which the InfoSec teams need to investigate.
Additionally, initially, people tend to think of an incident in the context of a cyber-attack. Again, this is true, but at an even higher level, you can break incidents down into two different types of incidents: operational and security. An operational incident, such as a server going down, is often assigned to an IT help desk and is generally not considered a malicious event.
Should you react to all intrusion alerts or potential security incidents in the same way? The short answer is no, in part because of the sheer volume of alerts InfoSec teams would have to investigate. Research shows that organizations receive an average of 5,000 intrusion alerts per day, generated from existing security tools such as firewalls, IDS and IPS systems, and more. There just aren’t enough resources – or hours in the day – to follow up on them all.
Considerations when forming an incident response approach
So, what’s an organization to do? The following are just a few items any organization should think about as they look to improve the cyber-attack incident response:
- As discussed above, define what a malicious incident looks like to your organization. Perhaps you’re willing to accept the loss of an individual PC to a malware attack. However, having a server go offline or an application disappear, especially one that uses or stores sensitive data, is much more serious – and warrants a higher level of scrutiny.
- Another is deciding how and when to involve the end-user. If the organization decides that user logins at odd times of day or a series of failed logins are worth investigating, one of the fastest ways to check in with the user directly – “trust but verify” the unusual behavior.
- Then, organizations should establish an infrastructure that makes it as difficult as possible to penetrate. For example, an infrastructure that remains stagnant is easier than one that mandates password updates and/or dual authentication. This increases the chances that a security event can be caught earlier in the process.
- Determine who from the organization is involved during all stages of the investigation. Perhaps the effort starts with a small team of internal staff, and then expand to include more resources from management or larger IT team. Preplanning is critical and with the plan published ahead of time, an organization can pull together a well-coordinated, timely response to the attack.
A focus on your most critical data
Having an agreement on what an intrusion incident looks like for your organization is critical and an important piece of your incident response plan. However, having the right security infrastructure and tools are equally important. Needless to say, there are many moving parts, during a security incident and the execution of a cyber security incident response plan. Even though these plans are written to address the worst case scenario it still requires things to be executed perfectly. Unfortunately – and perhaps not surprisingly – that doesn’t happen very often.
Therefore, we recommend focusing on protecting your most critical data. Just doing this alone will reduce much of the intrusion alert “noise.” By focusing on your critical data, you can set-up an infrastructure to record all traffic between your critical devices, go back and pull packet level details, and complete breach investigation faster – all critical for faster incident response and staying compliant with data privacy regulations.
If you place the majority of your attention on your most critical data, you can analyze events much faster. You can also automate key processes to answer those questions that always need to be answered in much less time.
Interested in learning more? Download the CSPi security incident response white paper, “Get Ahead of Cyber Attacks,” today.
*** This is a Security Bloggers Network syndicated blog from Blog – CSPi authored by cspi. Read the original post at: https://www.cspi.com/information-security-incident-blog/