Was the largest breach in history a misconfiguration problem?

Earlier this week, I heard a fascinating interview with the former Chief Information Officer of Equifax, Graeme Payne.  If you are unfamiliar with Graeme, he was the scapegoat for the Equifax breach; described in Congressional testimony as “the human error” that caused the breach.  Graeme, however, is a true gentleman who is very gracious about his situation.  He explained that the servers that were breached were “under his watch”, so it makes sense that he was the person who was ultimately held responsible for the breach.

In Graeme’s recently published a book, The New Era of Cybersecurity Breaches, Graeme describes the events of the Equifax breach and offers practical steps to secure a company from the same fate that was suffered by Equifax.  The only reason I have not yet read the book is because I did not know it existed.  Now, it is on my wish list, and, if the description lives up to the book contents, I anticipate an excellent read!

One item that struck me as peculiar during Graeme’s interview was that he stated, contrary to all the reports about the breach, that the breached server was patched against the Apache Struts.  To be clear, all of the news reports indicated that Equifax received notice of the vulnerability, the available patch, yet did nothing to prevent it.

I asked the following question: Didn’t you scan the servers after the patches were applied?  (It is excellent that BrightTalk offers interactive webcasts like this.) Graeme responded that they scanned the servers for vulnerabilities, and the patch was reported as successfully applied to the server.  How is that possible?

A further discussion ensued, in which the importance of authenticated versus unauthenticated scans was mentioned.  It even drifted into the idea that a company should use two different scanners!  We are not all the size of an Equifax corporation.  Running two scanners is simply unmanageable for many medium sized enterprises.

I posted a follow-up question: How did the vendor of the vulnerability scanner respond once the breach occurred.  Unfortunately, Graeme was not at liberty to discuss that.  (If you are unfamiliar with the legal system, it probably means that the terms of his dismissal are confidential, and he cannot discuss various topics, such as any impending action against a vendor.)

Whatever the vendor’s response, it doesn’t matter.  What matters is that the largest breach in history (to date), may not have been the result of human error or negligence.  It may have been just another case of a misconfiguration problem, this time, with a vulnerability scanner.

Given the recent breaches that have involved cloud misconfigurations, it is important to remember that these problems can still exist within the cozy confines of an organization. 

Graeme seems to be doing fine in his new existence, not as a scapegoat, but as a Phoenix.  I empathize with how he was treated, and I am confident that I speak for all the security community by saying, we wish him well. 

      

Article Link: https://feeds.feedblitz.com/~/608389106/0/alienvault-blogs~Was-the-largest-breach-in-history-a-misconfiguration-problem