Closed Loop Security and Compliance Helps You Safely Migrate to and Expand AWS Usage

By Bashyam Anant, Vice President, Product Management at Cavirin Systems
By Suresh Kasinathan, Cloud Security Architect at Cavirin Systems
By Naveen Ramachandrappa, Sr. Machine Learning Engineer at Cavirin Systems

DevOps staff in many organizations are one misconfiguration away from compromising their Amazon Web Services (AWS) resources to attackers as they migrate to and grow their adoption of existing and new AWS services.

In this post, we propose “Closed Loop Security” based on unifying proactive and reactive risk signals as a key strategy for DevOps staff to protect their AWS infrastructure from misconfigurations and vulnerabilities.

Cavirin Systems is an AWS Partner Network (APN) Advanced Technology Partner with the AWS Security Competency. Their solution helps organizations leverage the cost savings and agility of the cloud without increasing operational risk or reducing their security posture.

If you want to be successful in today’s complex IT environment, and remain that way tomorrow and into the future, teaming up with an AWS Competency Partner like Cavirin is The Next Smart.

Closed Loop Security

Closed Loop Security is a refinement of the NIST Cybersecurity Framework (NIST CSF).

It unifies proactive assessment of configuration and vulnerability checks with reactive risk signals from monitoring systems like AWS Cloud Trail and AWS CloudWatch, as well as threat detection systems like Amazon GuardDuty.

Put together, we believe Closed Loop Security helps organizations protect their AWS resources despite the volume, variety, and velocity of AWS IaaS and PaaS services adoption.

Like NIST CSF, Closed Loop Security has five steps, visualized in Figure 1 and described in detail below.

Figure 1: Closed Loop Security.

Step 1: Identify

Cavirin discovers and identifies cloud resources using AWS Command Line Interface (CLI) and SSH (Linux) or WinRM (Windows) sessions for Amazon Elastic Compute Cloud (Amazon EC2) instances.

With this information, we build Cavirin’s inventory of more than 30 AWS resource types at the compute, storage, networking, container, and PaaS layers. Each resource has a criticality (0.8 = Low, 5 = High) based on an assessment of confidential data, system integrity, and availability requirements.

Without this step, DevOps users have no visibility into what they are consuming in AWS, and as a result cannot protect their AWS resources.

Figure 2 – Single pane inventory of more than 30 AWS resource types.

Step 2: Protect

In the next step, we assess AWS resources by evaluating 100,000+ configuration and vulnerability controls sourced from AWS best practices, Cavirin thought leadership, vulnerability feeds, threat detection feeds such as GuardDuty, the Center for Internet Security (CIS), Defense Information Systems Agency (DISA), and more.

Examples of configuration controls include:

Are any Amazon Simple Storage Service (Amazon S3) buckets open to public?
Do any Security Groups or NACLs allow ingress on all ports?
Do any Amazon EC2 instances have critical vulnerabilities?
Do any Amazon EC2 instances have GuardDuty findings (cryptomining, suspicious inbound/outbound connections) flagged against them?
Are weak passwords in use?
Have AWS Identity and Access Management (IAM) and SSH certificates been rotated per best practices?
Are admin permissions associated with Amazon S3 buckets restricted to users with admin roles?

Of course, no DevOps user would knowingly leave resources in a risky state. However, with more than 30 AWS services in Cavirin’s AWS catalog that customers could be using with multiple users making configuration changes, it’s very easy to make mistakes.

One of the most common scenarios for misconfiguration among Cavirin customers is when a DevOps user temporarily opens Security Group or NACL ports in a pre-production AWS account for the sake of troubleshooting, and inadvertently pushes these configurations to their production AWS deployment.

Some customers use Cavirin to assess a baseline AWS environment created using an organization’s AWS CloudFormation template. Cavirin’s solution may find ways to tweak the template resulting in a more secure baseline infrastructure.

Step 3: Predict

Once Cavirin assesses configuration and vulnerability controls for your AWS infrastructure, it knows which controls are passing versus failing on each AWS resource in Step 2.

Next, Cavirin applies a proprietary scoring algorithm which results in a score (0 = High Risk, 100 = Low Risk) for each resource in your AWS account.

The scoring is based on the following tradeoffs:

Weight (0-10) associated with the technical control assigned by a proprietary machine-learning classifier; 0 is used for informational findings, while 10 represents critical findings.
Resource criticality.
Number of resources failing a given configuration or vulnerability check.

In simple terms, high-weighted technical controls that are failing on lots of critical resources will result in a low score (implying high risk) in our scoring algorithm.

For a DevOps user, scoring serves several purposes:

Create change management plans by prioritizing findings that offer the greatest security posture improvement.
Slice and dice scores from the company level to a resource group to a resource type to an individual resource to figure out which resource types need immediate attention versus those that can wait.
Understand the efficacy of change management by assessing trendlines of scores. Scores with an upward trend imply your actions are having the intended effect.
Understand gaps in CloudFormation templates that may be used to create secure baselines

Without scoring, DevOps users can be overwhelmed by the sheer number of configuration and vulnerability issues in their environment leading to inaction and greater risk.

Step 4: Respond

With the help of scoring, DevOps users have a prioritized list of findings they can remediate, using one of the following options:

Enact changes via the AWS Management Console, using Cavirin reports that detail remediation steps.
Modify CloudFormation templates, using remediation steps in Cavirin reports.
Publish security findings to ticketing systems (JIRA, ServiceNow), notification systems (Slack, PagerDuty) and SIEMs (Splunk) for follow-up through those systems.
Serverless remediation of cloud resources using AWS Lambda functions.
Ansible playbooks remediation for operating system (OS) resources.

Once remediation steps are implemented, an organization should be able to achieve a security baseline.

Figure 3 – Create remediation request as a JIRA issue.

Step 5: Monitor

Achieving a security baseline is a great start. However, infrastructure changes can happen continuously. Incorporating signals from monitoring systems like CloudTrail and CloudWatch, and threat detection platforms like Guard Duty, is an essential aspect of Closed Loop Security.

Cavirin closes the loop by enacting the following:

As AWS resources log events to CloudTrail, Cavirin evaluates them against its technical controls. Cavirin also tracks new and deleted resources through CloudTrail.
Cavirin accumulates a change log in the form of resources failing technical controls, new resources and deleted resources.
If the extent of these changes exceeds a customer-configurable threshold, Cavirin reassesses the customer’s AWS account using the protect workflow of Step 2, and the cycle continues through the predict and respond steps.

This approach of connecting reactive risk signals to proactive technical controls assessment is at heart of Closed Loop Security. For DevOps users, it’s a breakthrough because it:

Reduces the time and cost to react to alerts by linking them to technical controls, risk scoring, and remediation.
Minimizes operator alert fatigue by dispositioning alerts automatically.
Applies risk-based scoring to alerts.

Closed Loop Security Architecture

Cavirin’s Closed Loop Security has two components that can be used together or separately: monitoring framework, and remediation framework.

Cavirin is available on AWS Marketplace, and advanced users can create custom deployments using installation scripts. In either case, Cavirin is deployed in your AWS account with an IAM role associated with the Amazon EC2 instance on which Cavirin is installed with read-only permissions to discover and assess your AWS account.

Closed Loop Monitoring Framework

Once Cavirin is deployed in your account, the setup of monitoring is handled transparently by our solution.

The monitoring setup scripts invokes CLI and creates the artifacts outlined in Figure 4 below, including an Amazon Simple Queue Service (SQS) queue, CloudWatch Alarms, and a Cavirin-authored Lambda function with the least IAM privileges.

Note the monitoring framework uses different IAM permissions compared to the Cavirin AMI to ensure role separation between the protect and monitor activities.

As Figure 4 demonstrates, Cavirin’s monitoring framework automates the following steps, though these are largely hidden from the Cavirin user:

An AWS service (Security Group) logs events via CloudTrail.
Cloudwatch Alarms filter events based on what Cavirin can analyze. These alarms are configured as part of Cavirin’s set up of its monitoring framework.
Cloudwatch acts on alerts by triggering a Cavirin-authored Lambda function, which is deployed automatically by Cavirin and stays in place till the customer uninstalls Cavirin.
The Lambda function processes the alerts and attempts to match them to policies available in Cavirin. Either way, it publishes alerts in a Cavirin format to SQS queue.
Cavirin periodically polls the SQS queue for new alerts.
The SecOps users view alerts within the Cavirin dashboard.

Figure 4 – Closed Loop Monitoring Framework.

Closed Loop Remediation Framework

Once Cavirin is deployed in your account, the setup of remediation via AWS Lambda is handled transparently by Cavirin. The setup scripts create the artifacts outlined in Figure 5 below, including an Amazon Simple Notification Service (SNS) topic, SQS queue, CloudWatch Alarms, and a Cavirin-authored Lambda function with the least IAM privileges.

We chose SQS as we require FIFO (first-in, first-out) behavior for remediation confirmations as will be apparent next.

As Figure 5 demonstrates, Cavirin’s remediation framework automates the following steps, though these are largely hidden from the Cavirin user:

SecOps picks one or more policies to remediate from the Prioritized Issues list within the Cavirin dashboard. The Prioritized Issues is a result of the predict step of Closed Loop Security.
Cavirin publishes a remediation request to an SNS topic, which is created automatically by Cavirin as part of the remediation setup.
A Cavirin-authored Lambda function subscribes to remediation requests. This function is deployed automatically by Cavirin as part of the remediation setup.
Lambda function performs remediation and posts remediation confirmations to an SQS queue, which is set up automatically by Cavirin as part of the remediation.
Cavirin periodically polls the message queue for remediation confirmations.
SecOps users view alerts related to completed remediations. Completed remediations contribute to Cavirin’s change log for the customer’s AWS account.
If the extent of remediation confirmations, policy failures, deleted resources, and new resources exceeds a customer-configurable threshold, Cavirin reassesses the customer’s AWS account using the protect workflow of Step 2, and the cycle continues through the predict and respond steps.

Figure 5 – Closed Loop Remediation Framework.

Closed Loop Security in Action

We demonstrate Closed Loop Security through two scenarios.

Scenario 1: Security Group Ingress Rules

The scenario starts with an AWS account that has a Security Group with several ports open for inbound traffic, which is a risky configuration.

Figure 6 shows the current CyberPosture score for security Groups based on the identify, protect, and predict steps of Closed Loop Security. The prioritized issues shown on the right side of Figure 5 above lists Security Group inbound ports with their improvement potential.

Figure 6 – CyberPosture Score with Open Security Groups

Remediating the issue (closing an open port) is one-click away as shown in Figure 7.

Figure 7 – One-click remediation.

Post remediation, the remediation is acknowledged via a CloudTrail alert shown to the user in Figure 8.

Figure 8 – Remediation confirmation viewed through CloudTrail alerts.

The next assessment shows the improved score.

Figure 9 – CyberPosture score after remediation.

Scenario 2: Amazon GuardDuty Findings

With the configuration of a permissioned AWS service account, Cavirin can ingest GuardDuty findings that are accessible via one or more GuardDuty detectors.

Cavirin ingests all documented Amazon GuardDuty findings, including cryptominers and suspicious API, user, and machine activity. These findings are mapped to Amazon EC2 instances or AWS accounts discovered by Cavirin, and reduces their scores based on our algorithm.

The scenario reflects the following steps:

An Amazon EC2 instance IAM entity (user, group, role), or API exhibits suspicious activity. This is reported as a finding in GuardDuty and viewed as an alert in Cavirin.

Figure 10 – Amazon GuardDuty findings list.

Cavirin scores the affected Amazon EC2 instances or AWS accounts and reflects it on the dashboard and prioritized issues.

Figure 11 – CyberPosture score due to Amazon GuardDuty findings.

The user can act on these alerts in the AWS Console by quarantining Amazon EC2 instances or disabling IAM users. Just indicate “Mark as Read” against the findings within Cavirin.

In subsequent assessments, the CyberPosture score increases.

Closed Loop Compliance

Cavirin’s approach to compliance mirrors Closed Loop Security with a few significant differences.

For compliance frameworks like HIPAA, PCI, GDPR, and AICPA SOC2, Cavirin has developed a machine learning Recommender System that accomplishes the following:

Identifies the best-fit technical control from Cavirin’s technical controls repository.
Assigns a similarity score for each technical control that can be used to create differential weights for each technical control that serves to evaluate a compliance control

Compliance policy packs contribute to a compliance posture score, which can be sliced and diced by environment, resource group, policy pack, and resource type to create prioritized action plans.

Next Steps

We believe that Closed Loop Security and compliance as described in this post can help organizations safely migrate to and expand their AWS usage.

You can try Cavirin through AWS Marketplace >>

The content and opinions in this blog are those of the third party author and AWS is not responsible for the content or accuracy of this post.

Cavirin Systems – APN Partner Spotlight

Cavirin is an AWS Security Competency Partner. Their solution helps organizations leverage the cost savings and agility of the cloud without increasing operational risk or reducing their security posture.

Contact Cavirin | Solution Overview | Buy on Marketplace

*Already worked with Cavirin? Rate this Partner

*To review an APN Partner, you must be an AWS customer that has worked with them directly on a project.

AWS Partner Network (APN) Blog