Definition of Incident Response Terms
What is a Security alert
A security alert is a technical notification/warning/signal, from IT devices, about security issues and vulnerabilities etc. It helps in quick detection of cyber threats.
What is a Security event
An event is an observable change in an information system, happened at some point of time. Examples of cyber security events could be:
- A system crash
- Routers getting updated
- An ‘IT request’ for an anti-virus to check a folder
What is a Security Incident
Cybersecurity event Vs Cybersecurity incident
Information sources
Monitoring
Investigation
Incident Response Team
Type of Cyber Security Incidents
Why is Incident Response important?
Goals of Incident Response
Components of incident response plan
Indicators of an Security incident
7 phases of incident response
The cyber security incident response cycle comes from the NIST guidelines gives you a structure for dealing with an incident. We will go into more detail now. Just because you have an alert you do not call the entire incident response team together.
1. Preparation
2. Identification of incident
3. Containment
4. Investigation
5. Eradication
6. Recovery
7. Follow-Up
Step 1 – Determine if there is an incident
1. Head of security or incident response team has been alerted to unusual behavior by an individual or device.
*this stems from the monitoring services at the time of preparation section
Perhaps notified by some outside source that interesting things are happening.
- Might be a new vulnerability announced
- A detected incident
- May be a gut feel that something fishy is taking place in the system
2. Now Security or Incident Response Head is responsible to determine if there is an incident.
3. Begin to gather information from the alert source
4. Perform an initial investigation.
The cyber security incident response cycle comes from the NIST guidelines and gives you a structure for dealing with an incident. We will go into more detail now. Just because you have an alert you do not call the entire incident response team together.
Usually what happens is the head of the team or the person tasked with reviewing the logs and incidents will look at the alert and do a little investigation. This is how you begin to determine if there is an incident.
Based on the advance notices you get via an alert, that might come from your monitoring systems or from a person, you begin to gather the information.
You need if a person walks into your office or if you received an email from someone. You ask them a lot more information about what they saw and why they thought, that was unusual an alert coming from your monitoring system. They would take a look at that and try to pull out the information just exactly what was that alert trying to tell you.
And you will be looking to see if there are any other alerts related to the one, you’re investigating.
Once you have those alerts you’re going to start doing your initial investigations. You will be looking at the information sources you have prepared ahead of time so that you can begin to understand if anything is really going off.
Once you have made a determination, of the alert, it requires more investigation, review your alerts and try to understand what it is they’re telling you.
Look for other alerts that may be related – that’s a really important part. There may be other things that are being alerted but didn’t rise to the top or mean anything to you at the time but now that you suddenly have this big important alert you begin to see that those were steps in the process of getting to where you are now.
All those things put together can tell you this is really a security incident or if something else is going on.
Now that you know that this is a real security incident look to see what logs you have in place.
Make sure you really have them then determine if you need to get them secured right away. Remember there is a time frame on each log. A log only lives for so long and yours might have become very critical.
Now you might need to do something to save them and make sure they stay around longer than they normally would.
As you investigate the logs you will begin to characterize what type of impact of this incident might have on your system. This process of characterizing the incident is a very anti process. As you gain experience you will be better able to do this characterization.
Questions you will want to ask:
- Is it causing harm today or not?
- If it is causing harm it is going to make you do things differently than if it is something out there you can watch.
- If somebody is doing something in their own allocation, could you probably let that run and do more investigation?
- If it is something that is impacting other people?
- Is it an old event, going on for a long time?
A case like this the impact might already have happened so it might be better to watch it and get a better understanding for what is going on or maybe it is a brand new, you need to cut it off right now.
These are the things you need to understand and start to make decisions:
- Who is going to make the decision about what to do?
- who are you going to need to pull in on this?
- What attack vector are they using?
these are all early things that help you decide and characterize what the incident is and make the determination and how you’re going to approach it.
Once you have a characterization of your incident you need to start pulling together one information you must really look at the incident in detail.
Begin gathering your information. Remember you might need to move it to a different location to better facilitate examine it or to better protect it.
Most likely this will be all your various log files. These are the logs you identify as the important ones during your initial preparation phase.
Remember the things like firewall and logs usually have a very short timeframe for their lifespan. You will want to get those as quickly as possible and move them to a secure storage location, so that you do not have to worry about losing them.
You might also want to take snapshots of the system. The system is something that is very dynamic, and its state only has meaning during the incident. So, these snapshots are not something you can have it being done like logging, but it is something that you should be part of your procedure for certain incidents.
After you have gathered and secured your information you need to address mitigation.
Is there anything you need to deploy quickly to get things under control? Probably one of the first things you are going to do is increase your monitoring.
Many of the logging and alert systems and various levels of information that they give out during an incident particularly one that is currently going on you might want to up the level of information so that you can really see what’s going on in great detail.
You might also consider making changes to your firewall to stop traffic or even black holing traffic.
All of this will be based on the determinations you make while investigating the situation.
What is the right thing to do? That is hard to say as each situation is different and learning how to decide what the correct action at a time is, takes experience.
That is why you want to have contacted people, who have experience and expertise of this type of thing and have their contact information available to you.
Once you have secured your information sources and begun to make some determinations on mitigation there are some additional questions you should consider before you go too much further.
Decide what the response goal is for the incident.
Is your plan to search out every detail and piece of information so that you can track down the individual and prosecute?
Or is it you just want to fix things and get everything back up and running?
Deciding these goals is important and will dictate how you pursue your incident response.
Once you have decided what your goals are, you need to readdress your procedures.
Are they currently relevant for the incident you are working? Hopefully, your procedures are in line with their goals.
However, goals can change this time goes on. Also, each of the that might have a different goal associated with it for you most likely your procedures will not cover everything.
That is what makes the post incident reviews so important.
It gives you a chance to examine what happened and then modify and grow your procedure. If the event you are investigating is going on concurrently with your investigation well, you need to perform any type of live real time analysis yes.
So, do you have the tools you need to do that?
Do you know how to use those tools?
This is something you should consider during your preparation phase these questions are things you’ll have to look at during the investigation if you have bad backups or no backups that means you’ll need to really dig
deep and find out everything that happened so you can undo the damage.
If you have good backups, it might just be simpler to rebuild the system.
Privacy breaches are a special case in the particular note.
When dealing with PII, PHI or any of these special cases you need to contact additional people when an incident occurs most likely.
A lot more people will care about this type of an incident since it can have far-reaching implications. It could violate different federal regulations and you need to be aware of that.
Make sure your plan covers what needs to be done in these types of situations. Privacy breaches aren’t just limited to things covered by federal regulations.
You need to know what the privacy policy for your organization says.
So be aware of that and what you need to do if your incident violates one of those policies
NIST Incident Response Plan
Read here