Introduction
This document provides guidelines for configuring the Blocking and Isolation Policy on Mac endpoints. The guide is structured by enumerating different tiers that can be combined to build the best policy for a given environment and use-case.
The lower tiers contain more broadly applicable, generic prevention rules and upper tiers contain more advanced behavioral rules.
In general, tiers I to III, apply to most standard user environments, while tiers IV+ require more validation/testing in a specific environment, followed by closer monitoring and whitelisting false positives.
Administrators can start by picking rules from the lower tiers to create a baseline prevention policy and work up the tiers to add more advanced rules. Administrators should pick rules compatible to specific use-cases ( refer to the “Example Use Cases”). For behavioral rules in the upper tiers, whitelisting is more important to reduce potential false positives.
Note that, detection capabilities are not impacted by any prevention rules.
The document currently assumes 3.4 Mac sensor, which supports rules listed in the examples below.
Whitelisting
Administrators should consider at least "some whitelisting", starting with certs for code and installers sanctioned in the organization. Sufficient whitelisting enables implementation of more advanced behavioral rules and, hence, better 0 day malware prevention.
Mac supports whitelisting by:
1. Code signing cert
Applicable to binary files (code and DMG images) signed with code signing certs sanctioned in the organization and verified by sensor.
Example: Developer ID Application: Company Inc. (RER4OQRE3E)
2. PKG Installer cert.
Applicable to PKG install files signed with installer certs sanctioned in the organization and verified by sensor.
Use this in conjunction with 1), for common software installers and updaters distributed as PKG. When whitelisted, every code file packaged within the PKG is initially trusted (LOCAL_WHITE)
Example: Developer ID Installer: Company Inc. (RER4OQRE3E)
3. IT Tools
Trusted code droppers whitelisted by dropper path. When whitelisted, code dropped by whitelisted process (and not the dropper process itself) is initially trusted.
Use this for software deploy tools and developer tools.
Example: /Applications/MyTrustedIDE.app/Contents/MacOS/MyTrustedIDE
4. Hash
Whitelisting individual files by their hashes.
Use this to whitelist specific files that may have been categorized as malicious.
5. Permissions - by path
Specific Operation: allow specific process path to perform a specific operation (example: ransomware)
All Operations: Last resort. More for performance and and to minimize interop issues and not prevention.
Policy Rule Tiers Tier I. Detect + Prevent Blacklisted
Minimum prevention with maximum performance, aka “detect” or “response” mode.
Administrator responds to detected Threats and TTPs and manages the blacklisted hashes on the Reputation page. Delay-for-cloud reputation is implicitly disabled, resulting in zero perceived performance impact, albeit with minimum built-in prevention.
|
App. Target
|
Operation
|
Action
|
Notes
|
|
Company Blacklist
|
Tries to run or is running
|
Deny
|
Pre-execution blocking of applications blacklisted by hash by the Administrator
|
Tier II. Standard Malware Prevention
Pre-execution blocking of commonly known malware targeted by cloud reputation.
Note that, Deny/Terminate actions are synonymous for the “Tries to Run” operation, resulting in identical best-effort behavior: if application is already running, it is terminated, otherwise it is blocked on pre-execution.
The rules provide prevention capabilities similar to that of “traditional AV” where “static” signatures are used to identify and prevent malware; though Cb Defense cloud reputation service contains a super-set of reputations compared to what a typical AV would be able to store on the endpoint.
New files are delay-executed (delay for cloud is implicitly enabled), to ensure most accurate reputation is used to make the policy enforcement decision at pre-execution (i.e before the code image is loaded into the process). If malware process is already running on the machine, it is terminated and then blocked on subsequent execution.
Files encompassed by this set of rules include: Mac binaries, scripts, dylibs, kexts, installers, documents (especially containing macros) and Windows executables. Windows executables are blocked from running (for example through an emulation layer, such as Wine) and quarantined.
Files blocked from running by this set of rules are also quarantined in-place to prevent malware from spreading to other devices.
|
App. Target
|
Operation
|
Action
|
Notes
|
|
Known Malware
|
Tries to run or is running
|
Deny
|
High confidence malware blocked from running.
|
|
Suspect Malware
|
Tries to run or is running
|
Deny
|
Medium confidence malware blocked from running.
|
|
Adware / PUP
|
Tries to run or is running
|
Deny
|
Low confidence malware blocked from running.
Adware or Potentially Unwanted Program - may actually be legitimate in some environments; the rule could then be optional or countered with Whitelisting by Hash.
|
Tier III. Behavioral Prevention - Standard
Behavioral prevention rules are used to target untrusted reputations that fall between the “known good” and “known bad”, i.e. applications without well-established cloud reputations.
Sensor applies action at application post-execution: either by terminating the process exhibiting the behavior (Terminate Action) or denying an operation associated with the rule (Deny Action). The goal is to protect against possible “0-day” attacks and stop potential malware before its reputation is widely known to reputation services.
Reputations of interest are: NOT_LISTED (not known to be good/bad) and UNKNOWN (reputation is not yet available, i.e. sensor may be offline).
Behavioral rules in this tier are low in false-positives and are generally safe to include in standard user policies as a starting point.
Additional path based rules can be used to prevent well known applications from performing certain operations, regardless of their reputation. This enables to restrict operations of some common white applications, in case they become compromised or are utilized by malicious code along the attack chain.
False positives should be tackled with Whitelisting (by Hash, Cert., PKG Cert, or IT Tools) or Permissions for a specific operation, depending on use-case and type of false positive.
|
App. Targets
|
Operations
|
Action
|
Notes
|
|
UNKNOWN
NOT_LISTED
Suspect/PUP
|
Performs Ransomware-like behavior
|
Terminate
|
This set of rules enable the Ransomware prevention engine.
Targeting this set of reputations yields low Ransomware FPs.
Additional Ransomware rules can be created targeting common white applications that could be compromised.
|
|
UNKNOWN
NOT_LISTED
|
Tries to inject code or modify memory of another process
|
Deny
Or
Terminate
|
Rules preventing applications without well established reputations from performing code injection, and potentially compromising other applications.
Target reputations are either for the application performing code injection, or dylib being injected into an application, depending on type of code injection.
|
|
At path:
**.docm
**.xlsm
**.pptm
**.doc
**.xls
**.ppt
|
Tries to inject code or modify memory of another process
|
Deny
Or
Terminate
|
Prevention rules against malicious Mac MS Office macros ( performing code injection )
|
|
At path:
**.docm
**.xlsm
**.pptm
**.doc
**.xls
**.ppt
|
Tries to invoke cmd-interpreter
Tries to invoke fileless script
|
Deny
Or
Terminate
|
Prevention rules against malicious Mac MS Office macros ( invoking obfuscated scripts and cmd-interpreters )
For low FPs, DO NOT create rules for Microsoft Office program files. Instead, use the documents extensions as selector.
|
|
At path:
**.docm
**.xlsm
**.pptm
**.doc
**.xls
**.ppt
|
Tries to invoke untrusted app.
|
Deny
Or
Terminate
|
Prevention rules against malicious Mac MS Office macros ( invoking untrusted code )
|
|
At path:
/Applications/My WebBrowser.app/Contents/MacOS/WebBrowser
|
Tries to inject code or modify memory of another process
|
Deny
|
Example rule against a specific target application; i.e. for white listed applications that more likely to be vulnerable could become an attack vector.
In this case, web browser is prevented from injecting code into other applications.
Apply this rule as an example for browsers such as Safari, Firefox, Chrome, Opera.
|
| |
|
|
|
Tier IV. Behavioral Prevention - Advanced
The following rules are examples of more advanced rules targeting applications ( by reputation or by path). The rules prevent behaviors that could be characteristic to either malicious actors without well-established reputations, or whitelisted tools that take part in the attack chain.
In all cases, these examples should be used as initial guidelines, followed by deeper testing and tweaking for a specific use-case and environment. Many of the rules can be effectively implemented with some level of whitelisting to handle internal software installs, updates, or developer tools. The developer-use case will require especially more validation and controls, and not all rules may be applicable.
“At path” rules examples can be extended to other applications and common locations of interest.
|
App. Targets
|
Operations
|
Action
|
Notes
|
|
UNKNOWN
NOT_LISTED
|
Tries to comm. over network
|
Deny
|
These 2 rules effectively restrict any applications without well-established reputations from talking on the network ( such as from talking to command and control).
The rule is quite strict, but can be an effective way of “sandboxing” potential malware in more predictable environments, especially if combined with prior whitelisting to handle internal software installs and updates.
|
|
UNKNOWN
NOT_LISTED
|
Tries to invoke fileless script
|
Deny
Or
Terminate
|
The 2 rules prevent applications without well-established reputations from invoking fileless / obfuscated scripts.
Deny action blocks the fileless script from execution. Optionally, Terminate action blocks the script and also terminates the application invoking it.
|
|
UNKNOWN
NOT_LISTED
|
Tries to invoke untrusted app.
|
Deny
Or
Terminate
|
Prevent applications without well-established reputations from invoking other untrusted applications.
Deny action blocks the untrusted child app. process from execution. Optionally, Terminate action blocks the child process and also terminates the application invoking it.
The rule is likely too strict for developer/power-user case ( custom code of unknown origin), especially without proper whitelisting. Consider alternative rules with more specific “at path” targets.
|
|
UNKNOWN
NOT_LISTED
|
Tries to invoke cmd-interpreter
|
Deny
Or
Terminate
|
These 2 rules prevent applications without well-established reputations from invoking cmd-interpreters.
Deny action blocks the cmd-interpreter from execution. Optionally, Terminate action blocks the cmd-interpreter and also terminates the application invoking it.
The rule is likely too strict for developer/power-user case. Consider alternative rules with more specific “at path” targets, or more heavy use of Whitelisting.
|
|
At path:
/Applications/My WebBrowser.app/**
|
Tries to invoke cmd-interpreter
Tries to invoke fileless script
|
Deny
Or
Terminate
|
Examples of specific “at path” rules preventing a web browser (potentially compromised ) from executing command interpreter and obfuscated fileless scripts.
Apply this rule as an example for browsers such as Safari, Firefox, Chrome, Opera.
|
|
At path:
/Applications/My WebBrowser.app/**
|
Tries to invoke untrusted app.
|
Deny
Or
Terminate
|
The rule prevents a web browser (potentially compromised) from executing untrusted code, such as malicious code dropped on the device, or unapproved plugins.
Potential false positives caused by “Tries to invoke untrusted app.” can be addressed by whitelisting the target application ( proprietary plugin, etc).
|
|
At path:
/Applications/My WebBrowser.app/**
|
Performs Ransomware-like behavior
|
Terminate
|
Another example of prevention rule for a common application - that could get compromised and start encrypting user files.
Apply this rule as an example for browsers such as Safari, Firefox, Chrome, Opera.
|
|
At path:
/Users/*/Downloads/**
/Users/*/Desktop/**
/private/tmp/**
|
Tries to invoke untrusted app.
Tries to invoke cmd-interpreter
Tries to invoke fileless script
Tries to comm. over network
|
Deny
Or
Terminate
|
Example broader path-based rules that can be used to selectively restrict what applications executing out of unusual install locations allowed to do, regardless of their reputations.
This approach is less restrictive than “Tries to run” operation for the same path targets , making it less intrusive to a user, while still effective against many attacks.
|
|
At path:
**/.**
|
Tries to comm. over network
|
Deny
|
Prevents applications installed in hidden folders or files (technique sometimes used by Mac malware and rarely by legitimate software) from communicating on the network.
|
|
**/Python
|
Tries to invoke cmd-interpreter |
Terminate
|
Prevents EmPyre and similar python-based backdoor-like payloads.
|
TIer V. Offline Protection
|
App. Targets
|
Operations
|
Action
|
Notes
|
|
UNKNOWN
|
Tries to run or is running
|
Deny
|
Prevents against new code dropped on the device being executed before cloud reputation was known to the sensor, i.e. when device is offline.
The rule provides a restrictive mechanism to prevent from running any code that made its way on the device via local vectors ( USB, LAN) before sensor is able to look up any reputation information about the new file.
Any new code on the device won’t be allowed to run during the offline period.
Shortly after device regains connectivity and sensor confirms the new file is not known to be malware, it will be unblocked.
Whitelisting can sometimes be used to allow some new sanctioned code to run in such offline scenarios, e.g. by IT Tools ( dropper application) or Cert. ( dropped application).
|
Example Use Cases
Examples of mixing different tiers to meet common use-cases are listed below. Note, these are just guidelines that should be adapted to a specific environment.
For example, a Developer use-case could be implemented more loosely with Tier I only - for best performance, yet minimal protection. Similar use case could also be implemented with close to maximum protection, utilizing a mix of rules from tiers I to IV. However, such implementation will require more administration and heavier Whitelisting ( by Hash, Cert, PKG Cert, IT Tools, Permissions).
In many cases, a successful implementation segments different types of users into different Policy groups that work best for a specific use case.
This table provides some middle-ground as a starting point; additional tweaking and testing is recommended to find the best balance of: best prevention + highest performance + degrees of manageability suitable for the organization.
|
#
|
Use case
|
Tiers
|
Notes
|
|
1
|
High-performance build server #1
|
I
|
Large # of code drops followed by subsequent executions of new code, such as “configure script” - type posix builds.
Minimal prevention with maximum performance. No immediate need for Whitelisting, instead requiring more attention to detection Alerts.
|
|
2
|
High-performance build server #2
|
I + II + III
|
Adds protection against known malware and some behavioral prevention against 0-day threats. Can apply to::
- Build server that, unlike 1) above, does not execute dropped code immediately,
- Build server from use case 1); build tools and scripts that act as “code droppers” are Whitelisted with “IT Tools” or included in “Permissions” thus reducing delay caused by immediate execution of dropped code.
|
|
3
|
Technical user (developer / power user)
|
I + II + III
|
Similar to use case 2) - high level of protection can be achieved with minimal performance impact, but may require whitelisting of developer tools by Hash, Cert., PKG Install Cert, or IT Tools Whitelisting.
|
|
4
|
Non-technical User
|
I + II + III + IV
|
Near maximum prevention capabilities - can be applied in non-technical user environments.
Binary and PKG Cert. Whitelisting is used to mitigate occasional false positives from applications that upgrade frequently and may exhibit some suspicious behavior.
|
|
5
|
Non-technical User / restrictive offline protection
|
I + II + III + IV + V
|
Maximum prevention capabilities for a non-technical user. Adds restrictive offline protection.
May require some Whitelisting for common 3rd party applications.
|
#CBIntelUpdate