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
Ever since this was brought so forcefully to our attention, we have held several conference calls and workshops to address the issue. I'm not a programmer, but I am trying to educate the development team.
So far, I have articulated the difference between security features and secure architecture and development. Security features include things like role-based access, support for two-factor authentication, selective data encryption, logging and alerting, session time-outs, integration with Directory Services or SAML, access restriction by IP address, and options for password complexity and management. Secure architecture and development includes properly segmenting the front end from the back end, ensuring secure data transfer, and properly inputting validation to mitigate SQL injection or certain types of cross-site scripting. It also includes protections against buffer overflows and race conditions.
I have also organized on-site training from a third party that specializes in application security development, since I recognize that I'm not an expert in this field.
The best thing I can do is to provide the guidance, training and tools to allow the developers to be successful. But I will also be more aggressive in third-party assessments of all of our applications, not just the flagship products.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com.
Join in the discussions about security! Computerworld.com/blogs/security
Read more about security in Computerworld's Security Topic Center.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.