Enterprise companies in today’s world have hundreds of applications sitting inside of a public cloud such as AWS. Each of these applications exists in multiple environments such as sandboxes, development, staging/pre-production, and production. As you can imagine, each stage of development for each application requires a different focus for processing and presenting security-related issues. It can get rapidly complex and it’s all about focus.
In a dev environment, the focus is on IOC detection, weak integration with CI/CD pipelines, excessive permissions for non-people identities (servers, VMs, serverless, etc.), and network exposure. Inside production workloads, the risk of sensitive data exposure and compliance violations now becomes the focus. In sandbox accounts, the focus is on making sure the company isn’t embarrassed by a simple configuration mistake.
Presently, this separation of environments presents a unique challenge. Environments are defined with a combination of tags, resources, and accounts. IR, SOC, and CloudOps teams end up with hundreds of alerts that are not appropriate for the environments monitored causing complaints of too many false positives by the teams responsible and overall alert fatigue. Sonrai’s public cloud security platform organizes all analyses, alerts, and actions for environments into “swimlanes” and directs relevant issues to the proper owners or creates an automated process responsible for remediating the issue.
The platform's swimlanes give each environment uniqueness and importance with a single pane of glass with a visual representation of cloud security posture and overall risk. This means policy configuration issues in a development CI/CD pipeline are reported to workload owners and not security teams to be addressed before infrastructure and code is promoted to production. Our Security Center further breaks down alerts by Control Framework allowing easy separation by issues such as incidents, over-privileged identities, network misconfiguration, encryption lifecycle, and data exposure issues. This allows teams responsible for a particular swimlane to prioritize alerts. It also allows a top-level view of all workloads to evaluate if they have unique or systematic issues that exist across all workloads in the organization.
Breaches can happen due to escalation patterns across many different environments. It is difficult to correlate this activity and pinpoint who or what may have been affected. In cloud, audit data is not stored in a single location and Sonrai Security acquires it through many different locations across many different services (CloudTrail APIs, CloudWatch Events, Application access logs, and audit from 3rd Party sources such as Hashicorp Vault.) Blast radius of a compromised identity in AWS is particularly complicated to understand as there is no single place to find all resources a single identity has access to.
Sonrai’s centralized collection along with a flexible query model are useful tools for these investigations. The platform centralizes configuration and activity from across all cloud accounts and secondary audits representing multiple workloads into a single pane of glass. The quick search feature allows for impacted resources to be investigated from any deployment while relationship queries allow finding any identity (including non-people identities) that changed the configuration of another identity or resource as is commonly discovered in incident investigation. The model also allows for the chaining of queries to discover how far compromises have gone in terms of all identities that have been affected.
As cloud platforms continually change and researchers find new privileged escalations and weaknesses in cloud configuration, it is hard for CloudOps teams to keep up with all the latest issues.
Organizations building applications in AWS will quickly discover how complex identity and data access models are when extending to resource policies like S3 bucket or KMS policies, region restrictions, resource or management groups. And, more importantly, how a poor identity and access management (IAM) configuration will expose corporate data to breach by an external actor or an over permissioned insider. Sonrai Security’s Crown Jewel Monitor helps organizations unravel the complexity in public cloud IAM architectures, helping to eliminate weak or accidental configurations that if left unchecked, will inevitably lead to a data breach.
Central to Crown Jewel Monitor is a unique capability – the Sonrai Security IAM/data graph model. Behind the scenes, the Sonrai platform is collecting IAM related data from a broad range of sources (e.g. APIs, logs, cloud analytics). This information is compiled into a normalized graph data model that can quickly surface complex IAM and data relationships across an entire public cloud deployment. Unlike many tools that only show singular IAM relationships (e.g. role with an EC2FullAccess or owner of a subscription), the Sonrai platform can connect the dots and show all relationships in a single picture.
Sonrai's Crown Jewel Monitor baselines IAM and trust relationships directly to resources like data stores to detect changes in permissions previously baselined or accepted by the appropriate team members (e.g. cloud security architecture team). Alerts notify of deviations from the accepted baseline, flagging any changes that might introduce risk or that could be used maliciously that the security team may be unaware. The Sonrai graph allows for quick investigating of the changes. More importantly, Crown Jewel Monitor than maps the real activity from audit data to baseline behavior of identities and their access patterns to a resource that could indicate an attack.
No one solution solves security in public cloud. Modern applications use 3rd party software components that extend the functionality of AWS platforms. These components are not monitored by the cloud provider’s APIs, making it complicated to understand the full set of permissions an identity has and what data is possibly exposed by those permissions.
Sonrai Security continuous monitoring and normalized query language apply to 3rd party sources such as DataBricks and Hashicorp Vault. This allows monitoring for data exposure risk based on a secret stored in these services which gives access to sensitive data.
AWS security tools also provide exceptional value in the way of indicator and threat detection. Sonrai's integration with Amazon GuardDuty collects and analyzes the entire library of findings reported by GuardDuty. When a GuardDuty finding is received by Sonrai Security, the entire finding, as reported by AWS, is saved as “metadata” attached to the corresponding resource node in the Sonrai platform. Additionally, new findings will be alerted by the Sonrai platform across all connected accounts in a multi-account AWS deployment and placed into swimlanes and correlated with all other findings for that application and stage of development sending them to the correct team.
Security teams and architecture oversight often slow down the modern development cycle. We learned years ago fixing the vulnerabilities in code before deploying it was cheaper and more effective than fixing them in production we need to learn this lesson in new public cloud deployments as well. Code is now your infrastructure, IAM, data and application security.
While outside the scope of this report, we believe everything should be automated. To enable this, the Sonrai platform enables everything from provisioning, configuration, alerting, and remediation via APIs to remove as few humans from the process as possible.
Continuing on that theme, who wants to look at yet another console? Today, teams have their own set of tools, workflows, etc. Sonrai integrates into those solutions like PagerDuty using native AWS functionality (like SNS and Lambda) to support their incident response processes.