Nov 15, 2005

1. Nov 15, 2005 Assurance IS2150/TEL2910: Introduction of Computer Security

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

3. Trust • 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 the application of assurance techniques • Formal methods, design analysis, testing etc. IS2150/TEL2910: Introduction of Computer Security

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

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

6. Examples • Challenger explosion (1986) • 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 (trigonometric function) • Cost a lot of time and money IS2150/TEL2910: Introduction of Computer Security

7. Role 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 and business goals • Security requirements are specific, concrete issues IS2150/TEL2910: Introduction of Computer Security

8. Types of Assurance • 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 • Implementation assurance is evidence establishing implementation consistent with security requirements of security policy • Need to use good engineering practices IS2150/TEL2910: Introduction of Computer Security

9. Types of Assurance • Operationalassurance 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. IS2150/TEL2910: Introduction of Computer Security

10. Assurance steps IS2150/TEL2910: Introduction of Computer Security

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

12. Conception • Idea • Decisions to pursue it • Proof of concept • See if idea has merit • Rapid prototyping, analysis, etc. • 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? IS2150/TEL2910: Introduction of Computer Security

13. Manufacture • 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 • Includes decisions whether to proceed, for example due to market needs • May be the longest stage IS2150/TEL2910: Introduction of Computer Security

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

15. Fielded 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 • Answering questions; recording bugs • Retirement or decommission of product • Migration plans for customers IS2150/TEL2910: Introduction of Computer Security

16. Waterfall 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 maintenance IS2150/TEL2910: Introduction of Computer Security

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

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

19. 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 assure • This is common approach to building secure and trusted systems IS2150/TEL2910: Introduction of Computer Security

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

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

22. Threats and Vulnerabilities • 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 • A weakness that makes it possible for a threat to occur IS2150/TEL2910: Introduction of Computer Security

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

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

25. Architectural considerations • 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 • Application security means OS security as well • Special-purpose OS? • All DBMSs require the OS to provide specific security features IS2150/TEL2910: Introduction of Computer Security

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

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

28. Security Policy Requirements • Can be done at different levels • Specification must be • Clear • “meet C2 security” • Unambiguous • “users must be identified and authenticated” • Complete • 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 IS2150/TEL2910: Introduction of Computer Security

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

30. Techniques for Design Assurance • 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 • 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 IS2150/TEL2910: Introduction of Computer Security

31. Design Documents • Design documentation is an important component in life cycle models • 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 IS2150/TEL2910: Introduction of Computer Security

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

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

34. Design meets requirements? • 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 proof mechanisms are usually based on logic (predicate calculus) • Model checking • Checks that a model satisfies a specification IS2150/TEL2910: Introduction of Computer Security

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

36. Implementation considerations for assurance • Modularity with minimal interfaces • 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) IS2150/TEL2910: Introduction of Computer Security

37. Assurance through Implementation management • 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? IS2150/TEL2910: Introduction of Computer Security

38. Implementation meets Design? • 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 • 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 IS2150/TEL2910: Introduction of Computer Security

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

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