"ASSUME BREACH"
Applying the Zero Trust Principle
To Nullify Ransomware
There are several locations where breaches can and are likely to have occurred despite best intentions and defenses. Yes it matters how breaches occur but what’s most important is that they are detected and removed before they enable ransomware attacks that cause business disruption and organizational issues such as disabling systems, data exfiltration or corruption.
These pages cover detection in/across a wide area network, a user system or closed network, or within hybrid clouds. This order is deliberate because increasingly systems involve the use of cloud-based applications accessed from an organization’s locations that traverse a service provider wide area network.
It’s no small thing to bring a structured process to replace the stress of the verifying which of possibly thousands of defenses is the one being breached.
This page was previewed in the Spring 2025 edition of ISE magazine under the title “Assume Breach – Now What?“
Note on this update.
This expansion covers further details of standardized test functions and methodologies. Later it will extend the network detection to end user system and cloud systems detection as appropriate, together with further standards-based functionality planned for publication, mid-2025. Update: This is even more relevant given the April 27 new FBI report showing 256,000 attacks cost ransomware victims $16.6bn!

Why a Guideline on "Assume Breach?"
Ransomware is still running rampant, threatening everyone who reads this. Today, Zero Trust is the accepted strategy for protecting organizations and individuals from cybersecurity threats. Defenses are built around two principles: “Never Trust, Always Verify” and “Assume Breach.”
The first focuses onprevention: identifying and authorizing access to data, applications, and networks and now has thousands of products based on the NSTAC1 five-point implementation plan.
On the other hand, “Assume Breach” implies that you should assume that your defenses have already been breached, and the enemy is working inside your ecosystem. I realized, surprisingly, that there was very little done to deal with these breaches when they have happened, when it was likely too late! From my twenty-five years of working on service provider standards and Cloud ecosystems it struck me that there was a game-changing opportunity for service providers to curtail ransomware for their customers—a massive business advantage. It happens because all organizations use the provider’s network and that ransomware attacks traverse that network. That’s what this page is about.
What, How and Who
This page, like so many others, is informative, providing guidance on what can be done to reduce the risk of attack. It does not tell you how to implement the concepts since such implementation is organization-dependent and must fit in with existing systems, expertise and budget. Our Virtual CSO Service exists to address implementation. Being independent, this page also does not make recommendations on who to use or even list possible software solutions for (say) Network Detection and Response software, etc.
The Nature of Ransomware
- Attacks and breaches can occur anywhere across the Information Ecosystems: in subscriber systems, in multiple clouds and remote user systems.
- Increasingly, hybrid cloud environments means that transactions span this ecosystem where the protect surface and attack surface are distributed.
- With 80+ threat types focused on penetration of defenses and the reliance on the correct execution of 40+ defensive actions it is inevitable that mitigating actions are missed and that breaches occur.
- Ransomware continues to evolve and become more sophisticated making a fix-and-forget strategy untenable
The nature of a Ransomware attack is primarily with the use of “Ransomware as a Service” – effectively a for-purchase platform to deliver such attacks with limited technical knowledge required. This platform – termed an Advanced Persistent Threat (APT) – attack is Ransomware’s killer app.
As opposed to malware, which typically acts immediately, an APT is a sophisticated, often complex and sustained cyberattack that is today’s principal vehicle for ransomware. An APT attack consists of techniques for initial penetration to create a breach, infiltration and discovery of vulnerabilities and corrupting or exfiltrating information as described in detail below. It’s the APT that enables the Ransomware attack’s potency.
How Ransomware Works Using an APT.
While there are never guarantees in cybersecurity, it’s those signature techniques which, if curtailed, can prevent ransomware or severely reduce its success.
Access and Infiltration
- Using some of the 40+ methods (including many phishing types, identity theft, social engineering, AI-based scams, bypassing of multifactor authentication, etc.) it then penetrates the Subscriber, Cloud, infrastructure or OT-based system. As indicated this first step is only successful if end systems or human error cause them to fail. Endpoint Detection and Response (EDR) software is the first of several defenses that are designed to disempower APTs before they begin. These marketing solutions have limitations.
- The intruder continues with Reconnaissance probing for vulnerabilities, targets to exploit and financial opportunities if present.
- Dependent upon which, Threat Actors will deploy the next stage – Resource Development of vulnerabilities, targets to exploit and financial opportunities if present.

- Having penetrated a system, the Threat Actor establishes an undetected presence that compromises the system and establishes a hard-to-detect foothold by hiding Malware inside legitimate systems, applications and data files.
- They can also leverage file-less infiltration by corrupting native tools such as PowerShell or Windows Management Instrumentation, etc. These are known as “Living-off-the-Land” and such exploits are typically hide in end-user systems until activated and are therefore not detectable by end-user security software. In 2025, this technique is being bypassed by malware imbedded in seemingly innocent applications.
- Note: MITRE|ATT&CK lists 14 attack categories that are relevant.
Indicators of Attack in the Network
Having created a breach the following steps happen that have the potential to be detected:
- The act of Discovery (MITRE TA0007)[1] is the technique used by threat Actors to explore systems for vulnerabilities. There are 25 techniques listed by which an adversary may explore a system. Where that spans the SASE service, these can be detected by applying the Zero Trust methodologies below.
- It may prepare for an attack by elevating its privilege level and seeking targets in the systems’ network. Then it may lie dormant, Beaconing its remote host and lying undetected in systems for a long time. This is the first sign detectable in a Zero Trust enabled network.
- When activated, it will invoke one of more Lateral Movement attacks to infiltrate connected systems, operating out of infiltrated applications. This is also detectable in a SASE Service of Zero Trust enabled networks.
- To complete the attack, the next phase begins data exfiltration, damage or encryption to systems and applications etc. The result can be anything from disruption, identity or data theft, system and application software encryption, ransomware, etc. Attempts at bulk exfiltration are also detectable. Likewise, attempts at illicit encryption or corruption of software systems, device firmware and software.
While there are never guarantees in cybersecurity, it’s those signature techniques which, if curtailed, can prevent ransomware or severely reduce its success. Welcome to the journey.
Detecting Ransomware in the Network Using Zero Trust Strategies

Breach Transactions Traversing the Network Ecosystem
While there are never guarantees in cybersecurity, it’s these signature techniques which, if curtailed, can prevent ransomware or severely reduce its success. Here we show how the use of MEF Forum standardized services significantly impact business protection by detecting and disabling such attacks.
The good news is that an MEF standard service such as a SASE Service or Network as a Service implementing Zero Trust principles is ideally placed to detect the signs of breaches as they work inside the ecosystem and to nullify their impact.
This page provides implementation guidance on MEF 117 SASE Services together with MEF 118.1 Zero Trust Framework and MEF 138 Security Functions. These actions specifically address implementation actions after breaches have occurred. This is in alignment to the Zero Trust principle “Assume Breach” that has never been more relevant. I.e., the focus is principally on detecting the signs of such breaches by the application of strategies of the above MEF specifications. These are necessarily used in the successful attacks when a breach has been achieved and where preventative defenses have failed.
Threat Detection is critical to the vast majority of organizations.
As indicated, there are many aspects of the enterprise ecosystem that can be affected: Subscriber networks and systems, wide area network Services, OT networks and cloud infrastructures. While the methodologies provided here could be applied to all of these, the wide area network services provided by global service provider, MSP and MSSPs provide the integrated infrastructure for almost all end-user organizations, this page currently addresses:
- The SASE Service Framework and Attributes in MEF 117
- Services that deploy MEF Services such as SD-WAN
- Various emerging Network as a Service implementations
- IP Services that deploy MEF118.1’s Zero Trust Framework and Attributes
- The security functions called out in MEF 138 IP Security Functions
The increasing use of multiple and hybrid clouds implies growing importance of using wide area network and Internet access implies has significantly increased the attack surface. The relevance being that attacks and breaches span and are therefore detectable via connecting services such as a SASE service.

Detection of Threats by Applying Zero Trust Principles.
Deployment of Zero Trust intercepting Ransomware in a SASE service, a Network as a Service, SD-WAN or as the security oversight of an Infrastructure as a Service. Other detection and removal techniques shown are also explained.
Methodologies to Detect Potential Attacks

Extending the Security Functions of MEF 118.1 (the above is courtesy of the MEF updated with new information), MEF 138 and MEF 117
- The methodology described in MEF 118.1 is required to be applied in order to verify that transactions are legitimate and not infiltrated by a Threat Actor. The functions described are highlighted in the above diagram. The separation of Policy Management from many types of distributed Policy Enforcement Points is a key element of the strategy.
- Subject Actors in a Zero Trust enabled system are required to be identified via an Identity Manager, Authenticated via a form of Multi-factor Authentication, Passkey etc. “Applications” in the above means any system or application software.
- Authorization is required by the policies associated with that Subject Actor.
- Access is granted aligned with the Access Controls listed in MEF 118.1 section 12. These are Mandatory, Discretionary, Role-Based and Attribute-based Access controls describe by NIST and other sources. This is critical since even a subject actor with administrative privilege should be restricted how and when encryption, decryptions and movement of software and data assets can take place, the location of the subject actor and the software being used to perform such actions, etc.
- Attempts to execute transactions outside of rules of these access controls are blocked, quarantined, logged and reported.
- Similarly blocked and reported are breach of policies regarding unapproved locations, times, duration, amounts of data being transferred or accessing unauthorized target Actors, workloads, etc.
- Policies should also apply as appropriate to Zero Trust enforcement points particularly attempts to access segmented networks.
- Of particular importance are the limitations on the use of file sharing and file transfer applications as these are used in exfiltration of data and Lateral Movement attacks that transport malware.
This section will continue to be augmented with new developments in MEF SASE services anticipated for publication in the summer of 2025.
Threats Detected Using as an Indicator of Attack
The following threats enabled by a breach that are relevant and necessary for the Threat Actor to effect ransomware in a Network Ecosystem are detection and prevention of Beaconing (any attempt to access a remote host is easily detected), use of Discovery techniques, Living-off-the-Land transactions and Lateral Movement.
Additional Security Functions for SASE Services – addressed in MEF 117.1
Section 9.6.2.1 on Supported Application Identity and Access Management (SA-IdAM) determines whether a Subject Actor of a Session is Authenticated and more importantly, Authorized to access a particular supported Application thus is an important Indicator of attack. Similarly, Section 9.6.2.2 Data Integrity Security Function is the Security Function that examines whether certain supported Applications and determines if the actions included in those Sessions are allowed or blocked based upon the SASE Policy. Attacks based on Living-off-the-Land attacks are likely to be detected by this function.
There’s another issue for AI that’s emerging: the intrusive nature of AI models scraping the Internet (that means systems and servers over the Internet) to continually update their models. In what amounts to the level of denial of service that are seen in atacks, there are reports of systems having 97% of traffic being attributed to such transactions. Some service and cloud providers are taking evasive action which may end up limiting the effectiveness of AI implementations!
Additional Security Functions
Although not in scope for this version, this page along with MEF 138, SASE functions and other solutions calls out other security functions for the prevention of breaches that reduce the chance of a breach that uses the SASE Service to create ransomware:
All Security Functions listed in MEF 117 Should be implemented. Specifically, the Middlebox function will allow inspection of the contents of packets. Where Ransomware deploys recursive or other encryption systems, these can be detected and blocked.
Other SASE functions in MEF 117 include DNS, Domain Name, URL, IP, Port & Protocol Filtering, and Malware Detection and Removal. Further consideration is being given to Proxy, Cloud Access Security Broker and Remote Browser isolation. These are focused on defense and prevention rather than after a breach has occurred. These are also covered in detail in MEF 138 along with Data Loss Prevention and Protective DNS Security functions.
SASE functions also add security prior to transit of the SASE Service ecosystem, such as Universal ZTNA, including Lateral Movement detection, Secure Web Gateways, etc.
Other relevant Detection and Response solutions such as Network Defense and Response Systems (NDR) should be examined to see if they add protection and avoid breaches. This can be tricky as NDR is a marketing term and each package is different. Therefore, the individual functions of NDR systems or those that include NDR functionality should be examined to see if they provide added protection and to what extent they overlap with implementations of the above Zero Trust service attributes.
Where providers and espcially MSSPs are providing an outsourced service then addition software is available as follows: Endpoint Detection and Response (EDR) is deployed in Subscriber Networks and Extended Detection & Response Software (XDR) spans both EDR and NDR. For Cloud Ecosystems: Clould Detection and Response (CDR) focuses on those environments.
In summary, introducing each security function one-step-at a time reduces the risk of attack and the effect of each can be monitored/audited.
Dependencies and Actor Collaboration
Successful implementation depends on the reliable execution of several supporting elements. The Zero Trust principle of “Never Trust, Continually Verify.”
Subscriber implementation of Privileged Access and Account Management and Identity Management MUST be used to manage and limit the privilege of Users, Software and Devices. This limit is known as Least Privilege.
These are required to prevent or limit Threat Actors ability to impersonate processes. These SHOULD include the rules regarding what applications can be run and accessed, the amount of data that can be transferred to avoid exfiltration, to which location, when the User is authorized to access the Application and the location of the User or Application, etc.
It may fall upon the Subscriber to provide these functions directly or in collaboration with the Service Provider. In any case, it is imperative that the Service Provider verify and not trust that functions and supplied software can be depended upon. This collaboration is essential to strengthen any potential vulnerabilities or weak links.
The above also applies to any software or system used by the provider to implement the Services. This supply chain applies to any third part supply chain software such as SASE components, monitoring or auditing systems.
This process must be continually verified as part of any regression testing of updated systems.
Defensive Evasion
The implementation recommended in this paper is also subject to attack and disablement. Care should be taken to ensure that implementation of the system uses memory-safe languages and only be accessible using the same Zero Trust protective methodologies describe above. MITRE ATT&K (TA005) lists 25 techniques used for defensive evasion. The integrity of all deployed third party software and serivces is clearly important
Vigilance
Finally, continual awareness of development in attack techniques and defensive responses remains an essential part of every cybersecurity strategy and maintaining business resilience.
References
2. MEF 117 SASE Service Attributes and Service Framework (2022)
3. MEF 118.1 Zero Trust Framework (2024)
4. MEF 138 Security Functions for IP Services (2024)
5. NSTAC The President’s National Security Telecommunications Advisory Committee Zero Trust 5 Step Implementation Plan (2022)
6. Terminology. All terms are covered on our CyberPedia page
7. Supply Chain Risk Management. See our page on Delegation
Acknowledgement
This page draws upon the work of many over several years but in particular I would like to recognize the work of the three editors: Ralph Santitoro (Ciena) for MEF 118, Neil Danilowicz (MEF) for MEF 117 and Bill Bjorkman (MEF Retired) for MEF 138. I was proud to be a part of those efforts.