Security Requirements from Threats to Security Patterns Ph

Security Requirements: from Threats to Security Patterns Ph. D Thesis Proposal Fabricio Braz 04/11/08 1

Outline • Introduction – Problem Statement – Security Patterns & Security – Security Requirements • Proposed Research – General Goal – Specific Goals – Overview – Hypotheses – Contributions – Negative Scope 2

Problem Statement (1) • Complex software applications – medical, financial, legal, military, infrastructure… – distributed, web, COTS, wireless, multiplataform – standard/regulation compliance (HIPAA, SOx, Fisma, CC, PCI) – vital and sensitive information handling – variety of security policies to accommodate different system requirements while protecting against a variety of threats A systematic approach to build secure app is required 3

Problem Statement (2) • Increasing app with flaws and incidents reported [Cert-CC] x Application Security • Previous response • Operational System – Patch + Blame users • Approaches to deal with it – Inspect the final release (Pentest) – Security in, from the beginning [Mc. G 06] 4

Problem Statement (3) • Innocuous for well complex systems – Purely formal methods • Implementation does not reflect proved security models – Practical ad hoc • Procedural coding lacks of conceptual approach and abstraction • Insiders as a big source of threats A comprehensive approach is necessary to deal with security thoroughly the SDLC 5

Software Patterns & Security (1) • Security – Conf. , Avail. , Int. , Account. • Attacks – Monetary, political, vandalize, … • Responses – Authe. , A. C. & Autho. , Logging, Crypto. , Int. Dect. 6

Software Patterns & Security (2) • Patterns role in security dev – Do not repeat the same error – Well known solution to common problem in a context – Ideally every sec. problem would have its sec. pattern – The security patterns has increased (hundreds) enabling their use in the SDLC • Now the challenge is to find the appropriate one for a specific context [Fer 08, Haf 07] 7

Software Patterns & Security (3) 8

Security Requirements (1) • Definition – system security policies that constraints FR [Red 07] – sometimes the security is more than the constraint itself, it is the good to be delivered (HIPAA) – provides information about the desired level of security for a system to fit its business goals • Lightweight <-> Heavyweight – How to determine the appropriate system security level • Mitigate / stop the potential attacks or threats [Goe 06, Tøn 08, hip] 9

Security Requirements (2) • Approaches – Misuse Case • Deals with security requirements as use cases that defend against attack scenarios described by misuse cases [Ale 03, Sin 05] – SQUARE • A comprehensive methodology without a specific technique to elicit security requirements [Mea 05]. – Problem Frames • Not so commonly used as UML (how to convince the developer? ) 10

Security Requirements (3) 11

General Goal This thesis attempt to improve the security of new intensive software systems with a methodology that focuses on the integration between the requirements and design development phases through a smooth transformation from threats to security patterns applied to design artifacts. 12

Specific Goals • Survey security requirements approaches • Refine the analysis of misuse activities in order to be more systematic and to generate more precise threats • Develop a model to determine from the elicited threats a set of policies that can stop or mitigate them • Develop a model to map security policies to security patterns that realize them • Develop a model to incorporate the appropriate security patterns into the system design • Develop a tool that automates part of the analysis and transformation 13

Overview (1) Threats Policies The customer provides false information and opens spurious account Mutual authentication. Every interaction across system nodes is authenticated The manager creates a spurious account with the customer’s information Logging. Since the manager. Mitigationhis is using Realization legitimate rights we can only log his actions for [Design Artifact] auditing. Mitigation time at a later Selection Separation of administration from use of data. [Security Patterns] For example, a manager can create accounts but The manager creates a spurious authorization card to Security Requirement access the account. should have no rights to withdraw or deposit Definition money in the account. [Security Policies] An attacker tries to prevent Misuse Action the customers access to their Analysis accounts [Activity Diagram] Protection against denial of service. We need some redundancy in the system to increase its availability. 14

Overview (2) threat response T 1 r 1 p 1 R 1 P 1 r 2 p 2 R 2 P 2 r 3 p 3 R 3 P 3 r 4 p 4 R 4 P 4 T 2 T 3 Ti rj policy pk realization Rl sec. pattern Pm

Hypotheses 1. A comprehensive list of precise threats can be generated semi-automatically from ordinary UML activity diagrams. 2. A set of appropriate security policies (security requirements) can be inferred from a set of precise threats. 3. A set of appropriate security patterns can be inferred from the security policies. 4. The application static diagram in the architectural level can be semi-automatically enhanced from the security perspective, through threat analysis and security patterns knowledge. We first express use cases as activity diagrams. 16

1. A comprehensive list of precise threats can be generated semi -automatically from ordinary UML activity diagrams • How to recognize the activity diagram elements to be analyzed? – MOF / XMI • What are the syntax and semantic rules for precisely describing threats? – Ontology, First Order Logic, OCL • How the Misuse Activities should help? – Security Attributes Subverted + Source of Threat + Type of Misuse • What is the role of the following elements, when precisely creating the threat? (It may require its own syntax rule, to make the analysis easier. ) – Activity names, Arrows, forks, joins, merges, Entry/exit points, Flow objects, Decisions, Swim lanes (source of threats? ) • How about the false positives (negatives) generated? – Should the user have a way to refine this analysis according to domain? • How to validate that this threat list is comprehensive? – Using examples? (Checking that they cover all activities. • What’s the expected outcome? – Parameterized threat list • We can do this manually now [Bra 08] 17

2. A set of appropriate security policies (security requirements) can be inferred from a set of precise threats. • How to define of a comprehensive policy list? • We need to elucidate the terminology (Policy, Security Requirement, Hierarchical Policies, and Security Goal). • We need to create a mapping between the threat syntax and the appropriate policy(ies). 18

3. A set of appropriate security patterns can be inferred from the security policies • How can we reduce the ambiguity from the patterns elements (problem, solution, forces, and consequences) in order to enable inference, such as dependency, association, etc? • What else has to be taken into consideration in order to refine the pattern search? – Environment. – Problem, forces (lists the attacks the pattern can handle) • How may we validate that this inference is appropriate? – Are all the threats mitigated/stopped? • What else might help in the patterns inference process? 19

4. The application static diagram in the architectural level can be semi-automatically enhanced from the security perspective, through threat analysis and security patterns knowledge • How can we recognize the class diagram elements? – MOF/XMI • How can we reason about the best place to tie the Pattern Static Structure into the Analysis Class Diagram? (May we use the flow objects from the activity diagram? ) – Analyze if the class is an asset, whether it can be accessed remotely, whether it receives/sends info. to other classes. • What if the class diagram has already been security enhanced? Should we care about security replication? • How to validate the whole transformation (from activity diagram to security enhanced class diagram)? – Can we handle all threats? • What’s the expected outcome? What is the expected transformation to be employed in the class diagram? • How can we trace back to the flow object, since patterns have a relation Nx. N to threats 20

Contributions • A systematic approach: – deals with security from the beginning – realize the elicited security requirements by security patterns on design artifacts • Contributes to reduce architectural flaws • Some activities from the approach will be semi-automated, which gives scalability, mandatory when dealing with large systems. Automation is necessary for large systems to reduce cost. • Performing this approach might indicate the need of security pattern(s) refactoring or documentation in the worst case (cases in which no security pattern can realize a particular security police). 21

Negative Scope • Security Bugs (implementation failures) [How 06, Che 07] • Validation that the source code that • How does the environment affect the security concerns? How to demonstrate that its operation is secure? 22

Discussion • I would love to have a copy of your written comments. • We are recruiting volunteers! – email to: fabricio. braz@gmail. com 23

THANKS’ 24