DEV Community: Jonathan Rau

AWS Security Beginner Series #3: AWS Cloud Security, an Overview

Jonathan Rau — Fri, 07 Jul 2023 14:24:56 +0000

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.

AWS Security Beginner Series #2: The (AWS) Shared Responsibility Model

Jonathan Rau — Wed, 05 Jul 2023 13:01:00 +0000

Forward

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.

AWS Security Beginner Series #1: Global Infrastructure

Jonathan Rau — Mon, 03 Jul 2023 17:17:44 +0000

Forward

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

So, what is AWS again?

The most formative question when you begin: what exactly is AWS? Amazon Web Services (abbreviated as AWS or AWS Cloud) is Amazon's public cloud business which has been around nearly two decades. AWS allows you to access services such as storage, computing power, database, and other specialized use-case specific tools over the internet (hence public cloud) using a console (or other interfaces, we'll get to that later in the series) in which pay as you go meaning you get a monthly bill depending on your usage of a service. This can be how many gigabytes of data you store, how much memory is in a compute instance, how many times you run or invoke something, and so on.

The industry has largely moved away from distinctions of public cloud versus private cloud, but it is an important distinction from a security perspective. When I was first learning about the cloud I was always confused about the public piece, again, that is to denote you can access and consume services from anywhere on the internet. While your services that you build on using cloud resources can be public (e.g., they have an internet-facing IP address and/or DNS name) that is not what public cloud means.

The next question you may have (I had it) was how the hell is this even possible? The easiest explanation, without getting too much into the inner workings and macroeconomics of virtualization, data centers, and hardware financial lifecycles is that Amazon uses their money to purchase an eye-watering amount of traditional hardware and essentially leases parts of it, on-demand, to you.

Traditionally, a company would need to purchase several servers (with their own motherboards, cooling, power supply, CPUs, RAM, GPUs, etc.), networking equipment (routers, switches), storage, and license virtualization, operating systems, database engines, security tools, and more. All this hardware would be "racked and stacked" meaning assembled into their final configuring, "hooked up", and have the OS and applications installed onto it. The company would use virtualization to essentially get "the most bang for their buck" by creating virtual servers on the physical servers.

So if your server has 64GB of RAM (memory) available, and the application you are running only requires 8-12GB, you can slice and dice that 64GB into virtualized servers which has its own dedicated CPU, memory, storage, and networking carved out from the physical gear on the server. This could be done to serve more customers with their own copies of an application (sometimes called a tenant or instance) or to stretch budgetary limits or to even segregated workloads from each other.

This is of course, expensive, as you bare an upfront cost burden (though there are other leasing and rent-to-own schemes) plus the human capital expense of having systems administrators, network engineers, and more with expertise in the entire lifecycle from the day the server is unboxed to the day you send/sell it back.

This has not changed.

The value proposition of using the cloud is that the giant multi-national multi-billion dollar company does that all on your behalf and uses the same virtualization technologies and economies of scale -- they have greater buying power to command greater discounts to purchase more stuff -- to let you consume the services and only pay for what exactly you consume, as noted earlier.

This greatly lowered the barrier to entry for startups and established companies that were looking to modernize across all industries. Now, nearly everything you consume from your on-demand videos to video games to food ordering to banking to taxes to taxis and more all are hosted on the cloud. As the usage of cloud services evolved, even the most cynical and secretive organizations in the world have adopted the cloud for doing everything from raw storage to advanced targeting using machine learning algorithms and big data analysis.

Now how does AWS organization what amounts to 10s of 1000s of servers, network gear, and storage drives?

AWS Global Infrastructure Basics

“Global Infrastructure" is AWS' own terminology which broadly refers to the entire geographic distribution and hierarchy of how you consume and interact with the AWS Cloud. The "internet" is a huge place, and for the best performance, you should consume these services as geographically close to you as you can. It takes energy (and thus costs money) to move even the smallest byte across the world. The closer you can be to that point of origin, the better performance and cost you get, for the most part.

To ensure that AWS services can be consumed by customers across the world and all industries, AWS first picks a Region that they define as "...a physical location around the world where we cluster data centers." Remember, the data center is just a location that contains all of the hardware needed as well as support staff and security, and each Region is made up of a cluster of more than one Availability Zone (AZ) which AWS denotes as a "...group of logical data centers..." which is at least one data center.

The number of DCs that comprise an AZ largely depends on the newness of the Region and the actual geographic area. There is only so much space and access to the required power and labor force in any given area in the globe - and that largely dictates where AWS can build a Region as well as how many of these AZs. As demand, geopolitics, and economic environments change, AWS may choose to expand a Region or build new ones. Another barrier to creating more AZs is that AWS commits to at least 100KM (60 miles) between the AZs, but does not disclose how far the specific DCs are from one another.

Each Region is made up of at least three AZs and each AZ "...has independent power, cooling, and physical security and is connected via redundant, ultra-low-latency networks. AWS customers focused on high availability can design their applications to run in multiple AZs to achieve even greater fault-tolerance." When you select a Region to use an AWS service in, at a minimum, you're using at least one AZ. Sometimes this AZ usage is more pronounced, which we will get to, but all you need to know is an AZ denotes a data center somewhere within the area of the Region.

Regions are usually centered in a metropolitan area but may not be referenced as such. For example, AWS' North Virginia region, known as us-east-1 covers cities as far north as Ashburn and Sterling, as far south as Manassas and as far east and west as Vienna and Haymarket, respectively. Other Regions may not be as large - the Ohio Region (us-east-2) is within the Greater Columbus Ohio area that spans from Hilliard, Dublin, Columbus proper, and Worthington.

Another quirk of AWS AZ's is that they can be different for everyone. When you choose "Availability Zone 'A'" in us-east-1 (known as us-east-1a) to build or deploy an AWS service, it is different from customer to customer, that AZ "A" can be in a specific building in Herndon or Vienna or Manassas. There is a way to tell, but that's largely out of your control, and also largely does not matter. More information on this quirk (and more facts about the Global Infrastructure) can be found here.

When you select a Region, it should strike a balance from how close it is to customers (if you are building a service that is meant to be consumed) and how close it is to your team. This latency may not always matter, but the difference of a few milliseconds (or a few seconds) can make the difference between a consumer choosing between you and your competition, it can also have influence on timeouts for your services, and also loosely has some impacts on security. We'll discuss this much later, but there are regulatory and industry compliance requirements as well as laws that may dictate that certain (or all) types of a specific (or all) data for a certain market or demographic must be contained in one area. A common callout here is the European Union's General Data Protection Regulation (GDPR) which codifies legal and technical requirements for how data about EU citizens can be accessed, transferred, and stored.

There are also cost and availability considerations, which is more "advanced", some Regions are more expensive than others to use specific services. Additionally, Regions may be constrained with availability for certain Services. This can happen for very old and very new AWS services as well as AWS services and components that are used a lot - this will be explored much later as to not belabor the point - if you're just learning, pick a Region closest to you, and do not worry about it much.

Ultimately, as touched on, your choice may be dictated to you by AWS in the form of Service availability. AWS has nearly 400 distinct services ranging from object storage to very specialized security services, as AWS builds services on other AWS services, there are only so many areas that can be covered as they are created. Always refer to the information page of a service you wish to consume to be sure.

AWS Global Infrastructure Extended

While Regions and their AZs are considered the formative baseline of the AWS Global Infrastructure and are often very muted depending on the service(s) you use, there are other Global Infrastructure concepts that may be beneficial to keep in the back of your mind.

The first is the Local Zone which you can think of as a mini-AZ that has an even more specific geographic area but with the drawback that they're not numerous, they do not have the ability to host or deploy every AWS service, and can cost several times more than in a regular AZ. This is because the economies of scale are not as great (given the smaller location) and that other redundancies such as dedicated networking is built into the area. You may use one if you had incredibly specific sets of customers in addition to ultra-low latency requirements. As of the time of this writing, AWS boasts 34 Local Zones from Newark, New Jersey, USA to Auckland, New Zealand to Lagos, Nigeria with dozens more planned.

If a Local Zone is a mini-AZ, then a Wavelength Zone (WLZ) is a mini-Local Zone (or a micro-AZ, if you'd like). WLZs follow the same principles of hyper-localization and ultra-low latencies except instead of a metropolitan area edge location for the internet, the WLZ edge is a telecommunications provider's network coverage area, focused around 5G service. This means that the latency is even lower potentially than a Local Zone and have even less available services to consume and greater costs. However, if you have a specific carrier network where your customers are specifically consuming services via a mobile application, it can be worth looking into. In the United States, all the WLZs at the time of this writing are in specific Verizon 5G locations in specific cities, with other carriers accounted for outside of the United States such as Vodafone in Berlin and Munich or Bell within Toronto.

Taking a big step back from geographic specific concepts such as Local Zones and Wavelength Zones, there is a global network within the AWS Global Infrastructure known as the Global Edge Network. The Global Edge Network is what underpins Amazon's Content Delivery Network (CDN) service, known as Amazon CloudFront. We will examine this service in greater depth in the future. The important thing to know about CloudFront and CDNs in general is they are useful for supplying content close to your consumers like a Local Zone or WLZ can be used for. Instead of building an entire offering, you use a CDN to supply resilience, performance, and lower latency by "caching" content such as videos or pictures in small "Edge locations" which reduces strain on your backend and supplies a better consumer experience.

Using CloudFront, AWS handles this distribution for you and boasts over 400 "Points of Presence" which are mini datacenters located all over the world from South Africa to Japan to New York to Oslo which are controlled by 13 Regional Edge Caches, you do not need to do anything to utilize this beyond configuring the CloudFront service. However, you can apply geographic restrictions and tune your caching and security performance more specifically, which we will explore later.

To round out the "extended" topics, the last concept to be familiar with is an AWS Outpost which are "...fully managed solutions delivering AWS infrastructure and services to virtually any on-premises or edge location for a truly consistent hybrid experience. Outposts solutions allow you to extend and run native AWS services on premises, and is available in a variety of form factors, from 1U and 2U Outposts servers to 42U Outposts racks, and multiple rack deployments." What does this mean in practice? Imagine a portable, self-contained, mini data center that specifically mirrors AWS that you can bring with you (provided you can power the thing).

AWS Outposts range from "1U" size which is a specific blade in a server rack up to the "42U" behemoths that can be utilized for companies that either want to directly support a "hybrid" use case, are beginning a migration or exploratory analysis of AWS, have even lower or specialized latency requirements, or part of a government, military, law enforcement or disaster response organization that requires usage close to you an in potential austere, restricted, denied, or remote environments. The prices vary greatly, but can be paid monthly or up-front for 1 or 3 year terms which can range from $170,000 USD up to $775,000 USD depending on the configurations.

Outside of the lab, you may encounter one or more of the concepts, but on your own it is not likely you will have much interaction with any, but they are important to understand. While the overt security requirements may differ, the key to being a good cloud security practitioner no matter your specialization is familiarity.

Next Steps

Take time to explore the hyperlinks and setup an AWS Account if you have not already, again, a lot of these concepts are abstracted from you depending on how you use AWS but are important formative topics to learn.

In the next entry we will cover the AWS Shared Responsibility model which is often talked about but not well understood in certain cases.

Until then...

Stay Dangerous.

ElectricEye 2.75: Expanding Open Source Multi-Cloud Security

Jonathan Rau — Thu, 01 Jun 2023 14:05:30 +0000

Setting the Stage on ElectricEye

What better for my first dev.to post than talking about my first large-scale (and longest maintained) open-source project, ElectricEye. This post is dedicated to the release of version "2.75" (as in 2-3/4 not a real semantic version).

For the uninitiated, ElectricEye is a Python CLI tool dedicated to assessing cloud environments against 100s of checks for security, resilience, performance, and general best practices. What started as "the open source AWS Cloud Security Posture Management (CSPM) tool with the most coverage" has transcended (finally) to something even better.

ElectricEye has only recenty gone "multi-cloud", or "omni-cloud", as there is not a good term for both Public Cloud (e.g., AWS, Azure, GCP) and Software-as-a-Service (SaaS) combined. I optimized a half-decade of technical debt and bad Python to make ElectricEye more performant, broader, and more usable and approachable than ever before.

So let's get to it.

Two Point Seven Five

If you check out the Issues you may notice an ElectricEye 3.0 issue, like almost every software project in the world, after scoping a high-level Definition of Done like the world's strongest Scrum Master I quickly realized I was in deep sh*t. There was so much to do.

Between family duties, Merger & Acqusition duties, Board Advisor duties, and regular CISO-life (though as of the publishing of this piece I will not be CISO @ Lightspin any longer) -- I've managed to carve out time to take a huge chip out of the "3.0 prerequisites". This "2.75" version of ElectricEye introduces the following:

Coverage for Oracle Cloud Infrastructure (200+ checks, 20+ services) and Microsoft's M365 (3 "modules" and 30+ checks). Additional AWS checks have been added for EMR & Redshift Serverless, CodeDeploy, and others.
Loads of optimizations to allow ElectricEye to run 40% faster on pre-Python 3.11 - I've only tested down to 3.8. 3.11 is already pretty damn quick.
Expansion of the Attack Surface Monitoring (ASM) modules with an overhauled Shodan evaluation, new reverse-DNS function (no more socket resolving to your private IPs), support for VirusTotal and CISA KEV for malware & vulnerability exploitability enrichment.
Complete documentation overhaul for how to use ElectricEye and its Outputs, how to contribute and write your own Auditors, complete with a new Docker-specific section, Output examples, and...
New Outputs and revised Outputs. Added responsive HTML reports for audit-readiness and CSPM-focus along with Amazon SQS and two types of native Slack integrations for per-finding or summary-report alerting. Multiple Outputs are now supported.
Public Docker images on Docker Hub, Amazon ECR Public, and Oracle Cloud Infrastructure Artifact Registry along with a properly multi-layer Alpine 3.18.0 base image that won't break
Improved security-minded CI to build & scan SBOMs, better written CodeQL & Dependabot GH Actions, and I actually version pin now...
Improved controls mapping across NIST CSF, NIST 800-53 (rev. 4), AICPA's Trust Service Criteria, and ISO 27001:2013/2017 and information within finding descriptions & remediation. This is in preparation for future controls mapping work
Re-imagined "global service" and service eligiblity awareness for ALL AWS Partitions, even the SC2S/C2S zones. No more running into superfulous errors on endpoint availability or running S3 and CloudFront checks once per Region
Improved error handling, better written Python, and check logic for 100s of checks across ElectricEye - helped to improve speed, UX/DX, and fixed several evaluations that did not work properly.

There are probably some things I am forgetting in there, but overall, what started as a sh*tpost PR to add a few Oracle Cloud checks, ended up being one of the most comprehensive PRs I have ever done.

And now for some highlights.

Omni-cloud!

I added GCP checks about 2 months ago from the time of writing, the implementation relied on an insufferable amount of spaghetti code via click command line arguments and made a general mess of things.

To improve this experience, I wrote a new class (CloudConfig) within the codebase to handle cross-cloud/cross-SaaS integration with various API keys, OAuth tokens, X.509 certificates alongside shimming AWS Secrets Manager and AWS Systems Manager Parameter Store for retrieving sensitive values. This will be an area of focus to expand offerings for credential stores in the future, but not for awhile.

Additionally, I added much better support for AWS multi-Account/multi-Region support with a way to build partition-aware Boto3 Sessions, and as a way to keep the read-only evaluation permissions away from your local credentials that will have write and read access to secrets, buckets, queues, and the AWS Organizations APIs. You'll need to be a Delegated Administrator (or be in the AWS Management Account) to make use of the OU and Orgs-wide evaluations, however.

This also laid the path for reducing the amount of arguments needed to run evaluations and made ElectricEye more portable. You'll need to put in a tiny bit of groundwork to filling out a TOML, but you can parallelize with per-Auditor, per-Assessment Target, or per-Check CLI filters across multiple Regions and Accounts (or equivalents in other environents).

While the integration for different providers is not turnkey, it helps me write them that much faster, and can keep the discrete logic differences apart from each other. In fact, outside of pulling credentials from AWS-services, you do not need to run ElectricEye from AWS or with AWS creds at all.

That said, since every check is written against the AWS Security Finding Format, your current Session's AWS creds will be used to fill in the parts of the ASFF that require partitions, region, and Account information. This is only required for Security Hub - so it's jarring - but necessary.

Lastly, I've just about squashed all environment variables, I will still set some but no longer do you need to preset them and have a dozen or more of them in your Dockerfiles or container orchestration tools.

Outputting findings

While some of the changes happened in my last "2.5" release, I've been revamping all Outputs to make them more performant and responsible. What I mean by that is "upserting" findings into PostgreSQL and MongoDB, adding better support for TLS or cloud-native CAs for certain services (like MongoDB vs AWS DocumentDB), and adding more Outputs dedicated to the asset management side of the house.

I fixed the multi-output issue - the one where more than one output was not supported - so now you can totally generate CSVs, JSON, HTML, send findings to Security Hub, Slack, and PostgreSQL and more.

I added a native Slack integration I removed when I shuttered the "extras" part of ElectricEye that totally relied on AWS Security Hub and Lambdas + EventBridge. Slack can send filtered findings (by state and/or severity) to Slack or send a summary after each run using the new Slack Apps.

I also added support for Amazon SQS and writing in batches, this will provide the greatest flexibility for portaling findings around AWS especially if you're well-versed in parsing the ASFF which all ElectricEye findings conform to.

Finally, I added a second canned HTML report which uses some not-so-clever HTML tables, responsive CSS, and matplotlib to generate framework-level and control-level reports and impact analysis for your ElectricEye evaluations. It is not an audit report, but can help you get ready for one, or maybe decide to jettison controls you suck at operating.

Don't do that last part. Or I'll beat up your CISO. (In Minecraft).

I plan on revising DynamoDB, adding Microsoft Teams, and revising the CSV output, and selectively adding some non-AWS Outputs for other clouds. Maybe.

Expanding Attack Surface Monitoring

In the past, I added Shodan integration as a callback to some old code I wanted to use for an AWS blog post once-upon-a-time. Shodan and cloud assets is not all that exciting, until it becomes exciting, as are most things in cloud security.

Often you'll find that giant public DB or ELK stack attributed to your IP is the previous owner of whatever that regional public EC2 CIDR block the IP belonged to.

Not that it deters adversaries from swallowing the data up in their automation and smashing your edge.

I added NMAP support to do a custom "Top 20" port scan with future plans to add more functionality one day. While it is early days, I want to revisit how I can commoditize low-hanging-fruit-ASM so I've started to cherry pick other services to use.

I've added Checks that compare CVEs discovered by services such as Amazon Inspector, Oracle Cloud VSS, and Microsoft 365 Defender to the CISA Known Exploitable Vulnerabilities (KEV) catalog. I've added a way to compare sha256 hashes from Oracle Artifact Registry to hashes in VirusTotal. I will be working on this as a point of focus in the second half of the year, making certain parts more pluggable and performant, including ZAP and security header checks.

I completely rewrote the reverse-DNS lookups in ElectricEye to use Google DNS' public API and break away from using socket. While it was not always an issue, using cloud-specific DNS like AWS VPC or otherwise, could often give you back private IPs or completely wrong or empty responses. It's not perfect, but you'll miss less checks especially when it comes to DNS-only endpoints like Amazon MQ or AWS ALBs.

I have a working prototype for NMAP Script Engine (NSE) scripts as well as basic ZAP scans when connecting to one or more remote ZAP hosts. More to come on that, thinking about a better vulnerability prioritization engine as well that will bring in more exploit sources, so-called "SOCMINT", and deceptive technology.

Performance, performance, performance

Python is a fun language. Also, the only language I know. I also self-taught by writing a SOAR engine on AWS Security Hub as my first ever project. Not the best idea in retrospect.

I picked up a lot of bad habits like endlessly nesting for loops, handling errors with triple-nested try, except: continue type logic, and changing native types when I did not need to. Not using f-strings, not using list comprehensions, importing whole libraries instead of specific modules, pretty much any optimization anti-pattern.

Every PR I ended up finding more things to fix, be it evaluation logic or f-strings, or improving the consistency and readability. I made a concerted effort to be better with all new Auditors that I write for new clouds but also have gone back to fix and totally revise (in some cases) the AWS Auditors, or the "gen 1" evaluation logic in ElectricEye.

Benchmarking on Python 3.8, 3.9 and 3.10 - I was getting on average 40% quicker evaluations - even with the more I/O-intensive tasks like running detect-secrets against outputs of service environment variables written to file or running NMAP. I am trying to eek out every bit of performance as not everyone will be running ElectricEye on a M5.4xlarge instance or an over-provisioned Fargate deployment. There is still more work to do, but it vastly improves the end-user experience when your tool can run quickly and without errors with better overhead.

To add to this, I also revamped how AWS-specific checks handled service eligibility. It is no secret that AWS has multiple partitions (though only 3 are commonly known: commercial, US GovCloud, China Region) and also have various Regional support for different services. Old services like CloudSearch or odd services like Amazon Managed Blockchain obviously do not have the Regional support (nor customer usage) that something like Amazon S3 or Amazon EC2 will.

The new check uses the endpoints.json file directly from botocore and some extra parsing as endpoints are not 1:1 with service names. In the past, ElectricEye (and others) have used the "AWS Global Infrastructure" SSM Parameters which were not always accurate nor available in other Partitions. Now, no matter if you're working on TS/SCI targeting systems for the IC in SC2S or working on multimedia projects in AWS China or ATO-on-AWS in US GovCloud: your ElectricEye evaluations for AWS run only the Auditors that can be ran.

Speaking of S3, and other "global" services such as Amazon IAM and CloudFront, these Auditors will now run at-most-once and have the Regions hardcoded to aws-global (or the Partition-specific "global endpoint" such as aws-gov-global or aws-iso-global) as setting them all to us-east-1 is: jarring (especially when you're an "EU only" type shop), doesn't work for non-Commercial partitions (whose "global regions" are poorly documented), and better reflects those services.

With just S3, IAM, and CloudFront - that is more than 25 Checks per Region you only need to run once. Hence why it's in the performance section. Other Global Services include "Global" scoped WAFv2, certain Shield Advanced APIs, Trusted Advisor (well, support), and AWS Global Accelerator.

ElectricEye on Docker

So, ElectricEye could always run on Docker, the Dockerfile has been in there in various flavors since day one. ElectricEye at first was totally centered around running in on AWS Fargate (well, ECS with a Fargate launch type). The latest incarnation is Alpine 3.18.0 with a properly implemented multi-layer image that accommodates as little libraries as possible.

As ElectricEye expands to "omni-cloud" coverage, the dependencies start to bloat, and with the recent additions of rich HTML reporting (using matplotlib and pandas in the back) I was loathe to include them as using them with Alpine has been hellacious. Pro tip: use the apk and not the PyPI packages if you can help it.

So the better implemented multi-stage build helps speed up builds, manages dependencies a bit better, and allows you to bring ElectricEye anywhere. I've added documentation on using Docker where you can supply your own AWS credentials safely as well as overwrite the TOML configuration file that is pre-built into ElectricEye.

Speaking of pre-built, ElectricEye is now on Docker Hub, Amazon ECR Public, and Oracle Cloud Infrastructure Artifact Registry (for Containers), that last one is a meme and a mouthful all at once. Each of these are built and tagged with hashes and latest with GitHub Actions and I have also added Grype and Syft support to built and scan the SBOM produced from the built image for transparency and usage.

I will add additionally Registries as they make sense (cost is the main driver) and to give everyone a "compliant" offering inasmuch as using a specific registry may be dictated by internal policy or otherwise.

Do note that for the file-based reporting such as JSON, CSV, and HTML that you should supply s3:PutObject permissions to your ElectricEye profile so you can easily get them offloaded. Or, you know, run it locally instead of in a container. Or use a PV. Or whatever.

Eventually, Kubernetes is on the roadmap as I build out other parts of ElectricEye for "3.0".

Future Plans

Well, ideally, if someone wants to buy the IP and procure my services alongside it I would not be opposed. A few have kicked the tires on the idea but nothing has made it across that finish line. Tell your CorpDev folks to come hit me up?

Acquisition sh*tposting aside, that is not why I wrote ElectricEye and it is not why I continue to maintain it.

The security industry has commoditized CSPM drastically but I still find it leaves much to be desired. Sure, you get CSPM "for free" in a lot of places, but at the sacrifice of low service coverage, poorly documented APIs, not supporting all your clouds, let alone getting SSPM, ASM and asset management for free.

I give it all away just about. Sure there are "secret" features on local branches on personal devices I hold back, but the idea was always to make the broadest and deepest CSPM tool - and now with SSPM and other capabilities I hope it'll be the choice for security programs of all sizes and maturity. I cannot speak to whom, but it is being used in every single AWS partition and by companies with a footprint as large as 3K Accounts in AWS.

Pontification aside, I am still building towards "3.0" which means a bare-bones web application that can be easily spun up by any Cloud or Security Engineer/Analyst together with a performant and secure API and other "enterprise-y" features as I can get in such as MFA and SAML/OIDC. I have NO IDEA how to do most of that, but I will figure it out.

In a loose order of importance, here are some things I am working on as I have time for ElectricEye on the "road to three-dot-oh".

Expanded support for GCP

I plan to flesh out GCP to 20-30 services before I am happy with it. This will include the typical ASM-specific Auditors as well as the Firewall Rule evaluation.

Unlike AWS, there are not a ton of superfluous or overlapping service offerings for GCP. I will also add a new SSPM Assessment Target in the form of Google Workspaces along with trying to extend support to Folder- and Organization-level evaluation.

Expanded support for AWS

I want to "finish" AWS inasmuch as covering all of the likely-to-be-used services and adding support for new(ish) services.

I also want to move Checks closer to their Service-oriented Auditor. For example, moving ELBv2-specific checks within Shodan and Shield Advanced into the ELBv2 Auditor and moving more EC2-adjacent checks into the EC2 family such as AMIs and EBS volumes. A few Auditors need a complete rewrite such as IAM, Trusted Advisor, Global Accelerator, CodeBuild, and RDS.

Improved Controls Mapping & expansion

This is a two-fold change I plan on making. Firstly, to increase transparency I will be "reconfirming" mapping of NIST CSF controls (and maybe doing CSF 2.0 if it's ready by then). CSF controls are incredibly high-level versus specific benchmarks such as CIS or even CIS Controls, hell, it's even more high-level than some controls or objectives within the HIPAA "Security Rule" or GDPR Articles. CSF is great in that NIST supports mapping to a lot of popular frameworks and standards and CIS maps in reverse from it (as does AICPA, the "SOC2 people").

From there, I will "right-size" the mapping into subsequent frameworks and mapping to CIS Crticial Controls v8 and then jump across other frameworks from there.

I feel CIS has a great mapping methodology and they even qualify their mapping as a "subset" or "superset" and err on the side of "under-mapping". This will allow me to venture into frameworks I do not have much exposure too such as financial & banking-specific frameworks and OCONUS standards such as the UK NCSC Cyber Essentials, Australian Government standards, and others.

Secondly, I need to create an engine to support this mapping "just-in-time". The AWS Security Hub Finding Format (ASFF) only supports up to 32 values within the Python list (well, JSON array) in Compliance.RelatedRequirements which is why I stopped at the ElectricEye "core four" of NIST CSF (v1.1), NIST SP 800-53 (Rev.4), ISO 27001:2013/2017 Annex A and AICPA's 2017/2020 Trust Service Criteria.

In practice, Security Hub outputs will only ever have the "core four", but all other ElectricEye outputs will have the newer frameworks.

I would like to get to a dozen additional frameworks, not counting bumping 800-53 to Rev. 5 and CSF to v2.0 whenever that is ready. Will add some "Generics" such as CSA's CCM, other NIST SP's, some US Federal, some other countries, and cloud-specific CIS Benchmarks, and whatever else I can get working. I end up parsing a lot of these frameworks & mappings by hand, not even GPT-4 is reliable in this.

CIS has both their explorer and formal whitepapers & Excel spreadsheets, while NIST also offers a few native mappings, and other control framework authors provide forward-mapping between versions such as ISO 27001:2013/2017 to :2022 and PCI-DSS v3.x to v4.0 so I should at least be able to rely on their judgments instead of my own "just trust me, bro!" mapping to NIST CSF, which kinda sorta shouldn't be mapped against.

Add Support for Azure & other SaaS

Azure is a major gap, I did Oracle ahead of it as a joke, and ended up enjoying it a bit too much. Other enterprise SaaS such as Workday ERP, Salesforce, Hubspot CRM, and then a proper GitHub App are on the roadmap.

Azure I intend to use Enterprise Applications for and to get to the same 20-30 service benchmark for a "v1". I personally despise Azure, their bad documentation, but I will make do. It's popular for a reason.

The SSPM checks are usually not broadly encompassing, as there is all sorts of subscription and SKU compatibility, but I will use M365 as my model going forward to hopefully delineating exact permissions and license/SKU/subscription tiers.

There is more to do, but for now, I don't want to over-promise as I have in the past.

All for now, I'll see you in the community.

Stay Dangerous.