Creating resilience through security cells

Published: 28 October 2016

Andy Harris, Creating resilience security through security cells

By Andy Harris

It's quite remarkable to see just how deep today's data breaches go. The following issues are the main contributors:

  • The desire for frictionless movement of staff through the IT infrastructure. Every login or need to remember yet another password creates a barrier to getting work done. Getting stuff done is key to business, therefore security and business are in conflict.

  • Using the same password, sharing passwords, default passwords. If an attacker (internal or external) acquires one of these passwords they can move through the data assets of a business, moreover the attacker is hard to distinguish from legal access.

  • The wetware behind the keyboard. These can be easily fooled and caught off guard, and most of the time they address their business responsibilities expecting that you are responsible for all the security including their mistakes.

  • Protecting the front door then ignoring the supporting infrastructure. The classic example is focus on the Linux and Windows systems with less focus on the Hypervisor and even less on the NAS and SAN systems. The further away a system is from the end-users the less likely the passwords are to change. It's not uncommon to find SAN's with passwords more than 5 years old, new SANs often inherit old passwords as they are used to replace outgoing systems.

  • Passwords that are hard won. There are systems that are naturally secure by design. In the typical cut and thrust of a busy IT department no-one has the time to digest all the subtleties, especially where more than one vendor implementation is involved. Therefore there is a lot of head scratching before the systems work together. Once they are working there is an understandable reticence to change anything. You need to understand that attackers are specialised and have the time and motivation to understand all the interactions and how to subvert them.

  • Legacy and patching. These days the new hotness can become the old busted in 6 months. Suppliers (including ourselves!) tend to have a policy of supporting three releases back. So in this 'bi-modal' world it could be 18 months before a system is outside of its support cycle.

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.

Release Date: 
Friday, 28 October 2016
Article Type: 
Blog Post
Andy Harris