Author: Haviv Ohayon

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. 

---

If you’re a malicious actor in cyberspace, you could do much worse than targeting a Workday instance at a large corporation. As one of the world’s leading Human Capital Management (HCM) applications, Workday holds valuable data from employees and businesses worldwide.

The scale of Workday’s user base hints at the level of risk: 50 million users in over 170 countries. Over a million users access Workday every hour, executing 365 billion transactions annually. The platform’s scale and inherent risks prompt a strict security approach. 

Workday has rigorous security controls protecting its infrastructure. However, the problem is that much of the risk exposure inherent in Workday exists outside of what the company provides. 

Source

What is Workday Security?

Workday security is a series of security steps, protocols, and information security controls to mitigate risks in the complex Workday environment. Workday runs in highly secure data centers with network and infrastructure security operations. The company enforces strict application security (AppSec) policies, and all data is encrypted and subject to segregation by the client to protect the multi-tenant architecture. 

Passwords are “native login,” always hashed—never stored or transmitted in their actual forms. However, it’s worth paying attention to the type of password hashing algorithm used, as older methods may be inefficient. Modern algorithms like bcrypt or Argon2 are adaptive and more resistant to attacks, making passwords significantly more difficult and time-consuming to track. A modern, customizable hashing method is crucial to protect your Workday passwords.  

But Workday offers other crucial security features. The whole application is subject to a single security model, so all user interactions are subject to the same policies and enforcement mechanisms. The platform also offers single-sign-on (SSO) using security assertion markup language (SAML) and multi-factor authentication (MFA).

Consider what’s going on inside a typical Workday instance. You might have salary and benefit information for thousands of employees worldwide. Employees can see their salary and benefits, not anyone else’s. Administrative users may have greater visibility into this private information and be able to define access controls and security configurations.

This power ensures that no one sees what they’re not supposed to see and that no outsider can view, exfiltrate, modify, or delete any data. Still, Workday is a SaaS app like any other, so it suffers from the same SaaS security challenges. Just like you would secure your Salesforce environment to protect customer data, you should apply extra security measures to your Workday platform to protect employees’ private information. 

Source

Why Should You Care About Securing Your Workday Platform?

Workday’s extensive user base and dynamic functionality make it vulnerable to cyber threats. At most Workday companies, virtually every employee can access the software, subject to a broad and often complex range of permissions. The software integrates with other systems, too, which further expands the attack surface. 

Despite having its robust security features, Workday still faces various risks. Most of these risks stem from using and integrating this SaaS app with other apps, but they can be mitigated with the proper SaaS security best practices. As a Workday client, here are the common security threats you should be concerned about:  

• Phishing attacks—Malicious actors can trick employees into sharing their Workday login credentials or other information that lets them gain unauthorized access to the application.
• Credential stuffing attacks—If attackers have stolen passwords, such as those on the dark web, they can try to access Workday by pairing known user emails with possible passwords. This attack can work if MFA is not switched on and users use the same password for personal accounts. 
• Insider threats—Employees may abuse their access to the application for many reasons, ranging from curiosity to disgruntlement and greed. Privileged users comprise the most severe insider threat. 
• API threats/integrations—Workday connects with many popular enterprise applications through its application programming interface (API). The same API can be the basis for integration with virtually any software. Depending on how you configure the API, it may be vulnerable to threats like broken access control or injection attacks. Left un-remediated, vulnerable APIs can leak data to unauthorized parties.
• Supply chain attacks—Workday offers an integrated development environment (IDE) so developers can build custom add-ons and integrations for the software. By allowing custom code from outsiders, Workday could enable insecure software development processes. This exposes Workday customers to supply chain attacks like malicious code injections, social engineering, and compromised dependencies. 

Source

Challenges in Maintaining Workday security 

1. Overprivileged accounts

It is possible to let some Workday accounts become overprivileged, even if accidentally. For example, if a user has an admin role but then switches to a new job that does not require admin access and that access is not revoked, the user has excessive privileges. Bad actors can exploit these to access and steal sensitive data, manipulate settings, or approve financial transactions. 

2. Complexity of roles, hierarchies, and organizational structures

Workday allows you to create highly complex user roles with access rights that map to organizational structures and hierarchies. This level of detail is excellent because you can set up your access how you want it. However, organizations are dynamic, and over time, the role definitions you set up will become obsolete, creating risk exposure in the process. 

3. Lack of visibility over access controls

The complexity of roles and their respective privilege leads to a situation where security admins may lack visibility into access controls. Workday does provide an interface with a view of access controls, but when there are thousands of users to manage, with varying and ever-changing permission levels, admins struggle to parse who can do what on the software. 

6 Steps to Improve Workday Security

1. Monitor security configurations

Security admins’ flexibility and discretion can lead to insecure configurations, such as overly permissive bring-your-own-device (BYOD) policies or a lack of MFA. These misconfigurations allow attackers to enter your systems and can be very challenging to spot. To monitor security configurations properly, you should use an automated monitoring tool like Suridata, which scans configurations continuously and flags problematic ones.

Source

2. Create a privileges inventory and regularly update it

Keep your Workday access model simple and map it clearly to your organizational model and role definitions. The result will be an inventory of privileges that identifies what every type of user can see and do on Workday. This inventory should include the privileges granted to Workday integration system users (ISUs) and Integration Security Groups (ISSGs). Keeping this inventory up to date has to be someone’s job, and executive sponsorship may be necessary to ensure the budget to cover this cost. 

3. Deploy API security and third-party security countermeasures

The Workday API is a potential attack surface, so deploying countermeasures that mitigate API risk is a best practice. Firstly, it’s worth familiarizing yourself with the top 10 risks for OWASP API security. This list gives you a comprehensive overview of the threats to look out for and how attackers exploit these gaps. Then, using a dedicated API security solution, you can scan your environment for “rogue” APIs that may have been abandoned but expose Workday data to external API clients. These tools can also monitor API security settings and flag insecure APIs. 

4. Employ Secure DevOps practices

If your organization uses the Workday IDE and leverages DevOps, you should employ AppSec methods in your development process. One key component of AppSec is code scanning, for which you can employ SAST and DAST tools to identify vulnerabilities early. Integrating “shift left” security remediation can also help you embed the proper security controls during development, preventing you from having to fix vulnerabilities while your Workday app is running. 

Source

5. Continuous compliance monitoring

The personnel data on Workday is subject to several laws regarding consumer privacy, depending on where you operate. If you have employees in California, you must comply with CCPA, for example. If you’re in Europe, it’s GDPR. Violations of these laws can be costly and time-consuming to remediate. 

You can reduce your compliance risk by continuously monitoring for compliance (for instance, checking that data is in the correct sovereignty and no data about German citizens is stored in France). 

6. Continuously scan for insecure data 

Workday is likely just one element in your broader SaaS ecosystem. It’s also likely to be connected to other SaaS apps you use, such as online storage solutions. One risk in these conditions is that users will move data from Workday to another app, such as an online storage platform. This data storage can be highly insecure, leading to the risk of breach, exfiltration, and all the expensive remediation actions that follow such an event. 

SaaS security solutions like Suridata can continuously scan for personnel data across the entire SaaS ecosystem, automatically flagging data that needs to be removed and providing detailed insights into the issue so you can activate the proper remediation workflow. 

Making Workday SaaS Secure

Workday has many security features, but the software remains vulnerable to threats like phishing attacks, API attacks, and brute force. Complex access rules compound the problem. To make Workday more secure, you must implement countermeasures addressing these risks.
Suridata can make securing your Workday platform and data much more manageable. The Suridata tool scans your entire SaaS ecosystem (Workday and beyond, no matter how many SaaS apps you have), monitoring Workday’s security configurations, spotting any abnormal user behavior, and accurately identifying data that might have been mistakenly or maliciously exported from Workday. Interested in seeing it in action? Schedule a demo with our team.

Is it a coincidence that the mascot for GitHub, the world’s largest source code host, is cat? Probably not, given that managing software developers is often likened to herding cats. Although now owned by Microsoft, GitHub is at the core of most open-source software development projects, with over 400 million code repositories and 100 million developer users. Thousands of major enterprises rely on GitHub as a developer platform. 

In functional terms, think of GitHub as a software-as-a-service (SaaS) application, albeit one that comes with some serious security challenges. Hackers love GitHub because it contains so many keys to so many different kingdoms. It’s home to all sorts of login credentials for sensitive networks. Mostly, though, GitHub represents an amazing platform for launching supply chain attacks. By implanting malware-laden code components in GitHub, a malicious actor can easily seed thousands of development projects with unseen trap doors. 

Attacks on GitHub have become common, but uncommonly sophisticated and potentially devastating. GitHub leaked more than 12 million authentication secrets and keys in 2023 alone. Then, just last month, attackers used stolen cookies to hijack GitHub accounts and gained the ability to inject malicious code into trusted repositories.  

What is GitHub security?

Given the value of GitHub as a target, it should make sense that you need to take steps to defend your GitHub instance. GitHub itself offers numerous security features to help in this workload. Third-party tools can be useful, as well. Most importantly, however, it’s necessary to recognize the risks inherent in using GitHub and plan carefully to mitigate them.

Source

Why you need to invest in GitHub security

GitHub should be a priority for investments in security due to the central role it plays in application development. Not only is GitHub usually home to all sorts of valuable source code and internal documents, and credentials, it’s also ground zero for supply chain attacks on your organization. And, multiple teams typically access and collaborate on GitHub for version control—a formula for cyber vulnerability. 7 GitHub Security Best Practices for 2024 | Suridata

GitHub may already be part of your security program, especially if your organization has implemented application security (AppSec) countermeasures at the development stage or if it is doing DevSecOps. Even if you are “shifting left” in this way, though, you might still want to pay extra attention to GitHub, given its potential for risk exposure at the development stage. 

Indeed, it might be better to think about GitHub in terms of SaaS security. It’s most likely one of hundreds of SaaS apps that your organization is using, but perhaps you haven’t thought about it that way. It’s deep in the recesses of the IT organization, not a production app like Salesforce or Microsoft 365. So, you may not apply SaaS security to GitHub, but you might want to consider doing so. 

Source

The Security challenges of GitHub environments

Securing GitHub environments brings its share of challenges, especially considering the integrated, collaborative nature of the platform and the many different people and teams who use it. The fact that most users are developers compounds the challenges. They may de-emphasize security as a concern or neglect to follow security policies that interfere with their personal productivity (See: Cats, herding). 

Challenges include:

• Staying on top of access controls and permissions—Who can access GitHub, and what can they do once they’re on the platform. GitHub may not integrate/federate with your identity and access management (IAM) solution, so it can be hard to know who is who and who can do what. 
• Keeping third-party integrations secure—GitHub integrates with hundreds of other applications, from IT ticketing systems to work tracking tools and beyond. These third-party integrations can expose GitHub to risk, particularly the risk of unauthorized access. 
• Protecting the organization from GitHub-based phishing and social engineering attacks—The community-centric nature of GitHub users, who may span different entities, makes phishing and social engineering a serious risk. Will you be able to tell if one of your user accounts has been compromised?
• Avoiding misconfigurations that affect security—GitHub configurations can affect security. For example, applying proper Branch Protection Rules to ensure that new code is integrated only after it was checked and reviewed. Or, enabling GitHub built-in capabilities for scanning, identifying, by alerting on vulnerable dependencies within your code, as well as on possible secrets (i.e. passwords, tokens, etc.) that were accidentally placed within your code. 
• Protecting sensitive data stored in GitHub repositories—Are GitHub users storing data that hackers want, like log in credentials and keys? How would you know if they did?

Source

7 Essential SaaS Security Best Practices for GitHub

There are a number of SaaS security best practices you can adopt If you want to be serious about securing GitHub, either on its own or as part of a broader AppSec or DevSecOps initiative. Some are based on GitHub’s own extensive built-in security features. Others use third-party solutions. Others, still are policy or process based. 

Here are 7 to consider:

#1: Enable MFA for GitHub Accounts

MFA is an excellent countermeasure that cuts down on the chances of an unauthorized person gaining access to your GitHub environment. GitHub is on this, requiring two-factor authentication (2FA) using a time-based one-time password (TOTP). Many third-party solutions can also make this work, including Duo and Google Authenticator. One recommendation is to use an authenticator app versus SMS/Text messages for TOTP, due to the risk of simswap attacks that let hackers breach a GitHub environment even with MFA in place.

#2: Enforce Strong Passwords and Regular Updates

Strong passwords will help reduce the risk of unauthorized logins based on brute force attacks. Overall, though, GitHub requires a set of password policies, such as requiring regular password updates and strict rules against sharing passwords. It may be optimal to implement single sign on (SSO) and make access to GitHub subject to organization-wide access control policies and password rules. 

#3: Activate GitHub Secret Scanning

GitHub enables you to scan your repository and search for secrets that should not have been stored there. For example, a GitHub user might add a security token or private key in a repository to make his or her life easier when dealing with application integration. However, this practice leaves these secrets vulnerable to breach, leading to more potential risk exposure. The GitHub Secret Scanner reviews the entire Git history on all branches and scours it for secrets.

The GitHub scanner has a relatively narrow focus, however. It mostly looks for known string structures like API Keys—possibly missing password, admin URLs, and so forth. A third-party tool like Suridata’s SaaS security solution can be configured to scan for a much wider range of data hidden in massive GitHub repositories. A further best practice, which should ideally be a policy, is to replace any secret that has been made public. You should assume that it was discovered by someone and that is has been compromised. 

Source

#4: Apply Least Privilege Access Controls

Code in GitHub is vulnerable to manipulation by malicious actors, e.g., implanting malware-laden code into your codebase, it is a good practice to limit access privileges by default. The fewer places in GitHub a user can go, the better. This means putting the principle of least privilege (PoLP) into effect. GitHub offers five levels of access privilege: Read, Triage, Write, Maintain, and Admin. By applying PoLP, you can limit users to the lowest level of privilege they need to do their jobs. As a result, your repositories will have less risk of accidental exposure of sensitive data as well as intrusions by hackers. 

#5: Monitor Access Logs for Suspicious Activity

The sophistication of the March, 2024 GitHub attack, which involved inserting malware-infused copies of the popular Colorama tool in GitHub, shows how difficult it can be to detect attacks and prevent hackers from penetrating GitHub. To mitigate this type of risk, the best practice is to monitor GitHub’s logs, including access logs, for suspicious activity. Anomalies in access, such as users logging in from foreign countries or stolen cookies appearing on two devices at the same time, could signal the start of an attack. 

#6: Implement Branch Protection Rules

This is not a SaaS security practice, per se, but it’s still quite important for the security of code that resides in GitHub repositories. When a user can create a branch, that enables him or her to create a new version of a code component. This may not sound like much of a risk, but if the user is a malicious insider, he or she can implant malware into the new branch, which can then go into production. GitHub has a variety of branch controls, including the ability to lock branches, restrict the merging of branches, and restricting branching privileges to certain users.

Source

#7: Back Up your GitHub

Your GitHub data is precious. It represents intellectual property, many person-hours of work, and, in some cases, the digital core of your entire business strategy. You need to protect that data from attack, especially ransomware attacks. Even a simple outage can cause serious problems. GitHub has its own backup feature, Git CLI, but third-party vendors like Veeam support GitHub backups as well and make GitHub backup part of a broader enterprise backup process. One challenge to deal with, however, is the risk that a backed-up version of a GitHub repository will itself become a target of attackers.  

Onward to a More Secure GitHub

GitHub may not seem like it’s part of your SaaS ecosystem. It’s not an operational app or software your people use for general business productivity. However, structurally, and in all the most important senses, GitHub is very much a SaaS app. It’s web based. It’s accessible by browser from anywhere, on any device. It contains valuable, often sensitive data. As such, it should be subject to SaaS security countermeasures and controls. 

SaaS security best practices for GitHub encompass standard SaaS security controls like MFA and strong passwords. It’s also wise to apply best practices that are specific to GitHub, such as secrets scanning and enforcing policies that limit the risks of branching. If you approach GitHub with these best practices, you should be able to improve your application security posture by making your software development processes more secure. 

To learn more about how Suridata’s SaaS security solution can help with GitHub security, visit www.suridata.ai or book a demo.

---

Salesforce has been so successful that we tend to forget what a breakthrough it was when it debuted 25 years ago. At the time, people were skeptical that they could get enterprise-grade functionality on a browser. They were mistaken. 

As the leading customer relationship management (CRM) platform, Salesforce is a testament to the innovation and agility SaaS apps bring to businesses. However, there are still risks, particularly when it comes to security. 

39% of companies that use SaaS have experienced data breaches. Salesforce’s extensive integration capabilities, massive partner marketplace, and customization through purpose-built programming languages further exacerbate its cyber vulnerabilities. 

Why you need to invest in Salesforce security 

Salesforce is a highly professional organization that takes security seriously. However, the platform embodies several vulnerabilities, some of which are standard for SaaS and some particular to Salesforce. CRM apps like Salesforce hold sensitive data such as customers’ personally identifiable information (PII), financial details, and geolocation. Failure to secure SaaS data increases the risk of it being compromised by malicious actors and insiders. 

This problem is not different from what happens with other SaaS apps, but Salesforce’s deployment is usually so broad and interconnected in an organization that it amplifies the risk. Likely, every sales, marketing, and customer support person and their respective managers have access to Salesforce. That’s a large number of accounts that attackers can hijack. Plus, any extra person accessing this data increases the risk of insider threats.

Salesforce security should, at a minimum, be part of your SaaS security best practices. However, Salesforce deserves extra attention because of the potential business impact of a security incident in this app. 

Salesforce customers like Ohio’s Huntington Bank and the State of Vermont are dealing with the reputational fallout and expense of data leakage from the Salesforce Communities they set up. Securing your Salesforce app can prevent large-scale data breaches that often result in reputational damage, financial loss, and legal consequences. 

The most common security risks of Salesforce

Custom code vulnerabilities

Salesforce customers can create custom-coded functions with its Java-like Apex programming language. Apex enables developers to build apps that call on the Salesforce backend database. While useful, Apex classes potentially expose sensitive Salesforce data to unauthorized database calls through its application programming interface (API). This is of particular concern if Apex is configured “without sharing,” a setting that ignores the user’s permissions, allows access to records, and offers the ability to change them. 

Configuration weaknesses

You can configure Salesforce in ways that expose data to overly broad access. For example, the Salesforce Community module, which enables customers to set up public sites for their customers, can be configured to allow database access for guest users. Done wrong, this can easily lead to serious security misconfiguration vulnerabilities that facilitate data leakage.  

Integration risks with third-party applications

Salesforce is usually integrated with email systems, enterprise resource planning (ERP) platforms, and accounting systems, making it a gateway for attacks. The platform integrates with thousands of applications, many created using Salesforce developer tools and APIs. As a result, the potential for improper access and malicious activities on the platform is extremely high.

Social engineering attacks

This threat is not unique to Salesforce. However, the breadth and scope of the app in most organizations makes it vulnerable to hackers who impersonate work colleagues to pry loose access credentials, commit account takeover and other data from unsuspecting users. 

API vulnerabilities

Salesforce publishes numerous APIs that give other applications access to data and functionality on the Salesforce platform. While beneficial in business terms, the APIs create risk. One example is problems with object and file level security, where developers might generate an API call that does not consider the specific fields accessible, updatable, or deletable on the object invoked by the API. Significant risks also arise with the creation of third-party applications that invoke the Salesforce API but are themselves security deficient.

13 Essential Steps to a Secure Salesforce Environment

User Management & Permissions

1. Adopt the principle of “Least Privilege”

A Salesforce user should have the fewest possible access privileges. Applying this principle requires thinking and planning about user roles and what each role can access and clearly defining this in an Identity Governance framework. The “Least Privilege” principle should apply to system admins and developers working on custom Salesforce apps. 

2. Implement strong passwords & MFA

The ability for Salesforce users to log in from anywhere, on virtually any device, is great for productivity but disastrous for security. Requiring strong passwords and multi-factor authentication (MFA) can help reduce the risk of malicious actors gaining access by guessing passwords or using stolen login credentials. Salesforce has its own native MFA feature, but customers can also use third-party solutions like Okta and Duo for this purpose. 

3. Disable inactive users

Inactive user accounts are ripe for takeover by attackers. It’s wise to purge former employees or people who no longer need access to Salesforce from their user rolls. This should not be a manual process but take place automatically through integration with identity management solutions that manage the provision/de-provision of all system access for employees.

4. Integrate Salesforce with IAM solutions

Salesforce has its self-contained user management system. However, you shouldn’t let Salesforce be an identity silo, with a Salesforce admin taking care of provisioning/deprovisioning access. 

Instead, integrate Salesforce with your organization’s identity and access management (IAM) solution, such as Microsoft Active Directory. This integration lets you switch Salesforce access on or off centrally when employees join or leave the company or change roles. 

Allowing single sign-on (SSO) is a variant of this approach, enabling users to log in once and then automatically be signed in to Salesforce and other apps. Salesforce enables SSO through integrations with Okta, Duo, and many other SSO solutions. 

5. Map organizational structure and roles to Salesforce access rules

Salesforce functionality and access privileges are hierarchical. For example, a Sales Manager can see the activities of her direct reports. It is a good practice to map your organizational structure carefully to Salesforce role definitions and privileges. 

Data and Application Security

6. Implement field-level security

If you are using Apex code or Salesforce APIs, it’s wise to implement field-level security. This control forces you to decide which fields are exposed to access by the API or Apex classes. It is a countermeasure against exposing sensitive data to breaches.

7. Implement Data Loss Prevention (DLP)

Data Loss Prevention (DLP) for Salesforce can take various forms. Still, it mainly involves policies and processes like role-based access control (RBAC) and regular backups, which you can do using tools like Veeam. You should also implement data encryption as part of your DLP plan. Salesforce offers the Shield Platform Encryption feature, which encrypts data at rest on the Salesforce platform.

8. Mitigate third-party application risk

Third-party apps pose a significant threat to Salesforce, partly because it has little control over the quality of development and security of the third-party integration plugins that connect to its platform. SaaS security solutions like Suridata can scan for third-party plugins and flag integrations that may create risk in the Salesforce environment.

9. Engage in secure app development

If you’re developing applications for Salesforce using Apex or other developer tools, you should use secure development practices by leveraging approaches like the DevSecOps methodology. You should also review any AppExchange app for security before allowing anyone to implement it in your Salesforce environment. 

10. Build an IP allowlist

Salesforce enables IP allowlisting natively. This countermeasure allows you to restrict the range of Internet Protocol (IP) addresses that can access Salesforce, e.g., only IP addresses in North America. 

11. Focus on API security

APIs are a significant attack surface for Salesforce, so you should define and enforce security policies that reduce API-based vulnerabilities. This process may align with your organization’s existing API security and governance programs, so it may not be necessary to spin up API security just for Salesforce. 

Possible countermeasures include:

• Scanning for “rogue” or abandoned Salesforce API integrations.
• Managing API access.
• Using IAM and privileged access management (PAM) solutions.
• Using API security tools to discover APIs vulnerable to injection attacks. 

Monitoring & Logging

12. Create audit trails

Audit trails may not be a priority if you’re a small to medium company. However, generally, it’s helpful to create audit trails for review by stakeholders that range from executives to internal auditors and external regulators. Salesforce enables this capability natively in its Audit Trail Tab. 

13. Develop and test incident response processes

Salesforce security incidents are not that uncommon, so it pays to be prepared. An incident response process for Salesforce might be the same as you have for other SaaS apps. SaaS security solutions like Suridata offer SaaS detection and response (SSDR) capabilities, so you can leverage those to automate your incident response workflows and solve vulnerabilities promptly. 

Making Salesforce Secure

In a perfect world, your SaaS security measures would cover all risks affecting your Salesforce environment. However, the reality is that Salesforce is so far-reaching in the average organization and so profoundly interconnected that it embodies a unique level of risk. For this reason, you should review your Salesforce security, taking concrete steps to manage user access and permissions, protect data, and monitor Salesforce for signs of attack.

Suridata’s SaaS security solution can help you here. Suridata monitors user activities, checks for insecure configurations across all systems layers, and conducts granular vulnerability assessments. Plus, you get real-time alerts and in-depth vulnerability information to activate the correct workflows. Learn more here.

Have you ever managed to extract a file folder from a locked filing cabinet? Most likely not. That lock is a simple example of an information security control. Computers are no different, except that information security controls today are significantly more sophisticated. 

And they need to be, as cyber threats are causing massive disruptions worldwide. Ransomware incidents increased by a staggering 60% from 2022 to 2023. There was also a 49% jump in overall cybercrime losses, from $6.9 billion in 2021 to $10.3 billion in 2022.

Information security controls help detect cyber threats, prevent them from damaging information assets, and correct damage if it occurs. 

The 3 Principles of Information Security 

Understanding information security controls must begin with understanding the purpose of information security. The term “Information Security” (InfoSec) dates back to old-school nerdiness in the era of crewcuts and pocket protectors. As prehistoric as these people may have been, they had a clear and still extremely useful way to define the purpose of InfoSec.

They came up with three core goals for information security:

• Confidentiality—Information security efforts should endeavor to keep information private, ensuring that only those with permission can access a given data set.
• Integrity—The information in computer systems should have integrity, meaning that users can be confident that it has not been modified or selectively deleted by accident or malicious act.
• Availability—Information should be available to users to the greatest extent possible, ideally 100% of the time. 

The three goals are known as the “CIA Triad.” They underpin nearly every aspect of cybersecurity and form the foundation for information security controls. Today, the CIA Triad applies to software, data storage, networks, cloud-based systems, SaaS security, and virtually any other digital asset in cyberspace. 

What are Information Security Controls

Information security control is a safeguard that realizes some aspects of the CIA Triad. For confidentiality, for example, you might implement a control that uses an identity and access management (IAM) system to block unauthorized users from data you want to keep confidential. 

Some organizations set up their controls under a control framework, such as the National Institute of Standards (NIST) Cybersecurity Framework (NIST CSF) or ISO 27001. These frameworks suggest dozens of controls, and consultancies and auditors work with organizations in their implementation. 

Each information security control has a “Control Objective,” which states the purpose of the control. For example, NIST CSF has a control for “Identity Management and Access Control (PR.AC),” whose objective holds that “Access to physical and logical assets and associated facilities is limited to authorized users, processes, and devices, and is managed consistent with the assessed risk of unauthorized access.”

Following the control objective, each control has a set of control activities that realize the objective. PR:AC, for instance, has six sub-categories of control activity that support fulfilling the control objective. One of these sub-categories is PR.AC-1, which requires an organization to deploy a solution so that “Identities and credentials are issued, managed, revoked, and audited for authorized devices, users, and processes.” In practice, this means some sort of IAM system.

It may seem overly elaborate to require a control objective and a list of control activities to operationalize the CIA Triad. A small organization might not need to go through the whole hassle. However, working off an information security controls framework is beneficial for most organizations. The framework provides a coherent and complete approach to implementing controls that make the CIA Triad do its job of protecting your data. 

Without the coherence and thoroughness of a framework and its associated objectives and activities, you’ll likely have control gaps that create risk exposure. 

10 Types of Information Security Controls

Getting more granular, there are three categories of control functions: Preventive, detective, and corrective. These control functions deal with preventing attacks on information assets, detecting attacks, and correcting the effects of attacks, respectively. Controls also vary by type, with some controls being physical, such as locks; technical, such as web application firewalls; and administrative, such as data access policies. 

Effective cybersecurity posture comes from deploying a well-thought-through and balanced mix of these functions and types. Controls may be layered, supporting a “defense in depth” security strategy. With that in mind, here are ten types of information security controls that are common across the three control functions:

Preventative Controls 

1. Access controls

Access controls prevent the wrong people from accessing data, networks, SaaS apps, and other system components. They are crucial because unauthorized access is one of the most common cyber risks. Many IAM tools can help you build a robust identity governance framework and implement comprehensive access controls such as multi-factor authentication (MFA) or behavior analytics.

2. SaaS security controls

SaaS apps are new territory for information security controls, mainly because traditional controls don’t cover SaaS well. For example, you can have a practical set of access controls for your network, but they won’t do much to prevent a malicious actor from logging into a SaaS app. 

SaaS apps have their own built-in access management features. These apps will remain vulnerable unless you deploy specialized SaaS security tools that map the established access control list to SaaS. 

Other preventive cyber security controls specific to SaaS include monitoring and remediating misconfigured SaaS apps exposed to threats and policy-based controls that govern who has administrative back-end access to SaaS apps.

3. Data protection controls

Cyber attackers tend to be after data to steal, spy on, or ransom it. Data protection controls like data monitoring and data encryption are, therefore, among the more critical information security controls in force at an organization. Data encryption, for instance, makes data unusable to attackers, preventing the worst outcome of a data breach. 

Ransomware protections, such as immutable backups and logical air gaps, are preventive data protection controls. They make it harder for a ransomware attacker to achieve his objective of encrypting data and ransoming it.

4. Patch management

Some of the worst cyber attacks exploit vulnerabilities that could have been fixed with software patches but weren’t. A patch management regimen is a preventive policy-based control to reduce the likelihood of this outcome. It is usually implemented through a combination of processes and tools. For example, the policy may require you to apply all software patches as they are announced. In practice, this encompasses patch testing and patching prioritization. 

Detective Controls

5. Intrusion detection controls

Intrusion detection controls aim to discover when an attacker is trying to gain unauthorized entry into a system—and then alert the right people or even mitigate the threat automatically. Many intrusion detection systems (IDSs) can fulfill the control objective, though some suffer from false positives and excessive alerting. The new generation of IDSs uses AI to improve accuracy by flagging only actual intrusion attempts.

6. Anomalies and events detection controls

It may be possible to detect an attack by analyzing events occurring in the IT estate and flagging anomalies for investigation. For example, suppose a user located in the United States appears to be logging into a SaaS app from Europe. In that case, that anomaly might indicate that an attack is underway. 

Detective controls in this category may monitor device logs (think of network firewalls or endpoints) and flag suspicious activities for security analysts to examine. Some advanced threat detection tools will automatically mitigate the threats they detect, such as quarantining a device.

7. Vulnerability and misconfiguration scanning

Devices and applications must be configured for security. For example, you can “harden” a server by limiting who can install new software. It is very possible, unfortunately, for a device or application to be misconfigured, making it vulnerable to threats. 

This is a particular concern with SaaS because each SaaS app has its security configurations, and in many cases, individual end users can change these configurations. They can, for example, make data accessible to anyone, not just employees of the organization. 

SaaS security platforms like Suridata can facilitate the implementation of this control by enabling system owners to scan multiple SaaS apps and detect security misconfiguration vulnerabilities that expose the apps to risk. 

Corrective Controls 

8. Incident response plans

An incident response plan is a corrective control that counteracts the impact of a cybersecurity incident. Like most corrective controls, it works in tandem with a detective control. When a detective control signals that an incident has occurred, that triggers the incident response plan, which corrects the incident by quarantining compromised endpoints, reinstalling infected software, or notifying key stakeholders. 

9. Disaster recovery plans

Disaster recovery plans are a vital part of any cyber threat intelligence framework. The control objective of disaster recovery (DR) plans is to support the availability of systems and data. A good DR plan restores data and system functionality in a cyberattack or any other event that causes an outage.

10. Data backups

A data backup serves as a corrective control in case of a data breach or outage affecting data availability. By backing up data and providing the ability to restore it in the wake of an attack, the control mitigates the effect of the breach and realizes the control objective of data availability. 

Getting The CIA Triad Under Control, Everywhere

Information security controls are essential for preventing, detecting, and correcting security incidents that adversely affect data and systems’ confidentiality, integrity, and availability. Whether you implement them ad hoc or endeavor to operationalize a large-scale controls framework like NIST CSF, you will always be dealing with the same issues: What is the control objective, and what activities will it take to attain it?

SaaS can be a challenging environment for information security controls. Apps are freestanding and delivered by external entities. Individual end users may be able to set their controls—often at odds with organizational security policy and even common sense. 

New SaaS security solutions like Suridata can improve this risky setup.  By monitoring the entire SaaS environment and flagging data at risk and insecure misconfigurations, they provide the basis for defining and implementing information security controls for SaaS apps. Learn more about Suridata.