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
- Manually from alerts or automatically via alert rules
- From the service catalog
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.
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
The following podcast offers additional information on the use of Security