Just Published! Threat Report: Exposing Malware in Linux-Based Multi-Cloud Environments | Download Now

Carbon Black Cloud: Policy Recommendations for Developer's Workstations and Build Servers

Carbon Black Cloud: Policy Recommendations for Developer's Workstations and Build Servers

Environment

  • Carbon Black Cloud Console: All Versions
  • Carbon Black Cloud Sensor: All Versions
  • Microsoft Windows: All Supported Versions
  • Apple macOS: All Supported Versions

Objective

  • Provide guidance on configuring Policies and Policy Rules specifically on Developer's workstation and Software Build Servers

Resolution

  1. Create a specific Policy for the software developers (i.e., Development)
  2. In the Development policy, add Permissions Rules (When an application at path > Tries to perform any operation > BYPASS)
    Specify the directory path location of the work directories, for example
    "**\Program Files\Tomcat\tomcat_taskspace\work\Catalina\localhost\**\*.class"
  3. Assign necessary endpoint devices to the policy

Additional Notes

  • Permissions Rules should always be a specific as possible, as each one represents a security hole where you are blind to activity in the specified path.
  • Bypass rules (Permission Rules where the Action is Bypass) should be used sparingly, as all activities originating from the specified path will be ignored and will not be searchable.
  • Developer's workstation and Software Build Server will often execute a lot of applications with the NOT_LISTED reputation.  By nature, developer and software build processes are creating brand-new software that has not been observed in the wild.  These freshly-minted applications will most likely obtain NOT_LISTED reputation from the cloud.  Often the build tools (such as compilers and linkers) have to create intermediate files in the software creation process.  It is recommended to setup a policy to bypass the working directories that are used by such developer tools.  This practice will avoid unnecessary policy enforcement  and reduce overhead of scanning/hashing intermediate files and executables.
  • Use of single wildcard characters (*) matches one or multiple characters within the same directory level. Use of double asterisk (**) matches one or multiple directory levels.
  • This technique should only be used for the software development systems and the locations of their working directories. Beware not to expand the bypass area to unrelated areas as this poses security risks. Should malware find its way into these directories, they would not be detected.

Related Content


Was this article helpful? Yes No
75% helpful (3/4)
Article Information
Author:
Creation Date:
‎09-02-2020
Views:
3901
Contributors