Small, medium and large organizations have trouble separating what is the process for handling a security incident versus handling a regular IT incident.
What are the different items that organizations should think about when they are looking at incidents? What is the definition of incidents versus the security perspective of incidents and what does that mean for multiple environments? How should these security incidents be handled differently?
The typical goal of IT Incident Management is not to identify evidence but rather to restore the status quo. There is no concern about the 2 important pieces of security which are – integrity and confidentiality – it rather focuses on 100% availability.
Here are the 5 main reasons why we shouldn’t follow the same methodology for security incidents as regular incidents:
Whether planned or unplanned, there is always a threat agent behind a Security Incident. Whether it’s malicious or non-malicious, there is always intent to do harm.
That is the main reason why we can’t take that standard approach. There is intelligence behind the event.
When looking at Security Incidents and IT Incidents, it all moderately looks the same; Preparation, Detection, Diagnosis or Analysis, Repair, Eradication, Recovery. Everything matches below except for the containment phase.
If you try to eradicate a security event without containing then in your environment, you are playing whack-a-mole with your security, it is popping up everywhere and you are continuously in a cycle of taking care of infection or threats. You are supposed to look for containment, quarantine strategies when looking into your threats.
[table id=19 /]
In an IT Incident you are not trying to contain anything, you are trying to get a user back to status quo as quickly as possible. Containment is no longer a notion.
Information Security is like a hospital emergency room. If 60 patients all come in at the same time, the hospital will prioritize the patient with the greatest impact or the greatest risk to life.
For example, a head injury will be treated before a broken arm; a broken arm before a cut on the leg, a cut on the leg before a cold etc.
In some cases, there is no visible impact at all. In the event of a home invasion, any individual would look around to see if someone stole their money, their TV etc. What they may have missed is they could have stolen the keys to their office, their credentials to get in the office building and documentation on their laptop that would give them access.
There is no visible impact, or the actual impact is still unknown yet. It is covered up by another activity.
IT Incidents are shared on a “Who can help” basis, however, Security Incidents are shared on a “Need to know” basis.
Real Life Example:
In the Help Desk department, employees call about a user with a problem that needs to be fixed. Everyone helps each other to get users back online and solve their problem. In security, it is a “Need to know” situation. You don’t want to take your security tickets and your incidents and put them on your service implementation that is being supported from offshore.
Incidents have to be handled carefully. You need to follow specific steps. There is not a single communication plan for a Security Incident. There are many communication strategies that you need to have at play. What you need to define is what to communicate and when to communicate it.
Here are some of the questions you have to ask yourself:
All of that represent important pieces that need to be defined in the process.