Firewalls are among the most useful information security and compliance tools. Their role is to monitor traffic moving between network borders to determine whether it should be allowed to pass. Among other responsibilities, firewalls prevent unauthorized access to networks on which sensitive data is stored, making them an essential tool for businesses seeking to comply with regulations and standards that include HIPAA, PCI DSS, GDPR, SOC 2, and more. 

This article explores the AWS Network Firewall, a firewall available to businesses that host sensitive data on the Amazon Web Services (AWS) platform. 

What is the AWS Network Firewall?

AWS Network Firewall is a managed, auto-scaling firewall and intrusion detection and prevention service that protects Amazon Virtual Private Clouds (VPCs). It monitors and filters unwanted and unauthorized traffic into and out of VPCs. AWS Network Firewall is one of several firewalls available on the AWS platform, including Security Groups, Network Access Control Lists, and the AWS Web Application Firewall.

The AWS Network Firewall is designed to be straightforward to use and to require minimal infrastructure management following the initial deployment. As a managed service, it can be deployed quickly. It scales automatically with network traffic, removing the need for businesses to build and operate infrastructure to support essential network traffic monitoring and filtering. 

AWS Network Firewall is in scope for a wide range of AWS compliance programs, which means it can be used as part of a secure system that complies with HIPAA, PCI DSS, FedRAMP, and other frameworks. However, it should be emphasized that using AWS Network Firewall is not sufficient to achieve compliance with any framework; compliance is ultimately the responsibility of AWS users. 

AWS Network Firewall Features

We’ve already discussed some of AWS Network Firewall’s headline features: it’s a managed service for monitoring and filtering network traffic to and from Amazon VPCs. But there are other features that set it apart from alternative firewall services on the platform. 

  • AWS Network Firewall operates as both a stateless and stateful firewall. Users can configure stateless rule groups that examine packets in isolation or stateful rule groups that consider the packet’s context; for example, is the packet a response to a request from a particular IP address?
  • It is a high-availability auto-scaling firewall. As a managed service, Amazon handles redundancy and scaling, so users can rely on their firewall’s infrastructure to grow and shrink in line with demand. 
  • AWS Network Firewall includes an intrusion detection and prevention system. It monitors the flow traffic in real-time and can adapt to protect networks against vulnerability exploits and brute force attacks. 
  • AWS Network Firewall integrates with other AWS security services, including the AWS Firewall Manager, allowing users to consistently organize and manage rule groups and policies. 
  • Users can take advantage of managed rule groups, predefined rules that Amazon automatically updates to account for new software vulnerabilities. Managed rule groups significantly reduce the time and effort required to keep rules up-to-date. 

We’ve highlighted some of the most attractive features here, but you can see a complete breakdown of AWS Network Firewall features in the service’s documentation. 

Is AWS Network Firewall Layer 7?

AWS Network Firewall operates at Layers 3-7. These numbers refer to the OSI Model, which divides network communications into seven layers. Traditional firewalls operate at Layer 3, the network layer. They can inspect and filter packets traveling over the network, but they cannot, for example, identify attacks that exploit vulnerabilities in web applications—they have no insight into protocols that operate at Layer 7, the application layer.

In contrast, AWS Network Firewall can filter VPC network traffic at the network, application, and other layers. It is a flexible network filtering and intrusion detection service that complements AWS’s other firewall services. 

What Are AWS Network Firewall Deployment Models?

To understand AWS Network Firewall deployment models, we first need to discuss how the firewall works. In short, network traffic to the VPC is routed to a firewall end-point to be examined before it enters or exits the network. The firewall endpoint is deployed within a subnet of a VPC. Ingress and egress traffic flows through the firewall endpoint subnet and then to other protected subnets containing your cloud infrastructure. 

Deployment models influence where the firewall endpoint subnet is deployed. In a typical distributed deployment model, a firewall subnet is deployed into each virtual private cloud—each VPC has its own firewall subnet. This model allows VPCs to have an independently managed firewall with a unique firewall policy. It is typically used to monitor and filter traffic between the internet and a protected subnet, although there are other use cases. 

In contrast, a centralized deployment model uses a centralized VPC into which one or more firewall subnets are deployed. This model is often used to inspect traffic flowing between VPCs or between a VPC and a business’s on-premises infrastructure. You can read more about deployment models in Deployment models for AWS Network Firewall.

AWS Network Firewall vs. Security Groups and NACLs

AWS Network Firewall is one of several firewall services available on AWS. 

  • Security Groups are stateful firewalls that filter traffic to Elastic Network Interfaces typically used with EC2 instances. Security groups provide granular filtering for individual instances.
  • Network Access Control Lists (NACLs) are optional stateless firewalls associated with one or more subnets within a virtual private cloud. 
  • Amazon WAF is a web application firewall that filters traffic for web applications and APIs, allowing users to block common attacks such as those included in the OWASP Top Ten.

You might be wondering why AWS needs so many firewalls. They each play a distinct role. AWS Network Firewall protects the perimeter of your virtual private cloud. It controls inbound and outbound traffic for the entire network. 

In contrast, security groups are associated with individual EC2 instances and some other services. NACLs are an additional firewall that controls traffic to and from subnets, allowing users to configure rules that apply to multiple groups of instances and control traffic flowing between subnets. 

Together, these firewalls give users enormous flexibility in configuring access to instances, subnets, and VPCs. For example, you may want to allow connections of a specific type into your VPC with AWS Network Firewall, but to have Network Access Control Lists that deny similar connections access to particular subnets or instances. Another use case for multiple firewalls is to run production and testing subnets, which should be able to receive requests from external networks but should not be able to communicate directly with each other. 

AWS Network Firewall is one component of a layered approach to cloud security. To learn more, visit our extensive cloud security and compliance resources or contact a cloud security specialist to discuss KirkpatrickPrice’s cloud security audit and compliance audit services.

The Amazon Simple Storage Service (Amazon S3) celebrated its 15th birthday in 2021. S3 was conceived as a straightforward scalable object storage system developers could use without concerning themselves with files systems—everything on S3 is an addressable object in a bucket.

S3 quickly rose to dominate the object storage space. Because it is used everywhere, AWS S3 security as well as the privacy and confidentiality of the data businesses store in it are critical. A vulnerability in S3 would inevitably lead to data exposure on an unprecedented scale. Amazon understands this and has built security features into S3 and integrated it with security and privacy services such as AWS Identity and Access Management (IAM).

But, as with all cloud services, security is partially the responsibility of users. If S3 buckets are poorly configured, sensitive data may be exposed. This article explores ten S3 best practices your business can implement to avoid becoming the star of the next big S3 data leak story.

Ensure S3 Buckets are Not Publicly Accessible

Data leaks from S3 buckets often occur because a bucket containing sensitive files is configured to allow public access. This means anyone on the internet who knows where the bucket is can access the files. Bad actors have created tools that make it straightforward to discover buckets with public read permissions.

When buckets are first created, they are not publicly accessible. However, rather than setting up secure Bucket Policies or managing access with IAM identities, users often configure buckets for public access. This is often done for convenience: the user wants a group of people to access the data and doesn’t understand how to provide that access securely.

To check whether your buckets are publicly accessible, log into the S3 Console, click on a bucket, and select the permissions tab. Access permissions are displayed at the top. The prominent “Block public access” setting revokes the bucket’s public access configuration immediately.

You can also use the KirkpatrickPrice AWS Security Scanner to check for insecure S3 bucket permissions and other AWS cloud security vulnerabilities.

Configure Least Privilege Access

Removing public access is an essential step towards better AWS S3 security, but it is only the first step. In addition to ensuring that data can’t be accessed by everyone, you should ensure it can only be accessed by those who need the data. For example, if you want to share data in a bucket with a third party, they may only need read permissions and not write permissions. 

There are several ways to configure access permissions on buckets, but you should ordinarily use either bucket policies or IAM identities.

Both methods improve Amazon S3 security, but IAM identities are more flexible and granular. As a general rule, it is preferable to use IAM identities as part of a comprehensive identity and access management strategy. A third access control option is Access Control Lists (ACLs); however, Amazon recommends using bucket policies or IAM identities instead.

Implement S3 Encryption At Rest

Data stored in S3 buckets should be encrypted. Encryption ensures the data cannot be read if it is exposed through a vulnerability or misconfiguration. S3 provides three server-side encryption options:

  • SSE-S3 — encryption with keys managed by the S3 service.
  • SSE-KMS — encryption using keys stored in AWS Key Management Service.
  • SSE-C — encryption using keys provided by the customer.

Any of these options significantly improve security compared to storing unencrypted data in S3. However, SSE-KMS gives the user more control over their keys, allowing them to, for example, rotate keys as required.

Implement S3 Encryption in Transit

In addition to encrypting data at rest in Amazon S3, it should be encrypted in transit as it moves over the network. Data is automatically encrypted within the AWS network, but users should consider leveraging SSL/TLS when moving data across external networks, including the internet.

Store S3 Credentials Securely

If your applications access data stored in S3 buckets via the API, they will need to authenticate. To do so, they will use an AWS access key, a long-term credential associated with an IAM user that is used for programmatic authentication.

Improper use of AWS access keys can create security vulnerabilities. One common mistake is to embed access keys in code. Access keys embedded into code and then shared on version control platforms have been the root cause of many data leaks.

AWS access keys should be securely stored in AWS Secrets Manager, as we discussed in depth in How to Keep AWS Access Keys and Other Secrets Safe.

Use IAM Roles for Temporary S3 Access

Roles are IAM identities with a set of permissions. However, roles are not associated with an individual user, although users and other entities can assume a role to take on its permissions. In this context, the main benefit of roles is that they can be used to create temporary credentials which expire after a specified period, in contrast to IAM users’ access keys, which are permanent until deleted.

Enable Multi-Factor Authentication for IAM Users

Multi-factor authentication adds an extra layer of security to the standard username and password authentication. With MFA enabled, users must supply an additional factor of authentication—a one-time code or a hardware security key. Usernames and passwords can leak or be shared inappropriately. TFA ensures that accounts remain secure even if credentials are exposed.

Enable S3 Access Logs

Access logs allow administrators to identify unusual and unexpected access patterns that may indicate a security breach. They are also useful when analyzing security incidents to discover which data has been exposed, information that may be essential to fulfilling regulatory requirements.

S3 does not ordinarily log who has accessed data and which data they have accessed, but users can activate access logs. Amazon will log access requests and store the resulting log files in a different S3 bucket. The log storage bucket should have strict access permissions to ensure bad actors can’t alter the log or use the information it contains to plan an attack.

Classify Data Stored in S3 Buckets

Many regulatory standards govern the secure storage of sensitive data, particularly health data, financial data, and personally identifiable information (PII). S3 is a viable option for storing sensitive data, if correctly configured. But to be compliant, it’s important to know which data you’re storing in the first place—accidentally dumping a database full of PII in a bucket with broad access permissions is likely to result in compliance and audit failures.

Before data is stored in S3, it should be classified and subject to a risk assessment so that businesses are aware of what they are storing and the associated risks. Amazon provides a service that can help businesses to discover sensitive information in S3 buckets. Amazon Macie is a data privacy service that uses machine learning and pattern matching to automatically identify sensitive data and alert users about insecure access permissions.

Verify S3 Bucket Configurations

Our last Amazon S3 security best practice is to check bucket configurations and IAM permissions regularly. Over time, your AWS environment will evolve from its initial conditions. 

Partner with KirkpatrickPrice to Improve Your S3 Security

The KirkpatrickPrice AWS Security Scanner and cloud security audits help businesses verify their cloud security and privacy. To learn more, browse our extensive cloud security resources or contact an information security specialist today.

The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard merchants and service providers must comply with if they store, process, or transmit cardholder data. PCI DSS includes over 400 information security requirements, including requirements that apply to cloud infrastructure such as Amazon Web Services (AWS).

Organizations that use AWS to store and process credit card data must ensure their cloud infrastructure is compliant. But maintaining AWS PCI-compliance is not as simple as uploading sensitive data to a cloud service that has been audited and declared PCI compliant. As Amazon puts it, “It is the customer’s responsibility to maintain their PCI DSS cardholder data environment (CDE) and scope, and be able to demonstrate compliance of all controls.”

In this article, we examine what AWS PCI compliance means and how companies store and process data on AWS while maintaining PCI DSS compliance.

Which Data is Covered by PCI DSS?

Cardholder data is any personally identifiable information associated with a credit cardholder or their account. It includes:

  • The Primary Account Number (PAN)
  • Cardholder names
  • Expiration dates
  • Service codes

PCI DSS also addresses the storage, processing, and transmission of sensitive authentication data, including magnetic stripe data, CVC numbers and equivalent data, and personal identification numbers (PINs). Organizations storing and processing this data must ensure that the relevant infrastructure and systems are compliant.

Is AWS PCI-Compliant?

AWS is a PCI DSS Level 1 compliant service provider. Level 1 is the most stringent of the four levels of PCI compliance, and it implies that AWS has been certified compliant following an audit by a Qualified Security Assessor (QSA).

Which AWS Services Are PCI Compliant?

The majority of Amazon’s cloud services are PCI-compliant. Compliant services include Amazon Simple Storage Service (S3), Amazon Elastic Compute Cloud (EC2), Amazon Elastic Block Store (EBS), and around 150 other cloud services and programs. You can see a complete list of PCI compliant AWS services at AWS Services in Scope by Compliance Program.

AWS PCI Compliance and the Shared Responsibility Model

AWS operates a shared responsibility security model meaning responsibility for securing cardholder data is shared between the platform and the user. AWS implements secure and compliant systems which reduce the users’ operational burden. But it doesn’t absolve them of the responsibility to use AWS services in a secure and compliant manner.

Amazon is always responsible for securing the underlying hardware, but the user may be responsible for the service’s configuration and any software they run on it. The division of responsibility depends on the cloud service. On EC2, the user is responsible for securing the operating system and services they run on virtual servers. On S3, they are responsible for the aspects of the service that are user configurable.

To consider one common AWS security failing, Amazon S3 is a secure and PCI-compliant object storage service. If S3 is correctly configured and used as part of a compliant system, an AWS user could store cardholder data on S3 and maintain PCI compliance.

However, S3 can be configured insecurely. This could occur by setting a permission policy that allows public access to the data stored in a bucket. In that case, the service is PCI compliant, but the user’s implementation is not, and nor is any system that uses that implementation.

As Amazon’s compliance guidelines make clear, “AWS Services listed as PCI DSS compliant means that they can be configured by customers to meet their PCI DSS requirements. It does not mean that any use of that service is automatically compliant.” Additionally, the PCI DSS’s scope goes beyond infrastructure to processes and people—compliant infrastructure can’t make a system compliant unless all other appropriate controls are also implemented.

Ultimately, PCI DSS compliance is always the responsibility of the user. Amazon makes compliance easier, but if cardholder data is exposed or misused, it is the user who faces penalties and perhaps the revocation of their ability to process credit card payments.

How to Achieve PCI Compliance on AWS

Achieving PCI compliance on AWS is a complex topic: it depends on the size and scope of a business’s cardholder data environment; the cloud infrastructure, services, and software in use; and the processes the company supports with AWS services.

To implement a PCI-compliant cardholder data environment, AWS users must ensure that all infrastructure connected to the data environment complies with the relevant PCI DSS requirements. We cannot cover all applicable requirements here, so let’s look at three examples of how AWS helps businesses comply.

PCI DSS Firewall Controls

PCI DSS Requirement 1.1.4 requires businesses to implement a firewall at each internet connection and between any demilitarized zone and the internal network zone. Amazon provides two main PCI compliant firewall options: Security Groups and Network Access Control Lists (NACL).

Firewalls are a clear example of how the division of responsibility between AWS and the user works. AWS provides firewall services that help users comply with PCI DSS requirements, but the user must configure and manage the firewalls in a compliant manner. AWS also provides the AWS Firewall Manager to centralize and simplify firewall management for AWS environments.

Strong Encryption of Data at Rest and in Motion

PCI DSS Requirements 3 and 4 address cardholder data protection, including encryption at rest and in transit. Relevant requirements include:

  • Render PAN unreadable anywhere is stored.
  • Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open networks.

Businesses must encrypt cardholder data in transit and at rest with strong, modern cryptographic technology. AWS makes this relatively straightforward. Most storage services offer encryption at rest, including databases, storage services, and caching services.

Data is automatically encrypted as it is moved within a secure AWS network. Still, users must ensure that they implement suitable cryptographic protection when data is transmitted to third-party clients and services.

Secure Key Management

PCI DSS Requirement 3.5 and Requirement 3.6 include several key management sub-requirements such as:

  • Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse.
  • Restrict access to cryptographic keys to the fewest custodians necessary.
  • Generate strong cryptographic keys and implement processes to store and distribute them securely.

To help businesses comply with these requirements, AWS provides the AWS Key Management Service (AWS KMS). AWS KMS is a key management service that can generate and control secure keys. It integrates with many other AWS services that encrypt data, making it easier to comply with PCI DSS encryption and key management requirements.

Verifying AWS PCI Compliance with A PCI DSS Audit

As we’ve seen, AWS is a PCI-compliant cloud platform. AWS services help businesses build PCI compliant systems to store and process credit card data. Achieving PCI compliance is much less complex on AWS than on self-managed colocated servers.

However, less complex isn’t the same as simple. Businesses often face challenges configuring, managing, and integrating AWS cloud services in a way that maintains compliance. Non-compliant organizations risk fines and penalties, termination of the ability to accept cards as payment, loss of business, and legal costs.

As a licensed CPA and QSA firm, KirkpatrickPrice’s PCI audits will help your business demonstrate PCI compliance and reduce the risk of non-compliance. In addition to PCI audits, we also offer cloud security audits, penetration testing, risk assessments, and other services that help businesses to achieve PCI compliance on AWS.

Contact KirkpatrickPrice today to learn more about how a PCI audit could benefit your business.

AWS provides dozens of cloud services ranging from storage and compute to machine learning and security services. AWS is by far the biggest cloud platform, and thousands of businesses entrust it with their most sensitive data and critical workloads. Ensuring only authorized users can access these assets is the job of AWS Identity and Access Management (AWS IAM). 

As you might imagine, improper use of AWS IAM can create serious security vulnerabilities. This article introduces AWS IAM and discusses five of the most critical AWS IAM security best practices. 

What is AWS IAM?

AWS IAM is a cloud service for managing access to resources in the AWS cloud. As the name suggests, IAM has two main roles:

  • Identity management — verifying that a user is who they claim to be with authentication mechanisms such as passwords, multi-factor authentication, and federated identity management solutions such as Microsoft Active Directory. 
  • Access management — controlling which resources users can access. Each user has a set of permissions that determine the actions they can take within a business’s AWS account. 

These roles mean that IAM is the gatekeeper for AWS resources. If businesses fail to follow IAM best practices, they risk giving unauthorized users access to their data and infrastructure. 

What Are Users, Groups, and Roles in AWS IAM?

When an AWS account is first created, it has a single user. This is the root user, which has complete access to all resources. As we’ll discuss in the next section, the root user should not be used for day-to-day operations. It should, however, be used to create other IAM identities with varying permissions.

IAM provides three primary types of identity: users, groups, and roles. Each has an associated set of permissions, but they serve different purposes. 

  • Users — users represent people, and they are used to give individuals the ability to log in and manage AWS resources. Users are granted permissions, either by attaching a permissions policy or by adding them to a group. IAM users can also generate access keys, which can be used for programmatic access to AWS APIs. 
  • Groups — a group is a collection of users. Groups also have configurable permissions, which all members inherit. Groups make it easy to grant permissions to a class of users. For example, a business might create a DevOps group with permissions to manage EC2 instances. 
  • Roles — roles have many of the same properties as users. However, roles are not linked to a single individual, and they do not have log-in credentials. Instead, roles are temporarily assumed by users who need a specific set of permissions to complete a task. 

5 Steps to Secure Your AWS IAM Account

1. Create IAM Users with Appropriate Permissions 

We recommend using the root account to create users, groups, and roles with suitable permissions. Once that’s done, use those identities to manage day-to-day operations. To further improve IAM security, activate multi-factor authentication on user accounts. With MFA turned on, user accounts are safe even if their password is exposed.  

2. Enforce AWS Least-Privilege Permissions

Create permissions policies that provide the lowest possible access.  IAM identities cannot control resources unless they are given permission.  Determine the minimum set of permissions to grant when creating users, groups, and roles. You can always add more later if they’re needed. 

It may be tempting to give users broad permissions in case they need to carry out a particular task. But it is more secure to be restrictive at first, only granting additional privileges when a user finds they are required. 

As your business and its AWS environment evolve, the permissions needed by IAM identities will change. Perhaps a user needed broad permissions to manage resources at one time, but no longer. In that case, their permissions should be restricted and unnecessary access removed. For the same reason, ensure that unused users, roles, and groups are deleted. 

You may also want to use IAM Access Analyzer to refine permissions policies. IAM Analyzer helps businesses to maintain least-privilege access by generating permissions policies based on access activities.  IAM Access Analyzer also provides last-accessed and last-used timestamps that can help you to identify unneeded permissions and unused identities.  

3. Secure the AWS IAM Root Account

As we mentioned above, the root account has universal permissions. It can access and control all resources owned by an AWS account. With its access keys, developers can control those resources via AWS APIs. The root account is uniquely useful, but it is also uniquely dangerous. Attackers may gain complete control of your AWS account if its credentials or access keys are exposed.

Therefore, the AWS root account and its access keys should not be used to manage AWS resources. If your business is already using the root account in day-to-day operations, consider creating new users accounts with limited permissions. Use these instead of the root account. Change the root account’s password and delete its access keys. Use Amazon CloudTrail and CloudWatch to monitor API calls to ensure that you haven’t missed any use of the root account. 

4. Ensure Account Information Is Accurate

AWS may send you security notifications, and it’s imperative they go to the correct email addresses. It’s not unusual for businesses to create AWS accounts with email addresses that aren’t monitored. We recommend designating one or several individuals responsible for checking and responding to notifications. Ensure that their contact details are correctly recorded in AWS and that they regularly check the email inboxes for notifications. 

In addition to the primary email address associated with an account, AWS provides alternate contacts for billing, operations, and security notifications. Businesses can use these addresses to ensure notifications are sent to the right people. 

5. Use AWS Security Hub, Amazon GuardDuty, and other AWS Security Tools

AWS provides several services to help businesses to monitor and improve security. Perhaps the most important is the AWS Security Hub. The Security Hub centralizes alerts from several other services, allowing companies to access high-priority security alerts quickly. 

The services that send alerts to AWS Security Hub include:

  • Amazon GuardDuty, a threat detection service that monitors AWS accounts for malicious activity. 
  • Amazon Inspector, an automated security assessment service. 
  • AWS Firewall Manager, a centralized firewall management service.
  • Amazon Macie, a data security and privacy service that uses machine learning to help businesses to identify and protect sensitive information. 

KirkpatrickPrice’s AWS Cybersecurity Services provide AWS audits and a wealth of actionable information to help businesses identify AWS security and compliance threats and protect their infrastructure and data. Contact a cloud information security specialist today for assistance with your AWS security and compliance challenges. 

AWS Vulnerabilities

Amazon Web Services (AWS) dominates the enterprise cloud landscape. Around two-thirds of business cloud users host infrastructure on AWS.  That includes many of the biggest companies in the world and small and medium businesses in the tens of thousands. AWS’s popularity makes it a tempting target for cybercriminals: AWS vulnerabilities could let them steal data from thousands of businesses.

Amazon regularly finds and fixes vulnerabilities in the platform’s code and networks. However, many common AWS vulnerabilities originate with users.  AWS provides tools to help cloud users secure their data and infrastructure, but it is a complex cloud platform. Inexperienced users often misconfigure cloud resources, creating security vulnerabilities. 

This article will help you understand frequently exploited AWS vulnerabilities and how to guard against them. 

AWS Root Account Credential Leaks

The AWS root account controls every aspect of your AWS environment. The root account can add new users, modify user permissions,  create and destroy cloud resources, and access all of your data.  It’s important to have a root account. Without it, you would not be able to set up your AWS environment in the first place. But if it leaks, that environment has no protection. 

You should share the root account’s credentials only with trusted senior employees who need root access. It should not be widely shared within your organization, and it should not be used during the day-to-day operation of your AWS environment. Use the root account to set up IAM users with appropriate permissions, then rely on the new user accounts going forward. To further improve AWS security, activate two-factor authentication on the root account and disable the account’s API access key. 

Exposed AWS Access Keys

AWS access keys are credentials used for programmatic access to AWS APIs. Your code can use access keys to carry out tasks that the associated user has permission to perform. For example, your app might use access keys to deploy EC2 instances or store data in an S3 bucket. 

Misused access keys can create an AWS vulnerability. They are often embedded in code, which is then uploaded to a version control system like GitHub. Bad actors frequently target businesses that upload access keys to public repositories. But it is also dangerous to store keys in private repositories. Just like usernames and passwords, access keys should not be shared widely within your organization. If you put them in a private repository, anyone with access to the repository can see the keys. 

We explored how businesses can better protect their AWS access keys in How to Keep AWS Access Keys and Other Secrets Safe.

Sensitive Resources on Public Subnets

Amazon Virtual Private Cloud (VPC) allows businesses to create virtual network environments. VPC gives AWS users control over their network, including network security, routing, resource deployment, and subnets. 

Subnets are one of VPC’s biggest security and availability advantages. Businesses can create logically isolated subnets with traffic screening and access restrictions. For example, they can deploy public subnets connected to an internet gateway and private subnets that are not accessible from the internet. Private subnets can only be accessed by internal resources, making them an excellent option for database servers and other resources that should be hidden from the internet.

When you first provision a VPC, it contains a default public subnet. Unfortunately, many users do not change the original configuration. They deploy servers and databases to the default subnet, exposing them to the internet and creating a dangerous security vulnerability. 

Overly Broad IAM Permissions

AWS Identity and Access Management (IAM) allows businesses to specify user access permissions, groups, and roles. IAM permissions limit the actions these entities can take and the resources they can access.  Permissions should be limited to provide only the access an entity needs. 

Businesses often fail to set permissions correctly, configuring overly broad permissions or failing to re-assess permissions over time. If credentials leak, an attacker gains more access than they otherwise would have. But even if the credentials don’t leak, internal users may access sensitive resources and cause security and availability issues. 

Public Access to Origin Databases

Origin databases should be hidden from the internet. These databases support your apps and services. They may need to be accessible to web servers and other public-facing resources. But there is rarely a good reason to expose their IP address to external connections. 

An exposed origin database IP allows attackers to exploit other vulnerabilities. For example, an attacker could connect and exfiltrate data if the database’s access permissions are not correctly configured. This type of vulnerability has been the root cause of numerous data leaks.

Permissive Security Groups Rules

Security groups are AWS’s virtual firewall. They allow businesses to restrict traffic to and from AWS resources. The user creates a security group and configures inbound and outbound traffic rules. They can then assign the security group to other resources, such as EC2 instances. Security groups are highly flexible, empowering users to create custom firewalls for different scenarios. 

All AWS accounts have a default security group. The default group has permissive rules: it allows inbound traffic on all ports from network interfaces and instances within the same security group. It also allows all outbound traffic. The default group is automatically used for new resources when a custom group is not specified. 

If you don’t adjust the default security group’s rules or create and assign custom groups, instances and other resources are deployed with broad permissions. Many businesses fail to do so. Consequently, instances are often deployed with vulnerable ports that are accessible from the internet. 

We covered AWS security in greater detail in 10 Top Tips For Better AWS Security Today?

Server-Side Request Forgery

In 2019, the Capital One credit card company leaked customer details from 100 million accounts exposing AWS vulnerabilities. The attack was later found to have exploited Server-Side Request Forgery (SSRF). SSRF turns a business’s cloud infrastructure against it.  

Imagine a business that stores sensitive information in a database. The database is hosted on a cloud server without an external IP. The attacker can’t connect to it directly. But they may be able to connect to an internet-facing server with permission to access the database. In an SSRF attack, the attacker exploits a vulnerability in the internet-facing server and uses the server to send hostile requests to the target database. 

For that to work, a resource on an external IP must be improperly configured. In the Capital One case, the attackers exploited overly broad Web Application Firewall (WAF) rules—similar to the situation described in the previous section. However, many different configuration errors might open the door to an SSRF attack. 

Misconfigured S3 Storage Buckets 

We have left one of the most common AWS vulnerabilities until last. AWS S3 is a popular block storage service used by thousands of businesses. S3 stores data in buckets with flexible access permissions. Misconfiguring those permissions may allow malicious third parties to access sensitive data.

A huge number of businesses have been caught out in this way. They deliberately or unintentionally configure S3 buckets for public access. Bad actors scan for misconfigured buckets and exfiltrate the data. Victims of this AWS vulnerability include Twilio, BHIM, Attunity, and dozens more. 

How KirkpatrickPrice Helps

KirkpatrickPrice is a licensed CPA firm specializing in information security. We provide services to help clients secure their cloud infrastructure and comply with information security and privacy regulations, including:

Contact us today to begin your journey to improved AWS security.