Research: Cyber Resilience Readiness

Summary

Most organizations can produce a resilience plan. Fewer can show that the plan works when the systems it depends on are the systems under attack. That gap is readiness, and it is the subject of this report.

• Readiness belongs to a scenario, not to an organization. Ask whether a specific service survives a specific disruption, and answer with evidence.

• Recovery has become a target. Reporting on Mandiant’s latest findings describes ransomware operators going after backup infrastructure, identity services and virtualization management layers to deny recovery [2].

• Timelines are compressed and access is often older than the incident. The median gap between initial access and hand-off to a secondary threat group is 22 seconds, and prior compromise is the most common initial vector in ransomware operations at 30% [1]. Assume the attacker may already hold privileged access when disruption becomes visible.

• Recovery order follows dependencies, and identity usually comes first. Plans that restore through the same identity and management plane the attacker controls are exposed. This is the author’s analysis.

• Grade evidence, not plans. Treat each readiness claim as demonstrated, documented or assumed. Most claims in most programs are the last two.

Scope and method

This is an analytical report, not a survey. No primary dataset of organizational readiness was used, so it publishes no benchmark scores or percentages of organizations that are ready. Readiness is also distinct from maturity: maturity describes how developed a resilience program is, while readiness asks whether a particular service can survive a particular disruption now.

The analysis draws on four published sources:

• NIST SP 800-160 Vol. 2 Rev. 1, which describes how to design systems that can anticipate, withstand, recover from and adapt to cyber-related attacks and compromises [3].

• The Recover and Govern functions of the NIST Cybersecurity Framework 2.0, including recovery plan execution, recovery communication, and roles, responsibilities and authorities [4].

• Mandiant’s latest M-Trends findings on initial access, hand-off speed and ransomware, and secondary reporting of its findings on recovery denial [1][2].

• The EU Digital Operational Resilience Act, used as one example of a regulation that makes resilience testing an obligation [5].

Figures are cited. Interpretations and recommendations are the author’s judgment and are marked.

Four lenses for readiness

NIST SP 800-160 Vol. 2 Rev. 1 frames cyber resiliency as the ability to anticipate, withstand, recover from and adapt to attacks [3]. Those four goals translate into four readiness questions.

Interpretation: in the author’s assessment, most programs invest in withstand, document recover and rarely verify it. Verification is where readiness is won or lost.

Findings

Finding 1. Recovery is now part of the attack

Reporting on M-Trends describes operators targeting backup infrastructure, identity services and virtualization management layers, with the aim of removing the ability to restore and raising pressure to pay [2]. The same coverage describes attackers cloning powered-off virtual machines, including identity providers and domain controllers, in one reported intrusion. Because the clones were powered off, the activity did not trigger alerts on the systems themselves [2].

The recommendations in that coverage are specific: isolate backup environments from the corporate Active Directory domain, use immutable storage, and treat virtualization and management platforms as Tier-0 assets [2].

Speed compounds the problem. The median gap between initial access and hand-off to a secondary group is 22 seconds, and prior compromise is the most common initial vector in ransomware operations at 30%, up from 15% [1]. Implication: by the time disruption is visible, the attacker may have held access for some time. A recovery plan has to work on the assumption that credentials and management tools may be compromised.

Finding 2. Recovery order is set by dependencies, and identity comes first

To restore anything, administrators must authenticate, reach management consoles, resolve names and decrypt backups. The tools used for recovery have their own dependencies, and those are the ones plans most often leave out.

This table is the author’s analysis. Its use is practical: write down the real restoration sequence for one critical service, including the tools used to restore it, and see what the sequence depends on.

Finding 3. Tolerance has to be set per service, not per system

Recovery objectives set system by system rarely add up to anything anyone has tested. A service made of several systems has one realistic recovery time: the time along its longest dependency path. In the author’s view, readiness should be stated as the maximum disruption the business has agreed to tolerate for each critical service, with the dependency map behind it.

Finding 4. Decisions are part of readiness

The first hours of a serious incident are mostly decisions. Whether to isolate or keep trading, whether to take identity offline, who speaks to regulators and customers, and which third parties to call. The NIST Cybersecurity Framework treats these as governance matters: roles, responsibilities and authorities, and coordination of recovery communication with internal and external parties [4].

Implication: readiness evidence here is a rehearsal, not a document. Named decision-makers with named deputies, a communication channel that works if corporate email and chat do not, and agreed thresholds for the hardest calls.

Finding 5. The regulatory direction is toward tested resilience

The EU’s Digital Operational Resilience Act covers ICT risk management, incident reporting, third-party ICT risk and digital operational resilience testing for financial entities. Its testing provisions include basic and advanced testing, with threat-led penetration testing among its measures [5]. It applies to specific entity types, so organizations should check scope before relying on it. As a reference point, it shows testing moving from good practice to obligation in regulated sectors.

A readiness scorecard

Grade each area against three levels of evidence. Demonstrated means observed in a test or real event. Documented means written down but not tested. Assumed means believed, with nothing to show. Only the first counts as readiness.

What to change first

1. Choose three scenarios and grade each against the scorecard. Loss of the identity plane, a destructive event across a virtualized estate, and loss of a critical third-party provider are sensible starting points.

2. Map the dependency order for the most important service, including the tools used to recover it.

3. Separate backup and virtualization management from the corporate directory. This adds operational friction and break-glass procedures, which is the price of having a recovery path the attacker cannot reach.

4. Restore one service end to end, time it and record every undocumented dependency found along the way. Start with a tabletop exercise if a technical test is not yet safe to run.

5. Rehearse the decisions with executives and fix the out-of-band communication path.

Limitations

• No primary dataset was used. The report does not state how many organizations are ready, and it contains no benchmark scores.

• M-Trends reflects investigations by one firm and may not represent the wider population. Specifics on recovery denial come from secondary reporting of the findings and should be checked against the primary report before being relied on.

• The scorecard, the three evidence levels and the dependency table are analytical constructs, not validated instruments.

• The regulatory discussion uses one regulation as an example. Applicability depends on entity type and jurisdiction.

• The scenarios named are illustrative and not an exhaustive list of disruptions.

A useful first step is to take the most important service and ask one person to write down, without consulting a plan, the order in which it would be restored and what each step depends on. The gaps in that answer are a fair first measure of readiness.

Related Reading

RESEARCH / REPORT Cyber Resilience Maturity Model

Program-level maturity, which this report separates from scenario-level readiness.

EXECUTIVE BRIEFING Cyber Resilience: What Happens When Preventive Controls Fail?

The leadership view of the same question: what the organization relies on once prevention has failed.

PRACTITIONER FIELD NOTE Playbook: Running a Cyber Resilience Exercise

How to produce the demonstrated evidence the scorecard asks for.

Sources

[1] Google Cloud and Mandiant. M-Trends report, latest edition. cloud.google.com/security/resources/m-trends

[2] Industrial Cyber. Report coverage of M-Trends findings on recovery denial, backup targeting and virtualization targeting. industrialcyber.co

[3] National Institute of Standards and Technology. Developing Cyber-Resilient Systems: A Systems Security Engineering Approach, SP 800-160 Vol. 2 Rev. 1. csrc.nist.gov/pubs/sp/800/160/v2/r1/final

[4] National Institute of Standards and Technology. The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29. doi.org/10.6028/NIST.CSWP.29

[5] European Insurance and Occupational Pensions Authority. Digital Operational Resilience Act (DORA). eiopa.europa.eu/digital-operational-resilience-act-dora_en