System, Method and Apparatus for Quantifying Attack Likelihood in Dynamic Security Testing
Publication Date: 2014-Jul-30
The IP.com Prior Art Database
Current dynamic analysis tools do not model, as part of the security assessment they produce, the likelihood of exploiting a given problem. This leaves the developer to either organize the remediation process in some ad-hoc way, e.g. based on the types of reported vulnerabilities or manually review the entire scenario reported by the tool and spend expensive time on determining exploitability manually.. We have identified several criteria that can be checked automatically and together provide an accurate indication as to the degree to which a vulnerability is exploitable.
Page 01 of 3
Method and Apparatus for Quantifying Attack Likelihood in Dynamic Security
Method and Apparatus for Quantifying Attack Likelihood in Dynamic Security Testing
Background. Dynamic testing of software systems for security defects has enjoyed broad
adoption. Today's commercial tools, like IBM's AppScan Standard*, are able to detect a
wide range of top-importance bugs, including cross-site scripting (XSS)*, SQL injection (SQLi), code execution, cross-site request forgery (CSRF), etc.
The report by the testing tool is also informative, providing various variants of confirmed attacks
(e.g., using different payloads), detailed data on the HTTP request sequence leading to the
attack, recommendations for remediation, etc. What is still missing, however, is a clear measure
of how exploitable the problem really is.
By exploitability, we mean the ability by an attacker to actually exercise the reported problem.
While the weakness clearly exists and can be used to abuse the application, it does not mean
that all vulnerabilities are equally exploitable. We describe below several useful criteria for distinguishing between the exploitability of different vulnerabilities.
One example is if the attack requires that the user have an account on the subject
Another distinction is if the website doesn't defend against an attack at all, or there are
measures but these are incomplete/broken. These different scenarios lead to a different analysis of the reported security defect.
The importance of establishing the degree to which a vulnerability is exploitable is that this is a
critical consideration in prioritizing fixing of reported defects. The main value of automated
analysis tools is in creating work for the developers, who are often not security experts. Introducing this prioritization dimension is thus of important value, both from a business standpoint and from a usability standpoint
Background Art. We have conducted a careful search for prior art on the idea of measuring, or
quantifying, the likelihood of security attacks. The closest we found is a product feature [Qualys],
which correlates a reported finding with one or more known exploits for that finding. Another
loosely related idea is to measure the complexity of attack paths [Paths]. This theoretical idea
has been proposed in connection with enterprise networks (and not software applications), and
does not seem to directly apply in application security. In particular, relevant criteria in the domain of application security are different and are not captured by the proposed
Page 02 of 3
Summary. As indicated above, the main observation underlying our invention is that current
dynamic analysis tools do not model, as part of the security assessment they produce, the
likelihood of exploiting a given problem. This leaves the developer to either organize the remediation process in some ad hoc way, e.g. based on the types of reported vu...