NIST Cybersecurity Framework 2.0: Respond
Authors: Mark keppler, steve foretCybersecurity Frameworks Series, part 8
Today, we will take a deep dive into the RESPOND function. A significant cybersecurity incident is a crisis. Few of us are at our best during a crisis. That is why we at SEVN-X preach that the time for preparation and defining steps is before the breach, not during, and certainly not after you’ve already had one (though an analysis and post-mortem after an incident must be done).
The goal of the RESPOND function is exactly what it sounds like – build capabilities to facilitate an appropriate response to a potential cyber-attack and define the actions that should be taken. RESPOND supports the ability to contain the effects of cybersecurity incidents. Outcomes within this Function cover incident management, analysis, mitigation, reporting, and communication.
Sub-functions of the RESPOND function include:
Incident Management (RS.MA):
Responses to detected cybersecurity incidents are managed.
The Incident Management category requires that you have a plan and execute the defined steps of the plan as required.
RS.MA-01: The incident response plan is executed in coordination with relevant third parties once an incident is declared.
RS.MA-02: Incident reports are triaged and validated.
RS.MA-03: Incidents are categorized and prioritized.
RS.MA-04: Incidents are escalated or elevated as needed.
RS.MA-05: The criteria for initiating incident recovery are applied.
It’s 2024 and cybersecurity has been making headlines for a while now. Senior management of most organizations are asking questions about cybersecurity and especially ransomware. By now all companies should have an incident response plan and most do. But are they good plans or something downloaded from the Internet? Also, response plans should have “playbooks” that are specific to the type of incident identified (ransomware, business e-mail compromise, data leakage via lost media, etc.).
Plans should be tested and improved (ID.IM-02) and response personnel must know what’s required of them (PR.AT-02). Incident response exercises have become more common and there’s no good reason for not doing one, except if you know your plan’s been downloaded from the Internet and doesn’t reflect reality.
Incident Analysis (RS.AN):
Investigations are conducted to ensure effective response and support forensics and recovery activities.
The Incident Analysis category requires that you perform an analysis of what’s happened, what cause the incident (source, tactics, etc.) and the impact and document the steps taken by the response teams.
RS.AN-03: Analysis is performed to establish what has taken place during an incident and the root cause of the incident.
RS.AN-06: Actions performed during an investigation are recorded, and the records’ integrity and provenance are preserved.
RS.AN-07: Incident data and metadata are collected, and their integrity and provenance are preserved.
RS.AN-08: An incident’s magnitude is estimated and validated.
There’s a heavy dependency on controls applicable to DETECT – otherwise root cause and other details might be difficult to identify, and you may never know precisely what happened.
Incident Response Reporting and Communication (RS.CO):
Response activities are coordinated with internal and external stakeholders as required by laws, regulations, or policies.
The Incident Response Reporting and Communication category requires notification of stakeholders and law enforcement.
RS.CO-02: Internal and external stakeholders are notified of incidents.
RS.CO-03: Information is shared with designated internal and external stakeholders.
Most response plans we see have contact information for an escalation team of internal stakeholders and often has key external contacts and law enforcement contacts. Common gap is that organizations may have executed contracts with customers that contain notification requirements and timelines. Many organizations do not have a list of contractual requirements for notification.
Also, the new SEC rules require timely disclosure of material breaches.
Incident Mitigation (RS.MI):
Activities are performed to prevent expansion of an event and mitigate its effects.
The Incident Mitigation category requires containment and eradication of the incident.
RS.MI-01: Incidents are contained.
RS.MI-02: Incidents are eradicated.
These are basic but critical steps of a response plan, though easier said than done if you have not prepared adequately for an incident. Advanced endpoint protection and strong segmentation controls can really help with these requirements. Some leading endpoint protection systems have isolation functionality.
That concludes our deep dive into the RESPOND function. We will take a deep dive into the RECOVER function next. In the meantime, if you are not sure or would like to discuss, please feel free to reach out to SEVN-X. Our goal is to help you Achieve Better Cybersecurity and we’re happy to help!
Previous Blog:
Cybersecurity Frameworks Series part 7, NIST Cybersecurity Framework 2.0: Detect
Next Blog:
Cybersecurity Frameworks Series part 9, NIST Cybersecurity Framework 2.0: Recover