Security Manager's Journal: Security has to extend to your customers
When a security manager's company sells software, he can't ignore the potential vulnerability of those products.
Computerworld - 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.
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 firstname.lastname@example.org.
Join in the discussions about security! Computerworld.com/blogs/security
More by Mathias Thurman
- Security Manager's Journal: Stopping vendors from making us a Target
- Security Manager's Journal: Thousands of dollars in phone calls? Management hates that.
- Security Manager's Journal: Another step toward eliminating data loss
- Security Manager's Journal: Siccing MDM on personal mobile devices
- Security Manager's Journal: An admin surfing on a server? That's a big no-no
- Security Manager's Journal: Time to tweak the security policies
- Security Manager's Journal: Found: 30 unmanaged servers that shouldn't be
- Security Manager's Journal: The ins and outs of extending DLP
- Security Manager's Journal: Move to hosted email opens new vulnerabilities
- Security Manager's Journal: Two big goals for 2014 budget won't require a lot of money
Read more about Security in Computerworld's Security Topic Center.
- 2013 Cyber Risk Report The "Cyber risk report 2013 Executive summary" presents the major findings of HP Security Research's comprehensive dive into today's cyber vulnerability and threat...
- Why You Need a Next-Generation Firewall This white paper explores the reasons for implementing next-generation (NG) firewalls and lays out a path to success for overburdened IT organizations.
- Path Selection Infographic Path Selection Infographic
- Hyperconvergence Infographic A wide range of observers agree that data centers are now entering an era of "hyperconvergence" that will raise network traffic levels faster...
- Cloud Knowledge Vault Learn how your organization can benefit from the scalability, flexibility, and performance that the cloud offers through the short videos and other resources...
- LIVE EVENT: 5/7, The End of Data Protection As We Know It. Introducing a Next Generation Data Protection Architecture. Traditional backup is going away, but where does this leave end-users? All Malware and Vulnerabilities White Papers | Webcasts