Introduction
Cisco Vulnerability Management (CVM) formerly known as Kenna is a risk-based vulnerability management platform that helps individuals and organizations prioritize the large number of vulnerabilities present in their environments based on real-world risk to a much more manageable number of vulnerabilities. The CVM product has lots of features and capabilities to also help customers with their operationalization of the vulnerability management program.
One of the asks from customers is to be notified of new high severity vulnerabilities via email so they can better react to such vulnerabilities. Although the CVM platform has alerting features, this precise level of alerting is not possible now. We can however setup a system that provides this functionality by using a risk meter to track these new high severity vulnerabilities and some AWS Cloud services to handle alerting without the need to setup any mail server infrastructure.
In this guide, we will set up a system that checks for vulnerabilities in a CVM risk meter and sends an email alert via the Amazon Simple Notification Service (SNS) if any vulnerabilities are found. The logic will be setup in AWS Lambda and will be scheduled to run daily. While we can go into the setup of the relevant AWS services and roles, this would cause the article to be quite lengthy, so the detailed steps with relevant screenshots are provided in the PDF attachment found at the bottom of this page. In this article, we’ll be going through the setup of the risk meter within CVM, preliminary setup required within AWS and then a CloudFormation template to help the deploy be as seamless as possible.
As much as possible, services that are eligible for free tier are used in this guide. The main component that is guaranteed a cost is the use of AWS Secrets manager. At the time of this blog, the service cost is $0.40 per secret. This is used to store the CVM API token, and it is the recommended way to securely store and retrieve the token in AWS. Note that it is possible to avoid this cost by storing and using the API token as an environmental variable in the Lambda function, however, this is not secure and is available to be viewed as plain text within AWS.
High-Level Implementation Steps
Pre-requisites
- CVM Access – risk meter creation permissions and API access.
- An AWS account with privileges to use and configure the required services.
- Basic knowledge of getting around the AWS Console. Detailed steps and screenshots will be provided to assist with doing the preliminary configurations and setting up the CloudFormation job.
The high-level steps for setting up the system, using a CloudFormation template for the bulk of the AWS setup, is provided below.
- Within CVM, create the risk meter to track the desired metric. In this article, the use case is a daily alert for all new high severity vulnerabilities.
- Create a new SNS topic for the High Alert Vulnerability email. (The Lambda function will be granted permissions to publish to this topic within the CloudFormation template)
- Create a new secret in Secrets manager. (The Lambda function will be granted permissions to pull the secret within the CloudFormation template)
- Create an S3 bucket and store the provided Lambda layer ZIP file which has the relevant dependencies (Python ‘requests’ module) to make API calls from the Lambda function.
- Setup the CloudFormation stack using the attached CloudFormation template. Make tweaks depending on the desired scheduling of the Lambda function.
We would now go through each of these points in detail. Detailed screenshots are provided all through this blog to make the setup as seamless as possible.
- Within CVM, create the risk meter to track the desired metric
In this article, we are creating a risk meter to track newly created high severity vulnerabilities within the platform. We would be using the following query to search for all vulnerabilities having a score of 90 and above (adjust as required) which have been created within the last 24 hours.
vulnerability_score:>89 AND vulnerability_created:>now-24h
Below are screenshots of how this can be done from the VM (Explore) menu. You’ll need the risk meter ID when configuring the CloudFormation stack in AWS. The risk meter ID can be obtained from the reporting page of the newly created risk meter.
While this is the only use case we review here, there are lots of other use cases that can be beneficial e.g. tracking vulnerabilities that are going to be in SLA breach within a configured amount of time, risk accepted vulnerabilities that do not have a note on them, or may be missing a certain custom field, etc.
- Create a new SNS topic for the High Alert Vulnerability email.
Next, we would be creating an SNS topic within AWS. In summary, SNS uses a publisher / subscriber (pub/sub) model where all subscribers to a notification topic will be notified when a message is published to it. The Lambda function will be setup to publish to this topic whenever we have vulnerabilities in the risk meter created in step 1 and any emails subscribed to this topic will receive that email alert.
- Navigate to the Amazon SNS console.
- Click "Create topic".
- Choose "Standard" and provide a name (e.g., `HighVulnerabilityAlertTopic`).
- Click "Create topic"
Make a note of the ARN for this topic as we would need it when setting up our environmental variables in the Lambda function.
- Create a new secret in Secrets manager
Create a new Secret in the AWS Secrets manager service. We would be using this to store the API token from your CVM platform. Secrets are securely stored within this AWS service, and it integrates well with the Lambda service which means that they are also securely retrieved during execution. In the CloudFormation template, we will be providing the Lambda function with necessary permissions to access this secret.
Note that there is a cost associated with using this service. At the time of writing, the cost is $0.40/month for each secret stored. You can use environmental variables to store and retrieve this secret, however, this is not as secure as using the Secrets manager services.
- Navigate to the AWS Secrets Manager console.
- Click "Store a new secret".
- Choose "Other type of secret".
- Enter your secret key-value pair (e.g., `X-Risk-Token`).
- Name your secret (e.g., `RiskApiToken`).
- Click "Next" and follow the prompts to store the secret.
- Create an S3 Bucket and upload the Lamba layer ZIP file onto it.
The ‘requests’ Python module is used to initiate the API request and since this isn’t included in a Lambda environment by default, we have to make this available via the ‘Layers’ functionality. When setting up the CloudFormation Stack, we would be requested to provide a bucket that contains the Layer. In this step, we would be creating the S3 bucket (an existing bucket can be used) to store this ZIP layer file and would be providing the bucket details when setting up the CloudFormation stack.
- Navigate to the S3 AWS console
- Click on create bucket
- Minimal configuration is required – the only mandatory field is the bucket name.
- Scroll down and click on ‘Create bucket’
- Upload the provided ZIP file into the bucket using ‘Upload’ within the provided bucket.
Note: While the ZIP file containing the Lambda function's dependencies is provided, you can easily create your own. This would be especially useful in case at the time of review, there are significant updates to the Python modules. The steps to create this ZIP file are provided below.
- On your local machine, create a directory for your Lambda function and dependencies.
- Install the requests library into a python subdirectory and have it zipped and ready for uploading to a Layer for the Lambda function. Sample commands / code for preparing the zip file is provided below.
- mkdir my_lambda_function
- cd my_lambda_function
- mkdir python
- pip install requests -t python/.
- zip -r ../my_lambda_function.zip .
- Setup the CloudFormation stack using the attached CloudFormation template.
We would now be setting up the remaining AWS services to be used using CloudFormation. AWS CloudFormation is a service that enables you to model, provision, and manage AWS and third-party resources by treating infrastructure as code. Using CloudFormation templates, you can define your desired resources and their configurations in a text (.yml) file, which AWS CloudFormation then uses to automate the deployment and management of your entire infrastructure. This simplifies the process of setting up and maintaining AWS environments, ensuring consistent and repeatable deployments with minimal manual intervention. You’ll need a role for the CloudFormation service to perform its operations, so if that isn’t available, do consider setting it up before you start setting up the stack.
- Download the CloudFormation template in the attached. Review and possibly make edits like the schedule for the function to run, as well as role names which will be covered in a bit more detail below.
- Within the AWS Console, search for CloudFormation and click on ‘Create stack’ à ‘With new resources (standard)’.
- In the form, select ‘Chose an existing template’ and then ‘Upload a template file’. Navigate to the location of the file you downloaded earlier.
- Click on ‘Next’.
- You are then provided a screen to specify the task details which are required by the template file. If you use similar naming convention as shown in the screenshots below, then you would not need to make changes to the roles required. Review and configure as desired. The email endpoint is the email address that is to receive email notifications from the SNS service.
- Click on ‘Next’
- On the next page, specify the IAM role to execute the activities required for creating the resources and click on ‘Next’.
- On the next screen, review all the selections made for the stack, accept the acknowledgement and click on ‘Submit’.
- The CloudFormation service would proceed to setup the services required for the setup.
Verify that all the resources look to have been created properly by CloudFormation by navigating to the ‘Resources’ tab in the newly created stack and comparing with the screenshot provided below. You could also potentially test out the Lambda function to be sure it works as you anticipate. If you need to make changes to any of the parameters used by the Lambda function, you can find them under ‘Configuration’ and ‘Environmental variables’ as shown in the screenshot.
Attached are the CloudFormation template, the ZIP file which contains dependencies to be used by the Lambda function (instructions were provided earlier on how to create such a ZIP file), and a document that contains instructions of this setup without the use of CloudFormation service.
Conclusion.
Though the setup uses a few AWS services, the CloudFormation template should help make it much simpler to implement and this can be done in a matter of minutes if all the required permissions are available. You do get an extremely low-cost / free automated solution to alert you, based on your schedule, on any newly found vulnerabilities in your CVM environment. Many more alerting use cases can be used with this setup by creating the right risk meter to track the information of interest.
Feel free to customize the Lambda function and schedule to fit your specific needs.