Security Architecture

Security Architecture

• 1.
  Phil Huggins Private SecurityConference Spring 2010
• 2.
  My recent experiencehas 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’
• 4.
   A set principles or maxims used to guide design decisions  AND  The design decisions taken (or constraints adopted) during the design process.
• 6.
   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
• 7.
   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
• 8.
   Constraints for design decisions  Shared amongst all designers  Consistent application across all design streams  Long history in security  Saltzer & Shroeder (1975)
• 11.
  1. Economy of mechanism 2. Fail safe defaults 3. Complete mediation 4. Orthogonal security mechanisms 5. Semantically consistent defence in depth 6. Separation of privilege 7. Least privilege 8. Least common mechanism 9. Psychological acceptability
• 12.
  10. Threats change 11.Design for failure 12. Use configuration control 13. Product certifications are of little utility 14. Design security in from the start 15. Include the flexibility to change security controls in the future 16. No single points of failure 17. Don't virtualise across security boundaries
• 14.
  http://blog.blackswansecurity.com