12 Aug 2020 10:40 AM
For dynatrace node components like Cassandra and Nginx. Is it possible to apply CIS hardening benchmark on the said component., also is there any additional security components that configure during the installation.
Solved! Go to Solution.
18 Aug 2020 10:56 AM
From the product security team's side I can say, that we haven't been looking into CIS hardening benchmarks as of now.
@Radoslaw S., do you know if someone from the Managed team has been looking into this?
14 Jun 2021 11:04 AM
Hi, we're running our most secure environments on RHEL-based hardened OS with CIS benchmark level 1. This is achievable for any customer. We're pretty good out-of-the-box for Nginx. For Cassandra and Elasticsearch (similar as Cassandra) it needs some more explanation. Find some answers to common security requirements related to Cassandra below:
1. Ensure a separate user and group exist for Cassandra
All Cassandra configuration files are automatically put in place by the Dynatrace Managed installation scripts.
Dynatrace managed creates a dedicated user "dynatrace" in group "dynatrace" that is used for Cassandra. The user dynatrace is non-privileged service user (no console) and is not used for anything other than Dynatrace Managed.
While it is not solely for Cassandra, the usage is limited to Dynatrace Managed services, which form an integrated suite. Since we manage these services and dependencies between them, single user for Dynatrace Managed is necessary.
2. Ensure that authentication is enabled for Cassandra databases
Dynatrace Managed Cassandra nodes don't have authentication and authorization enabled. Dynatrace Managed mitigates that risk by automatically putting IP table rules (firewall rules) in place, which make sure that only Dynatrace server nodes are able to access the Cassandra port on the Cassandra nodes. Cassandra is used only by Dynatrace Managed internally.
Dynatrace is currently implementing a new storage system where authenticaion to databases is on the must have requirements list. This is a long term project though with no scheduled release date yet.
3. Ensure that authorization is enabled for Cassandra databases
Same as (2)
4. Ensure the Cassandra and superuser roles are separate
Same as (2)
5. Ensure that the default password changed for the Cassandra role
Same as (2)
6. Ensure there are no unnecessary roles or excessive privileges
Same as (2)
7. Ensure that Cassandra is run using a non-privileged, dedicated service account
As explained in (1), we create a non-privileged service user for Dynatrace Managed that is used for Cassandra.
8. Review User-Defined Roles
Same as (2)
9. Review Superuser/Admin Roles
Same as (2)
10. Ensure that auditing is enabled
Until version 4.0 is announced for Cassandra OpenSource.
Dynatrace is scanning all third party components (including Cassandra) for vulnerabilities (CVEs) using its own AppSec solution.
11. Inter-node Encryption
Dynatrace Managed Cassandra nodes don't have inter-node or client encryption enabled due to potential performance overhead. To mitigate the risk, the Dynatrace Managed server infrastructure needs to be hardened on the OS and network level by the customer, to ensure only authorized personnel can access cluster nodes. For cases where there is a risk of intercepting the traffic traffic between cluster nodes, we recommend external encryption means (IPSec tunnels or hardware encryption)
12. Client Encryption
We currently don't support client encryption for Cassandra. Dynatrace Managed nodes are intended to operate in secured, internal network. Communication with Cassandra is only within Dynatrace cluster. For cases where there is a risk of intercepting the traffic between cluster nodes, we recommend external encryption means (IPSec tunnels or hardware encryption)