Hypothetical Scenario – One of your primary accounting team members is no longer employed by your organization. Do you know what financial software-as-a-service (SaaS) applications they were using? Do you know if that user accessed any SaaS applications using credentials that were separate from their primary identity, which was disabled during offboarding? Could this terminated individual still have access to your financial systems and data?
This scenario isn’t specific to any one organization, department, or individual. SaaS applications are being widely adopted by most organizations which makes governance and security increasingly difficult.
SaaS Application Risks
While SaaS applications can vary drastically from a functional standpoint, they often share a number of common risks including those listed below:
- Compromised user credentials could be used to access a SaaS application from any device, anywhere in the world
- Non-Single Sign On (SSO) user accounts within SaaS applications may not be deprovisioned during employee offboarding, allowing continued access to company data after termination
- Users could access SaaS applications from personal devices and exfiltrate company data
- Sharing features of SaaS applications could be used to expose company data externally
- SaaS providers could be compromised, leading to exposure of company data
These risks are not new, and many organizations have mitigated these risks for their most critical SaaS applications. Example mitigations include single sign-on (SSO)/federated authentication, strong multi-factor authentication (MFA), device and IP restrictions, and other application-specific security settings.
Where we see organizations struggle, is doing this at scale and protecting all of their SaaS applications.
Securing SaaS at Scale
Organizations who excel at managing and securing their SaaS applications at scale each have a program with some combination of the capabilities below:
- Inventory Management: An accurate inventory with supporting inventory management processes is the pinnacle of a SaaS Governance program, as organizations can only secure what they know exists. Building SaaS application inventory management into an existing new technology onboarding process is a great way to quickly enable this capability. Establishing a corporate policy to require all SaaS applications to be centrally procured can help encourage teams to follow these processes. However, there is always the possibility that a team onboards a SaaS application on their own, which introduces the need for a shadow IT monitoring capability, such as corporate credit card expense alerts and/or reviews and user web traffic analysis. Simply asking departments or teams to verify their SaaS applications on a regular basis is another great way to identify gaps within the inventory.
- Secure Reference Architecture: A secure reference architecture which captures baseline security requirements can help to ensure consistent protections across all SaaS applications. Before a SaaS application is procured, it should be reviewed against the reference architecture to verify that security requirements can be met. If an application that cannot meet the most critical security requirements (e.g., does not support SSO with your identity provider), consider seeking an alternative solution. Once a SaaS application is procured, the security requirements in the reference architecture should be used as a checklist during initial implementation.
- Vendor Risk Assessments: Per the cloud shared responsibility model, an organization is responsible for the secure usage of a SaaS application, but the vendor is responsible for securing the underlying infrastructure of the application. Ultimately, a lapse in security by a SaaS application vendor could lead to the exposure of your organization’s data, making third-party risk assessments especially important. SaaS vendor security controls reviews should be performed prior to procurement to verify that the vendor has adequate network security protections, access controls, and secure development policies and procedures. SaaS application vendors should be reassessed post-procurement every one to two years, prioritizing applications based on business impact analyses (i.e., critical applications and/or applications which contain sensitive organization data).
- Centralized Identity Governance: Strong identity and access management practices are critical to securing individual SaaS applications. Using an organization’s primary identity provider to federate access to SaaS applications enables management of credentials, multi-factor authentication requirements, and permissions (via groups) in a single location. This also simplifies access and entitlement review overhead. The most mature organizations may even centralize management of local SaaS application user accounts (e.g., default admin accounts) with a security operations team for separation of duties purposes.
- Regular Application Auditing: To ensure applications continue to meet security requirements, they should be reviewed on a regular basis against the SaaS security reference architecture. Drift in authentication, data protection, or logging configurations or changes to role assignments could lead to exposure of company data within the application. Without regular reviews, configuration drift can be difficult to detect. Additionally, SaaS applications receive updates and enhancements frequently, and audits can be a great opportunity to identify and implement new application security features.
Organizations who have implemented a SaaS governance program with the capabilities above can confidently answer the questions posed in the opening scenario. They will know what SaaS applications are used by the accounting team. They will have assurance that those applications are configured and managed securely. And they will be confident that the user’s access was completely terminated during offboarding.
Conclusion
Given that there is limited guidance on securing SaaS applications from a pure consumer standpoint, SRA has developed a custom framework to assist organizations with building a SaaS governance program. SRA has used this framework to help organizations prioritize process enhancements and technical controls to bolster the security of their SaaS applications. If you’d like assistance reviewing your SaaS governance capabilities, contact us here.
Megan DeWitt
Megan specializes in data engineering and analysis, cloud infrastructure management, program development, and process improvements. Megan has substantial experience in IT and Security Operations and brings with her an understanding of managing security controls in alignment with an organization’s objectives, risk tolerance, and compliance requirements.
Megan currently works within the SCALR XDR infrastructure team focusing on applying data engineering to maximize an organization’s ability to store security events, accelerate search and response, and reduce SIEM operating costs. Megan has extensive experience in the Healthcare and Accounts Receivable industries.
Megan has certifications in Microsoft Identity and Access Management Administrator and AWS Security Specialty. Prior to joining SRA, Megan graduated with a Bachelor’s of Science degree in Computer Information Systems.
Matthew McHugh
Matt focuses on the engineering and implementations of security tools including network inspection, Network Access Control (NAC), Cloud Access Security Broker (CASB), and User & Entity Behavior Analytics (UEBA) tools.
Matt has also led many advisory projects for clients including security tool evaluations, security program assessments, and roadmap development initiatives.
Matt has experience working with clients across multiple industries including healthcare, pharmaceutical, financial services, and consumer products. This broad experience allows him to tailor project approaches based on specific client and industry needs.
Matt has been a distinguished speaker at conferences across the country including H-ISAC, HIMSS, and Palo Alto Ignite. Matt has also obtained his AWS Cloud Practitioner certification.