SaaS applications have become synonymous with modern business environments, and CISOs and security teams are struggling to find a happy medium between ensuring the security of their SaaS portfolio and powering productivity and streamlined business workflows for the organization.
In recent conversations with leading CISOs in the global market, including Frank Kim, member and former CSO of the SANS Institute; Sounil Yu, CSO of JupiterOne; Ray Espinoza, Vice President of Cloud Security at Medallia; Leon Ravenna, CISO of KAR Global; Alex Manea, CISO at Georgian and Tim Fitzgerald, CISO at Arm, took a deep dive into the CISO perspective on SaaS challenges, security pitfalls, practical tips for successful SaaS management, and avoiding the dreaded “death by 1000 applications”.
When SaaS multiplies
The endless game of cat and mouse between security teams and SaaS adoption is both frustrating and worrying. When faced with ever-increasing scale, CISOs are often left in the dark, unable to track, manage, and account for expansion. As Alex Manea puts it, “The reality is that each of these SaaS apps can be quite secure and cause a relatively minimal amount of risk, but when you start looking at dozens or even hundreds of apps across the environment, you start to get a larger scope. completely new risk.
Manea describes the risk as “death per 1,000 outages, or death per 1,000 apps, as the case may be,” and this is amplified by the speed at which these apps are being adopted. “The reality is that the CISO can’t really keep up with the variety and value that SaaS applications bring,” says Sounil Yu. “These outside companies deliver value at a speed that meets the business need. This is not a problem that can be solved, but a situation that we have to manage.”
Managing this expansion with manual processes is futile as CISOs have to guess which applications are potentially dangerous and which are protected. As Tim Fitzgerald says: “Even if we manage it one day, literally the next day there are 15 more apps that weren’t there the day before.”
Multiply the growing number of apps by the number of employees using them and then by the amount of customer and organizational data they have, and this risk grows dramatically. As data proliferates out of the organization and into SaaS applications, CISOs have limited insight into where it is, where it is going, and who has it.
“What scares me the most is idle or zombie SaaS,” says Leon Ravenna. “Employees adopted an app because it provided value at the time, and after a month they moved on, but the app remains in the organization with the same privileges. Only once the application is breached do security teams struggle to understand and assess what organizational data was stored on it.”
To stay ahead of such security pitfalls, I was interested in what parameters companies should consider when approving an app or banning its use.
A common practice is the use of vendors or risk assessment protocols that seek to establish a baseline of risk as a guide for decision making. This usually comes in the form of a robust questionnaire, which Frank Kim calls “a long, cumbersome, ridiculous set of questions.”
Inevitably, SaaS applications must be viewed as external risks that require enhanced protection. When considering which applications to approve, CISOs should treat them as they do internal security, using a holistic approach to bridge gaps and ensure applications are evaluated against all relevant parameters. “CISOs need to look at data security, governance, identity management, logging, supply chain, threat management, and application endpoint management,” says Alex Manea. “The SaaS applications that we deploy across the organization need to support single sign-on Y MFA. If they don’t, then these are not good for us.”
In addition to these parameters, Tim Fitzgerald suggests that enterprise CISOs consider two more general criteria before granting application access and privileges. “These companies need to be able to show some proof of their security mechanisms. It is not enough to be able to say what policies you have in place, but above all, we need to make sure that your business objectives and the risk tolerance you may have as a company roughly match ours.”
Alex Manea offers practical advice to assess these factors, as well as to establish the appropriate use cases and their applicability to the organization. “We have different tiers of applications depending on the internal use case: whether they are deployed across the organization, whether they need access to sensitive internal data, whether they need access to our financial or human resources systems.” However, it is important to note that these use cases may change over time. An app may start with simple permissions and may not require access to sensitive data, so it won’t alert security teams. If a change occurs, the SaaS provider could have greatly expanded their reach in the organization without the CISO’s knowledge.
As organizations scale, CISOs are presented with a new challenge: revoking privileges and removing applications when employees leave the workplace. Sounil Yu categorically states that “failing to remove users is the strongest indication of a poorly performing security function.” Few scalable controls are available to ensure delinking takes place and orphan accounts are prevented, leaving CISOs with fallible and manual processes. As Tim Fitzgerald describes, “When we’re looking to unbind services that we don’t control or aren’t aware of, it’s a very messy process. We rely on the personal responsibility of employees who leave the company, and this is not foolproof.”
Tips for CISOs to avoid SaaS security breaches
CISOs I spoke with described these pitfalls in organizational SaaS security programs as loopholes that, in hindsight, security teams should have avoided. By sharing their own experiences, they provide security professionals with invaluable and practical insights.
“GDPR it was a real catalyst for us to locate and identify our applications and data,” says Ray Espinoza. “One of the biggest lessons we learned was knowing where your data flows and what your SaaS applications integrate with.” Once security teams have a general understanding of what their SaaS portfolio looks like, Sounil Yu suggests that security controls for onboarding new applications should be applied in direct context to the size and stage of the organization. “The right time to switch from a free-for-all policy to a more controlled approach is an important decision. Putting tight controls on SaaS security can be a hindrance to growth for a young startup when core teams are being built and applications are onboarded with each new team. As the company stabilizes and the CISO has a good understanding of the SaaS portfolio, only then should they start to tighten restrictions.”
Keeping up with the scale and magnitude of business needs is a key part of maintaining the CISO’s role as a team player and facilitator of innovation. Tim Fitzgerald advises security teams to focus on being business partners rather than obstacles. “Fighting the tide by trying to control what employees can wear is pointless. It’s a fight CISOs will inevitably lose, and it will make security teams look anti-business and anti-innovative in the process. CISOs need robust and agile policies that build trust and make the verification process faster and easier, allowing the business to thrive.”
These processes, along with state-of-the-art security tools, should help CISOs ensure that access controls and data governance processes are in place, no matter where employees are located or what applications they use. CISOs should not have to police the organization, but instead use tools that ensure they are automatically engaged and ahead of the game. Using cumbersome point solutions that can discover only a fraction of organizational applications or monitor connections that only originate from the corporate network will only help empower the CISO and secure the organization. Cost-effective, comprehensive zero-touch SaaS coverage and governance should be critical components of CISOs’ control over their organization’s SaaS expansion.