Security Incident Response overview

With Security Incident Response (SIR), track the progress of security incidents from initial analysis to containment, eradication, and recovery.

Vulnerability databases can be used to proactively prevent issues and track down other systems that may also be vulnerable to attack. Additionally, a wide range of reporting and tracking systems are available for detecting trends and issues, and gauging your performance. Integrations let you use your preferred monitoring tools and link your security incidents to the related systems, users, and business services within your instance.

To protect investigations and keep security incidents private, restrict system access to specific security-related roles and ACLs. Non-security administrators can be restricted from access, unless you expressly allow them entry.

Security incidents can be logged or created in the following ways.
  • From the Security Incident form
  • From events spawned internally or from external monitoring or vulnerability tracking systems
  • Manually from alerts or automatically via alert rules
  • From the service catalog

Analysis

On the Security Incident form, view incidents, changes, problems, and tasks on the affected CI. The system can identify malware, viruses, and other areas of vulnerability by cross-referencing the National Institute of Standards and Technology (NIST) database, or other third-party detection software. As security incidents are resolved, any incident can be used to create a security knowledge base article for future reference.

Further analysis can be performed using the Business Service Management (BSM) map to locate other affected systems or business services that may be infected.

Containment, Eradication, and Recovery

While monitoring and analyzing vulnerabilities, you can create and assign tasks to other departments. Use the BSM map to create tasks, problems, or changes for all affected systems, documents, activities, SMS messages, bridge calls, and so forth.

Figure 1. Sample BSM Map
BSM Map

Review

Significant incidents may need an incident resolution review, also called a post-incident review. This can take on several forms. For example, the incident manager can:
  • Conduct a meeting to discuss the incident and gather responses.
  • Write and distribute questions designed for each incident category or priority to those who worked on the incident, to review incident resolution.
  • Write the report and gather information on their own.
A report for incident resolution review can be automatically generated. The report includes the following:
  • A summary of what was done
  • The time line
  • The type of security incident that was encountered
  • All related incidents, changes, problems, and tasks
  • The details of the resolution
An automated survey system for reviewing security incident resolution is also available. It gathers the names of all users assigned to the security incident, and sends a survey to gather data about the handling of this incident. This data can then be made available in a generated security incident review report, which can be edited into a final draft.

The following podcast offers additional information on the use of Security Incident Response.