Consider Security Risks of Cloud Agnostic vs. Cloud Native Infrastructure
As organizations around the world increasingly adopt and migrate to cloud, one of the many decisions they will need to make is whether to be cloud agnostic or cloud native.
Public cloud spending was predicted to approach $500 billion in 2022 and 600 billion in 2023, according to Gartner.
What’s more, by 2025, 51% of spending on traditional IT, including application software, infrastructure software, business process services and system infrastructure, will shift to public cloud.
As organizations around the world increasingly adopt and migrate to cloud, one of the many decisions they will need to make is whether to be cloud agnostic or cloud native. Critical to their decision is understanding the security risks of each cloud model.
For example, consider the scenario of a legacy three-tiered website architecture consisting of a web server, application server and database server. To simply migrate to a cloud agnostic model, the architecture could be split into web server, application server and database containers. Conversely, to migrate using a cloud native model, cloud services would be used for web, application and database roles (e.g., AWS S3, AWS Lambda and AWS RDS). In this hypothetical example, we can see the security differences start to take shape.
Cloud agnostic security responsibilities
Cloud agnostic security can be broken down at the various layers and result in a few concepts. Application security is the concept of securing the application’s code. Application owners are responsible for ensuring completion in areas such as SAST and code review (policies may require developers to perform this function).
Moving down the stack, next is containers' software security. This encompasses middleware, and other software, security that is installed in the containers, (e.g., Apache Tomcat). This is also the application owner’s responsibility to secure.
Moving further down the stack, next are the requirements to harden all containers and images in use. For example, the root user namespace issue should be mitigated through user mapping. This responsibility lies somewhere between the application owner and the container orchestration administrator.
Still further down the stack is the container platform hardening requirement. This step involves restricting and disabling access to exposed attack surfaces. The responsibility generally falls on the container orchestration administrator.
Lastly, at the bottom of the stack is the infrastructure where the orchestration platform sits. Security of this infrastructure is the responsibility of the cloud service provider (public cloud model) or the virtualization administrator (private cloud model).
Cloud native security responsibilities
Cloud native application security is the same as it is in the cloud agnostic model.
Moving down this stack diverges to cloud platform configuration and hardening. This process ensures mis-configurations, such as fully open and public access, are mitigated. This is the responsibility of the cloud platform administrator.
Next in line is the infrastructure security. This is the responsibility of the cloud service provider (customers generally do not have access or visibility to this infrastructure).
Consider security complexity
It's no secret that complexity increases security risk — and this is also true with cloud models. Cloud agnostic infrastructure certainly adds complexity with multiple layers and added overhead. When considering a cloud agnostic infrastructure, IT leadership must ask: Does my organization have the skillset and capability to effectively and securely manage applications, containers and platform?
A deficiency in any of these areas will require expert resources to address the gaps. These resources can include internal staff development, third party outsource partners, and contractors to augment temporary and permanent staffing skill shortages.
Cloud native infrastructure presents its own unique security challenges. IT leadership must ask themselves: Does my organization have the skillset and capability to manage effectively and securely both the applications and the cloud platform?
Again, a deficiency requires resources to address gaps. However, cloud platform capabilities are easy to spin-up or outsource when they are compared to container infrastructure capabilities.
A risk assessment can assist organizations with making the decision to go cloud agnostic or cloud native. After the decision is made and the application is migrated, Threat Modelling may identify and communicate any threats, vulnerabilities, and gaps.
Both cloud native and cloud agnostic infrastructures have their own unique risks and benefits. IT decision makers must understand the security risks before choosing which infrastructure to use, while ultimately asking themselves: Does the complexity of cloud agnostic outweigh the risk of vendor lock-in with cloud native?
No matter which architecture is chosen, the organization will gain significant benefits over a legacy architecture.
Why Cybersecurity Continues to Dominate C-Suite Attention
About the Authors
Product Engineer - Government Solutions
Jeffrey Tehovnik
The role of Product Engineer for Government Solutions is a natural fit for Jeff Tehovnik with his diverse and complimentary skillsets in Development, Cloud Network Infrastructure, and Security. Jeff has been working in IT since 1998 and graduated from Virginia Commonwealth University (BS-IS 2012, MS-CISS 2014) and the SANS Technology Institute (PGC Ethical Hacking & Penetration Testing). Jeff also enjoys research and educating on Technical Information Security Topics including Network Security Monitoring and Advanced Persistent Threats. In addition to recently passing the CCSP exam, Jeff holds the CISSP, GCIH, GPEN, GWAPT, GXPN and VMware NSX: Micro-Segmentation certificates. When he’s not delving into the cloud, Jeff enjoys Reading, Fishing, and Vacationing at the beach with his wife and kids. He is also an avid Hockey Fan.
Read more about Jeffrey Tehovnik