Once the enterprise has determined that security incidents require a process or set of processes in order to respond properly, the security team must begin working with key teams to build the formal process. Because there will be a need for support from the various teams in the enterprise, it is important to involve them in the development of the incident response process. This will also enable the teams to build the necessary procedures to react to specific types of incidents.
The key concepts and knowledge transfer of a forensic approach to a response is important to ensure that legal action can be taken if warranted. As with security operations, it is equally important to have experts in various technologies provide input on the process and output procedures to reduce the impact of the incident response. There must also be a means to trigger the incident response process, ideally through an existing ticketing system. In order to ensure that the proper response is initiated, the ticket will need unique categories for security incidents, and severity levels to determine which incident contacts need to be alerted, and when to trigger other non-IT related responses such as HR, legal, and press release staff.
The next section covers building out the incident response process and highlights recommended supporting processes.
While on the surface most security incidents appear to be network-related, there are also security-related incidents such as physical access violations or social engineering where a packet is never sent over a network. SIEM, IPS, firewalls, and other network-based security tools will only detect and alert on network-based incidents, but other security incidents must be accounted for in the process and developed into the security incident response plan, the formalized output of building supporting processes. There are several threat surfaces for the enterprise and each should be identified and scenarios developed to determine how to detect an incident and the next steps. In some cases this will be reliant on deployed security monitoring tools, in other cases detection will rely on an employee to respond and alert the security team and other personnel of the event.
A physical security incident is much different from a network-based incident because it requires a human to detect the incident, such as a stolen laptop. There are some physical controls such as alarms and card scanners that log access attempts. These are typically handled by facilities' security and rarely is the IT security team alerted to these activities. IT security will normally only be involved in case some form of data was lost or stolen as a result of the lost or stolen asset. An example may be a stolen preconfigured network device that provides details on the internal network design. In the case of unauthorized access to restricted areas such as data centers, there may be a collaborative response with facilities security and IT security.
When no technology-based controls are in place, employees must be trained to identify incidents in their environment. They must also know what steps are required for the various types of physical security incidents they may encounter. Wherever controls have been implemented for physical security, there must be a coinciding reporting method for violations of the controls and/or policy to alert security staff of the incident to ensure prompt action.
Security events detected at the network layer are almost too many to know which are of significant threat requiring immediate attention and which need to be ignored or simply monitored. With the help of correlation tools such as SIEM, identifying incidents can be easier through the automation of incident generation. There are methods and techniques used that will require manual review of security monitoring tools' output to look for anomalies such as packet analysis. It is common for something detected to be an anomaly that warrants investigation, however, it is never triggered as an incident in a SIEM. Whichever method is used to correlate events and generate an incident for investigation, an action will need to be defined in the incident response process and assigned severity and priority agreeable to all responding parties. It is advisable to have a security operations capability either within the security team or leveraging an existing network operations capability. The nature of network-based incidents requires constant monitoring and investigation. Some incidents will trigger the full incident response process, while others can be investigated and responded to within the security team or with smaller teams and do not warrant invoking the complete incident team.
As with any enterprise process, the incident process needs to be managed to be effective and repeatable. An assessment of the existing enterprise incident management tools needs to be performed to ensure that the solution can be configured to handle security incidents separate from other forms of enterprise incidents. If there is no existing incident management tool, there may be a lag in responsiveness to critical security incidents and the overall response may be poorly executed.
It is important to have a unique incident management process within the incident tool to ensure that response severity, priority, and contacts are specific to security incidents. In most cases, the standard incident configuration is incorrect for security. Additionally, security incidents may include sensitive data that could implicate employees. Confidentiality is of utmost importance for security-related incidents requiring limiting of access to incident details to only the response team and key management members for proper, controlled dissemination of information.
Once the incident has been responded to and the incident closed, there should be a "lessons learned" session to determine how to mitigate the incident in the future, discuss improvements in response, and update procedural documentation if needed. It may also be required to adjust the severity, priority, and responding team members for the specific incident type to ensure the most effective response to future incidents reducing the overall impact to the enterprise. This is depicted in this diagram:
