Ransomware Resilience Validation
Whether ransomware could halt your operations and block recovery
Starting from ransomware halting operations and blocking recovery, we validate the paths and conditions that lead to that harm and show where to cut them.
We follow the paths in from outside, the conditions for spreading inside and gaining privileges, and the conditions under which backup and recovery are disabled together, and see where it could be noticed and where it could be cut. For each path, the result sets out the conditions that held, how far a disruption would reach, and where to cut it first.
If ransomware got in, is there a path in our environment that would halt operations and block recovery?
We validate the paths and conditions from the way in through spreading to disabled backups, and show where to cut them and what to address first.
Reviewed
When it fits
- Downtime would cost you dearly
Manufacturing, logistics, healthcare, retail: organisations where production, deliveries, care or sales stop when the systems stop.
- Backup and recovery are new or have changed
You want to know that new backups and recovery procedures would not be disabled along with production in a ransomware attack.
- Others in your sector have been hit
You have heard of ransomware hitting organisations like yours, and want to know whether the same paths and conditions exist in your environment.
- You need to explain how prepared you are
You want to explain your ransomware readiness in terms of paths and conditions rather than general worry, and set priorities for investment and fixes.
What we look at
We divide the way to the harm into four stages, from getting in to operations stopping, and look at the conditions that hold at each.
- ENTRYThe way in
- Paths into the environment from outside
- Remote access points open to the outside, such as VPNs
- SPREADSpread and privileges
- Conditions for spreading inside and gaining privileges
- How well admin accounts and identity systems are protected
- Separation of network zones and limits on moving between them
- BACKUPBackup and recovery
- Conditions under which backup and recovery are disabled together
- Separation of rights between backups and production
- Whether backup copies are kept apart
- IMPACTDetection and impact
- Where an intrusion or its spread could be noticed
- How far a disruption would reach across the business
- Dependencies between business systems
‘Backups cannot be deleted with the same admin rights as production’
‘No single user PC leads straight to the core business servers’
‘Losing one admin account does not lock every server at once’
How it runs
Decide what must not stop
We identify the operations and systems that would cost most if they stopped and the data that must be recoverable, and set the conditions that must hold.
Agree scope and safety
We agree the scope and target systems, what is permitted and prohibited, and who takes part and how we keep in touch.
Validate paths and conditions
Stage by stage, from the way in through spreading to backup and recovery being disabled, we check whether each condition holds and where it could be noticed.
Show where to cut
For each path: the conditions that held, the impact on operations, where to cut it first and how to improve.
So that operations are not affected, the method and the criteria for stopping are agreed before we start.
What you receive
Results by path
For each path: the stage at which it was stopped, or how far it carried on, with the conditions that make it so.
How far a disruption would reach
If the conditions held, which operations would stop and what would be hard to recover.
Where to cut, and in what order
Where the paths can be cut, and what to address first.
Evidence and what was not covered
Proof that lets what we found be reproduced, and the parts this round did not examine.
The results show the state of the agreed scope at the time of testing. A re-test after fixes is agreed separately.