The focus of this chapter will be on presenting the idea of security incidents and response. First, we will define a security incident and then move on to developing the process of responding, including roles and procedures for remediation. Getting buy-in from other teams outside of security, including management, is key to the success and effectiveness of an incident response capability. The Taking action section will cover both internal response and leveraging of third parties when necessary. This chapter focuses on the basics of developing and implementing a security incident response capability in the enterprise. Incident response forms and process flow are included in Appendix E, Security Incident Response Resources.
This chapter covers the following:
- Understanding what defines an incident
- Developing security incident processes
- Building an incident response team
- Developing an incident response plan
- Taking action on security incidents
A security incident is as unique as the business type and all the components that make the business function. What may be considered an incident for an online retailer may not be of any significance to a healthcare provider. However, there are commonalities across all business types for events that indicate a security incident.
At the center of every enterprise is information technology; the systems, processes, applications, and data that provide the infrastructure and capability for the enterprise to facilitate the business that it conducts. It is expected that unauthorized access to a system by an online retailer or a healthcare provider would be mutually considered a security incident. It is also expected that because these are two distinct business types, there will be outlier events which, if detected, would trigger an incident response. Each enterprise will need to analyze its critical infrastructure and determine what would be considered an incident beyond the common incidents.
What makes a security incident is any action whether intentional, accidental, malicious, or negligence that causes a negative impact on, or loss to, enterprise data, systems, and applications. An exercise held with teams that are responsible for the various areas of the enterprise will identify what incidents are considered of what impact level to the enterprise and what actions would need to be taken. It is advisable to have this exercise led by the Disaster Recovery (DR) and Business Continuity (BC) teams as its output can be used as input for DR/BC planning. The security team can lead the mapping of the exercise output to technical response action.
For this capability to be effective it will require the collaboration and cooperation of the other teams much like enterprise security monitoring. It is likely that the same team members involved in security monitoring will be the team members defined as contacts for enterprise security incident response.
Common security incidents include:
- Unauthorized system access
- Website defacing
- Denial-of-service attack
- Malware outbreak (impact measured by the scope of infection)
- Password brute force attack
- Misuse as defined in security policies
- Sensitive data loss (accidental or malicious)
- Stolen computer equipment
- Unauthorized physical access to sensitive areas
This list is not comprehensive but it includes the most common events that trigger an enterprise incident response across industries. Thresholds for each will need to be determined allowing for the proper amount of attention and action required to remediate. For example, a virus found on a few systems may or may not warrant a full security incident response; it may only require the efforts of a few teams to remediate the issue and a lower-level incident ticket generated for historical purposes.
There would be a different response if the website of an online retailer was defaced. In this case, there is more impact to the business requiring more teams to not only remediate but potentially handle press, shareholders, the board, and others, because the incident has much higher visibility. It is easy to see that there are economies of scale because several attributes have to be assessed to determine the correct response for the individual enterprise.
There can be confusion over what is a security event and what is a security incident, and how to know when detected or learned events become incidents. A security event is a component of an incident and when there are multiple correlated events, an incident is the result. However, in some cases the initially detected event can be the incident and be treated as such in response. An example would be a stolen laptop; it does not consist of a series of events that comprise the incident, the event itself is the incident. This involves a bit of semantics too, but for the purpose of this book, events will be treated as seemingly disparate entities and incidents, a culmination of events. An example of a security event is a triggered signature on an IPS. This may not require an immediate response, but several of the same or related events may indicate a larger issue and therefore would be labeled as an incident.
Typically, the security events far outnumber the incidents, in particular those that require a formal incident response. In the following graph, the number of events is fluctuating and is infinite over time while incidents occur at a much lower rate and are finite:
