OWASP LCNC Top 10: Account Impersonation Part 2: Business Intelligence

I recently posted the start of an article about the OWASP LCNC top 10 security risks.  In that introduction, I suggested that one of the current limitations of the current list is it focused on LCNC as an umbrella, and until we get specific, we cannot also define actions to remediate the risk.  

In this part-two of the article, I want to continue looking at the first risk identified Account Impersonation, but with a focus on one specific domain: Business Intelligence.

Account Impersonation within Business Intelligence

As with all domains, account impersonation occurs when you do not know the user acting within your systems. 

Presentation scenario / Attack scenario

Within the BI world, the primary way this can occur is when accounts are shared.  That can be a planned sharing (cost savings on licenses where all users from a department share accounts) or unplanned sharing where one user has shared their account with another user without permission.

Risks

Before we discuss how to remediate account sharing, let’s discuss why it matters. To do this, I will present a few scenarios that can occur when accounts are shared.

A user just ran and downloaded a report of all your customers and their contact information.   Was there a valid business reason, or was it the employee who quit later that day and went to a competitor? If you don’t know who ran the report, how can you follow up to find out?

That same employee that quit was part of a group using a shared account.  Even though you disabled their account, can they still access your BI system using the shared credentials?   Depending upon where it’s hosted and how it’s set up, they may.   What other information do they still have access to, and what risk does it present?

There are many more, but I hope these two are enough to discourage account sharing.

Remediations

1. Have a policy against account sharing. 

To begin, let’s start with the basics.   If you don’t already have one, put a policy in place preventing account sharing. 

If this began as a cost savings (planned account sharing), I hope the risks outlined above make it clear the savings are not worth the risk.    If it’s unplanned account sharing, a clear policy against account sharing is also needed, and if it has teeth (employment termination) can be a tool to prevent/ limit sharing.

After that, I recommend user education to share the new policy.   Help your community understand why this change is occurring and why it matters.   Perhaps mandatory training (sorry, I know we all hate them, but they have purpose), an email campaign reinforcing, or other.  Regardless of how, you need to get the word to your users about this policy, the risks, and consequences if not followed.

• User Audit

Great, so your policy is in place, now it’s time to fix any share user accounts.   Check all users of the BI system.   Are the users named users (e.g. not Finance User 3)?   Are they all tied to an active employee?   Any accounts that are not should be disabled. 

If this is the first time doing this, get ready for a flood of calls from users who “lost access” to their reports.  Use this as an opportunity to understand who really is accessing your data and to introduce/reinforce the policy against account sharing.   

Keep track of who called with lost access?  What reports were they accessing?   Who gave them access? 

Use this information to determine if they really need access, and regardless of if they end up getting a named user account or not, reinforce account sharing is not allowed.

This type of audit should become part of a periodic check.   If you have a Center of Excellence, this should be added to their responsibility, with clear expectations of frequency and reporting of results.

• Monitoring

Policy and audits get us a long way down this road, but not all the way.   Despite these actions, it’s likely there will still be users that share accounts.    How do you find out when this is happening so you can act?

A good step is to track login data and use it to find “anomalies”.   Are there multiple concurrent logins?  Can you tie those to user devices?  If so, was it one user checking their phone and desktop, or two different users?   What about logins from different locations within a short period of time?  Could the same user login from two different offices within a short period of time?  

Is it just me or is there is something beautifully symmetric about using a data analysis tool to track data anomalies of those accessing the tool!  Ah, symmetry.

A better step is security monitoring tools designed to track these types of scenarios an others.   Maybe it’s a tool your IT department already has, or perhaps is a purpose built tool designed specifically for LCNC like Zenity  (sorry I cannot help but give Zenity a plug as one of its founders Michael Bargury has been so instrumental in leading the LCNC to 10 effort).

Wrap-up

I have two thoughts as I wrap up this look of Account Impersonation within BI. 

First, I would like to make a request for your help.   Are you using BI?  Have you experienced other scenarios where Account Impersonation is an issue?   Do you have other tools/methods to identify and remediate Account Impersonation?

Please let us know so as we continue to build out the OWASP LCNC top 10, we can add more value to the community.

Second, there are generally three remediation areas for all 10 risks: training, COE controls, and monitoring tools.  It wasn’t planned, but it’s interesting that this first risk and domain ended with controls in each domain.  I expect as we go through other domains and risks, this will be a common theme.