HP Security Products Blog
From applications to infrastructure, enterprises and governments alike face a constant barrage of digital attacks designed to steal data, cripple networks, damage brands, and perform a host of other malicious intents. HP Enterprise Security Products offers products and services that help organizations meet the security demands of a rapidly changing and more dangerous world. HP ESP enables businesses and institutions to take a proactive approach to security that integrates information correlation, deep application analysis and network-level defense mechanisms—unifying the components of a complete security program and reducing risk across your enterprise. In this blog, we will announce the latest offerings from HP ESP, discuss current trends in vulnerability research and technology, reveal new HP ESP security initiatives and promote our upcoming appearances and speaking engagements.

Decoupling the 'False Positive'

There’s often a significant amount of debate between internal appsec groups and developer groups around the topic of false positives. What exactly determines whether something is or is not a true false positive? And how can appsec groups synchronize so as to reduce confusion on the topic?

 

Semantics lie at the center of many arguments, and the debate around “false positives” offers no exception. What I’ve found is that there are often two different meanings that are being used in a single discussion about false positives, and if each side doesn’t realize which definition the other is using, chaos will ensue. Here are the two definitions I most commonly encounter:

 

  1. The tool is claiming something that isn’t true, i.e. the vulnerability that it says it found actually was not found. One example of this might be the presence of a secretfile.aspx.bak file. The tool says it found the contents of this .aspx file, but when you look at the response you see that it’s no more than a custom 404 page.
  2. The finding is technically correct, but nobody cares, i.e. a finding comes back saying that a password value is being passed via GET request to a given application, and the issue has been fully explained to the development team and management; they’ve simply decided not to change it.

 

Let’s forget for a moment that development groups (or any IT group really) shouldn’t be “deciding” anything when it comes to risk. The point here is that they acknowledge that the claim made by the tool is accurate—they simply don’t think it’s important enough to call an issue or defect.

 

This distinction is critical when appsec groups are communicating with development groups and management. I recommend keeping the term “false positive” firmly nailed down to the concept of the tool being accurate in its claims, and insisting that another term be used for not believing the issue identified is worth addressing.

 

Language matters. Insisting that key terms like these are used both correctly and consistently will prevent excessively long and repetitive email threads over semantics which can result in increased pushback from development and management groups.

 

So, as a follow-up, what do you see being used as a term for the "ignored positives"? Accepted risks? Another coloquialism? Let me know in the comments. Also, feel free to reach out to me at daniel.miessler@hp.com.

Labels: appsec| infosec
Search
Showing results for 
Search instead for 
Do you mean 
About the Author(s)
HP Blog

HP Software Solutions Blog

Featured


Follow Us
Labels
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.