When an incident occurs, there needs to be a clear plan of execution. In this video, you’ll learn how to create an incident management strategy for your organization.
<< Previous Video: Change ManagementNext: User Rights and Permissions >>
Security incidents are going to occur in your environment. The key is how you handle those incidents when they happen. And these could be some very broad types of problems that might occur. It might be somebody hacking into a database and getting all of your customer private information. Maybe a laptop that’s stolen or maybe something like a water pipe bursting. And if that occurs in a data center that then becomes a security concern as well. And something that has to be considered in you have to react when that incident happens.
The first thing you should know about mitigating risk here is who you contact, who you talk to inside the organization. Are there organizations or people you have to talk to outside of the organization? This becomes important when you’re dealing with finances for instance, if you’re a very large financial organization, and a security risk occurs you may be legally obligated to contact government agencies and inform them of that particular security breach. So that’s one of first things you have to think about when you’re showing up with an incident. Something has just happen is, who do we make aware that this has happened? You also have to think about who’s responsible for this problem when an incident occurs. If it’s with the database maybe the responsibility of that lies with the database administrator, maybe to your security professionals, maybe it’s somebody who is responsible in the data center. So now we get together all of the groups of people responsible for this to resolve or address the incident that has occurred. This is going to be your expert list two, and this may be external people that you’re calling.
If somebody’s has got into a database, and they’ve got into very sensitive data, and you really want to go back over this and find out forensically how did they get in here, what happened, we may need knowledge from the outside. We many professionals that deal with this all the time. We’re going to call these people that we have a retainer, these people that we’ve talked to and have a relationship with. Bring them in and get that help if you need it. You also need to think about what the technical steps are going to be, when you arrive when a problem occurs, and you want to make sure that you’re able to preserve evidence but still maintain uptime, it’s a very interesting balancing act.
If somebody’s taken over your email server maybe you unplug the server from your network connection and you start rebuilding locally, because people are going to miss the email if it’s down for a few hours. But if this happens to be your primary web server or your primary database, maybe it’s not as simple as unplugging this from the internet, maybe we need to provide some access to this database, and instead start working the problem with it connected to the internet. You have to make those decisions sometimes on the fly. And if you have everybody involved, and you’re getting feedback from everybody, and everybody can sign up and say, yes that’s the proper way we should go for handling this particular incident.
You also have to think about what gets documented. What goes into the report? This information is something that you’re going to use to go back over time and find out what happened during that time frame. But it’s also something you’re going to be able to use in the future. And if you need to be able to have some type of legal action brought against the person that caused this incident then you’re going to need to make sure you document as much as possible. So always keep that in mind and always think about documenting exactly what’s going on. We have an entire module on incident management. We talk about the things that you’re able to do to document pictures, and video, and things that you write down. It becomes an important part of this incident management.