News Application Security
A Vulnerability Disclosure Game Changer
Two new ISO standards will push third-party developers, online service providers and even hardware vendors to stop ignoring vulnerability disclosures
SAN FRANCISCO -- RSA CONFERENCE 2013 --Two new standards on the horizon in 2013 could prod ISVs, hardware makers and online services developers to start to address the black hole around how they handle responsible vulnerability disclosures and triage after vulnerabilities are found within in-house software, web apps and firmware. So says bug-finding maven Katie Moussouris, senior security strategist for the Microsoft Security Response Center and a former @stake penetration tester, who held court at a jam-packed and encored session at RSA this week about how the impending publication of two ISO standards will be a game changer for when "friendly hackers come a knockin'" on an enterprise's doors.
|Click here for more articles.|
More Security Insights
White PapersMore >>
- Mobile Commerce: State of the Market
- Strategy: How to Conduct an Effective IT Security Risk Assessment
"A lot of people wonder, how do i know if I'm going to have to be compliant with these standards?" For those of you who do business on a global scale, you will note that it is often a pre-purchasing prerequisite requirement to be ISO compliant with certain standards," Moussouris says. "I'm guessing that at least one of these will be on a customer's required list in the near future. This is why its important for you to learn about it now."
The first, ISO 29147, governs how well organizations "roll out the red carpet" for researchers seeking to inform them about vulnerabilities in their systems, says Moussouris. Most notable in the standard is a requirement that organizations make it obvious to researchers who they should contact to disclose.
"Hackers have a hard time figuring out where to report security vulnerabilities. If you don't make the front door really obvious the back door will be used and it could end up that a frustrated hacker ends up calling up the Wall Street Journal," she says. "There are a number of different customer support email addresses they can try, web forms and what not. The standard coming up will say, thou shalt have some way for external parties to report."
In the same vein, the new standard also defines a seven-day window for responding to researchers to just let them know that their disclosure was received. Though the standard doesn't specify how quickly organizations need to address the vulnerability itself, it does offer guidance on how to coordinate with the researcher and how to create advisories to customers once the fix has been made. It also includes information about how the processes should work in concert with the other corresponding standard, ISO 30111, which governs the process and organizational structure built to support vulnerability remediation regardless of whether an outside hacker finds vulns or an internal worker finds them.
"The insertion point into this process is, potential vulnerability acquired, now what? That's where we're picking up," says Moussouris, who is an editor for the yet-to-be published standard.
The standard offers guidance on how to build a framework to quickly address vulnerabilities through the five-stage process of receipt of vulnerability information, verification of the vulnerability, resolution development, release of the fix and post-release communication to ensure customers implement the fix. The standard addresses how organizations should be communicating internally to get a fix developed, how vulnerability information should be protected within internal systems, and how communication with customers should be carried out.
Additionally, the specification requires organizations address the all important task of root cause analysis, she says.
"This seems like captain obvious talking, but you'd be surprised. In my years of doing vulnerability reporting and coordination, you would be shocked at how many organizations will take a vulnerability report, patch that one vector you've shown them through proof of concept and not do a root cause analysis," Moussouris says. "They have no idea what's actually causing the vuln."
As she explains, root cause analysis should ideally be fed back into the security development lifecycle so that organizations can stop making the same mistakes over and over again.
According to Moussouris, both standards are on track for release in the latter half of 2013 or late 2014. She believes that they will both go a long way towards pushing third-party vendors into a more mature set of processes around vulnerability remediation.
"A lot of companies for a very long time got away with essentially just ignoring a lot of vulnerability reports," she says. "If you want to do business with certain organizations, especially governments that think ISO compliance is very important for security assurance, you are actually going to have to respond. It will be in the standard."
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.