Introduction
The pervasive “aaS” (as a Service) models introduced by cloud computing, combined with the use of declarative infrastructure-as-code and controls-as-code has radically altered how we think about securing enterprise environments. For those of us who have been in the field for some time, adapting our security reasoning the public cloud requires not just a mere update, but possibly the most significant mindset shift since distributed computing. To quote Bank Negara Malaysia (BNM):
“The use of cloud services may represent a paradigm shift in technology operation management as compared to on-premises IT infrastructure.”
During our inaugural Cloud Technology Risk Assessment Guidelines (CTRAG) workshop in Kuala Lumpur in August 2023 (before it became Appendix 10), many of the most upvoted questions were related to security and privacy. This post is a primer into designing security controls in the cloud along with an overview of fundamental concepts and safeguards in Amazon Web Services (AWS). In the appendix, we also address the most commonly raised concerns around privacy, co-mingling and logical isolation in the cloud as submitted during our 2023 workshop.
Understanding the AWS Shared Responsibility Model
In the second blog post of this series we allude to the shared responsibility model in the context of regulatory cloud risk assessments. BNM highlights the concept of shared responsibility early in the risk management section of Appendix 10, this reflects how foundational the concept is in understanding cloud governance and security.
The model divides the security obligations between the cloud service provider (CSP) and the client. For example, the CSP is responsible for securing the infrastructure that runs the cloud services. Infrastructure such as servers, routers, global networks, and data centres. The client is responsible for securing anything they put in the cloud, such as their data and applications.
The ‘line’ is Not Fixed
The concept of shared responsibility varies significantly across the different infrastructure models: On-Premises, Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Function as a Service (FaaS), and Software as a Service (SaaS).
In an On-Premises environment, the entire responsibility for security rests with the organisation. The organisation must manage everything from the physical servers to the software applications they run. This model offers the highest level of control but also requires significant resources and expertise to maintain security.
IaaS cloud services, such as Amazon Elastic Compute Cloud (Amazon EC2), offer shared responsibility. Here, the cloud provider is responsible for the physical infrastructure, including data centres, servers, and storage hardware. The customer, however, is responsible for managing the operating system, applications, and data. This model reduces the burden of physical security and hardware maintenance but requires customers to actively manage and secure their virtual infrastructure.
PaaS and FaaS services such as AWS Lambda will move the line even further “up”, with the cloud provider now assuming responsibility for the operating system, middleware and runtime environment for the customer’s code.
Security of the Cloud, a.k.a. “below the line”
Essentially, controls below the line are outsourced to the CSP. However, BNM expects FIs (Financial Institutions) to understand these controls, factor them into cloud control frameworks, and obtain assurance on those controls from the CSP to satisfy compliance and audit requirements.
AWS offer various compliance and assurance reports, such as SOC1, SOC2, and ISO 27001, which are conducted by independent third-party auditors. These reports provide transparency into AWS’s security and compliance controls, giving clients a clear understanding of how their data is protected.
AWS Artifact simplifies the process of obtaining necessary compliance information and the mentioned compliance reports. Instead of going through a lengthy request or verification process, clients can instantly download the required documents. Note that Artifact does require an AWS account to access.
Security in the Cloud, a.k.a. “above the line”
Controls above the line are those the FI is responsible for. Let’s highlight a few key control objectives and how these translate in cloud terms.
1. Identity and Access Management
- Enforce ‘Least Privilege’: Roles and permissions should be strictly limited to what individuals and services absolutely require to perform their tasks.
- Strong authentication: Use Multi-Factor Authentication (MFA) for all users, especially those with elevated permissions.
- Audit and monitor Identity and Access Management (IAM) activities: Use automation to monitor and record IAM activities for compliance and forensic analysis; setup alerts for unusual activity.
Many cloud breaches involve some element of excessive permissions; it is therefore highly valuable to use CSP tools to continuously prune permissions through ‘least privilege’ reviews.
2. Data Security
- Encryption: Encrypt data at rest and in transit using AWS encryption services like AWS Key Management Service (KMS) and AWS Certificate Manager.
- Data Backup and Recovery: Implementing robust backup strategies and test recovery procedures is significantly easier to achieve in the cloud – take advantage of AWS tools to automate this.
- Spot misconfigurations: Implement detective rules to catch unencrypted data storage.
Unencrypted data is a prime target for attackers. Encrypting data at rest and in transit significantly reduces risk and mitigates the impact of a potential breach.
3. Virtual Private Cloud (VPC) Security and Networking
- Secure Network Access: Implement security groups and network access control lists (NACLs) to control inbound and outbound traffic to AWS resources.
- Segregation: Use subnetting within a VPC to segregate different environments (e.g., production, development) and limit communication between them.
- Use VPC Flow Logs and continuously monitor network traffic and identify anomalies.
Misconfigured or loosely controlled networks can be exploited by attackers to move laterally, so ensuring security groups and NACLs are correctly configured can prevent unauthorised access.
Leveraging Cloud for Enhanced Security
Many of your existing security functions – while adjusting to the cloud – will continue to play a vital role. For instance, application security remains paramount and needs to be embedded into your increasingly agile Software Development Life Cycle (SDLC). Having the most secure cloud architecture can only go so far if you deploy a vulnerable application and expose it publicly.
Compared to traditional on-premises management, the cloud offers unparalleled advantages in enhancing security postures for organisations of all sizes. One of the key benefits is the simplification and automation of security controls deployment. Using Service Control Policies (SCPs) you can enforce permission policies across multiple AWS accounts, effectively enforcing guardrails which further enforce the principle of least privilege.
Infrastructure as Code (IaC) has transformed how we deploy and control assets and environments. IaC checks offer a proactive approach to security, allowing teams to embed compliance and security standards directly into the code that defines their infrastructure. This means that security is not an afterthought but an integral part of the infrastructure provisioning process – this is very much at the core of Sourced Group’s (Sourced) cloud platform philosophy.
At Sourced we are strong proponents of designing tailor-made control strategies for each organisation using the right combination of preventive and detective controls. As DevSecOps enthusiasts we always seek to minimise friction for developers by striking the right balance between the various types of controls at the organisation’s disposal.
Addendum: Addressing Cloud Security and Privacy Concerns
Let’s address some common questions and concerns that are particularly relevant for those towards the beginning of their cloud journey. These queries often stem from word-of-mouth, inappropriate use of on-premises principles, or issues that might have been relevant in the past but well-addressed in today’s cloud landscape.
How do I know my resources are segregated from other users’ resources?
AWS ensures that the data and resources of different users are kept distinct and secure through isolation mechanisms. These mechanisms also ensure that each user is not affected by the actions of other users on the same platform. AWS employs various types of isolation, which include:
Hypervisor Security
In an IaaS model, AWS uses a hypervisor to create virtual machines (VMs) for each customer on the same physical server. This hypervisor ensures that each VM is completely independent and unaware of other VMs on the same server. For instance, if two companies are using EC2 instances, they may be on the same physical server but are logically separated by the hypervisor, preventing any data crossover.
Network Isolation
AWS provides tools like Virtual Private Cloud (VPC) that allow customers to create a logically isolated network within the AWS cloud. This network is dedicated to a single customer and is isolated from all other networks in the AWS environment. Inside a VPC, subnets, security groups, and network access control lists (ACLs) further refine isolation and access control.
Storage Isolation
AWS ensures that data stored in services like Amazon Simple Storage Service (Amazon S3) or EBS (Elastic Block Store) is logically separated from other users’ data. This is achieved through unique identifiers and access management controls, ensuring that a user cannot access another’s data.
To reinforce these isolation mechanisms, AWS employs continuous monitoring and encryption. Monitoring involves the use of automated tools to constantly scan for unusual activity or potential security breaches. Encryption adds an additional layer of security, ensuring that, even if data were somehow accessed, it would be unreadable without the appropriate decryption keys.
Can AWS employees access my data?
AWS has internal governance policies and procedures in place to regulate employee access to client data. These include strict role-based access controls, mandatory security training for employees, and regular audits.
Any employee access to client data, whether requested by the client or due to legal obligations, goes through a rigorous internal review process. This process involves multiple levels of approval to ensure that the access is justified and compliant with AWS policies and legal requirements.
Client-Requested Access
When a client requests AWS to access their data, AWS first verifies the authenticity of the request. This involves ensuring that the request comes from an authorised representative of the client.
AWS employees do not have default access to client data. If a client requires AWS to access their data, they must explicitly grant permission. This can involve providing temporary credentials or setting specific IAM roles that permit limited access to AWS personnel.
Any access by AWS employees is logged and closely monitored. AWS maintains comprehensive access logs, which clients can audit to understand who accessed their data and why.
Legal Requests for Access
If AWS receives a legal request to access a client’s data, it first assesses the validity and legality of the request. AWS is known to scrutinise such requests to ensure they comply with legal standards and their own policies.
Unless prohibited by law, AWS typically notifies the client about the legal request. This gives the client the opportunity to respond or challenge the request.
If the legal request is deemed valid and AWS is compelled to comply, they will access the client’s data as required. This access is conducted under strict protocols to ensure minimal and specific compliance with the request.
The Impact of Encryption
AWS offers clients encryption services for their data. If a client uses AWS’s encryption mechanisms, the decryption keys can be managed by the client, not AWS (depending on how the service was configured). In such cases, AWS cannot decrypt the data without the client’s keys.
If AWS is legally required to access encrypted data, it will need the client’s cooperation to decrypt it. Without the keys, AWS cannot access the encrypted content.
For clients using AWS Key Management Service (KMS), the keys are managed by AWS but with strict controls. AWS employees do not have direct access to these keys. Access to KMS is logged and audited.
Has AWS had any security breaches targeting its service fabric or that resulted in unauthorised cross-tenant access?
While no system can be entirely immune to security threats, AWS has a strong track record in safeguarding its service fabric and preventing unauthorised cross-tenant access. AWS employs a comprehensive security model that includes physical security, operational security, and software security, significantly reducing the risk of such breaches.
Several incidents have been reported over the years, though it is important to note that these breaches often involved customer misconfigurations rather than inherent vulnerabilities in AWS’s service fabric itself.
Further Reading
The following resources offer further insights into how AWS maintains security within its cloud environment, and they can be helpful to clients looking to understand and comply with various security and compliance objectives.
- The Introduction to AWS Security whitepaper serves as a primer for understanding AWS’s security aspects. It offers an overview of the AWS platform’s design, focusing on high availability, dependability, and the tools necessary for running a wide range of applications securely. https://docs.aws.amazon.com/whitepapers/latest/introduction-aws-security/welcome.html
- The Security and Compliance Overview whitepaper delves into how AWS prioritises cloud security, assisting organisations in evolving their security, identity, and compliance strategies to suit the cloud environment. It is helpful to understand the broader context of cloud security in relation to AWS services.
https://docs.aws.amazon.com/whitepapers/latest/aws-overview/security-and-compliance.html
Max is a lead consultant at Sourced and brings over 15 years of extensive experience in security and risk management. His expertise lies in identifying and solving complex security and compliance issues, both at technology and process level.
Thomas is a Lead Consultant at Sourced with over 18 years of experience in delivering digital products. He gained a passion for evangelising Serverless architecture through his enthusiasm for cloud and entry into the AWS Ambassador programme.
Ian is the Head of Consulting for Sourced Group ASEAN. Based in Singapore, he has more than 10 years of experience in cloud transformation, and is a former AWS Ambassador and AWS APN Cloud Warrior. With a strong background in security, compliance and software delivery, Ian specialises in cloud transformation for financial institutions and other large enterprises.
