Secure Carbon Black Cloud updates
Introduction
- Update of the security product
- Update of the security policy
To use a real-world example, I am going to use the Carbon Black Cloud for a company with 30,000 computers running Windows OS (Operating System).
Create groups of sensors
Because you probably want to test some malware, you first need to test on an isolated virtual machine (isolated from production, but with Internet access), then on a real machine using the base image of Windows used in your company.
In your company, your neighbors and people in your department are good candidates to be beta testers, you will receive quick feedback.
Then because all entities of your company use different software, try to identify testers, it may be the most difficult part, but it is important, HR (Human Resources), sales and dev teams use different tools and have different constraints.
And finally, create 4 to 10 groups of computers to update progressively.
Table 1: Group of sensors
|
Number of computers |
Team |
Usage |
|
1 or 2 |
VMs (Virtual Machines) isolated from other computers but with Internet access |
Malware testing |
|
1 or 2 |
Laptop with company’s standard configuration |
OS compatibility testing |
|
10 to 100 |
Security or IT (Information Technology) team |
Day to day usage testing |
|
100 to 200 |
Various beta testers in all departments |
Compatibility with specific applications testing |
|
10 groups of 3000 |
10 big Groups of computers in production in chunks of 10% of total computers |
Production, and securely update of no more than 10% of computers. |
Carbon Black Cloud sensor version
The version number of Carbon Black sensor, is made of 4 numbers:
- “Major.Minor.Revision.Build”
As of today (3/27/2023), VMware Carbon Black Cloud propose 6 versions of Carbon Black Cloud sensor to download:
- 3.9.1.2464 (latest)
- 3.9.0.2357 (latest in minor branch 3.9.0)
- 3.8.0.722 (latest in major branch 3.8)
- 3.8.0.684
- 3.8.0.627
- 3.8.0.535
Windows Sensors Support is available in VMware Docs.
Table 2: Windows Sensors support as of 3/27/2023
|
Release |
Enter Standard |
Enter Extended |
Enter End of Support |
|
3.9 |
January 2023 |
||
|
3.8 |
January 2022 |
July 2023 |
January 2024 |
Because the Carbon Black version 3.9 is still in constant development, and introduces new features in new versions, I would recommend using the latest version of the major release 3.8 in production, and to test the more recent versions on beta testers computers to prepare a complete upgrade of the computer fleet in 3.9 release before January 2024.
If you need a bugfix or a recent feature only available in release 3.9, I recommend carefully reading all release notes before upgrading and using the latest minor branch version.
It applies to Carbon Black and to all software products in general.
PRO TIP: Do not update anything (Firewall, software, antivirus…) the day before your weekend/holidays, trust me!
PRO TIP2: If your company has a seasonal business, and for example your company is selling products for Christmas, do not update the two weeks before Christmas.
Security policy version
Test rule
If you are using Carbon Black, you are lucky, because you can test a new security rule based on all events recorded during the past 30 days!
Smooth policy update
I do not recommend changing a policy applied to 30,000 computers directly without testing!
Update policies for various sensor groups according to the following table.
Table 3: Policy versions
|
Number of computers |
Team |
Usage |
Policy version |
|
1 or 2 |
VMs isolated from other computers but with Internet access |
Malware testing |
Policy #n |
|
1 or 2 |
Laptop with company’s standard configuration |
OS compatibility testing |
Policy #n |
|
10 to 100 |
Security or IT team |
Day to day usage testing |
Policy #n-1 |
|
100 to 200 |
Various beta testers in all departments |
Compatibility with specific applications testing |
Policy #n-2 |
|
10 groups of 3000 |
10 big Groups of computers in production in chunks of 10% of total computers |
Production, and secure update of no more than 10% of computers. |
Policy #n-3 |
Policy versions comparison
Each time you want to change a rule in your security policy, duplicate the latest policy, and increment the version number or use the date in the policy name.
For example, if the current corporate policy is #22, and you want to block PowerShell in a new policy #23.
You can use cbapi-qt-demo open-source tool (C++) to compare policies #22 and #23 before applying to the first group of 3000 computers (10% of 30,000 in my example).
And do not to forget to check in “Audit Logs” who did change the security policy if you find unwanted changes.
I recommend building the latest version on Ubuntu, but an old version for Windows is available too if needed.
On the left, we have the security policy #22, and on the right the policy #23.
Using a tool to visualize the difference between two text files (gvimdiff in the screenshot), we can easily see that policy #23 adds a rule to block PowerShell, and there is no other difference between both policies.
Conclusion
VMware Carbon Black security policy update process is more secure than other security products because:
- you can test a new rule against the event’s history of the last 30 days.
- you can compare security policies with each other.
Author
- Stephane List, Staff Technical Marketing Manager at VMware Carbon Black
Additional Resources:
To learn more about Carbon Black APIs (Application Programming Interface), Python API framework, and open-source tools available:
- Carbon Black Developer Network
- cbapi-qt-demo GitHub repository