Author: Haviv Ohayon

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. 

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.

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.

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.

---

Where would Hollywood thrillers be without the hero stealing an ID card and walking right past the bad guys to save the day? In real life, though, it’s the bad guy who breezes past security with a stolen ID. When a hacker can impersonate a legitimate user, they can bypass all robust (and expensive) countermeasures. 

Hackers’ abuse of valid accounts shot up by 71% from 2022 to 2023, with stolen user identities comprising 30% of initial access vectors. Plus, data breaches arising from compromised credentials took 190% more resources to remediate than other forms of attack. Based on these findings, the need for identity threat detection and response (ITDR) to mitigate identity risks proactively is clear and compelling. 

What is ITDR (Identity Threat Detection and Response)?

Identity Threat Detection and Response (ITDR) is a security discipline that protects digital assets from identity-based attacks. It combines processes, tools, and best practices to detect and respond to user identity threats and support identity infrastructure.

ITDR goes beyond the functionality of traditional identity and access management (IAM) solutions. IAM and privileged access management (PAM) keep track of user identities and provide user authentication. IAM products provision and de-provision identities but do not monitor activities or flag suspicious cases. 

Similarly, while security incident and event management (SIEM) solutions monitor multiple systems for evidence of attacks, most SIEMs are not configured to catch identity-specific threats. 

SaaS applications are an excellent fit for ITDR, as their remote user bases and shared security model make them more vulnerable to identity-based attacks. Vulnerability misconfigurations and inconsistent integration with IAM solutions add to SaaS security risks. 

Source

Why is ITDR Crucial for InfoSec Professionals?

Information security (InfoSec) professionals should become familiar with ITDR because of the rise in identity-based attacks like phishing, credential stuffing, and privilege escalation. As remote work and outsourcing become more common, organizations are increasingly susceptible to these attacks. Additionally, corporate login credentials are often found on the dark web, making user impersonation easier. 

ITDR is also essential due to the rise in attacks on identity infrastructure. Attackers who compromise IAM solutions like Azure AD can access systems undetected and appear as regular users. Using legitimate credentials doesn’t attract much attention from security operations centers (SOC) and avoids triggering alerts. ITDR solutions help detect the subtle signs of these identity-based attacks.

Standard IAM and PAM solutions do not help in this context. Consider social engineering attacks like “MFA bombing” or “MFA fatigue,” where attackers send repeated MFA push notifications to a user’s device. Confused, some users may approve one MFA request and accidentally grant access to attackers. This tactic bypasses typical IAM defenses, but ITDR may help. ITDR tools identify unusual login behavior and take action, such as blocking access and initiating remediation.

Source

Key Components of an Effective ITDR Strategy

What does it take to build an effective ITDR strategy? While an ITDR solution is essential, more is needed to achieve success. For the solution to be effective, it must support these core components of an ITDR strategy:

• Identity Monitoring—Who’s who in your organization, and who can do what? The answers to these two fundamental questions can reveal various identity risks. For example, you may have unmanaged identities in your Workday application that exist outside of IAM and are a source of risk. ITDR monitors all identity activity to flag suspicious activities by such accounts. 
• Threat Detection—Identity-based threats include a wide range of attacks, from spear phishing to “pass the hash” password thefts. You need to configure ITDR to detect as many such threats as possible, including threats outside your domain (think looking for stolen cloud access tokens on the dark web). 
• Contextual Analysis—Spotting an identity-based attack requires a deep understanding of context, as attacks may resemble regular business activities. An ITDR solution can detect contextual anomalies, such as off-hours log-ins or unexpected privilege escalations, and begin remediation.
• Automated Incident Response—An identity-based attacker can quickly do much damage, so a nearly instant response should follow detection. For this to work, you need an automated workflow for incident response.

5 Steps to Implement ITDR in Your Organization

1. Assess Current IAM Posture to Identify Gaps

Effective ITDR begins with understanding your current identity and access management (IAM) state. Identity-based attacks often exploit gaps, particularly between IAM and PAM solutions. For instance, users may retain unnecessary administrative privileges from temporary provisions, like system reinstalls. Weaknesses in MFA or password policies can also increase identity risks. By evaluating your existing IAM, PAM, MFA, and SSO solutions, you can identify and close these security gaps with ITDR.

2. Choose the Right Tools 

Implementing ITDR means acquiring and deploying an ITDR solution. Many robust options are on the market, some focusing on verifying identities while others specialize in monitoring user activity. 

Look for an ITDR solution to execute your ITDR strategy across all relevant computing environments. Identity attacks can occur in on-premises systems, the cloud, and its various incarnations, including public and private clouds, infrastructure-as-a-service (IaaS), platform-as-a-service (PaaS), and SaaS. 

One of the challenges of defending against identity-based attacks in SaaS is the breadth of SaaS apps in the average enterprise. A robust ITDR solution for SaaS security, such as Suridata, will be able to monitor user behavior in most SaaS apps.

Source

3. Define and Configure Detection Rules

Once you have your ITDR tool, you must define what threats you want this solution to detect and set up its rules. The specifics will depend on your environment and industry, but it’s usually good practice to focus on the most sensitive digital assets first. Consider where you face identity risk in those assets. 

For example, in the manufacturing industry, identity risks may involve unauthorized access to material informatics systems that manage material specifications and supply chains. Your detection rule could be, “Monitor user accounts and flag any accounts with elevated permissions that are not regularly reviewed.” You would then set up your ITDR solution to enforce this rule.

4. Integrate with Incident Response frameworks

ITDR will not be a standalone system in your security operations. Instead, it must integrate with your team’s incident response frameworks in the security operations center. This integration might involve feeding alerts from ITDR into SIEMs or security orchestration and automation and response (SOAR) solutions. This way, if ITDR picks up on a possible identity-based attack, it can initiate automated remediation. ITDR can also initiate response workflows to alert SOC analysts and key stakeholders. This capability is crucial if the identity attack is part of a more significant threat, such as ransomware.

5. Regularly Audit and Test Controls

Users’ identity profiles and system deployments change frequently. Within months of implementing an ITDR solution, you may need more coverage for new applications and administrative privileges. Without frequent updates, ITDR controls can quickly become outdated and redundant. Regular auditing and testing of ITDR controls is essential to prevent gaps in your defense against identity-based attacks.

Source

Making ITDR Work For Your Organization

Identity is a significant cyberattack vector. ITDR offers a countermeasure by detecting identity-based attacks and responding quickly and effectively, often through automated processes.

While the ITDR strategy blends process, policy, and tooling, your choice of ITDR solution is essential for success. The right solution will enable your team to discover gaps in IAM and PAM, among other identity risk factors, and integrate seamlessly with incident response workflows. An ITDR solution should mitigate risk in all environments, including the cloud and SaaS. 

ITDR is especially important in SaaS, given these technologies’ remote, third-party nature. As an end-to-end SaaS security solution, Suridata offers comprehensive ITDR capabilities, including real-time detection, response, and protection against SaaS vulnerabilities across any of your SaaS applications. Learn more about how Suridata can protect your SaaS environment from identity-based threats. 

---

John logged into your company’s SaaS-based accounting app late last night and downloaded your customer list. There’s just one problem: John moved from Accounting to Marketing six months ago. But because you provisioned John’s SaaS access one app at a time, no one thought to change his permissions when he moved departments. This SaaS security risk is more common and dangerous than you might think. 

26% of companies that reported a SaaS security incident were attacked by an insider. The picture looks even more threatening when you factor in additional security challenges like SaaS sprawl and shadow IT. Role-Based Access Control (RBAC) is one solution that will bring greater access and privilege management control in the SaaS environment.

Understanding Role-Based Access Control (RBAC)

Role-based access Control (RBAC) provides access to networks and systems based on a user’s role rather than their identity. Without RBAC, system admins must provide access and privilege levels for one user at a time. 

Imagine manually assigning access permissions for every tool to each employee in your company. This process would be painfully time-consuming and error-prone, significantly hindering your SaaS security efforts. Under RBAC, admins could set access controls so only users with a specific role can access a particular system.

Aside from RBAC, there are three other access control methods: Mandatory Access Control (MAC), which leverages centralized access policies; Discretionary Access Control (DAC), which gives any resource owner the flexibility to grant permissions; and Attribute-Based Access Control (ABAC), which makes access decisions based on attributes like location and time.  

Source 

The Critical Components of Role-Based Access Control (RBAC)

RBAC operates through three key components: roles, permissions, and users. Roles typically align with an organization’s structure, often based on departments or hierarchy. For example, in Salesforce security, an “Executive” role might be able to view all sales reps’ deals, while a “Sales Rep” role would limit access to only the deals of the individual rep. 

This example illustrates how roles are tied to specific permissions. For instance, an “Admin” role may grant access to a system’s administrative back end, while a “Super Admin” role offers even deeper access. This structure is known as a “role hierarchy.”

Role-Based Access Control in SaaS Security: What are the Benefits? 

• Higher efficiency—With RBAC, admins can more efficiently provision access and privileges at a granular level. For example, it’s faster and simpler to grant everyone with the “Sales Rep/California” role access to accounts in California versus assigning that access to each sales rep in California individually. 
• Enhanced SaaS security—With RBAC, it is less likely for a user to have excessive privileges, reducing the risk of unauthorized SaaS application access and data breaches
• Simplified Identity and Access Management (IAM)—RBAC streamlines granting or revoking user access as employees join the company and change roles.
• Scalability—By grouping access rights and privileges by role, RBAC makes it easier to scale and apply access control to your organization’s growing portfolio of SaaS apps. 
• Improved compliance—Some regulations and industry compliance frameworks require reporting and audits on user access rights. RBAC makes these processes more manageable.

RBAC in SaaS Security: Challenges and Solutions 

RBAC can be challenging to implement in SaaS security. For starters, most SaaS apps already have their own built-in RBAC settings. For instance, the Salesforce Security Model enables users to define roles, profiles, and permission sets.

While that’s beneficial, you can’t custom-configure roles in dozens of SaaS apps. You must also align access changes with IAM systems and protocols, ensuring you follow your organizational security procedures. On top of that, your customization levels depend on the vendor’s features and differ from app to app.  

For example, if you assign Ethan the “Business Analyst” role in Salesforce, they will not be a “Business Analyst” in any other SaaS apps. Access needs change over time, so realistically, you’ll never keep up with it on an app-by-app basis. Additionally, you will have difficulty monitoring RBAC if you have separate role settings on each of your SaaS apps.

Source

How to Implement Role-Based Access Control in SaaS Applications

To make RBAC work as a factor in driving better outcomes for SaaS security, you need a solution that deploys RBAC across multiple SaaS apps. SaaS security solutions like Suridata facilitate this functionality. They integrate with IAM, enabling you to restrict access across the whole SaaS environment. This also means a change in role access rights in the central IAM/SaaS security solution applies to every SaaS app. This process sounds simple, but there are a few other steps required to implement RBAC in SaaS: 

1. Identifying Roles and Permissions

Before you integrate IAM with SaaS for RBAC, it is essential to think through how your RBAC policies will apply to SaaS. You have a head start if you already have RBAC for your on-premises applications. However, you must still figure out who is who and who needs access to what data and SaaS functionality.  

The “who can do what” chart will inevitably relate to organizational structures and compliance requirements. For instance, regulations may require the company to audit and report on access privileges for people in the finance department, so the IAM-RBAC mapping for SaaS must consider this. 

Implementing IAM-RBAC for dozens of SaaS apps simultaneously is not practical. Hence, a prioritized “heat map” that organizes SaaS apps based on their risk levels and criticality can help you know where to start. You can also download a risk assessment template for SaaS to ensure you review your apps across every essential factor. 

Source

2. Reviewing Your Vendors’ RBAC Capabilities 

Third parties are aware of the vendor-related risks they may bring to your organization, so they often provide crucial security tools to help you protect your systems from external threats. It may turn out that your highest-priority SaaS apps already have the RBAC capabilities you need built-in. 

These capabilities can give you extra time while you plan a more complete IAM-RBAC-SaaS integration. You may need to customize the app’s RBAC settings to fit your needs, but you’ll still avoid the full complexity of integrating IAM with SaaS. However, it’s essential to continuously monitor the built-in RBAC features to catch any potential issues with user access.

3. Implementing Single Sign-on (SSO) Integration

By setting up SSO, your users only have to log in once and can then access all IAM-RBAC integrated SaaS apps per RBAC policy. This setup helps with productivity and user experience.

Source

4. Integrating with External SaaS Security PM and IAM Solutions

To implement RBAC across multiple SaaS apps, you must integrate your IAM solution with each of your SaaS apps. These integrations will require custom work, such as coding, to integrate with the various APIs. Plus, you may want to integrate your SaaS security solution, too. The SaaS security solution can monitor user activity and flag problems like inconsistent use of MFA or suspicious signs-in on “local” accounts. 

5. Configuring User Provisioning and Deprovisioning Workflows

Each time a user needs access to a SaaS app under RBAC, you must provision that access based on RBAC rules. The same goes for deprovisioning. The challenge here is to set up a streamlined workflow that does not require too much administrative attention. You don’t want a situation where an admin has to provision or de-provision role-based access manually. Ideally, roles are assigned upon hiring—and then automatically flow to access provisioning. Similarly, you should automate role changes. 

Source

6. Leveraging an Identity Posture Management (IPM) Tool

Getting these moving parts to work together is only part of the challenge of making RBAC work for SaaS security. You will ideally have a SaaS security solution that continuously monitors and reviews user sessions and account configurations. 

With Identity Posture Management (IPM), you get the efficiency and security benefits of RBAC in SaaS while maintaining your overall identity posture. This method lets you promptly detect and remediate insecure access situations before they lead to data breaches. 

Getting Granular and Efficient Access Controls 

Granular access controls are crucial to tighten access to sensitive data and functionality, and RBAC is the most efficient way to implement them. By assigning access based on a role, you avoid the tedious and error-prone practice of provisioning and deprovisioning access on a user-by-user and app-by-app basis. 

Of course, RBAC still doesn’t make access management the most straightforward process ever. SaaS apps often have their own RBAC controls, which may not align with your preferred approach to access privileges. Plus, you may have to integrate your IAM solution with each SaaS app so that a role defined centrally can be applied to all connected apps. 
If you want to simplify RBAC and ensure that every system layer is protected, Suridata can help. As a SaaS Security platform, Suridata can identify all your SaaS integrations and usages to detect access control gaps and other vulnerabilities, providing instant alerts and enriched insights. Learn more here.

---

Raise your hand if you’ve used Salesforce.  If you worked at one of the company’s 150,000 customers worldwide, you’re likely familiar with it. Reigning as the world’s top customer relationship management (CRM) solution, Salesforce is also a flexible SaaS platform with numerous configuration options and third-party extensions.

While a great business tool, Salesforce is also a significant source of security risk and a popular target for data breaches. Recently, simple misconfigurations in the Salesforce Apex programming language led to unauthorized access to data on more than 100 websites. Salesforce offers its own Salesforce Security Model to protect its sprawling attack surface and mitigate data security risks. 

What is the Salesforce Security Model?

The Salesforce Security Model is a set of configurable access controls that operate at different layers of the Salesforce dataset and help businesses secure their Salesforce environment. It enables admins to establish access and data handling privileges for user roles, user profiles, individual permission sets, and sharing rules. The model also controls access and permissions at the object (databases) levels, fields, and records.

Knowing the difference between a Salesforce user’s role and profile helps one understand the security model. Roles are hierarchical, with differences in access privileges based on organizational rank. For example, a Salesforce admin might establish a user role called “Sales Representative.” Users in this role will be permitted to see the Opportunities object, but only their personal sales opportunities, not those of teammates. A user with a “Sales Executive” role can see all team members’ opportunities.  

In contrast, a Salesforce profile is a group of permissions and settings that control what a user can do with data, among other parameters. A profile determines whether a user has “read-only” access to certain records or whether they can edit or delete them. 

Source

The Different Levels of the Salesforce Security Model

The Salesforce Security Model is intended to balance the protection of sensitive data with user experience and business agility. It provides a way to safeguard data with a high degree of granularity and customization. To achieve these goals, the model offers access controls on multiple levels.

1. Organization-Level Security

At the organizational level, admins can limit who has access to the platform in your organization. Theoretically, a user can log into your Salesforce instance from anywhere worldwide, which isn’t ideal for security. To filter out malicious actors, organization-level security allows access to be restricted only to trusted IP ranges and log-in IP ranges. 

Admins could limit access to users logging in from IP addresses associated with the company’s network or expected geographical areas. A US-based company, for instance, could prohibit logins from Eastern Europe. Similar controls can prevent logins at certain times of the day, such as late at night or early in the morning.

2. Object-Level Security

Salesforce objects, such as Opportunities, Leads, Accounts, and Contacts, correlate mostly to the platform tabs. Each object is a separate database table. 

Depending on the organization’s size and structure, most users will not need to interact with all these objects, and it would not be secure to allow such interactions. For instance, if you’re a cold-call sales rep, you shouldn’t be allowed to access the Customer Support object.

Source

The Salesforce Security Model provides several ways to implement object-level security:

• Profiles—These can be by job category or organization-wide, such as “Basic User,” “Manager,” and “Executive.” Each organization-wide profile could have distinct object access permissions.
• Permission Sets—Salesforce allows you to assign multiple object-level access permissions to users without changing their profiles. For example, Joe can access Leads and Accounts, while Susie can only see Contacts.
• Permission Set Groups—To streamline the assignment of permissions, a Salesforce Permission Set Group bundles permission sets based on user roles and profiles.

3. Record-Level Security

Admins can use the Salesforce Security Model to manage access permissions for records, which equate to rows in a Salesforce object database. Record-level security can be based on roles and role hierarchies. For example, the Head of Sales can see all records, while regional sales executives can see all records in their regions. Geographical territories can create an additional layer of control. 

Similarly, criteria-based sharing rules can govern record sharing between users. For instance, if the field “Zip Code” is within a specific range of values, a user with a given role can share them. Admins can also assign sharing permissions manually.

4. Field-Level Security

The Salesforce Security Model also enables access control at the level of database fields. This level is critical because the full dataset often contains sensitive or private information. 

For instance, a Contact object might include a person’s birthday and personal cell number, which attackers could use steal and use for identity theft. Since there’s no reason for all users to see this field, admins can share it selectively.

Source

5. Additional Security Measures

Salesforce has various supplemental security countermeasures, including data encryption, two-factor authentication (2FA), and event monitoring. Session settings can also establish session timeouts and lock out specific IP addresses.

The Weaknesses of the Salesforce Security Model

The Salesforce Security Model is also a driver of risk exposure. Even with good intentions, it’s possible to inadvertently set up data access that violates customers’ privacy and allows their personal information to get into the wrong hands. The same goes for valuable customer lists and sales opportunities. For a malicious insider or external attacker, the customizable nature of roles, profiles, and permissions makes it almost inevitable for security gaps to crop up.

To make matters worse, Salesforce system owners and security teams often struggle to keep up with access permissions given by other admins, making it easier for security vulnerabilities to slip through the cracks. 

For example, if a Sales Manager requests that a Sales Rep be allowed to view deals in another territory, an admin could make that change in permissions without notifying the higher-level Salesforce system owners and security teams. The lack of visibility leads to overprivileged accounts, which hackers can exploit. 

Top Tips to Secure Your Salesforce Environment

1. Focus on Governance First

Securing Salesforce presents a significant governance challenge, but your organizational structure and personnel can be crucial in addressing it. Ideally, your organization will have precise information security controls, rules, and authority grants to set up Salesforce roles, profiles, and permissions. Who gets to decide on settings? Who can make changes? Who needs to approve these? These are the types of questions you should include in your well-thought-out policies.

Consider investing in a data governance tool to make the process auditable and streamline efforts. These tools can help you define data ownership and oversee data security in Salesforce and beyond.

Source

 2. Monitor the Broader Ecosystem

Salesforce is complex enough to secure out of the box. However, many organizations aren’t just dealing with the Salesforce platform but with its various extensions. These include Salesforce Apps from the App Exchange, custom-coded apps written in Apex, and integrations with third-party vendors using the Salesforce API. Every single extension introduces additional risk. 

For this reason, ensure you cover the additional integrations and Salesforce tooling your businesses use in your security policies. Your team must know how to approach these in the context of the Salesforce Security Model to avoid gaps.

3. Leverage Built-in Security Tools

It makes sense to take full advantage of Salesforce’s native security capabilities, such as data encryption or restricting login IP ranges and log-in hours, especially for critical profiles. Salesforce also offers features like Health Check, which allows you to review and optimize your security settings, and login forensics, which will enable you to monitor login activity and detect and respond to suspicious behavior.

Source

4. Implement Regular Reviews

Organizations and hierarchies change over time, so Salesforce settings can become obsolete and, therefore, insecure. Regular reviews of your Salesforce Security Model are essential to maintaining a secure environment. 

You should also evaluate role hierarchies, sharing settings, and permission sets to ensure they align with your current organizational structure and security requirements. Tools like Open Policy Agent can also support your monitoring efforts, enabling you to keep track of active policies, how you enforce them, and when changes occur.

5. Integrate with Existing Security and IAM Tools

You may already use security tools that enable an in-depth approach to securing Salesforce. For example, you can deploy a cloud access security broker (CASB) to monitor usage or constrain access to Salesforce. Or, if you use Microsoft Entra or comparable single-sign-on (SSO) solutions, you can centralize management of access to Salesforce for all users.

Compliance automation tools can also help streamline Salesforce security, ensuring your setup is aligned with regulatory requirements and industry practices.

Source

6. Deploy a SaaS Security Solution

Keeping Salesforce secure should be part of a broader SaaS security program. A SaaS security solution like Suridata can continuously monitor Salesforce on multiple levels, flagging anomalies that signal the presence of a threat. For example, if a Salesforce user exports more data than is required for his job, that will trigger a real-time alert to security managers. Suridata also offers comprehensive visibility into user permissions, data access, and security misconfiguration vulnerabilities. 

Balancing Security with Productivity on Salesforce

There’s a reason over 150,000 businesses trust Salesforce for CRM and other critical operations. However, the same inherent flexibility and customizability that make Salesforce useful also expose customers to cyber risk. The Salesforce Security Model has the potential to enable strong security controls, but the model on its own, without the proper governance and tooling, will not be very effective.

As a comprehensive SaaS security tool, Suridata helps you identify and mitigate vulnerabilities in Salesforce and all your other SaaS apps. Its deep scanning and monitoring capabilities ensure no vulnerability is left undetected across any of your SaaS tooling. Plus, you get real-time alerts and automated mitigation workflows to solve security issues faster. Learn more here.

---

The New SEC Regulations– An Overview 

In a decisive move to strengthen the security of financial markets, the U.S. Securities and Exchange Commission (SEC) has mandated that public companies must swiftly disclose any significant breaches that could impact investor trust and market stability. This directive highlights the critical need for ongoing transparency and robust cybersecurity measures, especially as the reliance on cloud services and SaaS applications grows. With cyber threats on the rise and SaaS platforms becoming integral to operations, companies are required to adopt a more strategic approach to their cybersecurity practices. 

Download the whitepaper and the checklist.

Ongoing Security Management Approach  

Navigating these new SEC regulations presents significant challenges, particularly due to the rapid nature of required, detailed reporting, along with the differences in SaaS products. To be ahead of those challenges, SaaS security should be implemented as an ongoing approach, and managing the SaaS eco-system is the game changer when it comes to the detection and accurate reporting of security incidents. 

The Suridata Difference

This is where Suridata steps in as an indispensable partner in the SaaS security landscape, providing the solution that allows organizations to effectively meet the SEC’s stringent cybersecurity disclosure rules. By enhancing visibility into entire SaaS ecosystems, including shadow and third-party applications, Suridata enables a proactive cybersecurity approach. More than just aiding in immediate reporting requirements, Suridata strengthens the overall SaaS security measures through detailed management of third-party app risks, thus ensuring ongoing compliance with SEC standards. 

As the cybersecurity landscape continues to evolve, the complexity of adhering to regulatory standards intensifies. Vigilance in security practices, particularly concerning the widespread use of SaaS applications, is crucial. Partnering with Suridata equips organizations to face these challenges head-on, protecting their critical assets and reinforcing their commitment to investor trust and regulatory compliance. 

Read the whitepaper and download the checklist to understand how to implement a SaaS security practice, that will not only help you prepare the report the day after but to prevent you from writing it in the first place.  

---

Snowflake, a leading cloud-based data warehousing company, recently faced a wave of attacks targeting its enterprise customers, resulting in the leakage of millions of sensitive records. Here’s a closer look at what happened and how companies can protect themselves. 

Attack Path and Methodology 

The attack spree against Snowflake customers began in mid-April 2024 and was officially acknowledged by Snowflake on May 23, 2024. 

The attack did not stem from a vulnerability within Snowflake’s platform. Instead, it was an identity and misconfiguration-based attack that exploited weak identity and access controls, as well as the absence of multifactor authentication. Here’s a breakdown of the attack path: 

• Initial Compromise: Attackers used credentials stolen by info-stealing malware, probably using Lumma Stealer malware.  
• Accessing Accounts: The attackers gained access to Snowflake environments using these stolen credentials. Notably, many of the compromised accounts lacked multi-factor authentication (MFA), making them easy targets. 
• Data Exfiltration and Extortion: Once inside, the attackers stole data from the compromised databases. They further pressured organizations by warning they would sell the stolen data on the dark web if their demands were not met. 
• Widespread Impact: The attack campaign affected several major companies, leading to high-alert advisories from cybersecurity authorities like the Cybersecurity and Infrastructure Security Agency (CISA). 

Security Recommendations 

In response to these incidents, Snowflake and the cybersecurity community have issued several recommendations to mitigate such identity-based threats: 

• Enforce Multi-Factor Authentication (MFA): Implementing MFA across all accounts is crucial to prevent unauthorized access, even if credentials are compromised.  
• Set Up Network Policy Rules: Restrict network access to trusted locations and ensure only authorized users can access critical systems or sensitive SaaS accounts. 
• Reset and Rotate Credentials: Regularly update and rotate credentials to limit the potential damage from stolen credentials. This will reduce the time window during which stolen credentials can be used by malicious actors, disrupt attackers ongoing access and reduce the ‘Risk of Credential Stuffing Attacks’ (Credential stuffing attacks involve using stolen username and password combinations from one breach to gain access to accounts on other services). 
• Monitor for Unusual Activity: Continuously monitor for signs of unusual user activity, such as unauthorized access attempts from unfamiliar IP addresses. 

How Suridata Can Help 

Suridata offers robust features to help organizations secure their SaaS environment, including Snowflake. Here’s how Suridata can assist: 

• Comprehensive Security Analysis: Suridata conducts comprehensive security assessments of SaaS configurations, identifying potential weaknesses and exposures. Preventive measures that can be taken include: 

• Restrict public access and enforce IP whitelisting. 
• Restriction of network policies that are too permissive. 
• Identify users not enrolled in MFA and enforce mandatory enrollment. 

• Identity and Access Management: Suridata enhances identity and access management by ensuring that authentication mechanisms, including MFA, are in place and properly configured for all users. It also detects user anomalies, that can provide insights into suspicious activities, potentially preventing threats before they can escalate. 
• On-demand User Remediation: Suridata offers remediation capabilities, enabling organizations to swiftly address user misconfigurations and enforce best practices across the Snowflake environment. From Suridata’s platform, risky users can be blocked from an application, their permissions can be revoked, or they can be deleted.  

Conclusion 

The recent attacks on Snowflake customers highlight the critical importance of robust identity and access controls in the SaaS environment. By implementing preventive measures, organizations can significantly reduce their risk of falling victim to similar identity-based threats. Suridata conducts thorough security checks of misconfigurations, identifying potential weaknesses. Key preventive recommendations include: 

• Implementing network policies that restrict access based on the user’s IP address. 
• Identifying and tightening overly permissive network policies to ensure access is granted only to authorized users. 
• Identifying users not enrolled with MFA and ensuring they are promptly secured. 
• Not sure if you are using Snowflake? Suridata offers free application scanning to help you identify and prevent attacks in your SaaS environments. 

---