Security Software – An Overview

Last Update: 25 August 2026

I’ve spent nearly my entire professional career in software security: designing software to prevent abuse by bad actors. I’ve been battling the bad guys for over two decades now, from hunting security bugs in Microsoft Office (I once won an Xbox for finding a vulnerability that allowed malicious clipart take over your computer) to designing security mitigations in Internet Explorer, Google Chrome, Edge, and Windows, to building tools to allow other good actors to find and kill security bugs.

In 2022, I left the world of software security for the world of security software, rejoining some old friends now on the Microsoft Defender team. The difference seems slight but it’s a big one– instead of trying to keep an otherwise-useful software product secure from attackers, now the entire point of my product is to protect users.

If not for adversaries, my product would have no reason to exist.

What Is “Protection”?

The goal of protection is to prevent bad actors from abusing technology to cause loss for protectees. While those losses can take many direct forms, most fall into several categories: 

• Loss of money (compromise of bank/credit accounts, ransoms paid to recover data) 

• Loss of productivity (loss of device/service availability, time to recover from incidents, etc.) 

• Loss of data (destruction of potentially irretrievable data) 

• Loss of reputation (bad PR, loss of customer/public trust, embarrassing secrets exposed) 

• Legal ramifications 

Beyond losses caused by bad actors, protection features must avoid other losses:  

• Loss of productivity due to protection in the absence of an attacker. False positives, application compatibility breakage, performance hits, and user confusion all lead to lower productivity.

• Loss of regulatory approval. For example, failure to demonstrate compliance with infosec standards could result in loss of permission to operate in a regulated industry.

• Loss of peace of mind. For example, failure to explain protection/posture results in user feeling unsafe/unconfident because they worry about attacks) 

Avoiding these other losses is absolutely critical– the cure must not be worse than the disease, both for society and for our business. I often joke: “You have a real hard time selling fire extinguishers if even one of them ever burns down a building.”

Framing: Protection Levers 

To provide protection, vendors of security software invest in several related areas: 

• Sensors – Allow watching events of interest to determine when an attack may be imminent or underway. Examples: AV File system monitor, Network Protection connection monitor. 

• Throttles – Allow control of the behavior of the system to prevent events when an attack is suspected or detected. Examples: Edge’s Anti-phish blocking, Defender’s File System filter, Defender’s Network Protection connection disruption.  

• Intelligence – Intelligence guides how to react to sensed data in order to block attacks with throttles, without interfering with the normal operation of the system. Intelligence includes both Threat Intelligence (indicators of compromise and indicators of attack (IoC/IoA) as well as Compatibility Intelligence (“Known good” software and services that are legitimate and should not be blocked.) Examples: SmartScreen Web Defense Service, Application Reputation Service, AV Signatures & Behavior Monitoring. In some cases, customers might provide their own intelligence via 3P TI or via direct knowledge of their own usage of IT. 

Beyond these core protection levers, three other levers are important for the overall protection story: 

• Remediations – The ability to act upon specialized intelligence to recover from an attack. For instance, after a ransomware incident is disrupted, what can we do to help the user? e.g. password change workflows, file recovery from OneDrive or Volume Shadow Copy, etc. 
• Telemetry – In situations where the protection environment encompasses multiple (often many) devices, the ability to understand the security state of the entire set of devices can be a critical capability.

• UX / Visibility – The ability of the user or a regulator to understand protection state and feel confident if the protection state is “good”, or to recognize the need for reconfiguration if it is not.

These levers work together to build higher level protection concepts: 

• Sensor + Intelligence = Detector 

• Sensor + Throttle + Intelligence = Blocker 

• Intelligence + Remediations = Recovery 
• Sensor + Telemetry = Security Operations

Improvements in each of these areas can increase the level of protection, and we can unlock new protections with either the introduction of new capabilities in each area, or a new combinations of levers. 

Other Uses for Sensors and Throttles

Sensors and Throttles are powerful primitives that have uses beyond traditional protection scenarios.

For example, an enterprise may combat insider threats and enforce regulatory compliance by using sensors and throttles to build Information Rights Management products like Microsoft Purview.

Sensors and Throttles are also often used to achieve non-protection goals, sometimes called Control scenarios. For example, combining the Web Defense Sensors and Throttles with a list of site categories enables Web Content Filtering to enforce an organization’s Acceptable Use Policy (“No gambling websites may be loaded at work“).

---

My Journey to Security Software

The last two years has been a whirlwind of learning: security software is a huge and very profitable industry, and as such there’s an entire universe of complexity and a new encyclopedia of acronyms and terms of art to learn. Even “Microsoft Defender” is a bit of a misnomer– it’s not one product, but an entire line of products designed to protect both enterprises and consumers from attack.

At a very high level, my product, Microsoft Defender for Endpoint, breaks down into two major components: Endpoint Protection (EPP) and Endpoint Detection and Response (EDR). These days, most of my work accrues to MDE’s EPP.

EPP

The primary goal of Endpoint Protection is to protect the user against threats on their individual endpoint device. Many EPP features focus on preventing initial access: i.e. attacks that allow an attacker to get malicious code running on the device in the first place. EPP features also aim to protect the security software itself from tampering: if an attacker with a low-level of access to a device can tamper with or disable the security software (EPP, EDR, etc), the malware then can elevate its privilege, move laterally throughout the organization, etc.

Modern endpoint protection software does not rely solely on static signatures¹ (file hashes or byte sequences), going beyond to emulate unknown code and watch for suspicious behavior of processes as they execute.

Every Windows user gets many of the most important EPP features for free, including MSAV (Microsoft Antivirus) which protects against viruses and malware, and SmartScreen, which protects against web-borne threats (phishing, malware, and techscams). Beyond these two core protections, there are many niche features (e.g. Exploit Protection) and adjacent features (e.g. the Windows Firewall is branded with “Defender” although it’s built by Windows). These security features are mostly exposed through the Windows Security app.

If a user decides to install 3rd Party security software (e.g. McAfee), it may take over some of the duties of some Defender components (usually replacing MSAV and sometimes the Windows Firewall).

Enterprises that deploy MDE EPP have some additional features that require configuration by an organization’s security team, including Device Control, Attack Surface Reduction rules, AppControl for Business, and Network Protection.

EPP Protection Components

Considering all that Endpoint Protection tries to achieve, the set of underlying “primitives” used to provide that protection is relatively small. Core protection components commonly include:

• Filesystem Minifilter – Senses/Throttles activity in the filesystem, including creation, opening, reading, writing, closing, and deletion of files. Most threats entail either writing malicious content to disk or modifying/reading sensitive content from disk. EPP software uses filesystem filtering extensively for monitoring (Sensor) and optionally blocking (Throttle) such filesystem activity. Observations are fed into behavior monitoring code and are used to kick off antivirus scans (e.g. when a new file is created during a download from a browser).
  
  Among many other things, Defender uses the Filesystem Minifilter to implement Real-time Protection scanning, Controlled Folder access, and various ASR rules.
• Network Filter – Senses/Throttles activity on network interfaces, including the establishment of inbound/outbound connections and read/writes from the network. Because most initial access occurs via the network, and virtually all cases of lateral movement involve the network, this sensor/throttle is critical for defense. On Windows, most network filtering occurs via Windows Filtering Platform callouts which provide coverage of all network traffic from all processes. Unfortunately for defenders, in the modern era, almost all network traffic is encrypted, leading to serious limitations in the protection provided by network filtering. In many cases, observed data is limited to {LocalProcess, Remote Address, Remote Port#, traffic volume}, precluding observation of things like URL, domain name, outbound data, inbound data.
  
  Among many other things, Defender uses Network Filters to implement Network Protection (and the features that build atop it, like Web Category Filtering). The Windows Firewall is not implemented by Defender, but operates at the same architectural level as Defender’s Network Filters.
• Process Monitor – Senses/Throttles the creation and destruction of processes and threads within a system, as well as sensitive operations between processes. If the EPP code detects an unwanted, suspicious, or malicious process creation (e.g. a signature suggests that the starting process’ command-line is a ClickFix attack) it can block the process creation. On Windows, this monitor is set by supplying PsSetCreateProcessNotifyRoutineEx2 with a callback into the EPP code.
  
  Filtering isn’t limited to creation of processes, and can include other sensitive operations, including use of interprocess interaction mechanisms (Named Pipes, Mailslots, shared memory, etc). For example, if a process gets a handle to another process and begins writing into the victim’s memory space, the Process Monitor can either prevent that write operation or schedule the modified memory to be scanned to match against signatures of malicious content (e.g. shellcode). If a process is determined to be malicious, the EPP software can kill it.
  
  Among many other things, Defender uses Process Filtering to implement AppControl, ASR rules, and File/Certificate IOC blocking.
• Miscellaneous Object Monitors – Senses/Throttles the use of other sensitive APIs. For example, on Windows, the system registry contains configuration data that is often abused by malicious code to establish persistence or attempt to tamper with configuration and elevate privilege. If malicious updates are detected, EPP software can prevent them and terminate the calling process.
  
  Among many other things, Defender uses Miscellaneous Monitors to implement Device Control, Tamper Protection, and to feed the BM engine in order to detect attempts to persist malware.
• Scan Engine – Implements the Threat Intelligence by scanning a given entity (e.g. a file or chunk/byte[] of data) collected by a sensor to determine whether it matches any of the signatures of known-malicious content. The scan engine can be invoked by many different scenarios, including events raised by the Filesystem Minifilter or Process Monitor.
• Behavior Monitoring (BM) Engine – Implements the Threat Intelligence by watching the series of signals from all of the sensors to determine whether a suspicious or malicious set of activities appears to be occurring.
• Participatory APIs – Enable client applications to expose their own sensors/throttles to security software.
  
  Generally, Microsoft Defender replies upon kernel callbacks rather than injecting “thunks” or detours into un-instrumented API calls or application code. Code injection is a powerful technique because it enables more targeted interceptions and enables more context about the flow of behavior. However, injection tends to be frail and can cause applications to break in unexpected ways, especially as applications are updated and their behavior or in-memory data structures change shape. Because injected security code executes as a part of an (unwitting) user-mode process, it can also be subject to attack by malicious content running in user-mode.
  
  The alternative is to expose Participatory Security APIs like AMSI and Edge SmartScreen, whereby “enlightened” applications directly call into EPP software to ask “Hey, does this look okay to you?” Beyond improving robustness and performance, performing direct calls into EPP APIs means that the client can supply explicit contextual information (e.g. “Where did this script content come from?“) and share potentially-malicious data that is decompressed/deobfuscated/decrypted (e.g. Edge calls SmartScreen with full HTTPS URLs, and the Windows Script Hosts supply AMSI with plaintext script content at the last moment before execution).

Aside: The risk of kernel sensors and throttles

The use of kernel mode sensors and throttles in security software is a topic of significant interest since the “2024 CrowdStrike Incident” in which a faulty signature (for Named Pipe observation) in CrowdStrike’s software caused their kernel sensor to crash. When kernel code crashes, the entire system crashes (bluescreen). Such a bug can have devastating impact, because if a system crashes in buggy kernel code immediately at boot, recovery can be very time-consuming.

Microsoft’s Windows Resiliency Initiative aims to provide a set of Windows built-in sensors and throttles that will allow most/all of an EPP product’s code to run outside of kernel mode, lowering the risk of a catastrophic system crash. This new platform is called the Windows Endpoint Security Platform (WESP) and is being developed in partnership with most major EPP vendors.

EDR

EDR software aims to address the fact that Endpoint Protection inherently can never be infallible — at some point, through user error, delayed threat intelligence, a novel attack, or other shortcoming, some devices will fall victim to an attacker.

EDR software only makes sense in the context of an enterprise where there’s a security operations center (SOC) tasked with keeping the company’s fleet of devices secure from attackers. EDR is a huge market, and big players include CrowdStrike, TrendMicro, Sentinel One, and others.

EDR software sends a firehose of telemetry to the SOC to allow creation of security alerts for investigation and remediation. For example, if malicious behavior is observed on a cluster of devices, the SOC can isolate those devices from the rest of the enterprise, can use the “Live Response” tool to run investigation packages on the suspicious devices, and can lock down the devices and any credential information used on them to protect the attack from spreading to the rest of the enterprise.

The SOC is also responsible for managing the security posture of the fleet, ensuring that security policies are configured, patches are installed on every endpoint, that risky apps are not present in the environment, etc.

EDR Protection Components

EDR software can often use sensors from the client’s EPP software to piece together what is happening on a device. Beyond that, on Windows, EDR’s observations largely come from a Sensor stream called Secure ETW, which asynchronously reports events of interest to security software directly from the Windows code itself. Some EDR software will use “thunks” or “detours” to inject monitoring sensors inside un-instrumented API calls or application code in order to provide more context about an application’s behavior.

Unlike EPP, which typically acts nearly synchronously to block threats in “real-time”, EDR commonly asynchronously sends its observations to the cloud/SOC. AI/ML models and human analysts can observe these signals and then send commands to the client to blunt attacks, remediate threats, isolate the client, collect forensics, etc. EDR cloud code can also send signals to other services and devices to observe and disrupt the spread of attacks (“lateral movement”) across the organization (by locking accounts, “tainting” devices, etc).

In most cases, EDR software is heavily reliant upon the network, sending events to the cloud via a telemetry pipeline (where cloud correlation and intelligence are used to detect and respond to threats), and receiving instructions via a command and control channel to direct the behavior of client components to respond to threats. This communication requires strong identity: both the client and the server must trust that the counterparty is legitimate to avoid spoofing attacks (e.g. spamming the SOC with fake events from a device) and prevent malicious code execution (e.g. a spoofed server sending malicious commands to the client). Communication channels also require confidentiality (to avoid leaking sensitive information about what’s happening on a device to a network observer). In most cases, HTTPS/TLS is used, sometimes requiring Certificate Pinning to further raise confidence in the security of the channel.

Other Defender Products

Many other products live under the Defender banner, including MDO (Microsoft Defender for Office), MDCA (Microsoft Defender for Cloud Apps), MDIoT (Defender for IoT), etc.

Some of these products reuse threat intelligence, sensors, and throttles from other products (e.g. MDO scans email attachments with MDAV on the server; MDCA uses Network Protection to enforce web application blocks). Some Defender products include sensors, throttles, and TI that are exclusive to each product. Part of our team’s journey has been finding opportunities to bring these product’s components closer together to reduce duplication and improve threat protection.

Going Deeper

If you’re looking to learn more about Defender EPP and EDR specifically, we have tons of documentation about Defender on learn.microsoft.com.

• If the goal is to get a holistic view of Defender, one of MDE’s PM’s (Paul Snow) just wrote the second edition of his book on MDE.
• The “Internals” of the Defender Protection engine are not widely documented by the team and are generally considered an implementation detail; they change routinely to address new threats and improve protection. There are a variety of books that discuss how modern AV and EDR work at a low-level: two I enjoyed are Evading EDR and Antivirus Bypass Techniques.

Stay safe out there!

-Eric

¹ The noun “signatures” and verb “sign” are a term of art that has two definitions. Usually, when I use these terms on this blog, I mean “Use a code-signing certificate to apply a digital signature to a file.” To antivirus software folks, you “sign” a (typically malicious) file by creating a “signature” that an antivirus engine will use to recognize that file (or its variants) when the file is scanned by the AV.