Like the other Big 3 CSPs, AWS follows a shared responsibility model and offers security guardrails to protect the platform and the underlying hardware. Nonetheless, AWS customers are expected to implement native or third-party security measures in order to keep their cloud workloads secure.
Which security measures you’ll need to implement will depend on the cloud resources being used. As an AWS customer, you must also adhere to basic AWS security guidelines that will enable you to reduce your attack surface and secure workloads fast.
In this article, we explore some of the basic security measures you can implement to protect your workloads in AWS.
AWS IAM policies and permissions
AWS IAM policies define permissions that are allowed or denied on cloud resources. The commonly used policy types are identity or resource based. In identity-based policies, permissions are attached to identities (i.e., users, groups, or roles). Resource-based policies, on the other hand, are mapped to specific AWS resources and define the actions and the conditions under which they can be performed by a principal (e.g., Amazon S3 bucket policies).
In addition to identity and resource-based policies, options like permission boundaries decide the maximum allowable permissions in a resource policy, access control lists, organizational service control policy, session policies, and more. When designing the landing zone for your workloads in AWS, it is recommended to use the right combination of these policies and access restrictions to ensure the principle of least privilege (PoLP).
AWS Control Tower
AWS Control Tower streamlines AWS resource usage through automation and orchestration of security and compliance settings. This is helpful for new customers with multi-account deployments, as the service helps to set up a secure landing zone for your applications.
Control Tower can be used to programmatically provision, manage, and maintain AWS accounts with built-in security configurations and compliance policies. For example, you can set up controls to restrict the deployment of resources in a different geography that might go against your data residency rules. The service configures some mandatory security guardrails, such as disallowing IAM role changes, cross-region networking, and public access of log archives. Customers can also choose to set up optional guardrails in accordance with the organization’s security requirements.
Account management
AWS Organizations offers a logical grouping to facilitate centralized management of multiple AWS accounts. Grouping workloads in AWS accounts that require a common set of controls is recommended. This helps with centralized security management of these accounts and streamlines the monitoring process.
You can group AWS accounts hierarchically and map specific access controls to them using organizational units (OUs). The organization’s management account can use service control policies (SCPs) to define maximum allowed permissions as well as the AWS resource access conditions for individual member accounts.
AWS CloudFormation aids with infrastructure-as-code implementation. It enables automated deployment of a group of AWS resources—referred to as stacks—in a single account or via stacksets in multiple accounts. In addition, you can integrate PoLP into the AWS CloudFormation deployment process using permission boundaries that define the maximum permissions that can be assigned to an IAM identity through an IAM policy. With permission boundaries and AWS CloudFormation, you can ensure that only pre-authorized services are deployed in your AWS accounts while using only the required permissions.
Layered networking
While deploying workloads in AWS, ensure that the workloads with the same network routing and reachability requirements are segmented into the same subnet. For example, placing databases in a subnet with no direct internet access helps reduce the attack surface. Frontend workloads can also be placed in a subnet with restricted access from the internet. A layered deployment like this will ensure that any compromised resources in one of the subnets are contained within that perimeter.
Route tables help define the allowed traffic routing paths inside a subnet. Applying a defense-in-depth strategy, you should implement the required controls for both ingress and egress traffic of workloads connected to your VPC. This includes the usage of network ACLs, route tables, subnets, and security groups (stateful inspection firewall). You can also streamline access from on-premises networks to AWS VPC by using the AWS Transit Gateway, which serves as a central hub for connectivity requirements.
Compute infrastructure security
According to the AWS shared responsibility model, the customer is responsible for the vulnerability and patch management of resources like Amazon EC2 and Amazon Machine Images (AMI). Customers can automate the process through the AWS Systems Manager Patch Manager service. Patch Manager offers timely installation of patches, service packs, and updates in order to protect your operating system and applications.
Customers can reduce the attack surface of compute instances by using hardened Amazon Machine Images. You can prebuild the images by integrating the required patches and security controls, and they can only be dynamically modified by authorized users through tools like Systems Manager.
At the software layer, the AWS Signer managed code-signing service ensures the integrity of the code running on your deployments. It detects code tampering by validating against a digital signature.
Data protection
Data protection in the cloud starts with the basics: encryption of data at rest and in transit. The encryption approach should address encryption key creation, storage, access control, and periodic rotation. The AWS Key Management Service (KMS) can be leveraged here to store and manage encryption keys securely.
KMS integrates with a number of AWS services out of the box and streamlines the process. The keys stored in KMS are protected by FIPS 140-2 validated hardware security modules, ensuring comprehensive protection of your data encryption keys. Encryption should also be enforced for data in transit through different native options for https redirection, i.e., Amazon Cloudfront, Application Load Balancer, etc.
In addition to encryption of data, implementing restrictions on public data exposure is a must. You should also implement least-privilege access to the data layer. Mandatory access control mechanisms like AWS S3 Object Lock and Glacier Vault Lock will also help to prevent data tampering.
Workload security
Integrating security as an add-on later in the application lifecycle can prove costly. Hence, it is important to identify workload security and compliance requirements from day one and to incorporate effective mitigation mechanisms.
Subscribing to the CVE lists of publicly disclosed security vulnerabilities will allow you to monitor the ever-evolving cyber-threat landscape. You can also leverage managed AWS services such AWS Shield and AWS Security Hub in such cases. AWS Shield provides real-time visibility into the network-level security of your workloads as well as detailed insights on organized DDoS attacks. AWS Security Hub offers cloud security posture management, reviewing your deployments against security best practices and detecting any deviations.
When deploying applications through CI/CD pipelines, you should also integrate the relevant security controls into the process, such as scanning of machine images and reviewing IAC templates against security baselines.
Identity protection
Your identity and access management controls are the key to your cloud environment; stolen or compromised credentials are often the first step in any cyber attack. It is crucial therefore to get the basics right, such as having a strong password policy in AWS IAM or the identity systems used for your workloads. User accounts, especially administrator accounts, should be protected through multi-factor authentication (MFA) enforced through IAM policies for enhanced identity protection. AWS Secrets Manager can help you securely store and manage the secrets your application uses to access other third-party services.
AWS Secure Token Service (STS) can be used to create short-term temporary credentials to access AWS resources. It eliminates the overhead of account management such as the need to rotate and revoke credentials. Since access through temporary credentials is time bound, this reduces the likelihood a leaked credential could cause extensive damage.
It is recommended to use a centralized identity provider so that access to all your AWS resources can be managed from a single location. You can also federate your existing identity service providers compatible with SAML 2.0 and OpenDI Connect (OIDC) with AWS IAM for ease of operations, especially in multi-cloud and hybrid cloud deployments.
Third-party integrations for AWS Security
With the cloud threat landscape constantly evolving, it is important to consider specialized tools in addition to the native AWS security guardrails discussed here. Processes for prioritizing and mitigating risks must be quick, effective, and as automated as possible.
The Vulcan Cyber® risk remediation platform enhances the security posture of your environment by enabling end-to-end risk lifecycle management for your AWS workloads. Vulcan’s AWS connector collects information on available AWS resources and analyzes them for security vulnerabilities.
For hybrid and multi-cloud deployments, Vulcan Cyber analyzes your resources and offers centralized visibility and comprehensive data about your threat landscape. This provides contextual insights of the vulnerabilities and their impact on different resources in the environment. Our remediation intelligence offers remediation recommendations like patch updates or scripts allowing you to fix the identified vulnerabilities fast.
Streamline your cloud vulnerability management with Vulcan Cyber. Claim your free 30-day trial, and start owning your risk.
