Navigating Cloud Security: A Shared Responsibility

Originally published by CyberArk.

Written by Alyssa Miles.

Each July, my family and I take a road trip from Kentucky back to my hometown in northwestern Pennsylvania to spend time on Lake Erie. As tradition dictates, we stop along I-71 for coffee at a branch of a certain coffee shop, which also happens to be my former employer as a teen. (Let’s call it Siren Coffee.)

This year, we sat waiting in the drive-thru for a drip coffee for a full 10 minutes. The frazzled barista profusely apologized and said they had run out because no one had refilled the machine, but a fresh pot was brewing.

This interaction transported me back to my barista days, and I recalled the many controls the coffee chain’s partners must follow to comply with health codes and protect the brand reputation of the store. All machinery must undergo cleaning and sanitizing. Trainers must ensure baristas are skilled in safely handling food and beverages. A timer, set as a safeguard for this specific drip coffee scenario, beeps at intervals to keep the coffee fresh and full.

However, all the controls in the world don’t matter to the health inspector if it doesn’t get done because you thought someone else was doing it.

In cloud environments, the cloud service provider (CSP) and the customer share security responsibilities to meet all controls. This shared approach ensures coverage for audits. It also clarifies the responsibilities of each party, making it clear who is responsible for what actions.

Let’s explore these responsibilities through the AWS Shared Responsibility Model lens.

Who Does What: The AWS Shared Responsibility Model

At Siren Coffee, there are different controls to maintain health and safety for employees and the public, and these controls fall within various roles. Each barista is required to follow procedures in food and beverage preparation, storage, and cleaning requirements. Shift leads are responsible for the people working. Store managers handle overall operations. Each responsibility is clarified and communicated through specific policies to ensure health code compliance.

Similarly, AWS clarifies roles and responsibilities by participating in a shared responsibility model. The model aims to relieve some operational burden for users, considering that AWS operates, manages, and controls the components from the host operating system and virtualization layer down to the physical security of the facilities where the service operates. However, customers are responsible for implementing appropriate security measures in the cloud to protect their data and applications.

Essentially, AWS is responsible for the security of the cloud, while you are responsible for security in the cloud.

The AWS Shared Responsibility Model (Source: AWS)

The AWS Shared Responsibility Model isn’t acting as a solo model for cloud security. It’s part of the security foundations within the AWS Well-Architected Framework, a collection of cloud security best practices built upon six pillars to help customers understand trade-offs for decisions made while building workloads on AWS. Zooming out from the model itself will give a complete picture of how it fits into building a holistic cloud security program.

A Perfect Shot: Security Foundations and the AWS Well-Architected Framework

When training to be a barista, you must know all the health safeguards and rules, learn the organizational structure to understand your responsibilities and memorize all the recipes. Everything you learn builds upon one foundational skill: pulling the perfect espresso shot.

Security foundations are that espresso shot for the AWS Well-Architected Framework. Once you have a handle on these areas, you can build and improve your cloud security program. It outlines best practices for protecting data, systems, and assets to improve your security posture. In the cloud, several principles can help you strengthen your workload security:

• Establish a strong identity foundation. Enforce the principle of least privilege (PoLP) and separation of duties with appropriate authorization for AWS resource interactions. Centralize identity management to eliminate reliance on long-term static credentials.
• Ensure traceability. Implement real time monitoring, alerts and audits for environmental actions and changes. Automate investigations and responses by integrating logs and metrics with your systems.
• Secure every layer. Adopt a defense-in-depth strategy with multiple security controls across all layers, including network edges, VPC, load balancing, instances, services, operating systems, applications and code.
• Automate security best practices. Use automated, software-based security mechanisms to scale security rapidly and cost-effectively. Develop secure architectures with controls managed as code in version-controlled templates.
• Protect data in transit and at rest. Classify data by sensitivity levels and apply encryption, tokenization and access controls as needed.
• Minimize direct data access. Employ tools and mechanisms to reduce or eliminate the need for manual data handling, thereby decreasing the risk of data mishandling or human error.
• Prepare for security events. Establish incident management and investigation policies that meet your organizational needs. Conduct incident response simulations and utilize automated tools to enhance detection, investigation and recovery speeds.

These measures outlined by AWS are an excellent starting point for building a cloud security program. Identity security is the first step in building a well-architected foundation for cloud security.

From Coffee to TEA: Implementing Cloud Identity Security

As any barista can tell you, when that morning rush hits, all you’re thinking about is the work in front of you. When assigned to the espresso bar, you’re deep in the weeds, making those coffees as each customer requests and getting them to that pick-up station. The last thought on your mind is the health inspector walking in and checking procedures.

Likewise, developers working within cloud environments are deep in the weeds of building requested features with a focus on deploying software. Compliance with security frameworks, like compliance with health codes, is critical. But, in both instances, you incentivize risky behavior when you make the safe option inconvenient.

AWS’s outlined cloud security best practices show that identity security is the first step to a successful cloud security program. According to the AWS Shared Responsibility Model, Identity and Access Management (IAM) is a responsibility that rests with the customer. It counts as security in the cloud.

So, what does that look like? The AWS Well-Architected Framework defines implementing a strong identity foundation as leading with PoLP. Our answer strays from coffee to adhere to this guideline and goes to TEA (time, entitlements and approvals).

TEA goes beyond the PoLP with a setup that has no entitlements available by default. Only after the necessary approvals are met (automatic, contextual, manual) will privileged access be granted. This access is only approved for the window of time required and with specific entitlements. After this window closes, users return to zero standing privileges (ZSP) within the cloud console.

With TEA, developers can avoid the frustration of coding sprint interruptions due to access issues, as the system grants access without the need for standing privileges. Secure, native access to cloud consoles fosters innovation and maintains velocity.

And maybe even a little time for a latte.

For a deeper dive into this subject, check out our eBook, “How to Secure Developer Access in the Cloud Without Compromising Their Velocity.”