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.
- "Path Insensitive Insecurity" - describes how using software structural complexity metrics, measuring control flow integrity, and performing structural analysis can help you make your applications more secure.
- To schedule a live demonstration or to speak with us about your software security requirements, Contact Us Here.