October 22, 2012, 11:17 AM — No business wants a customer complaining about security weaknesses in its products. If that had been the extent of what happened to my company last week, it would have been bad enough. But it was worse, because in this case, a customer skipped the normal means of reporting a problem and brought a concern about one of our software products directly to one of our senior vice presidents. Instant escalation.
Trouble Ticket
A customer finds serious security weaknesses in one of the company's software products.Action plan: Educate the development team.
Since I'm the security guy, this became my problem. Never mind that I'm not well versed in application development. Forget the fact that for the past year I've been saying we should pay more attention to the security of the software we sell with our hardware. We have a problem, it involves security, so I need to fix it.
Not that I see this as unfair. I am the guy in this company whose job it is to think about security. While I, like most security managers, focus on things like the corporate network, the protection of intellectual property and public-facing Web applications, I can't ignore that our business includes providing products that also need to be secure. Naturally, most of my attention in that area has been focused on assessing and providing security recommendations for our flagship product. But we have a lot of other software products that don't sell as well or make as much money.
It was one of those less popular software packages that caused our recent problems. A large customer had purchased it, installing both a Web front-end application and a back-end SQL database. Not unusually, the customer had to comply with some industry guidelines, and an assessment of our application turned up some glaring security issues. For example, the application wasn't sufficiently encrypting passwords. That's embarrassing, since proper protection of passwords should be a no-brainer for our development team.
The best practice is to encrypt passwords with a one-way hash and then utilize a random "salt" to ensure that brute-force attempts to crack the password would be extremely time-consuming. Our application only hashed the passwords, meaning they could be easily decrypted.
The customer also found several other problems. Most significantly, our software was vulnerable to SQL injection attacks, in which the back-end database would serve up sensitive data. In all, the problems gave the impression that we don't take security seriously.
Educate to Mitigate
