When the OpenSSL project announced a serious vulnerability, known as Heartbleed, the disclosure set off a race between attackers and developers to fix the issue. Web- and mobile-app developers had to incorporate the patch into their own software and then push out the update to customers. Yet, a month after the announcement, about 1 percent of sites had still not patched.
Five months later, a critical vulnerability in the Bourne Again Shell, or BASH, caused a similar scramble. Attackers gave developers and IT operations teams little time: Within 24 hours of the announcement of the vulnerability, security firms detected signs of attack.
Both attacks were well known, with researchers focused on informing developers of the dangers. Less well-known flaws in open source components are often overlooked, suggesting that developers could benefit from a closer watch on what attackers are doing, says Eric Olson, vice president of product strategy for Cyveillance.
"You have to have enough threat intelligence to know where most of the problems actually lie," Olson says. "Which are not the most present vulnerabilities, but the ones, based on the intelligence actually available, that attackers are going to target."
Getting intelligent about threats
For the most part, software developers do not need the real-time situation awareness that threat intelligence strives to provide. Talk about threat intelligence with security professionals and there will be a variety of opinions of what it entails; talk about threat intelligence with software developers and few will have an idea of what it delivers, says Paula Musich, research director for security information provider NSS Labs.
"It is impossible for developers to know what threat feeds are most relevant," Musich says.
Yet knowing what attackers are doing could help focus efforts. Each year, the vast majority of attacks boil down to a few vulnerabilities. In 2014, for example, ten vulnerabilities accounted for 97 percent of all attacks against companies, according to the 2015 Verizon Data Breach Investigations Report. In addition, in 99.9 percent of the attacks, the vulnerability was exploited more than a year after the issue was first reported.
Overall these numbers better support threat-intelligence-based patching, however, than letting vulnerability data direct development efforts, says Cyveillance's Olson. "There is a limit to the utility to a development shop, even an agile one, of switching tactics based on threat intelligence," he says.
To be useful to developers, threat intelligence has to be heavily filtered. The traditional threat intelligence feeds—sources of attack, malicious binary signatures, and malware analysis—are not going to help developers, says Jaime Blasco, chief scientist with security information system maker AlienVault. "It makes sense, but on the other hand, the traditional threat intel that people look at is going to tell you more about specific vulnerabilities," he says. "I'm not sure how that will be useful for developers."
There are some ways that threat intelligence—albeit broadly defined—can help developers, experts say. Here are the top three:
1. Focus on the basics, which includes security best practices
Because of economic pressures and the trend toward quicker, agile development of software, many programmers are writing the code that does what they want and attempting to secure it later. "It's the Iron Triangle model: You can have your program developed quickly, you can get the desired functionality, or you can make it secure—pick two," NSS Labs' Musich says.
Most often, developers aim for quick, functional software, she says.
Software developers should focus on the basics of creating secure code by following best practices. That will pay the most dividends, says John Dickson, a principal with the Denim Group, a software security consultancy. Creating general standards on privacy and security, implementing rigorous testing of software, and making sure that all software projects are part of the security effort are the best ways to make more secure code, he says.
"The real problem we have, still, is that ... the people who worry about software risk live in the security organization, and the people who have the ability to fix that problem live in the dev organization," Dickson says. "And never the twain shall meet."
Focusing on making sure that best practices are followed, along with a checklist of common issues, such as the OWASP Top 10, is the basic foundation of security for any development.
2. Use intel on attackers to bring home training
Writing secure code and preventing security vulnerabilities are often confusing topics for developers. Because the backgrounds of the two groups are so different, they often do not know how to communicate, says Denim's Dickson. "In the security organization, you have security guys who have a network background, trying to talk to developers who often don't even have a software engineering background," he says. "They don't even speak the same language."
Actual attack incidents gleaned through threat intelligence can better demonstrate to developers the benefit of secure coding. Secure-development training should use real-world attacks as a way to highlight the impact that software defects can have on security. "Developers need to know that it is not a question of if, but when," Cyveillance's Olson says. "Assume the app is going to be attacked."
3. Use feeds from open source libraries to get ahead of threats
Developers increasingly use open source and commercial libraries to speed development of their projects. Often, however, programmers do not monitor the threats posed by vulnerabilities in those libraries.
By some estimates, 85 percent of software projects have some out-of-date open source libraries. Developers should make sure that they have the most up-to-date information on vulnerabilities in common libraries.
Overall, security operations teams should focus on threat intelligence, and developers should focus on improving their security best practices. "On the development side, we are still at the lowest level of maturity here," says Dickson.
Keep learning
Learn from your SecOps peers with TechBeacon's State of SecOps 2021 Guide. Plus: Download the CyberRes 2021 State of Security Operations.
Get a handle on SecOps tooling with TechBeacon's Guide, which includes the GigaOm Radar for SIEM.
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed on cyber resilience with TechBeacon's Guide. Plus: Take the Cyber Resilience Assessment.
Put it all into action with TechBeacon's Guide to a Modern Security Operations Center.
