1 / 53

Trusted Computing Systems

Trusted Computing Systems. Definitions and Standards. Trusted Computer Systems. IT security is increasingly important Info can have varying degrees of sensitivity Subjects (people or programs) can have varying rights of access to objects (information)

zacharee
Télécharger la présentation

Trusted Computing Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Trusted Computing Systems Definitions and Standards

  2. Trusted Computer Systems • IT security is increasingly important • Info can have varying degrees of sensitivity • Subjects (people or programs) can have varying rights of access to objects (information) • IT managers demand increasing confidence in systems to enforce these rights

  3. Information System Security “Information system security is the application of managerial and administrative procedures and technical and physical safeguards to ensure not only the confidentiality, integrity and availability of information which is processed by an information system, but also of the information system itself, together with its environment. Such procedures and safeguards not only need to deter and delay improper access to information systems, they must also ensure that any improper access is detected; that is, individuals have to be made accountable for their actions. [Secman 3 - 103]

  4. Trusted Computer Systems Issues • Need to consider: • system security • physical security • communications security • Most concerned with system security & how to assure its correctness

  5. Rainbow Series—Early 1980’s Orange Book, etc.

  6. TCSEC Trusted Computer System Evaluation Criteria ("Orange Book") • Standard for single computer systems with terminal access • First standard definition of a trusted computer system, how to evaluate and ensure them • Original spec Aug 83, revised Dec 85 • Has tight coupling between functionality & assurance

  7. Criteria TCSEC defines a number of criteria within broad categories of: • Security Policy must have an explicit, enforced security policy; objects in system need access control labels • Accountability access to information must be controlled by rights of subjects vs. class of information; audit trails must be kept • Assurance system must contain mechanisms which can be independently evaluated to provide sufficient assurance that they enforce the stated requirements

  8. Other "Rainbow Book" Standards • Red Book Trusted Network Interpretation • Yellow Book Methodology for Security Risk Assessment • Lavendar Book Database Security Evaluation

  9. Evaluation Criteria Classes

  10. TCSEC Functionality RequirementsN means New/Changed/Enhanced functionality required= means no additional requirements

  11. ITSEC—Followed TCSEC • European Version

  12. ITSEC • Information Technology Security Evaluation Criteria (ITSEC) • European trusted evaluation standard harmonized with TCSEC - Unlike TCSEC, designed for both single & multiple networked systems - Target Of Evaluation (TOE) = evaluated system - Structured around - assurance and functionality • Details evaluation process by independent evaluators working with developer and sponsor • Evaluator: - Checks test & analysis results supplied by sponsor and - Performs additional tests to audit and supplement these

  13. Assurance • Correctness is addressed both from: - development process & environment in building TOE - operation of the TOE • TOE must also be assessed for: - suitability and binding of functionality - consequences of known and discovered vulnerabilities - strength of security mechanisms against direct attack

  14. Assurance – 7 evaluation levels • E0 -inadequate • E1 - statement of security objects, informal description of security architecture • E2 - +informal description of detailed design, testing, configuration control and controlled distribution • E3 - +detailed design and source code evaluated • E4 - +formal security policy model, rigorous architectural and detailed design, vulnerability analysis • E5 - +close correspondence between detailed design and source code, vulnerability analysis on source code • E6 - +formal description of TOE consistent with formal security model, evaluation of object code against source

  15. Functionality • Expressed as security objectives, functions & mechanisms • Security objectives defined as natural language security policy or formal model • Functionality classes defined by categories: • identification & authentication, • access control, • accountability, • audit, • object reuse, • accuracy, • reliability of service and • data exchange

  16. Functionality Levels • F1-F5 - map onto TCSEC classes with appropriate assurance levels (C1,C2,B1,B2,B3,A1 = F1+E1,F2+E2,F3+E3,F4+E4,F5+E5,F5+E6) • F6 - high integrity systems (eg. financial) • F7 - high availability/mission critical systems • F8 - high integrity data communications systems • F9 - high confidentiality data communications systems • F10 - high confidentiality and integrity networks

  17. Common Criteria—Today • ISO standard

  18. Common Criteria • Common Criteria being developed as an ISO standard (JTC1.SC27) • Based on existing TCSEC, ITSEC, CTCPEC (Canadian), Federal (US) standards • Concerned with standards for: - evaluation criteria - methodology for application of criteria - administrative procedures for evaluation, certification & accreditation schemes

  19. Common Criteria CC Part 1 covers: • IT Security • "reduction of risks associated with threats to the information arising directly or indirectly from human error or deliberate subversion“ • Threat Analysis • to discover conceivable threats • Risk Analysis • to determine countermeasures

  20. Common Criteria Key Concepts • Protection Profile • set of generic security requirements for some applications sector • Security Target • a particular instance of a PP • Target of Evaluation • actual system evaluated

  21. Functional Class Set • identification & authentication • trusted path • security audit • TOE entry • user data protection • resource utilization & availability • protection of TOE security functions • physical protection • privacy • communications

  22. Assurance Levels • AL0 - unassured • AL1 - tested • AL2 - structurally tested • AL3 - methodically tested & checked • AL4 - methodically tested & reviewed • AL5 - semiformal design • AL6 - semiformal verified design • AL7 - formally verified design

  23. DSD Publications • Australian Version

  24. DSD Publications • Defense Signals Directorate (DSD) - Australia's national authority - signals intelligence and - information security • DSD's Infosec role not classified • Infosec products and services available: http://www.dsd.gov.au/infosec/

  25. ACSI33 • Australian Communications-Electronic Security Instruction 33 (ACSI 33) • Developed by DSD • Provides guidance to Australian Government agencies

  26. ACSI33 Contents

  27. Gateway Certification Guide ·Developed by DSD ·         Provides independent assessment of an agency's gateway (firewall): ·         - configured and managed appropriately That - suitable safeguards have been effectively implemented

  28. Evaluated Products List • DSD maintains "Evaluated Products List" products/systems evaluated to a particular class • Australia formerly used ITSEC, now Common Criteria accept some O/S evaluations also note it’s a slow,costly process to have a system evaluated • examples: • B1 • SCO CMW+, BEST-X/B1, Sun Trusted Solaris • C2 • SCO UnixWare, BEST-X/C2, Sun Solaris, HP-UX, Novell Netware 4.11 Server< AIX • see EPL - Products at a Glance (Jan 2001)

  29. Evaluation Certifying Systems vs. Standards

  30. Evaluation Concepts and Relationships • evaluation -> assurance so that owners -> have confidence -> that countermeasures -> minimize risk -> to assets • Evaluation of "trusted computer systems" is the ultimate goal of implementing standards • Systems evaluated against evaluation standard

  31. Two Key Aspects Evaluated • Functionality functions in system which enforce security • Assurance effectiveness and correctness of system’s construction and implementation

  32. Trusted Computing Base • “Trusted Computing Base” concept is central to IA • Includes security-relevant hardware/software • Mediates all access between subjects & objects • is tamperproof • is validated

  33. Types of Secure Computing Systems • Categories of secure computing systems • Based on classification range of supported subjects and objects Dedicated (Single-Level) Systems System-High Compartmented Multi-Level Systems

  34. Dedicated (Single-Level) Systems • Handles subjects & objects with same classification • Relies on other security procedures (eg. physical) • Almost any system can operate at this level

  35. System-High • Only provides need-to-know protection between users • Entire system operates at highest classification level • All users must be cleared for that level of information • Have basic access controls to provide some protection of data

  36. Compartmented • Variation of System-High: can process 2 or more types of compartmented information • Not all users are cleared for all compartments, but all must be cleared to the highest level of information processed • Basic access controls provide some protection of data

  37. Multi-Level Systems • Validated for handling subjects & objects with different rights and levels of security simultaneously • Major features include: • user identification and authentication • resource access control and object labeling • audit trails of all security relevant events • external validation of system’s security

  38. Parties to an Evaluation • Sponsor of system (TOE) being developed • Developer of system (may be sponsor) • Evaluation facility performing evaluation • Certification body

  39. Security Evaluation Phases • Pre-evaluation defines security target & deliverables • Evaluation fulfills required evaluation tasks • Re-evaluation corrects faults or changes • Certification confirms & accepts evaluation

  40. Approaching Security Evaluation Tasks • Defining Security Requirements • use system specification • use standards/criteria • use experience • Risk Assessment • based on standards/criteria • based on experience • Theoretical Evaluation • of functionality required • to assurance level needed • Practical Testing • of code checking both normal/erroneous usage • Examination of the Source Code • for potential bugs • Penetration • attempting to hack system using knowledge of it

  41. Risk Assessment • Risk Assessment • determine what you are protecting • determine what you are protecting against • determine how much the protection is worth to you • goal: "provide some assurance that cost of security countermeasures is commensurate with risk“ • without it could spend too little or too much • Risk Assessment - Yellow Book • original risk assessment from "rainbow book" series • guiding principle is that recommended rating of a system depends on differential between user & info levels • Risk Index (defined in Yellow book) is given by: • Risk Index = Max Info Sensitivity - Min User Clearance

  42. Risk Rating Level Table**as specified in the Yellow Book

  43. Recommended SystemsThis table states what type of system should be used given the risk index computed.

  44. Risk Analysis - DSD Gateway Certification Guide • Yellow book approach is very narrow and prescriptive • In practice consider many factors • DSD includes risk analysis section in Gateway Certification Guide

  45. Process • Asset identification • Threat & threat likelihood estimation • Harm estimation • Risk assessment • Required risk & countermeasure rating

  46. Asset Identification • ID Asset: tangible thing, suitable level of service, staff, information • Who is responsible for each • Determined in conjunction with owners

  47. Threat & Threat Likelihood Estimation • Focus on threats to identified assets • May be multiple threats per asset • Focus on likely and/or disastrous threats • ID likely external threats from CERT reports, news, previous experience, legal requirements, etc. • Internal threats harder to evaluate: use organization experience • Assign likelihood (probability) per threat (negligible - extreme) • Document threat sources & likelihood estimation

  48. Harm Estimation • Estimate harm caused if threats realized • from insignificant – grave • If threat low/harm high, there is a risk • Harm estimation done with asset owner • Threat likelihood done by security specialist

  49. Risk Assessment • risk = threat likelihood x harm • Create tables of these values to grade riskbefore countermeasures applied

  50. Example:

More Related