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.

This is a community project and while you will see contributions from the Deep Security team, there is no official Trend Micro support for this project. The official documentation for the Deep Security APIs is available from the Trend Micro Online Help Centre.

Tutorials, feature-specific help, and other information about Deep Security is available from the Deep Security Help Center.

For Deep Security specific issues, please use the regular Trend Micro support channels. For issues with the code in this repository, please open an issue here on GitHub.

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.

1. Create a new Role with a unique, meaningful name (Administration > User Manager > Roles > New...)
2. Under "Access Type", check "Allow Access to web services API"
3. Under "Access Type", uncheck "Allow Access to Deep Security Manager User Interface"
4. 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
5. 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)
6. On the "User Rights" tab, ensure that "Change own password and contact information only" is selected
7. On the "Other Rights" tab, ensure that the default options remain with only "View-Only" and "Hide" assigned as permissions

1. Create a new User with a unique, meaningful name (Administration > User Manager > Users > New...)
2. Set a unique, complex password
3. Fill in other details as desired
4. Set the Role to the role you created in the previous section.

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.

For each of these rules, the AWS Lambda configuration is the same. Please make sure to configure the following;

• Handler: filename_for_the_rule.aws_config_rule_handler
• Role: a role with at least the rights as shown in dsConfigRulePolicy.json. Remember to change line 18 to reflect your S3 bucket information (BUCKET/PATH/TO/OBJECTS/*)
• (Advanced Settings) Memory: 128 MB
• (Advanced Settings) Timeout: 3m 0s

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 the rule to be considered compliant.

Lambda handler: dsIsInstanceProtectedByAntiMalware.aws_config_rule_handler

During execution, this rule sign in to 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.

Lambda handler: dsIsInstanceProtectedBy.aws_config_rule_handler

During execution, this rule signs in to 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.

Lambda handler: dsDoesInstanceHavePolicy.aws_config_rule_handler

During execution, this rule signs in to 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).

Lambda handler: dsIsInstanceClear.aws_config_rule_handler

During execution, this rule signs in to 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 its role-based access control to provide access to its 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:

1. hard-code the credentials inside the AWS Lambda function
2. pass the credentials to the function (current method)
3. 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 significant 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) and significantly reduces the possibility of the credentials leaking out. 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).

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.

See Protecting Your Deep Security Manager API Password below for instructions on how to implement option #3.

If you're feeling nervous about having a plaintext password in your rule configuration, this section will help you get set up with an encrypted password.

You may have noticed that the rules give you the option to specify your password as a string or URI, and that there are optional parameters for specifying an encryption key and an encryption context, each of which can also be provided as string or URI.

We won't try to cover all of the concepts involved here in great detail, but we will give you just enough to be dangerous. If you want to learn more, the AWS Key Management Service documentation is the best place to start.

In the AWS Key Management Service (AWS KMS), you create a Customer Master Key. This master key remains securely stored by AWS KMS, and can be used to generate data keys that are then used to encrypt individual data items, in this case your password. The encrypted data key is normally stored alongside the encrypted data. You can also optionally provide an encryption context to allow more fine-grained access to the encrypted data.

If you provide encryption context, you should provide the key-value pairs as a JSON object, like this:

{ "key1": "value1", "key2": "value2" }

If you provide an password encryption key, the rule will first call AWS KMS to decrypt the password encryption key, and will then decrypt the password. If you have provided an encryption context, that information will be provided when decrypting your password encryption key.

AWS S3 is a great place to keep your encrypted password and encrypted password key. To do this, simply provide the S3 URI to the objects when you're specifying the rule parameter values. For example:

If you want to keep the encryption context separate, you can put the value directly into the rule parameters as a JSON string:

There are some tools in the tools directory that will help you create and verify an encrypted password and an encrypted password key.

IMPORTANT: Make sure that the IAM role assigned to your rule has permissions to read the S3 bucket and objects, and also to access the KMS Decrypt API and the key.

ALSO IMPORTANT: The entire set of configuration rule parameters must be less than 256 characters when encoded as JSON.