Slide #18-1Introduction to AssuranceCS498SHFall 2006Based on slides provided by Matt Bishop for use with Computer Security: Art and ScienceSlide #18-2Reading Material•Chapter 18 Computer Security: Art and ScienceSlide #18-3Overview•Trust•Problems from lack of assurance•Types of assurance•Life cycle and assurance•Waterfall life cycle model•Other life cycle modelsSlide #18-4Trust•Trustworthy entity has sufficient credible evidence leading one to believe that the system will meet a set of requirements•Trust is a measure of trustworthiness relying on the evidence•Assurance is confidence that an entity meets its security requirements based on evidence provided by applying assurance techniquesSlide #18-5RelationshipsP o l i c yM e c h a n i s m sA s s u r a n c eS t a t e m e n t o f r e q u i r e m e n t s t h a t e x p l i c i t l y d e f i n e st h e s e c u r i t y e x p e c t a t i o n s o f t h e m e c h a n i s m ( s )P r o v i d e s j u s t i f i c a t i o n t h a t t h e m e c h a n i s m m e e t s p o l i c yt h r o u g h a s s u r a n c e e v i d e n c e a n d a p p r o v a l s b a s e d o ne v i d e n c eE x e c u t a b l e e n t i t i e s t h a t a r e d e s i g n e d a n d i m p l e m e n t e dt o m e e t t h e r e q u i r e m e n t s o f t h e p o l i c ySlide #18-6Problem Sources1. Requirements definitions, omissions, and mistakes2. System design flaws3. Hardware implementation flaws, such as wiring and chip flaws4. Software implementation errors, program bugs, and compiler bugs5. System use and operation errors and inadvertent mistakes6. Willful system misuse7. Hardware, communication, or other equipment malfunction8. Environmental problems, natural causes, and acts of God9. Evolution, maintenance, faulty upgrades, and decommissionsSlide #18-7Examples•Challenger explosion–Sensors removed from booster rockets to meet accelerated launch schedule•Deaths from faulty radiation therapy system–Hardware safety interlock removed–Flaws in software design•Bell V22 Osprey crashes–Failure to correct for malfunctioning components; two faulty ones could outvote a third•Intel 486 chip–Bug in trigonometric functionsSlide #18-8Role of Requirements•Requirements are statements of goals that must be met–Vary from high-level, generic issues to low-level, concrete issues•Security objectives are high-level security issues•Security requirements are specific, concrete issuesSlide #18-9Types of Assurance•Policy assurance is evidence establishing security requirements in policy is complete, consistent, technically sound•Design assurance is evidence establishing design sufficient to meet requirements of security policy•Implementation assurance is evidence establishing implementation consistent with security requirements of security policySlide #18-10Types of Assurance•Operational assurance is evidence establishing system sustains the security policy requirements during installation, configuration, and day-to-day operation–Also called administrative assuranceSlide #18-11Life CycleS e c u r i t y r e q u i r e m e n t sD e s i g nI m p l e m e n t a t i o n1324A s s u r a n c ej u s t i f i c a t i o nD e s i g n a n di m p l e m e n t a t i o nr e fi n e m e n tSlide #18-12Life Cycle•Conception•Manufacture•Deployment•Fielded Product LifeSlide #18-13Conception•Idea–Decisions to pursue it•Proof of concept–See if idea has merit•High-level requirements analysis–What does “secure” mean for this concept?–Is it possible for this concept to meet this meaning of security?–Is the organization willing to support the additional resources required to make this concept meet this meaning of security?Slide #18-14Manufacture•Develop detailed plans for each group involved–May depend on use; internal product requires no sales•Implement the plans to create entity–Includes decisions whether to proceed, for example due to market needsSlide #18-15Deployment•Delivery–Assure that correct masters are delivered to production and protected–Distribute to customers, sales organizations•Installation and configuration–Ensure product works appropriately for specific environment into which it is installed–Service people know security proceduresSlide #18-16Fielded Product Life•Routine maintenance, patching–Responsibility of engineering in small organizations–Responsibility may be in different group than one that manufactures product•Customer service, support organizations•Retirement or decommission of productSlide #18-17Waterfall Life Cycle Model•Requirements definition and analysis–Functional and non-functional–General (for customer), specifications•System and software design•Implementation and unit testing•Integration and system testing•Operation and maintenanceSlide #18-18Relationship of StagesR e q u i r e m e n t sd e f i n i t i o n a n da n a l y s i sS y s t e m a n ds o f t w a r ed e s i g nI m p l e m e n t a t i o na n d u n i tt e s t i n gI n t e g r a t i o na n d s y s t e mt e s t i n gO p e r a t i o na n dm a i n t e n a n c eSlide #18-19Development Models•Exploratory programming–Develop working system quickly–Used when detailed requirements specification cannot be formulated in advance, and adequacy is goal–No requirements or design specification, so low assurance•Prototyping–Objective is to establish system requirements–Future iterations (after first) allow assurance techniquesSlide #18-20Development Models•Formal transformation–Create formal specification–Translate it into program using correctness-preserving transformations–Very conducive to assurance methods•System assembly from reusable components–Depends on whether components are trusted–Must assure connections, composition as well–Very complex, difficult to assureSlide #18-21Development Models•Spiral or Iterative Model–Many of the same components as waterfall– Need to revisit levels of waterfall is explicit–Iteration can be harder to track• Sneaking in a new feature as part of an iteration–Some commercial tools to help track•Rational Unified Process (RUP)Slide #18-22Development Models•Extreme programming–Rapid prototyping and “best practices”–Project driven by business decisions–Requirements open until project complete–Programmers work in teams–Components tested, integrated several times a
View Full Document
Unlocking...