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
Read more about security in Computerworld's Security Topic Center.