What is App Control?
Carbon Black App Control combines application control, file integrity monitoring, full-featured device control, and memory/tamper protection into a single agent. App Control is used to lock down critical systems and servers, prevent unwanted changes, and ensure continuous compliance.
App Control is a positive security solution allowing for a "default deny" approach to reduce the attack surface. App Control gives administrators the operational confidence to automatically approve legitimate change and eliminate the burden traditionally seen in allowlist management.
Table of Contents
1. Accessing the TestDrive Experience
In order to complete this walkthrough please make sure you have the following:
- A valid account in the VMware TestDrive environment (if you do not have one sign up here)
- Allowed communication of TCP & UDP ports 80, 443, 8443; and if using PCoIP, both TCP & UDP 4172
- A Horizon Client is installed on your machine
Access the TestDrive portal at portal.vmtestdrive.com; sign in with your email and password.
Navigate to the 'Intrinsic Security' tab to view security related experiences.
Locate the appropriate experience. This lab is VMware Carbon Black App Control. Once located click the 'launch' button.
If prompted again, click the 'launch via WS1 button'.
Login with your TestDrive username and password. On the next screen, if not displayed, search for 'Carbon Black App Control' in the search-box. Click to open the VDI desktop via either the Horizon App or the web-based console.
The App Control console can be accessed via browser on an endpoint that has access to the App Control Server.
- Open the Chrome browser
- In the navigation bar, type in https://cb-appcontrol.vmwdp.com/ (or you can launch the Carbon Black App Control Chrome shortcut from Desktop).
- Note - you must include https
- Login with credentials provided in
App Control Credentials.txtfile on device desktop
On login you will view the home page. This TestDrive experience gives you view permissions on the App Control Server.
You may use the App Control server while reading background information or proceed directly to the lab activities depending on level of comfort. If you are new to App Control it is recommended to read the background sections prior to lab activities.
2. App Control Background
This section provides optional background related to the VMware Carbon Black App Control solution. If you have experience or background knowledge on the App Control solution this section may be skipped.
The App Control architecture consists of the following main components: App Control Server and the App Control Agent.
The App Control Server manages policies and rules including software approvals and bans. It also provides visibility into events and file activity on computers with an app control agent. To access the server, administrators use the App Control Console, which is a web-based user interface.
The server software runs on standard, server-class Windows computers. It can be run on a dedicated system or a virtual machine.
For information on supported App Control operating environment requirements see the following resource: VMware Carbon Black App Control Server Operating Environment Requirements
For information on installing the App Control Server see the following resource: Installing the App Control Server Software
The App Control Agent runs on client servers, desktops, laptops, virtual machines, and fixed-function devices. The agent monitors file and process activity and communicates with the App Control Server when necessary.
The App Control agent runs silently in the background until it blocks a file or requests approval (depending on enforcement level), at which point it can display a message to the user.
For information on supported agent operating environment requirements see the following resources:
App Control performs a one-time initialization crawl to inventory items and send this information to the App Control server. After the initialization crawl the App Control agent periodically sends over inventory updates to the server (30-second intervals).
Due to this operating method of looking for inventory updates versus a full inventory pull, App Control can keep resource utilization at 1-2% CPU per machine.
App Control is a positive security solution allowing for a "default deny" approach to reduce the attack surface and prevent threats.
App Control works by allow administrators to lock down critical systems, with the power to only allow approved files to run. This approach vastly limits the attack surface for advanced security capabilities.
VMware Carbon Black App Control is manageable and adaptive. The solution enables administrators to implement application control capabilities by providing methods of handling initial approval and trusted change overtime.
Not all machines and environments are alike. Prevention is customizable for systems and groups - admins can implement unique policies with different sets of rules as well as "Enforcement Levels" to determine how prevention is handled.
3. App Control Rules and Approvals
This section provides optional background related to the VMware Carbon Black App Control solution. If you have experience or background knowledge on the App Control solution this section may be skipped.
App Control can lock down critical systems by approving files and denying unapproved file execution. There are a variety of methods to control approvals and allow legitimate future change.
Files are classified according to their state. Security policies, which are groups of rules, control how files are treated based on their state. There are two types of states: global and local. The main states a file can be are approved, banned, and unapproved.
Global state determines what the file is allowed to do on agent-managed computers. The global state is a combination of file state and publisher state. File state is the approval/ban state of the file itself while publisher state is the approval state of the file’s publisher (if it is known). For example, a file may be unapproved but comes from an approved publisher (ex: Microsoft) leading to a global state of approved. Global states are:
- Approved for all computers
- Approved by Policy (approved by some, unapproved for others)
- Unapproved for all computers
- Banned for all computers
- Banned by Policy (banned for some, unapproved for others)
- Mixed (banned for some, approved for others)
While App Control keeps a global state for a file, each instance of a file on a computer has its own local state. Local state indicates what the file is allowed to do on the computer it was found on. Local states are:
- Approved
- Banned
- Unapproved
- Deleted (file has been deleted and will be removed from database on next update)
If a file has a global state of unapproved, it may have a different local state. For example, in the Medium Enforcement Level (see enforcement level section for additional details) a user can locally approve an unapproved file to run giving the file a local state of approved.
Files can be approved and also unapproved using a variety of built in/custom rules. Unapproved files will not be allowed to run regardless of Enforcement Level unless in a disabled state.
3.2.1. Trusted Change
Trusted change refers to changes in the environment that are legitimate. Change in an environment can occur from new applications being pushed, updates to existing applications, and so forth. App Control enables administrators with methods to approve trusted change in the environment removing the burden of manual approval when legitimate change does occur.
Rapid Configs are pre-built sets of custom rules that can be used to achieve more complex goals. They are curated by Carbon Black and built-in to the App Control solution. Rapid configs can accomplish use cases such as optimizing the interaction of App Control and a specific app, hardening of OS and apps, and approval of files created or delivered by certain tools or pathways.
One example of a rapid config is the Microsoft SCCM rule. This rule approves software that is delivered by SCCM. This offloads manual approval of applications that IT administrators push out via SCCM to a perpetual and automated method.
Rapid configs are continuously updated by Carbon Black. A recent addition to the rapid config ruleset is the SolarWinds-Sunburst Protection rule. This rule prevents exploitation of the SolarWinds breach. For more detailed information about the rules in this rapid config see the following resource (must be current Carbon Black customer w/access to User Exchange to view): SolarWinds Rapid Configs
Updater rules permit users to install application updates from approved sources as they become available for download. The list of updater rules are curated by Carbon Black. These rules allow for automated approval for trusted change allowing updates to selected applications.
3.2.2. Bulk Approval
Bulk approval refers to the initial approval to existing trusted files present on endpoint(s). When implementing application control bulk/initial approval accounts for the majority of approvals. Once the bulk approval is completed, administrators can then focus on trusted change over time. App Control provides simple methods for approving trusted existing files.
On the one-time initialization scan, App Control discovers each unique publisher identified in a valid certificate for a file.
Administrators can choose to approve, ban, or leave unapproved publishers that have been identified in the environment. A publisher can be approved for all computers or those in a specific policy.
A file identified as being from a publisher can only be approved by publisher if the certificates are considered valid by the operating system.
Reputation approval rules are used to automatically approve files based on the file and publisher trust ratings. Automatic approval using reputation can give end users flexibility and reduce the effort of maintaining approvals.
Trust ratings are assigned by Carbon Black File Reputation, which provides a cloud-based database of known files. Trust rating data combines file information from distribution partners, web crawlers, honeypots, and the Carbon Black user community. Reputation data provides context such as publisher and associated product (if any). The prior mentioned information is used by Carbon Black File Reputation to assign a threat level and trust rating (note: trust rating is also provided for publishers).
File trust ratings are given on a scale from 0 (lowest trust) to 10 (highest trust). Apps distributing known malicious software, for example, would have a trust value at or near 0. A signed OS file with no known vulnerabilities would have a trust value near 10.
Publisher trust ratings have four possible values: high, medium, low, and not trusted.
There are a number of options for reputation approval:
- Approval based on file or publisher reputation
- Approval based on a combination of file and publisher reputation
- Approval based on trust threshold (ex: approve if file trust is greater than 8)
When implementing reputation rules it is important to consider rule scope. Reputation rules can be enabled for all endpoints with an App Control agent or by specific policy groups.
In addition, reputation approvals can be disabled for specific files or publishers you don't want to automatically approve. For example you may want to implement trust based on threshold but disable approval for the publisher Adobe, which has a high trust level.
When you enable reputation approvals, any manual file or publisher state assignments you have made remain in effect and take precedence over reputation. For example, if you ban a file by name or hash, that file remains banned even if it would have been approved by reputation.
App Control offers administrators the capability to implement Custom Rules to address unique environmental concerns or use cases. Custom Rules define actions you want the agent to take in response to file, directory, or process activity that matches conditions you specify. They may be used to optimize performance, protect file integrity, create trusted file path for software distribution, or meet other special needs.
Many use cases can be fulfilled with Custom Rules including File Integrity Control (FIC). The following fields are used to create a custom rule:
| General Description | Field on Add/Edit Custom Rule Page |
|---|---|
| If this/these source process(es)... | Process |
| …and/or this/these user(s)... | User or Group |
| …attempts to perform this/these operation(s)... | Operation (Execute, Write or Both)* |
| …on this/these files(s)... | Path or File |
| …on computers in this/these policy(ies)... | Rule applies to/Policies |
| …on computers reporting to this/these App Control server(s)... | Rule applies to/Servers (if Unified Management is enabled) |
| …on computers running on this platform... | Platform (ex: Windows) |
| …then this/these action(s) should be taken. | Execute Action and/or Write Action |
Additional use cases for Custom Rules include but are not limited to:
- File Integrity Control/File Integrity Monitoring (FIC/FIM)
- Creating exception to other types of rules (such as approvals or bans)
- Execution control
- Approve files from software distributors
- Allow installers to run only from trusted network path
Given the flexibility of Custom Rules, rules can be created to suit any number of use cases.
Event Rules allow you to specify an action to be performed when a file- or computer-related event occurs that matches filters you define. Only events that relate to files or computers can be used to trigger these rules.
One common use case of an event rule is to take an action when a malicious file is detected.
A variety of actions are available to be taken when an event rules' criteria is met. You can chose to:
- Change global file state
- Change global process state
- Change local file state
- Upload a file
- Delete a file
- Analyze a file
- Move computer (to a different policy)
Note: Event rules can be tested prior to implementation. Event rules may have significant impact across the environment - it is always recommended to test rules before implementation.
| Approval Method | Software is Approved For | When to Use |
|---|---|---|
| Approving by Trusted Directory | All computers (global) | When you have a trusted, secure server (e.g., for software deployment) on which to create an authorized approval directory. |
| Approving by Trusted User/Group | Installation computer only (local) | When you want to give unlimited installation privileges to a Windows user account or all users in a Windows or AD group. Trusted users are allowed to install on any computer on which they log in with their credentials. |
| Approving or Banning by Publisher | Installation computer only (local), but can be installed on demand by any computer | When you want to approve all software from a vendor for which App Control can confirm a valid digital certificate. You also can approve or ban certificates that identify a publisher, and this affects file state. |
| Approving by Publisher Reputation | Installation computer only (local), but can be installed on demand on any computer | When you want to permit installation of application updates as they become available for download via specified application update programs. |
| Approving by Updater | Installation computer only (local), but can be installed on demand on any computer |
When you want to permit installation of application updates as they become available for download via specified application update programs. |
| Moving Computers to Local Approval Mode | Installation computer only (local) | When you want to permit users on computers in High Enforcement policies to install software. Local approval occurs when a user installs an unapproved file while in this mode. |
| Automatic Local Approval on Enforcement Level Change | Installation computer only (local) | When you want to locally approve unapproved files found while in Low enforcement or higher when you move the computer from a less secure Enforcement Level to either Medium or High. |
| Moving Computers to Local Approval Mode | Installation computer only (local) | When you want to permit users on computers in High Enforcement policies to install software. Local approval occurs when a user installs an unapproved file while in this mode. |
| Locally Approving All Unapproved Files on a Computer | Installation computer only (local) | When you want to locally approve all existing unapproved files on a specific computer. |
| Locally Approving Individual Files | Installation computer only (local) | When you want to select specific files on a computer for local approval. You can locally approve files or remove local approval. |
| Appoving Individual Files | Installation computer only (local) | When you want to automatically approve (by hash) all the software that Carbon Black File Reputation considers trustworthy. |
| Approving by Event Rule | Varies by Rule | When you want to automatically approve a file, either locall or globally, when it is included in a reported event. |
4. App Control Enforcement Levels
This section provides optional background related to the VMware Carbon Black App Control solution. If you have experience or background knowledge on the App Control solution this section may be skipped.
An enforcement level controls whether unapproved files (have not been approved or banned) are allowed to execute. Enforcement levels can be chosen for each policy that suits the security and user requirements for the group of computers associated with that policy. If a file has been banned, it is blocked at all enforcement levels with agent prevention enabled.
Administrators can define enforcement levels when a computer connected versus disconnected. If a computer is disconnected more strict enforcement levels may be desired this can be achieved.
Five enforcement levels are available:
- High
- Medium
- Low
- None (Visibility)
- None (Disabled)
High enforcement is the strictest enforcement level. In high enforcement only approved files are allowed to execute; unapproved files are blocked. App Control administrators should work towards moving to high enforcement for the strongest security stance however it is not recommended to start in high enforcement.
Medium enforcement prompts users when an unapproved file attempts to execute. A notification dialog is displayed, and a user can decide whether to allow or block the unapproved file execution. If the user chooses to allow that file is locally approved on that computer and will always be allowed to run.
Low enforcement allows both approved and unapproved files to execute without any user prompt. While approved and unapproved files are allowed to execute the file, activity is still monitored by App Control. Due to the visibility low enforcement grants while mitigating unwanted preventions it is recommended as one of the starting enforcement levels if blocked rules still wish to be enforced.
None (visibility) enforcement tracks file activities without blocking no rules are enforced. Due to the visibility none (visibility) grants it is recommended as one of the starting enforcement levels to gather file activity without enforcement.
None (disabled) enforcement stops all enforcement and tracking activities.
5. App Control Policies
This section provides optional background related to the VMware Carbon Black App Control solution. If you have experience or background knowledge on the App Control solution this section may be skipped.
Enforcement level and approvals can be assigned to computer groups, called Policies. A policy consists of groups of settings and an enforcement level (see previous Enforcement Level section for more information). Each computer running an App Control Agent is assigned to a policy. Policies can be created based on security and organizational requirements. For example, policies may be assigned based on functional role (e.g., marketing, IT); location; or type of computer (e.g., laptop, server).
There are three main policy settings:
- Basic Policy Definitions: policy name, basic security level (mode/enforcement level), etc.
- Device Settings: control the way policy treats removable devices (device control)
- Advanced Settings: control whether computers in a policy have certain file types blocked
The App Control console home page includes an Emergency Lockdown button. When pressed all agent-managed endpoints' Enforcement Levels will be changed to High Enforcement. Once emergency lockdown has been enabled, administrators can click on the same button to restore computers to their former enforcement level.
Emergency lockdown shifts the entire environment into a highly secure state - where any unapproved files will be prevented from executing. This functionality may be used, for example, if a threat is seen and some endpoints are in low or medium enforcement. Once the threat has been resolved prior enforcement states can be restored.
6. App Control Lab Activities
6.1. Enforcement Level Activity
This activity will cover Enforcement Levels and how assigned level affects running unapproved applications. For background on Enforcement levels see Section 4 of this guide.
This activity involves changing the Enforcement Level for your VDI endpoint. You can identify what your endpoint name is by right clicking the Windows icon in the lower left and selecting system from the menu. Your device name should follow the format cb-##-ac.
- Login to the App Control console. For information on accessing the console see Section 1.2.
- From the top menu, hover over 'Assets' to display menu options, then click 'Computers'
- Confirm that the selected view is 'Active Computers'
- Find your device name (for assistance find device name, see beginning of this section) and select checkbox
Note: From this view you can also confirm what Enforcement Level the device is currently in. Under the 'Connected Enforcement' and 'Unconnected Enforcement' columns
- Click the 'Action' button to display menu items
- From here, you can move the device into a desired policy. For convenience, three policies have been created for this lab: TD_Low_Enforcement, TD_Medium_Enforcement, and TD_High_Enforcement with the named Enforcement Levels
On the Desktop of your device is the application Steam, which is a digital distribution software often used for gaming. This file is unapproved in the environment. Let's run steam in the three different Enforcement Levels to see how each affects unapproved files.
Before beginning we can first confirm what file state Steam is in.
- In the console click on 'Tools' tab on the top menu to expand options, then click 'Find Files'
Let's search for Steam using the Find Files tool. On this page you can easily find files based by name or any other number of attributes App Control collects (ex: publisher, OS hash, etc.)
- Type in 'steam' to the textbox
- Select the 'contains' option when displayed
You will now have filtered down files to view files containing steam. If we want to filter further, we can search for steam.exe specifically as well. Scrolling through you should see 'unapproved' for both local and global state (click to expand image if needed).
Low Enforcement:
Confirm your device is in Low Enforcement (policy TD_Low_Enforcement). For information on changing Enforcement Level see Section 6.1.1. If not in Low Enforcement, switch to the Lowe Enforcement policy.
- On your endpoint's Desktop, click to run the 'Steam' application
- Note that while unapproved, Steam runs without prompt or issue
In Low Enforcement, unapproved files are allowed to run without user or admin action. If Steam was banned, it would not be allowed to run even in Low Enforcement.
Medium Enforcement:
You will now switch your device to Medium Enforcement (policy TD_Medium_Enforcement).
- On your endpoint's Desktop, click to run the 'Steam' application
- A prompt will appear from App Control, with details and the options to Block and Allow
- Do not click Allow - this will locally approve Steam on your device. We want Steam to remain unapproved for the final activity (running in High Enforcement)
- Click 'Block' to deny the execution of the unapproved app; selecting block will make no changes to Steam's file state of unapproved
In Medium Enforcement unapproved files are blocked or allowed to run based on the user's reaction to the App Control prompt. If file is allowed it will be granted the locally approved state.
High Enforcement:
You will now switch your device to High Enforcement (policy TD_High_Enforcement).
- On your endpoint's Desktop, click to run the 'Steam' application
- A prompt will appear from App Control informing the user the application is unapproved and blocked from running
- Close the notification when finished viewing
In High Enforcement unapproved files are blocked from executing. This is the most secure Enforcement Level with a 'default deny' approach.
Try It Yourself! Want to run more Enforcement Level tests? Create a .bat file on your device. The newly created .bat file will be unapproved. Play around with file states by approving in Medium Enforcement then try running in High Enforcement. As an example, you can create a very simple .bat file with the commands echo "WORDS_HERE"
6.2. Rule Discovery
This activity will cover a variety of rules and approval methods App Control offers. For more information on approvals see content in Section 3.
In the this activity you will be provided with a use case or scenario that can be solved by an App Control rule. After reading the use case, look through Software Rules (and all rule categories contained within) and determine what rule would best solve the given scenario. Answers and explanation will be provided in foldable section - expand only when ready to view answer.
The company VMturtles is using the App Control solution for their environment. They have a large number of Windows Servers that administrators manage - these Windows Servers all have App Control agents and are in High Enforcement.
VMturtles administrators use Microsoft SCCM to deploy new software and install updates as needed. The current App Control administrator, Sally, believes they must add each new updated application or net new application to the list of approved files using 'File Rules' in App Control.
As the newest member of the VMturtles team you believe there is a better method of allowing for trusted change in the environment. What rule do you suggest to the team in this scenario?
The Rapid Config rule for Microsoft SCCM resolves the given scenario. Rapid Configs come out-of-the-box (pre-built).
This rule approves software that is delivered by SCCM. This offloads manual approval of applications that IT administrators push out via SCCM to a perpetual and automated method.
Note: Another potential solution for this use case is creating a Trusted Directory. Trusted Directories can be added under the 'Directories' tab when viewing Software Rules. Trusted Directories can be used to automatically approve software during roll-outs. In this case, however, there is already an OOTB Rapid Config for Microsoft SCCM.
vCarbon, a technology company, is implementing the App Control solution. Initially they want to deploy in a Low Enforcement level to ensure no operational interruptions while implementing initial approvals and trusted change.
The security team at vCarbon wants to ensure that even while in Low Enforcement a rule is in place to report and block known malicious binaries. They've asked you to find a solution in App Control that can accomplish this task. What rule do you suggest to the team in this scenario?
The Event Rule to ban/report malicious binaries resolves the given scenario. Event rules give administrators the capability to take a variety of actions based on flexible file/computer triggers.
In the App Control console we have already created an event rule called 'Ban Malicious files' for this use case. In this rule, if a malicious file is detected a ban action will take place.
Note: There are all sorts of things you can do with event rules! While you are looking at the event rules check out the other samples that have been provided - including a rule to analyze all browser or email downloaded files.
An admin at the company vSpherical wants to allow files and applications to be downloaded and ran by users without his interaction in App Control. While they would like to allow users this freedom, they also want to limit this to only verifiably trusted files that come from a trusted publisher and the application itself is trustworthy.
What rule do you suggest in this scenario?
Enabling reputation approval with high publisher and file trust requirements resolves the given scenario. Reputation approval allows for dynamic approval of files based on administrator set thresholds of trust for app, publisher, or both.
Reputation approval is a fantastic way to allow for trusted change (and initial approval) while limiting that approval to verified, trustworthy apps and publishers.
PowerShell, while being a trusted tool, can also be leverage by attackers to do a variety of malicious actions. App Control gives the ability to lock down trusted tools like PowerShell without interrupting necessary operations.
The Carbon Black team who created this lab environment needs to allow unapproved PowerShell script executions via PowerShell. They want to limit this to a specific path, C:\cbappcontroldemofiles and only allow this for local administrators.
What would you suggest to the team in this scenario?
Creating an Execution Control custom rule resolves the given scenario. Execution control offer administrators flexible customizability on how applications, files, and or users/groups interact. For example, you can create an Execution Control rule that allows only users in the 'Developers' group to run .dll files using a development tool like Visual Studio.
In the App Control console we have already created a custom execution rule called 'PowerShell Usage for App Control Lab' for this use case. This rule allows PowerShell script executions by PowerShell at the previously mentioned path, and only for local administrators.
6.3. File Integrity Control/Monitoring
This activity will custom rules specific to FIM/FIC. For more information on custom rules see Section 3.2.3.
VMware Carbon Black App Control has the capabilities to perform File Integrity Monitoring and Control (FIM/FIC).
Consider an important file that you wish to track access/changes. In this scenario we have included such a file, sales.xls, on the App Control device desktop. This file is one we wish to monitor but not restrict changes to.
Before we test this scenario, let's take a look at the FIM rule that has been created within this App Control Server.
- Login to the App Control console. For information on accessing the console see Section 1.2.
- From the top menu, click 'Rules' to expand available options, then select 'Software Rules' from the dropdown
- On the Software Rules page, click the 'Custom' tab to view custom rules
- View the FIM - sales.xls rule
This rule will report any changes (writes, deletes, renames, etc.) to the sales.xls document. After testing this rule we will view the generated event reports in the App Control console.
Let's now make a change to the sales.xls document.
- Open the sales.xls spreadsheet document
- Edit a cell (or cells) and save the file
Now that we have made a change to our monitored document, let's view the report in the App Control console.
- In the App Control console, click the 'Reports' tab from the top menu to expand options, then select 'Events'
The Events page shows all recorded events App Control collects, including blocks, files executed, actions by console admins, and more. This data can be searched and filtered through to find relevant information - and any searches can be saved for future reuse (Saved Views).
In this lab we've created a saved view for the FIM use case called 'FIM by User'. This view looks for the custom rule report on the sales.xls file, and also groups events by editing user (within the last day).
- Select the 'FIM by User' view to view file change events
- Expand your username to view the event related to the change (or changes) you made to sales.xls
Another way to visualize events (and see reports from our custom rule) is in a Dashboard. App Control admins can create and customize dashboards, share them across console members, and even add them to the home page. A dashboard consists of a series of portlets, each of which provides summary information or controls that can help you manage the security of your computers and the files on them.
In this lab we have already created a dashboard for our sales.xls FIM use case.
- In the App Control console, from the top menu, click the 'Reports' tab to expand options then select 'Dashboards'
- On the dashboard page, click the dashboard name 'FIM Sales .xls' to view
As with the rest of the App Control solution, dashboards offer admins a great deal of flexibility. Dashboards can combine multiple portlets - all of which can be customized by chart type, filtered by certain data, and much more. If this was a very valuable chart that admins were constantly checking it may be useful to add to our homepage.
In the previous section we completed an activity on a monitored file that reports changes. What if we want to control (and prevent) users from editing a specific document(s)? We can use another custom File Integrity Control rule - but this time block changes.
In this scenario we have included such a file, salary.xls, on the App Control device desktop. This file is one we wish to restrict changes to - we don't want any user to be able to change important company salary data!
Before attempting to change our protected file, let's view the correlating FIC rule in the App Control Console.
- On the Software Rules page, click the 'Custom' tab to view custom rules
- View the FIC - salary.xls rule
This rule will restrict any changes (writes, deletes, renames, etc.) to the salary.xls document.
Let's now attempt to make a change to the salary.xls document.
- Open the salary.xls spreadsheet document
- Edit a cell (or cells) and save the file
- You will receive a notification from App Control that this has been blocked, click okay once notifications have appeared to dismiss
Now that we have attempted to modify our controlled document, let's view the report in the App Control console.
- In the App Control console, click the 'Reports' tab from the top menu to expand options, then select 'Events'
In this lab we've created a saved view for the FIC use case called 'FIC by User'. This view looks for the custom rule report on the salary.xls file, and also groups events by editing user (within the last day).
- Select the 'FIC by User' view to view file change events
- Expand your username to view the event related to the attempted change (or changes) you made to salary.xls
7. Additional Resources
- App Control Activity Path: https://carbonblack.vmware.com/carbon-black-app-control-activity-path
- App Control Documentation: https://docs.vmware.com/en/VMware-Carbon-Black-App-Control/index.html
- App Control Video Demo: https://via.vmw.com/tchz24b2b1d7no3048
- Carbon Black Cloud Malware Lab: https://kb.vmtestdrive.com/a/1552312-vmware-carbon-black-cloud-malware-lab
- Carbon Black EDR Lab: https://kb.vmtestdrive.com/a/1562070-threat-hunting-with-carbon-black-eedr-phishing-turned-into-ransomware
- Carbon Black Workload Lab: https://kb.vmtestdrive.com/a/1552314-introduction-to-carbon-black-cloud-workload
- Carbon Black Container Lab: https://kb.vmtestdrive.com/a/1552310-securing-modern-applications-with-cbc-container-security
- Carbon Black XDR Lab: https://kb.vmtestdrive.com/a/1655218-threat-hunting-with-carbon-black-xdr-phishing-turned-into-ransomware