IBM Demonstrates Secure Product Development Leadership

It’s easy to believe that the folks who design, develop, and distribute the technology we use know what they are doing and have our collective best security interests in mind. Sadly, this isn’t at all true. Many vendors focus solely on feature/functionality and disregard security in their product development and manufacturing. Others downplay risks believing that their technology sits well “behind the firewall.” Still others are just plain negligent.In my humble opinion, this situation is unsustainable. Either large organizations will come to some epiphany that they should only buy the most secure IT products, or (more likely) some type of attack and/or new regulations will force them to do so. This begs the question: Which vendors are actually integrating security into their product design, development, and testing process? Microsoft is with its Security Development Lifecycle (SDL) but for some reason other leading IT vendors have been reluctant to provide any visibility into how and where security fits into product development and corporate culture.I’m happy to say that IBM recently shed some light on its internal security processes with the release of a “Redbook” document titled, “Security in Development: The IBM Secure Engineering Framework.” http://www.redbooks.ibm.com/abstracts/redp4641.html?OpenThere are several reasons why this document is worth reading:1. It goes beyond development alone and outlines governance of the development process. In so doing, it addresses areas like protection of assets, inserting security checkpoints into project development phases, and product testing — from unit testing to full system verification. In other words, it talks about how to include security throughout the development process rather than discretely into individual activities. 2. It tailors security education to different roles within the development process. For example, a software developer needs different security skills than a program manager or product tester. This alone is worthwhile but IBM recognizes that many software developers have minimal training for actually writing secure code so the company has standardized on a common training and certification program to make sure that all software developers — whether they are working on z/OS or the next version of WebSphere — are up to speed. 3. It defines metrics for constant improvement. IBM knows that Armonk wasn’t built in a day. To measure secure development progress, the document provides a number of Key Performance Indicators (KPIs) for development groups to capture, monitor, and measure over time. For example, development organizations should track the amount of time it takes them to resolve post-release security problems, find ways to improve efficiencies to reduce the amount of time from days to hours, and then strive for consistency moving forward.IBM also includes some details on how it manages the security of its vast supply chain to ensure that its software development partners and component suppliers are meeting its internal standards for quality, integrity, and security.CIOs and CISOs can use this document in two ways. First, it should provide a baseline standard for measuring the security of other IT vendors. If other IT vendors are NOT adhering to the same types of processes, standards, and metrics as IBM is, raise a red flag and find out why this is the case. If these other vendors don’t have cogent answers or remediation plans, turn up the heat or look for alternatives. Second, any internal development work should be assessed in comparison to the IBM’s secure engineering framework. For example, is security included within the governance of the development process? Does the development team have the right training and/or skill set? This review should help to quickly identify any holes. Strong security must be “baked in” rather than “bolted on” to IT. IBM understands this and is willing to incur the added costs to ensure that it does all it can to produce secure equipment and code before it is deployed on your networks and mine. Given this, you have to really question the motives of other vendors that haven’t publicly articulated details of a similar security commitment.