SaaS Security

Many SaaS companies are initially focused on shortening their time to revenue—which often leaves information security on the back burner. Even when security is finally addressed, it’s usually on an as-needed/emergency basis rather than strategically. Sound familiar?

As a SaaS provider, your clients want to know their data is safe with you. Gaining that upfront trust with prospects can be the competitive advantage you need to close more deals.

Over the years, Pivot Point Security has worked with 100+ SaaS firms to help them define and achieve their information security objectives. Here are answers to some common questions we hear from SaaS firms, based on what we’ve learned:

How should a SaaS business approach information security?

SaaS firms should fundamentally aspire to move security “left”—meaning bake security into the development lifecycle as early on as possible. How this looks will depend on your development methodology. But pushing security as far left as you can is proven to be a very effective and efficient way to build, deploy and improve secure applications.

As an example, if you subscribe to an agile development methodology, you would have security integrated into each one of your stories that is part of an agile sprint. Verifying security would be integrated into your pipeline and iterative processes; e.g., in the form of automated code scanning as part of each iteration.

It’s also key that your developers have the necessary security training and awareness. A practical option is to align your development methodology with an open, trusted framework or guidance, such as OWASP provides.

To make developers aware of basic security issues, we recommend the OWASP Top 10 as a good starting point. Beyond that, the OWASP Application Security Verification Standard (ASVS) offers much more rigorous and proactive development and testing guidance. The problem that OWASP intends the ASVS to solve is a lack of process maturity in web application testing. As a standard for testing web apps, it offers three levels so you can align your requirements with your application’s risk profile.

A final key recommendation is to get some level of independent, third-party assessment and attestation of your success on a periodic basis. This gives customers, investors, regulators and management peace of mind, and also ensures that you are where you think you are. Both these outcomes are business-critical given that trust is everything to growing a SaaS.

What makes SaaS information security unique?

One unique aspect of SaaS security is that the software you need to secure is also your product, and security concerns are the biggest impediment to using your product or investing in your company. This situation argues for attaining the best third-party security attestation achievable; e.g., an ISO 27001 certificate or a SOC 2 Type 2 report.

Ideally, this attestation would also be accompanied by an OWASP ASVS Level 1 or Level 2 assessment to make it mean even more. In fact, it often makes sense to focus first on the security of your SaaS application before wrapping security controls and processes (like an ISO 27001 ISMS) around that.

Another unique aspect of SaaS security is that every SaaS firm, by definition, processes client data. If that data includes personal information (PI), personal health information (PHI), high business impact data, etc., your business is at significantly greater risk for a high-impact cybersecurity event—which means you need to set your security bar that much higher.

A further reason SaaS firms need to elevate their security is that customers exert greater pressure on you to iterate your solution, perhaps as often as once daily or even multiple times per day. This inherently drives a need for greater formality in ensuring that security processes are robust and followed unfailingly.

How can I assess the security of my SaaS?

How you assess the security of your SaaS application and associated infrastructure is a central factor in how prospective customers and investors view the desirability of doing business with you. Being able to meet security demands and prove compliance is likewise central to your ability to scale your business and drive growth.

Well known and widely respected forms of third-party security attestation like an OWASP ASVS assessment, a CREST-aligned penetration test or an ISO 27001 certificate (especially with an ISO 27701 privacy extension if you handle PI) are all strong forms of assurance that build trust.

Trust is the lubricant that reduce time to revenue by accelerating SaaS business deals, including both client contracts and venture funding.

Which security attestation is right for my SaaS?

Trust can make or break a SaaS provider. With security still the top barrier to SaaS adoption, does your security posture make prospects confident they can trust you with their data?

If yes, you have a major competitive advantage. If no, your business is (potentially) in peril.

A great way to inspire trust is to demonstrate you’ve earned it. How better than to attain a widely respected, independent security attestation from an accredited third-party?

But which InfoSec attestation should you choose? That can be a tough question, especially if you’re hearing different compliance demands from different regulators, clients and other stakeholders.

Based on our experience supporting 100+ SaaS providers across diverse industries, here are our top picks, in order:

  1. ISO 27001—The international “gold standard” for information security across industries, earning (and keeping) an ISO 27001 certificate requires a formal audit with annual surveillance audits. Because it focuses on the management system more than the specific controls it is often considered the strongest and most comprehensive single form of independent security attestation for a SaaS.
  2. SOC 2 Type 2—For SaaS firms operating primarily in the US, a SOC 2 Type 2 report is an excellent attestation option that gives your stakeholders comprehensive assurance regarding your security posture in the form of a detailed report that can include “trust principles” for Privacy, Availability, Confidentiality and/or Processing Integrity in addition to security.
  3. OWASP ASVS—Especially for SaaS startups, it can make more sense to focus initial security efforts on your web application and worry about your infrastructure later. In this regard, the OWASP ASVS gives you an open, standardized, comprehensive and tunable framework for testing, hardening and verifying your web application security. OWASP doesn’t offer formal attestation or certification against the ASVS. But it does define a range of “levels” and coverage areas to fit any SaaS use case. Further, you can still leverage an independent entity like Pivot Point Security to document your “conformance” to your ASVS scope.
  4. CSA STAR—Launched by the Cloud Security Alliance in 2013, the CSA STAR attestation program focuses on “key principles of transparency, rigorous auditing, and harmonization of standards.” It offers three levels of assurance: self-assessment, independent audit and “continuous auditing” (still under development). The intent of CSA STAR is to extend the ISO 27001 controls with prescriptive guidance for cloud environments.

For more details on deciding between ISO 27001, SOC 2 or both, click here to view our e-guide.

What is the Shared Responsibility Model for SaaS?

A shared responsibility model is simply an acknowledgement that in any cloud deployment scenario each party logically has certain security and compliance obligations.

Leading cloud service providers (CSPs) like Amazon and Microsoft have done an excellent job explaining how security “of” the cloud relates to security “in” the cloud. Most simplistically, CSPs are responsibility for security of the cloud infrastructure, while end customers are responsible for securing the data they store in the cloud.

In the case of a SaaS, which relies on the CSP’s services but must secure its own solution, there is a three-way “shared responsibility triangle” between your end customers, your cloud service provider (CSP) (assuming you outsource hosting) and your SaaS.

In brief:

  • Your CSP is responsible for securing the cloud infrastructure that your service/solution runs on, including virtual operating systems, virtualization/container layers and physical/facility security.
  • Your customers are responsible for protecting their data, securing their configurations and maintaining identity and access controls to manage their users and endpoint devices to prevent unauthorized access.
  • You are responsible for securing your SaaS platform, application instances, “internal” networks and associated virtual and physical infrastructure, and your own data. How you configure and use a CSP’s built-in security tools (e.g., web application firewalls, encryption) is also ultimately your responsibility.

In a shared responsibility model, responsibility and control are two sides of the same coin. Where control is abstracted away, so is accountability. Where you the SaaS provider are accountable, you have power and control to create a robust security posture.

From this viewpoint, the shared responsibility model is not a liability but an opportunity—to differentiate your business from competitors, give your stakeholders peace of mind, and ensure you can effectively block threats, remediate issues and minimize the impact of attacks to protect your brand reputation and business viability.

What are the top SaaS security risks?

SaaS companies store a lot of customer data, which makes them prime cybercrime targets. Add to that an emphasis on time to revenue over data protection, and it’s easy to see why your SaaS faces significant security risks.

Here are some of the top concerns for a growing SaaS:

  • Failure to enforce least privilege access to data. The lack of an enforceable strategy for least privilege access usually results in users having access to more data than they need (aka “privilege creep”). This becomes a problem when insiders “go rogue” or outsiders compromise privileged credentials. If customer data or instances are involved, it becomes a very big problem, indeed. Configuring security groups to restrict nonessential access to systems, applications and data stores is the straightforward solution to this issue.
  • Failure to use multi-factor authentication (MFA). Relying on passwords puts your data at risk, even if you enforce a strong password policy. Implementing MFA ensures that passwords, which are so easy to pirate or brute-force, aren’t your only defense against account takeovers.
  • Failure to patch vulnerabilities. Patching is foundational to cybersecurity, but a robust patching program can be elusive for startups and growing companies. For a SaaS, leaving your systems (including virtual and containerized environments) open to hacks against known vulnerabilities is the kiss of death. The only recourse is to prioritize a patching program, ideally in combination with segregation of systems and networks to limit breach damage.
  • Failure to address flaws in your SaaS offering. If you don’t proactively integrate security awareness and testing into the earliest phases of your software development lifecycle (SDLC), you’re left to reactively uncover security flaws within the working application. Worse yet, your testing may be limited or ad hoc. Application security testing services like penetration testing or verification against the OWASP ASVS are critical first steps to reducing SaaS risk.
  • Failure to educate your customers. Encouraging customers implement MFA to reduce the threat of account takeovers is central to their secure use of their service. Likewise, part of holding up your end of the shared responsibility model is keeping customers informed about their security responsibilities, as well as yours. Why worry about your customers’ data security if it’s their responsibility? Because 95%+ of cloud security breaches are caused by misconfigurations and other customer missteps—and these breaches can impact your brand image even though they’re not “your fault.”
  • Failure to spell out or uphold security responsibilities in your contracts. If you have weak or nonexistent security policies, and/or lack third-party attestations to demonstrate a strong security posture, your contracts may end up reactively promising different things to different customers; e.g., how to handle breach notification or who is responsible for what security controls/risks. This can put you at significant risk if you’re not able to track contract compliance. Having confidence in your security and maintaining consistency in your agreements/SLAs as much as possible is the goal.

How can I assess the security of my SaaS?

How you assess the security of your SaaS application and associated infrastructure is a central factor in how prospective customers and investors view the desirability of doing business with you. Being able to meet security demands and prove compliance is likewise central to your ability to scale your business and drive growth.

Well known and widely respected forms of third-party security attestation like an OWASP ASVS assessment, a CREST-aligned penetration test or an ISO 27001 certificate (especially with an ISO 27701 privacy extension if you handle PI) are all strong forms of assurance that build trust.

Trust is the lubricant that reduce time to revenue by accelerating SaaS business deals, including both client contracts and venture funding.

How can I optimize the security of my SaaS offering?

To align your security priorities with business needs, here are some questions to ask:

  • What do each of my key stakeholders want/need?
    • Customers/prospects – What kind of assurance do they want so they will choose you over your competition?
    • Senior management – Are they just looking to be confident your application is secure? Or do they need to demonstrate a mature security posture to secure funding or sell the company?
    • Partners – What kind of assurance do they want so they will keep doing business with you?
  • What security certifications or attestations do you need to have? [More on that here]
  • Which of your products/solutions/platforms does your attestation need to address (i.e., what is “in scope”)?
  • Should you initially focus solely on securing your cloud environment? Or should on-premises solutions also be considered “in scope”?
  • Is your development environment mature enough to be in scope? Or should you focus on your production environment at first and expand the scope later?
  • Do you understand and can you live up to your obligations according to a shared responsibility model?
  • Do you need a top-tier, independent cybersecurity assessment like one based on the OWASP ASVS or SOC 2?

Pivot Point Security has deep expertise in the SaaS vertical. We have worked with 100+ SaaS firms, many of which are ISO 27001 certified. We understand your technology stack (AWS, Azure, G Suite, Confluence, Jira, Github, Docker, Kubernetes, Rapid7, etc.)

Are you new to security frameworks and attestations? Not a problem! We can draw from our experience to ask the right questions, determine an efficient scope, navigate your current maturity level, and ultimately shorten your time to certification—and time to revenue!