Ransomware Frontline Report
4. Defensive Design: Turning a Patchwork of Products Into Recoverable Defense
Defense is evaluated not by a “list of products already deployed,” but by a design that asks where the conditions for an attack to succeed are reduced, where anomalies are found, where a failure is stopped even so, and what is restored and how. This chapter organizes the material around five boundaries so that priorities can be set regardless of organizational size. Here we address why each boundary is necessary. What to confirm in order to say something has been implemented (verification methods, evidence of completion, specific checklist items) is addressed in Chapter 12.
4.1 First Boundary: Assets and the Externally Exposed Surface
An asset that is not known cannot be protected. First, inventory the hosts, domains, VPNs, remote access, web administration consoles, cloud tenants, SaaS administrators, and outsourcing-partner connections reachable from the internet. IPA likewise identifies grasping internet-facing points of contact, vulnerability countermeasures, configuration checks, log monitoring, and BCP as important measures. [S06]
Items Required in the Minimum Ledger
| Item | Reason |
|---|---|
| Asset name, owner, business criticality | Speeds up decisions on contact, shutdown, and recovery. |
| Reachability route, reason for exposure, expiration | Checks whether an exception has become permanent. |
| OS, product, and update owner | Moves vulnerability response out of a “someone will handle it” state. |
| Administration method and privileged identity | Identifies single points of failure in the management plane. |
| Log location and retention period | Secures the ability to investigate after a compromise. |
| Backup and recovery order | Reduces business impact during a stoppage. |
Asset discovery does not end with a single inventory. The attack surface changes with automatic cloud provisioning, SaaS adoption, M&A, changes in outsourcing partners, and emergency exposure settings. Connect this to change management, and operate so that unowned or unclassified assets that remain can be escalated.
4.2 Second Boundary: Making Identity the Top-Priority Defensive Surface
In many environments, identity is the key to email, files, SaaS, cloud, VPN, and administration consoles. Compromise of an identity can have a broader impact than infection of a single endpoint. Organize it in the following order of priority.
- Classify all identities into human, service, emergency-use, shared, and outsourcing-partner categories.
- Separate privileged identities from identities used for everyday work.
- Apply MFA broadly, prioritizing phishing-resistant methods for privileged and external access.
- Tie conditional access to device health, location, risk, and application criticality.
- Consider granting privilege not permanently, but through elevation that is on-demand, approval-gated, and time-limited.
- Reflect resignations, transfers, contract terminations, and exception requests immediately.
- Make authentication, privilege changes, MFA registration, and app consent monitorable.
The idea that “identity measures are complete because MFA has been deployed” is dangerous. If legacy protocols, service accounts, emergency accounts, tokens, sessions, or support-related exceptions remain, the actual boundary stays weak.
4.3 Third Boundary: Operating Endpoints and Servers on the Assumption of Compromise
For the baseline configuration of endpoints and servers, consider least privilege, rapid patching, restraint on administrator privileges, application control, detection and response such as EDR, disk encryption, and log preservation. What matters more than “what to install” is how exceptions are managed.
- Who needs local administrator privilege, and for what business function?
- On which endpoints are maintenance software, remote operation, script execution, and macros permitted?
- Who isolates an endpoint whose EDR or log collection has stopped, until it is restored?
- For legacy OSes and legacy applications, which of decommissioning, isolation, virtual desktops, or access restriction is used to reduce risk?
Where a technically outdated asset cannot be eliminated immediately, the exception must not be hidden. Record the owner, deadline, reachable scope, compensating measures, residual risk, and decommissioning plan, in a form that management can accept.
4.4 Fourth Boundary: Separating the Network From Administrative Pathways
The purpose of network segmentation is to make lateral movement harder for attackers, localize anomalies, and make critical management planes and recovery assets harder to reach. Beyond simply adding VLANs, verify what traffic is actually permitted, which identities can administer it, and how many exceptions exist.
Perspectives for Defensive-Design Review
| Perspective | Question to check |
|---|---|
| From user to server | Whether administrative protocols or shares not needed for business are permitted. |
| Administrative endpoint | Whether general-use endpoints or email can reach the same management plane. |
| Backup | Whether there is a single unified route by which production can delete or alter it. |
| Cloud | Whether the tenant administrator’s endpoint, authentication, and logs are adequately protected. |
| Outsourcing partner | Whether the connection source, time, target, operation logs, and termination procedure are clear. |
4.5 Fifth Boundary: Data and Backup
Data classification is not only for compliance documentation. Knowing which information, if leaked, would trigger customer notification, regulatory response, business stoppage, or contract breach determines the priorities for monitoring, encryption, access control, and backup.
If critical data is left “somewhere in a shared folder” and readable by anyone, the impact of data exfiltration grows. Handle least privilege, periodic access review, expiration of external sharing, data retention periods, and backup isolation as a set.
Figure 6: Defense in Depth — So That a Single Failure Does Not Mean Total Loss
Rather than placing assets/exposed surface, identity/authentication, endpoints/servers, network/management plane, and data/backup separately, cut across them with monitoring, exercises, and improvement. Even if some point in one layer is breached, arrange for the next layer to enable discovery, blocking, limitation of impact, and recovery.
This arrangement does not mean a series of sequential gates. It represents a design in which gaps in countermeasures are not concentrated in any one place.
(Full figure translation deferred — see note at top of this file.)
4.6 Moving Vulnerability Management Beyond “Patch Work”
For vulnerabilities that could become an entry point for ransomware, prioritize not just by CVSS severity, but by external exposure, observed exploitation, asset criticality, compensating measures, and the impact of a failed update. Even where an update cannot be applied, combine measures such as taking the asset offline, restricting access, mitigations such as a WAF, stronger monitoring, isolation, and planned replacement.
The managerial failure lies less in being unpatched itself than in the fact that “no one can see the reason it is unpatched or the residual risk.” Make overdue items visible as exceptions, with an accepting owner and a deadline.
4.7 A Realistic 90-Day Priority Order for Small Organizations
Organizations with limited budget and staff should not implement everything at once. First, raise effectiveness in the following order.
| Period | Priority action | Evidence of completion |
|---|---|---|
| 0–30 days | Inventory externally exposed assets, privileged identities, critical operations, and backups | Owner, contact, exceptions, and recovery destination are recorded. |
| 31–60 days | MFA and separation for privileged identities, remediation of critical exposed vulnerabilities, log preservation | Tested against actual identities, devices, and logs. |
| 61–90 days | Restoration exercise for critical operations, incident contact network, review of outsourcing-partner connections | There is an exercise record, identified issues, improvement deadlines, and an owner. |
This order does not replace an organization’s own specific risks. In healthcare, manufacturing, government, and finance, for example, the operations that cannot be stopped and regulatory priorities differ. What is common is not to aim from the outset at “completing a perfect Zero Trust implementation,” but to address the most dangerous trust relationships and the hardest-to-restore operations first.