Jim Ivers wrote an interesting post about A Spell Check Equivalent for Building Security In that I would like to share.
“I can honestly say that spell check is the reason I now know how to spell “separate.” It only took about 20 years of patient and faithful repetition from Microsoft Word.
The concept of spell check is intriguing when considered in the context of security. There is a significant benefit to being corrected on the spot—an immediate identification of the error in your ways. Even more beneficial is being shown a suggested correction because the repetition of the process of identification and remediation is a highly effective learning tool. Spell check educates to put itself out of business.
Traditional working patterns for software security testing have been in a consistent rut for some time. Development teams wrote code until they completed the scope of a given release, and the completed application was then tested. Results were subsequently returned back to the development team for remediation.
This is when the fun really starts, because the development team has already moved onto the next development cycle. To address the findings of the test, they have to stop their current work, get their head back into the previous cycle, and begin to investigate and remediate the findings. Some testing tools have a history of returning false positives, which means the developers must first verify that each vulnerability is real and exploitable. This places a heavy burden on the development teams, who are often incented to be on time more than to be secure.
Even security training—assuming it exists, which it often does not—is monolithic. Developers are asked to step out of the development cycle and attend classes or engage with computer-based training. As millennials enter the development job force and adoption of agile development methods expands, this training method is no longer optimal. In particular, millennials like to learn in snackable segments.
Clearly a paradigm change is needed for both software security testing and training. In response, many vendors are throwing around a term that drives me nuts: move left. The idea is rooted in waterfall development graphics where moving left in the picture means you have embedded testing earlier into the process. What incites me is that for most of these vendors, all they have moved left is the “button” to launch the same testing process.
Not exactly paradigm-changing.
Drop the talk about moving left and adopt a building security in approach by leveraging technology that acts like a spell check for security. These tools live inside the development environment and check the code for bugs as it is being developed. The tools perform a lightweight static analysis of the code and identify common errors at the source such as cross-site scripting or SQL injection.
Advanced versions of these tools also provide educational material. The tools explain the nature of the bug identified to the developer and how it can be exploited. The tools also suggest fixes to the code to eliminate the bug. Some will actually make the change after confirmation from the developer. Bugs are identified, explained, and remediated on the spot.
The benefits from this approach are clear.
1. Vulnerabilities are identified in real time where the developer can immediately remediate the problem. No more waiting until the application is tested much later in the cycle and the code has to be re-opened to make the fix. Organizations who use these tools have claimed a 15 percent increase in developer productivity. This is attributed to the time saved not having to find and eliminate false positives or interrupt development cycles to fix previous releases. I have also seen testimonials that report savings of hundreds of thousands of dollars of remediation costs.
2. The interactive process becomes a micro-learning opportunity for the development team. These tools teach developers the nature of common bugs and provide a template for eliminating them from their code. The hands-on learning process has a much higher retention rate and impact than traditional learning methods. Eventually, common errors disappear from the code base.
3. These tools provide a macro view of the development team’s security readiness,consolidating information about staff and their performance against coding with security in mind. Managers can see patterns and take steps to address the underlying issues with additional training or by focused mentoring for specific individuals. Visibility provides the insight to make accommodations and further increase productivity.
The aim is simple and reasonable—to identify problems as early as possible so they can be remediated at the source. Although these tools do not eliminate the need for more extensive static and dynamic testing at the end of the development cycle, if applied properly, the security spell check should catch many of the problems before these tests. This transforms this round of testing into more of a final assessment rather than the single source of vulnerability testing.
Mature organizations should adopt a blended approach that employs testing tools at various stages in the development life cycle. The goal is to identify and remediate early, eliminate interruptions in the development life cycle, and use the tools to raise the security competency of the development staff.
The end result will separate savvy organizations from their competition. And yes, I spelled separate correctly.”
_____
Source:
www.securityweek.com/spell-check-equivalent-building-security
Photo: http://www.securityweek.com/
