Security heavyweights share 3 ways to get proactive on app sec
Too many organizations focus their information security efforts on reacting to attacks, rather than proactively trying to blunt them before they happen. A recent survey of 500 IT decision makers in the United States, commissioned by Veracode and conducted by Wakefield Research, found that almost three-quarters (72 percent) believe their organizations focus more on the remediation of vulnerabilities than on proactive or layered security programs.
How can organizations make their application security programs more proactive? Here are three suggestions from leading security pros.
Train developers to write secure code
The later vulnerabilities are found in the software development lifecycle, the more expensive they are to fix. Yet, organizations continue to produce software with known bugs. The study, entitled Bug Bounty Programs are Not a Quick Fix, found that 83 percent of IT decision makers admitted to releasing code before testing or resolving security issues for bugs.
"I know on a number of occasions that software manufacturers will release software with known security vulnerabilities that are serious," —Jeremiah Grossman, chief of security strategy, Sentinelan.
"It's more of a business decision than anything else," he continued. "You can withhold the release and if you do, the business will suffer economic consequences. If you release the software on time, even with security vulnerabilities, it may get exploited, but since software tends not to come with any warranties or liabilities, there's a business incentive to release it."
If developers are trained to write secure code, many of those flaws can be found early in the software development life cycle or avoided altogether. Not only will that make the software more secure, but it will reduce the cost of producing it because remediating bugs is costly.
"If the developer is educated and doesn't write the bug in the first place, there's no remediation cost." —Chris Wysopal, Chief Technology Officer, Veracode
Make sure your security culture is balanced
Many tools are available to help developers automate the discovery of vulnerabilities in their code, but those tools by themselves aren't enough to produce code that's as secure as possible. "Automation, while good, is insufficient," said Alex Rice, Chief Technology Officer at HackerOne, a bug bounty platform vendor.
"Nobody has gotten this right yet," he continued. "Everyone that rolls out an application security program has holes in it. Not just at the individual vulnerability level, but there are blind spots for entire vulnerability ranges that make it through our best efforts at automation and education. The only solution out there that identifies what slips through the cracks today is human creativity."
Automated tools need to be balanced with a manual review of code. "A balanced application security culture is important—and many organizations fall short," the Wakefield report says. Wysopal adds:
"A good balance can occur once you have automation running internally—static and dynamic analysis, maybe behavioral analysis—and human talent manually testing your software."
Automated tools are good at identifying common flaws, such a cross-site scripting errors, but other defects, such as those related to authorization or business logic, are better found by people.
Authorization errors allow one user to see another user's data, or a user to acquire privileges he or she should not have. "Those errors are very hard to find with automated testing, but easy for people to find," " Wysopal said.
Business logic errors can allow an attacker to use the legitimate processing flow of an application to achieve a negative result. For example, in software used to manage a company's bank accounts, a rule requiring human approval of a transaction of more than $2,000 might be omitted.
"Things like that are really hard for automation to find. It comes down to how complex the flaws are," Wysopal said.
Crowdsource your penetration testing
Penetration testing is another proactive way to boost application security. It's a proven method of identifying code vulnerabilities by attacking it as a hacker would. According to Wysopal,
"Even in a world where a developer may be ignorant of some secure coding techniques or just makes a mistake, catching that in a test phase is a lot cheaper to remediate than letting that security bug go into production."
Typically, a company hires pen testers and pays them by the hour to perform that task. But deploying a limited crowdsourcing approach can be an effective and economical alternative. "Instead of getting one person and paying them by the hour, you get lots of different people with lots of different skills sets and incentivize them based on the results that they can produce," said Casey Ellis, CEO and founder of Bugcrowd, operator a crowdsourced bug bounty platform.
Where do you get the "crowd" for the program? Companies like Bugcrowd provide the manpower and create a private bug bounty program tailored to an organization's needs and budget.
The advantage of a private program is that it limits review of your software to a set of trusted eyes. That contrasts with a public bounty program where anyone —Black Hats as well as White Hats — is invited to find vulnerabilities. "If a researcher participating in bug bounty program can find a bug, then an attacker can too," Wysopal observed.
Private programs can also produce benefits that go beyond just finding vulnerabilities. "You can use their findings to inform yourself in what security solutions you should invest in next," Rice said.
"Rather than trying to buy everything to protect against every possible category of security issue, you can leverage real-world feedback in order to choose your investment much more smartly than you would operating in a vacuum." —Alex Rice, CTO, HackerOne
The programs can also be used to improve existing software development life cycle security programs. "When bounty hunters find vulnerabilities, a company will do a triage on those and try to figure out why they weren't caught internally," Grossman said.
"Google does that," he added. "If the bounty hunters are finding a type of vulnerability that Google couldn't find, it will improve its tools so next time it will."
Ellis acknowledged, though, that public bug bounty programs aren't for everyone. "We've refused to work with companies that we feel aren't mature enough yet for that kind of program," he said.
There may be a lot of issues in their code base, he explained, or they don't have the personnel to do remediation. "It's one thing to find a bug, but it's another thing to find someone to fix it," Ellis said.
"This shouldn't be about swatting issues and eliminating point problems in an environment. It should be about educating your engineering team to improve and to not create bugs in the first place." —Casey Ellis, CEO and founder of Bugcrowd
Don't get rattled. Get real
Whatever proactive measures an organization decides to take, they should consider them within the context of the organization.
"People can treat things that are new to them as the one solution everyone should jump on." —Sam Rehman, Chief Technology Officer, Arxan
When the brass, rattled by data breach headlines, clamors for action, some organizations respond by embracing solutions because they're popular, rather than appropriate. Granted, solutions become popular because they've been proven to work, but that doesn't mean they work everywhere, or for everyone.
How has your team been proactive with regard to application security? Share your best practices in the comments section below.
Image credit: Flickr