Behavior Monitoring (BM) has been a vital part of finding new malware through our telemetry and sample collection processes since 2010. It’s also a protection feature, which I’ll discuss below. Our recent antimalware platform update has introduced network real-time inspection (NRI) to BM, giving much-needed network behavior coverage. NRI uses the same components as another feature in the platform, Network Inspection System (NIS), but does so in a significantly different way.
NRI works as another BM sensor, working in concert with file, process, registry, boot record, and other events to detect suspicious activity. BM triggers both telemetry and sample submissions on suspicious files for us to to analyze. This threat intelligence results in a better protected ecosystem for our users. While BM itself does not actively block, its telemetry can trigger real-time signatures from the Microsoft Antimalware Protection Service (MAPS) backend, delivered to the client, resulting in a removal of the threat. NRI has a low impact on system resources: instead of holding the connection and blocking, NRI makes a copy of the packet as it crosses the network and performs an asynchronous inspection. We’ve put this feature through rigorous scrutiny in our own labs, looking at network throughput and latency as well as CPU and memory utilization. This feature has already shipped in Microsoft Security Essentials in the October 2012 update, and is running on over 100 million machines. The results show that network inspection technology is suitable for a very wide range of machines, running a broad array of applications and services, without adversely affecting their performance.
NIS is our zero-day vulnerability shielding feature that can block network traffic matching known exploits against unpatched vulnerabilities. As you might imagine, this synchronous inspection carries a higher cost. Since network traffic must be held and analyzed for these exploits, it introduces latency, reduces throughput, and consumes additional memory and CPU cycles. NIS is not suitable for machines in high network intensive server roles such as IIS, Exchange, and SQL. Because of this, we provide a configuration option for administrators to adjust when the level of protection may be outweighed by the performance cost. By default, all server policies in our managed products have NIS disabled.
When a new zero-day unpatched vulnerability is widely found that affects Microsoft products, we can release a NIS signature to block that exploit on any machine with NIS enabled. This activates NIS to do synchronous inspection. After the vulnerability is patched, we can de-activate the signature, which ensures deterministic exploit coverage and performance control without leaving administrators and users wondering whether they are protected.
If you read this far, good for you! I promise to wrap up soon. Some of our customers have used an activated NIS service (nissvc.exe) as an indicator of unpatched vulnerabilities. Because NRI relies on the NIS service, it is now expected behavior to always observe it running, and it’s no longer a sign that something is unpatched. A running NIS service means that NIS has an active zero-day signature loaded (rare), or NRI BM has an active signature targeting suspicious activities at the network layer (common). At the time of this posting, there are 24 active NRI BM signatures and no active NIS zero-day signatures. Any machine with BM enabled should see the NIS service running.
By providing two distinct configuration features, we hope all machines will have NRI enabled, while still providing the option to enable NIS according to your performance requirements.
-- Jason Conradt, Program Manager, Protection Technologies
This posting is provided "AS IS" with no warranties and confers no rights.