Cloud-based infrastructure is critical to the daily operations of many organzations today, but these modern technologies and services can also pose new security risks if not set up properly. Learn how Rapid7 InsightVM integrates with cloud service providers like Amazon Web Services (AWS) to assess your cloud-based assets for common misconfigurations with its Cloud Configuration Assessment feature.
Moving to the cloud is top of mind for many organizations today, but doing it securely is equally critical. Today, we’re going to talk about cloud configuration assessment in InsightVM, which allows you to assess your cloud-based infrastructure for risk in the form of common misconfigurations.Show more Show less
InsightVM uses what we call “connections” to leverage account-based access roles that provide cross-account, read-only access to your AWS resources. You can set up separate connections for different AWS accounts, or you can use a single master account with cross-account trusts that can access everything. We can move through this interface to work with the data and review the results as they come in.
The default tab that I'm on is going to show findings, which you can see in the table below. Within this findings table, we'll see the services responsible for deploying the resource that we're looking at, things like EC2, IAM, S3, et cetera. We'll see the rule that was applied to the resources. We'll see the individual resource itself. We'll also see the status, which can be pass, fail, not applicable, or accepted.
Under severity, we're going to use Rapid7's scale from low to critical, as well as some informational findings. Informational findings are those that may not have an immediate security impact, but should be addressed nonetheless. I can browse through by using any of these clickable links. Things like the rule name will take me to a details page for that specific rule, where I can go through and on the lefthand side see a summary of the rule itself, including links to the CIS benchmarks, using some AWS best practices for remediation or fixing misconfigurations.
Then in the middle you'll also see a simplified description of the rule, and also a list of resources that may have been affected. These are filterable. We can click into the resource name from here, and clicking into the resource page shows you all the rules that apply to this one particular resource. Again, we get a nice summary over on the left-hand side. What is this resource? Where is it? What VPC does it live in?
We'll also see some resource-specific filtering options. In this case, this is an EC2 security group, so I can look at the details for ingress and egress rules, and see how people are able to access this particular resource.
If I want to, I can view specific details on the finding itself over in that right-hand column. Clicking on that little link will lead me to both a proof and remediation section for the finding itself. This is something that I'll run through our exception process.
When you create the exception, you're going to be able to do a couple things. One is set the scope, which may be this one individual finding. This one instance of a failed rule is on a very specific resource. Or, it may be the rule as a whole across the board. It's just not something that's pertinent to what we're doing right now.
It can also be a custom scope. You may look at specific accounts or specific regions or other criteria. You may want to plug in resource-specific IDs to fine tune that scope. What you'll see is as you change that scope up, you're going to see the potential impact along the bottom here, which tells you the amount of findings you're going to exclude, how many regions, and how many accounts those will encompass.
Once you set a scope that you're comfortable with, we go ahead and we set our expiration timeline. Anything from a week out through never. We'll also set a reason. Whatever the scenario may be, we go ahead and submit and we've created our exception.
We'll come back to that particular exception that we just created in just a moment. If I go to my resources view, I'm going to see a list of all the deployed instances of my infrastructure services that have been assessed. Over in the details column, you get a breakdown of the resources by category. Under EC2, you'll see I have EC2 instances, I have elastic IPs, I've got things like network ACLs, security groups, VPCs.
From the rules view, I can see all the rules, or those policy-based checks that are included within Cloud Configuration Assessment, and how they apply to your cloud infrastructure. In this table below, you're going to see the service the rule applies to and the rule itself. You're going to see the number of passed and failed resources, as well as the exceptions that you've created, and then you're going to see your overall compliance against the rule.
Finally, we work our way back to our exceptions, and under the exceptions view, you can look at any exceptions in place, broken down by service, rule, scope, impact, and overall timeline. When was it created? When is this going to expire?
InsightVM's Live Dashboards can display results from cloud configuration assessment to give you high level visibility into your cloud infrastructure. You can see information here regarding failed rules, findings by severity, your largest compliance gaps, including maybe some of the specific rules that you want to highlight. You'll see accounts associated with the highest amount of potential risk based on failed rules they're associated with, and also a breakdown of rules that have gone through an exceptions process.
You're going to have really nice visibility into your cloud infrastructure, along with any potentially risky misconfigurations. The best part? You have it alongside your vulnerability management workflow within InsightVM itself.
Get started with a 30-day free trial of InsightVM and see how you can better secure your cloud-based infrastructure.Start Free Trial
Learn how Rapid7 solutions integrate with Amazon Web Services (AWS) to advance your cloud security posture.View All Integrations