Retour 
Co-authored by James Robinson and Vadon Willis
Every functioning security team has an incident response plan. Advance strategizing and preparation are absolutely imperative to ensure a quick response to data breaches, ransomware, and numerous other challenges, but most companies first developed that plan years, if not decades, ago and now only revisit it periodically. This is a problem.
How many organizations have developed a separate incident response plan to address the unique risks of the software-as-a-service (SaaS) era? Far too few.
Think about it: A corporate security team’s response to a breach of a SaaS solution managed by a third party is, necessarily, far different from their response to an attack on the corporate network, data center, or endpoints. That’s not just because the security team has less control over the SaaS environment, but it’s also because they have less information that would crucially help to inform the response. Effective attack response requires a series of steps: identification, containment, and eradication of the threat; recovery; and learning lessons from the experience. But identifying, containing, and eradicating requires deep access and visibility into the software system and its log files.
Now, consider each of the SaaS applications that your company relies on. How much visibility do you truly have into those systems? And, with that in mind, what would an incident investigation look like if that SaaS application experienced a breach?
If you don’t know, it’s time for that to change.
SaaS Triage
Here’s a story based on a series of events we’re aware really did happen in security. Let’s say Company A had a solid incident response plan built on years of experience with on-premises investigations and forensic analysis, but frankly, they had not given enough thought to the ways in which that plan would need to change should they have a problem with a SaaS application.
Then, an employee made public a recording of a meeting that included some highly confidential proprietary information. His intent wasn’t malicious. In an effort to be helpful and make the information available to new employees, he placed the recording in a repository on the cloud-based videoconferencing application where the meeting took place. Thankfully an alert colleague noticed this mistake and notified the security team.
What Company A learned first is that they did not have access to their logs with this conferencing provider. They didn’t even have much information about their security settings. Fortunately, when they reached out, their sales contact at the vendor was very responsive to their concerns and got the right people involved right away. They quickly discovered that the recording was unsecured—that anyone in the world with the correct URL could access it–and they did not even have permission to change the security settings.
This was a crisis that initially left everyone on the security team feeling powerless. They had no visibility into whether anyone had taken advantage of the situation, so they had no idea what the ramifications might be, or what mitigation should look like. It was difficult to accept that they had been blind to this particular SaaS risk.
Nevertheless, once they identified the scope of the problem, they worked closely with the conferencing vendor on two fronts: They had the vendor immediately change the settings to make the problematic video private, and requested access to all the relevant logs. They investigated downloads of the video and viewings within the conferencing platform, correlating the SaaS logs with their internal logs to determine which actions involved people outside of Company. A.
The result was a relief: There had been no access that they could verify as coming from outside their corporate network. They were lucky: That cat used one of its nine lives and kept going. They learned from this experience and changed their policy—and their settings in every communications platform they use—to prevent videos from being publicly shareable.
Due Diligence & Incident Response
This situation drives home the fact that security incidents can happen on SaaS platforms and that if we don’t prepare in advance, there may not be much we can do. As a result, here’s an informal list of SaaS security best practices we developed here at Netskope. They are as follows:
1. Evaluate security from the start. A security review should be a core component of due diligence in every SaaS application selection decision. As a company reviews prospective providers, the security team should ask what logging capabilities are available, who has access to log files, and what the incident response process is, in case something goes wrong.
Many SaaS providers are starting to move into the security space, viewing support for customers’ security teams as an upsell. It drives me crazy, but it’s commonplace. The vendor’s standard SaaS offering is opaque and customers that want access to logs have to pay more. Obviously, in this environment, vendor risk management needs to happen before the contract is signed. Once the business has selected a SaaS solution at a specific price, the security team will face an uphill battle to add logging capabilities at an increased cost.
2. Don’t forget the software supply chain. The vendor risk management review should also include close investigation of the SaaS software supply chain. This reminds me of another situation where an organziation, let’s call them Company B, had an established, trusted relationship with a vendor and shifted to its SaaS solution with limited due diligence. They didn’t realize their mistake until a different, fourth-party software provider experienced a ransomware attack.
The SaaS solution was built on top of a platform from another vendor, which was neither cloud-native nor designed to support cloud systems. When the platform fell victim to a ransomware attack, they discovered not only that Company B had no visibility into the incident, but that