Strong Defense

The classic protection mechanisms for corporate IT infrastructure have always included regular software updates, up-to-date virus and spam protection, one or multiple firewalls (think network segmentation), and intrusion detection and prevention systems. However, even admins that can tick each of these boxes are not automatically safe and can see their companies fall victim to hackers.

If you conceptualize an organization's IT infrastructure, you can imagine a figurative surface that might include web services offered to the outside world over a network, although it by no means comprises all the elements of the interface. The "attack surface" on which Microsoft documentation [1] focuses is the sum total of potential attack points on the computer systems of an IT network that unauthorized users could exploit. Other terms for these points of attack include security gaps or vulnerabilities, which basically also include physical access to protected hardware.

Besides all the obvious network components, including every type of hardware and the firmware installed and running on it, you also have potential points of attack for hackers on the software side. These vulnerabilities do not necessarily have to be errors in the development of the server software itself. Internet Information Services (IIS) for Windows Server, Apache or N, mail servers, and many other standard services usually come with a secure basic configuration, but the software running on or behind the server often offers direct access to further infrastructure or data in the form of APIs or comparable interfaces.

Even human interfaces can be a relevant part of the attack surface. Cybercriminals often focus on access to the employee or customer user accounts and the infrastructure resources that can be accessed from those accounts. Of course, weak, easily guessed, or compromised passwords used for multiple services pose a risk that is as serious as user-managed devices in bring-you-own-device (BYOD) scenarios or shadow infrastructures set up without the knowledge of the IT department.

Attack Vector and Surface

The attack vector is the method or steps a hacker uses to penetrate a network or system, bypass existing security measures, and gain access to resources – or simply cause irreparable damage. Attack vectors can be diverse and comprise several steps, which, at times, makes them difficult to detect in the mass of legitimate user activities. Technically speaking, then, attack vectors consist of a mix of phishing attacks, malware in email attachments, zero-day exploits of software vulnerabilities, man-in-the-middle attacks, and physical access to critical resources.

This distinction forms the basis for the development of effective security strategies. Whereas the attack vectors represent concrete methods that criminals leverage to gain access step by step to a resource, the attack surface offers a holistic view of all possible attack vectors and the relevant devices or services. Three classes can be distinguished: unknown, known, and malicious assets.

Unknown assets are one of the biggest security problems and are a kind of shadow infrastructure that is managed individually, and usually without extensive specialist knowledge, by employees outside the control of the IT department. Known assets are the opposite: devices and services managed by the IT department, such as all client computers and servers, including the services running on them and the associated dependencies. Malicious assets are sometimes known but outside the direct control of the IT department, such as malware domains from domain generators, (web) servers hijacked by criminals, or mail servers used to send spam.

Microsoft Defender to Start

The core of attack surface mitigation on corporate assets consists of Microsoft Defender for Endpoint or Windows E5 licenses in an environment with Entra ID and Intune. In fact, you can also install Defender on Linux devices in your infrastructure, but rulesets other than those recommended in the standard documents are likely to be more useful.

The rules for reducing the attack surface can be enabled on Windows Server from version 2012 and Windows 10 and work without the Defender portal or group policies, even on home computers (more on this later). Armed with Defender's built-in tools, you can use the checklists provided by Microsoft to create policies that reduce the existing attack surface, and you can enable or disable the rules in different modes in the Endpoint security management console.

Before you simply go ahead and wildly enable rules in your organization, Microsoft recommends careful planning and testing to avoid enabling policies that can later cause problems in your infrastructure. In the planning phase, you first want to establish an overview of the business areas and identify the guidelines that make sense for those areas. Departments with software developers probably need different authorizations for Windows functions than for accounts.

You also need to keep an eye on the applications in use and the effects planned changes will have on them. During the changeover phase, you should put together a team that will act as a point of contact for this business area, evaluate any issues reported, and resolve them promptly. In large organizations, the team will comprise one or more admins and at least one analyst from your security operations center. In small companies, the admins will often have to analyze the reported problems and possible threats by themselves.

Rolling Out Rules

If you want to deploy rulesets for a very large number of devices in your organization, you need to define rings like those you probably already use for Windows updates for step-by-step deployment. It makes sense to match the rings for Windows deployment itself. Start with the inner ring and enable the selected rules in audit mode initially. After some time, you will start seeing reports on the Defender portal. In a 30-day view, you can see the effects of your ruleset and how many incidents the individual rules caused.

Work through these reports, identifying problems and false positives, and, if necessary, define exceptions for the further process. Note that existing Defender exceptions also apply to most of the attack surface reduction rules. When folders, programs, or processes are shared, they are not monitored, although this does not apply to the Windows Management Instrumentation (WMI) persistence rule.

In the next phase, you will exit audit mode and activate the defined rules. If you identified rules that repeatedly caused problems during your audit, you might not want to activate block mode for them but use warning mode first to collect further data. You can define exceptions, and they remain in effect on the local device for 24 hours. It is no problem to enable only the simple and clearly problem-free rules at first. Again, you will want to monitor the messages on the Defender portal during this phase and talk to the employees concerned. Also bear in mind that a reported incident is not automatically a false positive just because a user reported the problem; a legitimate attack could be behind the warning.