PhLR

100%. Instead keep track of where they sign up with their business email and explain why they can't use those tools.

Indeed, there are some great alternatives for discovering Shadow IT, some with more or less overhead (i.e. browser extensions that nobody wants to install).

Another interesting approach I learned from the Director of IT at Intercom (Emanuele Sparvoli): They pay for a single seat in each of the typical "Shadow IT" SaaS apps. Then they block within the SaaS app the ability to sign up with email/password coming from their domain.

It's pretty drastic since you literally pay for a seat in a tool you don't want to use. But it stops anybody from quickly signing up and instead will guide them to the IT team. They then have the chance to explain what the official alternatives are.

What's important is that the employee's understand the reason why certain apps are not allowed - whether that's cost, security or something else.

The biggest challenge is that there's an abundance of SaaS tools that are free to use or have extensive free trials. This often lures employee's in "just trying" a platform and ending up importing critical company data.

Slack and Loom are great examples of SaaS that profited from being "Shadow IT". They gained traction by employee's quickly self-onboarding onto the free-plan, without their IT or Security knowing what data is being shared.

We talked to lots of CISOs, InfoSec managers and IT admins about that issue. There's basically two camps: Actively block any new tool vs. not block but educate so people don't do anything stupid.

I feel not blocking makes most sense. Employee's want to be treated like adults, especially in tech savvy companies. If they feel like they are unnecessarily blocked they will just find a workaround (i.e. non-work email or device).

However, you definitely want to keep track of people are signing up for - that's where the Shadow IT scanner comes in handy. In case you see something that's against policy it's often enough to just explain why it's a risk for the company. No employee means harm and just wants to be treated like an adult.

Indeed, when I learned about it I felt stupid for not having somebody run a regular report. Everybody talks about Shadow IT but most companies have a decent option to uncover a large chunk of it quite easily

Good eye, but no, not related at all

Thanks!

Thanks! Any interesting findings?

Looks like a candidate for https://ssotax.org/friends-of-sso.html

Sounds like Tailscale is now a candidate for the "Friends of SSO" list https://ssotax.org/friends-of-sso.html

Respect for pushing that through the org!

When talking about controls are you referring to provisioning? What are some examples for missing controls?

Do you have some examples on what granular controls are provided with Okta but missing with Google?

Great approach. Wish there would be more vendors like that. This way we wouldn't even need to talk about SSO-Tax, availability of SCIM/SAML etc.

Thanks! Happy to chat if you want to share some of the ideas you had

'Auditing user accounts in SaaS applications' is a pretty good summary of what the current version is about. The 'SSO-Tax' has become a synonym for the extra charges of SaaS vendors in which they usually bundle 3rd party SSO, SCIM and SAML.

What other tooling would you want it to integrate with?

Great to see that we were not alone with the struggles! Let me know if you are up for a quick chat. Would love to learn more about your situation and how OpenOwl could help fix it. If you are up for it, my contact is in the bio

That's the spirit! Thanks for the kind words.

Indeed, ease of use is incredibly important. After all this is a tool that needs to be used non-developer IT admins as well.

In future versions it will be possible to do the same with, for example, your Google SSO sign-in and 2FA enabled. The reason for the limitation is that we simply wanted to get it out into the world and see if anybody is as excited about it as we are.