Reading between the lines of the US Homeland Security data breach

In January 2018, the US Department of Homeland Security (DHS) announced a data breach involving the personally identifiable information (PII) of 246,147 current and former DHS employees. The information included social security numbers, names, dates of birth, positions, pay grades, and work locations. Basically, a database of confidential human resources information. A former DHS employee had stolen the database and DHS investigators uncovered the theft in May 2017, as part of an unspecified criminal investigation.

In reaction to the breach, the DHS Office of Inspector General (OIG) said that it has implemented the following:

  • Placing additional limitations on which individuals have back end IT access to the case management system
  • Implementing additional network controls to better identify unusual access patterns by authorized users
  • Performing a 360-degree review of DHS OIG’s development practices related to the case management system

Based on the above we can read between these lines and make some educated guesses about how the breach occurred. It’s always important to analyze data breach information and adapt our security practices; we commend DHS for doing so quickly.

1 There are ‘insiders’ and there are ‘INSIDERS’

The data was stolen by a former employee who had full access to production database data. We don’t know if the production data was actually stolen from the live environment, or if they were using real data in a development environment (see the third bullet below). Regardless, administrator accounts need to be tightly controlled. Limiting who has “back end IT access” is a good step, but it’s not the same as limiting what someone with IT access can do. IT admin accounts are a favorite for malicious insiders and outside attackers. Limiting access to these accounts generally keeps the honest people honest, which is not enough to stop determined individuals with malicious intent. To do that, you need to prevent the exposure of sensitive data to the IT admin accounts, while still allowing admins to do their jobs. These days, that’s not as hard as you might think.

2 Eliminate reactive thinking

We don’t know what controls the DHS had in place before it discovered the breach. But, the fact that it added controls in reaction to the breach indicates they weren’t where it wanted them to be. This is usually the case. I’m not convinced that network monitoring is going to make the DHS better equipped to stop data breaches in the future. Enterprises have been deploying network monitoring controls for well over a decade and data breaches are still increasing. We must stop relying on reactive monitoring technologies. The best way to eliminate the damage from a data breach is to eliminate the ability to steal usable information. That will require proactive data security controls (encryption, tokenization, etc), deployed proactively.

3 Policies are not a control

We’re glad that the DHS is making it a priority to review its development processes to find areas to increase security. This is certainly time well-spent. But, it has to be done with full recognition that policies are not controls, and that people are fallible. In this specific case, not only are people fallible but software developers are creative and under constant pressure to meet deadlines. That work environment actually encourages users to circumvent security procedures to save time. The reality is development practices should be out-of-scope for sensitive data. Enterprises can and should develop software without using live data. Automated controls should be in place to make sure that PII is not used in non-production environments. Ever.

The DHS has a lot of smart and hard-working information security people. I’d be willing to bet it is doing a lot of things right, probably more so than a typical enterprise. The problem many enterprises have it they are trying to adapt network controls for securing data. These controls and approaches were originally intended to secure bandwidth, which made sense because that’s what attackers wanted at that point. Today, however, attackers want data – any and all data they can steal and misappropriate. We have to stop applying a network security mindset to data security, and start taking a data-centric approach.