Sonrai Adds Ability to Determine Vulnerability Blast Radius
Sonrai Security today announced it has expanded its cloud security platform to include the ability to determine the potential blast radius of a vulnerability.
The Sonrai Dig platform uses a graph engine to discover and analyze dependencies and enable IT teams to determine their overall security posture in the cloud.
Sonrai Security CEO Brendan Hannigan said the platform is being extended to make it possible to drill down into vulnerabilities after they are discovered without deploying agent software. The goal is to make it easier for IT and security teams to prioritize remediation efforts based on the potential blast radius of a vulnerability, he said.
The Sonrai Dig platform also makes it easier to identify vulnerabilities involving personally identifiable information (PII) that might result in fines being levied, noted Hannigan.
The addition of this capability extends the scope of the Sonrai Dig platform into the realm of cloud workload protection platforms (CWPP), adds Hannigan. Previously, Sonrai Dig focused on cloud infrastructure entitlements management (CIEM), cloud security posture management (CSPM) and data security. Collectively, the Sonrai Dig platform makes it possible to use a graph to dynamically track inventory, activity, identities, data and now workloads, he said.
That’s crucial because, with the rise of microservices-based applications and infrastructure-as-code (IaC) tools, cloud infrastructure is much more ephemeral than a traditional on-premises IT environment, added Hannigan. A graph-based tool can help with tracking changes to those environments as developers update and deploy new application workloads, he noted.
In general, Hannigan said as IT organizations look to embrace a zero-trust approach to managing IT, they will especially need more visibility into cloud computing environments. The challenge security teams face is it’s often difficult to assess risk when integrated cloud services permissions become extended. Permissions granted to one microservice can be extended to other services in ways a cybersecurity team never intended. That’s troubling because cybercriminals are becoming more adept at exploiting dependencies with each passing day. Unfortunately, because most of the services are provisioned by developers, misconfigurations have become a major cybersecurity issue when, for example, ports to cloud databases or storage services have been left open.
In theory, organizations are embracing DevSecOps best practices to shift more responsibility for application security left toward developers. The challenge organizations encounter is that it takes time and commitment on the part of developers that are typically more focused on writing code than they are on becoming cybersecurity experts. As a result, much of the responsibility for securing cloud computing environments still lies with a team of security experts.
Security teams, however, tend to view the cloud as an amorphous blob rather than a set of distinct services that can be managed and secured, said Hannigan.
It’s difficult to measure the degree to which cloud computing environments are insecure. Cloud service providers require organizations to embrace a shared responsibility model that, essentially, makes the entity deploying software on a cloud platform responsible for securing it. The cloud service provider is only responsible for ensuring the security of the underlying infrastructure. Of those two tasks, it’s arguable the former is much more difficult to achieve than the latter.
