It is easy to make an argument that security starts at the top. Policies and procedures must be in place which enable the organization and in particular the development groups to be secure. A workable budget must be earmarked for security improvements. However, while these people can do a lot to hurt an organization’s push up the software security maturity stack when they are inline they are merely enablers, not drivers. Typically these people do not have a clear picture of what it takes to develop software never mind secure software. This is not their domain or their responsibility. Nor should it be. They look down to the people they’ve hired to develop the software to drive security initiatives.
It is also simple to make an argument for information assurance or information security groups to be the ones who drive security initiatives. They typically are in charge of corporate security initiatives and will often understand pretty well the nuances of security. All too often these groups are separate from the development organization however and lack the oversight to drive initiatives within the development teams which will better the security quality of the software being produced. Instead they spend time and resources marketing their initiatives internally hoping for adoption. I’ve worked with many organizations suffering this malady currently and there is a lot of wheel spinning. Security is not the only driver in the development lifecycle. In fact most days it is not even the most important. Having security drive your development teams is like putting oil in your gas tank. Oil is important in a car but if in the wrong place it does more harm than good.
Another argument I have heard is to start with the developers or testers, the people doing the work. While it is important that this group has bought in to the security initiatives they cannot be the drivers. The software team is moved by one driver, the ship date. While they will consider all other things such as performance and usability, everything takes a back seat to ship. The development team is, and should be, too close to the forest to see the trees. It is not their job to consider the security implications of the design they’ve been handed. It is their job to implement and test it. While these people need to be educated on how to code securely and test for security defects it is often the process they are handed which is more valuable. If it is stated that part of build is running a static code analysis tool then they will run it and fix the bugs they find, thus increasing security. These people are not able to drive that process in most development organizations. I’ve been in this position trying to fight upstream and convince the team leadership that security matters when they were focused on ship dates and did not consider security to be a real issue. It is why I left development for the security industry. I wanted to help organizations avoid the mistakes I was fighting against in my own team.
I feel the answer is actually to start in the middle. Look to your development team management to improve your software security maturity. I’m talking about the Lead Architect, Team Lead, or Senior Developer type role. The title and responsibilities vary slightly from organization to organization but however it is divvied up, this is the layer to look to. These are the people who gather customer requirements, an oft overlooked phase when discussing security in the development lifecycle. They are the ones who help define tasks and phases in the project plan and can work security activities in almost seamlessly. They are the ones who represent the development teams to upper management and can impart the importance of spending for tools and training which will improve the team’s ability to create quality software. This is also the group that mentors the developers and testers on their team, reviews their code and guides them to create quality software. This all puts them in a unique position to drive security improvement. They are high enough to own initiatives and see they are adopted by the development organization and low enough to understand the problem in the context of the software being produced.
It is important that these people in your organization understand software security and know how to drive quality improvement in this area. Whether that means considering it when hiring new people into these roles or training those already in your organization, getting these people to take ownership of software security as part of software quality and enabling them to drive the changes they suggest is critical to ensure that all other training and tools purchases do not simply become shelf-ware as so much security spending tends to.
- John
