Secure-System Design
Designing systems with security in mind is not a simple task. When
“security” becomes a requirement of a system’s specification then 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
8th 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 Development.
– One part of the Systems Development
Lifecycle (SDLC)
• Design: not Security Requirements
8th ICCC: Secure-System Design
2
© 2007
atsec information security
Some examples of
System and software
development models
8th ICCC: Secure-System Design
3
Maturity of security design
discipline
• Baskerville in 1993 describes
– First generation: with predefined generic checklists
and standards
© 2007
atsec information security
• E.g. BS7799-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?
8th ICCC: Secure-System Design
4
Frameworks
Providing structure to design
• Some Frameworks for system/software
development even consider secure-system
design
© 2007
atsec information security
– Common Criteria
• Focuses on requirements and security problem definition.
Verifies design
– ISO/IEC 21827 (SSE-CMM®)
• Focuses on security engineering as a defined, mature, and
measurable discipline. Focus is on process improvement
– Security patterns
• Focus on security (Blakely, B., Heath, C. & al, e. 2004,
Security Design Patterns, The Open Group.)
8th ICCC: Secure-System Design
5
Frameworks
Providing structure to design
• Some frameworks don’t consider secure-system
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)
8th ICCC: Secure-System Design
6
Specifications & Standards
• Specifications: often embed “best
practices” for security design
• Technical Standards: technical building
blocks
– Crypto Primitives
– Protocol definitions
© 2007
atsec information security
– FIPS 140-2: Cryptographic Modules
8th ICCC: Secure-System Design
7
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
8th ICCC: Secure-System Design
8
Levels of Abstraction
technique)
– Security-Design Guidelines
– Security-Design Principles
– Security-Design Families & Classes
– Security Primitives
© 2007
atsec information security
• Stepwise Refinement (a software engineering
8th ICCC: Secure-System Design
9
Security-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"
8th ICCC: Secure-System Design
10
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
8th ICCC: Secure-System Design
11
Security-Design Techniques
© 2007
atsec information security
• Techniques
–
–
–
–
–
Threat Modeling
Risk Assessment
Evaluation Criteria
Secure Coding
Vulnerability
Assessment
– Formal Methods
– Cryptographic
Techniques
– Access Control
• MAC / DAC
– Multilevel Security
• Bell LaPadula
• Biba
– Trusted System
– Secure Operating
System
– Secure Protocol
– Static Code Analysis
– Reverse Engineering
8th ICCC: Secure-System Design
12
Security Function 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
8th ICCC: Secure-System Design
13
•
•
•
•
•
•
Encryption
Key exchange
Hash functions
HMAC functions
Digital signatures
Certificates and CAs
© 2007
atsec information security
Security Primitives
8th ICCC: Secure-System Design
14
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.
• There has been a lot of work completed on this topic. 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
© 2007
atsec information security
– Procedural Patterns
– Structural Patterns
8th ICCC: Secure-System Design
15
Examples of 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 V1.0
At http://www.scrypt.net/~celer/securitypatterns/
8th ICCC: Secure-System Design
16
®
© 2007
atsec information security
SSE-CMM - ISO/IEC 21827:2007
• SSE-CMM® = System Security Engineering Capability
Maturity Model
• Does not specify a specific design process
• Aims to improve the design process used by an
organization
• The scope encompasses system engineering activities
including design
• Is applicable to organizations of all sizes
• PA9 – “Provide Security Input” and PA10 – “Specify
Security Needs” covers requirements capture and high
level design processes. Secure-system design is not
identified as a separate process area.
8th ICCC: Secure-System Design
17
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
8th ICCC: Secure-System Design
18
Design Verification & Validation
© 2007
atsec information security
• To provide assurance a design should be
verifiable.
• There is a well known technique for that…
8th ICCC: Secure-System Design
19
© 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 validation methodology
8th ICCC: Secure-System Design
20
Thank You
atsec Information Security Corporation
Austin, Texas, USA
Phone: +1 512 615 7382
Email: [email protected]
www.atsec.com
© 2007
atsec information security
Fiona Pattinson
8th ICCC: Secure-System Design
21
References and Bibliography
•
•
•
•
© 2007
atsec information security
•
•
•
•
•
•
•
•
•
ISO/IEC 21827:2007 "Information technology -- Systems Security Engineering -- Capability
Maturity Model (SSE-CMM®)" JTC1/SC27
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'
8th ICCC: Secure-System Design
22