Information Security

Defending the digital infrastructure


Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Viewpoint: Blame software insecurity on project managers

Blame Begins at Top
I believe Edward Adams' frustrations ("Straw House," March 2007) are misguided. The article pins the blame for security flaws on developers. I believe this is incorrect; it's not the lack of academic security training that leads software developers to write code with holes, but rather the project managers' and systems analysts' lack of security awareness. Security must always flow from the top down.

Customers do not understand the importance of ensuring their products are coded securely. However, as with all too many security related activities, awareness is often not realized until it is too late. Mr. Adams' article would argue that it is the developer's job to make customers aware. I would disagree. It begins with the systems analysts who have the most contact with the customer. If these analysts were to properly communicate that specific functionality would require steps to ensure secure coding, and stood their ground to ensure software was not released until these steps had been met, today's software may no longer be the weakest link.

However, the person most responsible in this equation is the software development project manager, who is responsible for ensuring a project arrives on time and budget. At times, this job calls for crashing the project or altering functionality to meet the confines of these resource requirements. If the project manager allocated the proper amount of development time and money for secure development during the project's initiation, we would not have near the amount of security problems we see today.

I believe Mr. Adams' claims that developers lack security training are incorrect as well. With any academic study I have taken in the field of software development, properly coding software for secure operations is always presented. However, it is not always laid out in such a fashion as, "do these steps for security," but is rather mentioned as a process to ensure your code is well formed. Regardless of how information assurance topics are presented, they are helpless in effectively implementing those techniques without the proper support at the top.

Scott Christiansen
IT Director, Leo A Daly Company

Key Kudos
Thank you for your recent article on encryption ("Encrypt It," February 2007). While cryptographers have always been aware of the issues with key management, it is gratifying to note that the security press is starting to pay attention.

I wanted to bring your attention to an effort to standardize symmetric key-management services, being driven by the OASIS Enterprise Key Management Infrastructure Technical Committee (EKMI-TC). The committee aims to deliver the following:

  • Standardize a protocol--the Symmetric Key Services Markup Language (SKSML)--for applications and/or devices to securely acquire symmetric key management services (SKMS) over a network.
  • Create implementation and operations guidelines for building and operating symmetric key management systems.
  • Work with other standards bodies on SKMS audit guidelines.
  • Create an SKSML interoper-ability testing suite.
Connect to us
Send your comments to
We reserve the right to edit letters for clarity and space.

We are also working with ISACA to ensure auditors are trained and knowledgeable in key management guidelines. We believe that a standard key-management protocol is absolutely critical to protecting data.

Arshad Noor

Article 9 of 13
This was last published in June 2007

Dig Deeper on Information security policies, procedures and guidelines

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

Get More Information Security

Access to all of our back issues View All