Author: Shiran Rachman

What We Know 

In July 2024, The Walt Disney Company suffered a major security breach when the hacking group NullBulge infiltrated its internal communications. The attack targeted Disney’s Slack channels, leading to the leak of approximately 44 million internal messages and exposing sensitive company information. 

How Did It Happen? 

The breach was caused by a Disney employee who unknowingly downloaded an unverified AI tool from GitHub. The software contained embedded malware, which allowed hackers to infiltrate both personal and corporate environments, including: 

• Disney’s Slack channels – exposing internal conversations and sensitive data 
• The employee’s 1Password account – which contained stored credentials, including access to Disney’s internal systems, and was NOT protected by Multi-Factor Authentication  

By compromising the employee’s 1Password vault, the hackers gained access to Disney’s organization-wide credentials, further escalating the breach’s impact. 

Following the attack, Disney launched an internal investigation and terminated the employee. The company claimed inappropriate materials ware found on the work computer—a claim the employee disputes. 

Key Takeaways: Strengthening Security Against AI-based 3^rd party apps  

This breach underscores the risks associated with unmanaged AI-based 3^rd party apps and Shadow SaaS applications, reinforcing the need for proactive security measures: 

1. Implement Multi-Factor Authentication (MFA) 
MFA significantly reduces the risk of unauthorized access by requiring multiple verification steps, preventing attackers from easily exploiting compromised credentials. 

2. Restrict AI-based 3rd party Software Usage 
Unverified GitHub repositories and third-party apps can introduce malware into corporate systems. Organizations should enforce strict policies on software usage and require security approval before authorization. 

3. Automate Discovery and Response 
Security teams cannot manually monitor all applications that employees use. Automated discovery of AI-based Shadow SaaS apps and 3rd-party apps is critical to stopping security threats before they escalate.  

How Suridata could prevent such breaches  

Suridata provides comprehensive visibility into any unauthorized third-party and shadow SaaS applications, allowing security teams to detect, assess, and mitigate risks before they lead to breaches, using the following capabilities:  

Identify AI-Based Applications in Use – Suridata has the ability to recognize AI tools, helping security teams track and monitor their adoption across the organization. 

Prioritize Risky Apps – The malicious GitHub AI tool would have been immediately detected and classified as critical, triggering a security notification. 

Automated Security Actions Through Workflows – Suridata enables organizations to automate security responses through predefined and custom workflows, such as: 

• Revoking access to suspicious apps 
• Blocking installations of unverified tools 
• Requesting business justification for app usage before approval or removal 
• Continuous notifications- automatically notifies when AI-based apps are authorized or are in use 

Final Thoughts 

The Disney breach is a powerful reminder that 3^rd party apps, Shadow SaaS apps and AI applications, pose serious security threats. Companies must move beyond reactive security measures and adopt proactive solutions like Suridata to prevent data leaks before they happen. 

You might think your organization doesn’t need a data security policy. All cybersecurity countermeasures protect data, don’t they? Yes and no. Data is important enough to merit its own dedicated security policy. Without one, you are vulnerable to costly attacks, regulatory penalties, and reputation damage. A thorough data security policy helps you avoid these negative outcomes. It forms the foundation for trust, compliance, and operational security.

The cyber threat environment certainly isn’t getting any less forgiving when it comes to protecting data. Data breaches in the third quarter of 2024 exposed more than 422 million records worldwide. Regulations affecting data security are also strict—and expensive if you don’t comply.

While IBM/Ponemon research says that a data breach costs $4.88 million to remediate on average, the numbers can get a lot more frightening than that. Meta paid $1.3 billion to settle EU data privacy violations in 2023. Amazon paid $877 million in a similar settlement in 2021. And, you’re probably thinking, if companies as well run and tech-savvy as Meta and Amazon can have data security problems like that, what am I doing about it? That’s where having a data security policy comes in.

What Is a Data Security Policy?

The term “data security policy” may be a little confusing, partly because any number of security policies related to data could be called “data security policies,” e.g., always encrypting data at rest. When an organization has a data security policy, sometimes called a data protection policy, it’s referring to a set of policies, practices, and controls that collectively have the goal of protecting the organization’s data from breach and other types of damage, such as ransomware.

A data security policy is often broad in scope, covering how data is handled, who is responsible for various data sets, and who can access them. These issues are more relevant than ever now that cloud computing and software-as-a-service (SaaS) have become so commonplace. Data security policy overlaps with data governance, which is about ensuring data availability, security, and quality. Data security policy also embodies the many controls and steps required to protect data and maintain regulatory compliance. 

Why Does Your Organization Need a Data Security Policy?

Do you need a data security policy? Yes, and for several compelling reasons. The biggest driver of need is the confluence of rising data volumes, the distribution of data across multiple cloud platforms, and serious cyber threats and compliance requirements. These four forces combine to make it effectively non-negotiable that your organization have a coherent and thorough data security policy.

Of these issues, the proliferation of cloud and SaaS platforms is arguably the most serious challenge to data security. Employees now routinely store documents containing sensitive data on cloud volumes like Google Drive, often with open sharing settings. Notable SaaS data breaches include a 2023 hack of the Microsoft cloud that affected US government agencies.

The average business now has over 100 SaaS apps running, each of which can contain sensitive data—without anyone quite knowing where it all is. And, that’s not even considering the problem of “shadow SaaS,” which occurs when employees set up SaaS instances on their own without informing the IT department or security team.

All these factors add up to substantial data risk exposure. The stakes are certainly high. Data breaches are expensive to handle. They can trigger legal and regulatory problems that are costly to resolve, with fines for GDPR violations, for example, reaching into the millions. They disrupt business operations and potentially damage brands.

Done right, a data security policy goes a great distance to mitigating these risks and bolstering your overall security posture and compliance, including:

• Strengthening trust with customers and partners
  
• Facilitating proactive threat mitigation
  
• Strengthening the security of the SaaS ecosystem
  
• Aligning business operations with regulatory frameworks
  
• Reducing exposure from shadow IT and shadow SaaS
  
• Optimizing data governance and ownership
  
• Enables advanced incident containment strategies
  
• Supporting vendor risk assessments and monitoring
  
• Establishing a resilient compliance posture

7 Must-Haves for Every Data Security Policy

A sound data security policy comes to life through a collection of activities, workloads, and processes. It’s a good news/bad news situation. The good news is that many elements of a good policy already exist in your organization. For instance, you already have access controls. The bad, or at least challenging news is that you must align these elements, which may originate in multiple departments, with the data security policy, e.g., do your access controls support the objectives of the data security policy? With that in mind, here are seven “must haves” for every data security policy.

#1 – Comprehensive Data Inventory

A data security policy must be rooted in a comprehensive data inventory, which asks two basic questions: What data does your organization have? Where is it stored?

Both questions are deceptively simple. Regarding the data you have, this should include structured data found in databases and unstructured data, e.g., PDFs. Unstructured data might also comprise emails, instant messages, and rich media like audio and video recordings. You will almost certainly need an automated tool to discover all the data in your organization and its cloud instances.

Regarding where your data is stored, remember that the honest answer is “Almost anywhere, including places we haven’t thought of.” With a SaaS data discovery tool like Suridata, you can automatically scan numerous SaaS applications and find data that needs protection under the data security policy.

A related question is, “Who owns the data?” Each dataset in the inventory should ideally connect with a person or team responsible for maintaining data quality and following data lifecycle policies, e.g., deleting data over seven years old if that’s the rule.

#2 – Risk Assessment

With the data inventory in hand, you can now assess the risks each data set faces. You can take your choice of approaches to a data risk assessment, but the purpose is always the same: determining which data assets are at the highest risk for breach, and the impact of a breach. This requires ranking data by sensitivity and value. For example, a customer list may be more sensitive than a product list because the former contains personally identifiable information (PII), which is subject to privacy laws. The product list is probably already public, so breaching it means nothing.

The reason for this ranking is to prioritize protection. It’s impossible to apply the same level of protection to every data set. In this context, consider that data sensitivity and value may differ. Intellectual property (IP) data supporting your next patent could be worth billions of dollars. The business impact of an IP breach would be immense, so your IP might require the highest level of defense.

#3 – Access Control Policies

Who can access each data set? That’s a critical part of the data security policy. You already have some sort of access control mechanism in place, but you will likely have to adapt it to the data security policy. This may be because access is typically granted in your organization by network segment or application, not data. However, as data becomes subject to higher levels of protection, you will want to map access rights with data sets.

Indeed, you may already be working on some version of data-driven access controls if you’re implementing zero trust (ZT). ZT allows for granular grants of access down to the level of individual files, if necessary. If your organization is doing ZT, it’s a good idea to bring them into the process of developing the data security policy.

The best approach may be to use role-based access controls (RBACs), e.g., if your role is “Accounting Team Member,” then you should be allowed to see data that lets you do your job on the Accounting Team but not data for the Sales Team, and so forth. Defining and enforcing access control policies will invariably require using an identity and access management (IAM) system, such as Microsoft Entra ID, and SaaS security solutions like Suridata.

#4 – Real-Time Threat Detection

One of the more troubling aspects of serious data breaches is that attackers may be able to lurk inside your networks for months before being detected. A data security policy should mandate real-time threat detection. The goal is to prevent data breaches by responding to threats before they can cause too much damage. In some attack scenarios, such as ransomware, seconds count. The faster you can shut down an infected endpoint or stop ransomware from encrypting data, the more effective your data protections will be.

#5 – Misconfiguration Management

Software configurations, particularly in SaaS, can expose data to risk. For example, a SaaS app may allow public document sharing by default. This is an insecure configuration, one that needs to be hardened to prevent data leakage. However, keeping track of configurations across multiple SaaS apps can be difficult, especially considering that people outside of IT and Security can change their SaaS settings. An automated misconfiguration detection and remediation solution is essential for mitigating configuration risk.

#6 – Third-Party Integration Monitoring

Third-party applications can be a source of data risk exposure. With SaaS, for example, third-party plugins enable external apps to be treated as “users” of SaaS apps that contain your data. Your SaaS environment might have dozens or hundreds of such connections, any one of which could be insecure. The plugins themselves tend to be uneven in terms of quality and maintenance. For these reasons, the data security policy should incorporate third-party integration monitoring.

#7 – Data Encryption Standards

Some think that encryption is the only countermeasure required for data security. In reality, encryption is your last line of defense. Working from your data inventory and risk assessment, your data security policy should ensure that the most sensitive and valuable data sets receive the right levels of encryption. Again, with the sprawl of SaaS, you may leave some data unencrypted and at risk.

These seven are “must haves,” but there are more. Backup and recovery are important for ensuring data security. Incident response matters, as do audit logging and monitoring. And, while it’s not always the most effective way to defend against cyberattacks, employee training can help protect data. When employees understand, for instance, that they should not store sensitive data on public file drives, that can help avoid data security incidents.

How to Build and Implement a Data Security Policy

Realizing a data security policy means running herd on a variegated set of documents, programs, and people—especially people. Making a success of a data security policy is a human-centric activity. An effective data security policy will comprise people and organizational units who understand their roles in the policy and their responsibilities for policies and processes.

Practically speaking, a data security policy is like any other serious, large-scale security or governance program. It starts with a discovery and consensus-building process, followed by assignments of responsibility, with executive leadership and accountability at individual and team levels. It’s an ongoing workstream with regular assessments, course corrections, and updates.

The choice of tools matters. Suridata can help with the SaaS dimensions of a data security policy. The platform can automatically discover sensitive information across the SaaS ecosystem. It monitors SaaS apps for misconfigurations and automatically flags them for attention or automatically remediates them. In parallel, Suridata detects anomalies and policy violations, including external and anonymous data shares, which can be harmful leaks of important data, even if they are inadvertent.

Getting to a Successful Data Security Policy

Your organization needs a data security policy. The growing volumes and diversity of data, coupled with the cloud’s endless and hard-to-track potential for data storage, make data protection a high priority. The worsening threat environment and strict regulations affecting data make the matter all the more urgent.

However, a data security policy is only as strong as the tools and processes supporting it. Getting it right means embarking on a multi-step journey that includes action steps like building a comprehensive data inventory, conducting a risk assessment, evaluating and updating access controls, and more. Much of the time, the foundational elements of the data security policy already exist, but they need to be adapted for the policy. People are essential to success, too. Clear roles, responsibilities, and accountability will enable what can be a complex set of policies to come together to protect sensitive data.

Suridata provides you with the ability to proactively address the “must-haves” with its advanced SaaS scanning, detection, and monitoring capabilities.

To learn more about how Suridata can help you operationalize your data security policy, schedule a demo.

Cyberhaven, a leading Data Loss Prevention (DLP) provider, experienced a sophisticated cyber-attack that exploited its trusted Chrome extension. Designed to monitor user inputs in real time, block unauthorized data entry on platforms like social media or AI tools, and alert users and admins to violations, the extension was turned into a gateway for attackers. 

A malicious update exposed 400,000 Cyberhaven users, enabling attackers to harvest sensitive data such as passwords and cookies, putting countless accounts at risk. 

How Did It Happen? 

1. Phishing Attack: 

• A malicious email was sent to Cyberhaven’s admin, impersonating Google. 

• The email falsely claimed that the Chrome extension was violating Google policies and required immediate action to avoid removal from the Chrome Web Store. 

2. OAuth Exploitation: 

• The email included a link that directed the admin to a fake OAuth permissions page. 

• The admin unknowingly granted permissions to a malicious application, allowing attackers to upload new versions of Cyberhaven’s Chrome extension. 

3. Malicious Code Deployment: 

• Using the obtained permissions, attackers uploaded a compromised version of the extension, containing malicious code. 

• The code was designed to exfiltrate user-sensitive data to a Command-and-Control (C2) server. 

4. Automatic Updates: 

• Chrome extensions update automatically. This caused the malicious version to spread to any Cyberhaven user. 

Discovery and Mitigation
Hours after the malicious update was live, Cyberhaven’s security team detected the breach. They removed the malicious code and issued a public statement.  

Attack Flow Diagram

How Suridata Protects Companies From Malicious Extensions 

Suridata’s SaaS security platform identifies third-party apps and extensions and automates workflows to address risks arising from them.  

1. Identification of Third-Party Apps and Extensions 

Suridata provides continuous monitoring of your organization’s SaaS environment to identify all connected third-party applications. The platform scans the entire SaaS ecosystem to uncover every plugin authorized by users, detailing who approved it, the permissions granted, and other critical metadata—all presented in an intuitive interface designed for quick, and informed decision-making. 

2. Automated Workflows for Remediation 

Suridata empowers organizations to create automated workflows that address the risks associated with new third-party apps or extensions. These workflows can automatically send alerts to notify relevant stakeholders about newly added third-party apps, based on their priority, permissions, or associated risks. 

With Suridata’s workflows, organizations can also take actions such as automatically revoking access to high-risk apps or extensions or assigning tasks to team members for further investigation. 

Those automations significantly reduce the exposure-window by enabling immediate notification and action when a potential threat arises. One such use case is when a high-risk application with critical permissions is authorized by an admin, as happened in the Cyberhaven case, Suridata could notify the admin, who may not have been aware of the situation, and even revoke access or disable the application (leveraging the SaaS vendor’s capabilities). 

Suridata provides fast identification and alerting on new & existing, potentially risky, third-party apps. Thus, allowing your security team to take immediate actions to minimize exposure and remediate the risk. 

Recently, the security landscape has been shaken by several high-profile breaches, and the latest incident involving GitHub tokens has once again highlighted the critical importance of Machine-to-Machine security practices. This blog dives deep into the details of The New York Times GitHub token breach that exposed the entire source code of The New York Times, its implications, and what organizations can do to safeguard their systems. 

A Bad Time for The New York Times: Entire Source Code Exposed 

Using a stolen GitHub token, attackers exploited access to The New York Times’ GitHub repositories. 

This token was overprivileged, granting access to all repositories within The New York Times GitHub organization. It is probable that the token was poorly managed, having a long expiry period, being leaked through accidental public exposure, stored on a compromised employee’s device, or used by an ex-employee to access private GitHub content. 

This breach underscores the risks associated with SaaS application tokens, which are often the most vulnerable points and the entry point to the organization’s sensitive data.  

What Happened? 

The breach occurred in January 2024 when attackers used a stolen GitHub token to access The New York Times’ repositories. The attacker leaked data, which included 270GB and over 5,000 repositories, with fewer than 30 being encrypted. The stolen files contained IT documentation, infrastructure tools, and source code, including the viral Wordle game. 

The Impact 

The impact of this breach is far-reaching:

• Repository Access: Attackers could access private repositories, leading to data leaks and exposure of proprietary code. 
• Data Manipulation: With write access, malicious actors could alter or delete critical code, inject malicious code, or disrupt development processes. 

How Could Suridata Help?  

At first, to prevent such breaches, Suridata protects your repositories and data at GitHub, with the following best practices: 

• Token Management: Suridata maintains an inventory of your GitHub tokens, allowing investigation for each one. This includes the latest access, and expiration dates. 
• Regular Token Rotation: Suridata alerts you to rotate tokens frequently to minimize the impact of potential breaches. 
• Implement Least Privilege: Suridata displays the permissions granted to tokens and recommends the minimum necessary for their operation. 
• Breach Detection: Suridata continuously monitors all tokens across the SaaS environments, detecting anomalies in usage and changes in roles and permissions. 

Following a potential breach, Suridata responds as follows: 

• Revoking Tokens: Revoking any compromised tokens to prevent further unauthorized access. 
• User Notification: Promptly notify impacted users, advising them to regenerate their tokens and review repository access logs. 

Conclusion 

Organizations must remain proactive in securing their development environments, especially when they are easily accessed through tokens. By continuously improving defenses, and embracing automated responses, organizations can better protect their valuable assets from evolving threats. 

Not sure if you are using GitHub? Suridata offers free application scanning to help you identify and prevent attacks in your SaaS environments. 

---

Overview of The Breach

On May 2, 2024, Dropbox disclosed a significant breach involving its digital signature service, Dropbox Sign (formerly HelloSign). The breach was discovered on April 24, with unauthorized access traced back to a compromised service account within Dropbox Sign’s backend infrastructure. This allowed attackers to exploit elevated privileges and access a customer database, affecting all Dropbox Sign users.

Details of Compromised Data

The breach led to the exposure of sensitive information, including emails, usernames, general account settings, and for some users, phone numbers, hashed passwords, and critical authentication data like API keys, OAuth tokens, and multi-factor authentication (MFA) details. Notably, the breach also affected individuals who interacted with Dropbox Sign documents but did not create an account. This caused the exposure of their names and email addresses.

Potential Impacts and Dropbox’s Response

Dropbox has initiated several remedial actions in response to the breach. These include resetting user passwords, logging out users from connected devices, and rotating all compromised API keys and OAuth tokens. The company is currently reaching out to all affected users with specific guidance to secure their information. Dropbox is also cooperating with law enforcement and regulatory authorities.

The ultimate impact of this breach is unknown, but it is likely to be significant. Now that the attackers have critical authentication data, they can hop between customers’ accounts, retrieve more data, and put more customers in danger.

The Role of Suridata in Enhancing Security

The Dropbox Sign breach highlights the essential role of Suridata in both preventing and responding to similar cybersecurity incidents. With its capabilities in managing and securing third-party apps and APIs, Suridata is particularly valuable, especially as it integrates Dropbox as a core business SaaS application within its management framework. As the breach occurred in Dropbox Sign, which is an integral part of Dropbox’s suite of services, leveraging Suridata enables organizations to gain precise insights into their Dropbox account activities. This includes detailed tracking of account movements, connected plugins, and both human and non-human account interactions, along with the specific times each element was accessed. Moreover, Suridata provides a comprehensive risk analysis, identifying misconfigurations that could lead to unauthorized access.

Additionally, Dropbox serves as a third-party application used in various business applications. Suridata can identify on what applications Dropbox is being authorized, and point out where it should be isolated or where credentials should rotate.

For example, Suridata can assist with:

• Isolating sensitive integrations: Detecting and managing which third-party applications, like Dropbox Sign, are authorized to integrate with core business applications, recommending isolation or restricted access where necessary.
• Rotating and managing credentials: Identifying and implementing automated workflows for credential rotation for services connected to Dropbox Sign to prevent unauthorized access from compromised credentials.
• Enhanced view of account activities: Ensuring that all users and API activities within Dropbox Sign are monitored with alerts for any unauthorized access attempts or anomalous behaviors.
• Applying access controls: For example, enforcing policies that require multi-factor authentication for all accesses to Dropbox Sign.
• Regular risk assessment: Regularly scanning and assessing Dropbox Sign configurations and usage to identify potential security misconfigurations or vulnerabilities that could lead to breaches.

This proactive and detailed approach empowers organizations to enhance their security postures effectively, ensuring that their data remains secure while protecting sensitive data, against evolving cyber threats and maintaining trust with users.

Potential Attack Path

---

Breach Details

In April 2024, Sisense, established in 2004 to offer business intelligence and data analytics software, suffered a significant data breach. The breach involved unauthorized access to Sisense’s GitLab code repository, which led to the exfiltration of data from Sisense’s Amazon S3 accounts. This breach has been described as one of the most severe in recent times, potentially affecting millions of credentials. 

Implications 

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has taken an active role in addressing this breach due to its potential to initiate a massive supply chain attack that could affect thousands of companies globally. The breach highlights critical vulnerabilities in software products and the growing interest of attackers in targeting such infrastructure. 

Call to Action 

In response to the breach, Sisense’s CISO has issued urgent recommendations for all customers to rotate any credentials used within their Sisense applications immediately (see the original message) 

Customers should also reset API keys and look for unusual activity starting from April 5th, 2024. Users must act quickly to mitigate further risks. 

How Suridata Could Have Helped 

In this incident, Suridata could have mitigated the risk significantly by:  

• Securing access to Gitlab using IP based controls 
• Ensuring that all users access requires MFA and that there are no exceptions 
• Configuring and scanning to confirm that there is no committing of credentials into code  
• Restrict AWS API key usage by IP Address 
• Making sure that client information is encrypted at rest 
• Detect Sisense as a shadow SaaS / third-party app connected to core business applications.

Conclusion 

The Sisense data breach serves as a critical reminder of the importance of enhanced SaaS security practices, especially in safeguarding interconnected applications and third parties. Companies must stay proactive in their security strategies to protect their data and maintain trust with their customers and partners. 

---

Last October, Okta, the $1.8 billion identity and access management (IAM) giant, revealed that it had been targeted in a complex and multifaceted cybersecurity attack that exposed vulnerabilities in the company’s digital identity security. The attack highlights the risks associated with managing sensitive user data. It also demonstrates the necessity of robust digital SaaS identity security measures, along with the importance of rapid detection, communication, and response to those kinds of threats. This article looks at what happened, and how it could have been prevented.

First, to truly understand the Cloudflare breach, we need to see the timeline of events:

October 2023: Okta  Breach

Early October: Okta’s breach occurred, resulting in the compromise of various customer credentials, including those belonging to Cloudflare.

The breach began with an attack that exploited a stolen cookie from Okta’s support system, leading to unauthorized access to Okta’s support case management system. This system, separate from the main Okta service, is used for managing customer support tickets and related data, which includes sensitive HTTP Archive (HAR) files containing cookies and session tokens crucial for maintaining user sessions.

The breach led Okta to revoke session tokens embedded in shared HAR files, disable the compromised service account, and implement measures to prevent employees from signing into personal accounts on Okta-managed devices. These steps were part of Okta’s broader effort to enhance security and combat the threat of session token theft against administrators. Those crucial measurements can be performed through a centralized SaaS Security platform, such as Suridata.

October 18, 2023: Cloudflare’s Okta instance was specifically breached using the authentication token stolen from Okta’s support system, affecting files belonging to 134 customers, including Cloudflare.

---

November 2023: The Cloudflare Attack & Response

November 14, 2023: Attackers first gained unauthorized access to Cloudflare’s self-hosted Atlassian server, marking the beginning of the direct attack on Cloudflare.

November 22, 2023: The attackers established persistent access through ScriptRunner for Jira, accessing the source code management system, and attempting to access a console server linked to an undeveloped data center in São Paulo, Brazil.

November 23, 2023: Cloudflare detected malicious activity within its systems.

---

Post-Attack Actions

November 26, 2023: Cloudflare’s cybersecurity forensics team initiated a detailed investigation into the incident.

In the following weeks: Cloudflare undertook extensive remediation efforts, including credential rotation, system segmentation, forensic triage, and a comprehensive reboot of systems across its global network.

January 5, 2024: Formal remediation efforts were concluded, although Cloudflare maintains ongoing efforts in software hardening and security improvements.

---

Insights and Summary:

The Cloudflare breach was initiated through the exploitation of stolen authentication tokens and service account credentials from a prior Okta breach. Attackers targeted Cloudflare’s self-hosted Atlassian server, gaining unauthorized access to its Confluence, Jira, and Bitbucket systems. Despite the attackers’ efforts, the breach did not affect customer data or systems. Cloudflare undertook extensive remediation efforts, including credential rotation, to prevent future intrusions.

---

How Could have Suridata Prevented this Attack?

1. The breach highlights the complex challenge of managing and securing authentication tokens and service account credentials in a landscape where sophisticated attackers continuously seek to exploit any vulnerabilities. Suridata protects tokens and API keys by proactively monitoring those digital assets, revoking their access, deleting them, setting expiration dates, granting specific scopes, and alerting for the need for rotation of tokens and credentials. In this case, Suridata could have detected the access permissions granted through the token, its usage, and who granted and used the token. Suridata could have then alerted the relevant admins or the security team regarding the suspicious activities and high-risk score, thus preventing the misuse of the tokens.
2. Suridata, which integrates with critical systems such as Okta, Confluence, Jira, and Bitbucket, could offer substantial benefits in the early detection and mitigation of cybersecurity risks. Suridata’s capability to connect with these systems means it can continuously monitor for new risks, anomalies, or changes in user or token behavior, providing a proactive stance against potential security threats.
   This means that any unusual behavior or deviation from the norm, such as the misuse of authentication tokens or unexpected changes in user privileges, could be quickly identified. This level of surveillance is crucial for early detection of security incidents, potentially even before any data compromise occurs.

---

Conclusion

A breach of this magnitude is a serious problem for any business. For a company like Okta, whose brand is largely based on its reputation for guarding identity credentials, this breach proved to be a major embarrassment—and a significant distraction and resource drain in the remediation process. No system is ever completely bulletproof, but an examination of the attack chain suggests that certain countermeasures, such as those provided by Suridata, could have mitigated the threat.

---

Introduction- What is ServiceNow?

ServiceNow, uniquely positioned as both a Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS), offers a versatile digital workflow platform.

Key applications include IT Service Management (ITSM) for automating IT services, IT Operations Management (ITOM) for infrastructure optimization, IT Asset Management (ITAM) for asset tracking, Service Desk and Customer Support for efficient issue resolution, and an Employee Self-Service portal.

This multifunctionality makes ServiceNow a repository for a vast array of valuable organizational data, attracting attention in the realm of cybersecurity.

---

Security Alert: ServiceNow’s ACL Vulnerability Explained

ServiceNow experienced a data exposure flaw. This vulnerability, involving the default configurations of access control lists (ACLs) in ServiceNow’s widgets, particularly the ‘Simple List’ widget, enabled unauthenticated access to sensitive data stored in the ServiceNow platform​​​​.

---

What Led to This Situation?

The flaw stemmed from the way ServiceNow’s widgets, which act as APIs for the Service Portal, were configured. These widgets, by default, were set to public, allowing unauthenticated access to specified data. The vulnerability existed because the access control for these widgets was not governed by Access Control Lists (ACLs) but by fields on the individual widget record itself​​​​.

---

What Is the Risk?

Potentially, the leak could affect thousands of companies that use the platform. Attackers could steal personally identifiable information (PII) such as names, email addresses, customer records, financial information, and intellectual property.

There was a risk of unauthorized access to sensitive data, which could have severe implications for data privacy and security for the organizations using ServiceNow​​.

---

How Would Suridata Make the Difference?

Suridata focuses on SaaS security, pinpointing misconfigurations and safeguarding sensitive data across applications. Using its advanced monitoring and automated remediation features, the platform can detect configurations like ‘Widgets with Public Access’ early on, preventing unauthorized data access.

---

How to Address and Mitigate the Risk?

Remediation steps include reviewing and securing ACLs with roles or addressing the underlying access control issues. In addition, implementing temporary mitigations such as inbound IP address restrictions and disabling public widgets.

Organizations are advised to take the security of their data into their own hands, thoroughly reviewing both customer-made configurations and the vendor’s product default configuration.

Implementing Suridata as a security measure for misconfiguration drift monitoring would have prevented the potential loss of data.

---