Forward

(This forward will always appear). To get back into writing broadly helpful blogs, I want to resurrect a series I once wrote on a personal blog a long time ago, "AWS Security for Beginners" which looks to repackage fundamental building blocks and hopefully help newcomers and lateral movers to the cloud security industry understand core competencies.

I have done everything from being a Project Manager to Product Manager to Engineer to Architect to CISO and roles in between. I have been fortunate to stay very hands-on and involved with building and architecting on AWS (and other clouds & platforms) and want to put that body of knowledge to good use on your behalf.

The series will be loosely chronological, meaning that thematically I will go from simple & broad concepts to more specialized concepts as the series progresses and I will try to not create dependencies in the form of having to go back to X number of blogs to learn something.

Hope you learn something, but if not, that you at least Stay Dangerous.

What is “Shared Responsibility”

In the previous (and inaugural) entry to this series you learned about the AWS Global Infrastructure which is both the physical (geographic) and logical way that AWS represents its cloud and how you interact with it at a high level. In there we discussed the “old way” of racking and stacking servers and other physical hardware, using virtualization, and a massive amount of buying power to keep costs low – for you. This reminder is important, at least it will be, in the next paragraphs.

The Shared Responsibility Model – despite the “model” moniker – is a lot less rigid, it is not a framework, as much as it is a high-level guideline that defines (sometimes obviously) what the cloud provider (in this case: Amazon Web Services) is responsible for and what you are responsible for. At a quick glance, this is (fairly) obvious, the cloud provider is the one who must manage the purchasing, upgrading, decommissioning, patching, cooling, powering, and the labor force around the physical server and networking components. Then everything else is on you, right? Well, sort of.

When the Shared Responsibility Model was originally created, the complexity of AWS and other cloud service providers was not like it was today. In the very beginning, there were only SOAP interfaces which evolved to ugly consoles, to a bunch of RESTful APIs, to CLIs and SDKs, and then the massive number of services ranging from “automagic” machine learning to satellite ground stations, 5G network edge locations to a damn 18-wheeler with massive data-sucking power!

Each one of those “things” – be it the giant truck, your CLI, your console, or individual AWS services are all in-scope of the Shared Responsibility Model in some way or another. That is where the true grasp of the Shared Responsibility Model is achieved, not just in knowing what it is, but understanding its actual applicability across different services and components.

Let us start small: Security of the Cloud versus Security in the Cloud, this is AWS’ own terms, and applies to other providers and even (some) Software-as-a-service (SaaS) vendors too. While security is usually the topic of the Shared Responsibility Model, it does extend to non-security use cases, such as DevOps, networking, software engineering, IT Finance, and more.

Of the Cloud VS In the Cloud

As touched on before, AWS is the one on the hook for the “physical” part of the cloud, the servers and networking and physical locations. As a business, AWS needs to ensure that is in top working condition, is safe to use, is physically safe from ne’er-do-wells and government-backed data assassins, and in recent years: is sustainable – both environmentally and economically.

To that end, AWS describes their high-level responsibility as "...protecting the infrastructure that runs [all] the services offered in the AWS Cloud. This infrastructure is composed of the hardware, software, networking, and facilities that run AWS Cloud services.” That is broadly true across every single service and offering – besides software AWS maintains and offers for your usage (think about the CLIs and other APKs) as well as physical components (depending on who has custody at the time) – but can also increase.

Another popular way this “of the Cloud” responsibility layer is phrased is “below the hypervisor.” As in the last post, I do not want to belabor virtualization, but a hypervisor is also known as a “virtual machine manager” and is thus the software that controls the virtualization of physical components. AWS makes use of commercial and AWS-built hypervisor technologies to carve out and attribute virtual pieces of their infrastructure to you to use. So, anything outside of that management, you are on the hook for. There are AWS services which abstract even further than virtualization of the host, and the further they abstract, the more they are responsible for and the less you are.

A practical way to think about this, without getting into AWS services (yet), is the difference between using something like Intuit’s TurboTax to file your taxes and printing out a Form 1040 and doing it all on your own. Intuit (who also uses AWS) is responsible for managing the AWS instances and services that TurboTax is built on, is responsible for scaling it, for providing you a secure way to access it, a secure way to differentiate your session from others, and pretty much everything up to providing you with the information to the Internal Revenue Service (though Intuit is responsible for making sure it gets to our Tax Collecting Overlords).

While AWS will not come out and call certain services “software-as-a-service” (SaaS), that also applies, and harkening back to my takeaway from the last post: the foundations of a peerless security practitioner are understanding the nuances and employment of underlying services, you (and others, such as DevOps Engineers and Architects) will be looked upon to know the differences and the implications of services that are on that sliding scale of AWS’ responsibility.

To use another more AWS-y example, this is the difference between Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic MapReduce (EMR), and AWS Lambda. I promise we will get to all of those directly one day, for now, use the hyperlinks and your imagination.

Amazon EC2 is the do-all service that provides your virtual machines (VMs) in the cloud, AWS’ responsibility ends at their hypervisor and tenant management, you get the VM(s) and are on the hook to ensure that they are patched, have software installed, have their networking and identity requirements fulfilled, are responsible for shutting it down, and for backing up and securing the data. You are on the hook for the host-based security, for additional licensing costs (beyond any “built-in” licensing that may come with the operating system), for logging and monitoring and everything else. So those pieces that you are on the hook for? That is Security in the Cloud, but more than just security as I touched upon, that is your remit of responsibility while operating in the cloud. That does not cover everything – financial management, hiring, retention, providing access to the services, and all of that continues to pile up.

Despite the lines of demarcation for responsibility, AWS is happy to provide you with services to help with all of those “in the Cloud” taskings – but that does not mean they are responsible for it. Forgot to turn it off? Downloaded “back-doored” or end-of-life software? Got malware? Left your self-hosted database open to the internet without any form of authentication? You are responsible for that.

Not to deride anyone, but the Shared Responsibility Model does highlight software on AWS’ end such as Compute, Database and Networking – and I have worked with people who though that extended to those components on Amazon EC2 and other services. NO! At least not in that case.

Next is Amazon EMR, not the best example to use in a series meant for beginners, but bear with me. Amazon EMR is a suite of tools that runs MapReduce workloads on the AWS cloud, this is a framework (and family) of tooling to work with distributed and big data analytics such as Apache Spark, Apache Hive, Presto (well, Trino), Apache Flink, and others. The “regular” version of Amazon EMR uses Amazon EC2 under the covers, it deploys EC2s on your behalf and installs some software, so that brings AWS’ responsibility up to ensuring those pre-installed components and the orchestration of EMR is working properly, but you are ultimately on the hook for any jobs you run on that workload as well as securing, patching, and managing the EC2s (and the EMR deployment).

There are two more versions on Amazon EMR as well, but we will get to that much later. In old school cloud security parlance, Amazon EMR would be known as a “platform-as-a-service” (PaaS) tool, one in which the cloud provider gives you a platform to build off, it is (minimally) configured but the platform in question is still operated by you.

Lastly is AWS Lambda, this is in the loose categorization of a “serverless” service, which does not mean that a server does not exist -- or that the server runs on organic hardware, like a mashed-up human eldritch horror -- but that you do not mess with the server. A simplistic – and in the case of Lambda, a realistic – way of thinking about this is that AWS manages the Amazon EC2 virtual machines on your behalf to provide the Lambda service. So, what is Lambda? Lambda is an event-driven, serverless, function service – you author the code, configure AWS Lambda settings (e.g., how much vCPU or how long the function can run for), and select a variety of events that Lambda will run that code in response to. It can be an HTTP POST from another server, someone uploading a file to an AWS service or sending a message to an AWS service or an external service. I am being meaningfully obtuse here for a reason.

In the case of Lambda, the responsibility to heavily tilted towards “of the Cloud” as AWS is on the hook for running the servers that the AWS Lambda functions will run on, they’re in charge of provisioning them, maintaining a library of off-the-shelf runtimes for certain types of languages (e.g., Python, NodeJS, Ruby), and securing and patching the underlying services. On the other hand, you still have similar responsibilities, but they are far less and more manageable. You write the code, maintain it, configure the function, and make sure you do not allow just any ne’er-do-well to continuously invoke it and laugh maniacally as they increase your bill by $10.03 USD.

This is but the surface of Shared Responsibility and it remains a fluid and everchanging partnership between you and AWS. Misunderstandings are rare, but do happen, and can be fatal to decision making processes when it comes to service adoption. As services change, so does shared responsibility, and as AWS matures, they offer more services to help you plug in the gaps of your responsibility which can get more confusing as each service has its own Shared Responsibility. Confused yet? Good. That means you may be learning.

Next Steps

As always, take time to explore the hyperlinks and read more about the services and concepts that we explored in this post. I would also check out resources that AWS provides from their Cloud Security and Shared Responsibility landing pages to branch out into adjacent concepts. While it is more “art than science,” trying to grasp the different flavors of Shared Responsibility is important to understanding what you are on the hook for as security practitioner and where AWS can help fill gaps.

If you have not already, create an AWS Account, the only way to learn all of this is to start building and experimenting yourself. If there are ever any questions reach out to me on LinkedIn and I will be happy to help you out. There is a fair bit of more hands-off content to cover as we continued along, the next entry will be exploring some AWS-specific cloud security topics. Until then?

Stay Dangerous.