Building A SaaS Security Program: A Quick Start Guide

Written by Bryan Solari, AppOmni

Every few years a new technology takes hold of businesses worldwide, expanding adoption at a speed that far outpaces our ability to secure it. Inevitably, the security shortfalls of this technology become known, and we build risk mitigation strategies that meld into our existing workflows. The use of SaaS applications represents a foundational shift in our use of technology and requires a new programmatic approach to ensure secure use. In this post, we’ll provide some initial steps you can take to build the cornerstones of your SaaS security program.

Define Your Inventory

A sizable portion of your security risk comes down to what you own or, in SaaS, what you license. Creating an inventory of your assets provides insight into which teams are using which SaaS applications. During this inventory phase, risk can be reduced by understanding your attack surface and removing any unnecessary SaaS applications.

This process will also help uncover ‘fourth parties’ that maintain connections to your organization through integrations within your SaaS apps. An example of a fourth party might be a bulk exfiltration tool that is downloaded from your SaaS applications’ app store and is granted access rights to your SaaS environment. Peeling back which third and fourth parties have access to your environment will ensure you have a full picture of your overarching SaaS attack surface.

Identify Who is Responsible for What (RACI)

Understanding who is responsible for which operations within your program is key.While every company is unique, SaaS security is most commonly handled as an enterprise security function. We designed a RACI chart based on the most common responsibility matrix we encounter:

Design Your Desired State

Writing down your security requirements in a set of “Best Practice” policies is important. One challenge with SaaS security is that each SaaS application presents a unique threat model - but there are some common threads. For example, many SaaS applications allow the administrator to “relax” security settings or allow external third parties to engage with internal users through portals. Addressing these common themes (investigating instance posture for configuration errors or ensuring internal/external segmentation where applicable) can be a good way to codify your SaaS security requirements. Additionally, utilizing a framework like SOC2, CIS benchmarks, or NIST 800-53 as a north star for your initial policy can be helpful.

Run A Baseline Assessment

Once you have these guardrails in writing, it’s time to put them into action by comparing your current SaaS application settings to your ideal security state. Reporting against both best practice policies and compliance standards in place at your organization can help you assess the point-in-time stance of your current security posture. Make sure you set a near-continuous scan cadence against your policies through the use of automation since SaaS environments change readily and vulnerability assessments are only valid for short periods of time. Ensure you’re evaluating your instance posture as well as data access (a.k.a. who has access to what). A complete picture of your SaaS security posture is nearly impossible to achieve without a thorough approach to both.

Define a Remediation & Triage Strategy with Peer Teams

Understanding which SaaS applications belong to which teams (see Step 1: Define Your Inventory) is important because once you’ve identified the issues, you’ll need to chat with the correct business app team to fix them. It’s inevitable that some of your most pressing security issues may exist in business-critical SaaS workflows. This can create friction with engineering teams who may not be aware that their preferred settings introduce security risks. When you face this friction, remember that the purpose of your initial SaaS security program should be to create visibility into business risk and spark a conversation between security & IT. This visibility will help leadership make an informed, risk-based decision on what to do when security best practice and IT efficiency are at odds.

Also remember that time constraints and resource prioritization prohibit perfect secure deployment. As a result, your triage team will need to act quickly to inventory all security vulnerabilities, map them to owners, and make severity-based decisions about the risk of each finding so they can fix the issues that matter most first.

Shift Left as Much as Possible to Catch Issues Pre-Production

Finally, move as much of your assurance activity into staging as possible. Automate your scans via security tooling, integrate your discovery capabilities into your SDLC, and take advantage of any pre-production QA workflows to block issues from reaching your production environment. Modern technology makes this easier than ever before. By shifting left, you’re saving your team a lot of time by eliminating the need for repetitive, wasteful triage downstream. That means you can eliminate classes of SaaS security issues prior to their instantiation into your enterprise production systems.

By following these steps, you’ll be well on your way to building a SaaS security management program. We’ll dive deeper into each of these steps in future posts on the subject as this space develops.

About the Author

Bryan Solari helps enterprise organizations at AppOmni and has been advising clients on “security at scale” for more than a decade. His experience includes consulting on, and assisting with, application and cloud security programs at more than 250 global technology companies.