• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Security Architecture
 

Security Architecture

on

  • 146 views

A presentation I gave to a private security conference in spring 2010.

A presentation I gave to a private security conference in spring 2010.

Statistics

Views

Total Views
146
Views on SlideShare
146
Embed Views
0

Actions

Likes
0
Downloads
6
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Security Architecture Security Architecture Presentation Transcript

    • Phil HugginsPrivate Security Conference Spring 2010
    • My recent experience has been: Large, complex systems Multi-year delivery 20+ people customer delivery teams 40+ people supplier delivery teams Need to know High threat 4 of them would be considered ‘death stars’
    •  A set principles or maxims used to guide design decisions AND The design decisions taken (or constraints adopted) during the design process.
    •  Everyone in a design process has models Implicit (intuition) or Explicit (written down) Usually somewhat wrong Usually somewhat incomplete People like to follow established practice Hard to challenge even in new circumstances
    •  Tools to aid thinking not replace thinking Reference architectures are not a design Risk is just one security model Most models are good for the purpose they have been created If you’re doing something exceptional expect the model to be less useful
    •  Constraints for design decisions Shared amongst all designers Consistent application across all design streams Long history in security  Saltzer & Shroeder (1975)
    • 1. Economy of mechanism2. Fail safe defaults3. Complete mediation4. Orthogonal security mechanisms5. Semantically consistent defence in depth6. Separation of privilege7. Least privilege8. Least common mechanism9. Psychological acceptability
    • 10. Threats change11. Design for failure12. Use configuration control13. Product certifications are of little utility14. Design security in from the start15. Include the flexibility to change security controls in the future16. No single points of failure17. Dont virtualise across security boundaries
    • http://blog.blackswansecurity.com