Who changed the router settings? Easy Accountability for Shared Access!

Who changed the settings on the router? Who changed the password on the SFDC account? Who changed language settings on the service? Who… who.. who… a never ending stream of important questions.

The move to the cloud

Why do these questions come up in enterprises? After all aren’t we using sophisticated account management practices, tied in to Active Directory and more. The answer lies buried beneath the surface of modern day SaaS applications, although what we are discussing here is hardly anything new. The who did this or that series of questions has existed since time immemorial. With legacy software and on premise versions of various products, IT and security teams had a perimeter within which they could create a walled garden, specify which doors you could go through, and which you cannot open. Therefore it was easier (in a sense) to have visibility into the actions of employees and accounts that are active.

With the move to cloud services and the constant ra ra ra of SaaS and opex versus capex discussions, most enterprises have in one way or the other started to make a move to the cloud. In fact most enterprises use at least 5 purely SaaS applications for CRM, HR, Financial tracking and what not.

The not so pretty aspect of these “easy to use” SaaS applications is the fact that employees often need to share access to a single SaaS account. Why is this the case? The reason is quite simple. Role Based Access Control also known as RBAC is usually built into an application from the perspective of the application developer. When has a SaaS vendor ever asked you — “Do the RBAC and roles we have in our product map to your needs?” — rarely, is the answer.

Shared Access

Given the more or less inflexible nature of these applications that you do not control, have no hand in designing and are just meant to use — it becomes necessary to give certain members of your team access to each other’s accounts. A typical case would be giving access to an admin account so that someone can add one more user to the service. Think about Google. Using Google apps is easy, the admin account can create, delete, suspend any user from your corporate gmail/email list. Many a time more than one team member will need access to these features — and lets be honest, do you really go through the complicated and circuitous documentation on all SaaS apps to figure out how to “delegate” authority?

Ease of use and clarity

Only 30% of SaaS applications, based on customer conversations, have satisfactory RBAC controls built in. The vast majority either lack them entirely or have sub-par functionality. Now, the question arises that out of the 30% of apps that do have RBAC — how many of them are easy to enable and understand. This is a much more tricky question as it lends itself to a subjective answer. From what we see only about 25% of apps that have RBAC built in can be configured in less than 1 hour. Everything else takes way longer. Take for example the most popular CRM in the world — Salesforce. Does Salesforce have RBAC — Yes, Is the RBAC granular — Yes, Is it obvious and easy to configure — No for many an admin that we have talked to. Ease of use makes sure that when the customer requires it, they will use the feature you have provided. Simply providing a feature without making it easy to use is like washing your hands off a problem. I gave you a solution, you asked for a solution, so we are done.

Compliance Issues

When RBAC is enabled or when employees need to share access to common accounts, this violates a bunch of compliance principles ranging from PCI, to HIPAA, to FFIEC, to ISO and what not. If sharing of account access is done in an insecure manner where multiple employees keep control of the shared account and you have no way of guaranteeing that corpus is tightly controlled — you are in violation of compliance regulations. Consider the case for banks. You need to be able to give every user an individual account — but what will you do when the SaaS service you chose for your needs only offers one login. Even though you have multiple internal people with separate emails and employee IDs, what will you do when they need to login to the SaaS service. This si a real world problem faced by many companies.

Track and Attribute

First the bad news (it’ll be quick) — Apps are not going to provide you with the RBAC you want anytime soon. You think this is not true — take a look around, how many apps have provided you with SAMPL and OAuth support in the last 10 years? Are all your corporate apps using SSO — no.

The good news — Yes, you can still share accounts and still stay within your compliance framework. You have to focus on making sure you can do the following:

  1. Share account access not credentials
  2. Share account access based on time requirements
  3. Have someone authorize the account sharing request, preferably using biometrics
  4. Monitor and track what the shared account is used for and keep non tamper-able copies of this information

Conclusion

Following the four simple guidelines above can let you share access to various SaaS applications within your organization and yet remain in full compliance with all regimes. the goal is to make security an enabler and not a roadblock. Following these rules of thumb you can have your employees get the access they need and make sure their accounts are not misused. Here is an example — https://youtu.be/GYWWoA4xfP0

In this article we have talked about how account sharing can become a pain and why. We have also outlined 4 simple rules that if followed will help you share access and still remain in compliance with various regulations.


Originally published at Onion ID Website.