A set of AWS Config Rules to help ensure that your AWS deployments are leveraging the protection of Deep Security. These rules help centralize your compliance information in one place, AWS Config.
Deep Security has a strong role-based access control (RBAC) system built-in. In order for these AWS Lambda functions to query Deep Security, they require credentials to sign in.
Here's the recommend configuration in order to implement this with the least amount of privileges possible within Deep Security.
- Create a new User with a unique, meaningful name (Administration > User Manager > Users > New...)
- Set a unique, complex password
- Fill in other details as desired
- Create a new Role with a unique, meaningful name (Administration > User Manager > Roles > New...)
- Under "Access Type", check "Allow Access to web services API"
- Under "Access Type", uncheck "Allow Access to Deep Security Manager User Interface"
- On the "Computer Rights" tab, select either "All Computers" or "Selected Computers:" ensuring that only the greyed out "View" right (under "Allow Users to:") is selected
- On the "Policy Rights" tab, select "Selected Policies" and ensure that no policies are selected (this makes sure the role grants no rights to user for any policies)
- On the "User Rights" tab, ensure that "Change own password and contact information only" is selected
- On the "Other Rights" tab, ensure that the default options remain with only "View-Only" and "Hide" assigned as permissions
With the new User and new Role in place. Make sure you assign the Role to the user. This will ensure that your API access has the minimal permissions possible which reduces the risk if the credentials are exposed.
Checks to see if the current instance is protected by Deep Security's anti-malware controls. Anti-malware must be "on" and in "real-time" mode for rule to be considered compliant.
| Rule Parameter | Expected Value Type | Description |
|---|---|---|
| dsUsername | string | The username of the Deep Security account to use for querying anti-malware status |
| dsPassword | string | The password for the Deep Security account to use for querying anti-malware status. This password is readable by any identity that can access the AWS Lambda function. Use only the bare minimum permissions within Deep Security (see note below) |
| dsTenant | string | Optional as long as dsHostname is specified. Indicates which tenant to sign into within Deep Security |
| dsHostname | string | Optional as long as dsTenant is specified. Defaults to Deep Security as a Service. Indicates which Deep Security manager the rule should sign into |
During execution, this rule sign into the Deep Security API. You should setup a dedicated API access account to do this. Deep Security contains a robust role-based access control (RBAC) framework which you can use to ensure that this set of credentials has the least amount of privileges to success.
This rule requires view access to one or more computers within Deep Security.
Checks to see if the current instance is protected by any of Deep Security's controls. Controls must be "on" and set to their strongest setting (a/k/a "real-time" or "prevention") in order for the rule to be considered compliant.
This is the generic version of ds-IsInstanceProtectedByAntiMalware.
| Rule Parameter | Expected Value Type | Description |
|---|---|---|
| dsUsername | string | The username of the Deep Security account to use for querying anti-malware status |
| dsPassword | string | The password for the Deep Security account to use for querying anti-malware status. This password is readable by any identity that can access the AWS Lambda function. Use only the bare minimum permissions within Deep Security (see note below) |
| dsTenant | string | Optional as long as dsHostname is specified. Indicates which tenant to sign into within Deep Security |
| dsHostname | string | Optional as long as dsTenant is specified. Defaults to Deep Security as a Service. Indicates which Deep Security manager the rule should sign into |
| dsControl | string | The name of the control to verify. Must be one of [ anti_malware, web_reputation, firewall, intrusion_prevention, integrity_monitoring, log_inspection ] |
During execution, this rule sign into the Deep Security API. You should setup a dedicated API access account to do this. Deep Security contains a robust role-based access control (RBAC) framework which you can use to ensure that this set of credentials has the least amount of privileges to success.
This rule requires view access to one or more computers within Deep Security.
Checks to see if the current instance is protected by a specific Deep Security policy.
| Rule Parameter | Expected Value Type | Description |
|---|---|---|
| dsUsername | string | The username of the Deep Security account to use for querying anti-malware status |
| dsPassword | string | The password for the Deep Security account to use for querying anti-malware status. This password is readable by any identity that can access the AWS Lambda function. Use only the bare minimum permissions within Deep Security (see note below) |
| dsTenant | string | Optional as long as dsHostname is specified. Indicates which tenant to sign into within Deep Security |
| dsHostname | string | Optional as long as dsTenant is specified. Defaults to Deep Security as a Service. Indicates which Deep Security manager the rule should sign into |
| dsPolicy | string | The name of the policy to verify |
During execution, this rule sign into the Deep Security API. You should setup a dedicated API access account to do this. Deep Security contains a robust role-based access control (RBAC) framework which you can use to ensure that this set of credentials has the least amount of privileges to success.
This rule requires view access to one or more computers within Deep Security.
Checks to see if the current instance is has any warnings, alerts, or errors in Deep Security. An instance is compliant if it does not have any warnings, alerts, or errors (a/k/a compliant which means everything is working as expected with no active security alerts).
| Rule Parameter | Expected Value Type | Description |
|---|---|---|
| dsUsername | string | The username of the Deep Security account to use for querying anti-malware status |
| dsPassword | string | The password for the Deep Security account to use for querying anti-malware status. This password is readable by any identity that can access the AWS Lambda function. Use only the bare minimum permissions within Deep Security (see note below) |
| dsTenant | string | Optional as long as dsHostname is specified. Indicates which tenant to sign into within Deep Security |
| dsHostname | string | Optional as long as dsTenant is specified. Defaults to Deep Security as a Service. Indicates which Deep Security manager the rule should sign into |
During execution, this rule sign into the Deep Security API. You should setup a dedicated API access account to do this. Deep Security contains a robust role-based access control (RBAC) framework which you can use to ensure that this set of credentials has the least amount of privileges to success.
This rule requires view access to one or more computers within Deep Security.
If you're curious about the wisdom of storing access credentials in a 3rd party service...good. You've got your security hat on. Let's take a look at the risks.
Right now, Deep Security uses it's role-based access control to provide access to it's APIs (yes, a more elegant system is on the way). This means we need to provide our AWS Lambda functions with some way of getting a set of credentials.
Because Deep Security sits outside of the AWS IAM structure (a/k/a it's not an AWS service), we have the following options;
- hard code the credentials inside the AWS Lambda function
- pass the credentials to the function (current method)
- put the credentials somewhere else and provide access to that location to the function
Option #1 removes the credentials from AWS Config and moves them to AWS Lambda. This allows for the segregation of duties via IAM access to these services. In turn it creates a significance maintenance challenge in the event you change credentials.
Option #2 (current method) stores the credentials in AWS Config. Any user or role with sufficient privileges can access AWS Config and the stored credentials. This is the same situation as option #1 but doesn't present the same maintenance issue.
Option #3 would put the credentials in an alternative location (like S3 encrypted by KMS) reduces the possibility of the credentials leaking out significantly. Using IAM, you can ensure that only the Lambda execution role used for the function has access to the encryption key and the S3 key (object in the bucket). This solution has a lot more moving parts and is more difficult to configure.
In a discussion of option #1 vs #2, option #2 is the better choice as the maintenance issues presented by hard coding credentials are significant. If segregation is required, option #3 is far superior as it directly addresses the security issues of broader access to the credentials.
The risk posed by exposing the credentials to AWS COnfig can be partially mitigated by reducing the permissions that the credentials hold in Deep Security (see above, "Permissions In Deep Security"). However option #3 (storing the credentials in S3 and encrypting with KMS) is a much better option.
We will release guidelines on how to implement this solution shortly for situations when option #2 (which will remain the default) is insufficient.