Wells Fargo Data Breach: what have we learned?
If you subscribe to my link feed, you will have seen the post from The Bankwatch that I shared earlier today. If you have not yet subscribed, get to it. Or, go read the entirety of the post here. As the author states, there isn’t a whole lot that we know about the Wells Fargo breach as of yet. In fact, there has been a relatively light amount of coverage. I have only seen the Finextra post and the post referenced above. This, in and of itself, is intriguing.
It is, as always, rather difficult to determine what lessons should be learned without the full picture. In the case of Wells Fargo (as indicated both of the links above) the issue seems related to lost hardware that stored sensitive customer data. This is, clearly, not a good idea.
But, to me, it brings up a bigger issue.
In discussing security with software companies, I can only provide advice and my interpretation of the standards that are set forth for developing secure payment software. I am not, and do not pretend to be, a QSA or a definitive resource on meeting all PABP/PA-DSS requirements. In these discussions, however, I have noticed a theme. In many cases, security seems to be an after-thought.
Perhaps that is too strong.
Software Companies know the importance of security, but they are faced with the challenge of how to implement their software in a fashion that meets all security standards and this decision process is often left to the end of the development cycle.
Quite frankly, security is hard. Protecting, in the case of payments, cardholder data is of the utmost importance. But the requirements surrounding payment software security extend beyond just the method of persistence and encryption. (If you want further detail, I recommend this excellent blog post on PABP Compliance by Dave Herrald.)
So what did the Wells data breach remind me?
Quite simply, security is not and cannot be treated as a simple check-box in a project plan. Rather security must be treated as a core element of product planning, feature discussions, point releases, etc. In essence, security should reside in the DNA of your company.
Fortunately, you don’t have to go it alone. There are a myriad of resources that can help you simplify both the process and to determine the appropriate way to meet the minimum requirements. Leverage resources…don’t attempt to rebuild the wheel.
What’s your perspective? Agree? Disagree? Anything to add? Critiques?
The comment form is below. . .
August 14, 2008