Equip the team
IBM Rational's Weider went so far as to say that educating developers is critical to winning the war on security-and that organizations need to take on the responsibility of that education. "Developers rarely get security training during school, so this needs to happen on the job," he said. Step 3: Equip the team.Chelf warned, however, that some of these tools can slow the process-something that irks business managers and developers alike. "Make no mistake, adding security to your software development process can potentially slow down your release efforts," Chelf said. "And not only is time to market absolutely critical to your business, your developers also do not enjoy anything that is added to their process that slows them down." Fortunately, tools are available that can help developers be more secure and more efficient, Chelf said. Static code analysis is a great way to counteract the otherwise-onerous process of manually reviewing an entire code base for security vulnerabilities-a task no one really wants to undertake, he said. Tools and technologies are available to help organizations with verification, validation and security and to help enhance software integrity throughout the system. "The benefits gained by discovering defects earlier in the software development process counterbalance the additional time you are asking your developers to spend in developing secure code," Chelf said. "I recommend picking tools that are designed for the developer. You can pick analyzers that are made for the security audit team, or QA, but the most influential group of people as it pertains to software security is your software developers." Microsoft's Bidstrup echoed the importance of minimizing risk from implementation vulnerabilities by using static code analysis tools. He also said organizations should "use defense-in-depth mitigations by applying the best options available from compilers and build tools." Meanwhile, PreEmptive's Holst said organizations should "select common practices, frameworks, technologies, architectures and suppliers to ensure consistency and a -principle of least surprise' across the enterprise." Step 4: Test and test again. The fourth step in developing for security is to employ security-testing techniques. In the past, verification-ensuring a program did not fail-and validation-ensuring a program did what it was supposed to do-were the primary tasks a software development organization needed to address prior to release, Chelf said. "[However,] the difference between verification/validation and security is that it is much more difficult to test for security," he said. "Testing to make sure the program runs correctly and does not fail is something observable. Testing to see if a certain failure could be exploited is much more difficult to observe." Part of this stems from the fact that, when developing software with security in mind, you're developing against an adversary, Chelf said. "This is a much different paradigm than simply trying to make your customers happy with features that work," he said. "And when working against an adversary, you must concern yourself with not only whether a system fails, but how exactly it fails, because that hacker will try every mode of failure he or she can to try to uncover the weakness in your system.
The third step to secure development is to equip team members with the tools and technologies that will help them build applications in a secure manner from the very beginning.