CyberArm partners with Neustar Security Services to offer best-in-class DNS, application, and network security CyberArm and Neustar Security Services are pleased to announce our entrance into a strategic partnership, combining CyberARM’s industry leading Managed Security & Consulting Services with Neustar Security’s cloud-delivered security services to enable businesses to thrive online. [...]
“When you react, you let other control you. When you respond, you are in control.”
― Bohdi Sanders,
It’s obvious we cannot achieve 100% security so we always tend to build blocks and set plans to recover our data or systems when bad things happen to reduce the risk to a level we call it “acceptable”. The purpose of this series is to help you build your incident capabilities in a simple and effective way. If you are planning to build a SOC, increasing your incident management capabilities is one of the core areas to having an effective SOC.
What is Incident Management
Incident management is like any other business process which should typically be comprised of three pillars: people, processes and technology. Relying on technology alone won’t lead to an effective incident management and response. Having the right people and well defined processes with the right tools are the main perquisites to build a successful incident management process. In this writing, I will cover how we can define and combine all these three pillars to have an effective incident management capability in your organization.
As per ITIL, incident management is the practice of restoring services as quickly as possible after an incident.
As per NIST, incident response is a structured process used by organizations to detect and respond to cybersecurity incidents.
Now we know it is a practice or a structured process to respond to an incident. Nice! but wait! what is an incident? … is it something bad? is it a breach? how to deal with it?
When dealing with security issues, it is important to have a consistent language because people define “incident” differently and use “incident” and “breach” interchangeably.
Event vs Incident vs Breach
Before starting, lets define some important terms that we should constantly use during the course of managing incidents.
Event
If you log in to your computer, it is a log in event. If you open a website, it is an event. Anything that causes a system state change that is not something serious from a security point of view is called an event. Event can be logged and traced.
Incident
If you visit a website that violates your company’s internet usage policy, it is an incident. If you open a malicious attachment, it is an incident. Any event or series of events that violate a policy or a security control is categorized as “incident”. Did anything bad happen? Is there a business impact? not necessarily…
Breach
If a hacker obtained access to your system, it is a security breach. Is security breach similar to data breach? No! it is two different things. If this same hacker obtained access to your data, it becomes a data breach so it’s a matter of order where a security breach happens first and a data breach may follow except where a company negligently expose data, that’s considered a data breach. A breach is defined as an unauthorized access that violates the confidentiality, integrity or availability of an asset.
As you can see, there’s a natural progression in these terms: Events happen and you have to log and monitor those events to detect incidents, and when an incident occurs you have to respond to those incidents to prevent breaches...
Now, lets take a real example to remove any confusion. A user logged in to his computer (Event), opened his email account (Event) and started checking his emails (Event). During the day, he received a malicious email. He opened it and then clicked the embedded link (Incident) and entered his credential (Incident) thus unknowingly giving his credential to the hacker (Incident). Quickly, he realized that the webpage is suspicious and reported the incident to the security team. The security team took the required actions and disabled the user’s account. This would be an incident, BUT this same scenario could have turned into a breach if the user didn’t report the incident and the hacker logged in to the user’s inbox and took data.
Does the notification requirement differ between an incident and a breach in such case?Of Course! Security team may not notify anyone when a user has violated a policy and clicked a malicious link but this won’t be the case when a breach really happens because they may have to notify their customers, partners, law enforcement, etc…
When building your Incident Response Plan, it is very important that you define these terms in order to have a single language across your security team and other teams in the organization.
Defining Incident Tiers
Now we know the difference between an incident and a breach. It’s time to understand the type of incidents and how they differ because incidents are not equal in nature. For example, the incident treatment of opening a malicious link received via an email should not be the same as when opening a social network website that violates a company’s policy.
In the first scenario, you are going to ask yourself if opening such malicious link has caused any compromise to the computer and whether or not the user has given his credentials to the hacker which might escalate to a breach and this is not the case in the second scenario. Also, the first incident might require more effort to investigate and the involvement of more stakeholders to figure out what happened and fix it.
By defining the incident classification tiers, it helps you define the resources needed, the effort needed, the impact to the organization and the actions needed to handle an incident. The purpose is to prioritize incidents. Typically, this can be achieved by answering the below questions:
Answering these questions can help you in ranking the incident.
In part 2, we will talk about the elements of incident response and how we should prepare for a cybersecurity incident.
