Democratizing SaaS Security Remediation

To fully embrace digital transformation at scale, enterprises are democratizing IT to empower business users across organizations to select, deploy and manage best of breed SaaS applications and their third-party integrations directly. As we all know, this paradigm shift unlocks innovation opportunities by enabling business users to independently adopt new solutions and integrations quickly, addressing their business technology needs at maximum velocity.

The flip side of this, is that when many of the decisions are made outside of the central IT department, in most cases they also lack the required security and governance. Therefore, security teams are left without critical business context to contextualize and assess the risks associated with their SaaS mesh. How can a security engineer or SOC analyst understand why a marketing team needs a new Salesforce extension, or why the engineering team added a new GitHub App? Employees and business stakeholders must be involved in the process in order to gain comprehensive understanding of the business context. Security controls and procedures must adapt to this new modus operandi and democratize their SaaS risk mitigation processes.

The reality is that security teams have largely struggled with communicating security requirements to the entire organization. Often, they are perceived to operate like a secretive “Big Brother” that demands that all IT decisions be channeled through them, with little transparency into why the security vetting and deployment of new SaaS applications and third-party integrations takes so long or why it is critically important. And, on top of this, it often appears to the end user that security teams view business needs as a low priority, and rank security concerns as more important. This provided only a minor inconvenience in the days of a limited number of organization-wide on-prem applications, where IT was required for configurations. But with IT decentralization, this is no longer the case when business users adopt hundreds and even thousands of SaaS applications and third-party integrations.

The end user’s perspective is that the security team performs time-consuming reviews of their chosen SaaS apps, with little or no regard for their immediate business needs. The end user is satisfied by their SaaS vendor’s inherent security mechanisms, which do not necessitate additional IT reviews, making it seemingly simple and safe to deploy it. What the vendor fails to tell them - and security teams may fail to communicate - is that the shared responsibility model stipulates that the vendor is responsible only for the security of their infrastructure, not for its usage. That responsibility lies with  the end user, and ultimately their organization. The sad truth is that end users, naive as they are when it comes to security, almost universally over-privilege third-party integrations, thereby unnecessarily increasing the potential blast radius of any supply chain breach, regardless of the inherent security of the connected SaaS applications.

To make matters worse, end users will often deploy multiple third-party applications and/or integrations during a PoC evaluation, and fail to offboard those that were not selected at the end of the evaluation. This, in addition to failed offboard of terminated or inactive third-party vendors, can leave organizations with hundreds of abandoned integrations that sit unused and exposed, increasing the organization’s SaaS attack surface.

Democratizing SaaS security remediation workflows is increasingly necessary for modern business needs, and security teams must find ways to adapt - not obstruct - such progress. This must be the product of communication between users and security teams which requires trust. Security leaders must strive for their users to trust their judgment and intent, so that they feel their business needs are being considered and will not need to bypass security reviews. Security teams must also enable the end user to remain empowered to adopt and review SaaS apps and integrations, while voluntarily allowing security policies into the process. Finally, security teams can benefit from educating the end users in a collaborative way, in order for them to fully understand and appreciate the importance of security in their daily tasks. 

Valence was built from the ground-up with these three pillars in mind. Instead of evaluating new SaaS integrations and offboarding existing ones from a purely security standpoint without end-user input on business need, security teams can use Valence to automate the process of eliciting application business owner feedback and empower them to either approve business critical applications or offboard unused or non-critical ones themselves. Over time, this trains end users to proactively consider the security implications when evaluating and adopting SaaS applications. 

The democratization of SaaS security remediation workflows is an important complement of IT democratization. It means engaging with end users and SaaS application business owners to include them in the mitigation process so that they are actively engaged with the security team as they remediate SaaS security risks, and are consulted by the security team when offboarding high risk, over privileged, or unused integrations. 

Over time, this also educates the entire business organization on the principles of SaaS security hygiene, clearly establishing  that they can be implemented without disrupting business productivity. Ultimately this enables users, not security teams,to become the first line of defense against SaaS supply chain attacks and other abuses of high-risk third-party integrations.

‍