Secure Systems Research Group - FAU Model Checking Techniques for Security Systems 5/6/2009 Maha B Abbey PhD Candidate

Secure Systems Research Group - FAU Model Checking Process –Modeling – formal design Convert a design into a formalism accepted by a model checking tool. Modeling of a design may require use of abstraction to eliminate irrelevant or unimportant details –Specification – temporal logic (properties to specify) Before verification, it is necessary to state the properties that the design must satisfy. Temporal logic is commonly used which can assert how the behavior of the system evolves over time. Issue: Completeness – it is hard even impossible to determine if a given specification covers all the properties that a system should satisfy. –Verification – ideally automatic Requires manual human touch which consists of analyzing the verification results. Results traces are often generated and used by the designer to track down where the error occurred. In formal verification, we verify that a system meets a desired property by checking that a mathematical model of the system meets a formal specification that describes the property.

Secure Systems Research Group - FAU MOPS: MOdelchecking Programs for Security properties Push Down Automaton Find security bugs in C programs verify conformance to rules of defensive programming – targeted at developers writing security-critical programs and at security auditors reviewing the security of existing C code designed to check for violations of rules that can be expressed as temporal safety properties –A temporal safety property dictates the order of a sequence of operations. For example, in Unix systems, we might verify that the C program obeys the following rule: a setuid-root process should not execute an un-trusted program without first dropping its root privilege

Secure Systems Research Group - FAU MOPS (2) [Che02] Automated approach to examine security-related temporal safety properties in SW –Detection of violations of ordering constraints (Temporal safety properties) A temporal safety property dictates the order of a sequence of security-relevant operations –The ability to detect violations of the properties or to verify the satisfaction of them would be a significant help in reducing the frequency of software vulnerabilities –Verifying that security properties are satisfied (possibly on all execution path) can reduce the risk of security vulnerabilities –the sequence of operations in a property may span multiple functions or files in a program making the ability to discover vulnerabilities difficult during manual verification and testing –MOPS provide the ability to make these properties explicit and to verify whether they are properly respected by the source code of some application.

Secure Systems Research Group - FAU MOPS (3) Possible mistakes by giving false alarms (warnings that do not correspond to an actual security vulnerability) but not overlook a real violation of the security property Unavoidable Limitation –no algorithm can both avoid false alarms and avoid overlooking real bugs – false alarms are tolerable enough in practice that the approach is still useful despite occasional bogus warning messages.

Secure Systems Research Group - FAU MOPS (4) Modularization –Ability to decompose complex properties into simpler ones –Very important for practical use Pattern Variables –Control flow and path sensitive –Data flow analysis done via pattern variables bound to any expression that satisfies context constraints in a program. Enable syntactic matching

Secure Systems Research Group - FAU UMLSec allows one to express security-related information within the diagrams of a UML system specification UML profile using the standard UML extension mechanisms stereotypes, tagged values and constraints. Stereotypes are used together with tags to formulate security requirements and assumptions on the system environment, and constraints give criteria used to determine whether the requirements are met by the system design StereotypeBase ClassTagsConstraintsDescription secrecydependencyassumes secrecy integritydependencyassumes integrity criticalobject, subsystem secrecy, integrity critical object secure linkssubsystemsecurity matched by links >, > enforces secure communication links secure dependency subsystemdependency matched by links >, > structural interaction data securitysubsystemprovides data securitybasic data security requirements fair exchangesubsystemstart, stopafter start eventually reach stop enforces fair exchange

Secure Systems Research Group - FAU UMLSec (2) UMLsec –evaluate UML specifications for vulnerabilities in design –encapsulate established rules of prudent security engineering –make available to developers not specialized in security –consider security from early design phases, in system context –make verification cost-effective –UML Extension mechanisms (Stereotype, Tagged value, Constraint, Profile) –UMLsec: general ideas Activity diagram: secure control flow, coordination Class diagram: exchange of data preserves security levels Sequence diagram: security-critical interaction State chart diagram: security preserved within object Deployment diagram: physical security requirements Package: holistic view on security –UML verification framework supporting the construction of automated requirements analysis tools for UML diagrams-> The framework is connected to industrial CASE tools using XMI and allows convenient access to this data and to the human user. –plug-in that utilizes the model-checker Spin and Theorem prover SETHEO to verify security properties of UMLsec models

Secure Systems Research Group - FAU SETHEO Automated theorem-prover to verify security properties of UMLSec models using ATPs for formal security requirements analysis has a potential for efficiency and the ability to handle relatively large specification documents, by avoiding the state space explosion problem one often faces when having to deal with a non-deterministic adversary (unless applying specialized optimization techniques). [Jur05] Translation of UMLSec into First-Order Logic for automated analysis –Behavioral specifications are compiled to first-order logic axioms giving an abstract interpretation of the system behavior suitable for security analysis –conditions on security-critical data (such as freshness, secrecy, integrity) can be formulated –Automated verification of the constraints associated with stereotypes defined within the UMLsec extension (such as the data security requirements) –allows to perform a more abstract analysis compared to the use of model- checking

Secure Systems Research Group - FAU Some References [Che02] Hao Chen, David Wagner, “MOPS: an infrastructure for Examining Security Properties of Software”, CCS’02 [Jur05] J. Jurjens, “Sound Methods and Effective Tools for Model- based Security Engineering with UML”, 27th International Conference on Software Engineering (ICSE 2005), ACM, 2005, [Che07] S. Cheung, B. Dutertre, M. Fong, U. Lindqvist, K. Skinner, and A. Valdes. “Using model-based intrusion detection for SCADA networks”. Procs. of SCADA Security Scientific Symposium, [Fer06a] E. B. Fernandez, M.M. Larrondo-Petrie, T. Sorgente, and M. VanHilst, "A methodology to develop secure systems using patterns", Chapter 5 in "Integrating security and software engineering: Advances and future vision", H. Mouratidis and P. Giorgini (Eds.), IDEA Press, 2006,

Secure Systems Research Group - FAU Next Step Compare different verification/validation methods –[Che02], [Jur05], [Che07] Which one is best suitable for the conceptual control models –Security Patterns [Fer06a] Pattern – guideline –UML diagrams are the solution –Patterns can be input to all dev cycle phases –Safety Patterns –Need of formally modeling these patterns At what level can properties be defined –Is it at the pattern level –UML Model level Are there common properies –Authentication –Authorization Choi paper – Jaeger trent SSL Security – restriction Safety - critical

Secure Systems Research Group - FAU Feedback