Critical Infrastructure Deployment Considerations

Introduction

In order to be successful in the implementation of any security solution it is important that you assess your roll out strategy, timeline for implementation, as well as communication strategies.

Overview

Review this resource to follow a phased approach to deploying onto your critical assets. 

This guide should be used for critical servers, developer machines or anything with additional sensitivities. This guide is not intended for standard systems as the default roll out into Standard will be appropriate.

This resource does not cover best practices for adding and testing new blocking and isolation rules, review blocking and isolation best practices under the Optimize tab in Tech Zone to assist in developing a workflow to refine policy rules.

Roll Out Considerations

To determine your roll out strategy it is important to ask a few questions to determine your end goal.

  1. Are you intending to replace or coincide with your pre-existing antivirus/security solution?
  2. Are there environments you manage with higher levels of sensitivity? i.e. Critical Servers, Developers?
  3. What level risk aversion does your organization allow for security?

Pre-Existing Security Solutions

To begin the roll out of VMware Carbon Black Cloud, you will need to prepare for co-installation and/or the migration of your existing security solution.

Pro-Tip: Most Carbon Black Cloud (CBC) customers will co-install Carbon Black with their existing solution initially. Once fully deployed and protection level is adequate with the CBC they will then remove the previous security solution entirely.

Installation of two security products can cause performance issues if not properly excluded. Exclusions should be made in both CBC and the other security vendor.

Environmental Sensitivity

Installing a new security solution can cause conflict and/or concerns within your organization, most organizations will build roll out plans incorporating strategies for different groups within the organizations. Performance and uptime on these systems will often be the primary focus for a successful roll out.

Pro-Tip: Most CBC customers will create a group for the sensitive or unique needs groups and implement at a different pace than other organizational groups. i.e. Developers and Critical Servers are groups often treated with the highest level of sensitivities.

Risk Aversion

Your level of risk aversion will determine the speed in which you will be able to implement a security solution. For minimal / no disruption you will want to build a timeline that allows for adequate baselining of your enterprise. For organizations with executive buy-in can implement on an accelerated timeline and manage ad hoc fixes as they arise.

Pro-Tip: Common implementation timelines range from 3 months to 1 year based on desired implementation speed.

 

Based on the answers to the previous questions this will impact the speed in which you move between phases.

 

Phase 1: Initial Deployment

Policy Creation

Due to the sensitivities of your systems and overall risk aversion of your corporation it is important to start with the policy most in line with those needs. For the purpose of securing your critical infrastructure and desiring to make no impact to your systems we will start with the duplication of the Monitored policy.

Note: The Monitored policy does not apply any blocking within your environment so you are removing prevention variables and focused on performance optimization.

Start by duplicating a pre-existing policy.

Graphical user interface, text, application</p>
<p>Description automatically generated

Ensure you are selecting the desired Target Value for your new policy.

Default selection should be Medium.

Once the new policy is duplicated edit the new policies settings.

Local Scan Settings

Disable local scan setting.

This will ensure we are not downloading the local .dat file of known bad signatures and we are able to focus in on performance optimization first.

Sensor Settings

The recommendation for critical or sensitive systems is to deselect the setting options.

Graphical user interface, text, application, email</p>
<p>Description automatically generated

Optional settings:

Use Windows Security Center | Select if you are deploying onto Windows systems with Microsoft Defender running. This allows Security Center to recognize Carbon Black as an Anti-Virus provider.

Display Sensor Message in System Tray | Select if you want your users to have a local Carbon Black UI. Most customers choose to either hide the system tray OR if enabled they will add Help Desk contact information for reference.

Require Code to Uninstall Sensor | Select this option if you want to ensure your users are not able to uninstall the Carbon Black sensor.

Enable Live Response | Select this option if you want the ability to remote into the system while working through the implementation process.

Once the settings are configured navigate to the Prevention tab and configure permissions for any of your pre-existing security solutions.

Prevention Settings

The key to success when deploying a kernel level filter driver is to identify other kernel modules co-existing on the system and ensuring that there are proper exclusions.

Common examples include Antivirus, and Data Loss Prevention Tools.

Pro Tip: Run fltmc in a local cmd interpreter to identify all kernel drivers

For detailed information on Anti-Virus exclusions, visit: https://community.carbonblack.com/t5/Knowledge-Base/Carbon-Black-Cloud-How-to-Set-up-Exclusions-in-the-Carbon-Black/ta-p/42334

Graphical user interface, text, application, email</p>
<p>Description automatically generated

With the above steps complete, let’s now move onto Device Segmentation.

 

Device Segmentation

Segmenting your devices will allow for you to have greater control around the organization of your assets.

Navigate to Inventory > Sensor Groups > Select ‘Add Group’

Graphical user interface, application</p>
<p>Description automatically generated

Criteria can be applied on a variety of settings with ‘any’ or ‘all’ criteria.

Note: you can create multiple groups and apply them to the same policy, but will allow you to apply new policies with refined permissions and rules as you continue through the implementation procedure.

Ensure you apply these sensors to your newly created policy from the section above.

If you created multiple groupings, select ‘Reorder Groups’ to move the groups in order of preference as the groupings will apply from the top down based on matching criteria.

Graphical user interface, text, application</p>
<p>Description automatically generated

Recommendation is to order from most to least specific.

 

Deploy your Sensors

Once you are complete with the above sections you are now ready to deploy your Carbon Black sensors to your critical assets via your deployment tools.

Once deployment is completed monitor your systems performance for your desired period of time, then move onto Phase 2: Initiate Background Scan.

Be sure to review alerts surfaced on these devices. If any issues arise review Troubleshooting: Configuration vs. Interoperability for Endpoint Standard for best practices on resolving any potential interoperability  issues.

Phase 2: Initiate Background Scan

In order to start replacing your Anti-Virus you will want to start by performing a background scan on your systems to ensure there is nothing pre-existing on these systems.

Navigate to Enforce > Policies > Your Policy > Sensor Settings

Enable ‘Run Background Scan’ in Standard Mode.

Graphical user interface, text, application, email</p>
<p>Description automatically generated

The background scan will perform a low and slow background crawl of the system to identify malicious pre-existing files.

Note: you are still in a Monitored only policy, no action will be taken on these files. Alerts will be generated on anything malicious found.

You have the option to store a DAT file locally on your system to allow for offline malware signature look up. This will also increase the speed in which a file is deemed malicious by having this file locally.

Navigate to Local Scan Settings and set to Enabled and Normal.

Graphical user interface, application</p>
<p>Description automatically generated

Allow for 48-hours+ to complete your background scan before moving onto Phase 3: Enable Delay Execute.

Be sure to review alerts surfaced on these devices.

If any issues arise review Troubleshooting: Configuration vs. Interoperability for Endpoint Standard for best practices on resolving any potential interoperability issues.

 

Phase 3: Delay Execute

To complete the configuration phase you will enable ‘Delay execute for cloud scan’.

Graphical user interface, text, application, email</p>
<p>Description automatically generated

Once this is complete, it is recommended to baseline for your desired period of time you are ready to build blocking and isolation rules to begin layering in the prevention.

 

Summary and Additional Resources

When it comes to critical infrastructure it is important to take a stair step approach to securing these environments. We have broken out the experience into 3 phases to ensure minimal disruption.

  1. Phase 1: Create Custom Monitored Policy
  2. Phase 2: Enable Background Scan
  3. Phase 3: Delay Execute for Cloud Scan

Completing these 3 phases should result in the following policy configurations:

General

Prevention

Local Scan

Sensor

Target Value: Medium +

Permissions Rule: Exclude AV and other security products

Blocking and Isolation: None

On-Access File Scan Mode: Normal

Allow Signature Updates: Enabled

Run Background Scan: Standard

Delay Execute for Cloud Scan

Optional:

  • Use Windows Security Center
  • Display Sensor Message in System Tray
  • Require Code to Uninstall Sensor
  • Enable Live Response

 

At this point there are no prevention rules in place and this is a critical step to ensure the newly deployed endpoints have appropriate prevention strategies. It is also a continuous process that is needed to create new security measures for the ever-changing threat landscape without affecting the day-to-day functions or creating unnecessary blocks.  

 This resource does not cover best practices for adding and testing new blocking and isolation rules, review blocking and isolation best practices under the Optimize tab in Tech Zone to assist in developing a workflow to refine policy rules.

 

Additional Resources

For more information, you can explore the following resources:

Changelog

The following updates were made to this guide:

Date

Description of Changes

2021/11/11

  • Guide was published.

Feedback

Your feedback is valuable.

To comment on this paper, contact VMware Security Business Unit Technical Marketing at SBU_tech_content_feedback@vmware.com .

 

 

 

 

Associated Content

From the action bar MORE button.

Filter Tags

VMware Carbon Black Cloud Endpoint Standard Document Best Practices Advanced Optimize