07 June 2013

Why CIOs Shouldn't be Afraid of Shadow IT Organizations


I heard a little story the other day. Let me run it by you to see if you've ever come across this.

A small group of people with a big problem signed up for salesforce.com. They became proficient using and administering it. It was a huge productivity boost to one of their critical business process. Things were going so well that they flew too close to the sun. The CIO and the corporate IT organization discovered that there was a shadow IT organization within their walls.

One of the greatest fears of a CIO or VP of IT is when a shadow IT organization purchases, implements, and starts using a system that they have little knowledge or control of. Movement of mission critical apps to the cloud has made this more challenging for CIOs and is often discussed as the 'Consumerization of IT'.

Now the CIO and IT organization are playing catch-up; trying to gain oversight over the shadow IT group to ensure that they follow best practices and official security policies defined by the company. This is where terms like 'segregation of duties', 'least privilege', and 'escalated rights' get thrown around in the game of buzzword bingo. The scary part for the CIO and IT is that they not only need to get up to speed on salesforce.com, but they need to be smarter than the shadow IT organization that has a head start using it.

From my standpoint, this is where understanding how salesforce.com's access management is critical to the success of both groups. You neither want to limit the productivity of the shadow IT group too much, nor escalate their privileges within the corporate IT organization above what is appropriate.

From a process standpoint, there are really five critical steps get control of this situation:
  1. Identify user rights that may violate a security policy if mis-assigned or mis-used. This may vary by organization; however, I typically sum this up in four sensitive security permissions: Manage Users, Modify All Data, View All Data, and Customize Application.
  2. Determine which users have access to these permissions by checking their profiles and permission set assignments. These are the users you will need to monitor.
  3. Reduce your risk by segregating duties where applicable so that users have only what they need to perform a task and nothing more. There are a lot of different ways to do this in salesforce.com. I've blogged a couple different ways worth checking out such as: How Not to Give Out Modify All Data, Reduce Risk Through Re-Certification, and Maker-Checker. I'm also always amazed how few people I talk with know about the Delegated Administration feature.
  4. Create a governance policy that downloads and checks the Setup Audit Trail once per month. Look for patterns that may indicate a compromised security policy. For the most part, this pattern involves either changing the permissions in a profile/permission set or the assignment of any profiles/permission sets that have been identified as a potential security risk. Whenever a questionable activity is identified, flag the user and time in the audit trail.
  5. Finally, check the Login History to determine if the user performing questionable changes is actually a single user or multiple users sharing the same user account. This is easily done by viewing the history of logins for a user and correlating the Source IP, Browser, and Application fields. If there is a lot of variance, they have given their credentials out to other people. Once a user voluntarily gives out their user credentials, you lose the ability to audit their actions. Plus, it's actually a violation of the terms of service.
Most of the conversations I have with CIOs and VPs of IT start from a place of fear but in reality, there are a lot of proactive and reactive ways in which they can limit their risk. 

As Sun-Tzu once said, "If you know the enemy and know yourself, you need not fear the result of a hundred battles."

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.