Security Architecture

181 views

Published on

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

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
181
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Security Architecture

  1. 1. Phil HugginsPrivate Security Conference Spring 2010
  2. 2. 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’
  3. 3.  A set principles or maxims used to guide design decisions AND The design decisions taken (or constraints adopted) during the design process.
  4. 4.  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
  5. 5.  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
  6. 6.  Constraints for design decisions Shared amongst all designers Consistent application across all design streams Long history in security  Saltzer & Shroeder (1975)
  7. 7. 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
  8. 8. 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
  9. 9. http://blog.blackswansecurity.com

×