Brought to you by:
Enterprise Strategy Group | Getting to the Bigger Truth™
ESG TECHNICAL REVIEW
Continuous Security Posture and Risk Management of Infrastructure-as-code with Tenable.cs
By Alex Arcilla, Senior Validation Analyst
JANUARY 2022
Abstract
The concept of secure access service edge (SASE) has generated an enormous amount of market attention and user interest in the short time since it has been introduced. This should not be all that surprising considering the fundamental changes cloud and mobility have had on the enterprise over the last decade and the comparatively little innovation network security technology has seen during that time.
Further, the pandemic has forced organizations to confront the reality that the cybersecurity models they have used for decades are no longer effective in a highly distributed world, creating an additional groundswell around SASE.
The Challenges
According to ESG research, 45% of respondents are taking a cloud-first policy approach and deploying new applications using public cloud services unless someone makes a compelling case to deploy them using on-premises resources, up from 38% who said they were taking a cloud-first approach in 2020. However, organizations are encountering new security challenges when deploying these applications. As a matter of fact, 33% of respondents to a separate ESG research study said that they view cloud service provider (CSP) infrastructure as the element of the cloud-native application stack most susceptible to compromise (see Figure 1).
Figure 1. CSP Infrastructure Presents Greatest Risk to Cloud-native Applications
Which element of the cloud-native application stack do you feel is most susceptible to compromise and therefore represents the greatest risk to your organization? (Percent of respondents, N=383)
Source: Enterprise Strategy Group
Ensuring quality and compliance as code has become critical to ensure that end-user and business needs are satisfied with little delay. Organizations have employed tools to detect and mitigate vulnerabilities at the application level throughout the development pipeline. However, vulnerabilities and threats to cloud infrastructure are typically not uncovered until the application has been deployed, using cloud security posture management (CSPM) or cloud Infrastructure entitlements management (CIEM) tools. Uncovering security-related issues after the fact can only increase time and cost spent on remediating any potential or successful breaches. What if those issues could be detected and remediated in infrastructure-as-code (IaC)before the application code is deployed?
The Solution: Tenable.cs
Designed for DevOps and DevSecOps, the Tenable.cs platform can programmatically detect and remediate security risks before public cloud infrastructure is provisioned to support cloud-native applications. By continuously monitoring code throughout the development lifecycle, the platform can help developers to prevent vulnerabilities or security gaps from being embedded in IaC. After deploying the application, developers can use the Tenable.cs platform to detect any public cloud infrastructure changes (e.g., adding storage, changing virtual instance configuration) or policy violations, then update the source code so that application updates do not inadvertently introduce new security vulnerabilities. Vulnerabilities can be detected at the cloud infrastructure, Kubernetes cluster, and pipeline levels.
Figure 2 details how the Tenable.cs platform helps organizations to detect and remediate vulnerabilities (either noted as policy violations or cloud resource misconfigurations) embedded in infrastructure before and after application deployment. Throughout each stage of the application development lifecycle (initial code, code commit, build, deploy, and run), organizations can continuously scan infrastructure to detect vulnerabilities. Before code is passed onto the next stage, developers can opt to apply IaC fixes manually or automatically as code.
Figure 2. The Tenable.cs Platform
Source: Enterprise Strategy Group
To detect security gaps in infrastructure and recommend remedial actions, Tenable.cs leverages policy groups and best practices created by Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP), as well as policy groups created in-house. End-users can also create custom policies. Tenable.cs enables organizations to integrate with multiple third-party source code management (SCM) and continuous integration/continuous development (CI/CD) tools. The integration enables organizations to install IaC scans into existing workflows that leverage such tools.
By using Tenable.cs, organizations can reap the benefits of proactive monitoring and remediation. While Tenable.cs can minimize the time and effort spent in locating and remediating security gaps within cloud infrastructure, the larger benefit comes from preventing policy violations and misconfigurations from being inadvertently deployed in production. The chances of bad actors exploiting such vulnerabilities are minimized, thus decreasing overall security risk.
ESG Tested
ESG evaluated the Tenable.cs platform via remote demonstrations conducted from Pleasanton, CA. The goal of the review was to determine how developers can use the platform to scan for and identify security gaps in cloud infrastructure code during initial development and the continuous integration/continuous development (CI/CD) pipeline.
ESG began by reviewing how Tenable.cs scans code during initial development. We navigated to the Tenable.cs user interface (UI) to see how work is organized. Code to be scanned and reviewed is grouped by projects, which contain IaC associated with one or more public cloud accounts, code repositories, Kubernetes clusters, and CI/CD pipelines, such as Jenkins and CloudBees (see Figure 3). Associating a project with an account, cluster, or pipeline simply required us to click on “Connection” and select a connection type.
Figure 3. Grouping IaC via Projects
Source: Enterprise Strategy Group
ESG then initiated a scan using the Tenable.cs UI by clicking on the “Run Scan” command associated with the “Default-AWS” project (see top of Figure 4). Once the scan completed, the Tenable.cs UI uncovered five policy violations.
Figure 4. Scanning for Policy Violations via Tenable.cs UI and CLI
Source: Enterprise Strategy Group
Clicking on the link under the “Failing policies” column heading revealed the specific violations and corresponding severity, while clicking on any individual violation summary revealed the impacted cloud resource, such as AWS EC2 instances (middle of Figure 4). We could also arrive at the same tally of policy violations by running the scan via the Tenable.cs CLI (bottom of Figure 4).
ESG then reviewed how to detect cloud misconfigurations or drifts from previously provisioned cloud infrastructure. We scanned existing cloud infrastructure resources (such as AWS security groups, EC2 instances, and VPCs) associated with the project named “AWS” to determine any differences before and after deployment, such as a change of EC2 instance type during runtime (see Figure 5).
Figure 5. Detecting Sources of Configuration Drift
Source: Enterprise Strategy Group
The scan uncovered four sources of drift. After clicking on “aws_security_group.acme.web,” we examined the noted drift, comparing the original security group configuration in IaC with the current configuration in AWS. Any highlighted code indicated where IaC had to be modified so that potential vulnerabilities were removed.
ESG also scanned code in the CI/CD pipeline (see Figure 6). By clicking on the tab “Pipelines,” we were able to select the single pipeline repository and saw that the IaC violated three predefined policies, flagged as “High” severity events. Clicking on the red bar revealed detail about the specific policy violations.
Figure 6. Scanning for Vulnerabilities in Pipeline Repositories
Source: Enterprise Strategy Group
While ESG saw that Tenable.cs enabled a developer to submit trouble tickets (via integrations with Jira) to remediate policy violations or drifts, we also observed how issues could be remediated via pull requests—IaC fixes manually or automatically generated and applied. After navigating to the “Violations” tab located above the code comparison (see Figure 7), we chose the policy violation “Ensure Security Groups do not have unrestricted specific ports open.” Tenable.cs noted in red that the IP address range needed to be changed, while the correction (inputting a specific CIDR block) was noted in green. We then created a pull request of the selected violation. A “Remediation” window opened to input an appropriate CIDR block.
Figure 7. Generating Pull Request and Specifying Remediation for Single Policy Violation
Source: Enterprise Strategy Group
ESG then navigated to BitBucket, selected the newly created request and verified that the fix was correctly inputted (see Figure 7). We could then either approve or decline the code change.
Tenable.cs could also generate IaC fixes automatically for all policy violations via auto-remediation. We navigated back to the “AWS” project and turned on the “Auto-remediation” option (see Figure 8). We initiated another scan that triggered the creation of a pull request. Viewing that request in Bitbucket, we noted that each violation was annotated with the recommended IaC fix.
Figure 8. Generating IaC Fixes via Auto-remediation for Multiple Policy Violations
Source: Enterprise Strategy Group
Up until now, ESG observed how policy violations and misconfigurations could be identified and remediated before integrating new code into existing code bases. We also observed how such issues could be captured within CI/CD pipelines before the code is integrated and deployed. Since Tenable.cs enabled integration with CI/CD tools such as Jenkins and CloudBees Software Development Automation (SDA), scans could be executed within these tools during the build process. If any violations or misconfigurations were discovered, the build would be prevented unless IaC fixes were applied.
As seen in Figure 9, ESG configured the “Build” process in Jenkins to execute an Tenable.cs scan. We selected “Build Now” from the Jenkins UI to begin the code build. When the scan completed, violations were found, resulting in a failed build.
Figure 9. Tenable.cs Integration with Jenkins
Source: Enterprise Strategy Group
Within the CloudBees SDA tool, the Tenable.cs scan was initiated during the “Release Readiness” phase. Exit gate rules were defined by the number of Tenable.cs violations (see figure to the right). If the number of discovered violations exceeded the gate threshold, the code would not be released to subsequent phases of the CI/CD pipeline.
Throughout this review, ESG noted how developers can greatly reduce the time to identify potential vulnerabilities in IaC. Not only do code quality and compliance increase, but, more importantly, the risk that IaC-related vulnerabilities could be exploited once code is deployed is greatly reduced.
Why This Matters
Infrastructure-related vulnerabilities, specifically policy violations and cloud resource misconfigurations, are typically detected after cloud-native applications are deployed. Yet, the risk of bad actors exploiting these vulnerabilities is high. Ideally, these gaps would be addressed very early in the development lifecycle for cloud-native applications.
ESG validated that Tenable.cs can help support DevOps and DevSecOps in uncovering security gaps within IaC by continuously monitoring how code is developed, integrated into existing code bases, and released. We saw how Tenable.cs helped to conduct infrastructure scans throughout the development lifecycle in order to catch and remediate security gaps. We observed how the platform can scan infrastructure against any number and type of policy and cloud resources configuration best practice, then generate appropriate fixes to be applied manually or automatically. We also validated how Tenable.cs can integrate with CI/CD tools to locate and remediate vulnerabilities during code integration and build.
The Bigger Truth
ESG research respondents consider meeting prescribed best practices for the configuration of cloud-resident workloads and services (32%) and lack of visibility into public cloud infrastructure hosting cloud-native applications (30%) as top challenges of securing cloud-native applications. Not addressing these challenges early in the development lifecycle translates into security gaps embedded in IaC that can be exploited after applications are deployed.
With Tenable.cs, organizations can minimize vulnerabilities within cloud-native applications by continuously monitoring infrastructure throughout the development lifecycle. Instead of closing security gaps that are uncovered during runtime, Tenable.cs examines code periodically (from initial development, through CI/CD, to deployment) to uncover and remediate potential vulnerabilities before infrastructure is deployed. Organizations can decrease time in discovering and remediating these security gaps within IaC before applications are in production, thus decreasing overall risk.
Throughout our review, ESG validated that Tenable.cs can help organizations to:
- Proactively uncover vulnerabilities embedded in infrastructure throughout the application lifecycle.
- Remediate policy violations or cloud resource misconfigurations before they can be exploited during runtime.
- Identify and close security gaps when code is integrated into existing code bases before committed to the final build.
Ultimately, organizations can use Tenable.cs to close security gaps in IaC before bad actors can exploit them during runtime. Not only can organizations reduce the time and effort of mitigating infrastructure vulnerabilities, but they can drastically reduce the risk of exploited vulnerabilities.
While Tenable.cs can strengthen the security of cloud-native applications, organizations should consider how existing workflows can be modified to support the use of this platform. Organizations should also consider where the ultimate responsibility of securing public cloud infrastructure lies to determine how Tenable.cs can best be implemented within the cloud-native application development lifecycle. Considering these issues can help in assessing how widely Tenable.cs can be adopted.
If your organization is seeking a way to proactively secure infrastructure within the development lifecycle, preventing embedded vulnerabilities from being exploited during runtime by applying fixes in IaC, ESG suggests taking a closer look at Tenable.cs.
DOWNLOAD PDF REPORT
This ESG Technical Review was commissioned by Tenable.cs and is distributed under license from ESG.
All trademark names are property of their respective companies. Information contained in this publication has been obtained by sources The Enterprise Strategy Group (ESG) considers to be reliable but is not warranted by ESG. This publication may contain opinions of ESG, which are subject to change from time to time. This publication is copyrighted by The Enterprise Strategy Group, Inc. Any reproduction or redistribution of this publication, in whole or in part, whether in hard-copy format, electronically, or otherwise to persons not authorized to receive it, without the express consent of The Enterprise Strategy Group, Inc., is in violation of U.S. copyright law and will be subject to an action for civil damages and, if applicable, criminal prosecution. Should you have any questions, please contact ESG Client Relations at 508.482.0188.
Enterprise Strategy Group | Getting to the Bigger Truth™
Enterprise Strategy Group is an IT analyst, research, validation, and strategy firm that provides market intelligence and actionable insight to the global IT community.