Security Requirements: from Threats to Security Patterns

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

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

3. 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

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

5. 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

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

7. 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 [Fer08, Haf07]

8. Software Patterns & Security (3)

9. Security Requirements (1) • Definition • system security policies that constraints FR [Red07] • 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 [Goe06, Tøn08, hip]

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

11. Security Requirements (3)

12. 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.

13. 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

14. Overview (1)

15. Overview (2) threat policy sec. pattern response realization r1 p1 R1 P1 T1 p2 r2 R2 P2 T2 r3 R3 p3 P3 r4 p4 T3 R4 P4 Rl rj Pm pk Ti

16. Hypotheses • A comprehensive list of precise threats can be generated semi-automatically from ordinary UML activity diagrams. • A set of appropriate security policies (security requirements) can be inferred from a set of precise threats. • A set of appropriate security patterns can be inferred from the security policies. • 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.

17. 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 [Bra08]

18. 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).

19. 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?

20. 4. The application static diagram in the architectural level canbe 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 NxN to threats

21. 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).

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

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

24. Thanks’