Auto-Remediation in SaaS Security: Why SSPM Clients Frequently Prefer Guided Remediation

Written by James Alston, Senior Solutions Engineer, AppOmni.

In the ongoing struggle to relieve Security teams of tedious manual work while still providing exceptional protection, auto-remediation has emerged as a frequently-discussed topic related to SSPM solutions. And its potential is certainly appealing.

Advocates of auto-remediation point out that it allows Security teams to remediate risks without manual effort across enterprise SaaS and DevOps. In principle, it does.

Auto-remediation typically triggers a workflow when a specific event occurs, such as when a configuration change falls out of the proper corporate controls, or a certain threshold is hit. Auto-remediation enables security teams to resolve an issue almost immediately rather than creating an alert or ticket for an engineer to investigate and remediate.

For example, imagine SSO becomes disabled. An alert or ticket is created and routed to the Network team. Someone writes code that reenables the connection. With auto-remediation, the instant SSO goes down in the same manner, that code will be deployed automatically. Manual remediation work and the likelihood of an SSO service interruption essentially disappear.

But auto-remediation workflows can lead to consequences that overshadow the original problem.

Good Intentions Thwarted By Lack of Communication and Collaboration

What if the SSO outage mentioned above was planned, such as to allow the Network team to perform system maintenance? They attempt to disable SSO again, and almost immediately it’s back online. The network engineers can’t pinpoint how to stop this auto-remediation “fix” quickly enough, and they’re forced to postpone the work until they can perform a root cause analysis.

While many Security orgs have comprehensive change management procedures and automation in place, these are typically defined and tweaked over a long period of time. The rush to auto-remediate often overlooks these essentials. And a Security or dev team that creates well-intentioned auto-remediation typically generates more issues than it solves. At AppOmni, we’ve seen hypotheticals like this play out all too often.

After all, enterprise Security teams may oversee thousands of apps. While mid-size clients likely manage far fewer apps, they have correspondingly fewer resources with which to do so. In either business setting, Security teams rarely have the bandwidth to understand the configurations and security architecture of every app.

Auto-remediation workflows built in a void, without consultation and collaboration from the appropriate Centers of Excellence (CoE) and larger IT org, can wreak havoc. Many Security teams interested in auto-remediation experience a Groundhog’s Day loop of:

• Implementing an auto-remediation workflow,
• Experiencing unintended consequences that business users or your SSPM solution log tickets for,
• Rectifying the issue and “fixing” the original auto-remediation workflow,
• Creating new unintended consequences that affected users or SSPM log tickets for …

This vicious cycle is one of the key reasons we see clients abandon auto-remediation, or postpone its implementation for the foreseeable future, and revert back to guided remediation (also called assistive remediation). Well-documented procedures and policies make little difference when business users remain unaware of them.

The extra work and user frustration, however, aren’t the only reasons SSPM auto-remediation isn’t widely adopted.

Auto-Remediation May Violate Authorization Best Practices

Like most SaaS security vendors, we stress least privileged access across all SaaS apps and the SDLC stack. The vast majority of our clients embrace this best practice and typically request that AppOmni leverage least privileged access for our continuous monitoring.

Auto-remediation requires granting a security vendor read/write access — and often requires full system admin access if certain SaaS vendors do not accommodate a lower-tier read/write role. This conflicts with least privileged principles to provide continued SaaS security monitoring, and adds unnecessary risk and blindspots to the remediation process vs. sending findings and remediation steps to an existing change management flow where approval processes, escalation processes, change management processes and reporting + tracking is already built-into the process.

If your organization has established change management procedures and automation in place, we recommend guided remediation over auto-remediation. For example, your SOAR platform can be granted the needed permissions to perform change activities, eliminating the need to overextend admin access.

This approach allows SSPM solutions to:

• Run with least privileged access for continuous monitoring,
• Send findings to the existing workflow (e.g., your SOAR), and
• Enable your SOAR or other similar solution to perform changes.

Beyond adhering to least privileged access guidelines, your existing platform will often provide central tracking, visibility, and auditing for any change activities performed. In contrast, relying on auto-remediation usually means reviewing and collating distributed audit logs and change management activities.

From a workflow perspective, routing SSPM findings into the existing SOAR’s (or similar platform’s) approval and escalation flows — instead of creating auto-remediation workflows — avoids duplicating efforts, and leverages the existing central approval process flows, escalation flows, reporting and track-ability options.

Is Auto-Remediation Ever Recommended?

Auto-remediation can have its place, particularly in the CSPM world. When it comes to SaaS and SSPM, we’ve also seen it used successfully when development teams focus on continually implementing, monitoring, and improving code. The cases that we’ve found work best for auto-remediation in SaaS environments:

• Reveal an extremely low likelihood for variables,
• Have undergone thorough analysis, conversations, and tests with all involved internal parties and vendors, and
• Occur in sandbox and/or developer environments.

A workflow that passes these requirements may be a candidate for SSPM auto-remediation. Like all process changes, a successful pilot starts with open and inclusive communication.

Remediation Process Steps to Take Now — And to Consider for the Future

A 2022 Forrester Trend Report focusing on SSPM* suggested that “...initially you should stay away from [auto-remediation] as it may cause conflicts in the policy management process. Instead, building on the rapport you built with SaaS app owners, notify them of misconfigurations with a description of the implications of these misconfigurations.”

We agree. We’ve found that most companies are interested in auto-remediation in theory, but ultimately decide not to use it on a day to day basis once they consider the effort required and potential consequences if it’s not implemented properly.

Instead of leaping to auto-remediation, build on the fundamentals: relationship-building and ongoing communication with CoEs and your IT counterparts, coupled with guided remediation from your SSPM vendor. Create a cohesive team that shares not only information but also responsibility.

Empower your SSPM solution — with, of course, least privileged access — to monitor your SaaS apps and SDLC stack. You’ll soon discover existing misconfigurations your team can share with the CoEs and IT to discuss risks and remediation recommendations.

Ask your SSPM vendor what threat intelligence capabilities their team can provide. Ideally, you’ll be able to combine automated monitoring with guidance from their Security professionals, whose sole directive is continuously surveying the security landscape. This approach will result in better risk reduction results, and far fewer operational headaches, than relying primarily on auto-remediation.

*Available to Forrester subscribers or for purchase