The Cloud Risk Encyclopedia is a free and public resource featuring over 1,200 cloud security risks. DevOps teams can use the Encyclopedia as a resource to supplement security checklists. As an example, in this blog we show you how to create an AWS S3 bucket production checklist by referencing cloud risks from the Encyclopedia. If you are interested in learning more, there is a link at the end of this article to register for an upcoming webinar that will expand on this topic.
New Cloud Risk Encyclopedia Q2 2022 Update
This week, Orca Security published a new update to the Cloud Risk Encyclopedia, a public resource featuring cloud security risks and remediation strategies pulled directly from Orca’s cloud security platform. This new update now covers 1,280 cloud risks – including 300+ new risk entries since its original launch in early 2022.
Orca also added five new featured risk pages that include detailed information on each risk, related risks, examples of attacks that exploited the risk, as well as recommended mitigation strategies:
- Neglected Assets – Host OS Reaching End of Support
- Data at Risk – Azure Storage Container is Publicly Accessible
- Data at Risk – Potentially Personal Identifying Information found – Email Addresses
- Authentication – Users with Console Access Do Not Have MFA Enabled
- Authentication – SSH Authentication with Username and Password
In light of this update, the Orca Research Pod asked me to write a blog post about how DevOps engineers can take advantage of the Cloud Risk Encyclopedia to help simplify their tasks and improve security operations. I am Director of DevOps at Orca Security and have previously filled management and engineering DevOps roles at several organizations.
What Is the Cloud Risk Encyclopedia?
For those not familiar with the Cloud Risk Encyclopedia, it is a collection of commonly found cloud security risks along with remediation strategies pulled directly from the Orca Cloud Security Platform.
Users can search or filter on risks based on cloud platform, risk category, compliance framework, and risk score. For trending risks, the encyclopedia includes more detailed descriptions, related risks, examples of related incidents, and preventive strategies.
One of the ways I think the Cloud Risk Encyclopedia can be a great DevOps resource is by using it to build or enhance production checklists to help avoid common cloud misconfigurations and security loopholes.
Preventing Cloud Misconfigurations With Production Checklists
When it comes to cloud security, all too often, data breaches occur due to simple misconfigurations or human error.
Gartner predicts that through 2025, more than 99% of cloud breaches will be traced back to preventable misconfigurations or mistakes by end users.
Some examples of how misconfigurations can come back to haunt you include recent breaches in the news: researchers recently found that 1200 Unsecured ElasticSearch Databases had been held to ransom. PegasusEFB’s open AWS S3 bucket left data in more than 23M files accessible to anyone, while also exposing EFB software’s source code.
By maintaining checklists on commonly used cloud assets and services, such as AWS S3 Buckets, Azure blob storage, ElasticSearch and MongoDB, many cloud configuration issues can be prevented.
DevOps can use checklists to avoid damaging data breaches and ensure that security operations run smoothly.
Creating DevOps Checklists With the Cloud Risk Encyclopedia
While DevOps teams are often not directly responsible for security controls, their main goal is to ensure that all infrastructure and resources are up and running in production.
Cloud security risks—particularly those stemming from misconfigurations—can interfere with that objective.
The Cloud Risk Encyclopedia can complement the use of for instance AWS CIS, Azure CIS and GCP CIS benchmarks since it consolidates many CIS benchmarks, compliance frameworks – including NIST Cyber Security Framework (CSF), CSA Cloud Controls Matrix (CCM) and SOC 2 – and Orca Security best practices in one resource.
In total, the Encyclopedia includes risks from 29 compliance frameworks and CIS benchmarks across the 3 major cloud platforms.
In addition, the Encyclopedia allows teams to find all risks related to a certain resource and use these to build or enhance DevOps checklists. For instance, by searching on ‘S3 Bucket’, you will find all risks associated with S3 Buckets, using information from multiple sources.
Example: Creating an S3 Bucket DevOps Checklist
Let’s use deploying an AWS S3 bucket as an example of how the Cloud Risk Encyclopedia can be useful.
When deploying S3 buckets, DevOps teams need to pay attention to permissive storage policies, unencrypted cloud storage (at rest), storage open to the public, and misconfigured access control lists.
Compiling information from various sources, the following list could be used as a DevOps S3 Bucket configuration checklist:
When creating an S3 Bucket, make sure that:
- Bucket policies do not use non-existent, blocked, or deleted IAM users
- Bucket policies with IAM users from other accounts have proper access rules
- S3 bucket is private or is public only by intention (i.e.not made public by mistake)
- S3 file objects could be set to public or private, depending on intended level of access
- S3 storage is encrypted at rest
- S3 bucket enforces the use of TLS version 1.2 and above
- Any KMS keys used for bucket or object encryption are designed with ‘least privilege’ in mind
While DevOps teams can and should utilize information from AWS CloudTrail logs, bucket policies and AWS Key Management Service (AWS KMS), they could also compare notes and customize their checklist with some of the related risks and alerts in the Cloud Risk Encyclopedia to avoid S3 bucket misconfigurations in their unique cloud environments.
Just doing a search for ‘S3’ in the Encyclopedia yields the following risks:
Logging and Monitoring:
- S3 Bucket Access Logging is Disabled
- S3 Bucket Object-Level Logging for Write Events is Disabled
- S3 Bucket Object-Level Logging for Read Events is Disabled
- S3 Bucket Server Access Logging is Disabled
- CloudWatch Alarms Not Monitoring S3 buckets Configuration
- Metric and Alarm Do Not Exist For S3 Configuration Changes
- Data Protection – S3 Glacier vault with public access
- Data Protection – Unencrypted S3 Bucket
- Data Protection – Internet Facing EC2 Instance with Broad S3 Access
- Data Protection – Bucket Allows Unencrypted Uploads
- Data Protection – S3 Bucket Should Enforce HTTPS
- Data Protection – Glue data in S3 not encrypted
- Data Protection – S3 Bucket Used to Store CloudTrail Logs is Publicly Accessible
- Data Protection – EMR Cluster At Rest S3 Encryption Disabled
- Data Protection – S3 bucket data is not protected (not using S3 object lock)
- Data Protection – AWS S3 Bucket Without “”MFA Delete”” Enabled
- Data Protection – S3 bucket lifecycle rule is not defined
- Data Protection – S3 Bucket Object Versioning Not Turned On
Data at Risk:
- Data At Risk – S3 Bucket Allows Public LIST
- Data At Risk – S3 Bucket Allows Public PUT
- Data At Risk – AWS S3 bucket has global view ACL permissions enabled
- Data At Risk – S3 Bucket Allows Public FULL_CONTROL Access
- Data At Risk – S3 Bucket Allows Authenticated READ_ACP Access
- Data At Risk – S3 Bucket Allows Authenticated FULL_CONTROL Access
- Data At Risk – S3 Bucket Policy allows cross account access
- Data At Risk – S3 Bucket Allows Authenticated READ Access
- Data At Risk – S3 Bucket Allows Public DELETE
- Data At Risk – S3 Bucket Allows Authenticated READ Access
- Data At Risk – S3 Bucket Allows Public READ Access
- Data At Risk – S3 Bucket Allows Authenticated WRITE_ACP Access
- Data at Risk – S3 Bucket Allows Public WRITE_ACP Access
- Data at Risk – S3 Bucket Allows Public READ_ACP Access
- Data At Risk – S3 Bucket is Accessible to Unmonitored Accounts
- Data At Risk – S3 Bucket Policy allows cross account access via AWS service
- Data At Risk – S3 Bucket Policy allows unknown cross account access
- Data At Risk – S3 Bucket Allows Authenticated WRITE Access
- Data At Risk – S3 Bucket Allows Public Access via Bucket Policies
- Data At Risk – S3 Bucket Allows Public WRITE Access
- Data At Risk – S3 Bucket Allows Public GET
Orca Best Practices:
- Best Practices – AWS S3 bucket is not using DNS-compliant bucket name
- Best Practices – S3 Bucket Should Use Transfer Acceleration
- Authentication – AWS S3 Bucket Allow Access to Any AWS Authenticated User
- IAM Misconfigurations – Internet-Facing Ec2 Instance Has Full Access to S3
- Vendor Services Misconfigurations – S3 Bucket not Configured with Public Access Block
In addition to our ‘S3’ search in the Encyclopedia, it is also important to include risks related to ‘KMS keys’ in the S3 Bucket checklist. The Encyclopedia includes information on over 30 such risks, including:
- Data Protection – An KMS Key with Public Access Policy
- Data Protection – IAM Inline Policies Allow Decryption on all KMS Keys
- Data at Risk – AWS KMS Master Key Cross-Account Access
- Data at Risk – KMS CMK is Exposed
Webinar: How DevOps Can Leverage the Cloud Risk Encyclopedia
Want to understand more about how DevOps can benefit from the information in the Cloud Risk Encyclopedia?
Join me – Liran Lavi, Director of DevOps – and my colleagues, Bar Kaduri, Cloud Threat Researcher and Jason Silberman, Senior Product Marketing Manager at Orca Security for our Webinar ‘DevOps Teams: Why the Cloud Risk Encyclopedia Should Be Your New Best Friend’ on July 13th, 2022.
We’ll be demonstrating how DevOps engineers can leverage the Cloud Risk Encyclopedia to enhance production checklists, reduce attack surfaces, and prevent data breaches.
About the Orca Cloud Security Platform
By deploying Orca, teams can be automatically alerted to these misconfigurations as well as many other risks, including malware, vulnerabilities, lateral movement risk, sensitive data at risk, and IAM risk.
With Orca’s Shift Left Security capabilities, DevOps teams can also scan Infrastructure as Code (IaC) templates and container images to detect risks before they are deployed into production.
Orca’s platform is completely agentless, eliminating the gaps in coverage, alert fatigue, and operational costs of agent-based solutions.