Later analysis of the IRS attack brings out some important issues that you need to consider as part of your development efforts. The first is that you really do need to expend the effort to create the most secure environment possible. Many of the successful attacks use simple methods to obtain the desired result. Training really does help reduce social engineering attacks, updates really do help close security issues that a hacker can use to access your system, good programming practices keep hackers at bay, make applications easier to use, and reduce errors that result in security issues. All of these methods help you remain secure. However, remaining vigilant is important too. Monitoring your application and the libraries, APIs, and microservices on which they depend are all important. Despite protestations to the contrary, the IRS probably could have done more to prevent the breach, or at least mitigate the results of the breach.
A focal point of the analysis for me is that the IRS currently has 363 people working security and a budget of $141.5 million to ensure your data remains safe. The author is a bit harsh and asks whether the IRS Commissioner Koskinen thinks his people are stupid because he keeps making the claim that these hackers are quite skilled. Yet, the hacks used are really quite simple. Breaches happen to every organization at some point, no matter how much money you want to throw at the problem. Organizations get blindsided because hackers attack from a direction that is unexpected in many cases or the organization simply isn’t keeping track of the current threats. Again, I’m not heaping insult on the IRS, simply pointing out a problem that appears common to most of the breaches I read about. What is needed in this case is a frank admission of the facts and a whole lot less in the way of excuses that simply make the organization look weak or stupid anyway.
The IRS, like many organizations, later came back and increased the tally on the number of individuals affected by the breach. This is another common issue. Instead of investigating first and speaking later, many organizations provide numbers at the outset that really aren’t based on solid facts. When an organization has a breach, the public does need to know, but the organization should wait on details until it actually does know what happened.
The application that caused the breach is now dead. It’s a demonstration of a final principle that appears in many of my books. If you really want to keep something secret, then don’t tell anyone about it. Breaches happen when data is made public in some manner. Yes, it’s convenient to access tax information using a web application, but the web application will be breached at some point and then the confidential details will appear in public. Organizations need to weigh convenience against the need to keep data secure. In some cases, security has to win.
The more I read about security breaches, the more convinced I become that they’re unavoidable. The only way to prevent data breaches is to keep the data in a closed system (and even then, a disgruntled employee could still potentially make a copy). Being honest about data breaches, providing the public with solid facts, and ensuring remediation measures are effective are the only ways to control the effects of a data breach. Let me know your thoughts on this issue at John@JohnMuellerBooks.com.