.

Are we heading for a security diSaaSter?

By Eva Nahari, Principal, DNX Ventures

Industry analysts predict the SaaS market will grow by 20% YoY, and reach an estimate of $200B by 2024. At the same time the pandemic has accelerated digitalization by years. Companies are at a rapid pace offloading any non-core business to SaaS to achieve efficiency to meet increasingly higher pressure demands.

What does the SaaS migration mean from a security perspective? If you offload part of your business workflow to SaaS vendors, that part of your business will now be hosted in the cloud and protected by the SaaS vendor.

Let’s take out of the equation the regular security checks and compliance procedures to get the check boxes squared away in the SaaS vendors’ product sheets. If we look beyond that, there are some interesting challenges presenting themselves – all of which need attention or innovation, fast.

  • SaaS is built on cloud infra – is the cloud infra involved reliable and secure? Has the SaaS vendor stitched together the complex djungle of cloud services in a secure way? The cloud ecosystem is rapidly evolving. Will the SaaS vendor keep up? What happens if there is a regional failure? Is the SaaS vendor service set up properly in case of disaster?
  • SaaS is often built on modern microservices architecture – this means more risk with more individually moving parts and more surface areas vulnerable for attack. What many organizations miss, though, is to not only consider each microservice’s security but how they are secure together – component security means nothing if they don’t work in harmony together.
  • SaaS software is often built with a continuous delivery model – with faster pace comes higher risk for mistakes as well as process complexity, i.e. it becomes harder and harder to gain exact visibility at any point in time
  • SaaS now contains lots of your data. Do you really have good visibility into how data is being governed? Are you sure your sensitive data is not leaking?
  • SaaS is more and more accessed by remote workers. Do you know they are truly who they say they are? Are they accessing services securely and in the prescribed ways?

The biggest challenge for SaaS is that infosec or IT has been forced to take a back seat, as business demands have pushed organizations to move to SaaS and move to continuous delivery to stay competitive, perhaps even before they are fully ready.

Recently I talked to an infosec team leader at a large, well-known SaaS company (who, by the way, claims they are a continuous delivery organization although their release process is three weeks). The infosec lead is just one of many examples, who could not answer with certainty what software is deployed where, without further investigation. He could not immediately tell or show what scans were actually completed for what features and what set of features were in each release. If he was asked where released code actually originated from, his team was completely dependent on developers and other people to get answers – and their availability. Often leading to weeks in incident resolution and root cause detection time.

Which leads to a fourth point, in addition to the ones listed above: the modernization of incident management. Organizations can no longer afford the risks and costs involved in depending on stale and people-heavy (and error prone!) processes. There needs to be a fast and executable plan and system in place for when incidents happen, not if they happen. We know they will happen. Mitigation and handling processes will need to get to the same pace as the release cycles.

But the lack of visibility, the slow digression towards no control, the still people-heavy and undefined incident resolution processes: it is a tsunami of risk waiting to happen. I think the message on a C-level is a beautiful utopia of “autonomous CI/CD”, “continuous security”, and “continuous delivery”, but the reality on the street is that organizations are struggling desperately to get there – and in the interim there are big security risks lurking in and around the corners.

The movement of DevSecOps is not happening fast enough. We will need more innovation and more investment in this space. We need to strive to preempt incidents and detect bad code or dependency decisions at the time of decision making. We need security awareness and checks earlier in the development process. We need the visibility and security control back in the hands of infosecwithout restricting the agility and flexibility of developers that are needed to meet the demanding continuous delivery goals. This is especially important in SaaS environments. In an ideal world, an engineer should know at the time of code check-in that this is a security vulnerability, or a bad dependency. This is in reality impossible, as many security vulnerabilities are dynamic and an artifact of a runtime, thus impossible to detect statistically.  Yet, it should not be an infosec team member’s responsibility, after the fact, and after the software has been shipped. Infosec should instead be responsible for the incident management policies and efficiencies and the visibility into impact at any point in time. The responsibility should instead move to someone at runtime able to detect system or code failures, and should be able to instantly flag the developers and apply a patch to a running system. This new place of responsibility is tools, automation, and roles in the emerging DevSecOps. Security is now a matter of the CI/CD pipeline.

Study shows 69% of developers make non-optimal choices when it comes to updating software dependencies. Imagine the non-optimal choices made with regards to security. Think about this and act towards a change – set infosec at the table again, and not in the back seat, but do it through technology and advisory that fuels workflows instead of blocking them. IT and infosec control should not be opposed to engineering freedom, but should instead encourage faster flow and better quality throughout the developer process, while still making it easier to preempt risks and meet security KPIs and SLAs.

Eva Nahari is a Principal at DNX Ventures with a 20+ years operational experience (e.g. Cloudera, Oracle, BEA Systems). DNX Ventures has invested in companies like Mitiga, Squadcast, SOC Prime, Safebreach, and Netrise to fuel better pathways for when incidents happen and solutions for the growing enterprise security needs ahead with the growing dependency on SaaS. Feel free to contact DNX if you want to learn more.

 

Hot Topics

Related Articles