Building a coping mechanism for data breaches

Data breaches may be daily news, but they will always be a significant worry for business stakeholders. It is the IT team, however, that have to deal with the technical side of breaches. Here’s my view on establishing a coping mechanism.

In most of the breaches that we analyse, there is always an element of human failure:

• You are just one stupid password away from a data breach
• Default passwords are asking for trouble
• Build passwords don’t get removed
• Files are not protected
• Users opt to cache passwords in browsers rather than to remember them
• A percentage of your user base will always be fooled by phishing attacks.

Endpoint protection is rarely perfect. Better perhaps to always assume that a Windows system will be compromised at some point, and to remember that detection is typically 100 days after compromise. If it’s not your endpoints, it could be the various third parties that have access to your systems – contractors, consultants, and temporary project-based staff.

Of course, there are the more complex zero-day style attacks but, in reality, these are cracks in the system that are beyond your control. Your people and endpoints are unfortunately the real issues.

Change your password policy

Let’s openly recognise that most password change requests come at just the wrong time for your users; and not just your end users, but your DevOps and SysAdmins too. They are motivated to do a particular task, and then the password change becomes a barrier in doing so. Their previous cognitive load was on the task at hand, and now you ask them to choose a strong password. Mostly they won’t, because they don’t know or appreciate what a strong password is. Often, they get belligerent about security, and choose whatever they can just to continue with their daily tasks.

The more often you ask, the more likely they are to find a pattern that works for their memory and your password policy. In password terms, they start to tokenise – for example ‘Liverpool2018Jan!’ is long, contains upper and lower-case letters, some digits and punctuation. One glance and you’ll see it’s predictable – it’s pretty obvious what will happen in February.

User improvements

Help your employees maintain the security of the business by slowing down the password refresh rate. Choose the passwords for them – one that doesn’t relate to the person but is an easy to remember, complex, password. An even more solid approach is to switch to a task-based system – delegate the task not the privilege. No more direct logins and nothing to phish.

SysAdmin and DevOps Improvements

Again, there are multiple ways to support the security protocols within your business. Stop humans sharing passwords and instead use an established Privileged Access Management (PAM) approach. By separating the people from the passwords, and in particular never letting any passwords near endpoint systems, you reduce the ability to share details to make life easier for temporary (or forgetful) colleagues.

We find that what often works very well is the move to implementing ‘one instance of an identity’. In most computer systems an account can be used several times, so a legitimate user and attacker can have concurrent access. In the ‘one instance’ model any attempt at concurrency will cause disconnections which are a great early warning system. Good PAM systems will map one identity instance through to shared accounts.

In addition, you can record sessions. This has multiple benefits especially when working with outsourcers and third parties on site, such as vendors and contractors. This is the best deterrent for internal wrong doing and also acts as a solid audit process for compliance and regulation procedures.

System improvements

Whilst monitoring access into the systems, it’s important to also bear in mind the systems themselves and the threat they are in the network. Applications that are complex to install on endpoints, in particular those with out of date requirements, could be moved to a ‘MAP Server’ (Management Application Proxy Servers), which would map just the windows back to endpoints rather than have the whole application on end-points, providing less need to access systems and share passwords.

Of equal importance is being careful with APIs, or more precisely scripts and codes. These will often have credentials that can be used by an attacker; whilst Service Accounts often carry some very high privileges. Organisations are often worried about changing them because they don’t know what will fail as a consequence so are knowingly leaving systems open to threats because there is deemed to be no alternative.

In the fast-paced world of business there is constant demand on the IT team to introduce and implement new technologies, but it should be noted that such new systems are not finished when they function properly, but when they are secure. As a result of ‘speed’ to delivery, the cloud is often a work-around to a short term but pressing need for functionality. Check the security protocols of any service provider.

The goal of all these changes is ultimately to remove fragile or brittle parts of the system. End-to-end services should be more shock absorbent, such that the failure of one system doesn’t mean the failure of others. You could think of it in terms of the way a modern car absorbs energy in a collision.

The fear of “how far did they get?”

In the immediate aftermath of a breach it can appear that the attackers had the tools to get everywhere in your infrastructure. The steps above have also been designed to limit the spread of an attack. This means the team can make some reasoned decisions about where to look and what to fix.

Disconnect the networks, freeze the evidence, be quick and be decisive. Take backups of logs, check system configurations and review any databases. If you suspect any endpoints, put them on a shelf and immediately issue staff with replacements.

Although the IT team will bear the brunt of any breach, the business needs to survive. The IT team needs to be able to decide what systems, applications and devices are safe to continue to use; what systems have been compromised in credential terms; and which of the deep compromised systems is critical to business operation. These take the remediation priority.

In most cases, at this point, the IT team will need outside help. Good, fast external help is the best approach, and will be cheaper in the long run than trying to do an internal fix.

Through this process, you’ll find that breach evidence is in fact not laid out in a neat time line. Your team will uncover partial evidence that will lead to widely different conclusions. As time progresses you will get nearer to the real cause and each conclusion is valuable because it will show you any future weaknesses in the network.

Configure your systems to be in resilient ‘security cells’ and give yourself a clearer indication of any potential security compromises. It’ll be a bit more effort, but the outcomes will be way better than buying a bigger firewall.