The stakes of Amazon Web Services (AWS) security are high. A strong security program both reduces the risk of data leakage and exposure to threats and supports business growth by leveraging the benefits of the cloud. However, even the largest and most sophisticated companies are falling victim to breaches due to vulnerabilities in their AWS environments. One headline-making example that has been much dissected, but still serves as a good reminder, is the Capital One data breach, which resulted from a Server-Side Request Forgery (SSRF) attack followed by taking advantage of a role with unnecessary permissions. It was a costly error that led to an $80M fine.
Why do compromises continue and how can enterprises analyze the risk? AWS penetration testing provides actionable insight into an organization’s AWS security posture to safeguard sensitive data and enable compliance while in the cloud. Effective AWS pentesting requires dedicated expertise and experience, as its basic tenets and focus differ from those that apply to testing on-premises solutions.
What makes AWS penetration testing different
Though the basic principles of information security apply to both on-premise and AWS environments, the application and execution of those principles applies differently in the cloud. This raises new challenges for penetration testers and security teams, though knowing these differences can also bring opportunities to meld security with development and operations processes, strengthening the AWS environment. Here are four differences to note.
Whether on-premise or in AWS, businesses need an accurate inventory of systems to know what they are responsible for and where business data is housed. In AWS, the discovery phase of a penetration test takes on a whole new level of criticality. AWS allows developers or operations staff to spin up services at will, without having to requisition physical hardware and networking. This makes testing and scaling easier than ever, but also makes previously unidentified assets more likely.
A mature AWS security program includes procedures for keeping inventory in the cloud. Penetration tests identify new cloud services so security teams can stay knowledgeable about the environment while development and operations teams take advantage of the flexibility and scalability of the cloud.
In addition to traditional usernames and passwords, AWS also allows access to resources via other means, such as API keys, federated authentication, and session tokens. This gives attackers new means for lateral movement through an environment. In addition to harvesting data dumps and public code repositories for usernames and passwords, attackers also search for API keys in code that has been released publicly in places like GitHub. If released code contains those keys, and the accounts used for testing still exist and have access to sensitive information, then the keys can lead to a data breach. An AWS penetration test must first address this issue by looking for AWS API keys in public code repositories or available internal documentation stores to ensure that clients can deactivate accounts and change credentials as necessary. Second, the pentest must verify that the IAM policies used in the environment effectively follow the principles of least privilege.
This is critical not only because of sensitive data that may be stored on the machines themselves but because compromise of a sufficiently privileged API key can give an attacker access to features that previously required them to be on-premise. Out-of-band management of systems that store or access critical data used to require either physical access to a machine or access to a local network. In AWS, it can be done at the API and identity layer, without physical or local network access, giving a deeper urgency to authentication flaws.
Identity and Access Management
Identity and Access Management is a fundamental concept even in on-premise environments, but it takes on a deeper complexity in AWS. Quite simply, there are far more role-based access capabilities in AWS than in traditional Active Directory, including not just user accounts but also roles, service accounts, and groups. On its face, that sounds good from a security perspective. There are indeed advantages since it allows for more thoughtful and granular assignment of privileges when used correctly.
When such power rests in the hands of someone without deep knowledge of AWS and the environment being built on top of it, however, it can turn into a security liability. Consider the case of an administrator getting frustrated with the wealth of security settings and allotting either a user account or a test account full privileges just to get something to work. In that case, the increased role-based access capabilities have become a liability. When penetration testing AWS, a tester needs to identify over-privileged policies that could be attached to users, roles, service accounts, and groups, accounts and suggest actionable ways to remediate those Identity and Access Management shortcomings.
Different implications of known vulnerabilities
Even though many of the categories of vulnerabilities in the cloud are shared with those identified in other networks and software, the implications can be different, and in some cases more critical. A penetration tester needs to know both the full range of vulnerabilities to test for as well as the ways in which their impact in AWS differs from their impact in other environments.
Consider, for example, the Server-Side Request Forgery issue mentioned in context of the Capital One data breach. In traditional infrastructure, a SSRF vulnerability may be a medium- to high-impact vulnerability. However, since cloud services allow web access to the data and management planes in a way that on-premise infrastructure typically would not, an SSRF vulnerability in AWS would be a high- to critical-impact vulnerability, depending on the contents of the system and network where the vulnerable instance sat.
AWS penetration testing in a broader security program
The time has already come for your business to consider AWS security and penetration testing. The speed of setting up infrastructure and developing solutions in the cloud outpaces that of on-premise solutions, and, according to a recent survey conducted by Hanover Research, 82% of respondents rank meeting the needs of business faster as a top priority. Whether or not your business is officially migrating, the odds are that your development and operations teams are already testing, building, or running services in the cloud. Your security team is responsible for knowing what services and data are in the cloud, testing the controls, and minimizing the risk to sensitive systems and data.
Penetration testing, just as with all aspects of the security program, must be done in partnership with other teams in the business. Communication is vital. The security team must work closely with the application and operations teams to integrate with their tools. After all, security is not the ultimate business goal, but rather a necessary part of achieving business goals. To gain support and buy-in security must be positioned throughout as something that supports and strengthens plans to achieve the company’s bottom line.
Penetration testing is also an integral part of the “trust, but verify” attitude that lies at the foundation of a successful AWS security program. The process of penetration testing allows the security team to verify: ensure that they are getting the security-relevant data they need from the AWS infrastructure for inventory, troubleshooting, and forensics; that security principles are being followed; and that the intended security controls are being correctly implemented.
Engaging the right AWS security partner
Reaping the benefits of secure cloud expansion is more efficient with the right partner on your side, there to help you every step of the way as you design, secure, test, and improve your cloud infrastructure.
How do you find the right partner? Here are some key considerations:
Expertise: The right cloud security partner has proven expertise in AWS. Since your business will be in the process of learning the platform, bringing in a partner who already has deep knowledge will help your business adopt it in a fundamentally sound way.
Collaborative approach: The right partner knows that AWS security must happen in concert with your business and its goals and can demonstrate their experience in collaborating with clients who have moved into the cloud with their assistance.
Mindful of security maturity as a process: The right partner has experience with AWS environments at all levels of security maturity. They can guide your business through the stages of security maturity, from the initial architecture and configuration of the environment to integrating the environment with other partners, to performing purple team assessments.
Why Security Compass?
Security Compass has the experience and expertise to be your trusted AWS partner. Fortune 500 companies work with us to design, develop, and secure cloud infrastructure. We have 30 penetration testers on staff who are AWS certified solutions architects and logged over 20,000 hours of cloud security assessment work in 2019 alone.
Security Compass not only has ground-up technical experience with AWS, but also the right approach to weave that expertise into a plan for your business. Our team also has experience integrating with development processes, including creating developer-minded security tools like SD Elements and building training software for developers.
To learn more about Security Compass’s technical expertise with AWS penetration testing and security, watch our webinar about Server-Side Request Forgery in the cloud as well as our Mitre ATT&CK in the Cloud webinar. You can also learn about our penetration testing services, and get in contact with us to discuss your AWS expansion plans and security needs.