Published: 28 October 2016
By Andy Harris
It's quite remarkable to see just how deep today's data breaches go. The following issues are the main contributors:
That list can be scary and guilt provoking, in fact rather typical of how the the cyber-security industry sells you products. Well, it's not just you, it's us as well, we face all those issues as well, we're under constant attack as well.
Your Infrastructure is like any big critical system, it has to fail gracefully. It has to absorb the inevitable knocks with a repairable nature. In previous presentations we've called this the security cell approach. You could think of it in the same was as a car. When a modern car is involved in a collision it fails cell by cell. Each cell absorbs collision energy, the subsequent cell absorbing more than the last, the goal in to protect the occupants.
If too many people have domain administrator access then your cells are too large. A compromise will go deep.
Of course a risk profile approach makes the most sense. If 86% of all passwords are being stolen from desktop why let them go anyway near the desktop in the first place. If 10% of accounts are compromised by phishing why let the users have passwords in the first place?
It's the cognition problem, you're overloading the wetware! They react by recording the passwords in files on the desktop. If you give them a complex password policy to follow they will reduce it to patterns. As soon as they use a pattern their passwords are vulnerable to rainbow table attacks. (they start using common long words so you've reduced the problem from a multi-character brute force to an ordered token brute force).
Removing the password problem from your people reduces the risk by around 96%, and that's significant.
By taking an 'Identity In Role Out' approach we gain a significant security cell. The actual accounts used on the systems can be valid for just that system, not all the others. So access to one system does not confer the right to wander around the others at will.
Why do our users need access to systems in the first place? A little workflow analysis will quickly reveal that most access is task based in nature. If we wrap up and parameterise those tasks we can use an 'Identity In Task Done' model. Now your staff get what they need done much faster with the benefits of more security and less errors.
So lets look at the access needed to sort out the special cases, changes and reconciliation. These need full access, but there is always a reason, and that reason can be managed as an incident or change. So why have an account enabled or grant access to a role if there is not a reason. Your ticketing system can be used to drive your access profiles to enable access only when there is a reason for it. That's a real reduction in attack surface and a great security cell, even if an attacker has all the credentials they can't use them without a valid business reason. This is the real essence of Privileged Access Management.
To address the issue of legacy systems, there are two levels of virtualisation. The first is straightforward: run the system on its own VM, and protect it with firewalls etc. You can still use the system and the firewalls will help with the protocol sensitive weaknesses that are discovered from time to time.
Considering the second type of virtualisation, we've realised that legacy management tools are also a key part of the ongoing management. We've created MAP server as environment to virtualise application management tools to keep them in their own safety cell as well.