News Vulnerability Management
Playing In The Sandbox Helps Developers Learn About Bugs
Using virtual environments, two start-up projects create different ways of showing -- not telling -- developers how and why to prevent bugs
For four months, massive denial-of-service attacks have caused problems for U.S. financial institutions. At the heart of those attacks are a host of servers running Web applications with known vulnerabilities.
While a server-based botnet inundating networks with tens of gigabits of data per second may highlight the danger of Web-application vulnerabilities, developers don't need to wait for their software to be compromised to see such attacks in action. A group of computer security specialists have created Hack.me, a virtual playground where developers can see the impact of various vulnerabilities on almost a score of open-source applications. The aim: to teach developers the danger of vulnerabilities.
More Security Insights
- Remote Data Replication: Combat Disasters And Optimize Business Operations
- Check Point 2013 Internet Security Report
- Strengthening Enterprise Defenses With Threat Intelligence
- Strategy: Advanced Persistent Threats: The New Reality
"We realized that explaining and educating users about Web application security with theoretical arguments is not enough and has proved a failing approach for years," says Armando Romeo, founder of eLearnSecurity and the Hack.me project. "Countless books have been published on the subject, but we still have developers writing insecure code and management level completely ignoring threats related to Web applications."
Using Hack.me, a developer or security professional can attack a live instance of a vulnerable Web or mobile application to see the impact of different vulnerabilities. Or a developer can upload a version of his own code so that others can attack it in a safe and virtual environment.
"If you break something, you can always start fresh [by] resetting your sandbox," Romeo says. "All these operations literally take seconds compared to hours of server deployment and application configuration you had to go through before."
eLearnSecurity is not alone in trying to use sandboxed environments to teach developers to better secure their software. Startup Bugcrowd aims to give developers a place to offer up their applications to a crowd of freelance pen testers, who compete to find vulnerabilities in the application for a bounty.
"We are working with larger companies who know what bug bounties are but haven't yet been able to implement them, and with smaller companies who haven't had an app sec testing solution that fits their budget requirements until now," says Casey Ellis, founder and CEO of Bugcrowd.
The project has run a number of bounties so far, including one for $5,000 in total rewards that is currently ongoing. Based in Australia, the startup has already started soliciting additional projects. The project could provide an opportunity to developers who may not otherwise have the funding to hire a pen tester, Ellis says.
"Every bounty we've run so far has yielded a third-party 0-day," Ellis says. "That doesn't usually happen under the traditional model and goes to show that the testers are doing a fantastic job."
[Penetration testing is only the first step of self-inspection -- ask internal auditors to scrutinize IT practices beyond compliance to take risk management to the next level. See Go Hack Yourself.]
While the penetration-testing possibilities are intriguing, these types of projects can be invaluable in teaching developers the seriousness of eliminating vulnerabilities in their software, says Jerry Hoff, vice president of the static code analysis division for WhiteHat Security.
"Education is the first line of defense against vulnerabilities," Hoff says. "In a lot of organizations, most developers have no idea about how the technology can be used, or abused, by attackers."
Yet these types of projects should be part of an overall plan to teach developers the best way to code securely and minimize vulnerabilities, and not used as a single lesson with no context, he says. Rather than just scare developers, teach them how to use secure coding techniques to make their code harder to exploit, he says.
"It is a little like a magic trick, but it kind of puts developers in a paralyzed state of fear because of all the things you can do," Hoff says. "It is better to discuss security controls, and let them know why they have to do it."
Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.