The Assumption of Breach Theory

We all now realize that Bob Mueller’s classic admonition is correct. It is not whether we will be breached, it’s when.

Given that we will all be breached at some point, adoption of the assumption of breach theory should be mandatory cybersecurity policy for all companies big and small. This theory holds that any attacker with enough time, commitment and resources will eventually be able to get into any network. The best measure of an effective information security strategy then, is the ability for a company to detect when an incident happens and the speed it takes to effectively respond.

In 2017 the average time to detect ran anywhere from 8 to 12 months from the date of the initial network penetration.

To make matters more difficult, it has taken some companies several years to disclose the breach publicly. Yahoo (attacked in 2014, disclosed in 2016), LinkedIn (breached in 2012, disclosed in 2016), and Myspace (hacked in 2013, disclosed in 2016), and in terms of big losses, Equifax leads the recent spate of tardy breach notifications with a 5-month delay.

In the case of Equifax, according to the Government Accountability Office (GAO), the attackers initially breached their online dispute portal, and then were able to gain access to the organization’s core database for a period of almost three months. We know that the initial breach was due to the company failing to patch the Apache Struts 2 framework running on the online dispute portal, but that is not the point. It turns out that evidence of the breach was only noticed by IT staff after a long-expired certificate on security equipment, which was supposed to be monitoring outbound encrypted traffic, was updated.

The lack of a certificate meant that the device had effectively not been working for 10 months.

It was only then that the company belatedly started to address the attack, but didn't know how much data had been taken, nor how the breach had occurred. On August 2, 2017, Equifax finally got around to notifying the FBI 5 full months after they detected that a breach had first occurred.

There are myriad and obvious reasons why companies have historically hesitated to announce these things ranging from frozen fear to concerns about the risks of providing false or misleading information to the public because they are making statements based on incomplete data. All network intrusions may not be breaches. It does take time, effort, and good forensics to determine whether a data breach has occurred and, if so, it takes more time to correctly identify the data was affected. If companies notified the public of a "data breach" every time they had an incident or intrusion in their network, it would become a steady stream of nonstop news.

That said, with the new GDPR “72-hour rule”, and the follow-on legislation that is sure to be enacted around the country this year, companies no longer have the luxury of delaying their announcement once a breach was determined to have occurred. In this new era of transparency, all companies would be smart to create a specific narrative in advance of that moment when (not if) an incident (breach) occurs and it should minimally contain some key elements.

Among them, a statement that explicitly says you have implemented security policies that include threat-based assessments around the types of data you store and process. Stating also that you regularly perform these assessments and they are subject to independent audits will make it clear that you have reasonably prepared for a potential attack.

You should also point out that you have taken reasonable measures in accord with best practices for data protection and risk management principles to protect your data from the threats that are most prevalent to businesses in our domain. It would also be a good idea to include the specific process and technology protections you have in place to prevent a breach and that if an attacker is able to gain access into your network, they would have to have taken extraordinary measures to bypass your security. This implies that you have applied reasonable diligence to protect your network and information assets from attack.

The whole point of a prepared narrative is to dispel any notion that you are lazy, careless, reckless, incompetent or just plain stupid. Failure to apply patches when called for, the absence of a continual vulnerability monitoring and management system or the lack of a comprehensive threat detection infrastructure doesn’t happen under your watch because you are in complete compliance with all the reasonable practices and guidelines spelled out in one or all of NIST, COBIT, ISO, GDPR, NYDFS, etc., frameworks or regulations. Identifying which frameworks you are following is also a good idea as you will want substantial evidence that you are a responsible corporate custodian of data privacy.

This by the way, will also serve you in a variety of other ways that relate to your competitive advantage in your field. Since the facts are that most companies fail to protect their information assets properly, your willingness to spend vast sums of capital and go to great lengths to establish maximized cybersecurity and data privacy protection will position you favorably among existing and new customers. You will be perceived as the good guy while your competitors will be perceived as careless, money-grubbing capitalist monsters.

No one is suggesting that anyone can prevent a breach or a cyber-attack. The liability for such an attack increases however as evidence mounts to suggest that you didn’t act to implement the basic levels of protection for the data you store and process, diligence around assuring that the third-parties to whom you have granted access to your networks have in turn implemented sufficient data and network protections to keep your data safe, and that you have failed to implement reasonable policies and technological defenses against cyber-attacks and breaches.

When you do get breached and a client or regulator or opposing counsel representing a bunch of angry class action plaintiffs assesses what you have and have not done in the look-back, and it is discovered that you have failed to exercise reasonable pro-action, the case against you will become very difficult to defend.

So, using that assumption of breach principle and preparing for the inevitable with that narrative created in advance of the actual incident will go along way to lowering the pressure that will begin to rise immediately following your announcement.

Of course, just having the prepared narrative all by itself will not stand alone. You will have to have actually done what you claim you have as well.

As we saw with Equifax, the Apache Struts vulnerability was not properly identified as running on the online dispute portal when patches for the vulnerability were installed throughout the rest of the company. In addition, databases were not properly segmented, enabling the attackers to access multiple databases during the attack.

And data governance was also terrible, especially the storage of unencrypted credentials for internal databases. And finally, Equifax’s lack of restrictions on the frequency of database queries allowed the attackers to execute approximately 9,000 such queries which if monitored would have popped out immediately as that many queries is far outside the bandwidth expected through normal operations.

All of which could have been easily handled with proper hygiene, adherence to best practices and diligence in execution.

Easy to talk about, but for some, not so easy to do.