The modern kill chain is eluding enterprises because they aren’t protecting the infrastructure of modern business: SaaS.
SaaS continues to dominate software adoption, and it accounts for the greatest share of public cloud spending. But enterprises and SMBs alike haven’t revised their security programs or adopted security tooling built for SaaS.
Security teams keep jamming on-prem pegs into SaaS security holes
The mature security controls CISOs and their teams depended on in the age of on-prem dominance have vanished. Firewalls now protect a small perimeter, visibility is limited, and even if SaaS vendors offer logs, security teams need homegrown middleware to digest them and push into their SIEM.
SaaS vendors do have well-defined security scopes for their products, but their customers must manage SaaS compliance and data governance, identity and access management (IAM), and application controls — the areas where most incidents occur. While this SaaS shared responsibility model is universal among SaaS apps, no two SaaS applications have identical security settings.
AppOmni research reports that on average, a single instance of SaaS has 256 SaaS-to-SaaS connections, many of which are no longer in use, but still have excessive permissions into core business apps such as Salesforce, Okta, and GitHub, among others.
Between the multitude of different SaaS security settings and constant updates that alter them, security teams can’t effectively monitor these connections. The number of entry points multiplies exponentially when employees enable SaaS-to-SaaS (also called “third party” or “machine”) connections. Machine identities can use API keys, secrets, sessions, digital certificates, cloud access keys, and other credentials to enable machines to communicate with one another.
As the attack surface migrated outside the network perimeter, so did the kill chain — the way in which threat actors orchestrate the various phases of their attacks.