Non-MS Use Cases: Identifying and removing users from non-Microsoft applications after they leave your company

In the final post in this 12 part series about IT and security in a Microsoft M365 world Detexian’s CTO Adrian Kitto delves into why and how you must remove users from your non-Microsoft applications after they leave your organization.

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

6. Part 6: Privileged Access Management in non-SCIM apps with Microsoft M365 E3

7. Part 7: Identifying, Evaluating, and Tracking Open Shares for External Users with Microsoft M365 E3

8. Part 8: Keeping Abreast of Changes in User Permissions, Configuration, and Access with Microsoft M365 E3

9. Part 9: Discovering and Reporting on DLP Alerts Older than 7 Days with Microsoft M365 E3

10. Part 10: Identifying, Evaluating, and Tracking Open Shares for External Users with Microsoft M365 E3

11. Part 11: Tracking changes in user consented applications with Microsoft M365 E3

Introduction

In the realm of IT management, overseeing user accounts and access to company resources is a fundamental task. While it's common practice to have robust processes for provisioning and de-provisioning users within Microsoft's suite of applications, such as Microsoft 365 (M365), the same diligence often does not extend to non-Microsoft applications. This blog post delves into the importance of identifying and removing users from non-Microsoft applications after they leave your company. We'll explore the risks associated with non-single sign-on (SSO) applications and the challenges IT departments face in managing these non-core applications.

The Risks of Non-SSO Applications

Non-SSO applications, which require users to manage separate login credentials, present several inherent risks when employees leave your company:

• Access After Departure: When employees depart from the company, there's often a delay in revoking their access to non-SSO applications. This lapse can lead to unauthorized use of company resources, data breaches, or intellectual property theft.

• Human Error: Manual de-provisioning processes are prone to human error. An oversight in removing access to even a single application can expose sensitive data to former employees.

• Password Risks: Employees might reuse passwords or choose weak passwords for non-SSO applications, making these accounts vulnerable to compromise. Cybercriminals can exploit these weak points to gain unauthorized access.

• Outdated Security: Non-SSO applications may lack modern security features like multi-factor authentication (MFA), leaving them more susceptible to breaches.

• Data Retention: Failure to remove access to non-SSO applications can lead to non-compliance with data privacy regulations. Companies must ensure that ex-employees no longer have access to customer data or other sensitive information.

• Audit Trail: Regulatory bodies often require organizations to maintain an audit trail of user access and permissions. Incomplete de-provisioning can result in compliance violations.

The Challenge of Managing Non-Core Applications

Managing non-SSO applications can be challenging for IT departments for several reasons:

• Multiple Applications: Organizations often use a variety of non-core applications, each with its own access management system and user database. This diversity complicates the de-provisioning process.

• Manual Effort: Many organizations rely on manual processes to revoke access, relying on IT staff to remember to disable accounts and credentials. This approach is time-consuming and prone to errors.

• Access Blind Spots: IT departments may not have full visibility into user access across all non-SSO applications. This lack of visibility can result in incomplete de-provisioning.

Varying Departure Processes: The procedures for handling employee departures may differ across departments or teams, leading to inconsistencies in de-provisioning practices.

Effective Strategies for Managing Non-SSO Applications

To mitigate the risks associated with non-SSO applications and streamline their management, organizations can implement the following strategies:

• Implement SSO Solutions: Transition to SSO solutions for as many applications as possible. SSO centralizes access management, simplifying user provisioning and de-provisioning.

• Create an Application Inventory: Maintain an up-to-date inventory of all non-core applications in use. Prioritize these applications based on their importance and the data they access.

• Automate De-Provisioning: Implement automation tools or scripts to facilitate the de-provisioning process for non-SSO applications. Ensure these tools integrate with your identity management system.

• Regular Audits: Conduct periodic user access reviews for non-core applications to identify and remove inactive or unnecessary accounts.

• Standardize Departure Procedures: Establish a standardized offboarding process that includes thorough de-provisioning of access to all applications, both core and non-core.

• Security Awareness: Educate employees about the importance of promptly reporting their departure to HR and IT. Encourage them to follow company protocols for account closure.

Conclusion: Safeguarding Against Risks

The risks associated with non-SSO applications should not be underestimated. Failing to manage access to these applications effectively can lead to security breaches, compliance violations, and data loss. By adopting a proactive approach to identifying and removing users from non-Microsoft applications after they leave the company, organizations can safeguard their data, maintain compliance, and reduce security vulnerabilities. While managing non-core applications may present challenges, the investment in automation, education, and standardized procedures is a vital step toward robust access management and data protection.

Security thought for the week

Next week is AISA’s CyberCon in Melbourne Australia. I’m not speaking at this year’s conference however I spoke last year in the Human Security stream. This caused me to look into what was the first hacker / security conference and when it was? My research leads to the first known hacker conference often being pointed to the "Homebrew Computer Club." While not solely a security conference, it played a pivotal role in the early days of the hacker and personal computer revolution.

The Homebrew Computer Club was founded in March 1975 in Menlo Park, California. It was a gathering of computer enthusiasts and hobbyists who shared an interest in building and tinkering with early personal computers and related technologies. Many of the club's members were involved in early computer hacking and exploration of computer systems.

I have to say, I was surprised it was as early as 1975 when DEFCON and Blackhat were mid-90’s.

Till then, stay secure.

Adrian