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.
Cloud Security Overview
As the burgeoning security expert that you are, diving into cloud security for AWS can feel overwhelming, to say the least. The information AWS provides within different security domain areas, AWS service-specific security settings, the Shared Responsibility Model (which we covered in the last entry), tool categorization, and industry jargon makes this a harrowing topic. This is a topic that we will continue to chip away at slowly. Firstly, what is cloud security anyway?
Cloud security is a catchall term that encompasses any traditional security practices, well, on the cloud. While there are remnants of the industry that still call it out for certain tools, think of cloud security as an additive extension to typical security domains and subdisciplines. In some cases, the application of the practices does not change at all. Vulnerability management, application security (AppSec), IT governance, regulatory compliance, offensive security, security operations, endpoint/hosted-based protection? It is all more or less the same within the cloud.
Often you will hear that security in the cloud -- harkening back to the last entry, all the responsibility areas you need to cover – is harder because of the ephemeral nature or the elasticity of the cloud. That is not (totally) unwarranted. With respect to the cloud, ephemeral refers to the fact that all deployed infrastructure and services can be just as easily destroyed, and in many cases, this is by design. You create compute servers, or containers, or databases and either scale them up and down (which is what elasticity refers to) or you straight up destroy them after they are used.
Elasticity can also refer to some of the inherent “auto-scaling” nature of certain cloud services, which means the service will either create copies of itself or automatically reconfigure its own resources (CPU, RAM, Storage, etc.) to meet demand.
This ephemerality and elasticity are oft pointed to as a difficulty area when it comes to investigation and managing potential issues in the form of vulnerabilities, misconfigurations, bugs, weaknesses, or legitimate incidents affecting the cloud resources. If your services and infrastructure are as rocky as the sea during a storm, it can be hard to nail down the source of truth when it comes to treating risk in its various forms.
Truthfully, this is less of a problem than it is purported to be. Yes, if you do not otherwise have methods to keep a live inventory of assets along with all related security and configuration information, it can make (incident) response difficult. However, if the impacted asset is gone, is the issue still there? Also, in my experience, important network and identity constructs are typically not ephemeral so this issue only comes up in rare case-by-case instances. In other words, it is unlikely that the important parts of your baseline infrastructure - such as an Amazon Virtual Private Cloud or specific AWS Identity & Access Management (AWS IAM) Roles will disappear. That is an opinionated take borne out of real-world experience, and a concept we will explore later down the road.
As we reviewed during the Shared Responsibility Model post, AWS has several “baked in” security responsibilities (and general responsibilities) as part of the “Security of the Cloud” but AWS also offers many different overt security services as well as implicit and/or explicit security settings for AWS services. Part of this broad security architecture expertise you will need to acquire, as I have alluded to, is not just a regular cloud architecture knowledge but understanding the full security implications of service offerings, their configurations, their dependencies, those “built-in” security features, and later down the line the regulatory and industry compliance and legal posture.
(We will cover legal and compliance in more detail in the next entry to this series.)
AWS-specific Security Overview
The way that AWS describes it themselves, “…you will gain the control and confidence you need to securely run your business with the most flexible and secure cloud computing environment available today. As an AWS customer, you will benefit from AWS data centers and a network architected to protect your information, identities, applications, and devices. With AWS, you can improve your ability to meet core security and compliance requirements, such as data locality, protection, and confidentiality with our comprehensive services and features.”
They go on even further but let us break it down. As covered multiple times, AWS takes on the burden of securing the actual physical (and certain logical pieces) of the cloud offering itself. That means physical security, environmental security, firefighting equipment, ensuring redundant power and cooling, and other areas that your on-premises Chief Security Officer would have under their purview as it relates to business continuity, disaster response & readiness, physical security, and more. That is a very muted benefit, as you were not going to drop tens of millions of dollars on building your own data center.
(Though, ironically enough, AWS does offer physical devices in the form of the AWS Snow Family and AWS Outposts on top of Internet of Things and satellite technologies – so physical cloud security is more of a reality than a meme).
Further underpinning AWS' claims of world-class security is a massive amount of regulatory, industry, best practice, and legal compliance vetting in which individual AWS services and the Global Infrastructure, on top of employees and processes at AWS are reviewed by qualified assessors and independent auditors. So, in another word, AWS can cash the check their mouth (or, "Twitter fingers") is writing for themselves. AWS gives you all the widgets and guidance but as the cloud security expert you will become you will need to know how to use a combination of those facts, tools, and your own understanding to secure you workloads.
To go further, AWS has its own internal threat hunting, application security, security operations, security architecture, and other specialized security teams. This capability is not necessarily customer-facing, at least not in its full capacity, but their Trust and Abuse apparatus as well as (limited) internet scans can provide aircover in the form of identifying truly high-risk events, potential fraud, finding CSAM or DMCA related materials, or interdicting your own infrastructure if it happens to be hijacked by a sophisticated attacker. These capabilities are mentioned, maybe not as overtly, in different areas but are typically only deployed in response to egregious events and AWS is not obligated to do so beyond ensuring their own security and avoiding potential legal and/or reputational damage.
AWS has its own parlance when it talks about “strategic security” – both from a more “vertical” grouping of services and processes as well as “horizontal” product categorization that fall within industry norms. It is worth noting that this parlance is not consistent across all AWS documentation and products (both the actual AWS services as well as whitepapers, blogs, and other collateral).
Prevent
This area covers all identity-related taskings such as ensuring minimization of permissions and identities themselves including authorization, authentication, multi-factor authentication, and entitlement management. Prevent also covers “active” data and infrastructure protection such as employment of a variety of firewalls, encryption (which in AWS, is closely tied to identity), and overt data protection for certain services. So, simply, any mechanism by which you stop (prevent) someone – regardless of how malicious or not they are – from accessing “cloud stuff” due to security reasons.
Detect
This area covers asset visibility (knowing what deployed services are where), configuration & posture management, logging, monitoring, tracing, and the management and dissemination of all that data. This is also an area where my own tool, ElectricEye, operates for AWS and other clouds and SaaS providers. In practice, this is the area you will spend much time concentrating on as it supports other categories, you cannot Prevent access to something you do not know exists, right?
Respond
This area covers all automation and orchestration with AWS to “react to contact” be that creating and triaging incidents, recovery of services and infrastructure in the form of backups for traditional disaster recovery or using the automatic elasticity of certain AWS services, as well as the forensics and post-hoc response in the form of “battle damage assessments”.
Remediate
To me – this area is redundant with Respond – but this area covers the more active countermeasures and posture reconfiguration within the Respond area. This can be automatically rotating credentials and encryption keys, applying stringent security policies and protections in direct response to an event or incident, and fixing configuration and weaknesses in near real-time.
These categories are remarkably close to the United States’ National Institute of Science and Technology (NIST) Cybersecurity Framework (CSF) which has five “pillars” that cover down on these four “strategic security” areas that AWS defines. We will be exploring the CSF in the future, but it is worth a cursory glance, or at least familiarity of its five categories: Identify, Detect, Protect, Respond, Recover, with a forthcoming version of the CSF also adding a sixth Govern category.
AWS Security Service Categorization
As mentioned in the previous section, AWS also has a more “horizontal” taxonomy that defines security capability areas that their tools are loosely organized under. This can be a bit confusing depending on how familiar you are with Gartner and the wider industry terminology, for the most part, AWS terminology is much broader and can overlap with several capabilities and practices as well as overlap with other AWS categories.
AWS uses both this "taxonomy" and industry terminology interchangeably. AWS also goes further to categorize AWS Partners (other vendors and consultancies that, well, partner with AWS) even if they call their offering or product something different. I call this out again to be wary of confusing or conflicting terminology and another important soft skill to have as a security expert: the ability to disambiguate and clearly (over)explain a concept.
Network and Infrastructure Security
This category covers traditional firewalls and other network based detection and prevention technologies (Threat Detection/Incident Response (TDIR), Unified Threat Management (UTM), Network Intrusion Detection System (NIDS), etc.). AWS calls this capability “infrastructure security” a lot more than not in their own documentation, which does make sense, as the cloud is defined as publicly accessible services over the internet – so the “network” part of infrastructure is implicit. At least that is what I assume their thinking is. Infrastructure security also includes the usage of “private” connectivity (e.g., connections that route solely through your own AWS environment or AWS’ internet backbone) as well as automatic traffic encryption.
Host and Endpoint Security
This category covers “agents”, “sensors”, or other software installed onto a virtual machine itself (or tightly coupled with it, such as a “sidecar container”) that can provide detection and prevention of threats. This typically covers malware and data loss tooling such as Anti-Virus, Endpoint Detection & Response, Endpoint Protection Platforms, File Integrity Monitoring, Cloud Workload Protection Platforms (CWPP), Host Intrusion Detection Systems, and Data Loss Prevention. It is important to know that AWS only recently (circa 2021) started a foray into this area in the form of certain Kubernetes and post-hoc hosted based tooling and relies heavily on Partners and open source to shore up this area.
Data Protection and Encryption
This category covers any explicit data protection services such as encryption, User and Entity Behavior Analytics (UEBA), Data Classification, Data Loss Prevention (via Identity, likely), Data Loss Detection, and the newly vaunted Data Security Posture Management industry lovechild. AWS has a lot of services and are expanding into per-service offerings here such as active detection and masking or removal of sensitive data elements being sent to certain application integration and messaging offerings.
Governance, Risk and Compliance
This category covers both consultancies as well as services that provide analysis of technical and procedural “controls” that you should or must implement in an environment. This typically takes the form of ingesting output from other security tools and service-specific configurations to make that determination – either automatically or as part of a formal auditing or assessment process. AWS does surface their previously mentioned audit paperwork via the AWS Artifact service but has since also created the AWS Audit Manager service which is meant to collect and centralize this evidence as well.
Logging, Monitoring, Threat Detection, and Analytics
This category covers the centralization, aggregation, analysis, and/or reporting on various logs, alarms, metrics, traces, and other telemetry for the sake of providing visibility and surfacing “security insights”. These include Security Information & Event Management (SIEM) tools, Extended Detection & Response (XDR) platforms, and have some overlap with other categories that also provide in-place security analysis such as TDIR and UTM tools.
Identity and Access Control
This category broadly covers all identity & access management use cases and tooling including the definition, management, access control, and entitlements of permissions, user assignments, governance, authorization, authentication as well as Single Sign-On (SSO) via Security Assertion Markup Language (SAML) and OpenID Connect (OIDC). Tools in this category can also include Identity Governance & Administration (IGA), Identity Providers (IdP), Identity Threat Detection & Response (ITDR), and Privileged Identity Management (PIM) to cover the more identity-focused part of this category. Access Control also extends to Cloud Access Security Brokers (CASB), Secure Access Service Edge (SASE), and Zero Trust Network Access (ZTNA) tooling.
Vulnerability and Configuration Analysis
This category broadly covers all types of vulnerability management and posture management tooling to detect vulnerabilities, weaknesses, and other issues. It includes every type of configuration, posture, and vulnerability management activity other than code-related tooling and practices which is covered by the Application Security category. This category includes deployment tooling for building secure artifacts, Threat & Vulnerability Management tools (TVM), Container Security, Cloud Security Posture Management (CSPM), Cloud Native Application Protection Platform (CNAPP), and general Asset Management tools.
Application Security
This category covers any tooling and processes which assess and analyze code, business logic, inputs, and software dependencies and supply chains for vulnerabilities, weaknesses, bugs, and similar security issues. AWS has only recently gotten into this area with first party offerings but tools in this category include Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Interactive Application Security Testing (IAST), Software Composition Analysis (SCA), Software Bill of Material (SBOM), Application Security Posture Management (ASPM), and Application Security Testing Orchestration (ASTO) capabilities.
There are a handful of additional categories that are not worth calling out as they are solely focused on consultancy AWS Partners and will not be first party offerings, nor are they used in documentation. It is worth looking into some of these tools and capabilities that were mentioned as it is highly likely you will encounter a decent amount of these at an employer or when you are researching labs. It is also worth understanding that while several tools may exist in a category, they can still highly differ in their purpose.
Next Steps
As always, take time to explore the hyperlinks and read more about the services and concepts that we explored in this post. You do not need to memorize every single tool and capability, but it is worth committing to memory the different ways that AWS explains services and uses a mix of their own terminology and industry terminology as well. You will more likely encounter this if you ever took part in an evaluation or Proof of Concept (POC) with different vendors – knowing about categories can aid in research – but also you will see the terms in AWS service documentation.
Cloud security, just like regular cybersecurity (or is it information security? Do not answer that, I do not care), does benefit from having a wide breadth of exposure but really benefits from choosing a specialization. There is quite literally too much to cover and master overall. That is why security folks self-organize in communities, why there are more consultancies than you can shake a sharp stick at (the consultancies also have a lot of sharp sticks), and why you are on a security team.
You do not need to make up your mind on what you want to do this second, however, even with a specialization you will end up doing a lot of general “engineering” and “architecture” either way. Just something to keep in mind, take your time to learn networking, how identity works, how operating systems work, the basics of services, and build up security knowledge and then specialization.
There are only a few high level concepts left to cover, in the next entry we will explore (at a high-to-medium level) Governance, Risk, Compliance, and Privacy (GRCP), how all those areas are distinct but co-dependent and how to think about GRCP on the AWS Cloud. Until then?
Stay Dangerous.
Top comments (0)