Browse Prior Art Database

System, Method and Apparatus for Delta Analysis for Incremental Black-box Security Testing

IP.com Disclosure Number: IPCOM000230882D
Publication Date: 2013-Sep-17
Document File: 3 page(s) / 101K

Publishing Venue

The IP.com Prior Art Database

Abstract

We propose a novel approach, dubbed delta security testing, for performing black-box security scanning that leverages knowledge on the results of a previous scan and the software changes that were made to the application since that scan in order to significantly reduce the time the scan requires. The key idea is to monitor software changes via an agent, and communicate these changes to a specialized module that uses static analysis techniques in order to decide on the entities (parameters, cookies or paths) whose flow is affected by the changes. The scanner then tests only these entities, and deduces the results of the tests of the rest of the entities from the previous scan.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 3

System, Method and Apparatus for Delta Analysis for Incremental Black -box Security

Testing

Delta Analysis for Incremental Black-box Security Testing

Background. Black-box security testing is often able to uncover serious security vulnerabilities. For web applications, for example, the scanner often finds a wide range of injection vulnerabilities, such as cross-site scripting (XSS), SQL injection (SQLi) and log forging.

Reducing the time it takes a security scanner to test the application is crucial for all the different phases of the application lifecycle. During development, it allows to scan the application more frequently, which increases the chances of creating secure software. At maintenance, it allows to deploy changes in the application, like adding new features and fixing defects, in a shorter time. Moreover, sometimes such maintenance changes require taking parts of the application's functionality offline until the changes are deployed (e.g. in the case of fixing severe security vulnerabilities or major defects). In these cases, the time it takes to bring the functionality online again may be critical, and could e.g. entail financial consequences.

The problem is that usually it takes a long time to run all the tests comprising a scan. For example, a scan of a middle-sized application may sometimes last from few hours to more than a day. Limiting the number of tests performed by the scanner in order to reduce the time it takes to scan may result in missing vulnerabilities, thereby compromising the security of the application.

A key limitation of existing security scanners is that they don't rely on the results of a previous scan and the software changes that were made to the application since that scan when they decide which tests to execute.

Usually there is a relatively small number of software changes in an application between two subsequent runs of a scan over it. These changes are likely to affect the results of only a small subset of the security tests (e.g. if a new servlet has been added). Testing with only this delta subset of the tests during the new scan, and deducing the results of the rest of the tests from the previous scan, would yield the same results as testing with all the tests (which is the wasteful work existing scanners perform), but in a significantly shorter time and with many less

1


Page 02 of 3

resources.

Summary. We propose a nove...