The Elements & Responsibilities of Cloud Security Architecture
Posted by: Romke de Haan
Our world is moving to the cloud more and more every day. Web apps, mobile apps, personal information, pictures, data and more exist somewhere in among a sea of servers we call the cloud.
As organizations make this shift or reassess their current security posture, it’s important to evaluate security layers. This article will discuss the concept of cloud security architecture, how it works and how to apply its ideas.
Types of Cloud Security Architecture
Defining cloud security architecture typically depends on the type of cloud model you have deployed. When that is established, you can look at the security architecture as the guiding principle of what you need to configure, deploy and manage for your cloud environment’s best security.
Since each style has shared responsibilities with the cloud provider, it is best to know which ones you have implemented to be aware of your security responsibilities. The three primary styles currently are:
- Infrastructure as a Service (IaaS)
- Software as a Service (SaaS)
- Platform as a Service (PaaS)
These cloud offerings give customers a cloud-native architecture for running applications and services from outside their organization. The concept of cloud-native architecture is when an application or service is specifically designed to live in the cloud. This is planned from the inception of the software or service and is built around cloud infrastructure.
Elements of Cloud Security Architecture
With a cloud-native approach from a cloud provider, security aspects are shared with whoever is providing the cloud services. Some of the elements to keep in mind when designing cloud infrastructure or as you navigate the cloud as a whole are:
- Security at Each Layer: Ensure that each layer of the cloud’s security stack is “self-defending.” There may be multiple components in each layer, so having defense-in-depth is critical. This goes into having things like automatic updates on operating systems, secure coding and monitoring logs
- Centralized Management of Components: This is taking the concept of multiple components in each layer and managing each — especially security — from one place, making sure to incorporate efficiency opportunities.
- Design for Redundancy in Case of Failures: Even though most of us hate the concept of failure, we have to design our cloud infrastructure for the possibility that it will happen. This means building out disaster recovery plans and having backups on hand to re-establish operations. Another aspect of this is making sure you have resiliency built into all components, or at least the ones that continuously need to be online.
- Design for Elasticity & Scalability: When it comes to elasticity, we have to keep in mind specific design options. When scaling, should it be a horizontal or vertical scale? In other words, can you make the server bigger or add more servers/services? You need to keep in mind what images you will use to deploy new systems or services. What are the thresholds that dictate the scaling up or down? What is the locale or region that the new components will operate in? All of these need to be answered before you build out your architecture.
- Choose the Right Storage for Your Deployments: When choosing storage, it comes down to your organization’s use cases and needs. Take time to look at the options available as they are not created equal. Each has its security controls and different performance specifications. This is a time to revisit data security strategies and make sure you are following the company’s guidelines.
- Plan for Alerts & Notifications: This is one of the most critical aspects of security architecture design. While designing how the components will talk to each other and how users interact with those components, you need to ensure that you are being alerted and notified. This keeps you in the loop on what is happening in your cloud infrastructure. Your primary source of information are the logs created, so it is vital to enable logging wherever you can, such as instance, network, identity, access and service activity.
- Centralization, Standardization & Automation: Centralization, Standardization and Automation (CSA) is something that needs to be thought about during design. Centralization is using services and tools that can be integrated into a single dashboard for viewing. Standardization is creating consistent architectural security models across the vast amount of services offered in the cloud, reducing the burden of implementation of those new services. Finally, Automation, the more you can automate your infrastructure, the quicker you can scale and respond to incidents and issues.
How is Cloud Security Architecture Evolving?
Cloud architectures are moving towards the serverless and microservices approach, living in a shared cloud environment. This is removing the use of standard security tools that we are typically accustomed to.
The reasoning is that standard tools are not designed to run in containers or a specific service. Since these standard monitoring and security tools are not being used, there is more reliance on systems like CASB, Zero Trust and Cloud Workload Protection Platforms (CWPP).
Cloud security architecture is a vital part of cloud security as a whole. The concept of building security into the infrastructure or services allows organizations to better manage, expand and monitor their cloud environments. Without these practices in place, the environment could be opened up to a security incident, leading to data loss.
Responsibilities of Cloud Security Architecture
Public Cloud vs. Private Cloud
The public cloud is where you would use a cloud provider with shared resources and compute among multiple customers. The data and access are hidden from each customer, and each customer in the public cloud can be thought of as a tenant renting space. In this model, the customer and provider usually share responsibility for security.
On the other hand, the private cloud is infrastructure owned by the organization using it, and can be onsite in a data center that is internet-facing or hosted on-premise. With this model, almost everything is the customer’s responsibility.
Provider vs. Consumer Responsibilities
With cloud hosting providers, the responsibility for them is the security of the cloud. In other words, they are responsible for keeping the software (compute, storage, database, networking, etc.) and the hardware or infrastructure (regions, zones, edge, etc.) all secure.
For customers of cloud providers, the responsibility is for security in the cloud. Where providers take on backend protection, the customer is responsible for the security of the usage information. This includes:
- Data
- Access
- Applications
- Identity Management
- Operating Systems
- Network Security
- Firewall Configurations
- Encryption/Decryption
This is a lot of information to track for the customer in the cloud. According to Gartner, through 2023, at least 99% of cloud security failures will be the customer’s fault. This is not a hard pill to swallow, considering the immense amount of responsibility and the significant shift for organizations to a cloud model.
How Cloud Security Architecture Varies By Service Model
SaaS
SaaS is an application you can purchase from a cloud provider or a company that is hosted in the cloud. With this model, the customer is only responsible for managing the application, and the provider typically handles security for the backend. Examples of SaaS include Salesforce, Microsoft 365 and Dropbox.
The primary threat for organizations adopting SaaS is very much the same as other applications. Phishing is still a significant problem with these applications, as attackers will try to gain access by getting you to give them your login credentials. Along these same lines, credential exposure and insider threats will be something to look out for.
To thwart these threats in SaaS, customers should consider improving their SaaS security architecture and getting CASB, or Cloud Access Security Brokers, to assist with securing these applications by giving users visibility, access controls and data protection using APIs, proxies and/or gateways.
IaaS
IaaS is where organizations can purchase infrastructure from a cloud provider. The systems and networks can be instantly established, and companies install their own operating systems, applications and middleware. Examples of IaaS include Azure and Rackspace.
The security threats for IaaS are the same as your typical on-premise threats. Since the organizations are installing the operating systems and applications, they are responsible for the security that goes with it — threats like vulnerabilities, malware, insider threats and credential exposure.
With these threats, you will want to have standard security tools and cloud-specific tools in place — things like Endpoint Protection (EPP), CASBs and vulnerability management. Other pieces to implement would be access management, data encryption and network encryption. Using these in conjunction with each other creates a better security strategy by creating layers of security. These protections are critical, especially when Gartner expects that 50% of enterprises will unknowingly and mistakenly have exposed some IaaS storage services, network segments, applications, or APIs directly to the public internet by 2021.
PaaS
PaaS is where organizations can purchase a platform from a cloud provider. This allows the company to develop, run and manage applications without addressing the underlying infrastructure that is usually required for running the applications. Examples of PaaS providers include AWS, Oracle and Google for their respective platforms.
When it comes to threats and PaaS, the primary things you will encounter are mostly self-inflicted. Using defaults in the application configurations leads to compromises of the application itself. Other issues usually fall under the category of permissions on the cloud data and leaving it exposed to unauthorized access. One last thing to remember is the use of SSL, as improper implementation can lead to leaks.
Securing your PaaS environment requires using some usual cloud-style security and some non-standard security applications. For instance, you will still want to have a CASB to enforce security policies and access. Nevertheless, you will also want to implement a Cloud Workload Protection Platform (CWPP). This will give you visibility and protection into the workload, moving through different environments and vendors.
At GuidePoint, we’ve developed a model for Security in the Cloud for IaaS and PaaS services provided by the largest Cloud Service Providers. If you want to dive further, check out our white paper, The Five Phases of Cloud Security Architecture.
How to Evaluate a Cloud Security Maturity Model
The cloud security maturity model (CSMM) consists of guidelines that may or may not fit every organization. It is a good starting point to help guide investment decisions into specific areas of a cloud environment.
There are different maturity models from various organizations. It is best to look into the one that makes the most sense for your organization.
Authentication should be a top priority, considering the number of attempts to compromise this entry point and user identities. Things to look for or to ask your cloud service provider about include:
- Do you have multi-factor authentication methods?
- Do they allow for Single Sign On (SSO)?
- Do you integrate with enterprise authentication and directories?
Past security issues should be taken into account when evaluating how they handled other security incidents and their quantity. For example:
- How many breaches have they experienced as a company?
- Have they ever hosted malware in their cloud?
- Do they perform regular penetration tests on their environments?
Policies, compliance information and documents are also important documents and philosophies to take into consideration. How your cloud service provider handles their security will help you know how they will handle your security. Will they tell you when there is a breach and disclose the information to you? These are all very valid questions when evaluating providers.
When evaluating your cloud security provider, it’s best not to leave any stone unturned. Your organization’s security is not something to take lightly, and you want to be as informed as possible when you make decisions.
Remember that not all cloud security models are created equal. In one, you may manage the majority of the environment’s security, whereas in the other you control only certain areas. Know your cloud model first and foremost so that you can define your cloud security architecture.
GuidePoint Security’s expertise and agile approach allow us to provide complete, thorough reviews of your cloud security architecture. Learn more about our cloud security services and how they can keep you one step ahead of threat actors while ensuring your business operations continue with no interruptions.
Romke de Haan
Romke de Haan has over 22 years of experience as a technical & business leader and technology strategist. Romke has worked with commercial corporations such as Microsoft, Razorfish, & Kohl’s as well as federal agencies including the General Services Administration, Environmental Protection Agency, and Transportation Security Administration.
Romke has provided technology leadership in digital transformation and innovation through the design of data driven and UI-focused systems hosted both in the cloud and on-premise. In working with federal agencies such as the TSA, Romke helped lead cloud migration initiatives by transforming organizational practices from siloed structures and waterfall methodologies to Agile delivery methods such as DevSecOps through CI/CD pipelines.
Romke’s skillset not only includes technology but also includes UI design and business strategy allowing him to better align digital transformation initiatives with the needs of the business. Romke has served in various roles including application architect, developer, mentor to startups across the US and South America, and civic initiatives such as being a founder member of Milwaukee’s Code of America chapter.