I am sure most practitioners by now have probably heard about the Equifax breach. If you have not yet, get ready to hear about it nonstop—probably for the next year or 2 at least. Why? Because it eclipses even the 2013 Target breach (which people are still talking about) both in number of individuals potentially impacted (143 million) and the potential sensitivity of the records involved (which include social security numbers, dates of birth, addresses, credit card numbers and driver's license information.)
The details of this are still unfolding, so we do not have the full picture yet. It will probably be a few months before we do. But in the meantime, I think we know enough to highlight at least a few lessons learned. Specifically, things that it behooves organizations to have in mind as they plan (and ideally exercise) their own incident response strategies. We can use what happened with Equifax as an illustration of why these principles are a good idea.
Since it is early in the cycle, it bears noting that a grain of salt should be applied as we go through these. After all, emerging details might change our understanding of specifically what transpired. But in the meantime, there are a few items that, based on what we know right now, are useful takeaways for other organizations planning their own response processes.
Lesson 1: Application Security
The first takeaway is based on what we know about the root cause. We do not fully understand what happened, but we do know that it was caused by (per Equifax) a “website application vulnerability.” It is unclear whether they mean an issue in the underlying web server (or supporting software) or an issue in the application running on it, but we know that organizations tend to struggle with application security—so I do not think anyone would be surprised if it is the latter. This event should, therefore, serve to underscore the importance of application security generally, i.e., having a robust development and release life cycle, “building security into” production applications, and the importance of robust testing of both applications and the underlying technical substrate upon which they reside.
Lesson 2: Optics
The second thing we can learn is about management of the optics during the incident response process and the breach notification process. Equifax is taking a bit of flak in the press and on social media because 3 key executives (including the chief financial officer and president of US operations) sold more than US $2 million worth of stock in August. That is after the breach was discovered internally, but before it was disclosed to the public. Equifax told the press that these executives had no knowledge of the breach at the time (because otherwise it would be illegal), but had they known, Equifax could have avoided what is bound to be a source of serious bad press for them in the coming months.
This is why it is a good idea to foster and maintain clear, open and timely communication channels between all areas (including executives and legal counsel) as incident response events unfold. Additionally, the point has been made in the press that the free identity theft protection offered by Equifax requires those accepting that offer to give up their right to sue or participate in a class action. Those are not great optics either. Consumers are likely angry about this, so hanging out an offer “with strings attached” is potentially caustic.
Lesson 3: Encryption
It probably stands to reason that, had the information that was compromised been encrypted, it would have been included in the information made public about the breach. To the previous point about the optics, stating that the information was encrypted would defuse quite a bit of Equifax’s current public relations nightmare. Based on this, we can probably assume for now (though later facts might certainly indicate otherwise) that it is not encrypted.
Encryption of data at rest is not difficult to deploy nowadays; that is true whether the data are structured or unstructured. So, if you have a database of millions of social security numbers, bulk storage of files containing financial information or any other situation that could be explosive from a privacy standpoint, asking yourself why those data are not encrypted is probably a useful question to ask. There are absolutely reasons where it can be challenging to implement encryption, but balance that against the explosive potential consequences of a large-scale breach.
Lesson 4: Be Alert to Deadlines
Equifax is also taking criticism in the press about the time that it took to notify impacted individuals. They discovered the breach on 29 July, but we are only learning about it now. Keep in mind that some jurisdictions have a specific “clock” by which you must notify customers (e.g., Florida, USA, is 30 days—or 45 with an extension). Of course, law enforcement may direct an organization to delay that notification (we do not yet know if that was the case in this situation or not), but it is helpful to take these deadlines into account, include them in incident response planning and put mechanisms in place to make sure they are followed during an incident when stress levels are high.
There are likely numerous other lessons that will surface as events unfold. If so, there are likely numerous other learning opportunities that will surface. We will just need to watch, wait and analyze them as they come.
Ed Moyle is director of thought leadership and research at ISACA. Prior to joining ISACA, Moyle was senior security strategist with Savvis and a founding partner of the analyst firm Security Curve. In his nearly 20 years in information security, he has held numerous positions including senior manager with CTG’s global security practice, vice president and information security officer for Merrill Lynch Investment Managers and senior security analyst with Trintech. Moyle is coauthor of Cryptographic Libraries for Developers and a frequent contributor to the information security industry as an author, public speaker and analyst.