Aug 23, 2022
Aug 23, 2022
6 min
The core principles for protecting SaaS throughout its lifecycle are fundamentally about security architecture—discovery, justification, sanctioning, securing, and decommissioning are all implicated by security architecture. As SaaS moves through its lifecycle, security architects have an outsized impact on the fate of their organization’s SaaS defense.
Time and again we find regular challenges with SaaS security—access control and protection, avoid data loss, identify SaaS risks, monitor the SaaS security posture, safely connect users to their technologies without compromising security or compliance. These are real challenges from real life.
Generally, security teams rely on a patchwork of technologies, processes, and people to mitigate risks of SaaS; technologies such as CASB, SSE, SWG, IdP/SSO; processes such as justification and attribution, and many aspects of third-party risk management (for SaaS); people such as security and risk teams, compliance auditors, finance, marketing, customer support, sales, and every other business group now sourcing their own SaaS—business-led SaaS that is expected to be 85% of the SaaS estate by 2030.
And yet, with all this solutioning, 60-70% of the SaaS attack surface remains unguarded. Users still leverage duplicate passwords (109 per user on average), and the untamed herd of SaaS risk continues to outpace our ability to domesticate it.
Let’s start at the beginning, while keeping the end in mind. SaaS has a lifecycle whether you secure it or not.
The core principles for protecting SaaS throughout its lifecycle are fundamentally about security architecture—discovery, justification, sanctioning, securing, and decommissioning are all implicated by security architecture. As SaaS moves through its lifecycle, security architects have an outsized impact on the fate of their organization’s SaaS defense.
Here, we suggest 3 principles of the SaaS security lifecycle, concluding with a call to reimagine security architecture.
Enable secure SaaS lifecycle for every app, orchestrated and adaptable for SaaS today and SaaS yet to be deployed. To start this process, we must first discover what the SaaS attack surface really is. What does it consist of? What attributes can be classified, organized, and prioritized for mitigation? What remedial technologies or processes are functioning? How does that change my risks and my priorities? When did this SaaS first appear? When did this SaaS get abandoned? Why didn’t we know about it? Who has overly permissive or dangling access?
These are excellent questions. And the questions have answers that comes from SaaS visibility.
First, discover all SaaS, past and present. By discovering all SaaS varieties—core-IT and business-led SaaS—you can identify which apps are being used, especially SaaS apps accessed without users touching the corporate network. The challenge is to get the signal for user-SaaS relationships without another agent, proxy, infrastructure, or event dependency.
Users don’t traverse my network to get to most of their SaaS, that leaves agents, proxies, and the like toothless. And when it comes to events, you could be waiting for a long time before events signal a user-SaaS relationship—and you would never know about SaaS used in the past, no longer used in the present, and loaded with dangling access for future exploit.
Second, prioritize what matters to you. Factful and relevant risks depend on many factors, most of which are inaccessible to most security teams—high-fidelity attributes of our SaaS attack surface. Thankfully, you have done the discovery phase and now you can prioritize reality-based SaaS risks. To prioritize what really matters, you need to understand the inherent risk of SaaS, pinpoint real-world use, misuse, and abuse—enumerated and classified, validate mitigations such as controls and remedial policies, and finally arrive at a SaaS risk index tuned to you.
This makes it clear, that to adapt to the real-world SaaS attack surface, we need to know where we have been, where we are now, and where we should go in the future. These are questions well-suited for an architectural shift toward a unified SaaS security control plane to identify, prioritize, and protect all SaaS varieties.
But how to we get the security we want to SaaS we don’t directly control or manage…or even know about? That brings us to the second principle to secure the SaaS lifecycle.
Users are the one factor common to all SaaS, resulting this real world where identities are the new enforcement point—so use it. Infuse security policies and control to identities, transforming users into security carriers to SaaS, resulting in universal secure access.
According to Microsoft, “As you enable employees to work from virtually anywhere and from any device of their choice, your organizational access perimeters and boundaries change. Your new security controls need to adapt to this dynamic environment and be able to quickly respond to the constantly evolving threat landscape.”
Sure—environments and controls change, but boundaries don’t even exist anymore and the one constant is identity. This means, we must treat identities as the only available enforcement point. Period. Once the internet became the new network, identities necessarily became the new enforcement point. If we believe the first part, we must conclude the second is also true.
a) if the internet is the new network, all entities and enforcements in flux (e.g., chaos)
b) identities are constants, usually human, that interact with the internet to derive meaning and value
So, why would you use anything else to carry your security into the chaos?
Access protection for today. While organizations like Microsoft will have you invest in a patchwork of bloated tools (security controls), there is an inherent incompleteness and insufficiency in the entire project—it doesn’t treat identities as the real-world enforcement point. If you want on-demand secure protection, it must be there when the user is—right now, and back in the past and ready for anything that comes in the moment. The only vessel available to carry security in such a moment is the identity.
Past and future access security. History doesn’t repeat, but it rhymes. And there’s a lot to be learned from looking into the past and seeing how your SaaS attack surface evolved through time. Starting with identities enables you to go back in time and identify the layers of SaaS fingerprints from a full history of user-SaaS relationships, resulting in intelligent security policies pegged to the user and the real-life way each organization consumes SaaS.
Without an identity-based approach—treating user-SaaS relationships as the only available enforcement point—we will take shortcuts; technical shortcuts that cling to rusted infrastructure models (CASB/SWG), hypothetical SaaS inventories (IdP/SSO), and nostalgia to put the corporate network into the internet (SASE/SSE). While some of these solutions can bridge us to the world that’s coming, a mindset anchored in security architecture will see the folly in persisting any SaaS security technology unless identity is the enforcement point.
Identities (user-SaaS relationships) are the only factors that persists through the SaaS security lifecycle—we must recognize it as the only real enforcement point.
We need an architectural paradigm shift that drives security outcomes, not ownership, and that is tuned for business-led SaaS. By the year 2030, 85% of what we call ‘SaaS’ will be business-led SaaS—characterized by business groups identifying and acquiring SaaS technology outside IT budgets, procurement, support, or security. This trend to enable the ‘bring your own app’ culture is becoming pervasive.
Gartner estimates over 70% of organizations consider business-led IT valuable to them. Yet, when we look at exceptionally clever threats like those preceding Mailchimp CEO Ben Chestnut’s prompt resignation to see that the systemic risk of SaaS-on-SaaS-on-SaaS demands an architectural rethinking.
In the 2011 film, Moneyball, Peter Brand (played by Jonah Hill) explains the outcomes principle to Billy Beane (played by Brad Pitt): “Your goal should not be to buy players, your goal should be to buy wins. And to buy wins, you need to buy runs.”
Now, take the logic of Moneyball and apply it to SaaS security—your goal should not be to ‘own’ the SaaS, your goal should be to protect it. And to protect it you need to facilitate and authenticate a secure outcome. We can dispense with ‘owning’ every entity of the SaaS attack surface. The business will own the apps, users, content, and code—security can facilitate and validate a secure outcome based on real-world observations and identity-centric enforcement.
An architectural shift is necessary to drop old habits and embrace reality as it is. A reality-based SaaS security strategy begins and ends with security architecture, informed by and in service to the SaaS security lifecycle. The SaaS security lifecycle consists of 6 stages, consistent with the SaaS lifecycle generally:
The Grip SaaS Security Control Plane is an essential element to modern security architecture—resolving the accidents of SaaS in the past, mitigating present risk across the SaaS estate, and infusing your users to take security with them to SaaS that hasn’t even been invented yet. Get the data sheet to learn more.
See Grip Live on LinkedIn - SaaS Security for Modern Work
Request a consultation and receive more information about how you can gain visibility to shadow IT and control access to these apps.
Fill out the form and we’ll send you our Datasheet.
Give us a test drive.
Fill out the form and we’ll get in touch with you.
Fill out the form and watch webinar's video.
