The five universal foundations for building an efficient cloud security program are laid forth in this expert blog by Josh Stella, chief architect at Snyk and co-founder of Fugue, a company that was acquired by Snyk last February. Snyk is a global pioneer in developer security solutions.
The term ‘misconfiguration’ may appear harmless – a simple error that can be easily corrected, such as shifting your automobile into drive while the parking brake is still engaged. You swiftly see the problem and let go of the brake. But what if your automobile is riddled with hundreds of misconfigurations? Nobody has time to manually check the engine, gearbox, suspension, brakes, and electronics every time they get in their car, despite the fact that a single misconfiguration might lead to automobile failure or human damage.
Cloud infrastructure environments also include a huge number of complicated settings, all of which are specified and maintained by the cloud client. Customer errors, such as cloud misconfigurations, can cause system downtime or a serious security breach. Misconfigurations abound in any business cloud setup.
According to The State of Cloud Security 2021 Report, 36 percent of firms had a major cloud security leak or breach in the previous year owing to cloud misconfiguration.
‘Misconfiguration of cloud resources is the most widespread cloud vulnerability and may be exploited to access cloud data and services,’ the National Security Agency (NSA) warns. ‘Misconfiguration, which is frequently the result of cloud service policy errors or a misunderstanding of shared responsibility, has a wide range of consequences, ranging from denial of service vulnerability to account breach. The rapid rate of [cloud service provider] innovation adds complexity to securely setting an organization’s cloud resources while simultaneously introducing new capability.
Misconfigurations, Minor and Major
For security specialists, detecting and correcting computer misconfigurations is not a novel notion. Network protocols and firewall ports are customizable components of an IT system in the data center, and a misconfiguration here might provide a security issue that must be addressed.
Misconfigurations in the cloud range from basic errors involving single resources, such as leaving a harmful port open, to complex architectural design defects involving several resources that might be difficult to detect for security teams. Despite its complexity, the fact that cloud computing is 100 percent software implies that these errors are fully avoidable. Those that succeed in preventing misconfigurations see it as a software engineering issue rather than a physical data center architecture issue.
This is because cloud infrastructure is designed rather than built. And those who program it, usually developers or DevOps engineers, make decisions on how their cloud infrastructure is configured – and then change it on a daily basis. You want them to have this capability because it’s important for them to be able to quickly install and enhance apps, which is one of the most important factors driving cloud adoption. Every shift, however, introduces new hazards – and new types of dangers.
APIs are the backbone of cloud computing, and they play a key role in how we utilize it – and how adversaries use it. APIs are the ‘middlemen’ in software that allow various apps and cloud services to communicate with one another. Security teams can’t rely on any network perimeter to identify and stop incoming threats since there is no set IT architecture in a single place.
The cloud control plane, which is the API surface used to configure and run the cloud, is where security teams should concentrate their efforts. Customers can utilize this control plane to create virtual servers, change network routes, and obtain access to data, for example. When attackers gain a footing in a cloud environment, however, they exploit the control plane to gather information about the environment, move laterally, and extract data. This is the assault surface on the cloud.
Every major cloud breach involves attackers compromising the control plane. Control plane compromise assaults are lightning fast ‘smash and grab’ vulnerabilities that don’t transit traditional networks that can be watched, unlike data center attacks, which tend to take a ‘low and slow’ strategy to evade detection on the network. Organizations that are successful in averting these threats adopt a new approach to cloud security, beginning with the developers and DevOps engineers who build and manage cloud infrastructure.
– Expert Blog continues below the photo –
Policy as Code
Instead of purchasing physical infrastructure and putting software into it, developers build applications in the cloud and create the infrastructure for the applications. Because cloud infrastructure is built with code, it is mostly controlled by developers and DevOps. This new paradigm forces the security team to become domain experts in secure cloud architecture and to share that expertise with developers so that they may create safely. Policy as code is how security teams do this.
Security teams can describe security and compliance policies in a programming language that an application can utilize to verify configurations are accurate using policy as code. Policy as code allows programs to examine other code and operating environments for undesirable circumstances, such as harmful misconfigurations. This implies that all cloud stakeholders are on the same page when it comes to security, with no ambiguity or dispute about the rules, and different teams are enabled to implement policy at various stages throughout the software development life cycle (SDLC).
Because the number of cloud services in use across your organization is likely to grow in the future, automating the process of identifying and correcting cloud misconfigurations is critical for preventing vulnerabilities from being exploited by attackers, and it relieves manual burdens on security teams that are already overburdened. When you build your automation on policy as code, you can expand it as your cloud usage and complexity develops. Developers may also utilize the same criteria to guarantee that infrastructure is safe prior to deployment, reducing the number of misconfigurations that security teams must resolve.
Think Like a Hacker
Organizations that have successfully established cloud security strategies have features that any company may learn from. When people ask me where they should start when it comes to better securing cloud environments, I always propose first getting a thorough understanding of your environment and the SDLC for cloud infrastructure – and then thinking like a hacker to spot holes in your design. If you’re simply concerned with removing particular misconfigurations, you’ll have to get it right 100 percent of the time, whereas hackers only need to get fortunate once. You must be aware of what an attacker may do if they get access to your network.
That leads to the second point of attention for successful businesses: preventive and secure design. It’s too late to identify and stop an attacker after they’ve gotten access to your environment and penetrated the control plane. The aim is to avoid deploying misconfigurations and to build cloud environments that deny adversaries access to the control plane while reducing the blast radius of any possible breach.
The third thing we see successful firms do is provide developers and DevOps engineers with tools that assist them in designing and constructing secure cloud infrastructure. The interaction between your security staff, developers, and operations is changing dramatically, with everyone incorporating security into their workflows. Security teams act as security architects, advising and directing other teams. Policy as code, once again, is the technical enabler.
Building cloud security on a foundation of policy as code is the fourth thing we see every successful firm accomplish. I’ve gone into great detail about policy as code here, but it’s the technical underpinning of any cloud security program if you want it to expand with your cloud usage without requiring you to scale up your security staff. You can’t reliably communicate policy across the business without policy as code, and you can’t empower developers with technology to help them operate more securely without it.
Secure Cloud Innovation
Measuring what matters is the fifth and final cloud security objective. You must understand where you are currently in terms of cloud security, where you want to go, and how to track your progress along the way. In the cloud, how much risk are you willing to take? How quickly are your teams providing secure cloud innovation? How many hours of engineering are you devoting on cloud security?
How long are your developers expected to wait for security teams to manually review and approve deployments, for example? How many hours do security teams spend assessing and prioritizing cloud misconfigurations before forwarding them to DevOps for resolution? How much time and effort are spent on the rework required to handle architectural security vulnerabilities rather than designing architecture that is intrinsically safe from the start?
Because the cloud’s architecture allows us to handle security as a software engineering challenge – and design software engineering solutions to help everyone move quicker and more securely – successful businesses see cloud security as an enabler rather than a barrier to innovation.
To conclude, those that get cloud security right concentrate on the following five principles:
- Know your environment – Understand everything that’s going on in your environment, how it’s built and deployed, and how hackers could attack it.
- Focus on prevention and secure design – Shift your security mindset to focus on preventing the kind of cloud vulnerabilities that hackers are attempting to exploit through safe design and deployment methods.
- Empower developers – Shift left on cloud security by arming everyone engaged in cloud infrastructure design, development, and management with tools to help them get security right from the start.
- Align and automate using policy as code – Build a scalable technical foundation for cloud security by bringing all teams under the same security source of truth.
- Measure what matters – Identify the key risk, velocity, and security investment metrics you should be tracking. Determine your current baselines and goals, and track your progress.
