IS2150/TEL2910: Introduction of Computer Security1 Nov 15, 2005 Assurance

2IS2150/TEL2910: Introduction of Computer Security Overview Trust Trust Problems from lack of assurance Problems from lack of assurance Types of assurance Types of assurance Life cycle and assurance Life cycle and assurance Waterfall life cycle model Waterfall life cycle model Other life cycle models Other life cycle models

3IS2150/TEL2910: Introduction of Computer Security Trust Trustworthy entity has sufficient credible evidence leading one to believe that the system will meet a set of requirements 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 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 the application of assurance techniques Assurance is confidence that an entity meets its security requirements based on evidence provided by the application of assurance techniques  Formal methods, design analysis, testing etc.

4IS2150/TEL2910: Introduction of Computer Security Relationships Evaluation standards Trusted Computer System Evaluation Criteria Information Technology Security Evaluation Criteria Common Criteria

5IS2150/TEL2910: Introduction of Computer Security Problem Sources (Neumann) 1.Requirements definitions, omissions, and mistakes 2.System design flaws 3.Hardware implementation flaws, such as wiring and chip flaws 4.Software implementation errors, program bugs, and compiler bugs 5.System use and operation errors and inadvertent mistakes 6.Willful system misuse 7.Hardware, communication, or other equipment malfunction 8.Environmental problems, natural causes, and acts of God 9.Evolution, maintenance, faulty upgrades, and decommissions

6IS2150/TEL2910: Introduction of Computer Security Examples Challenger explosion (1986) Challenger explosion (1986)  Sensors removed from booster rockets to meet accelerated launch schedule Deaths from faulty radiation therapy system Deaths from faulty radiation therapy system  Hardware safety interlock removed  Flaws in software design Bell V22 Osprey crashes Bell V22 Osprey crashes  Failure to correct for malfunctioning components; two faulty ones could outvote a third Intel 486 chip bug (trigonometric function) Intel 486 chip bug (trigonometric function)  Cost a lot of time and money

7IS2150/TEL2910: Introduction of Computer Security Role of Requirements Requirements are statements of goals that must be met 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 and business goals Security objectives are high-level security issues and business goals Security requirements are specific, concrete issues Security requirements are specific, concrete issues

8IS2150/TEL2910: Introduction of Computer Security Types of Assurance Policy assurance is evidence establishing security requirements in policy is complete, consistent, technically sound Policy assurance is evidence establishing security requirements in policy is complete, consistent, technically sound  To counter threats and meet objectives Design assurance is evidence establishing design sufficient to meet requirements of security policy 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 policy Implementation assurance is evidence establishing implementation consistent with security requirements of security policy  Need to use good engineering practices

9IS2150/TEL2910: Introduction of Computer Security Types of Assurance Operational assurance is evidence establishing system sustains the security policy requirements during installation, configuration, and day-to-day operation Operational assurance is evidence establishing system sustains the security policy requirements during installation, configuration, and day-to-day operation  Also called administrative assurance  Example, Do a thorough review of product or system documentation and procedures, to ensure that the system cannot accidentally be placed in a non-secure state.

10IS2150/TEL2910: Introduction of Computer Security Assurance steps

11IS2150/TEL2910: Introduction of Computer Security Life Cycle Conception Conception Manufacture Manufacture Deployment Deployment Fielded Product Life Fielded Product Life

12IS2150/TEL2910: Introduction of Computer Security Conception Idea Idea  Decisions to pursue it Proof of concept Proof of concept  See if idea has merit  Rapid prototyping, analysis, etc. High-level requirements analysis High-level requirements analysis  What does “secure” mean for this concept? Identify threats  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?

13IS2150/TEL2910: Introduction of Computer Security Manufacture Develop detailed plans for each group involved Develop detailed plans for each group involved  May depend on use; internal product requires no sales  Plans: marketing, sales training, development, testing  Software development and engineering process Implement the plans to create entity Implement the plans to create entity  Includes decisions whether to proceed, for example due to market needs May be the longest stage May be the longest stage

14IS2150/TEL2910: Introduction of Computer Security Deployment Delivery Delivery  Assure that correct (assured) masters are delivered to production and protected  Distribute to customers, sales organizations Installation and configuration Installation and configuration  Developers must ensure that the system operates properly in the production environment

15IS2150/TEL2910: Introduction of Computer Security Fielded Product Life Routine maintenance, patching Routine maintenance, patching  Responsibility of engineering in small organizations  Responsibility may be in different group than one that manufactures product Customer service, support organizations Customer service, support organizations  Answering questions; recording bugs Retirement or decommission of product Retirement or decommission of product  Migration plans for customers

16IS2150/TEL2910: Introduction of Computer Security Waterfall Life Cycle Model Requirements definition and analysis Requirements definition and analysis  Functional and non-functional  General (for customer), specifications System and software design System and software design Implementation and unit testing Implementation and unit testing Integration and system testing Integration and system testing Operation and maintenance Operation and maintenance

17IS2150/TEL2910: Introduction of Computer Security Relationship of Stages

18IS2150/TEL2910: Introduction of Computer Security Other Models of Software Development Exploratory programming 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 (Similar to Exploratory) Prototyping (Similar to Exploratory)  Objective is to establish system requirements  Future iterations (after first) allow assurance techniques

19IS2150/TEL2910: Introduction of Computer Security Models Formal transformation Formal transformation  Create formal specification  Translate it into program using correctness- preserving transformations  Very conducive to assurance methods System assembly from reusable components System 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 systems

20IS2150/TEL2910: Introduction of Computer Security Models Extreme programming 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 day  Objective is to get system into production as quickly as possible, then enhance it  Evidence adduced after development needed for assurance

21IS2150/TEL2910: Introduction of Computer Security Key Points Assurance critical for determining trustworthiness of systems Assurance critical for determining trustworthiness of systems Different levels of assurance, from informal evidence to rigorous mathematical evidence Different levels of assurance, from informal evidence to rigorous mathematical evidence Assurance needed at all stages of system life cycle Assurance needed at all stages of system life cycle

22IS2150/TEL2910: Introduction of Computer Security Threats and Vulnerabilities Threat Threat  A potential occurrence that can have an undesirable effect on the system assets of resources Results in breaches in confidentiality, integrity, or a denial of service Example: outsider penetrating a system is an outsider threat (insider threat?) Need to identify all possible threats and address them to generate security objectives Vulnerability Vulnerability A weakness that makes it possible for a threat to occur

23IS2150/TEL2910: Introduction of Computer Security Architectural considerations Determine the focus of control of security enforcement mechanism Determine the focus of control of security enforcement mechanism  Operating system: focus is on data  Applications: more on operations/transactions Centralized or Distributed Centralized or Distributed  Distribute them among systems/components  Tradeoffs?  Generally easier to “assure” centralized system Security mechanism may exist in any layer Security mechanism may exist in any layer

24IS2150/TEL2910: Introduction of Computer Security Architectural considerations Example: Four layer architecture Application layer Application layer  Transaction control Services/middleware layer Services/middleware layer  Support services for applications  Eg., DBMS, Object reference brokers Operating system layer Operating system layer  Memory management, scheduling and process control Hardware Hardware  Includes firmware

25IS2150/TEL2910: Introduction of Computer Security Architectural considerations Select the correct layer for a mechanism Select the correct layer for a mechanism  Controlling user actions may be more effective at application layer  Controlling file access may be more effective at the operating system layer  Recall PEM! How to secure layers lower to target layer How to secure layers lower to target layer  Application security means OS security as well  Special-purpose OS?  All DBMSs require the OS to provide specific security features

26IS2150/TEL2910: Introduction of Computer Security Build or Add? Security is an integral part of a system Security is an integral part of a system  Address security issues at system design phase  Easy to analyze and assure Reference monitor (total mediation!) Reference monitor (total mediation!)  Mediates all accesses to objects by subjects Reference validation mechanism must be– Reference validation mechanism must be– 1.Tamperproof 2.Never be bypassed 3.Small enough to be subject to analysis and testing – the completeness can be assured Security kernel Security kernel  Hardware + software implementing a RM

27IS2150/TEL2910: Introduction of Computer Security Trusted Computing Base TCB consists of all protection mechanisms within a computer system that are responsible for enforcing a security policy TCB consists of all protection mechanisms within a computer system that are responsible for enforcing a security policy TCB monitors four basic interactions TCB monitors four basic interactions  Process activation  Execution domain switching  Memory protection  I/O operation A unified TCB may be too large A unified TCB may be too large  Create a security kernel

28IS2150/TEL2910: Introduction of Computer Security Security Policy Requirements Can be done at different levels Can be done at different levels Specification must be Specification must be  Clear “meet C2 security”  Unambiguous “users must be identified and authenticated”  Complete Methods of defining policies Methods of defining policies  Extract applicable requirements from existing security standards (e.g. Common Criteria)  Create a policy based on threat analysis  Map the system to an existing model Justify the requirements: completeness and consistency Justify the requirements: completeness and consistency

29IS2150/TEL2910: Introduction of Computer Security Design assurance Identify design flaws Identify design flaws  Enhances trustworthiness  Supports implementation and operational assurance Design assurance technique employs Design assurance technique employs  Specification of requirements  Specification of the system design  Process to examine how well the design meets the requirement

30IS2150/TEL2910: Introduction of Computer Security Techniques for Design Assurance Modularity & Layering Modularity & Layering  Well defined independent modules  Simplifies and makes system more understandable  Data hiding  Easy to understand and analyze Different layers to capture different levels of abstraction Different layers to capture different levels of abstraction  Subsystem (memory management, I/O subsystem, credit- card processing function)  Subcomponent (I/O management, I/O drivers)  Module: set of related functions and data structure Use principles of secure design Use principles of secure design

31IS2150/TEL2910: Introduction of Computer Security Design Documents Design documentation is an important component in life cycle models Design documentation is an important component in life cycle models Documentation must specify Documentation must specify  Security functions and approach Describe each security function Overview of a set of security functions Map to requirements (tabular)  External interfaces used by users Parameters, syntax, security constraints and error conditions Component overview, data descriptions, interface description  Internal design with low-level details Overview of the component Detailed description of the component Security relevance of the component

32IS2150/TEL2910: Introduction of Computer Security Design meets requirements? Techniques needed Techniques needed  To prevent requirements and functionality from being discarded, forgotten, or ignored at lower levels of design Requirements tracing Requirements tracing  Process of identifying specific security requirements that are met by parts of a description Informal Correspondence Informal Correspondence  Process of showing that a specification is consistent with an adjacent level of specification

33IS2150/TEL2910: Introduction of Computer Security Requirement mapping and informal correspondence Security Functional Requirements External Functional Specification Internal Design Specification Implementation Code Requirement Tracing Informal Correspondence

34IS2150/TEL2910: Introduction of Computer Security Design meets requirements? Informal arguments Informal arguments  Protection profiles Define threats to systems and security objectives Provide rationale (an argument)  Security targets Identifies mechanisms and provide justification Formal methods: proof techniques Formal methods: proof techniques  Formal proof mechanisms are usually based on logic (predicate calculus)  Model checking Checks that a model satisfies a specification

35IS2150/TEL2910: Introduction of Computer Security Design meets requirements? Review Review  When informal assurance technique is used  Usually has three parts Reviews of guidelines Conflict resolution methods Completion procedures

36IS2150/TEL2910: Introduction of Computer Security Implementation considerations for assurance Modularity with minimal interfaces Modularity with minimal interfaces Language choice Language choice  C programs may not be reliable Pointers – memory overwrites Not much error handling Writing past the bounds of memory and buffers Notorious for Buffer overflow!  Java Designed to support secure code as a primary goal Ameliorates C security risks present in C Sandbox model (mobile code security)

37IS2150/TEL2910: Introduction of Computer Security Assurance through Implementation management Configuration management tools Configuration management tools  Control of the refinement and modification of configuration items such as source code, documentation etc.  CM system functions Version control and tracking Change authorization Integration procedures Tools for product generation CVS?

38IS2150/TEL2910: Introduction of Computer Security Implementation meets Design? Security testing Security testing  Functional testing (FT) (black box testing) Testing of an entity to determine how well it meets its specification  Structural testing (ST) (white box testing) Testing based on an analysis of the code to develop test cases Testing occurs at different times Testing occurs at different times  Unit testing (usually ST): testing a code module before integration  System testing (FT): on integrated modules  Security testing: product security Security functional testing (against security issues) Security structural testing (security implementation) Security requirements testing

39IS2150/TEL2910: Introduction of Computer Security Code development and testing Code Unit test Integrate Build system Execute system Test on current Build Code Test the test On current build Integrate tested test into automated Test suite Build test suite Code bugs

40IS2150/TEL2910: Introduction of Computer Security Operation and maintenance assurance Bugs in operational phase need fixing Bugs in operational phase need fixing Hot fix Hot fix  Immediate fix  Bugs are serous and critical Regular fix Regular fix  Less serious bugs  Long term solution after a hot fix