Developers understand the importance of writing secure code, but the day-to-day demands of their jobs often make following through difficult, according to application security expert Frank Kim. He hears this from developers at conferences all the time. "They're very interested in security, but when they get back to work they have to focus on timelines and creating features."
This problem is being addressed in part by
"In terms of security, developers have made a lot of strides compared with just five to 10 years ago," said Kim, application security curriculum lead for SANS.org. There are now various methods available to integrate security into the software development lifecycle (SDLC), "but a lot of that effort is concentrated in big companies that have the resources to get it done," he said. Smaller organizations are also integrating security into the lifecycle, but with scarcer resources, noted Kim, head of security consultancy ThinkSec.
One way developers have tried to integrate security into the SDLC is by running source code scanners. But the challenge manyorganizations face is that these scanners, also known as static analysis tools, are pretty complicated, said Dan Cornell, principal of the Denim Group, an application security consultancy. "You have to educate someone to get to a level of proficiency, and [rolling out the scanners] across the entire development organization is expensive. Lots of organizations don't plan for how challenging it will be."
For organizations that are early in their efforts to bake in security into the SDLC, Cornell said the cycle goes like this: developers write code, the security team runs scanners that "blow up the code," and gets developers to fix it. Then the cycle is repeated. This can create bad vibes on both sides. Organizations further down the road with security have begun to include on the security teams people with development skills who can better understand the needs of the developers. In the most successful organizations, he said, the security team provides developers with libraries that make it easier to write secure code, which leads to more positive interactions between security and development.
Integrating more security into the development frameworks avoids questions about who is responsible for security testing and at what point in the development cycle it should take place, Kim said. "Relying on the frameworks to enforce secure coding is a better strategy for the long term."
Secure application security frameworks
Some frameworks such as Struts and Spring and other open source and commercial tools have bits and pieces that help with secure coding, Kim said. "We're slowly getting there, with various protections built in by using some built-in tags or APIs [application programming interfaces]. Some things are built in for CSRFs [cross-site request forgeries] and other protections." Kim said it's not just frameworks, but APIs and servers like Apache Tomcat are also building in protections.
For example, Cornell said the ".NET framework has a good set of input validation routines and components baked into the standard framework." In the Java world, Spring provides support for authentication and authorization, and in the Python world he points to a framework based on the Django Web application platform called PlayDoh.
Observers are beginning to see some positive results, according to Brian Shura, director of services at AppSec Consulting. "We still see most of the same vulnerabilities like SQL injection and cross-site scripting errors … but for newer applications built on newer frameworks, we see far fewer vulnerabilities when testing."
He attributes that to the baked-in security in the frameworks. For example, he said, "ASP.NET has built in REST validation. It's not the most robust, but it will eliminate 95% of cross-site scripting. The older ASP.NET framework doesn't have any of that protection. With the older [framework] you might find 100 instances all over. The same application built in [the newer] ASP.NET you might find a handful."
Shura also pointed to security features such as input validation filters that he's seeing in frameworks. "The developer still has to choose to use them, but if it's part of the framework [the developer] will be much more likely to use security controls." He also notes that session management built into some frameworks "tends to be fairly strong. If developers choose to use the feature, it will be significantly more robust than if they built session management from scratch."
While more frameworks now have security features available, these features are not always turned on by default, Shura said. "The developer has to know and be aware of the security vulnerability, and turn on that feature. It's probably because the framework developers don't want to do anything that would impact usability, so they leave it to the development team to decide."
While Cornell said he's "disappointed that a lot [of] the bigger [development] frameworks don't force this stuff better than they do, they're starting to."
Over time, Kim expects more and more security to be integrated into frameworks. He compared it to [QA, which 30 years ago wasn't an integrated part of the lifecycle, whereas today testing is baked in to the development process. Now the development lifecycle is evolving again. "Microsoft has devoted a lot [of] resources to the security development lifecycle; Oracle has a big software security initiative in-house, and various financial institutions. We see a lot of players across the board dedicating the right amount of visibility to this."
And the open source frameworks are also following suit. PlayDoh, for example, has a published a list of "secure by default" features.
Cornell cautions, though, that these frameworks have to be easy to use. "You've got to make sure it's consumable by [the developers] and not make their job harder. Security folks are often focused on correctness, and developers more on getting the job done in a limited time. To the degree security folks can make easy for developers to do the right thing, it pays real dividends."