AWS Partner Network (APN) Blog
Integrating Third-Party Solutions to AWS Config Rule Evaluations
By Jose Obando, Security Trans Consultant at AWS
This post aims to assist you on deploying a set of custom AWS Config Rules that leverages third-party REST APIs (Qualys and Trend Micro in this example) to evaluate Amazon Web Services (AWS) resources in an automated fashion.
The AWS Config evaluations represented in this guide show the reporting status of Amazon Elastic Compute Cloud (Amazon EC2) instances against TrendMicro and Qualys.
AWS Config continuously monitors and records your AWS resource configurations, and allows you to automate the evaluation of recorded configurations against desired configurations. Sometimes these desired configurations require customers to evaluate third-party solutions that do not reside within the AWS services.
Using the Rule Development Kit (RDK) and AWS services such as AWS Config, AWS Secrets Manager, and AWS Key Management Service (KMS), we can orchestrate these evaluations and have a single repository for compliance evaluation.
The code provided along with this post requires you to have administrator access to multiple services, and each has a step-by-step setup process in this guide.
In order to make the most of this guide, it’s recommended you know basic Python and understand some programming concepts such as functions and variables.
Important dependencies and potential blockers include the fact you’ll need a minimum set of AWS permissions to use RDK, Secrets Manager, or KMS. These are documented in the resources section at the end of this post.
Use Cases and User Stories
The code used in this guide shows you how to integrate a third-party REST API that requires XML structures while leveraging AWS’s own APIs that use JSON structures.
The concept behind this walkthrough is that multiple services can be integrated into AWS Config to generate a custom evaluation, regardless of whether they’re part of the AWS services or not.
User stories:
- “As a security analyst, I would like a way to define AWS Config Rules so that I can get a concise view/report that shows me an asset’s compliance status based on my organization’s security standards.”
- “As a security manager, I’d like a single place that offers a simple view my peers and I can use to review which resources we have on AWS and their current status against our multiple security solutions.”
High-Level Architecture and Design
To deploy this or similar rules, you will need to have the RDK installed in your development environment and deployed on your AWS account.
For example, the code in this guide was created with the following command:
rdk create <NAME_OF_RULE> --runtime python3.7 --maximum-frequency TwentyFour_Hours
Download the Rules and Edit According to Your Environment
To get started, download the rules from the attached .zip files:
For the Trend Micro Rule
The code provided here is for self-managed Deep Security. You’ll want to update the URL variable to point to your Trend Micro installation.
If you deployed through AWS Marketplace, you can see the URL in the Outputs Tab of your AWS CloudFormation stack.
For the Qualys Rule
The Platform variable defines your current Qualys API server.
Examples may include:
- qualysapi.qg2.apps.qualys.com
- qualysapi.qg3.apps.qualys.com
- qualysapi.qg4.apps.qualys.com
See your Qualys documentation to know which Qualys API server to use. This can be found on page 72.
Deploy the Rules Using RDK
Make sure the RDK is configured on your account. You can check this by running the rdk init command:
Next, make sure you’re on the directory where your RDK Rule folder is. If the RDK Rule Folder is named TESTRule then it should look like this:
To deploy the rule, use the rdk deploy command:
Create the KMS CMK to Protect Your Secrets
To make API calls, you will need credentials for each third-party service. This new KMS key will be used to encrypt/decrypt your third-party credentials.
Go to KMS in your AWS Management Console and select Create Key. In this example, I have created a symmetric key with KMS-generated key material:
You will need to specify an alias for the key, and fill out the other information as necessary.
Next, you need to specify a key administrator. This will be the user that has admin access over the key itself.
Now, specify access to use the key by adding the role for the AWS Lambda functions used in AWS Config to the list of key users. You can get these by typing the name of the rule without any spaces or special characters.
For example, for your rule named Service_Name_Of_Rule, you would use the role starting with “ServiceNameOfRule.”
Create Secrets in AWS Secrets Manager
Next, you will create a secret in AWS Secrets Manager. This is where our third-party API credentials will be stored.
From the Secrets Manager console, select Store a New Secret. Once you’re in the new secret page, select Other Type of Secrets.
In this example, I am using the following key/value structure for Qualys credentials:
| Secret Key | Secret Value |
| qualys_usr | thisisyourusername |
| qualys_pswrd | YOUR_API_PASSWORD |
Once the secrete has been created, the console view should look similar to the following example.
Next, select your previously-created customer managed key.
We are naming this Secret “QualysCredentials.” If you decide to name it differently, you will need to update the code accordingly (line 246).
Repeat these same steps for the Trend Micro credentials.
For Trend Micro we’re using an “apiKey” key and the string as the value.
| Secret Key | Secret Value |
| apiKey | D5C29B86-39E6-6512-BD7D-F1CACD67E2CE:QRX2plV4EPh5J3E1OlOVlV71fAIpwlpOPO1Mbh611jY= |
The secret should look similar to the following example.
Create an IAM Policy That Allows Access to Secrets
This AWS Identity and Access Management (IAM) policy will be attached to the Lambda roles for the two AWS Config Rules.
From the IAM console, choose Policies on the left side panel and then click Create Policy.
Select the JSON tab, and modify the following policy with the correct Amazon Resource Name (ARN) for each secret.
Click on Review Policy at the bottom of the page, and then name the policy accordingly. We’re naming ours “RetrieveSecretsForThirdPartyConfigRules.”
Finally, click on Create Policy to create the IAM policy.
Assign IAM Policy to Lambda Roles for Secret Retrieval
To assign your Lambda, select Roles from the IAM console.
Then, click on the search field and use your rule’s name without any special characters or spaces. For example, for your rule named “Service_Name_Of_Rule,” use the role starting with “ServiceNameOfRule.”
Click on your role, and then select Attach Policies from the new page that loads.
Search for the role we created previously and mark the checkbox on the left side of the search results.
Click on Attach Policy at the bottom of the page.
Review Results
Review the AWS Config console and click on your rule name. You’ll need to click on Re-evaluate since access to the secrets was not given at the time of deployment.
You can click on a specific resource and see which rules are compliant or non-compliant.
You could potentially have multiple agents running on an instance and query the control plane of that third-party to validate the agent is running and reporting accordingly.
Summary
Using the tools and methods described in this post, you can securely store credentials in AWS Secrets Manager and authenticate against third parties. You can also pull that information into AWS Config and leverage features such as “Configuration History” to track compliance of a resource over time.