When Avertium’s CyberOps Center of Excellence analysts map out the attacks we see against the MITRE ATT&CK framework, we find that the most common Initial Access technique used today is Phishing. Through the Phishing tactic, attackers will often attempt to execute malicious code on the victim machine through malicious links or attachments.
Execution of this malicious code can grant the attacker elevated privileges, establish persistent access, or even enable full remote control of the device.
Developing and enforcing a whitelist application is one-way organizations can dramatically decrease the threat these attacks pose to their corporate cybersecurity.
This article explains the difference between whitelists and blacklists and explores using application whitelisting to stop malware.
Before discussing the specifics of application whitelisting, it’s important to understand what a whitelist is.
Application whitelisting is the practice of specifying an index of approved software applications or executable files allowed on a computer system.
Some systems whitelist by default, allowing only certain apps to be run on a computer. However, such a list is often biased (Ex., Microsoft only allowing Microsoft Edge and blocking other browsers) and may not meet the needs of an organization or individual.
News! Avertium Adds Sophos 2020 MSP Partner of the Year, Americas to List of Partner Awards
When trying to protect a system from malicious content (emails, websites, applications, etc.), the two primary paths are a blacklist and a whitelist.
In a blacklist, the security system allows anything that is not explicitly denied (i.e. known malicious content). A whitelist employs the flipside, only allowing approved content through the barrier.
The choice between the two comes down to the specifics of the situation and the trade-off between usability and security.
Simply put, a blacklist is an easy path to take, but it's much less effective than a whitelist. As with most things in life, if something is worth doing it's often hard.
Let’s unpack that.
If it’s possible to completely define either all possible malicious content or all possible benign content, then defining them in a blacklist or a whitelist is an ideal solution. However, in most cases, it’s impossible to exhaustively list all possibilities. This means that the system will suffer from a potential lack of security (malicious content not included in a blacklist is allowed) or usability (benign content not included in a whitelist is blocked).
Developing a customized whitelist can help improve system security by specifically tailoring protection to the needs of the individual or organization. To build an effective whitelist, you must fully understand your operation and its data and security program governance; what your healthy data flows and access and authorization look like in order to spot irregularities, and what applications are supposed to be running within an environment.
“The whitelisting challenge is not the technical side. It all comes down to technology governance and security program governance,” says Avertium CISO Paul Caiazzo. “It has to be very strong to support application whitelisting because it really does require a very firm grasp on the organization’s operational workflows, what should be happening on the network, and what's happening on the network. At enterprise scale, the challenge grows unwieldy without the right mix of knowledge, process, and technology.”
Caiazzo adds that, in addition to knowing the environment, to use application whitelisting to stop malware successfully, the governance structures needed to maintain the whitelist must be built and adhered to.
“The well-governed organization controls the waitlist granularly and strictly,” says Caiazzo. “Exceptions are extremely rare, and additions to the whitelist go through a security change advisory board review. And if that's done, then it's a very effective strategy to minimize potential risk.”
Related Reading: Gauging Risk Tolerance for Remote Workforce Security Versus Privacy
Even within a strong whitelisting program, there is potential for that system to break down. One way is for an attacker to use an attack tactic called masquerading.
“This is not just masquerading as a user, but an application masquerading as another application even down to the actual software signature, often via a stolen private key.”
An example is an attacker stealing software sign-in keys to allow the bad actor to masquerade their applications as others. Key security is a critical component of a security program whenever private keys are used, and whitelisting’s dependency upon key security is often overlooked.
“If the white list application hasn't been set upright, it won't catch that,” cautions Caiazzo. “Like anything, there's nuance to it. But a program built alongside strong governance can be very effective.”
Developing an application whitelist is a two-stage process. First, the list of programs that should be allowed on the protected system needs to be defined. Then, the application whitelist needs to be enforced on the target system, including mechanisms for monitoring exceptions and performing updates.
To protect a system and use application whitelisting to stop malware, you need to first identify the programs allowed to execute on the system. The whitelist should be designed to allow any programs necessary for normal operation. It should block superfluous or potentially vulnerable applications. Doing this achieves the appropriate balance between usability and security.
When defining an application whitelist, two major considerations exist; job roles and necessary background functionality.
To maximize security and usability, application whitelists should be defined on a role-based or even individual basis. For example, a system administrator or member of the IT staff may have a very different set of necessary programs than an accountant or a salesperson. Allowing users access to programs unnecessary for their job role expands their attack surface.
The second consideration is the necessary background functionality for a computer to run. For example, disallowing explorer.exe (the application that allows access to files and folders) to run on a Windows computer will render it unusable. An application whitelist should allow background programs necessary for proper computer function.
The next step is to create a way to enforce your application whitelist on your protected computers. The best enforcement method mainly depends on the target operating system used by your computers.
Windows computers, except for the Home edition, allow application whitelisting via the computer’s Local Security policies under the Security Policies Editor. If you’re using Windows Home Edition, you’ll need to use a third-party application to enforce your policy.
Mac has a couple of different built-in options. Under the apps tab, Parental Controls is the option to limit applications. You can specify whether or not to allow apps from the App Store and define specific apps to allow.
For a more general policy (similar to the default settings on Windows 10), you can limit installation to apps from the App Store and identified developers under the General tab of Security and Privacy settings (under System Preferences).
Many phishing and other malware attack vectors rely upon an attacker being able to download and execute malicious software on a target system. Using an application whitelist, organizations with strong data and security governance in place can restrict programs to only those pre-approved by the organization. This can help to dramatically improve organizational cybersecurity. The practice blocks cyberattacks in their early stages instead of incurring the increased costs of later detection and cleanup.
Are you ready to apply more rigor to your security program by assessing and using application whitelisting to stop malware? Reach out to start the conversation.