The situation
Most SaaS applications today have some level of modern authentication. The ones that cause problems are usually tied to older directory services, or were set up before the company had a mature approach to identity.
They usually stay outside single sign-on and MFA for one of a few reasons:
- Technical limits.
- No internal expertise to get them converted over.
- Concern about the maintenance window needed to move users and information from local logins over to single sign-on.
MFA has its own challenge. People who don't deal with it in their daily lives can chafe at it, avoid the system or open a lot of tickets to get a device set up. It's necessary from a security standpoint, but it needs to be implemented judiciously at the user and application level.
How we approach it
We develop an iterative process, driven by the priority of which applications go first. Whether it's a single application, dozens of applications or even a thousand, we approach it the same way and work toward the same goal: putting business systems behind phishing-resistant logins and restricting those applications to only using those logins.
- Set the priority. Working with your security team, we decide which applications come first. That can be based on data sensitivity, quick wins, making the biggest impact first so downstream applications benefit, or whatever else matters to your business. You pick from a menu of options and decide the priority and timing. Moving from an internal directory to cloud-based accounts, for example, has a big impact on day one, and everything else rolls up under the new directory structure.
- Evaluate each application on its own merits. No two are the same, and you don't know what you're working with until you get in with the app teams.
- Find the stakeholders. That means the owners at the system level and the decision makers, so everyone is aware of what's happening and the policy can be communicated.
- Learn the business use case. We get the business use case for each product from the team that relies on it.
- Agree on the cutover. We work with the application team and the security team to come up with a compromise on when the application can be cut over, with as little impact on users as possible.
- Implement, then rinse and repeat. We work with the app team to get it implemented, then move to the next application on the priority list and start again.
The takeaway
Each application that's converted to single sign-on and MFA gets phishing-resistant logins and inherits security controls from the identity management platform, instead of relying on its own local hardening for user logins.
It's a major step toward a Zero Trust environment.
Where it gets complicated
On this kind of work, it can all get complicated, and you don't know what you're working with until you get in with the app teams. So it's important not to make assumptions about the environment or how easy it's going to be.
The real complication is getting all the resources you need in one room: the system owners, the decision makers and the security team. Everyone needs to be aware of what's happening so the work gets done as quickly as possible without impacting more users than it has to.