Checking threat modeling data flow diagrams for implementation conformance and security

Abstract

Threat modeling analyzes how an adversary might attack a system by supplying it with malicious data or interacting with it. The analysis uses a Data Flow Diagram (DFD) to describe how data moves through a system. Today, DFDs are represented informally, reviewed manually with security domain experts and may not reflect all the entry points in the implementation. We designed an approach to check the conformance of an implementation with its security architecture. We extended Reflexion Models to compare as-built DFD recovered from the implementation and the as-designed DFD, by increasing its automation and thus its adoptability. We also designed an analysis to assist DFD designers validate their initial DFDs and detect common security design flaws in them. An evaluation of the approach on subsystems from production code showed that it can find omitted or outdated information in existing DFDs.Parts of this work were conducted while the first author was an intern in the Center for Software Excellence at Microsoft. Abi-Antoun's work is supported in part by NSF grant CCF-0546550, DARPA contract HR00110710019, the Department of Defense, and the Software Industry Center at Carnegie Mellon University and its sponsors, especially the Alfred P. Sloan Foundation. Report Documentation PageForm Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number. Threat modeling analyzes how an adversary might attack a system by supplying it with malicious data or interacting with it. The analysis uses a Data Flow Diagram (DFD) to describe how data moves through a system. Today, DFDs are represented informally, reviewed manually with security domain experts and may not reflect all the entry points in the implementation. We designed an approach to check the conformance of an implementation with its security architecture. We extended Reflexion Models to compare as-built DFD recovered from the implementation and the as-designed DFD, by increasing its automation and thus its adoptability. We also designed an analysis to assist DFD designers validate their initial DFDs and detect common security design flaws in them. An evaluation of the approach on subsystems from production code showed that it can find omitted or outdated information in existing DFDs.

Security Requirements for Tolerating Security Failures

“…Threats in a system have been modeled by several approaches, which include attack trees [2], data flow diagrams [3], and UML-based modeling [4,5,6]. Attack trees in [2] provide an approach to modeling and analyzing the threats of systems, and the threats are analyzed in terms of attacker's capabilities.…”

“…Attack trees in [2] provide an approach to modeling and analyzing the threats of systems, and the threats are analyzed in terms of attacker's capabilities. The design models in [3] are specified with data flow diagram, and the threats to the models are identified and analyzed using scenarios of each function in a system. Several threat modeling approaches, such as misuse cases [4], abuse cases [5], and HAZOP (Hazard and Operability Analysis) [6], have been developed for object-oriented software systems.…”

Analyzing security architectures

“…Also in earlier work [5], Abi-Antoun, Wang and Torr defined a model for reasoning about security at the architectural-level, following the STRIDE methodology commonly used in threat modeling. The previous security model and checker were implemented using custom code.…”

Enforcing Conformance between Security Architecture and Implementation

“…When a security expert asks a developer to build a security architecture for a system under study, the developer typically produces a diagram mostly from his recollection of how the system works, with little tool support to extract such an architecture from the code. Then, during the security review, the experts study the architecture, assign to the components different architectural properties such as trustLevel [2] or privacyLevel, and enumerate all possible communication between the more trusted and the less trusted components of the system. But if the architecture does not show all the communication that is present in the system, the results of an architectural-level analysis may be incorrect.…”

“…Architectural properties In previous work, we defined element-level properties, such as trustLevel, to support an architectural-level analysis to identify spoofing or tampering [2].…”