Risk - Medieval approaches to AppSec

Vulnerability management involves a little more than finding security issues in code and/or hosting systems......I find that much of the industry does not understand that vulnerability management, penetration testing, threat detection, endpoint detection, malware prevention and even anti-virus services and tools are about managing risk.

Managing risk is about reducing it to a suitable level based on the cost of reducing it in the first place. There is no point in spending lots of time and effort on an issues which have little impact or which are very unlikely. Firstly what we want to to reduce the impact of the stuff which has a decent chance of occurring and would be a real pain in the ass if it happened, it would disrupt our business etc.

"A situation involving exposure to danger..."

So blindly throwing tools at a problem to help discover risks to your business is not going to work....but why??

• Tools don't understand Risk: automated tools cannot give you an idea of risk. They find technical bugs wherein they manifest themselves into security vulnerabilities if they introduce the potential of risk. A tool does not understand what a risk is in the context of "a situation involving exposure to danger..." Tools find bugs. - Blessed are the tool makers whom hand craft the tools of the interweb to detect systems unworthy of the title "secure". - Nobody expects the Spanish inquisition!!
• People will not understand Risk without understanding what is at Risk: So to understand a potential risk faced by a system the individual making the risk based decision needs to understand the system. The fact remains most security folks don't have time to understand what the system is/does and therefore cant apply a reflective relative risk assessment. - “The oldest and strongest emotion of mankind is fear, and the oldest and strongest kind of fear is fear of the unknown”
• Tools may discover risk in a risky way!!: Many security assessment tools are not designed, out-of-the-box to be production safe. Production safe testing requires rule tuning such that detection of technical vulnerabilities does not invoke invasive or disruptive tests. We dont want our assessment methodology to damage our sick patient. - "Our chief weapon is surprise, fear and surprise; two chief weapons, fear, surprise, and ruthless efficiency! Er, among our chief weapons are: fear, surprise, ruthless efficiency, and near fanatical devotion.."
  
• Risk Based approach - Really?? Wow!: All risk management is based on er, um Risk. If you hear someone talking about "A risk based approach when discussing Application security" ask them "what is the risk of of a kick in the ass?" Or "What other approaches are there?" - “A ship is always safe at the shore - but that is NOT what it is built for.”

Vulnerability is the state of being open to injury...

• All vulnerabilities are not created equal: Bottom line is how open are you to the possibility of said injury? How bad can the injury be? We don't need to fix all the bugs just the ones that matter (and that which may injure the business or your clients). To understand "what matters" you need to understand the context of the issue. Tools alone can't do this, that's why we developed edgescan.com.....