© 2007 atsec information security 8 th ICCC: Secure-System Design 1 Secure-System Design Hadrian’s wall in Northern England Designing systems with security

1

© 2

007

a

tse

c in

form

atio

n s

ecu

rity

8th ICCC: Secure-System Design

Secure-System DesignH

adria

n’s

wal

l in

Nor

ther

n E

ngla

nd

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.

Fiona Pattinson

2

© 2

007

a

tse

c in

form

atio

n s

ecu

rity


Secure-System Design (SSD)

• 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)

3

© 2

007

a

tse

c in

form

atio

n s

ecu

rity


Some examples of system and software development models

4

© 2

007

a

tse

c in

form

atio

n s

ecu

rity


Security in the Lifecycle

• Security Requirements– Common Criteria (SFR , SAR)

• Security Design– Threat Modeling (CEM Appendix)– Stepwise Refinement (Levels of abstraction)

• Security Verification– Static Code Analysis– Common Criteria, FIPS 140-2

• Security Validation– Penetration Testing– Field!

6

© 2

007

a

tse

c in

form

atio

n s

ecu

rity


Maturity of the Security-Design Discipline

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

7

© 2

007

a

tse

c in

form

atio

n s

ecu

rity


Frameworks Providing structure to design

• Most general frameworks for software/system development process don’t consider secure-system design– 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

© 2

007

a

tse

c in

form

atio

n s

ecu

rity


FrameworksProviding structure to design

• Some Frameworks for system/software development consider secure-system design– 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.)

9

© 2

007

a

tse

c in

form

atio

n s

ecu

rity


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.

(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• 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.

®

10

© 2

007

a

tse

c in

form

atio

n s

ecu

rity


Requirements:Specifications & Standards

• Specifications: often embed “best practices” for security design– FIPS 140-2: Cryptographic Modules

• Technical Standards: technical building blocks (higher-level design abstraction– Crypto Primitives – Protocol definitions

11

© 2

007

a

tse

c in

form

atio

n s

ecu

rity


Requirements:Legislation/Regulation

• 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

12

© 2

007

a

tse

c in

form

atio

n s

ecu

rity


Requirements:SFR Classes and examples of families

• 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

13

© 2

007

a

tse

c in

form

atio

n s

ecu

rity


Security-Design:Guidelines

• Assume that Human Behavior Will Introduce Vulnerabilities into Your System

• Assume that Technology Will Contain Vulnerabilities– 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"

14

© 2

007

a

tse

c in

form

atio

n s

ecu

rity


Security-Design: Principles

• 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

15

© 2

007

a

tse

c in

form

atio

n s

ecu

rity


Security-Design Techniques

• Techniques– Threat Modeling– Risk Assessment– Secure Coding– Vulnerability

Assessment– Formal Methods– Cryptographic

Techniques & primatives

– Access Control

• MAC / DAC

– Multilevel Security

• Bell LaPadula

• Biba

– Trusted System

– Secure Operating System

– Reference monitor

– Static Code Analysis

– Reverse Engineering

17

© 2

007

a

tse

c in

form

atio

n s

ecu

rity


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

18

© 2

007

a

tse

c in

form

atio

n s

ecu

rity


Examples of Security-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)

• 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

Structural patterns Procedural patterns

From the Security Patterns Repository V1.0At http://www.scrypt.net/~celer/securitypatterns/

19

© 2

007

a

tse

c in

form

atio

n s

ecu

rity


SSD and Common Criteria

• 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

20

© 2

007

a

tse

c in

form

atio

n s

ecu

rity


Security-Design Verification

• To provide assurance a design should be verifiable.

• There is a well known & mature method for that…

21

© 2

007

a

tse

c in

form

atio

n s

ecu

rity


Security-Design Validation

• To determine if the design works. Is the system design meeting the security-requirements in the field?– Assurance, Common Criteria– Ongoing Vulnerability Analysis– Penetration Testing

22

© 2

007

a

tse

c in

form

atio

n s

ecu

rity


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

23

© 2

007

a

tse

c in

form

atio

n s

ecu

rity


Thank You

Fiona Pattinsonatsec Information Security Corporation

Austin, Texas, USA

Phone: +1 512 615 7382

Email: [email protected]

www.atsec.com

24

© 2

007

a

tse

c in

form

atio

n s

ecu

rity


References and Bibliography• 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‘• Anderson, J. P. 1972, Computer Security Technology Panning Study: VOL1 & 2, USAF.

25

© 2

007

a

tse

c in

form

atio

n s

ecu

rity


Abbreviations Used

• 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

Documents

© 2007 atsec information security 8 th ICCC: Secure-System Design 1 Secure-System Design Hadrian’s wall in Northern England Designing systems with security