Are you ready for the next security incident in your organization? In this video, you’ll learn about the categories of incidents, roles and responsibilities of your incident response team, and the importance of running exercises prior to an actual incident.
There are many different kinds of security incidents. There might be a case where someone clicks an attachment in an email, and that attachment installs malware onto someone’s system. From there, the malware then is able to gain access to both internal and external systems. Or the security incident may be one that creates an outage, such as a distributed denial-of-service attack created by a series of botnets.
Maybe someone has broken into your systems and has stolen confidential information, and now the thief would like some money or they take all of the information and make it public. Or a security incident may be somebody who is inside of your organization installing peer-to-peer software that then allows external access to all of your data.
All of these incidents are very different in the way that they operate, and internally, you might want to categorize them into different types of incident categories. The categories that I show here are based on the computer incident handling guide that is available from the National Institute of Standards and Technology. But, you can build your own categories that make sense for your organization.
One type of category might be one that deals with external or removable media. If somebody installs malware because they plugged in a USB drive, this may fall into the category of removable media. If someone’s performing a brute force attack, we might categorize that incident as attrition. If somebody is attacking a web server, then we can categorize this in the web category of attack types. Email is another very common way to attack, and it’s common to create a category of attacks based around how people might attack an email system.
If we have users inside of our organization that are not following the acceptable use policy, then we may want to categorize those types of incidents as ones of improper usage. We also have incidents that occur when people lose critical pieces of hardware. And if a laptop or a mobile device is stolen, we may need to categorize that as the loss or theft of equipment. And, of course, create whatever categories make sense for the type of tracking and analysis that you need to provide in your organization.
When an incident occurs, there are a number of different people across the organization that will be involved. One of these might be the incident response team. The incident response team is a very specialized group of people who have been trained to deal with these types of security incidents. One might also need to involve the IT security management. They will be able to make decisions about how to handle this particular incident, and how it might affect all of the organization.
We might also need to bring in our compliance officers to make sure that anything associated with this incident is also compared to the compliance that we must follow as an organization. We’ll have technical staff, of course, that will be helping us in the trenches. And we’ll always want to involve our user community to help resolve any type of incident that may occur. This is not a comprehensive list. You will certainly involve other parts of the organization, such as your legal team, public relations, you will have security operations and other operations teams, and many other parts of the organization will be involved when there there’s an incident.
As you can tell, we may need to contact a number of different people if there is an incident. You will already have a set of incident response policies, and they’re going to determine exactly who gets contacted initially for a particular incident and who may be contacted for ongoing updates. That contact list is one that you should already have available. And you may need to contact people incorporate or the organization, such as the CIO or the head of information security.
And there might be people internally that are not part of IT. For example, human resources and your legal department may be involved with certain kinds of incidents. And there may be people outside of your organization that you need to contact. If this particular incident involved a service that dealt with a third party, you may need to contact that third party. If something criminal has occurred, you may need to contact law enforcement. And if you’re part of the US government, you may be contacting US-CERT, which is the United States Computer Emergency Readiness Team.
Many organizations will already have a predefined group of professionals whose job it is to receive, review, and respond to these types of cyber incidents. This is the Cyber-incident Response Team, or the CIRT. We’ll need to determine what type of incidents are appropriate for the CIRT to respond to. If you have a virus infection, you may or may not have the CIRT involved.
But what if it’s ransomware or a denial of service? The CIRT may not be part of the formal organizational structure, it May be a group of people that are brought together when an incident occurs. And this group is usually focused on handling the incident. There will be a response to the incident, this group will perform analysis of this incident, and provide a report of the security incident that occurred.
The time to test your response team is not during an actual event but instead, during an exercise. You want to have standard times of the year when an exercise might occur. Maybe you perform them annually or semiannually, but you want to be able to perform some tests prior to an actual incident occurring. There will be well-defined rules of engagement. For example, during an exercise, we may not be touching production systems, but instead may be focusing only on test systems.
And there will probably be a very specific scenario that has been defined– one with a very small scope that you can use to get through this in a relatively short amount of time. Sometimes, you may not even be performing the actual response but instead, performing a tabletop exercise where everyone discuss what the steps might be in the process. And once the exercise is over, you have an opportunity to document what occurred and discuss ways to make the process better the next time.