Slide 1Slide 2Slide 3Slide 4Slide 5Slide 6Slide 7Slide 8Slide 9Slide 10Slide 11Slide 14Slide 15Slide 16Slide 18Slide 19Slide 20Slide 21Slide 22Slide 23Slide 24Slide 25Slide 26Slide 27Slide 28Slide 29Slide 30Slide 31Slide 32Slide 33Slide 34Slide 35Slide 36Slide 37Slide 38Slide 39Slide 40Slide 41Secure DesignInformation AssuranceFall 2006Secure DesignInformation AssuranceFall 2006Reading Material•Chapter 19 of Computer Security: Art and Science•Threat Modeling by Frank Swiderski and Window Snyder•Build Security in Portal https://buildsecurityin.us-cert.gov/–Particularly Article on Risk-Base and Functional Security Testing–https://buildsecurityin.us-cert.gov/daisy/bsi/articles/best-practices/testing/255.html?branch=1&language=1•Secure Coding: Principles and Practices by Mark G. Graff and Kenneth R. van WykOutline•Secure Design–Best Practices–Security Requirements–Assurance Techniques•Threat Modeling•Other Design/Development Issues•TestingGoals for Secure Development•Correct Operation–System does what it supposed to do•Secure Operation–System operation cannot be corrupted•Assured System–Evidence that system operates within specified security and feature requirementsSecure Design•Good software engineering principles–Common sense–Stuff you know you should be doing–An art not a science. Valuable to review and be aware of•Presence of bugs in general provide opportunity for security vulnerabilities•Security addressed up frontBest Practices•Discussed 8 design principles•Numerous other Check Lists and best Practices documents–GASSP http://www.auerbach-publications.com/dynamic_data/2334_1221_gassp.pdf–http://csrc.nist.gov/pcig/–Security at a Glance Checklist http://www.securecoding.org/companion/checklists/SAG/•Check lists are useful, but should not be followed blindly–Dependent on application domain, organization, technology•Newer tools integrate best practice enforcement–E.g. Numega, RationalSecurity Architecture•High level design that addresses the security requirements•Model that lets the designers and developers reason about the security functions of the system–Metaphors for security can be useful•E.g. think about folders and filing cabinets in sheds•Same security architecture can be reused between similar applications–E.g., can use same style of security architecture over multiple client-server applicationsLayered Architecture•Can address security at any or all layers–Application–Service/Middleware–Operating system–HardwareSecure Core•Reference Monitor – control element that mediates all access to objects•Reference Validation Mechanism (RVM) – an implementation of a reference monitor–Tamperproof–Always invoked–Small enough to be subject to analysis and testing, the completeness of which can be assuredRVM Implementations•Security kernel – Software and hardware that implements the RVM•Trusted Computing Base (TCB) – All protection mechanisms which a computing system responsible for enforcing a security policy–Indirectly includes elements used by TCBSecurity Requirements•Security is generally non-functional–e.g., Application should be secure against intruders•Need to make requirements more precise–Version 1: “Users must be identified and authenticated”–Version 2: “Uses of system must be identified and authenticated by system”–Version 3: Adds “... before system performs any actions on behalf of user”•Ideally can map to existing precise requirementsSecurity Requirement Completeness•Justify security requirements by associating requirements with threats•Identified during project requirements phase–Use security requirements to drive security architecture–Identify assets to protect•Rank importance of asset•Cost/benefitExample Threat•Threat T1: Person not authorized to use the system gains access by impersonating authorized user•Requirement IA1: User session must begin with proof of authentication•Assumption A1: The product must be configured such that only the approved group of users has physical access to the system•Assumption A4: Passwords generated by admin will be distributed in secure mannerDesign Documents•Security Architecture–High level function descriptions–Mapping to requirements•External Interfaces–Functional specification•Internal Design Description for each component–Overview of parent component–Detailed description–Security relevance•Literate programming tools can help with Interface and Internal Docs–e.g., Java doc and DoxygenRequirements Tracing•One means of assurance–Mapping security requirement to lower design levels–Map security design elements to implementation–Map security implementation to testOther Design Assurance Options•Informal Arguments•Formal Methods–Theorem provers–Model Checkers–UML to some degree•UML tools can drive this formalism down to implementation and test•Review MeetingsThreat Modeling•Similar to risk analysis–Discussed in Threat Modeling by Frank Swiderski and Window Snyder–Also UML notation http://coras.sourceforge.net/documents/uml-sa-report2.pdf•Systematically analyze code–Entry points, use scenarios, data flow diagrams–Number everything•Develop threat models or attack trees–Use to drive necessary mitigations/counter measuresAdversary’s Point of View•Analyze entry points–Where the attacks must start–Uniquely number entry points•Understand assets–What is goal of attack•Trust levels–Expected privilege levels associated with each entry pointEntry Point Analysis•For each entry point document–Name, id, description, trust levels•Example, web listening port–Id = 1–Description = The port that the web server listens on.–Trust Levels•1 – remote anonymous user•2 – remote user with login credentials•3 – Insurance Agent•4 – Web adminCharacterize System Security•Use Scenarios–Document how the system is expected to be used–E.g., web server will communicate with database on private network•Identify assumptions and dependencies–E.g. web server depends on security of underlying session managementData Flow Diagrams•Models –Where entry points are used–external entities–changes of protection domain•DFD’s can be nestedExample DFDThreat Profiling•Start by looking at the assets•STRIDE classification–Spoofing–Tampering–Repudiation–Information Disclosure–Denial of
View Full Document
Unlocking...