“We are delighted to announce that starting January 1st, all frontal services provided by our company will be given by male representatives.” Wait, what?
Imagine this post on your company’s Twitter page. Bad for business, isn’t it?
Fortunately, Jamie, your Social Media Manager, has no intention of posting it. But, the malware that stole Jamie’s password, does. Unfortunately, you are probably not well protected.
You did invest and buy those three new nifty systems, and they are hard at work securing your perimeter. But they have a blind-spot. These systems are focused on Active Directory (AD) privileged accounts, since they hold the keys to the kingdom. Jamie’s account is monitored as well, but without that extra Admin flag, its 3 AM login from an odd computer would be prioritized just low enough to not be immediately addressed by the SOC team.
It doesn’t have to be this way, does it?
The business privileges blind spot
The security world is centered around AD admins, and for a clear reason. Most of the security toolset at hand, targets monitoring and enforcing these privileged accounts. But, your purpose is to protect the company’s business, not its infrastructure. Getting admin credentials is just the attackers’ means, not their goal.
The Social Media Manager role is a business privileged one. They have high permissions on crucial systems. Here are other examples:
- Payroll Manager
- SWIFT Account Operator
- Technician with access to nuclear centrifuge control system
These business privileged roles are not an inherent part of the domain infrastructure, and therefore policing them is limited. Unfortunately, most classic security tools follow suit. There are dedicated solutions for some use-cases (SWIFT in particular), but they commonly live in parallel to the AD security systems.
We, as an industry, need to broaden our horizons. The first thing is awareness. We - CISOs, Microsoft and vendors - need to start talking about it. Talk, though, is not enough. Without a supporting toolset, that talk would die out and the issue would soon be forgotten.
Security systems give great weight to AD admins. There is no reason business privileged roles should not receive the same treatment. Yet, there is a challenge.
Identifying business privileged roles
Privileged accounts are easy to detect, as they have special AD attributes. How do we find out which accounts have special business privileges? AD has a lot of metadata. Admins make good work of managing the organization’s directory, and normally there would be valuable information in some of the many possible attributes: department names, titles, manager fields, mail delegation, etc. Additionally, many companies use some type of HR system, which exposes an API, and can shed a lot of light on the business context of the organization, and on the concrete roles of employees.
This is a lot of data to work with and assessing of which accounts are business privileged. True, this data is very dynamic, and we can’t guarantee a 100% success rate. However, our experience shows a high rate of classification using this method.
Furthermore, these results are not forced on the user - they can be prompted to confirm them, or change them manually. This engagement goes a long way towards helping you monitor business privileged accounts.
Let’s assume the worst: all attempts to automatically classify these roles have failed. Even then, a security product must allow the user to easily comfortably mark them manually. We need to encourage and support that mindset if the user chooses so.
In version 2.2 of our product, we have added business privileged roles. We have seen some similar moves elsewhere in the market as well. The black hole of business privileged is slowly beginning to be addressed.
As security experts, it is our role to champion the cause. As product vendors, it is our goal to provide the security personnel with the tools that will cause Jamie’s incident to appear in alarming red at the top of the dashboard.