Category: Blog

Hacking into a system and remaining a standard user can’t be too much fun. It would be like sneaking onto a private beach but only being allowed to build a sandcastle. If you want to do anything impactful (or harmful), you need a higher level of privilege. Privilege escalation helps attackers accomplish this goal, and they are increasingly common. 
55% of insider attacks rely on privilege escalation exploits, where bad actors improperly gain higher “back end” access. Indeed, some of the worst cyberattacks, from WannaCry to NotPetya and BlueKeep, have occurred because of privilege escalation. Knowing how these attacks work is the first step in preventing and mitigating them.

Understanding Privilege Escalation Attacks

In a privilege escalation attack, a malicious actor (sometimes an insider) gains the privileges available to admin or super admin users. With these privileges, the attacker can disrupt the target system, cut off users, change passwords, install ransomware, or breach its data.

To understand privilege escalation attacks better, it helps to be familiar with the general concept of privilege in computer systems. Virtually all computer systems have a front end, which offers features for use by the public or standard users. For example, users can access basic functionality like looking up a customer’s address within their Salesforce environment or other customer relationship management (CRM) tools.

The back end is administrative. It is where admins, also known as privileged users, can perform tasks that affect the content and functioning of the system itself. This includes modifying the data displayed on the standard user interface or deleting customer records. A superuser with the highest privilege level can uninstall the CRM solution or delete its database. 
Attacks like privilege escalation can be devastating, leading to costly remediation, data breaches, compliance penalties, and loss of customer trust. In many cases, the super admin level of privileges, often called “root access,” allows the attacker to erase logs, reinstall operating systems, and otherwise cover his tracks so no one will know how they got in.

Source

Types of Privilege Escalation Attacks

There are two basic types of privilege escalation attacks:

1. Horizontal Privilege Escalation Attack

A horizontal privilege escalation attack is one in which an attacker takes over an account, usually a standard user’s. With this standard user account as a starting point, the hacker will usually try to take over additional accounts with higher privileges to access different feature sets and data. 

2. Vertical Privilege Escalation Attack

Vertical privilege escalation, in contrast, involves increasing the attacker’s privilege level. It typically includes a period of surveillance, during which the attacker observes how the system works, who’s on it, and how privileges are assigned. After surveillance, the attacker will move to exploit a vulnerability. 

For example, the attacker might take advantage of an unpatched operating system vulnerability, such as the Linux “Dirty Pipe” (CVE-2022-0847) vulnerability, which allows an attacker to escalate his privilege level by manipulating the Linux kernel. 

Common Security Gaps Leading to Privilege Escalation

1. Credential Exploitation

An attacker may be able to log into a target system using stolen credentials or simply by guessing a user’s password. Alternatively, they can run a brute force attack that discovers passwords by repeating trial-and-error attempts. This attack type assumes the system uses single-factor authentication (1FA). SaaS applications are often exposed to this risk if, for instance, users can set their security configurations and avoid multifactor authentication (MFA).

2. Misconfigurations

A system’s configurations can expose it to a privilege escalation attack risk. Examples abound, but some of the biggest offenders are allowing simple passwords and 1FA and leaving systems with default security settings (a common mistake in SaaS applications).  

3. Overly Permissive User Roles

Giving users excessive permissions can increase the risk of privilege escalation. For instance, a standard admin might inadvertently be granted super admin access, often due to staffing constraints or mismanaged roles. 

In many enterprise applications, “Executive” users can access broader datasets than standard users, whose access might be limited by region or department. To simplify management, organizations may assign executive-level access to all users. However, this approach significantly raises the stakes: if an attacker compromises one of these accounts, the potential damage becomes much greater.

4. Lack of Monitoring for Suspicious Activities

Many organizations fail to monitor user activity closely enough to detect insider threats or external signs of privilege escalation. Without real-time monitoring, anomalous behaviors (like logins at unusual hours or a new user rapidly gaining elevated privileges) can go unnoticed. This blind spot allows attackers to move laterally or escalate access without triggering any alerts, leaving systems vulnerable for extended periods.

5. Third-Party Integrations

Integrating with third parties, which is common in SaaS environments, can open the door to privilege escalation attacks. The SaaS app may treat the third party as a “user.” If security settings are not hardened or the third-party plugin has been compromised, the third party can be a vehicle for unauthorized privilege escalation. 

How to Prevent and Mitigate Privilege Escalation Attacks 

What can you do about privilege escalation attacks? Best practices fall into two broad categories: prevention and mitigation. Prevention is about setting up controls and countermeasures that reduce your risk exposure for privilege escalation. Mitigation, conversely, is about minimizing the impact of a privilege escalation attack. Here are some of the most popular prevention and mitigation best practices (some require purpose-built tools): 

Prevention

Attribute-Based Access Control (ABAC)

This approach to access control extends the traditional role-based access control (RBAC) model to a higher level of granularity, such as role hierarchies. Adding attribute-based access control (also called ABAC) limits role-based access by attributes like device location. Enforcing context-aware controls that restrict when, where, and how elevated permissions can be used minimizes the risk of privilege escalation.

Source

Risk-Based Access Review

A periodical risk-based access review (usually quarterly) is critical to examine user access rights and verify that they are entitled to those privileges. It can often present unexpected findings, such as users who have left the company but still have access rights or who have changed roles but retained earlier access to systems they no longer need.

Continuous Misconfiguration Detection

System misconfigurations are endemic to SaaS environments. A company might have a hundred SaaS apps running, each with unique security settings, making application dependency mapping incredibly challenging. 

Solutions like Suridata can continuously monitor SaaS security configurations, detect insecure configurations, and alert admins to situations where they pose a risk for privilege escalation and other threats. When a misconfiguration is flagged, Suridata can also provide detailed remediation guidance. 

Zero Trust Architecture (ZTA) Implementation

A Zero-Trust Architecture enforces the principle of least privilege and continuous authentication, reducing the likelihood of privilege escalation. Although ZTA minimizes the probability of privilege escalation, a sophisticated attacker can still work around it by impersonating users with high access privileges.

Behavioral Analytics for Insider Threat Detection

Insiders (such as employees or contractors) may carry out privilege escalation attacks due to resentment or a desire for revenge. To mitigate these risks, organizations should combine security testing with behavioral analytics. 

Continuous penetration testing can help identify vulnerabilities that insiders might exploit, while AI-driven behavioral analytics can detect subtle patterns that indicate a potential threat. 

Suridata can identify security threats of SaaS applications and enable rapid detection and mitigation of malicious privilege escalations. 

Source

Mitigation

Real-Time Privilege Escalation Detection with Contextual Awareness

One challenge in mitigating privilege escalation attacks is differentiating between routine changes in privileges and those that come from attacks. Understanding context can make a big difference in distinguishing the good from the bad. For example, if a user’s access privileges are escalated across two departments two days in a row, that strongly suggests an improper context for the escalation. 

Third-Party Integration Risk Assessment

Third-party integrations create unexpected back doors for privilege escalations, mainly for SaaS apps. Suridata can mitigate this risk by detecting insecure integration (for example, from plugins that contain known vulnerabilities or have not been patched) and flagging them for remediation. The platform also monitors user activities, analyzes access levels, and prioritizes risks for mitigation. 

Risk-Based Multifactor Authentication (MFA)

Multifactor authentication is more effective when it adapts to risk signals. Instead of treating all access attempts the same, risk-based MFA evaluates the context, such as the user’s location, device, or access time. 

For instance, the system can flag or deny the request if an OTP request comes from an unusual location or at an odd hour, like 2 AM on a Sunday.  Zero Trust Architecture may also involve re-authenticating the user or device during an active session to ensure ongoing trust.

Incident Response for Privilege Escalation

If a privilege escalation attack occurs, quickly contain the affected account, analyze logs for suspicious activity, revoke unauthorized access, and patch exploited vulnerabilities. Implement password resets, forensic investigation, and enhanced monitoring to prevent further compromise and strengthen security controls.

Protecting Access Privileges from Improper Escalation

Hackers often need to escalate their system access privileges to achieve their goals, and they resort to privilege escalation. They have many options available for privilege escalation, including social engineering, account takeover, and password theft. Once inside a system, they can exploit many vulnerabilities to gain back-end admin access or root control. 

Privilege escalation attacks are a serious risk for the entire IT estate, but SaaS is a particularly problematic environment to defend. Many SaaS apps have their internal privilege hierarchy and difficult-to-monitor security configurations. Preventing and mitigating privilege escalation attacks in SaaS requires ongoing user behavior monitoring, visibility into third-party integrations, and continuous awareness of security configurations. 

Suridata enhances SaaS security by detecting misconfigurations, excessive permissions, and third-party app risks, preventing privilege escalation attacks. Its automated remediation, real-time threat detection, and compliance support help enterprises strengthen their holistic SaaS security posture. Learn more at Suridata. 

Have you ever wondered why most enterprises schedule application upgrades at four o’clock on Sunday mornings? They do this in case the change “breaks” the application and causes it to cease functioning. Hopefully, an outage won’t affect many users then, and the upgrade team can either solve the problem or reverse the upgrade before it affects user experience.

But breakages aren’t a hypothetical issue. Three in four dependency vulnerability patches cause systems to break, often due to the unpredictable behavior of application dependencies. Application Dependency Mapping (ADM) is essential to addressing this risk. 

Any stakeholder, from application developers to security teams and application admins, relies on application dependencies maps to anticipate issues and prevent security vulnerabilities arising from unexpected impacts of upgrades and changes.

What is Application Dependency Mapping, and How Does it Work?

Application Dependency Mapping (ADM) visually represents the relationships between applications and sometimes their infrastructure, like servers or storage devices. Because these dependencies can introduce vulnerabilities, ADM is critical in enforcing a robust data security policy and helping teams identify and mitigate risks.

These dependency maps often use color coding or other visual cues to help stakeholders understand dependencies, their impact on security, and application reliability. Some maps even show data flows and dynamic interactions.

There are several ways to map dependencies. The simplest is manually drawing them with tools like Visio. Larger organizations use purpose-built tools that ping IP addresses, analyze network traffic, or install software agents to uncover dependencies. Application Performance Monitoring (APM) tools can also reveal relationships through performance data.

Source

The growing use of SaaS applications complicates the ADM process. Pinging IP addresses and network monitoring are not viable methods to capture relationships between SaaS applications. Yet, SaaS apps often rely on each other in ways that impact security and performance. For example, a third-party integration plug can create a hidden dependency, potentially exposing both apps to data security risks.

Why Application Dependency Mapping is Essential in 2025 

Application dependency mapping is critical for application reliability and maintaining a strong cybersecurity posture. While this has long been the case, it is more urgent than ever as supply chain risks are growing within application dependencies.

A recent example of this trend is the Okta breach in late 2023, where hackers compromised the support management system connected to Okta’s identity management solution to steal customer data. ADM could have helped security teams pinpoint such dependencies. Reasons why this process is essential today include:

• Enhanced Visibility and Risk Management—Application dependency mapping reveals connections that may be insecure and need remediation. Knowing where you have risk, you can manage it more effectively. 

• Improved Incident Response—Knowing your application dependencies helps you respond faster to security incidents. If one application depends on another, you can quickly identify potential gaps in that dependency that may have caused the breach and remediate them.

• Faster, More Predictable, and Secure Change Management—An application dependency map highlights potential issues during a change process so you can address them beforehand. If problems arise, it helps you quickly troubleshoot the cause.

• Stronger Compliance and Auditing—ADM can aid compliance by making data protection and system integrity easier to achieve and audit. While not always required by regulations, several laws and frameworks mandate these practices, including GDPR, HIPAA, and NIST 800-53.

8 Steps to Perform Application Dependency Mapping

Setting up an application dependency mapping tool and letting it run is tempting, but that ignores some important bigger-picture issues and best practices. Here are eight steps that will help achieve the best outcomes from the ADM process.

#1 Step: Take a Phased Approach

If you’re new to application dependency mapping, starting with a subset of your IT estate is best. Not all applications and dependencies are equally critical, so begin by mapping those affecting your most business-critical applications, then expand to others in subsequent phases. Focus on high-risk areas, such as customer-facing applications or systems that handle sensitive data, to identify vulnerabilities quickly.

#2 Step: Inventory All Applications And Their Integrations

Even with a phased approach to ADM, it is wise to start with a complete inventory of your applications and their integrations, such as API connections. Integrations differ from dependencies, which can exist within applications or between software elements not captured in the integration inventory. Regularly update the inventory to account for new applications or integrations so your maps are always accurate and up to date.

#3 Step: Map Connections and Dependencies Between Applications

Links between applications can be challenging to identify, even for experienced professionals. This is due to the complexity of modern IT environments, which span both cloud and on-premises infrastructure. Use purpose-built tools, which save time and help uncover missing dependencies that are hard to spot.

For example, real-time dependency tracking and monitoring tools can update your maps continuously to reflect any changes in the environment, helping to catch new connections or vulnerabilities that may arise after initial mapping.

Source

#4 Step: Leverage AI and Automation

ADM workflows are time-consuming and prone to error, but automation helps you move faster and build more accurate dependency maps. AI can also support this process, using pattern recognition and machine learning to identify dependencies and assess risk levels. Look for tools that integrate AI to flag high-risk dependencies.

Consider using GenAI to speed up report generation. GenAI can automate the production of dependency maps and accompanying documentation so your team can focus on analyzing the data rather than creating it.

#5 Step: Assess Risk Exposure Based on Dependencies

A dependency can expose your organization to risk, but not all dependency-related risks have the same potential impact on operations and security. Classify your assets based on their value and sensitivity, such as customer data, intellectual property, or financial records. Once you’ve identified your “crown jewels,” map out their dependencies via a detailed security risk assessment. These could be databases, third-party services, or cloud integrations.

#6 Step: Include SaaS in Your Map

Mapping dependencies between SaaS applications can be challenging, but it’s essential to understand how they connect and where data might be vulnerable to unauthorized access. Tools like Suridata can help by identifying misconfigurations, access tokens, API keys, and third-party integration plugins that introduce dependency-related risks. Suridata’s real-time monitoring of SaaS apps can also detect threats and attacks targeting these dependencies, even if they were not previously identified.

#7 Step: Integrate with Development 

With continuous integration/continuous delivery (CI/CD), new dependencies appear multiple times a day. Therefore, it is essential to integrate ADM with development workflows to avoid falling behind. Automate the dependency mapping process within your CI/CD pipeline by integrating ADM tools with your version control and deployment tools. This ensures real-time updates to your dependency maps, keeping them in sync with the development cycle.

#8 Step: Test Dependencies and Update Maps Regularly

Dependencies tend to change, often rapidly. As a result, the dependency map from last year or last quarter is likely to be obsolete. Some dependencies are gone, while new ones have appeared as your cyber attack surface expanded. To avoid having an out-of-date map, it’s wise to test dependencies and update your maps regularly. Some ADM tools can do this automatically.
Keep in mind that ADM is a people-oriented organizational process. Developers, application owners, IT managers, security team members, and other stakeholders should know its importance. When you try to include stakeholders in the process, the map will be more accurate and impactful for everyone’s work.

Moving Toward Effective, Sustainable Application Dependency Mapping

Application Dependency Mapping (ADM) is key to identifying cybersecurity risks and ensuring application availability by uncovering hidden threats in application dependencies and interconnected SaaS environments. With the right automated tools, ADM becomes faster and more accurate, helping you prevent costly outages and data breaches. Suridata’s SaaS security platform can enhance your ADM efforts with real-time monitoring and automated detection of SaaS application integrations. Suridata turns complex data into actionable insights, strengthening your overall security posture.

To learn how Suridata can streamline your ADM processes, improve security, and support proactive management of SaaS-related risks, book a demo.

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. 

Did your mother ever tell you not to open the door to strangers? She knew best: there was a chance, however small, that something bad would happen. She’d done her version of a security risk assessment (SRA) to protect you from harm. Cybersecurity may be a lot more complex, but the risk management concepts aren’t all that different. 

Nearly three in four organizations have experienced one or more significant disruptions due to third parties in the last three years. Your enterprise has likely opened its doors to vendors and partners so you can continue to improve your products and customer service. However, a chain is only as strong as its weakest link, and failing to assess third-party risks can weaken your security posture. An SRA is a valuable step in protecting your digital assets—and in some cases, it may even be legally required.

What is a Security Risk Assessment?

A Security Risk Assessment is a structured review and analysis of cybersecurity risks. While the implementation process may vary, it always involves identifying risks, estimating their likelihood and impact, and prioritizing mitigation through controls and countermeasures. The details may be complex, but the goal is simple: pinpoint the most damaging cyber risks and focus on minimizing their chances of occurring.

The SRA should interest various stakeholders: 

• Chief Information Security Officer (CISO) 
• Chief Information Officer (CIO)
• Department heads in IT and security
• Chief Compliance Officer (CCO) and Chief Financial Officer (CFO)

All of these individuals have a stake in the process and will want to see an SRA lead to measures that bolster security posture. For the CFO, an SRA is part of a bigger responsibility of protecting all corporate assets from harm—a fiduciary duty realized through overall risk management and data security policies. 

With the rise of cloud computing and Software as a Service (SaaS), security risk assessments are more crucial than ever. SaaS introduces new vulnerabilities by storing valuable data and operational processes on external platforms, increasing the risk of exposure. Additionally, SaaS applications can create third-party risks that businesses often have limited visibility into.

Benefits of Regular Security Risk Assessments

Even if you have to undergo a security risk assessment to comply with a specific standard like ISO 27001, the process brings many other security benefits, including:

• Improved Security Posture and Resilience—By identifying and prioritizing the most significant risks for mitigation, an SRA helps your enterprise better defend its most valuable digital assets, improving security posture and resilience. 

• Better Incident Response Capabilities—Knowing which risks deserve the highest focus and investment helps your team be targeted and proactive in threat detection, risk management, and threat response.  

• Lower Costs and Fewer Wasted Resources—An SRA highlights the highest priority risks, enabling you to avoid overspending on low-impact risks. 

• Better Collaboration Across Departments—The SRA process fosters alignment and better collaboration among IT, security, business management, compliance, risk management, finance, and legal teams. 
  
• Improved Third-Party Risk Management—An SRA helps stakeholders discover sources of third-party risk by evaluating partners and vendors.

How to Conduct a Security Risk Assessment in 5 Steps

A security risk assessment typically comprises five steps. The names of these steps may vary based on the framework or organizational context, but they answer the following five simple questions:

1. What digital assets do we need to protect?
2. What’s threatening them, and how are they vulnerable?
3. What will happen if they are attacked and compromised?
4. What should our priority be for managing risk for each identified asset?
5. How will we keep this risk mitigation going over the long term?

Having a single person or small team executing the entire 5-step process is a good practice. They will be responsible for the following:

Step 1: Determine Scope

It’s essential to determine the scope of your SRA at the outset to answer this question so you can build the proper timelines and allocate the right resources. For instance:

• Will your security risk assessment analyze risks for the entire organization or a single business unit? 
• Will it look at physical infrastructure, such as servers, data centers, software, data repositories, and networks? 
• Will it examine third-party connections? 

In some compliance scenarios, an SRA may only be required for a specific system, such as payment processing. Properly scoping the project is essential to ensure no risks are overlooked. The scoping process should begin with a stakeholder discussion and a whiteboard session to identify critical assets and resources. Then, complement this manual process with specialized tools that automate digital asset discovery. For example, in SaaS environments, Suridata can automatically inventory SaaS applications and map the data they contain—including those not officially sanctioned by IT (“Shadow SaaS”).

Step 2: Threat and Vulnerability Identification

With your asset inventory and scope of assessment, it’s time to determine what threats can cause risk exposure. For example, if you’re running an application server, you will discover hundreds of possible threats that could compromise it, like remote code execution (RCE) or SQL injection attacks. Threat intelligence sources like the MITRE ATT&CK knowledge base and the Cyber Threat Alliance can help with enriched threat information.

For organizations leveraging artificial intelligence in their operations, conducting an AI audit (a dedicated audit of AI systems and algorithms) can help identify unique vulnerabilities that may not be immediately evident through traditional assessments.
Some of the most serious threats in SaaS environments stem from third-party integrations. These plugins often allow one SaaS app to interact with another as a user, potentially granting access to sensitive data without oversight. An automated third-party integration monitoring tool like Suridata can detect and flag insecure plugins for remediation, helping to mitigate these hidden risks and implement SaaS security best practices.

Step 3: Risk Analysis

Just because a threat exists does not mean your digital assets will be exposed to risk. There are thousands of threats, and an equal, if not larger, number of vulnerabilities could cause problems. But will they? And, if a threat manifests in an attack, what will be its impact? This is where risk analysis comes into play. The risk analysis step of an SRA involves assessing the likelihood of a threat leading to a successful attack and the potential impact of such an event. The effect can be measured using the traditional information security “CIA Triad” (Confidentiality, Integrity, Availability) or by estimating the financial cost of a security incident. For instance, a breach that costs $100 to remediate has a much lower impact than one that costs $1 million.

Source
Suppose your e-commerce server is vulnerable to a cross-site scripting (XSS) attack that could allow a malicious actor to steal your customer list. How likely is the attack? What would the impact be? A common best practice is to rate probabilities on a scale from 1 to 5, with one meaning “rare” and five meaning “highly likely.” Similarly, impact can be rated from 1 (“minimal”) to 5 (“very severe”).

You can then plot your probabilities, impacts, and inferred risk level on a “Risk Matrix,” as shown here:

The Risk Matrix establishes the risk level for a given threat. In this example, even though a DoS attack has a very severe (level 5) impact, its probability is low (1). As a result, the overall risk level is moderate (3). Alternatively, a SaaS privilege escalation attack is highly likely (5) and very severe (5). The risk level is, therefore, very high (5).

If you’re modeling risk by cost, use Probability x Impact = Risk. With that approach, the risk matrix might look like this:

Step 4: Prioritization of Risks

The relative risk levels should generally translate into levels of prioritization for mitigation. Based on the matrix, SaaS privilege escalation should have the highest priority for a countermeasure. This is an imprecise process, though, and in some cases, you may want to take action even if the probability of an attack is low. For instance, if an outage in your e-commerce server will disrupt your business and brand, then DoS deserves high priority, no matter how unlikely it is to occur.

Prioritization of risks generally means taking one of three actions for a given risk:

• Avoid—Do not mitigate, but perhaps stop the process from occurring by, for example, removing an outdated server and replacing it with a more secure edition.

• Transfer—Transfer some or all of the risk to a third party, such as a cloud platform or a managed service provider (MSP). Cyber insurance can also serve this purpose. 

• Mitigate—Take action to prevent the risk from occurring by patching systems or installing controls and countermeasures.

Dependency mapping is valuable to this process, revealing interdependent systems whose vulnerabilities might amplify overall risk.

Source

After you’ve taken one of these steps, you’ll still have what’s known as “residual risk” – the remaining impact or costs that may persist even after implementing security controls. This is inevitable, and senior leadership must decide whether to implement further mitigations or accept the risk as an inherent part of business operations.

Step 5: Documentation and Monitoring of Risks

The final step involves documenting the work of the SRA team and recording it in a “Risk Register.” This document memorializes the risk, its applicable scenarios, when it was identified, risk level, and current mitigations. It forms the basis for ongoing monitoring and follow-ups. In most enterprises, an SRA is repeated periodically, once or twice a year. The Risk Register is essential for thorough and effective subsequent processes.

Getting An SRA Right

A five-step Security Risk Assessment (SRA) is optional for many companies. However, it’s a valuable process—even when not legally required. An SRA helps identify your most significant security risks, prioritize mitigation efforts, and save money and resources.

This five-step process begins by defining the scope and identifying critical assets. It is followed by threat and vulnerability identification, risk analysis, prioritization, and documentation. By the end, you’ll better understand where to focus your cybersecurity efforts.

With SaaS playing an increasingly prominent role in today’s risk landscape, security solutions must be designed to address its unique challenges. Suridata helps organizations assess SaaS risks during an SRA, identifying issues like insecure data storage, misconfigured SaaS applications, and third-party integration vulnerabilities.

To learn more, visit Suridata.ai or check out the Suridata demo.

The most frightening sentence in the InfoSec world is arguably, “Oh, wow, we didn’t know that was running…” When your organization is using a digital asset like a server or software-as-a-service (SaaS) app, but no one knows about it, you’re exposed to unknown risks. If you’re attacked, you will hear the next most frightening sentence, which is, “We didn’t know this asset existed, but it has been breached.” 

You can’t protect an asset if you don’t know it’s there. And, you will certainly have trouble responding to a security incident involving an unknown or poorly documented asset. With 69% of CIOs planning to adopt between 30 and 60 new AI apps in 2025, the management and security problem known as “asset sprawl” is becoming more acute. If your organization is like most, you’re no longer just managing a few devices or on-premises servers. Your security team is likely juggling hundreds of assets, many of which are scattered across the cloud.

Cyber Asset Management (CSAM) offers a solution. This framework helps IT departments and security teams identify all relevant digital assets and stay on top of their cyber defense. This article explores how CSAM works and why it’s an increasingly important element of a cybersecurity strategy.

What is Cybersecurity Asset Management (CSAM)?

Cybersecurity asset management is a framework comprising a body of practices and purpose-built tools that protect your hardware, data, software, and network infrastructure from cyber threats. CSAM is not  a product, though there are products that offer CSAM functionality. It’s important to note, however, that CSAM almost always involves integration between security systems, such as linking identity and access management (IAM) solutions with CSAM asset inventorying applications, and so forth.

Like most open-ended frameworks, CSAM gets realized in many different ways, but a CSAM implementation usually has the following capabilities:

• Continuous discovery of assets relevant to cybersecurity, i.e., “cybersecurity assets”—making IT and security operations (SecOps) teams aware of all assets. Done right, this means that there will be no hidden assets or users.
• A real-time inventory of assets—enabling stakeholders to know what’s on the network on an ongoing, up-to-date basis, vs. periodic inventories, which quickly become obsolete.
• Detailed asset classification—offering granular descriptions and categorization of assets, which is useful for determining access controls and criticality for protection and restoration.

A CSAM implementation may also have integrations that enable vulnerability tracking by asset, automated policy enforcement, anomaly detection, and compliance monitoring or assurance. For example, integrating continuous web application penetration testing services, can enhance vulnerability management by providing real-time insights into potential security weaknesses. CSAM also often integrates with security tools like SIEM, SOAR, SaaS security platforms, and so forth.

Who needs CSAM? Any organization that has more than a handful of digital assets is a good candidate for CSAM, though larger entities, especially ones that are growing in the cloud, are definitely in need. Companies that need to comply with the US Federal Information Security Modernization Act of 2002 (FISMA) will find CSAM helpful, if not essential, in complying with FISMA’s required inventory tracking and ongoing authorization processes.

Why is Cybersecurity Asset Management (CSAM) Important?

CSAM is a worthwhile framework to adopt. In addition to facilitating FISMA compliance, CSAM offers a number of compelling benefits in terms of security, IT management, and business. Security advantages from CSAM start with the framework’s ability to bolster security posture. Assuming it’s hard to defend what you can’t see, CSAM solves this problem by giving you improved visibility of all your digital assets. You have a better chance of enforcing security policies and keeping assets up to date, e.g., through patching, if you know what you have.

Operational efficiency is a further security benefit from CSAM. Security departments are chronically under-staffed and under-resourced. By automating asset discovery and security status tracking, CSAM makes the SecOps process more efficient. Security analysts will spend less time figuring out which systems are affected by a breach, for example. Incident response improves as a result. They’ll be more on top of patch management. Audits also become easier and less time consuming to conduct.

CSAM helps you detect shadow IT and shadow SaaS, as well. If employees are setting up SaaS apps without permission, a CSAM solution or SaaS security platform with CSAM capabilities will find them and flag them.

Businesswise, CSAM contributes to operational efficiency and potential cost savings. When IT managers can easily view a complete inventory of digital assets, they will be better able to negotiate licensing deals and hardware procurement with vendors. This benefit gets at the link between CSAM and IT asset management (ITAM), which deals with the financial side of IT assets.

How to Optimize Your Cybersecurity Asset Management Strategy

Best practices are emerging that help you optimize your cybersecurity asset management strategy. Most have to do with connecting CSAM with other systems and aligning with security frameworks. Highlights include:

Take an End-to-End Perspective, but Base Prioritization on Risk

Success with CSAM involves balancing a broad overview of CSAM with a risk-based prioritization. Ideally, CSAM will inventory all assets on a real-time basis. However, it is a good practice to allocate resources to assets that represent high-impact risk exposure.

For example, you’ll want to know about every mobile device your company owns. It’s smart, though, to reserve in-depth tracking of security configurations, identify known vulnerabilities, and manage patches for assets whose compromise could cause a major security incident. Some refer to this as risk-based asset classification. A database with sensitive information would be a good example of such an asset. Additionally, it’s wise to think outside of your organization when you define your digital assets. The cloud enables wide-ranging and flexible connections that can create cybersecurity assets out of thin air. For instance, a partner’s API may not officially be a digital asset you own, but it’s an asset that can affect your security. It’s a good idea to inventory it and track its security status.

Integrate CSAM Across Your Security Stack and SecOps

A CSAM solution has to integrate across the security stack and SecOps if it is to deliver on its potential for strong security posture. Its asset inventory feeds into other security tools. A vulnerability management system, for example, should match vulnerabilities with assets. If there’s a known vulnerability in a certain Linux kernel, then knowing where that kernel is operating will help you fix the problem precisely and completely. CSAM can also integrate with SIEMs, with the result that you can match log anomalies with specific assets.

Integrate CSAM with Your Configuration Management Databases (CMDB) 

CSAM and configuration management databases (CMDBs) go together. Most assets require configuration, so it makes sense to match up asset inventory with configuration data. Configuration tracking is certainly essential for SaaS security. Suridata, for example, enables you to monitor security configurations for all of your SaaS apps. It will flag insecure configurations for remediation.

Automate Everywhere You Can

CSAM works best with automation. The more you can automate its processes, the more benefit you’ll get from the framework. For example, it pays to automate policy enforcement and track enforcement status according to your asset inventory. Like, if you want strong passwords on all databases containing personal identifiable information (PII), then ideally you will have an automated process to keep track of whether that policy is being enforced on all such databases.

Automation can also be a big help if your organization has to comply with NIST framework. Otherwise, compliance can be a time-consuming resource drain that’s hard to audit. Automated CSAM expedites the process. The same goes for development of system security plans (SSPs) and plan of action and milestone (POA&M) management, both of which feature in government compliance regimens.

Making CSAM Work

Asset sprawl is a real problem, one that’s getting worse as enterprises embrace AI, SaaS, and the cloud. CSAM offers a way to get ahead of the security risks exposed by asset sprawl and the inevitable gaps in visibility that come with it. CSAM provides a range of benefits, including a better security posture, improved incident response, and stronger regulatory compliance. A CSAM solution does not work optimally on its own, however. It does best when integrated with the security stack and SecOps. Automation is essential for success, as well. Done right, CSAM makes the jobs of IT, security, and compliance teams easier while enabling them to be more effective.

To learn about Suridata’s SaaS asset tracking and configuration monitoring solutions, visit our website or book a demo.

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.

If you hang around the IT world long enough, you’ll hear someone say, “This is not your father’s firewall” or router, or server… We have to update this idea for today’s dizzying rate of change in technology and cybersecurity. Now, it would be more like, “This is not your twin brother’s firewall.” Security managers face pressure to adapt quickly as big changes like remote work and the widespread embrace of SaaS force changes in security policy and strategy. This is the problem that adaptive security seeks to solve.

Adaptive security, as its name suggests, is an approach to cybersecurity that dynamically predicts threats and rapidly adapts to them—enabling better security outcomes by making threat prevention and incident response more able to handle the latest modes of attack. The security sector is responding favorably to the idea of adaptive security. One industry study, for example, predicts that the market for adaptive security products will reach $27 billion by 2029.

An Adaptive Security Platform (ASP) delivers adaptive security functionality. It uses real-time monitoring and analysis to adjust security policies and enforcement automatically in response to evolving threats. This article discusses how ASPs work. It examines why an Adaptive Security Platform is a wise investment and what makes for an effective solution.

What is Adaptive Security?

Adaptive security is, first and foremost, an approach to security. It’s not a product, per se. Rather, it’s a model, an architecture, and a set of ideas that ASPs bring to life. “Adaptive” is the key word here. An ASP helps the security operations center (SOC) adapt quickly to the newest threats. It achieves this goal by automatically and continuously monitoring user behavior and other activities across the entire attack surface, uncovering vulnerabilities, anomalies, and malicious traffic.

The ASP’s real time monitoring and user behavioral analytics enables the SOC to stop threats from becoming attacks. Getting there may involve predictive analytics and root cause analysis. The ASP then informs policy definition and enforcement, along with the nature of your countermeasures, so your security toolset can adapt continuously to newly perceived threats.

Adaptive security is a necessary evolution away from traditional approaches to security. It’s not as simple as a “before vs. after” story, but adaptive security imbues security with greater flexibility and dynamism than was previously available. The old approach to security focused on perimeter defenses, signature-based threat detection, and a generally siloed “small picture” view of the security landscape, e.g., data security, email security, network security, and so forth, instead of an overall risk mitigation strategy.

Many organizations have pursued adaptive modes of security even if they have not implemented an ASP or fully embraced the adaptive security approach. Companies that deploy endpoint detection and response (EDR) solutions, for instance, are taking an adaptive approach to endpoint security.

What Is an Adaptive Security Platform and Why Do You Need One?

An adaptive security platform operationalizes the four core elements of an adaptive security strategy:

• Predict—Assessing and prioritizing risk exposure, driving changes in security posture by anticipating attacks across the full IT estate, including the cloud and software-as-a-service (SaaS) applications.
• Prevent—Dynamically defining and enforcing security policies that harden and isolate systems, preventing attacks in the process.
• Detect—Continuously monitoring users, systems, system activity, payloads, and network traffic to discover threats, incipient attacks, and attacks in progress.
• Respond—Containing and quickly remediating security incidents.

These four elements reinforce each other and operate in a mode of continuous updating and evolution. Data from prediction informs prevention, which informs detection, and so forth.

Why would you need an ASP? The main reason is that cybersecurity teams have had to adapt to rapid and simultaneous changes in the threat environment, business strategy, and employee behaviors. Consider that businesses started pursuing digital transformation strategies just as almost everyone was forced to work from home during COVID. At the same time, a great deal of IT moved off premises and into the cloud and SaaS environments.

While these changes were affecting security policies and operations, malicious actors have been busy coming up with increasingly dangerous and sophisticated threats. These include zero days, advanced persistent threats (APTs), and spear phishing, among many others. It’s been a difficult collection of forces to confront.

Just as businesses were changing the way they operated and freeing employees to work from home on personal devices, security teams were contending with a flood of serious threat vectors. This translates into a variety of novel risk scenarios. An employee accessing a SaaS app on a personal device through a home internet connection, for example, has the potential to put sensitive data at risk without anyone knowing about it. In this environment, an ASP starts to become mandatory.

An ASP mitigates risk as it enables the kind of digital agility businesses need to remain competitive. Other benefits include improved security outcomes through real time threat detection, a reduction in the attack surface, and a better user experience. Cyber defense can become proactive, versus reactive.

How to Select an Adaptive Security Platform for Your Needs

What should you pay attention to when selecting an adaptive security platform? There’s a lot to do here because adaptive security, by its nature, encompasses the complete spectrum of issues that arise in cybersecurity and digital business strategy. Here are seven steps to consider when selecting an ASP.

# 1—Consider Your Needs and Environment
What do you need from an ASP? An informed procurement decision needs to come from a careful assessment of your IT estate. This should include your on-premises digital assets and infrastructure, but also your cloud environments, SaaS apps, and third-party connections, e.g., API-based integrations with external companies. And, you should factor in how your end users expect to interact with the IT estate, and where they work. From this assessment emerges a total picture of what you have to defend. That’s your maximum ASP footprint.

Then, look at your threat landscape. What are the most serious threats you face? And, which of your assets need the most protection? If the maximum ASP footprint represents the most extensive deployment of the ASP, the threat assessment should narrow the scope so you can deploy the platform in the most impactful way possible.

At the same time, it’s a good idea to think through your overall business plans and examine how they affect your conception of an ASP. For example, if you’re on the verge of abolishing bring-your-own-device (BYOD) or work-from-home policies, that should change your plans for ASP implementation. Similarly, if you’re planning to phase in a big digital transformation that spreads your data across multiple cloud and SaaS instances, as well as third party kiosks and retail stores, that again should influence how you’re thinking about an ASP.

#2—Align with What You Already Have
It’s likely that you already have some elements of adaptive security at work in your environment. If you’re using an extended detection and response (XDR) solution, for instance, you may find that it is providing an adaptive security methodology to the areas of your IT estate that it covers. You may decide to phase out XDR and replace it with an ASP, but it might be smart to leave it alone and modify your ASP deployment instead.

#3—Maintain a Policy and Organizational Focus
An ASP must be a manifestation of security strategies and policies that fit within a specific organization context. It creates an adaptive security capability in service of security policies. Its functions and outputs will be relevant to people in distinct areas of the organization, such as the SOC or the compliance department. It’s a good idea to think through the policies and organizational aspects of the ASP when you’re evaluating your options.

#4—Pay Attention to Unintended Consequences
An ASP, like any broad-scoped and complex piece of technology, has the potential to create unintended consequences. For instance, will it create integrations that you will then have to support? If it requires the deployment of software agents, will those affect performance or create support headaches? Remember, too, that any platform you deploy will require at least one person (or partial person) to administer.

#5—Match Platform Capabilities to Your Requirements
With all of these factors in focus, you can now turn the platform’s actual capabilities. Evaluate how well the ASP succeeds or falls short on multiple fronts, including:

• Data protection mechanisms—How well does the ASP cover data assets? Like, does it continuously monitor data access requests and detect anomalous activities in databases?   
• API security—APIs represent a significant attack surface, one that can let malicious actors directly into your most sensitive digital assets. For this reason, an ASP’s API security capabilities, e.g., the ability to monitor API behavior or integrate with API security solutions, should have a high priority in selecting an ASP.
• User and Entity Behavior Analytics (UEBA)—Anomalous end user behavior can signify the start of a cyberattack, so UEBA functionality, or the ability to integrate with a UEBA solution, is important in an ASP.
• Support for Zero Trust Architecture (ZTA)—If you’re like many organizations, you are probably embarking on a ZTA project, or have already done one. An ASP should be able to monitor network access requests, device verifications, and other elements of a ZTA.
• SIEM and SOAR integration—An ASP must be able to ingest data from security incident and event management (SIEM) systems. That’s part of the ASP’s continuous monitoring function. As incidents occur, the ASP must then integrate with a security orchestration and automated response (SOAR) solution so it can influence the incident response process.
• Logging, reporting, and forensics—The right ASP will provide you with rich logging and reporting outputs. You will need this information, along with forensics on security incidents, to realize the technology’s potential for continuous adaptation.
• SaaS security—SaaS apps represent a potentially dangerous blind spot for security managers. Often holding sensitive data, they may operate outside the view of traditional security monitoring tools. An ASP will ideally support SaaS security or integrate with a SaaS security platform. Suridata, for example, takes the principles of an ASP and applies them to securing SaaS applications. It helps organizations adapt their security measures to the dynamic nature of cloud-based software and the ever-evolving threat landscape in the SaaS world. Specifically, Suridata can perform dynamic risk assessment across the multi-app SaaS environment, monitor user behavior and third-party integrations, and check security configurations.

#6—Evaluate the Scalability of Security Policies 
The ASP has to scale your security policies as your IT estate grows and changes in accordance with shifts in business strategy. It cannot be rigid, and this is, believe it or not, a problem with some ASPs. It has to be highly adaptable to change.

#7—Analyze the ML and AI Capabilities 
An ASP will have some artificial intelligence (AI) and machine learning (ML) capabilities. The question to ask, though, is how they work. AI and ML should not be a “black box.” Rather, you should understand how they “train,” the functional areas of the ASP they affect, and so forth.

Getting to Adaptive Security

Adaptive security is necessary today because the combination of increasingly agile business strategies and serious cyberthreats are making traditional forms of cybersecurity less effective at protecting digital assets. An ASP continuously monitors the cybersecurity environment and enables it to adapt rapidly to changes in threats and the IT estate.

The shift to cloud computing and SaaS may require the use of solutions like Suridata. It offers the adaptability enterprises need as their SaaS environments expand.

To learn more, visit https://suridata.ai or the company’s demo page.

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. 

Admit it: You’ve recently worried about your hair on a Microsoft Teams call. As one of the world’s most widely used collaboration tools, Teams is an essential platform for organizations worldwide. However, it is also a prime target for hackers who see it as a gateway into corporate networks, file repositories, and even a launchpad for impersonation and fraud. 

The risks have only grown over the past few years. Microsoft is doing its part in tackling growing threats by blocking an average of 4,000 identity authentication attack attempts per second on Teams. Still, this app’s security has to be a joint effort. As a SaaS product, Teams operates under a shared security model where customers must also play a role in defense. 

Explaining the Microsoft Teams Vulnerability

Microsoft Teams is an incredibly multifaceted platform. In addition to the standard voice and video functionalities, it offers project management, collaboration workflows, and integrations with the broader Microsoft ecosystem (think Outlook, Office, SharePoint, and Active Directory). Together, Teams and their integrated parts form a broad external attack surface. 

Microsoft Teams vulnerabilities generally fall into two categories. The first allows attackers to bypass security controls and send files to external tenants—TeamPhisher is one example of this type of attack. 

The second type concerns security managers and involves phishing schemes to impersonate executives. For example, an attacker could pose as the Chief Financial Officer to trick employees into wiring funds to fraudulent accounts. 

Since users often perceive Teams as an internal-only tool, they may assume that all contacts are legitimate employees, amplifying the risk of social engineering attacks. This implicit trust within Teams is what makes exploits like TeamPhisher particularly dangerous.

Source

The Impact of Microsoft Teams Vulnerabilities for Businesses

Attackers who can gain access to Teams have the potential to carry out a wide range of destructive acts, including:

• Malicious Code Execution—Attackers can exploit the insider network access provided by penetrating Teams. For instance, they could mount malicious code execution attacks, injecting code into a system to disrupt it or extract sensitive information. 
• Data Breaches and Information Theft—Because Teams users are generally assumed to be authorized insiders, an attacker posing as a Teams user can access data and files from the inside. They may steal sensitive information, intellectual property, and information about other Teams users.
• Social engineering Attacks—When attackers access users’ personal information, they can use it to power more targeted and convincing phishing and social engineering attacks. By learning details like an employee’s pet’s name, they can impersonate someone from their inner circle, making the deception more believable.
• Exploitation of Privileged Accounts—An attacker who takes over a Teams account can exploit the victim’s access privileges. For instance, if the victim is an accountant, the attacker might be able to see financial reports stored in Teams. They can also escalate their privileges by contacting the IT department using Teams.
• Installation of Malware or Spyware—Bad actors can upload malware-laden files into Teams file repositories. These might include ransomware or spyware.   

Source

6 Precautions You Need to Take to Mitigate the Microsoft Teams Vulnerability

So, what can you do about the Microsoft Teams vulnerability? One thing to remember is that Microsoft itself shoulders a significant burden here. They are on task to identify vulnerabilities and constantly update the SaaS software. Microsoft also issues guidance on mitigating Teams risk. With TeamsPhisher, for example, the company advised Teams administrators to review settings and take actions that make it harder for an attacker to exploit the vulnerability. 

However, you must take some responsibility, too. Here are six actions you can take to secure your Teams platform:

1. Restricting External Access to Protect Shared Channels

Limit external access by adjusting settings in the Teams Admin Center. Start by blocking users from inviting external participants to shared channels, as these guests can read and write messages, creating a potential entry point for malicious actors. 

Review and manage Teams’ external access settings for broader collaboration needs. If external access is required, restrict it to specific, trusted domains. Otherwise, set Teams to “Block all external domains” to prevent unauthorized access entirely. 

You can also configure Teams so that unmanaged external users cannot initiate conversations with users in your organization. This control can reduce phishing attempts and unauthorized access.

2. Regularly Review User Permissions and Related Workflows

Companies like Teams because it enables seamless collaboration between employees, vendors, and contractors, but this openness also introduces significant security risks. A critical best practice for safeguarding access is to review user permissions regularly. For example, you may find that a freelancer who is no longer employed still has access to sensitive resources. Equally important is scrutinizing the workflow for granting and revoking access. Security lapses often occur when removing access from external users is overlooked or forgotten.

Source

3. Train and Educate Users on Teams Security 

Due to its collaborative features and file-sharing capabilities, Microsoft Teams is especially vulnerable to human error. A comprehensive training program can improve security by teaching employees safe data-sharing practices, spotting phishing attempts, and recognizing signs of compromise. Training should also include practical SaaS security steps, such as verifying unknown contacts before sharing sensitive information, reporting suspicious activity to IT, regularly updating passwords, and adjusting privacy settings to control external access. 

4. Implement Conditional Access Policies

Limiting access to users who meet specified conditions, such as complying with MFA, helps reduce the probability that a malicious actor will penetrate Teams. Alternatively, conditional access policies can restrict the digital assets a user can access once he has gotten into Teams. He may not be permitted anywhere else on the network, which is good for reducing the risk of lateral movement.

Source

5. Monitor and Audit Teams Activity

Teams’ vulnerabilities and exposure to social engineering make monitoring and auditing user activity crucial. Suspicious behaviors (like sending the same file to many users across different departments) can signal a potential attack. Blocking such actions until further investigation can help mitigate risks.

Another effective measure is deploying Data Loss Prevention (DLP) tools. These tools track file transfers and other sensitive actions, providing real-time alerts when a data breach is detected, enabling swift intervention before damage occurs.

6. Monitor and Control Teams Integrations

Teams integrates extensively with the Microsoft ecosystem and various third-party enterprise applications. While this enhances productivity and streamlines business operations, it also increases the potential for security risks. Unmonitored integrations and insecure third-party plugins can open the door to vendor-related risks. 

Monitoring tools like Suridata can help you mitigate these risks. These tools can continuously assess SaaS integrations for security gaps, flagging potentially unsafe third-party plug-ins and identifying other risk factors. Regularly reviewing and controlling these integrations ensures that only secure and necessary connections remain active, minimizing exposure to security breaches.

Getting the Team on the Same Page for Teams Security

There are no two ways about it—the Teams platform is vulnerable. From phishing attacks to exploits that enable unauthorized external access to Teams, the application exposes organizations to risk. However, it is possible to improve security for Teams if you take certain precautions, such as implementing conditional access rules, deploying DLP, monitoring integrations and activity for anomalies, and enforcing training. 

If you want to fast-track and automate the security of your Teams platform – you should employ a specialized solution. SaaS security platforms like Suridata can monitor Teams user activity and inspect third-party integrations and configurations—flagging suspicious situations instantly and alerting security teams to remediate. Learn more here. 

The rush to adopt new security paradigms often overshadows cybersecurity essentials. While we’re all jazzed about implementing a cool new software-as-a-service (SaaS) strategy, “doing” SASE or zero trust, we may overlook or lose sight of security controls, which are the foundation of security posture. 

49% of CISOs worry they lack a clear picture of their organization’s vulnerabilities. This lack of visibility is especially true in complex SaaS environments, where it can be challenging to verify control effectiveness. 

Controls only count if they work, and regular SCAs are crucial to ensuring they do. A Security Controls Assessment (SCA) helps by testing and confirming that they are working as intended. 

What is a Security Controls Assessment (SCA)?

In cybersecurity, a security control typically combines policy, process, and technology to realize a control objective. For instance, if the aim is to prevent non-employees from accessing a SaaS application, an effective control could enforce a policy that requires SaaS users to have a valid employee ID number. This objective is then connected to a control activity, which might involve an automated check to verify each user’s ID against an employee database before granting access.

A Security Controls Assessment (SCA) evaluates whether security controls work as intended to meet specific objectives. For example, if you aim to ensure that “vulnerabilities in assets are identified, validated, and recorded” (per the NIST CSF Risk Assessment RA-01), you might rely on a vulnerability management tool as a control activity to identify unpatched software.

Conducting an SCA for this control would reveal whether these tools effectively identify vulnerabilities, such as unpatched software, as intended. SCA is particularly relevant for SaaS, where misconfigurations in SaaS apps can cause significant risk exposure. 

Source

Why Do You Need a Security Controls Assessment (SCA)?

There are other ways of assessing controls, such as “red teaming” and penetration testing. These methods are effective but tend to be comparatively costly and intermittent. Controls, however, may change over time, and a periodic red teaming exercise could leave a problem undetected for months. This issue can be particularly acute in a SaaS environment, where SaaS providers frequently update their code, and changes may cause security settings to shift without being detected.

An SCA offers a more thorough, proactive, and consistent approach to testing controls. SCAs can cover any control type and  work across the significant domains of cybersecurity, including: 

• Application security– evaluating API security practices or assessing how well code scanning controls detect malware in open-source software libraries.
• Data security– verifying data encryption protocols.
• Identity and access management (IAM)– assessing access controls.
• Incident response– examining and testing incident response plans and workflows.
• SaaS security– determining whether SaaS solutions can detect unauthorized “shadow SaaS” instances.
• Infrastructure security– detecting configuration flaws or inspecting patch management processes.

SCAs also support regulatory compliance. Regulations like HIPAA, which mandates access controls for health records, or SOX, which requires separation of duties, rely on adequate security controls. For example, the U.S. Center for Medicare and Medicaid Services requires businesses it interacts with to perform SCAs as part of its “Acceptable Risk Safeguards” policy. 

Source

How to Perform a Security Controls Assessment (SCA)

How you perform an SCA will depend on the size and nature of your organization, but here are some common steps that should apply to all:

1. Define the SCA’s Scope and Objectives

Select a group of controls you can assess thoroughly and accurately. One way to determine the target controls for the SCA is to work from an existing control framework, such as NIST CSF, ISO 27002, or CIS Critical Security Controls. You can also base your choices on compliance, such as selecting the SOX IT General Controls (ITGCs) or application controls (ITACs). 

Another proven approach is to start by inventorying your most valuable information assets. Which systems are critical for your business? What data is the most important to defend? Some of these may be located in the cloud, on SaaS apps, or in places you know nothing about until you do an automated data discovery scan.  With that inventory, you can look for the controls that protect those assets. 

Some refer to this as the control’s “heatmap.” It guides you to the controls that matter most to your security posture and overall risk management goals. 

2. Determine the Organizational Aspects of the SCA

An SCA doesn’t operate in isolation; it requires clear ownership and defined responsibilities. In larger organizations, a full-time role may be dedicated to SCA, but more often, it’s a shared responsibility among individuals with other duties.

Successful SCA implementation may involve several “dotted line” relationships among teams and individuals contributing to the process. To avoid confusion, everyone involved should clearly understand their roles, and any contractors or consultants should be aware of project expectations. Managers play a crucial role by ensuring team members have the flexibility in their schedules to prioritize SCA-related tasks effectively.

3. Select Your SCA Tooling

You can find SCA solutions that handle many of the control assessments you need to make. These tools simulate attacks, often using the latest threat intelligence and a high degree of automation. They may also combine static testing (SAST) and dynamic testing (DAST) to cover a breadth of controls and threats. However, testing SaaS controls requires a specialized SaaS security solution like Suridata, which can continuously monitor controls affecting SaaS configuration and shadow SaaS. 

Source

4. Gather Information on Controls

This step may occur earlier in the process, but collecting information on each control you want to assess (including its objective and activity) is crucial. Some of this may already exist in control documentation, but you’d be surprised how bare that cupboard can be sometimes. It’s up to you to ensure you’re testing the control against its objective. Otherwise, how would you know if it’s working right?

5. Test the Controls and Perform Vulnerability Assessment

Now comes the actual testing and assessment. This process may require evaluating the vulnerabilities and threats affecting the control’s effectiveness. The SCA solution and other technologies employed for the SCA generate significant amounts of data in this stage. If your SCA involves SaaS, you may require a separate platform for SaaS security, feeding into the SCA dataset. You have to analyze that data or configure the SCA solution to demonstrate how well or deficiently the control functions. 

Source

6. Controls Documentation Review and Updating

With SCA data, you must report your findings and explain which controls were adequate or deficient. It is crucial to update controls’ documentation as part of this process. For example, you may discover that an existing control activity relies on an integration that is no longer supported. It should be replaced by one that will enable the control activity. 

7. Remediate Issues

The SCA process typically involves either remediating deficient controls directly or assigning those tasks to a dedicated team. Ideally, the SCA solution can automate remediation tasks; for instance, Suridata automates the shutdown of insecure third-party SaaS integration plugins.

You should also assess incident response capabilities where relevant. For example, suppose a data security control mandates removing sensitive data from SaaS applications. In that case, the SCA should verify that this removal happens quickly, reliably, and in a fully auditable way.

The SCA process is never truly “finished.” The critical question is how frequently you will repeat the assessment. Sometimes, an SCA tool may run continuously, ensuring constant oversight. Regardless of how often you perform SCA, continuous improvement should be a guiding principle, with each evaluation followed by discussions on enhancing control effectiveness and refining the SCA process.

Getting Ready to Hit “Go” on SCA

SCAs may seem overwhelmingly complex if you’ve never done one before. These assessments do take effort, but the good news is that once you’ve done your first SCA, the next time gets much easier. Success relies on identifying your most important controls and finding the proper SCA tooling, so the process is as automated as possible. 

For new control areas, like the cloud and SaaS, the answer may come from purpose-built SaaS security solutions like Suridata. These solutions can help you automate many of the SCA steps and provide clear guidance and information on the state of your SaaS controls.  Learn more here.

---