When Access Controls Go Wrong: What We Can Learn From the OPM Breach

Published: 26 June 2015

Cathering Jamieson

By Catherine Jamieson

Details are only just starting to filter through about the true size and scale of the recently discovered data breach at the US Office of Personnel Management (OPM). But if the reports are correct, it’s already one of the most damaging incidents of its kind in the long and sorry history of government data breaches.

Poor security around privileged accounts appears to have directly enabled hackers to steal some of the most sensitive information ever grabbed from US government data stores.

Let’s take a look at what lessons UK organisations can learn from the mistakes made over the Pond.

What happened?

A breach of the OPM’s systems was first detected back in March, when a newly installed security system raised the alarm. At first it was thought that somewhere in the region of four million records were compromised. Then things got a lot worse. It emerged that hackers had also managed to gain access to extremely sensitive data on staff applying for security clearance roles in military or intelligence positions – the so-called SF-86 form. This contains personal, medical and financial information and could be used by a foreign state to blackmail and coerce government employees and even recruit spies. Aside from that, it would be valuable information to use in follow-up spear phishing attacks.

It’s now thought that the breach toll could have risen to as many as 18 million current and former government employees and their families.

How did it happen?

A two-hour hearing before the House Oversight and Government Reform Committee last week revealed some details. OPM chief information officer, Donna Seymour, crucially admitted that the attackers had gained “privileged user access”. Then Department of Homeland Security assistant secretary for cybersecurity, Andy Ozment, claimed that encryption of the stolen data would “not have helped in this case” because the hackers had gained user credentials to the systems that they attacked, most likely through social engineering. We can probably deduce that these credentials were for privileged, or admin-level, access.

Why are privileged account credentials so highly sought-after by attackers? Because they provide access straight to the information they want, without needing to escalate privileges. These accounts are usually less bound to scrutiny by senior managers, after all, the IT department is usually left to its own devices because it can be trusted, right? And unusual account behaviour – for example, large volumes of data downloads – doesn’t ring alarm bells on IT user accounts, so there’s a better chance of getting in and out before being caught.

Furthermore, a OPM contractor told Ars Technica that he worked on a project with a Unix sysadmin physically located in Argentina, while his colleague sat in China. As we’ve discussed before, in relation to the string of attacks on POS systems in the US, organisations must extend the same strict IT access policies to their contractors and ‘trusted’ third parties.

Lessons learned

We should all think more carefully about how we secure privileged accounts. Osirium’s answer is Privileged User Management: technology which ensures device credentials never pass through the client’s system, so they can’t be lifted by social engineering, hacked or stolen, or misused by IT admins. Our Privileged Session Management system, meanwhile will record, store and playback privileged account activity for security and compliance purposes.

Here are some more take-aways from the OPM debacle:

  • Invest in tools to gain greater visibility into privileged accounts, to better understand when unusual activity takes place
  • Enforce strong password management as standard and ensure IT admins cannot make exceptions
  • Try to prevent “over-privileging” of junior admin staff
  • Operate policy of “least privilege” when it comes to admin account access
  • Extend all strict access controls to third party providers
  • Vet all third party providers strictly before hiring and conduct regular security audits
  • Release Date: 
    Friday, 26 June 2015
    Article Type: 
    Blog Post
    Catherine Jamieson