Section Introduction, Lessons Learned & Reporting Flashcards
Introduction
This section of the Incident Response domain focuses on reflecting on the incident once recovery has concluded. This is to determine what went well and what could be improved, with the overall objective of developing security controls to prevent similar incidents, and reviewing the response process to identify any potential weaknesses and enhance response in the future.
Learning Objectives
By the end of this section you will have achieved the following objectives:
How to review on what went well during the incident, and what could be improved upon if a similar event occurred in the future.
Understand ways that security teams can improve their response to security incidents.
Understand the importance of documentation, updating the incident response plan, and updating or creating new run-books.
Understand why metrics are collected and used to identify strengths and weakness to aid incident response development.
What Went Well?
While reflecting on the weaknesses of the response to an incident is important to learn and grow, it’s still crucial to concentrate on how the response went well. Members of the incident response team should be appraised for their work containing and dealing with the incident, returning business operations to normal. As mentioned at the start of this course, simply being given appraisal and feedback can prevent issues such as imposter syndrome and professional burnout.
At a post-incident meeting, all appropriate stakeholders should gather to review the incident from start to finish. Some examples of discussion points could include:
Who performed well?
Were any new tools or processes used that provided benefit?
Review the metrics that have been collected from the incident.
Review the communication between different company departments.
Identifying areas where the security team and other departments operated well should be highlighted, and these should be properly recorded within run-books so that the same approach can be used in future incident responses.
What Could be Improved?
Identifying weaknesses in the response to an incident can help organizations to better prepare and respond in the future, potentially reducing the amount of damage that malicious actors can conduct, and minimizing the impact to the business. This lesson will cover how security teams and incident response stakeholders should identify where they lacked, and how it should be addressed.
During the post-incident meeting, all stakeholders should take the appropriate time to reflect on the issues they had during the process. Did someone mess up evidence collection? Were the team lacking resources such as laptops and blank hard drives? Once weaknesses have been identified, it is important to discuss how the organization can ensure that they don’t happen in future incidents. Questions that could be asked include:
What limitations were there regarding tooling?
What limitations were there regarding procedures and guidelines?
Did any individuals or departments hinder the incident response? How?
Consider how each of the NIST Incident Response Lifecycle stages was weak, and how it can be improved in terms of resources, personnel, and documentation.
Now that the weaknesses have been uncovered, it is important to ensure that there is actually change. There’s no point highlighting these issues if they won’t be fixed. This is the perfect time to discuss with management the need for resources to strengthen the response to future incidents. This can include:
More budget for security personnel such as Forensic Analysts, Incident Responders, Incident Commanders, etc.
More budget for personnel in other departments, such as Legal, Public Relations, Communications, or Human Resources.
More budget for tools that can assist with incident response activities.
Review of documentation such as run-books, policies, and procedures.
Importance of Documentation
As mentioned previously in this domain, maintaining an incident response plan (IRP) and response run-books for different scenarios is key to quick and straightforward responses. By recording every incident in detail, if a similar one occurs, analysts can refer to the documentation of the old incident for guidance. The following documentation could be updated after an incident, if appropriate:
Incident Response Case Notes
Whatever tool the organization uses to record security investigation notes in (such as ServiceNow and IBM Resilient) should be completely updated to ensure that the case contains everything it should, such as information from all stages of the incident response lifecycle, artifacts should be included, such as file names, file hashes, IP addresses, domain names, etc. Attachments should be added to the case, including emails sent to stakeholders, copies of malicious files, log files, and anything else deemed important to the investigation.
Incident Response Plan
Maybe the overall response process could be improved, which should be discussed and any changes be implemented to the organization’s incident response plan (IRP). This could include changes to stakeholders that are part of the incident response team, new methods for secure communication, changes to contact numbers or email addresses, and other details that are consistent across all potential incidents.
Incident Run-Books
Reviewing run-books for the type of incident that has occurred can help to improve future responses by providing guidance for analysts that respond to the incident in the future. The more detail in these run-books the better, as it’ll encompass more potential scenarios, working to make future responses more structured and organized.
You can find lots of example run-books here to get a feel for what they look like and include.
Organization Policies
Maybe the incident occurred as a result of an action that wasn’t properly restricted by organizational policies, such as a user downloading software from the internet because the Acceptable User Policy doesn’t prohibit them from doing so. Updating this policy stating that all software should be acquired from an internal repository, or employees can create a ticket with the IT Service Desk to have the software downloaded for them from known safe sources will prevent future incidents, or at least provide solid accountability. Another example would be an internet-facing system that didn’t have updates and security patches applied, because there is no vulnerability management or patching policy, requiring the system owners to keep it up-to-date and secure. Implementing this could again help prevent similar incidents in the future.
