Attack Surface Reduction

First, consider a few definitions and terminologies before we proceed:

• Threat Actor: A threat actor or malicious actor is a person, entity, or object responsible for an event or incident that impacts, or has the potential to impact, the safety or security of another entity. In Cybersecurity, this can only be a “Human” or an “Executable file” (Executable file is any type of a file that sends instructions to the CPU either directly or through interpretation).
• Security Posture: is the overall security status of an enterprise’s entire inventory consisting of software and hardware assets, networks, services, people, information etc. and covers also security controls and measurements, cyber defense systems, and enterprise readiness that allows an enterprise to be poised to react, respond and recover from security incidents.
• Attack Surface: All the contact points on systems (or networks) that an adversary can try to breach to access its data, credentials, and information systems. It is the sum total of all possible techniques and paths that an attacker can use to gain unauthorized access to a company’s assets. (The attack surfaces of your home, for example, from a burglar’ perspective, might be your doors, windows, chimney, basement, garden etc.)
• Attack Vector: An attack vector is a path or means by which a hacker can gain access to a computer or network server in order to deliver a payload for malicious outcome. In most cases, attack vectors enable hackers to exploit system vulnerabilities.
• Vulnerabilities: The official definition of vulnerability is a weakness that can be exploited by a threat actor. We can also define it as a deviation of intended behavior of the system due to intended or unintended manipulation of system inputs or states.

So, if we use those terms and define them all in the same context, an attack vector is a path or means by which a hacker can gain access to a computer or network server in order to deliver a payload for malicious outcome. In most cases attack vectors enable hackers to exploit system vulnerabilities. All possible attack entry points on systems are collectively termed as the “attack surface”. A Security Posture of the enterprise might have millions of possible attack entry points or “attack surfaces” — some of them may have security controls or counter measures from attacks enabled, others may still be open and exploitable. A systems without an attack surface is an impossibility.

Let’s look at all the categories of attack surfaces:

• Human Attack Surface
• Network Attack Surface
• Systems Attack Surface
• Application Attack Surface
• OS/Kernel Attack Surface

Human Attack Surface

Defines all type of errors, mistakes or malicious intentions by human actors internal to the organization. Regardless of how many technical controls implemented, no matter how few processes and data resources exposed to the external world. Users will always be one of the biggest sources of an attack by enabling attacks with a click of the mouse, or by replying to a phishing email. Security awareness training is one of the techniques that train employees on behavior necessary to maintain security policy compliance. Separation of duties, enforcement of least privilege to the users of the system, and maintenance of need to-know principles are necessary at this step. All these steps help apply “Attack Surface Reduction” to “Human Attack Surface”.

Network Attack Surface

Having an external boundary of your systems, the network attack surface can be the biggest among all other categories. This covers all external attack paths including reconnaissance to delivery. The attacker can be outside the organization, or inside, where s/he is intent on penetrating the network defenses. At this step, we must define external trust boundaries between systems, network segments, and organizations. Before any data transfer or critical actions can take place across the boundary, it is important to define and mandate a trust boundary. Requests for services or data from outside of a system are a required component of the action/condition chain required for malicious control of a target. On the network level, this can be granted by properly segmenting the network. To reduce attack surfaces on the network, define a level of trust and create trust boundaries. Trust levels should start from organization to organization and extend to external business partners, customers, remote employees, and cloud services. Once trust-levels are defined, segmentation of the network is needed, while also allowing the same trust-level networks to communicate for any other connectivity. Developing an enterprise network edge and data center trust boundaries, can deny malicious access to systems, processes, and data resources.

System Attack Surface

A system is the combination of hardware and software components as well as users/systems with access to the system, processes, and the ability to change the data. Systems can be on the same network or expand to a number of networks due to
dependency of external systems or data. The first step in reducing the system attack surface should be discovering all system components, and all internal and external system dependencies. This isolates and then breaks down the system components into different trust levels. As in network attack surface reduction, we should also define trust boundaries. System trust boundaries exist both internally and externally whenever a trust boundary separates two systems or their processes. Establishing a trust relationship requires verifying the identity and applying an appropriate set of access rights management communications channels.

Next, consider the external trust boundaries that exist between systems, network segments, and organizations. Anytime two systems connect, whether the system itself or enterprise, they will share a common attack surface. The attack surface of system A will depend on the processes in system B, which system A depends on. This attack surface should be governed by a set of access rights between A-B. In addition to that, both systems require identity verification before establishing common sessions. The same is true of Web services or other processes that might request use a process or data resource from another system. Organization to organization communication is also another channel of connection that needs to be investigated for this level of attack surfaces. When an organization establishes connection with another organization, its attack surface is extended to that of the external entity, with a trust boundary between them. Two actions help retain an acceptable attack surface: assurance of the external entity’s expected levels of trust, and establishment of strong trust-boundary management.

The attack surface at the system level can be controlled and reduced by carefully selecting access rights. A subject-Object model can be constructed wherein the subjects can be a system process, other systems, or users, and objects can be a system process or data inside the system. System processes or data as objects that are accessed by subjects should be controlled by access rights for the channel of communication. The Channels/Protocols represent the communication media, and these could be as basic as offline messages, emails, user interfaces, or synchronous API calls between two different systems. If we model this definition as: a system attack surface is the total of all exposed processes/data resources and allowed channels/protocols as constrained by the existing set of access rights, we end up with this formula:

So, in order to reduce the attack surface at the system level, we need to reduce the number of exposed processes and data resources, and also reduce the number of channels. However, most of the time this cannot be applied easily without negatively effecting system functionality. Therefore, increasing system access rights and carefully designing it so that it will govern all channels and all data resources is one of the more practical ways of reducing the attack surface.

Application Attack Surface

At this level, we are operating at the endpoint or server level, and applications running on them create an attack surface that requires protection. Traditional endpoint protection solutions like Host-Based Firewall, NextGen-AV, Host-based IDS, etc, are good examples of this level. There are also basic attack surface reduction (ASR) techniques applied by operating systems like universal extensible firmware interface (UEFI), operating system module and driver verification, Kernel and Memory integrity protection: Kernel Data Protection (KDP), Address Space Layout Randomization etc., for this level.

Here are some basic examples of attack surface reduction techniques for this level:

• Hardware-based isolation
• Application control
• Access Control on Objects
• Exploit protection
• Malware protection
• Network protection

And here are some basic examples of ASR rules that Windows itself integrates:

• Block executable content from email client and webmail
• Block all Office applications from creating child processes
• Block Office applications from creating executable content
• Block Office applications from injecting code into other processes
• Block JavaScript or VBScript from launching downloaded executable content
• Block execution of potentially obfuscated scripts
• Block Win32 API calls from Office macro
• Use advanced protection against ransomware
• Block credential stealing from the Windows local security authority subsystem (lsass.exe)
• Block process creations originating from PSExec and WMI commands.
• Block untrusted and unsigned processes that run from USB
• Block executable files from running unless they meet a prevalence, age, or trusted list criteria
• Block Office communication applications from creating child processes
• Block Adobe Reader from creating child processes
• Block persistence through WMI event subscription

However, if we recall the definition of Attack Surface as the total of all possible paths an adversary can take in an attempt to cause a breach, these are only the tip of the iceberg for surface reductions, and there is a huge surface under the water! As previously mentioned in other documents http://techtalk.comodo.com/2020/08/27/comodo-mitrekill-chain/ — the Kill-Chain Step 5 and onwards lacks comprehensive ASR strategies.

OS/Kernel Attack Surfaces:

Now lets talk about my favorite layer. First, let me tell you why it is my favorite layer :

• This is the most powerful layer: this is where your OS Kernel resides and operates
• This is the most under-utilized ASR-applied layer

Imagine being able to use the power of this layer coupled with effectiveness of ASR techniques… this is an extremely powerful combination.

This OS/Kernel Attack Surface layer is responsible for running everything from a simple client computer, virtualized server, or containerized workload running on the cloud, all of them running on operating systems and interacting with OS Kernels for any type of communication or persistence in the system. It truly is a magical layer for bringing heightened security.

The real damage is done at Kill Chain-Step 5 and beyond. Because this is where the installation of malicious payloads take place. Rightly so, the Cybersecurity world tries to stop them from reaching this layer, however we all know it’s a mathematical impossibility (The Halting Problem, Alan Turing): 100% detection is Not Possible. This means adversaries will breach step-5, period! Therefore, we propose that applying ASR on this powerful yet under-utilized layer is of paramount importance!

Xcitium introduces ASR2 as part of its ZeroDwell Containment feature — a holistic security architecture to minimize the attack surface on the OS/Kernel layer. The reason why we name it ASR2 is because Xcitium’s new architecture has two separate and very effective ASR techniques being applied to this powerful yet underutilized layer. Let me explain what these are:

Executable/Code Level Attack Surface Reduction Technique (ELASR)

With this technique, we allow full system resources to be available only to known good applications and processes, whether or not these executables come in as a .EXE or as scripts running in an interpreted environment. They only get full access to system resources if they are known good. And we call this component Verdict Cloud!

Verdict Cloud is an infrastructure that has everything from AI to behavioral analysis, from static to dynamic analysis, from algorithms giving verdicts to human brains and insights determining verdicts. Let’s take a look at actual historical data to see the power of ELASR. (this is historical data set from 08/01/2020 to 08/31/2020 from enterprise customers).

1. Device :
   1. 9.17% Percentage of active devices that saw an unknown executable file
   2. 90.83% Percentage of active devices that operated on known good state
   3. 0.13% percentage of active devices that had malicious activity running in Kernel API Virtualization via ZeroDwell Containment (KLASR: Kernel Level ASR)
   4. 0% infection/breach
2. File:
   1. 97.31% Percentage of the unknowns that turn out to be clean
   2. 0.21% Percentage of the unknowns that turn out to be potentially unwanted application (PUA)
   3. 2.28% Percentage of the unknowns that turn out to be malware (to reemphasize none of these resulted in infection or breach as every unknown executable, which these files were, because they all were running in Kernel API Virtualization mode)

While in automated ZereoDwell Containment (Kernel API Virtualization), unknown files are simultaneously uploaded to Xcitium Verdict Cloud, where every unknown file is assessed to deliver a trusted verdict, Good or Malicious:

Please note, the Xcitium Verdict Cloud is very different than other cloud-based sandbox solutions. It is not a sandbox, and it doesn’t just rely on behavior analysis (dynamic analysis) to give a verdict.

The Verdict Cloud analyzes unknowns using two different verdicting methodologies,

1. Analyzing to find Good behavior
2. Analyzing to find Bad behavior

Each submitted file undergoes further real-time analysis powered by Verdict Cloud global threat intelligence, which is constantly collecting machine learning and AI derived IOCs from nearly 90 million sensors worldwide.

• Each file, to start with, is put through behavioral analysis to identify malicious intent. Unknown executables are detonated in a virtual, cloud-based environment; all actions are monitored and analyzed. Processes spawned, files and registry key
  modifications made, host state changes, and network activity are recorded. Such proactive behavior analysis can often accelerate the identification of zero-day malware.
• If a process is found to be malicious by Verdict Cloud, a Malicious verdict is assigned, and a unique identifier IOC signature is immediately returned to all networked endpoints.
• The file is quarantined or deleted from all managed endpoints (depending upon policy) and the local and global blacklists are updated.
• We don’t just rely on dynamic analysis as a final verdict, though. If no malicious behavior is identified by Verdict Cloud, it is submitted to our Global SOCs for indepth human analysis with an SLA of ~4 hours. Please note: the reason Xcitium is able to assign a verdict to human analysis is because of the innovation that reduces the attack surface to a limited few unknowns,
• To preserve the integrity of the global whitelist, automated behavior analysis can add signatures only to the global blacklist. The status of ‘Good’ can only be granted to a file after in-depth checks by our technicians (or if the local administrator adds it to the local whitelist).

2-Kernel Level Attack Service Reduction: KLASR

Kernel API Virtualization is achieved by introducing a virtualization layer between processes running an unknown executable with Kernel functions. We have introduced 5 main virtualization components that filter any relevant Kernel calls or callbacks:

• File System
• Registry
• Kernel Object
• Service
• DCOM/RPC

These are the main virtualization components that run both user and kernel mode, handle necessary interrupts, and implement all necessary filter drivers to fulfill requests.

Kernel API Virtualization is also described in my previous post http://techtalk.comodo.com/2020/08/17/comodos-patented-kernel-api-virtualizationunder-the-hood/ and it takes place while a file or object is undergoing verdicting. ZeroDwell Containment (Kernel API Virtualization mode) does not allow access to system resources or user data directly. This provides protection against zero-day threats, prevents damage from occurring to the real system, and has no impact on end-user experience or business
operations.

Xcitium’s holistic security architecture leverages numerous threat prevention technologies to intelligently classify and route all unknown files and processes to a secure container (Kernel API Virtualization). Rather than containing all user processes of a certain type, Xcitium’s proven and trusted verdict decision engine, called Verdict Cloud, identifies and contains any and all non-whitelisted and non-blacklisted processes that have not yet exhibited malicious behaviors. This delivers a secure threat prevention strategy for unknown files without over committing system resources to contain safe processes which present no danger. Security is further enhanced by the fact that even whitelisted processes running on the host are still subject to policy-driven behavior monitoring from Xcitium’s advanced endpoint host monitoring, HIPS, firewall, AV and Defense+ systems.

When a file is requested from an external source, it first passes through Xcitium’s packet filtering firewall which is installed on every endpoint. As a first layer of protection, this eliminates any threats housed within malformed data packets. After that, every single file that enters an endpoint must pass through the following security inspections on a local machine:

1. If the file is determined to be malicious, by customizable policy, it is quarantined or deleted.
2. Xcitium’s File Look-Up Server (FLS) checks the very latest whitelist and blacklist databases. These checks are run in real-time and deliver near instantaneous feedback to the local machine – end users do not experience any delay. A digital hash of the unknown process or file is created and uploaded to the FLS to check whether the file signature is present on the latest databases that contain the global blacklist of all known malware signatures, and the whitelist of known safe file signatures.
3. If the hash is discovered on the blacklist then it is known malware. The result is sent back to the endpoint and the process is quarantined or deleted.
4. If the hash is not on the latest blacklist, its signature is checked against the latest global whitelist. If the hash is discovered here then the file is considered safe to run on the host machine. The local whitelist will be updated accordingly.
5. Files and processes that emerge from the inspections above with a status of “unknown” are automatically ushered into Xcitium’s ZeroDwell Containment (Kernel API Virtualization) on the local machine.

Xcitium Verdict Cloud: ASR on the Executable-Code Level

While in ZeroDwell Containment (Kernel API Virtualization), unknown files are allowed to progress but are simultaneously uploaded to Xcitium’s Verdict Cloud, where several static, dynamic and behavioral forensic analyses are performed in an effort to quickly issue a trusted verdict, Good or Malicious:

• Each submitted process undergoes real-time analysis powered by Verdict Cloud global threat intelligence, which is constantly collecting machine learning and AI derived IOCs from nearly 90 million enterprise and consumer user installations worldwide.
• Our remote servers submit each file through behavioral analysis to identify malicious intent. Unknown executables are detonated in a virtual, cloud-based environment; all actions are monitored and analyzed. Processes spawned, files and registry key modifications, host state changes, and network activity are recorded. Such proactive behavior analysis can often accelerate the identification of zero-day malware.
• If a process is found to be malicious by Verdict Cloud, a Malicious verdict is assigned, and a unique identifier IOC signature is immediately returned to all networked endpoints.
• The file is quarantined or deleted from all managed endpoints (depending upon policy) and the local and global blacklists are updated.
• If no malicious behavior is recorded by Verdict Cloud, the file remains contained on the local endpoint and is submitted to our Global SOC teams for in-depth human analysis.
• To preserve the integrity of the global whitelist, automated behavior analysis can add signatures only to the global blacklist. The status of ‘Good’ can only be granted to a file after in-depth checks by our technicians (or if the local administrator adds it to the local whitelist).

Kernel API Virtualization : ASR on Kernel

Kernel API Virtualization is achieved by introducing a virtualization layer between processes running unknown executable with Kernel functions. Again, we have introduced 5 main virtualization components that filter any relevant Kernel calls or callbacks:

• File System
• Registry
• Kernel Object
• Service
• DCOM/RPC

As mentioned in the preceding section, these are the main virtualization components that run both user and kernel mode, handle necessary interrupts, and implement all necessary filter drivers to fulfill requests.

There are a few container-based solutions on the market today, with each vendor claiming to provide automatic and complete protection against threats while simultaneously reducing how much time administrators need to spend dealing with malware. All this is supposedly achieved without interrupting end-user workflows, without requiring additional expense, and without hogging network or system resources.

Let’s analyze some data sampled from over 55K endpoints within our enterprise customers.

The first table shows that out of 55,042 endpoints, only 825 of them still have some unknown files, which means that among endpoints protected by Xcitium, only 1.49% of all endpoints have unknown files, and 98.5% of all endpoints are operating in a known good state. Xcitium reduces application attack surface by 98.5%. And the remaining 1.49%, causing zero infections because every unknown was contained using Kernel API Virtualization, reduced the attack surface to 0. During this period, 432,632 unique files were analyzed, 9,874 zero-day malware were identified and eliminated, with zero infection. This is how ASR x ASR = ASR2