Privileged Access Management in non-SCIM apps with Microsoft M365 E3

Here’s a hard one, how do you track privileged access inside of non-SCIM provisioned applications? Detexian’s CTO Adrian Kitto has a few tips and tricks for you.

In case you missed it last time, please check out:

  1. Part 1: Who / What / Why does the mid-market all have Microsoft M365 E3 licenses

  2. Part 2: How does Microsoft M365 E3 work with the non-Microsoft ecosystem applications?

  3. Part 3: Discovering user consented apps with Microsoft M365 E3

  4. Part 4: Identifying and removing inactive users with Microsoft M365 E3

  5. Part 5: Calculating inferred or effective MFA for non-Microsoft applications


Introduction

In today's modern workplace, protecting sensitive data and ensuring secure access to critical systems is paramount. Many enterprises take the path of SAML SSO federation to enable users secure and seamless authentication and authorization across multiple systems and applications. It allows users to log in once with their identity provider (IdP) and access multiple service providers (SPs) without the need for separate login credentials.

To take this one step further many enterprises also use SCIM (System for Cross-domain Identity Management) provisioning to simplify and streamline the process of managing user identities and their access rights across different systems and applications. It provides a standardized way to create, update, and delete user accounts, as well as manage their attributes, privileges  and group memberships.

Unfortunately for the mid-market many of the corporate SaaS applications they choose do not support SCIM provisioning (e.g. Pipedrive  or Sendgrid) or if they support it it requires an upgraded license (e.g. Slack or Airtable)  which the business is unlikely to upgrade to for the same reasons outlined in Blog 1 of this series.

The mid-market problem

This leaves the average mid-market IT team to provision and manage users in both Azure AD and the SaaS applications. This becomes particularly problematic when the mid-market organization is attempting to implement and maintain Privileged Access Management (PAM). 

After MFA Privileged Access Management (PAM) is one of the most critical controls in safeguarding organizational assets and mitigating the risk of unauthorized access. Privileged accounts, such as system administrators, hold elevated access rights that can potentially be exploited by malicious actors. Having effective PAM helps organizations manage and secure these accounts by enforcing strong authentication, granting just-in-time access, and implementing robust authorization controls.

This is particularly important when an organization is attempting to gain or maintain ISO 27001 certification as Annex A, specifically control A.9.2.3, mandates the implementation of PAM to ensure the protection of sensitive information. This control requires organizations to establish processes, policies, and technologies that control and monitor privileged access. Where that privileged access is manually provisioned in a native SaaS without Azure AD / SCIM connectors it becomes increasingly difficult to maintain compliance with each SaaS application added to both the corporate workplace and the scope of ISO27001.



Strategies to work around the lack of SCIM provisioning

To effectively monitor and track privileges in non-Microsoft SaaS applications, organizations need to implement a number of manual controls, you could implement the following strategies:

  1. Role-Based Access Control (RBAC):
    Implement RBAC models to assign appropriate access rights to users based on their roles and responsibilities. Regularly review and update these roles to ensure they align with business needs and maintain the principle of least privilege. I suggest that implementing a series of recurring calendar invites on something like a 3 or 6 month recurrence to “Check the default user permissions in Pipedrive are still least privilege” or whichever SaaS you need to manage. When you set this up for the first time, make sure you take note of the settings (I find screen shots help a lot!) so you can refer back to what you had set before. 


  2. User Activity Logging:
    Enable comprehensive logging capabilities within non-Microsoft SaaS applications. Log and monitor user activities, including authentication attempts, privilege changes, and critical actions. Analyze these logs for suspicious activities and anomalous behavior. Make it part of your daily or weekly routine to log into each SaaS under your control and check the activity log, are administrative changes only being done by people you know have the rights? Are there any changes to privilege access? Is there any accounts with a lot of failed authentication attempts? In time you will get a feel for the stuff that really matters in each SaaS, you will also get a feel for the missing information that maybe other SaaS logs that a particular SaaS doesn’t. 


  3. Integration with Identity and Access Management (IAM) Systems:
    Integrate non-Microsoft SaaS applications with IAM systems to centralize privilege management. Leverage IAM solutions to enforce strong authentication, manage user accounts, and automate provisioning and deprovisioning processes. Where you can use SCIM you should look to use it, where maybe the SaaS app uses API or scripting interface consider developing your own scripts to maintain and enforce privileges, the benefits of this will be consistency and auditability of changes. 


  4. Periodic Privilege Reviews:
    Conduct regular reviews of user privileges in non-Microsoft SaaS applications. Verify that users have only the necessary access required for their job functions. Remove excessive privileges and ensure separation of duties to minimize the risk of unauthorized access. Following on from A) and B) have an third party person do periodic reviews of who have privileges in each SaaS, it is very easy to fall into the trap of everyone needs every administrative rights when they don’t.



Conclusion

Privileged Access Management is crucial for organizations to protect sensitive data, comply with industry standards like ISO27001, and mitigate security risks. Even in non-Microsoft SaaS applications that are not SCIM provisioned, organizations can adopt proactive monitoring strategies, RBAC models, user activity logging, and IAM system integration to effectively manage and track privileges. By prioritizing PAM and implementing robust monitoring practices, organizations can enhance their security posture and safeguard critical systems from unauthorized access.

Security thought for the week

The SCIM (System for Cross-domain Identity Management) provisioning standard was proposed by a group of individuals and organizations who formed the SCIM working group from the Internet Engineering Task Force (IETF) in 2010.

The SCIM working group consisted of various participants from different companies and organizations, including industry leaders such as Cisco, Google, Salesforce, and many others

Since its proposal, SCIM has gained wide acceptance and adoption in the industry, becoming a key component of modern identity and access management solutions. The ongoing contributions and support from various organizations continue to shape and evolve the SCIM provisioning standard.

Till then, stay secure.

Adrian

Previous
Previous

Identifying, Evaluating, and Tracking Open Shares for External Users with Microsoft M365 E3

Next
Next

Calculating inferred or effective MFA for non-Microsoft applications