SecureSystem Designing systems with security in mind is

Secure-System Designing systems with security in mind is not a simple task. When “security” becomes a requirement of a system’s specification there are many nuances of the design process that contribute to achieving that goal. © 2007 atsec information security Hadrian’s wall in Northern England Fiona Pattinson 8 th ICCC: Secure-System Design 1

Secure-System Design (SSD) © 2007 atsec information security • Definition of a “system” – “System design is the process or art of defining the hardware and software architecture, components, modules, interfaces, and data for a computer system to satisfy specified requirements. ” • Design: not whole development cycle. – One part of the Systems Development Lifecycle (SDLC) 8 th ICCC: Secure-System Design 2

© 2007 atsec information security Some examples of system and software development models 8 th ICCC: Secure-System Design 3

Security in the Lifecycle • Security Requirements – Common Criteria (SFR , SAR) • Security Design © 2007 atsec information security – Threat Modeling (CEM Appendix) – Stepwise Refinement (Levels of abstraction) • Security Verification – Static Code Analysis – Common Criteria, FIPS 140 -2 • Security Validation – Penetration Testing – Field! 8 th ICCC: Secure-System Design 4

Maturity of the Security-Design Discipline © 2007 atsec information security • Anderson in 1974 describes the problem: “The reason that it is difficult to provide technical security in contemporary computer systems is that the technical foundation (i. e. design) of the hardware and software is totally inadequate to withstand malicious attack…” “Unless security is designed into a system from its inception, there is little chance that it can be made secure by retrofit…” • Baskerville in 1993 describes – First generation: with predefined generic checklists and standards • E. g. BS 7799 -1, NIST (http: //checklists. nist. gov/), DISA (http: //iase. disa. mil/stigs/checklist/) – Second generation (mechanistic): From predefined and generic solutions to customized systems • E. g. ISO/IEC 27001, UMLsec, security spiral, RUP security, CRAMM – Third generation (Logical, transformational): painlessly adaptable security methods • Security patterns? 8 th ICCC: Secure-System Design 6

Frameworks Providing structure to design • Most general frameworks for software/system development process don’t consider securesystem design © 2007 atsec information security – Examples of (many) others with little focus on security • ISO/IEC 12207. 0 -96 Software Lifecycle processes • Software design has two activities: Software architectural design, Software detailed design. No focus on security • SWEBOK (Software Engineering Body of Knowledge): Chapter on software design but doesn’t cover design for security very well • SEI CMMi – Process Improvement: Little focus on technology • ISO/IEC 90003 • Rational Unified Process (Has some proprietary security plugins/enhancements) 8 th ICCC: Secure-System Design 7

Frameworks Providing structure to design • Some Frameworks for system/software development consider secure-system design © 2007 atsec information security – Common Criteria • Focuses on requirements and security problem definition. Verifies design – Security patterns • Focus on security (Blakely, B. , Heath, C. & al, e. 2004, Security Design Patterns, The Open Group. ) 8 th ICCC: Secure-System Design 8

® SSE-CMM - ISO/IEC 21827: 2007 • SSE-CMM® = System Security Engineering Capability Maturity Model • Does not specify a specific design process © 2007 atsec information security – Aims to improve the design process used by an organization. (Process Improvement) – Aims to assess and organization’s capability in using security engineering processes • The scope encompasses system engineering activities including design • Is applicable to organizations of all sizes • PA 9 – “Provide Security Input” and PA 10 – “Specify Security Needs” covers requirements-capture and high level design processes. Secure-system design is not identified as a separate process area. 8 th ICCC: Secure-System Design 9

Requirements: Specifications & Standards • Specifications: often embed “best practices” for security design • Technical Standards: technical building blocks (higher-level design abstraction – Crypto Primitives – Protocol definitions © 2007 atsec information security – FIPS 140 -2: Cryptographic Modules 8 th ICCC: Secure-System Design 10

Requirements: Legislation/Regulation © 2007 atsec information security • Can influence or even specify Design / Requirements • Examples – FIPS Approved algorithms – CC Scheme policies (e. g. Audit requirement from NIAP) – Federal Information Security Act / Data Protection Directive / Electronic Signature generation 8 th ICCC: Secure-System Design 11

Requirements: SFR Classes and examples of families © 2007 atsec information security • Security Audit – Security audit automatic response – Security audit generation – Security audit analysis – Security audit review – Security audit event selection – Security audit event storage • Communication • Cryptographic Support • User data protection • Identification and authentication • Security Management • Privacy • Protection of the TSF • Resource utilsation • TOE Access • Trusted Path/Channels From Common Criteria: Part 2 8 th ICCC: Secure-System Design 12

Security-Design: Guidelines • Assume that Human Behavior Will Introduce Vulnerabilities into Your System Assume that Technology Will Contain Vulnerabilities • – – © 2007 atsec information security – – – Follow the Rules Regarding Concurrency Management Design Configuration Subsystems Correctly and Distribute Safe Default Configurations Carefully Study Other Systems Before Incorporating Them into Your System Through Delegation If Emulation of Another System Is Necessary, Ensure that It Is as Correct and Complete as Possible Handle All Errors Safely Use All Security Mechanisms Correctly Do Not Allow Your System to Ever Use or Depend on Language Behaviors that Are "Undefined" 8 th ICCC: Secure-System Design 13

Security-Design: Principles © 2007 atsec information security • Design principles – – – Securing the Weakest Link Defense in Depth Failing Securely Least Privilege Separation of Privilege Economy of Mechanism Least Common Mechanism Reluctance to Trust Never Assuming that your Secrets are Safe Complete Mediation Psychological Acceptability Promoting Privacy From “Design Principles” by Barnum and Gegick at https: //buildsecurityin. us-cert. gov/daisy/bsi/articles/knowledge/principles/358. html? branch=1&language=1 8 th ICCC: Secure-System Design 14

© 2007 atsec information security Security-Design Techniques • Techniques – Threat Modeling – Risk Assessment – Secure Coding – Vulnerability Assessment – Formal Methods – Cryptographic Techniques & primatives – Access Control • MAC / DAC – Multilevel Security • Bell La. Padula • Biba – Trusted System – Secure Operating System – Reference monitor – Static Code Analysis – Reverse Engineering 8 th ICCC: Secure-System Design 15

© 2007 atsec information security Security Patterns • A security pattern is a well-understood solution to a recurring information security problem. • A security pattern encapsulates security expertise in the form of worked solutions to these recurring problems, presenting issues and trade-offs in the usage of the pattern. – Procedural Patterns – Structural Patterns • The use of patterns seems to be particularly successful in the security domain. • Many published security pattern catalogues cite the Common Criteria as a source • In Security Design Patterns by Bob Blakley, Craig Heath, and members of The Open Group Security Forum specify a design methodology using patterns 8 th ICCC: Secure-System Design 17

Examples of Security-Patterns © 2007 atsec information security Structural patterns • • • • Account Lockout Authenticated Session Client Data Storage Client Input Filters Directed Session (mini-pattern) Hidden Implementation (mini-pattern) Encrypted Storage Minefield Network Address Blacklist Partitioned Application Password Authentication Password Propagation Secure Assertion Server Sandbox Trusted Proxy Validated Transaction (mini-pattern) Procedural patterns • • • • Build the Server from the Ground Up Choose the right stuff Document the Security Goals Document the Server Configuration Enroll by Validating Out of Band Enroll using Third-party Validation Enroll with a Pre-existing Shared Secret Enroll without Validating Log for Audit Patch Pro-actively Red team the design Share responsibility for Security Test on a Staging Server From the Security Patterns Repository V 1. 0 At http: //www. scrypt. net/~celer/securitypatterns/ 8 th ICCC: Secure-System Design 18

SSD and Common Criteria © 2007 atsec information security • CC does not intend to specify a secure-design methodology, tools, techniques etc. • Some design principles are embedded in CC – Asset protection: A risk analysis paradigm – Implies that Security functionality is separated from other functionality by design – Recognises the operational environment as a key factor in security assurance – Demands documentation of design and proof of correspondence to implementation level – Concept that formal definition gives more assurance 8 th ICCC: Secure-System Design 19

Security-Design Verification © 2007 atsec information security • To provide assurance a design should be verifiable. • There is a well known & mature method for that… 8 th ICCC: Secure-System Design 20

Security-Design Validation – Assurance, Common Criteria – Ongoing Vulnerability Analysis – Penetration Testing © 2007 atsec information security • To determine if the design works. Is the system design meeting the securityrequirements in the field? 8 th ICCC: Secure-System Design 21

© 2007 atsec information security Conclusion • The topic of secure-system design is evolving quickly • Specifying security requirements seems to be reasonably well understood • The design process & methodologies are poorly defined and cohesion of security design with software and system design is poorly defined • Common Criteria provides a mature verification and some validation methodology 8 th ICCC: Secure-System Design 22

Thank You atsec Information Security Corporation Austin, Texas, USA Phone: +1 512 615 7382 Email: fiona@atsec. com www. atsec. com © 2007 atsec information security Fiona Pattinson 8 th ICCC: Secure-System Design 23

References and Bibliography • • © 2007 atsec information security • • • ISO/IEC 21827: 2007 "Information technology -- Systems Security Engineering -- Capability Maturity Model (SSE-CMM®)" JTC 1/SC 27 Berg, C. J. 2006, High-Assurance Design: architecting secure and reliable enterprise applications, Pearson Education Inc. ISBN 0 -321 -37577 -7 Siponen. 2006, 'Secure-System Design Methods: Evolution and Future Directions', IT Professional, vol. 8, no. 3, pp. 40 -44. CCMB-2006 -09 -01 "Common Criteria for Information Technology Security Evaluation Version 3. 1: Part 1: Introduction and general model" The Common Criteria Management Board, Howard, M. & Lipner, S. 2006, The Security Development Lifecycle, Microsoft Press. Blakely, B. , Heath, C. & al, e. 2004, Security Design Patterns, The Open Group. Ravi, S. , Raghunathan, A. , Kocher, P. & Hattangady, S. 2004, 'Security in embedded systems: Design challenges', Trans. on Embedded Computing Sys. , vol. 3, no. 3, pp. 461 -491. Siponen, M. 2002, 'Towards maturity of information security maturity criteria: Six lessons learned from software maturity criteria', Information Management, vol. 10, no. 5, pp. 210 -224. Premkumar T. Devanbu, S. S. 2000, 'Software engineering for security - a roadmap', in ICSE, ACM Press, Limerick, Ireland, pp. 227 -239. Baskerville, R. 1993, 'Information systems security design methods: implications for information systems development', ACM Comput. Surv. , vol. 25, no. 4, pp. 375 -414. Rushby, J. M. 1981, 'Design and verification of secure systems', in SOSP '81: Proceedings of the eighth ACM symposium on Operating systems principles, ACM Press, pp. 12 -21. Alexander, C. , Ishikawa, S. & Silverstein, M. 1977, A Pattern Language: Towns, Buildings, Construction, Oxford University Press. Saltzer, J. H. & Schroeder, M. D. 1975, 'The Protection of Information in Computer Systems‘ Anderson, J. P. 1972, Computer Security Technology Panning Study: VOL 1 & 2, USAF. 8 th ICCC: Secure-System Design 24

• • CC: Common Criteria CEM: Common Evaluation Methodology FIPS: Federal Information Processing Standard PA: Process Area SAR: Security Assurance Requirements SDLC: Software Development Life-Cycle SFR: Security Functional Requirements SSD: Secure-System Design © 2007 atsec information security Abbreviations Used 8 th ICCC: Secure-System Design 25