Analyze the Attack Surface

Call 800-638-6316 or Contact Us Here

Recommended Security Analysis Processes

Analyze the Attack Surface Leveraging Path Analysis

Analyze the effectiveness of security testing using path coverage

Compare complexity metrics with known vulnerable code

Video Library:

Control Flow Security Analysis Using Attack Maps

Path Coverage and Security Vulnerabilities

Document Library:

Improving Software Security by Identifying and Securing Paths Linking Attack Surfaces to Attack Targets

Control Flow Security Analysis with McCabe IQ - Applying a Path-based Method to Vulnerability Assessment of the Microsoft SDL Banned Function Calls

Combining McCabe IQ with Fuzz Testing - how leveraging static and dynamic path analysis will improve fuzz testing and software security.

Complexity Analysis of Hostile Applets - Forensics: Using Path-Oriented Metric Analysis to Unravel Hostile Applet Algorithm Patterns, Signatures, Similarities, Authors and Derivations

Cyclomatic Path Analysis and Security Vulnerabilities - Learn how Cyclomatic Path Analysis detects more security vulnerabilities and errors in your critical applications.

More Papers

Analyze the Attack Surface Leveraging Path Analysis

Use McCabe IQ to find an Attack Surface and Attack Target, then use its path and subtree analysis with visualization and complexity metrics to understand the Useable Attack Surface, Attack Map (attackable subset of code), Attack Trees, api and library exploitability and the connectedness of components and vulnerability; and use path level code coverage to determine the thoroughness of your tests of that attackable subset of code.

Determine the Attack Surface (external access) and Attack Target (vulnerable, such as data manipulation) code. The tool’s Class Editor (which binds modules into user classes of concern), can be used with editable class files. This subset of code could be identified using one or more of several sources, including:

previously-identified module names of concern, for example, modules indicated by a security analysis scanning or testing tool or by your organization’s manual analysis
library module names known to perform functions such as external communications and data manipulation, especially if known to have vulnerability, for example, modules identified by industry or provided by McCabe in pre-specified lists

Identify an Attack Map (attackable subset of code), which may consist of the Attack Surface, the Attack Target, and modules that have control flow relationships with such modules. The Attack Map focuses on vulnerable and exploitable code. The tool’s Exclude feature can provide views/reports of such subsets of code and their relationships. The tool’s Data Dictionary feature can highlight locations using specified insecure elements of concern (e.g., calls to recv or strcopy), and permit viewing metrics, graphs, and test conditions associated with them.

Generate source code structural complexity metrics for the Attack Map (attackable subset of code). Such metrics indicate the impact, reliability, ease of maintenance, ease of testing, etc. of this code, both at the design level (module relationships) and the module level.

Use visualization and reporting techniques to further analyze the Attack Map (attackable subset of code). Structure charts, class diagrams, flowgraphs, subtrees (Attack Trees), paths, and other information help an analyst quickly understand the code of concern, and its relationships with other modules. Locations of calls to code of concern can be viewed. Global data usage within the Attack Map could be viewed. Specified data complexity metrics, graphs and test conditions can pinpoint where in the module’s source code calls are being made by the attack entry and target modules.

If desired, focus on changed modules within the Attack Map, to understand with visualization and metrics or with code coverage the risk related to recent code changes in sensitive areas.

Analyze code coverage for the Attack Map (attackable subset of code). That is, execute at least what you consider your security test cases, and possibly all tests, and then analyze whether any code within the Attack Map that is NOT exercised by those tests needs to be tested with additional security-related tests. Code areas of high risk to your organization, such as those of concern for security, should have more thorough quality processes applied, including more thorough code coverage. The code coverage level should be at least branch coverage, with the more thorough levels of basis path coverage (i.e., Structured Testing) or boolean/MCDC coverage highly recommended for increased confidence of your security testing.