The current issue of IEEE Security & Privacy Journal has an article by John Steven and Ken van Wyk regarding how to get development and security staff to co-evolve towards better software security. They get right to the heart of the issue:
Developers fulfill the single most important role in software security: they build the software. Yet, it’s very likely that all but a handful of an organization’s developers are completely blind to how the software they’re building or maintaining today could be exploited tomorrow. A predictable consequence is that developers can’t build security into their applications and often push back heavily on any security analyst who takes a pot shot at their code.
This is part of the tension that exists between all operational and development groups, operations staff are typically suspicious of what the developers are throwing over the wall into production, in security we have the additional case that new vulnerabilities and exploits are discovered over time.
The authors discuss mitigating some of the core issues through training. As someone who does security training, I particularly like their suggestion that training should be seperated based on audience:
Executive training should teach the difference between software security and conventional network security approaches, particularly the pervasiveness of software security issues. It should also present and align business owners with the ESSF. Finally, it should establish short- and medium-term goals for software security capability, as well as set group owner expectations, means of measurement, risk management goals, and MBOs. Management-level awareness training should teach development managers how to make schedule, cost, functionality, and risk trade-offs via a risk-management framework. It should also demonstrate how software security touchpoints affect development methodology. Finally, it should equip managers with knowledge collateral and questionnaires to validate the probability and impact of security findings and mitigation strategies. Awareness training for development and security staff should seek to transform the way developers behave when they return to their development environments. It should further show how to execute software security touchpoints to build security in to the development life cycle. It’s also vital that it clearly shows how attackers exploit software and how to resist attack. Finally, it should provide analysts with a toolkit of specific attacks and principles with which to interrogate systems.
One of the big challenges in training is targeting the message correctly. Even in the technical software security training sessions I do, I typically see a mix of app arch, app dev, traditional security (i.e. network) staff, and operations. A large part of the challenge is making sure the software people understand enough about security and that the security folks understand enough about software.
As with many big challenges, software security is not going to be solved with one magic tool or technology, instead it is a mix of architecture, process, and organization. Training and awareness runs through all of these.