Without a Solid Cloud Security Architecture, Overall Strategy Weakens
Written By: Rob Deane
Share this post
One of the overlooked and most misunderstood activities that must be performed to successfully leverage cloud computing technologies is the creation of a cloud security architecture. The strategy should be designed to help an enterprise both secure and showcase data assets and applications that will be resident in the cloud through the lens of shared responsibility with cloud service providers (CSPs). The goal of instituting a cloud security architecture is to identify and help eliminate security weaknesses that may result from a primarily product-driven approach to security.
It is important to understand the nuance between cloud security controls and cloud security architecture when preparing for a move to the cloud. A properly developed cloud security architecture is driven by threats facing an enterprise whereas cloud security controls are tactical measures taken to reduce information security risks. By first focusing on threats, we will begin to see the interrelationship between users, cloud environments, service providers, and applications. The enumeration of threats as part of your cloud security strategy will also play a major role in limiting security control redundancies, thereby reducing capital and operational costs.
Key Elements of a Cloud Security Architecture
Whether you are migrating existing applications to the cloud or are building them in Amazon Web Services (AWS), Microsoft Azure (Azure), or Google Cloud Platform (GCP), there are security aspects that are shared with the cloud provider. The design of a cloud infrastructure requires the cloud security professional to consciously think about things such as the attack surface presented by web-enabled interfaces, the criticality of information assets, and the various attack vectors that may be leveraged by a malicious actor. The primary goal of a cloud security architecture is to marry these functional elements of the strategy with the architecture plan. Here is a sample of the elements to consider when embarking on any cloud journey.
Build Security at Every Layer
There are a number of individual security technologies that need to be selected, deployed, configured, maintained, and monitored for a secure cloud infrastructure. The best way to approach this task is to understand the scope of the effort in the context of the cloud security stack. It may be simplest to think of this in terms of layer — orchestration layer, hypervisor layer, application layer, guest system layer, network layer, and physical layer. The protection of any cloud infrastructure requires multiple technologies and processes that will be dictated by deployment models, the sensitivity of data being stored, and regulatory requirements. Only by applying a defense-in-depth strategy and applying practices like automatic operating system updates, secure coding, and activity monitoring can you reduce exposure to outside threats.
Redundant and Resilient Design
One of the key cloud security architectural components is the disaster recovery plan. It’s necessary to have in place should your cloud infrastructure fail or something even more devastating occur, such as a ransomware attack. This includes maintaining any backups that will be required to resume full operational capacity. Another aspect of cloud security architecture that cannot be ignored is resiliency. Some may believe that resiliency is centered around application design, but the reality is that the infrastructure layer, network, and data must also be considered a part of the equation.
Centralized Management of Components
This is the practice of funneling the vast amount of security-related data from the full complement of tools deployed in the cloud infrastructure through centralized processes and personnel. The effort ensures a comprehensive view of the cloud security status, which is especially important in multi-cloud scenarios where cloud service brokers are often used to centralize and integrate all cloud management into one place. For less complex cloud environments, a single product or platform that can integrate into all provider environments to enable control of security policy and access management without dependency on the underlying cloud infrastructure may be used.
Elasticity and Scalability
Before building out your cloud security architecture, it is critical that you understand the thresholds that need to be established so you can design to the correct horizontal or vertical scale. Horizontal scaling refers to the provisioning of additional servers to meet the needs of the business, often splitting workloads between servers to limit the number of requests any individual server is getting at one time. Vertical scaling is essentially resizing a server with no change to code. It is possible to increase the capacity of existing hardware or software by simply adding resources. One caveat is that vertical scaling is limited by the fact that you can only get as big as the size of the server.
Alerting and Notifications
Even if an organization does everything else right, not having the appropriate alerting and notifications integrated into your cloud security architecture will haunt you in the end. How all of the cloud components interact with each user is critical to understanding what is happening within your cloud environment. Cloud and infrastructure events that are created by the security tools deployed, as well as logs enumerating application and user events, will play an important part in the discovery process should a security event or an operational issue arise in the future.
Appropriate Storage for Deployments
There are many different types of storage available in the cloud and it’s essential to understand each type and select the ones that are best suited for your deployment. Each storage option will likely have its own unique security options. The type you choose should take into consideration your organization’s data classification and data security policy before settling on a particular storage security design.
Centralization, Standardization, and Automation (CSA)
One of the final elements to emphasize in cloud security design and architecture is centralization, standardization, and automation (CSA). The term centralization in this context means that when you are choosing tools and cloud services, you want them to be able to integrate into a single dashboard to provide visibility for those managing cloud resources. In many cloud deployments, numerous management tools, dashboards, and interfaces begin to accumulate over time. One potential solution to this challenge is to use the same vendor products across as many cloud environments as possible.
If automation is the principal idea behind DevOps, it is reasonable to say that DevSecOps is also driven by the concept. Manually running cloud security tools is not a sustainable solution. Necessitating the automation of security controls (along with orchestration) can go a long way in reducing the burden of protecting these environments.
Cloud Security Architecture and the Shared Responsibility Model
If there is one essential understanding every company should have with its Cloud Service Provider (CSP), it is the division of responsibilities between the company and provider for securing the cloud environment. A shared responsibility model will be instrumental in defining security ownership by expressly dictating the assets, processes, and functions each party owns.
Infrastructure/Platform as a Service Shared Responsibility
It is important to appreciate the nuances in coverage across CSPs. For example, Amazon Web Services (AWS) claims responsibility for “Security of the Cloud,” which includes protecting the infrastructure that runs all of the services offered in AWS Cloud. This infrastructure is composed of the hardware, software, networking, and facilities that run AWS Cloud services. By comparison, Microsoft Azure claims responsibility for physical hosts, physical network, and physical datacenter. Regardless of CSP, there will be variations in responsibilities depending on service type (e.g., IaaS, PaaS), which include security controls around application/platform software, operating system, and local networking and virtual machine/server instances. Navigating who will be responsible for each security task can sometimes be extremely complex given the fact that many companies subscribe to a multi-cloud environment.
Uncertainty Around Shared Responsibility Models
There are distinct differences in regard to security responsibilities depending on whether the company is standing up an IaaS or PaaS environment.
In an IaaS (server-based) deployment, the company is most likely going to assume full responsibility for Identity and Directory infrastructure, applications, network controls and operating system.
If a PaaS (serverless) deployment is the solution of choice, the company is responsible for securely configuring the control plane. While the provider will often provide management of the physical implementation of the company’s identity and directory infrastructure, applications and network controls, the company is still on the hook for configuring access management through the control plane.
This may appear to indicate that a great deal of security tasks still lie with the company, but cloud vendors still maintain full control over the virtualization layer as well as the physical hosts, network, and datacenter.
Cloud Security Architecture Design Patterns
Designing the appropriate security controls that protect the confidentiality, integrity, and availability of information in the cloud can play a major part in managing cloud security threats. These security controls can be provided by the cloud provider, the enterprise, or even by third party service providers. There are essentially two levels of design patterns used in cloud security architecture — high level and custom.
High-level design patterns are primarily focusing on activities that establish the necessary security controls, which describe the interaction between the functional elements of the enterprise security architecture. Trust boundaries, which define the logical perimeter that spans beyond physical boundaries to represent the extent to which cloud-based IT resources are trusted within an established cloud ecosystem, are also critical to operate in the cloud successfully. Standard interface points, encryption models, and security event logging are further components that make up standard design patterns. Enterprises that opt to develop their own cloud applications can use custom cloud design patterns to create a secure application access framework.
A few examples of cloud security architecture design patterns are:
Federated identity pattern – used to delegate authentication responsibility to an external identity provider.
Gatekeeper pattern – used to help protect applications and services by using a dedicated host instance that acts as a broker between customers and the application or service. It works by validating and sanitizing requests and passes requests and data between them.
Valet key pattern – uses a token that provides customers with restricted direct access to a specific resource to be able to offload data transfer from an application. This is appropriate for applications that leverage cloud-hosted storage systems and can serve to maximize scalability and performance.
Taking the time to come to agreement with the cloud provider on security controls will allow the enterprise to build security into the system design process and alleviate the need to add additional safeguards in the form of bolt-on solutions. If security principles and architectural patterns are created during the design phase, appropriate security controls will not be overlooked. Ultimately, the enterprise cloud security architecture should support the need to protect the confidentiality, integrity, and availability of all data processed or stored in the cloud.
Cloud Security Architecture Planning and Best Practices
Cloud security architecture is basically a strategy to secure and view an enterprise’s data and applications in the cloud by sharing security tasks with cloud providers. It is now expected that cloud-enabled innovation be a part of the DNA of an enterprise if it intends to remain competitive. A cloud security architecture should reduce or eliminate gaps in security that product-driven solutions are likely to leave behind. Also, cloud security reference architectures and design patterns can be reused in future environment builds. This reuse enables enterprises to leverage established security expertise to speed up development and improve security.
Conduct Due Diligence
As enterprises consider the growing number of cloud service options available today, security challenges will certainly arise as they move to cloud and consume cloud services. Regulatory pressures will require enterprises to carefully consider the safeguards put in place by each cloud provider that address topics such as security, privacy, and trust.
Many cloud security architects are turning to checklists created by Microsoft and AWS that are aligned to international standards to help guide discussions about moving to the cloud. These checklists serve to raise key considerations to be taken into account during cloud migrations. If using a checklist for due diligence evaluations, enterprises need to define the enterprise cloud requirements for applicable checklist elements, define the project specific requirements, and assess project options accordingly.
Determining Data Sensitivity
Developing an effective strategy for securing sensitive data requires a clear understanding of the high-level data security patterns and the alignment of these patterns to the providers available cloud security controls. Enterprises can apply these security controls to implementation-level details specific to data stores, such as Amazon Database Service (Amazon RDS), Amazon DynamoDB, SQL Database, and Azure DocumentDB (for example).
Bring Employee Cloud Usage Out of Shadows
It is an unfortunate fact that many enterprises rush moving data to the cloud without informing the information technology or security teams. While there is no arguing that cloud computing can often prove to be exceptionally convenient and valuable to the business, unmanaged adoption of cloud services can leave sensitive or proprietary data exposed. When employees begin taking advantage of their favorite cloud-enabled tools and applications instead of ones authorized by the enterprise, it is not unusual for them to use personal credentials to access those services, thereby putting proprietary company data at risk. The security and compliance implications alone can be a strong argument for reigning in these unsanctioned practices.
Endpoint Security Solutions and the Cloud
The flexibility, elasticity, and cost savings of cloud computing is driving enterprises away from traditional to cloud-enabled computing models. Responsible cloud adoption requires evaluation of business requirements to ensure protection, visibility, speed, and scalability. Endpoint solutions that operate seamlessly in the cloud have evolved from antivirus solutions to fully integrated suites for the protection of information assets in any cloud environment that includes advanced capabilities such as User and Entity Behavior Analytics (UEBA).
As with the adoption of any new technology, there are challenges to overcome. There is a lot to consider when building your cloud security architecture, but the benefits to the overall security strategy are worth the effort. By getting the fundamentals right, your organization will be able to embrace all the cloud has to offer while reducing exposure to threats.
The team at Security Compass Advisory has experience doing just that. We partner with you to understand your current cloud security posture and design solutions that will help you grow your business profitably and securely. Find out more about our cloud security services here.