5 Common Cloud Security Misconfigurations for AWS

Security incidents caused by misconfigurations in the cloud happen every single day. In fact, DivvyCloud reports that over the last two years, 33 billion records have been exposed because enterprises struggle to implement proper cloud security. When you take that number and consider Ponemon’s research, which estimates the average cost per compromised record is $150, that means cloud security misconfigurations have cost companies worldwide nearly $5 trillion since 2018.

Misconfigurations in AWS can have serious consequences, but they’re completely avoidable when you have the right resources to guide you. Let’s discuss five misconfigurations that our auditors see over and over again in AWS environments: IAM policy errors, incorrect security group attachments, deployment pipeline misconfigurations, backup storage location misconfigurations, and S3 bucket misconfigurations.

IAM Policy Errors

IAM is one of the most complex architectures within AWS. IAM controls who has access to which resource, so it’s an incredibly important aspect of cloud security. IAM policies that cause misconfigurations include:

  • Lack of MFA
  • Not following password best practices
  • Keeping unused credentials instead of disabling them
  • Not understanding role assumption or how it’s logged
  • Attaching IAM policies to users instead of groups or roles
  • Not rotating keys every 90 days
  • EC2 instances do not have proper access to resources
  • Running all privileges to all users instead of utilizing the concept of least privileges
  • Resource-based policies are not attached to a defined resource

Incorrect Security Group Attachments

Do you attach the appropriate AWS security groups to the correct EC2 instances? The functionality of security groups is similar to a firewall and filters inbound and outbound traffic based on rules. This is a misconfiguration that shows up especially when default security groups are involved.

Our auditors see incorrect security group attachments often, especially when defaults are involved. To avoid this common AWS misconfiguration, you must fully understand security groups.

Deployment Pipeline Misconfigurations

In the DevOps model, you live and die by your deployment pipeline. When your developers aren’t aligned with security standards or your CI/CD pipeline isn’t implemented and secured properly, it can lead to critical consequences.

Backup Storage Location Misconfigurations

In terms of backup storage locations, we find that people often forget about the security of backups in some instances. Knowing where your backups are going and what security policies you have in place is critical. Let’s say you have a backup storage bucket – are you checking policies on that bucket? Does the organizations encryption policy extend to backups? Questions like these need to be asked to appropriately secure backups.

S3 Bucket Misconfigurations

Symantec reports that in 2018, S3 buckets had with more than 70 million records stolen or leaked as a result of poor configuration. AWS says that the top five S3 security concerns are:

  • Public access to S3 buckets
  • Not utilizing server-side encryption for S3-managed encryption keys
  • Not encrypting inbound and outbound S3 data traffic
  • No familiarity with how S3 versioning works or S3 lifecycle policies
  • No use or analyzation of S3 access logging

Why We Chose These Misconfigurations

In the AWS Shared Responsibility Model, AWS is responsible for security “of” the cloud and customers are responsible for security “in” the cloud. AWS considers configuration management a shared control, explaining, “AWS maintains the configuration of its infrastructure devices, but a customer is responsible for configuring their own guest operating systems, databases, and applications.” This means you, as the AWS customer, cannot depend on AWS’ security practices alone when it comes to configuration. You can avoid the consequences of misconfigurations when you properly understand and configure IAM security groups, deployment pipelines, backups, and S3 buckets.

At KirkpatrickPrice, we’ve created a framework for cloud security audits based on the CIS Benchmark and other industry standards. We hire technologists, then train them to be auditors – and this increases the value and quality of our AWS audits. Contact us today to begin testing your cloud security measures and discover if your AWS environment has any of these common misconfigurations.

More Cloud Security Resources

AWS Security for S3 and EC2

AWS Security Checklist

AWS Security Best Practices

5 Key Areas of Cloud Security

Data breaches are on the rise worldwide and across cloud platforms – which is why we talk about cloud security within AWS, Azure, and Google Cloud so often. As more and more organizations migrate sensitive information and services to cloud environments, it should drive customers to consider how the cloud will impact their privacy, security, and compliance efforts.

In cloud security audits at KirkpatrickPrice, controls will be tested against our framework that are based on the CIS Benchmarks for AWS, Azure, and Google Cloud. These audits utilize our audit delivery tool, the Online Audit Manager, and the framework assesses five key areas of cloud security:

  1. Identity and Access Management
  2. Securing Data in the Cloud
  3. Securing the Operating System
  4. Protecting the Network Layer
  5. Managing Security Monitoring, Alerting, Audit Trail, and Incident Response

As you work to make your cloud infrastructure as secure as it can be, we encourage you to spend extra time in these five areas so that you can strengthen your overall security posture.

Identity and Access Management

IAM is central to a secure environment. Role-based access control and the principle of least privilege have been perennial tenants of access control implementation, and with the rise of cloud infrastructure deployments this is even more true. In fact, Azure says that cloud customers should treat identity as the primary security perimeter because it manages who has what access to which resource. IAM security measures include MFA implementation, password management, creating and disabling credentials, role-based access controls, segregation of environments, and privileged account activity. For industry resources about IAM in the cloud, learn more here:

Securing Data in the Cloud

To secure the data in your cloud, you must consider the security of data in all states – at rest, in transit, and in storage – and who is responsible. The shared responsibility model  has become a paradigm that defines interactions with cloud resources and who is responsible for data security. The use of proper encryption and key management solutions within AWS, Azure, and Google Cloud are the two critical areas of data security in the cloud. For industry resources about data security in the cloud, learn more here:

Securing the Operating System

No matter the operating system that your cloud provider supports, maintenance, proper configurations, and patching methods can strengthen the security of that operating system. Scheduling maintenance windows, staying current with system configuration requirements, and establishing a patch baseline are integral components to cloud security and something your organization must be vigilant in implementing, especially given the current cyber climate where malicious individuals and organizations are quick to exploit vulnerabilities. For more industry resources about security operating systems, learn more here:

Protecting the Network Layer

Network security is how you protect resources from unauthorized access. Network security can be a challenging task because it requires an understanding of connectivity between resources. Having a plan of action that identifies where segmentation is required, how connectivity will be implemented, and ongoing hygiene of the network is critical for securing your organizations environments. For industry resources about network security in the cloud, learn more here:

Managing Security Monitoring, Alerting, Audit Trail, and Incident Response

Without a proper monitoring program, you won’t have the insight to recognize security incidents or anything going wrong within your cloud infrastructure. The implementation of monitoring is critical for operational oversight. Ensuring that appropriate data points are being analyzed for security information, event management, and proper correlation algorithms is important for operations in the cloud. No matter the cloud provider you choose, you should utilize the monitoring and logging features, plus enable notifications for things like unexpected configuration changes and authentication failures. For industry resources about monitoring and incident response, learn more here:

More Cloud Security Resources

Who’s Responsible for Cloud Security?

AWS Security for S3 and EC2

Best Practices for Configuring Your AWS Perimeter

Best Practices for Privilege Management in AWS

Could what happened at Capital One happen at your organization?

That depends on your commitment to cloud security. This breach could happen to any organization that’s not educated on AWS vulnerabilities and best practices. We’ve talked about how security misconfigurations played a role in Capital One’s breach, but now let’s discuss how privilege management contributed to this successful hack.

What Happened at Capital One?

According to Verizon’s 2019 DBIR, misuse of privileges is the cause of  nearly 70% of breaches and 29% of all breaches involve the use of stolen credentials. Privilege management, misuse, and IAM misconfigurations led to the first misstep in the Capital One Breach.

When the attacker executed the first command, the hack began. This command allowed the attacker to acquire security credentials for a specific WAF-role with elevated privileges that had access to folders in Capital One’s AWS environment.

Did this role need elevated privileges?

The public can’t know for a fact. Were those credentials protected appropriately? Apparently not, because the environment was susceptible to the SSRF attack that had detrimental consequences for Capital One. It’s important to evaluate privileges assigned to all roles in your organization.

The Principle of Least Privileges in AWS

In AWS, the concept of least privilege means that you give users the least amount of access and responsibility necessary to complete their duties. Least privilege is also referred to as role-based access or need-to-know access and falls under AWS Identity and Access Management policies.

Configuring a system based on least privileges and need-to-know principles aren’t new concepts, but many organizations fail in this area. Best practice for least privileges comes down to the assignment of roles and responsibilities, limiting access based on what’s required, and creating a separation of duties. Consider the following requirements from industry frameworks:

  • SOC 2 common criteria 6.3 says, “The entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties, to meet the entity’s objectives.”
  • We see the subject of least privileges again in PCI Requirement 7.1.2, where it requires organizations to limit access to privileged user IDs to personnel who truly require it for the function of their job.
  • Least privileges and minimum necessary is also key to the HIPAA Privacy Rule, which requires covered entities to enhance their safeguards to limit unnecessary or inappropriate access to and disclosure of PHI.

AWS Security Best Practices

Best practice for least privileges is to ensure that your policies allow the fewest actions and access to resources as possible. It is even AWS’ recommendation that when you create IAM policies, you begin with least privileges and then grant elevated privileges when necessary. IAM policies should also be tested by someone with knowledge of your AWS environment and IAM policies for assurance that they are functioning as intended.

AWS recommends creating IAM policies surrounding these subject areas:

  • Lock Away AWS Account Root User Access Keys
  • Create Individual IAM Users
  • Use Groups to Assign Permissions to IAM Users
  • Grant Least Privilege
  • Get Started Using Permissions with AWS Managed Policies
  • Use Customer Managed Policies Instead of Inline Policies
  • Use Access Levels to Review IAM Permissions
  • Configure a Strong Password Policy for Users
  • Enable MFA
  • Use Roles for Applications that Run on Amazon EC2 Instances
  • Use Roles to Delegate Permissions
  • Do Not Share Access Keys
  • Rotate Credentials Regularly
  • Remove Unnecessary Credentials
  • Use Policy Conditions for Extra Security
  • Monitor Activity in Your AWS Account

Don’t underestimate the value and complexity of IAM policies, though – especially in AWS. IAM policies are one of the most complicated things out there because you have to have an operational and security perspective. IAM policies give your organization the power over which actions can be performed by or on any given resource in your AWS environment. How does your organization ensure that IAM policies protect your AWS environment?

How to Strengthen AWS Environments

As more data migrates to AWS, organizations must have processes in place to validate their cloud security efforts. Whether that’s through consulting with an AWS Cloud Practitioner or CCSK, something like a SOC 2 audit, or advanced penetration testing, you need a third party’s perspective and expertise to gain assurance.

What consequences would you face if, like Capital One, your clients’ data was compromised?

We don’t want you to ever have to find out. Let’s partner together to secure your AWS environment.

More AWS Resources

Cloud Security Audits

The Justice Department’s complaint

AWS’ Letter to Senator Ron Wyden

Who’s Responsible for Cloud Security?

Who Should Perform Your Cloud Audit?

Best Practices for Configuring Your AWS Perimeter

Could what happened at Capital One happen at your organization? As a business owner, stakeholder, or IT personnel, that’s the unavoidable fear that appears when you hear about the latest data breach. The Capital One data breach is one of the most damaging data breaches of 2019, and we’ll continue to learn about the repercussions for months to come. This data breach impacts 100 million individuals in the United States and 6 million in Canada. The compromised data was from businesses who filled out credit card applications, and Capital One reports that, “The largest category of information accessed was information on consumers and small businesses as of the time they applied for one of our credit card products from 2005 through early 2019.” Most importantly – we know that this breach could happen to any organization that’s not educated on how to properly configure your perimeter security groups. Let’s discuss web application firewalls (WAF), Server Side Request Forgery (SSRF) attacks, metadata, and how a misconfiguration could lead to a compromised AWS environment and stolen data.

Security Misconfiguration in AWS

Evidence from the Capital One case confirms that this data breach began with a misconfigured open-source WAF used in AWS. The intruder, Paige Thompson (a former AWS employee), launched a SSRF attack to manipulate the WAF into running commands it should have never been allowed to – including the command to communicate with the metadata service on AWS.

The Justice Department’s complaint outlines three commands that Thompson performed to abuse the misconfiguration and extract the compromised data, which was later found on a GitHub file:

  1. AWS WAF uses IAM service-linked roles, meaning that an IAM role is linked directly to the AWS WAF. The first command that was executed leaked the security credentials for a specific WAF role with elevated privileges that had access to folders in Capital One’s AWS environment.
  2. The second command that was executed, the “List Buckets Command,” used the compromised WAF role to list the names of Capital One’s folders in their S3 bucket. Thompson obtained access to over 700 folders.
  3. The “Sync Command” was the final step in actually extracting the data from these folders and/or buckets because the WAF role that Thompson compromised already had the required permissions to do so.

The bottom line? The WAF role was probably assigned too many permissions to begin with, and that combined with the misconfiguration led to a successful SSRF attack that had detrimental consequences.

In a statement given to KrebsOnSecurity, Amazon argued, “The intrusion was caused by a misconfiguration of a WAF and not the underlying infrastructure or the location of the infrastructure. AWS is constantly delivering services and functionality to anticipate new threats at scale, offering more security capabilities and layers than customers can find anywhere else including within their own datacenters, and when broadly used, properly configured and monitored, offer unmatched security—and the track record for customers over 13+ years in securely using AWS provides unambiguous proof that these layers work.”

Mitigating Risks in AWS and Securing Your Perimeter

How could you mitigate potential risks and misconfigurations facing your AWS environment? Cloud security experts at KirkpatrickPrice challenge you to consider the following:

  • Understand and monitor the configuration of perimeter security systems (including WAFs). They need to be regularly reviewed to ensure that intended rule sets are functioning as designed.
  • Relying on a WAF, though, to catch exploits is no replacement for proper code creation. The WAF just masks poor code development. Mitigation should focus on good application development hygiene and the enforcement of secure coding practices.
  • Penetration testing can yield huge benefits for externally-facing web applications and infrastructure. The scope and rules of engagement for the penetration testing, though, must ensure that the testing will include exploits that are specific and unique to AWS environments.
  • You must protect your internal services. In the Capital One case, the reason the exploit was able to access the information was because of the metadata service. Learn about a proxy for the AWS metadata service here.

How to Strengthen AWS Environments

How do you validate that your AWS environment has been properly configured? How do you determine that your security and privacy practices are effective? How do you protect the metadata service? Who’s responsible for cloud security – you or the cloud provider? We’re afraid that organizations aren’t asking enough questions like these. As more data migrates to AWS, organizations must have processes in place to check their cloud security efforts. Whether that’s through consulting with an AWS Cloud Practitioner or CCSK, something like a SOC 2 audit, or advanced penetration testing, you need a third party’s perspective and expertise to gain assurance.

What consequences would you face if your clients’ data was discovered to be open to the public? We hope you’ll never have to find out. Let’s partner together to ensure that misconfiguration is not your enemy in your cloud environment.

More AWS Resources

AWS’ Letter to Senator Ron Wyden

AWS Shared Responsibility Model

What is Web Application Penetration Testing?

Who Should Perform Your Cloud Audit?

AWS Security for S3 and EC2

Best Practices for AWS Security

AWS brings new opportunities for businesses to innovate, build, and grow – but what about the data in the cloud? Is it protected? How likely is it to be compromised? The 2019 Cloud Adoption and Risk Report from McAfee reports that the sharing of sensitive data in the cloud is increasing 53% year-over-year. The average enterprise generates over 3 billion events every month in the cloud and uses 1,935 different cloud services, giving malicious attackers ample opportunity to find, steal, and sell the data you are responsible for. This means that organizations must do everything in their power to implement AWS security and safeguard personal information. Where should you begin? Let’s discuss some of the basic security practices for S3 and EC2. These are extremely complicated subjects, but let’s make a starting point for your AWS security strategy with the following best practices.

Protecting S3 Buckets

S3 buckets are a major component of using AWS, but they’re also a major security concern. McAfee reports that 5.5% of all AWS S3 buckets that are in use are misconfigured and publicly readable. Why? S3 buckets are extremely complex, and anything that is complex is harder to secure. Randy Bartels, Vice President of Security Services at KirkpatrickPrice, comments, “AWS has an obligation to make it less complex, and users have an obligation to understand the complexity and make sane choices in setting up policies.” How can you be sure your S3 buckets align with best practices for AWS security?

  • Does your organization have IAM policies? This will give you a way to manage permissions for digital identities. IAM best practices include policies that outline strong password requirements, key rotation every 90 days or less, role-based access controls, and MFA.
  • Are permissions based on a least privileges principle? Users should only be allowed to access data that is necessary to perform their job duties.
  • Does your organization have S3 bucket policies? These will define access or grant access to specific buckets and objects.
  • Do any of your S3 policies allow a wildcard identity or action?
  • Does your organization use block public access properly?
  • Are access control lists made? Make sure that you’re aware if they have the capability to provide any type access to “Everyone” or “Any authenticated AWS user.”
  • Does your organization use S3 access logs? Do you analyze user behavior based on logs?
  • Is sensitive data in S3 encrypted at rest?
  • Is inbound and outbound data traffic encrypted?
  • How to you implement SSE? Does your S3 encryption strategy utilize SSE-S3, SSE-KMS, or SSE-C?
  • Are the responsible personnel knowledgeable about S3 versioning and S3 lifecycle policies?
  • Does your organization monitoring actions taken on buckets and objects? Making your monitoring program a priority will help solve small problems or risks before they become a much larger incident.

Protecting EC2 Instances

AWS outlines 5 key areas for baseline configuration that will secure EC2 instances, which include:

  • Least access
  • Least privilege
  • Configuration management
  • Change management
  • Audit logs

These aren’t new security concepts by any means, but they are ones that are incredibly important in AWS security. In addition to those baseline areas, you must consider the following questions when protecting EC2 instances:

  • Do your encryption strategy address protecting your data in EC2? It should address when, how, where, and what data is encrypted.
  • Do you collect IP traffic from VPC flow logs?
  • What do you do to manage access keys and key pairs?
  • Do IAM policies related to EC2 follow a “need to know” basis?
  • Is inbound and outbound traffic controlled through Security Groups?

Who Should Perform Your Cloud Audit?

Just like any type of technology or IT operation, the security of your service needs to be validated by a third party, whether that is through a SOC 2 attestation, penetration testing, consulting, or another form of security testing.

When choosing who should perform an audit of your AWS environment and controls, you need to focus on finding an auditor who is also a cloud expert. Because cloud technology is new and evolving, the industry lacks best practices that are known and understood. AWS does a good job at distributing best practices for security, but you want to hire an auditing firm that does thorough testing and has auditors that understand how AWS works.

If you don’t feel ready for an audit but want to begin your own AWS security practices, AWS has developed many security tools to help you achieve secure environments. AWS security is just as important to AWS as it is to customers. These tools can help you achieve best practices for cloud security, automate security assessments, give alerts for security incidents, and assess data security requirements to verify the security and compliance of cloud solutions. Amazon CloudWatch, Amazon Inspector, and AWS CloudTrail are a few examples.

At KirkpatrickPrice, we hire technologists, then train them to be auditors – and this increases the value and quality of our AWS audits. Any auditor from KirkpatrickPrice who’s performing a cloud audit understands cloud computing and technology and proves it through certifications like CCSK or CCSP. Contact us today to begin security testing for your AWS environment.

More AWS Security Resources

AWS Security Best Practices

AWS Security Checklist

5 Best Practices for Cloud Security

How Can a SOC 2 Bring Value to Your SaaS?