Access official resources from Carbon Black experts
Advanced Search
IMPORTANT ANNOUNCEMENT: On May 6, 2024, Carbon Black User eXchange (UeX) and Case Management will move to a new platform!
The Community will be in read-only mode starting April 19th, 7:00 AM PDT. Check out the blog post!
You will still be able to use the case portal to create and interact with your support cases until the transition, view more information here!
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
Create a specific Policy for the software developers (i.e., Development)
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"
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.
