By Prasad Kunchakarra, Eric Hein, Todd Sternburg | July 18, 2022
Since 2019, it has been clear that security misconfigurations create major issues for modern workloads deployed in cloud architectures. To solve this problem, Capitis developed our C2VS solution, which we have been implementing at major financial and governmental agencies for the past three years. Based on this work, we have identified the most common challenges in identifying misconfigurations using a combination of out-of-the-box and client specific security control tests.
C2VS has been continuously testing infrastructure, platform, and application security controls for our client systems, and has been rolled out to hundreds of AWS accounts containing hundreds of thousands of resources. The results from the C2VS scan data have proven that security misconfigurations are a major challenge and that this problem is especially heightened when large organizations transition workloads from on-prem to cloud infrastructures. During the migration process, the security configurations of workloads continuously change, increasing the likelihood of misconfigurations.
In this blog we analyze the gaps in organizations’ security control processes (implementation, testing, compliance, and governance), as well as examining the fundamental limitations of the current set of security tools/products offered by security vendors.
After implementing thousands of tests across all layers of security boundaries, we have the following key learnings about common impediments to identifying misconfigurations.
Application Layer Focus: The current discipline of App Sec focuses on the areas of Software Composition Analysis (SCA) and code security weakness and leaves several blind spots related to the interaction of application, platform, and infrastructure layers.
Generic Configuration Tests: Cloud infrastructure security controls such as NACLs, Security Groups, IAM Roles/Policies, etc. are tested typically with Cloud Security Posture Management (CSPM) tools that use generic security configuration tests, which are good at catching gross violations of network security segmentation principles or excessive permissions. However, they have several blind spots related to identifying weaknesses in network controls – essential to detect lateral movement of an adversary and/or excessive permissions that lead to privilege escalation by an adversary.
False Positives: These tools often generate false positives because they do not incorporate organizations’ standards, policies and procedures or application specific data and workload security requirements. False positives lead to continuous questioning of the accuracy of findings by application teams, causing a wastage of time and resources, while many of the legitimate security control gaps remain unaddressed for several weeks to months.
Siloed Tools & Teams: The current Application Security tools and CSPM tools work independently of each other and are operated by different teams, and as a result, the attack vectors that exploit multiple layers of weaknesses go undetected.
SIEM Detection Efficacy: Effectively detecting security movements of an adversary is not accomplished in most organizations’ SIEM implementations. The adversary movement may go undetected for several months or forever because the application-specific security events of interest are not captured or baselined to identify the anomalous behavior of an adversary. CSPM, Application Security controls verification, or vulnerability management tools test the effectiveness of detective controls implemented by SIEM tools.
What can be done to solve these issues?
Chief Information Security Officer for Google Cloud, Phil Venables, recommends the following in his blog Controls-Updated from Feb 26, 2022:
Treat controls as first-class objects like other parts of a system’s function.
Phil’s insight based on years of practice as a leader in the security profession is invaluable. It is encouraging to see a seasoned industry veteran expressing similar opinions as those we have shared previously in our blogs. The following additional context helps illustrate the point:
…the vast majority of attacks that are either well known (or that I have otherwise become aware of) still seem to have this common pattern - that they are not the result of some awesome attacker capability to exploit some hitherto unknown vulnerability or to realize a risk from some combination of controls weakness not contemplated. Rather, a remarkably common pattern is that the control or controls that would have stopped the attack (or otherwise detected/contained it) were thought to be present and operational, but for some reason were actually not - just when they were most needed.
In other words - a majority of the attackers’ activities could have been stopped or contained if security controls were properly implemented and tested. Phil further asserts:
There are many reasons for these failures to sustain the correct implementation of important controls, for example: a bad change, operational error, a new implementation that was incomplete, other faults/breakage, some wider change that nullified the in-situ control, ongoing lack of configuration discipline and many other operational factors. In fact, any issue that drives any type of system error can be an issue that negates or disables a control.
The indication is that security control failures can be caused by a lack of security configuration discipline, leading to bad changes, non-implemented changes, or other global changes that nullify the existing security controls.
The recommendation to avoid this problem can be summarized as:
- Maintain an automated security control catalog
- Design and peer review security controls like any system component of the software
- Implement security controls as code
- Test security controls to make sure that the designed security controls are implemented correctly. These tests include build-time security control testing during software development life cycle phases: unit, component, integration, and end-to-end tests
- Continuously monitor controls, which includes security configurations management discipline
- Treat security control failures as security incidents for effective disposition
As discussed earlier, the security tools offered by most vendors cannot satisfy the needs of security controls testing because security controls and associated tests are specific to each system, which are based on organization’s security control catalog and security control patterns. Generic security control tests offered by vendors have blind spots and will not detect gaps in security control implementation, bad changes, misconfigurations, errors, or side effects of global changes in configurations. In addition, generic security control tests may also lead to false positives resulting in wasted time and effort.
For more information about our approach see our other blog entries.
About C2VS
Our C2VS product and solution is fundamentally built around the six recommendations mentioned above. While the C2VS product offers an out-of-the box control catalog and security control tests, it is also a framework built for writing custom automated security control tests. Our tests make sure that each and every implementation statement is tested. The implementation statements of controls are typically based on the requirements dictated by an organizations’ security control catalog, policies, standards, procedures, and recommended security control patterns. Capitis’s professional services team, which includes security analysts, DevSecOps Engineers, and experienced Enterprise Application Architects, rapidly customizes C2VS to meet the needs of the organization – organizations reap the benefits of our implementation within weeks.
About the Authors
Prasad Kunchakarra is the CEO and Founder of Capitis Solutions Inc. He has over 15 years of experience in architecting and implementing secure platforms both for Government and commercial clients.
Eric Hein is the Chief Engineer at Capitis Solutions Inc. He has over 15 years of experience architecting enterprise applications and managing agile teams.
Todd Sternberg is an information assurance subject matter expert at Capitis Solutions Inc. He has over 20 years of experience in assessing and accrediting information systems for Government, Intelligence Community, DoD, and Commercial clients.