This document provides a brief outline of services and practices performed during a typical engagement.
Static analysis
Using an interactive disassembler and custom framework we review the compiled binaries and discover vulnerabilities such as buffer overflows, integer overflows, format bugs, access control issues and so on. A part of this phase is automated to discover common problems but much of it is performed manually by highly skilled reverse engineers.
Dynamic analysis
Using data flow analysis (the movement of data through a running application) and control flow analysis (code paths traveled during operation) we gain invaluable knowledge of how an application operates. Fault injection is also applied to test target code paths for potential weaknesses (e.g. software bugs).
An application assessment is staged in a way similar to most other consulting engagements and what might be typical from a web-based application audit or review.
Scope
Planning is done with the customer to determine what goals must be achieved during the audit. Product components and objectives are identified any must and should items are highlighted to produce a statement of work (SoW) with its associated deliverables.
Pre-assessment
During this phase we review documentation or errata available about our target product. This includes manuals, developer kits, sample applications, consumer reports, bulletin boards, and blogs.
Drive and Document:
During this phase the product is used as it is normally intended, offer the auditor the basic feel for functionality. The auditor will attempt to use each available feature of the product, becoming familiar with it in its entirety.
Review target application class risks:
Each application is prone to its own set of niche weaknesses. During this phase these weaknesses are researched and documented.
Review weaknesses in chosen languages:
Our auditors are familiar with every major programming language so this phase is usually just a brief refresher and tool update. If the language is obscure or internal then we must research it and prepare our tools to isolate weaknesses introduced by the target programming language.
Review target's risk history:
The risk history encompasses any public or sometimes privately discovered bugs and/or vulnerabilities in the target software. These previous risks are reviewed as an aid to further prepare the auditor
Assessment
After performing the pre-assessment we continue into the core of the audit process--the actual assessment.
Prepare packages:
Often executable packages are provided in a state that hinders static and dynamic analysis. During this phase we prepare packages for automated and manual analysis by dealing with packers and files hidden in resources.
Application footprint:
To fully understand the risk that an application introduces when installed into an environment we must record every change made to the computing system when the application is introduced.
Attack surface area:
The attack surface area consists of every top level entry point into the application and for that matter any medium that can be used by an attacker to communicate with a target application. These include remote input points, such as network protocol support, port bindings, and application protocol support as well as local input points such as hardware interfaces, standard IPC mechanisms, and named object access.
Enhanced fault injection:
After our initial review we can fine tune a fault injection array to test the target application. Utilizing internal application events we can synchronize fault testing and dramatically increase the speed at which we deliver faults. This is accomplished by analyzing common control paths, determining completion paths, determining failure paths, and inserting hooks at relevent points to monitor events and syncronize fault delivery.
Utilizing extensive debugging tools the target application will be further instrumented during a fault injection session so that even the most insignificant application failures are caught and recorded.
Remediation
Finally when the assessment piece is completed the results must be reviewed in the company of development and/or application security teams. This involves working together to alleviate the discovered risk and potentially re-architecting the product to help prevent future flaws.
To find out how application assessments can improve your balance sheet contact us.