Regulatory standards for cybersecurity and data privacy are continuing to evolve in response to feedback, industry consultation, and the rapid adoption of cloud services and remote work. Across standards, these updates reflect a broader shift towards a decentralized modern environment. This emphasizes the need for organizations to adapt their IT and security strategies to protect their SaaS estate against potential attacks and maintain the integrity and privacy of SaaS data.
The updated requirements in IT infrastructure v3.1 by NCSC Cyber Essentials introduce significant changes to strengthen security controls for SaaS and cloud assets. The UK government-backed Cyber Essentials scheme, overseen by the National Cyber Security Centre (NCSC), aims to provide organizations with a framework to secure their IT infrastructure against common cyber threats. Specific to cloud assets and SaaS, NCSC requires that the SaaS vendor:
- protects your data in transit between clients and the service, as well as within the service
- protects user accounts with modern authentication, and authorization policies
- provides logging and auditing, to maintain user experience and flexibility for the majority of responsible users (this approach is preferable to prevention and control, which some users may try to work around)
To answer some of these questions, organizations are required to know how SaaS vendors are processing their data at rest and in transit.
Even in the United States, there is an increasing drumbeat of regulation focusing on cloud assets and specifically, SaaS. Whether it is the National Cybersecurity Strategy, which calls for, in some sectors, “new authorities” to set regulations that can drive better cybersecurity practices at scale, Gramm-Leach-Bliley Act (GLBA) updates, or new state privacy laws, there are lots of new requirements coming down the pike. Here are three examples:
- The New York Department of Financial Services (NYDFS) has proposed rules that update its cybersecurity regulations. The influential agency wants to mandate, for example, role-based account controls (RBAC) to limit user access privileges. This has big implications for the administration of SaaS applications because admins will need to know what access users have and when to deactivate access when users leave or get a new role.
- The U.S. Federal Trade Commission’s (FTC) Safeguards Rule, like increasing numbers of compliance regulations, mandates the use of multi-factor authentication (MFA) “for any individual accessing any information system.” Again, big implications for SaaS apps because a policy isn’t enough. You have to know where the policy is and is not enforced, which could be tricky if you have branch locations internationally. The latest version of the rule gives covered organizations until June 9, 2023 to comply with the rules.
- Enforcement of the California Privacy Rights Act (CPRA) begins this summer and expands on consumer protections. Firms that do business in California that achieved $25 million in revenue the prior calendar year or processes data of more than 100,000 customers may be covered. One unique aspect is that CPRA gives employee data similar protections as customer data. If that data is stored in Workday or Salesforce, for example, it needs to be protected. Four more states will have new or expanded privacy laws enacted by the end of this year.
Keeping track of regulations and what changes can mean from a SaaS deployment and configuration standpoint can be challenging for IT and security teams. The reality is that most organizations have SaaS apps that don’t operate in standalone islands but are inherently interconnected with each other which makes the problem of adhering to regulations even more difficult. Each SaaS application has its own unique set of rules and regulations when it comes to managing integrations, which can create significant difficulties when trying to ensure compliance and security across all integrations.
Organizations in regulated industries must be agile in the face of regulatory chaos and surging SaaS threats. Adapting SaaS security strategies for this new era requires the adoption of automation, embracing collaboration to include more stakeholders in the regulatory compliance process, and continuously advancing the strength of controls and policies—all the while dealing with economic and competitive pressures. It is no easy task.
How automation aids security and compliance
SaaS Security Posture Management (SSPM) tools address this issue by continuously monitoring user behavior, configuration, and privileges out of the box without the need for proxy management and complex deployments.
SSPM can help organizations implement and manage robust identity and access management (IAM) policies across their SaaS applications. This includes enforcing multi-factor authentication (MFA), single sign-on (SSO), and the principle of least privilege access. By providing granular visibility into user permissions and access levels, SSPM tools like Obsidian enable organizations to identify and remediate excessive privileges, ensuring compliance with modern authentication and authorization best practices.
But for any automated system to work, the core components that need to come together are visibility and the ability to programmatically take corrective action when certain conditions are met. In the world of SaaS security, missing either of these elements can result in blindness to systemic vulnerabilities and an incomplete understanding of residual risk.
Obsidian solves this problem by continuously monitoring a SaaS application’s configuration, the integrations between them, activity, and the ability to enforce technical measures to detect, prevent, and automatically respond. Obsidian’s Posture Management for instance leverages real-time data to perform continuous risk assessments that automatically inform customers of their risk exposure. Settings Management and Posture Rule features provide the ability to define and automatically enforce an appropriate risk tolerance across the SaaS environment.
Validate Once, Comply with Many
One of the most beneficial features that organizations can expect from the Obsidian Platform is its ability to automate the validation of any technical control and prove compliance across all mapped frameworks. For example, let’s say an organization has implemented an Enterprise Password Policy which requires all privileged users to have 16-character passwords. This poses three questions that need to be answered:
- How are Privileged Users defined?
- What SaaS settings can be configured to enforce this requirement?
- Once established, how will it be monitored and reported?
With Obsidian, GRC teams can address each of these questions at scale. First, they can create a rule that helps them define what SaaS application permissions constitute as a “privileged user” that looks something like this:
IF “User Permissions” = Role 1 + Role 2 THEN User = “Privileged User”
Once that step is completed, GRC teams can then leverage Settings Management to surface the password setting for a SaaS application. After the setting has been selected, an additional Posture Rule can be created which looks like this:
IF User = “Privileged User” THEN ‘Password Strength’ MUST = 16
With those two steps completed, the GRC team has defined what they consider to be a privileged user and enforced a policy requirement for any user that meets that definition. There is one additional step GRC teams can take to really achieve a ‘validate once, comply with many’ approach. That is to then take that same Custom Rule that was created and by using Obsidian’s built-in compliance mapping feature, they can seamlessly search across frameworks for any control that mentions passwords or privileged user access. Once the compliance framework controls have surfaced, they can be easily mapped to the Custom Posture Rule that was created. The end result is a single Posture Rule that if it’s in a “Passing” state, that means each compliance control that is associated with it is now in a “Compliant” state.
GRC teams iterate on that same process to define and apply Custom Posture Rules to any and all enterprise policy or regulatory framework requirements and achieve peace of mind that if any of those settings revert to a “non-compliant” state, security and GRC teams will be immediately notified and a ServiceNow or Jira ticket will be created to automatically document the issue.
Give it a try!
As of today, customers can get access to frameworks that support NIST 800-53, ISO 27001, and CCM. This means that if you are an organization that needs to stay compliant with any of these regulations, you can map requirements across these regulations to technical SaaS controls and know immediately how compliant you are. We are also actively working on supporting other regulatory frameworks such as HIPAA, CIS, PCI DSS, SOX, NYDFS, and more over the coming months.
We are also offering a no-cost risk assessment to help teams better understand the risks present in their environment. A member of our team will provide you with a snapshot of powerful security insights that include:
- Your SaaS security posture score with insights into user privileges and application configurations, providing actionable steps you can take to minimize risk
- Compliance mapping to complex industry and regulatory standards including SOC 2, NIST 800-53, ISO 27001, CSA Cloud Controls Matrix (CCM), and more
- Surfaced risk exposure introduced by SaaS integrations to your core applications including insights into permissions and different levels of access, integration activity, and areas of excessive risk
You can learn more about this risk assessment and apply for it here.