Unformatted text preview:

1Courtesy of ProfessorsChris Clifton & Matt BishopINFSCI 2935: Introduction of Computer Security 1Dec 9, 2004Dec 9, 2004Assurance & EvaluationAssurance & EvaluationMalicious code, Risk ManagementMalicious code, Risk ManagementLegal IssuesLegal IssuesLecture 10Lecture 10INFSCI 2935: Introduction to Computer Security 2TrustTrustll TrustworthyTrustworthy entity has sufficient credible entity has sufficient credible evidence leading one to believe that the system evidence leading one to believe that the system will meet a set of requirementswill meet a set of requirementsll TrustTrust is a measure of trustworthiness relying on is a measure of trustworthiness relying on the evidencethe evidencell AssuranceAssurance is confidence that an entity meets its is confidence that an entity meets its security requirements based on evidence security requirements based on evidence provided by the application of assurance provided by the application of assurance techniquestechniques¡Formal methods, design analysis, testing etc.2INFSCI 2935: Introduction to Computer Security 3RelationshipsRelationshipsPolicyMechanismsAssuranceStatement of requirements that explicitly definesthe security expectations of the mechanism(s)Provides justification that the mechanism meets policythrough assurance evidence and approvals based onevidenceExecutable entities that are designed and implementedto meet the requirements of the policyEvaluation standardsTrusted Computer System Evaluation Criteria Information Technology Security Evaluation Criteria Common CriteriaINFSCI 2935: Introduction to Computer Security 4Problem Sources (Neumann)Problem Sources (Neumann)1.1. Requirements definitions, omissions, and mistakesRequirements definitions, omissions, and mistakes2.2. System design flawsSystem design flaws3.3. Hardware implementation flaws, such as wiring and chip Hardware implementation flaws, such as wiring and chip flawsflaws4.4. Software implementation errors, program bugs, and Software implementation errors, program bugs, and compiler bugscompiler bugs5.5. System use and operation errors and inadvertent mistakesSystem use and operation errors and inadvertent mistakes6.6. Willful system misuseWillful system misuse7.7. Hardware, communication, or other equipment malfunctionHardware, communication, or other equipment malfunction8.8. Environmental problems, natural causes, and acts of GodEnvironmental problems, natural causes, and acts of God9.9. Evolution, maintenance, faulty upgrades, and Evolution, maintenance, faulty upgrades, and decommissionsdecommissions3INFSCI 2935: Introduction to Computer Security 5Types of AssuranceTypes of Assurancell Policy assurancePolicy assurance is evidence establishing security is evidence establishing security requirements in policy is complete, consistent, requirements in policy is complete, consistent, technically soundtechnically soundll Design assuranceDesign assurance is evidence establishing design is evidence establishing design sufficient to meet requirements of security policysufficient to meet requirements of security policyll Implementation assuranceImplementation assurance is evidence establishing is evidence establishing implementation consistent with security requirements of implementation consistent with security requirements of security policysecurity policyll OperationalOperational assuranceassurance is evidence establishing system is evidence establishing system sustains the security policy requirements during sustains the security policy requirements during installation, configuration, and dayinstallation, configuration, and day--toto--day operationday operationINFSCI 2935: Introduction to Computer Security 6Waterfall Life Cycle ModelWaterfall Life Cycle ModelRequirementsdefinition andanalysisSystem andsoftwaredesignImplementationand unittestingIntegrationand systemtestingOperationandmaintenance4INFSCI 2935: Introduction to Computer Security 7Other Models of Other Models of Software DevelopmentSoftware Developmentll Exploratory programmingExploratory programming¡Develop working system quickly¡No requirements or design specification, so low assurancell Prototyping (Similar to Exploratory)Prototyping (Similar to Exploratory)¡Objective is to establish system requirements¡Future iterations (after first) allow assurance techniquesll Formal transformationFormal transformation¡Create formal specification¡Very conducive to assurance methodsINFSCI 2935: Introduction to Computer Security 8ModelsModelsll System assembly from reusable componentsSystem assembly from reusable components¡Depends on whether components are trusted¡Must assure connections, composition as well¡Very complex, difficult to assure¡This is common approach to building secure and trusted systemsll Extreme programmingExtreme programming¡Rapid prototyping and “best practices”¡Project driven by business decisions¡Requirements open until project complete¡Components tested, integrated several times a day5INFSCI 2935: Introduction to Computer Security 9Architectural considerations for assuranceArchitectural considerations for assurancell Determine the focus of control of security Determine the focus of control of security enforcement mechanismenforcement mechanism¡Operating system: focus is on data¡Applications: more on operations/transactionsll Centralized or DistributedCentralized or Distributed¡Distribute them among systems/components¡Tradeoffs?¡Generally easier to “assure” centralized systemll Security mechanism may exist in any layerSecurity mechanism may exist in any layerINFSCI 2935: Introduction to Computer Security 10Architectural considerationsArchitectural considerationsExample: Four layer architectureExample: Four layer architecturell Application layerApplication layer¡Transaction controlll Services/middleware layerServices/middleware layer¡Support services for applications¡Eg., DBMS, Object reference brokersll Operating system layerOperating system layer¡Memory management, scheduling and process controlll HardwareHardware¡Includes firmware6INFSCI 2935: Introduction to Computer Security 11Trusted Computing BaseTrusted Computing Base(Security an integral part) (Security an integral part) ll Reference monitor (total mediation!)Reference monitor (total mediation!)¡ Mediates all accesses to objects by subjectsll Reference validation mechanism must beReference validation mechanism must be––1. Tamperproof2. Never be bypassed3. Small enough to be subject to analysis


View Full Document

Pitt IS 2935 - Assurance and Evaluation

Download Assurance and Evaluation
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Assurance and Evaluation and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Assurance and Evaluation 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?