B uilding secure systems using patterns

1. Building secure systems using patterns Eduardo B. Fernandez Dept. of Computer Science and Engineering Florida Atlantic UniversityBoca Raton, FL, USA http://www.cse.fau.edu/~ed

2. Secure software development • Most of the approaches to produce secure software are based on analyzing code • While this is a reasonable approach, it will not have a strong impact in future systems • We need to emphasize the modeling aspects of code development and we have proposed a methodology for this purpose • We are now developing different aspects of this methodology

3. A methodology for secure systems design • A main idea in the proposed methodology is that security principles should be applied at every stage of the software lifecycle and that each stage can be tested for compliance with security principles • Another basic idea is the use of patterns to guide security at each stage • Patterns are applied in the different architectural levels of the system to realize security mechanisms • This project proposes guidelines for incorporating security from the requirements stage through analysis, design, implementation, testing, and deployment • Modeling can include also hardware, which means that a complete secure system can be designed in this way.

4. Work in 2007 • We did some work to apply security using MDA (Model Driven Architecture) (Nelly) (Pat) • We developed two new types of patterns, the Attack/Misuse pattern (Juan) and the physical access security pattern (J. Ballesteros, Maria) • We showed how to superpose security patterns on analysis patterns to produce secure analysis patterns (SSAPs), that incorporate security policies to stop specific types of attacks (Argentina and Paraguay) • We developed more security (several) and privacy patterns (Barkha) • Started work on pattern classification (NII)

5. MDA and security (Nelly)

6. Patterns for web services and identity

8. Translation between levels

9. Patterns and levels

10. Relate methodology stages to MDA (Pat) • Requirements: compare our approach to an existing set of requirements (SSH) • Analysis: evaluation of our approach and UMLSec • Design: model transformations • Comparison of models produced with our approach and existing models (Ganymede)

11. SSAP • We have proposed the use of Semantic Analysis Patterns (SAPs) to build conceptual models of applications (X. Yuan) • A SAP is a composite pattern that corresponds to a few fundamental use cases • Using SAPs it is possible to build conceptual models in a simpler and more reliable way • In the methodology we add instances of security patterns to the functional parts of the conceptual model to define security constraints at the application level. These constraints are then enforced by the lower architectural levels.

12. Secure SAPs • We extend the SAPs to consider possible attacks to the fundamental use cases that define it, and we define policies to prevent the attacks (X. Yuan and Argentina/Paraguay) • Since the SAPs are used to build the conceptual model of an application, we have now a portion of a conceptual model where functional and security aspects are integrated from the start, a Secure Semantic Analysis Pattern (SSAP) • To describe SSAPs we have extended the template with sections on possible attacks (the possible attacks in each activity of a use case), needed policies (to prevent or mitigate the attacks), and secure structure (the class model of the solution with security constraints)

13. Basic use cases

14. Possible attacks • A1 In the ‘start case’ activity, the client or the responsible lawyer might be impostors. • A2 A lawyer might create a false contract. • A3 The client or the external people might give a false deposition. • A4 A lawyer may change a deposition. • A5 A lawyer or a secretary may produce intentionally incorrect precedents, briefs, or costs. • A6 A secretary may produce an increased or decreased bill. • A7 A lawyer may change some aspects of the outcome to collect a higher fee. • A8 A lawyer can disseminate client or case information for monetary gain. • A9 An external attacker may read/change case information or access client/lawyer communications.

15. Solution

16. Secure structure The attacks identified earlier mean that we need the following policies to avoid or mitigate them: • A1 Mutual authentication, to avoid impostors. • A2 Authorization to restrict only lawyers to create contracts, and logging to record possible illegal actions from a lawyer. • A3 Logging, to keep records for future auditing that could detect false depositions. • A4 Authorization and document protection against change. • A5 Authorization and logging, to restrict who can perform these actions and to keep records for future auditing. • A6 Logging, to record suspicious actions of a secretary. • A7 Separation of duty. Two lawyers must concur on the fees to be charged. • A8 Logging, to record possible illegal actions of lawyers. • A9 Authorization and access control to stop external attacks and cryptography to protect communications

17. Secure class diagram

18. SAPs and security patterns

19. Use of SSAPs

20. Patterns for physical access control • Describe security mechanisms for physical systems: access to buildings (Ballesteros, Desouza, Maria) • Alarm Monitoring. Defines a way to raise events in the system that might require special attention, like the tampering of a door. • Relays. Defines the interactions with electronically controlled switches. • Access Control to Physical Structures. Applies authentication and authorization (RBAC) to the control of access to physical units including alarm monitoring, relays, and time schedules that can control when things will happen.

22. Ideas for physical AC • Describe through patterns the basic features and concepts for any Physical Access Control system, specialize models for specific environments • Patterns can guide the design of physical access control systems or they can be used to evaluate current products or standards • Extensions: dynamic restriction of the locations where a suspicious user could go or reconfiguration of exits in case of emergencies • Privacy-oriented restrictions • Combination with context-based access control

23. SCADA systems • Patterns for secure SCADA (Ajoy, Y. Shao) • Dependability patterns---combine security and fault tolerance/safety/reliability (Ingrid) • Extend the general development methodology to include safety and fault tolerance as well as security

24. Attack patterns • It is not clear to an inexperienced designer what security pattern should be applied to stop a specific attack • Security patterns are not useful either for forensics because they do not emphasize the modus operandi of attacks. • Attack patterns describe, from the point of view of the attacker, how a type of attack is performed (what system units it uses and how), proposes ways of stopping the attack by enumerating possible security patterns that can be applied for this purpose, and helps analyzing the attack once it has happened by indicating where can we find forensic data as well as what type of data.

26. Decision trees • Work with O. Zimmermann (IBM Research), P. Cholmondeley • From the conceptual model, which is technology independent, an architect has to make several choices about the technology platform, standard, or product to be used • We can record these decisions in a tree form • We can reuse these decisions in similar applications

27. Architectural decision tree

28. Law firm example We need to apply the following policies to avoid or mitigate the identified threats: • T1: Authentication • T2, T3, and T5: Authorization/ access control and logging • T4: Backup and logging • T6: Message encryption • T7: Message encryption and digital signatures

29. Security decisions in the architectural decision tree

30. Value of decision trees • The architectural decision tree records explicit design decisions about security, vis a vis functional architectural decisions • In this way an architect can reuse a good design or backtrack in the tree and make a different decision if a particular decision does not lead to a satisfactory solution (with respect to functional and security requirements), or the new application has different requirements • A specific tree, showing the decisions made in a specific application, is a kind of pattern in that it embodies good practices that were useful in some real case. More work is needed.

31. Security and analysis patterns • WiMax security (Mike) • VoIP signaling protocols (Juan, C. Wieser) • VoIP security (Juan, Maria) • Access control in distributed systems (Nelly, Maria, J. Wu) • Secure handling of legal cases (Argentina/Paraguay) • Customer Relationship Management (CRM)(Mei) • Secure pipes and filters (Carlos)

32. More patterns • Secure three-tier (Mihai, Mirela, Mike) • Standards: comparison and adaptation (Nelly) • Identity management (Nelly) • Contexts and Context-based access control (Alvaro)

33. New patterns • VPN, IDS (Ajoy) • Security ring architectures (David LaRed) • Implied authorization (Maria) • Flight schedules (Zhen Jiang) • Cell phones (Mihai, Mirela) • Invoice and payment (Mihai) • IP Multimedia Subsystem IMS) networks (Jose Ortiz-Villajos) • Patterns for access control (Guenther) • Secure Pipes/filters and Secure Blackboard (Jorge Ortega)

34. Privacy patterns • Privacy policy definition (Luanna Lobato) • Privacy negotiation and enforcement (Barkha)

35. More work in progress • General methodology (NII, Jurjens) • Pattern classification (NII team) • Pattern coverage (Mike) • Security requirements: comparison of misuse cases, misuse activities, abuse cases, problem frames (Fabricio) • Verification of existing security requirements using our approach (Pat) • Formalization (Jurjens, NII) • Pattern recovery from source code (Mike)

36. Patterns for access control

38. Collaborative work • National Institute of Informatics, Tokyo, Japan (N. Yoshioka, H. Washizaki) • Open University, London, UK (J. Jurjens) • Serenity Project (EU) (A. Man~a) • University of Regensburg (G. Pernul)

39. Proposals • Models and patterns for privacy negotiation and enforcement (Maria (PI), Shihong)—submitted to NSF • Coverage and guidance with security patterns (Mike (PI), Maria)—Jan. 17 (NSF) • Secure and safe software development for infrastructure systems (Mike, Maria)—NSF and Homeland Security