1 / 56

Trusted Computing Systems

Trusted Computing Systems. Definitions and Standards. Information System Security.

gabriel-bailey
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. 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]

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

  4. TCSEC Trusted Computer System Evaluation Criteria ("Orange Book") Aug 83, revised Dec 85 • First standard TC definition • How to ensure • How to evaluate • Couples functionality & assurance • Single computer system w/ terminal access

  5. Criteria within Broad Categories • Security Policy • Explicit, enforced security policy • System objects need access control labels • Accountability • Access controlled by rights of subjects vs. class of information • Audit trails must be kept • Assurance • System mechanisms must be independently evaluated • Sufficient assurance mechanisms enforce requirements

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

  7. Evaluation Criteria Classes

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

  9. ITSEC—Followed TCSEC • European Version

  10. ITSECInformation Technology Security Evaluation Criteria • European standard • Harmonized with TCSEC • Designed for single & multiple networked systems • Structured around - assurance and functionality • Details evaluation process • Independent evaluators work with developer/ sponsor • Checks test & analysis results supplied by sponsor • Performs additional tests to supplement

  11. 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

  12. Assurance • Assessment • Suitability and binding of functionality • Consequences of known/discovered vulnerabilities • Strength of security against direct attack • Correctness • Development process • Environment in building TOE • Operation of the TOE

  13. Functionality • Functionality classes in categories: • identification & authentication, • access control, • accountability, • audit, • object reuse, • accuracy, • reliability of service and • data exchange • Expressed as security objectives, functions & mechanisms • Natural language security policy • Formal model

  14. 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

  15. Common Criteria— • Today’s standard • ISO standard

  16. Common Criteria Overview • Defines IT security requirements for product/system • Basis for evaluating IT products/systems security properties • Resolves differences between evaluation standards of different countries. • Allows international recognition of evaluation results.

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

  18. History • Purpose: • Replaces the Rainbow Series of Security Documents • CC Project to align separate IT security criteria into one set • Jun. 1993, sponsored by US, Canada, and Europe • Jan. 1996, Version 1.0 completed • Apr. 1998, Version 2.0 produced • 1999 incorporated into ISO Standard 15408.   • Aug, 1999, Version 2.1 produced (incorporated changes from ISO process)

  19. Agencies involved National Institute of Standards and Technology (NIST), National Security Agency (NSA) US Communications Security Establishment Canada Communications-Electronic Security Group UK Bundesamt fur Sicherbeit in der Informationstechnik Germany Service Central de la Securite des Systemes d’Information France National Institute of Standards and Technology National Communications Security Agency Netherlands

  20. CC Content • General Model (Part 1) • General concepts / principles of IT security evaluation • General model of evaluation. • Constructs for expressing IT security objectives, selecting/defining IT security requirements, writing high-level specs • CC described in terms of target audiences • Security Functional Requirements (Part 2) • Set of standard functional components, families, and classes • Expresses TOE functional requirements • Security Assurance Requirements (Part 3) • Set of standard assurance components, families and classes. • Expresses TOE assurance requirements • Evaluation criteria for PPs and STs • Evaluation Assurance Levels (EALs) for rating assurance for TOEs

  21. Where CC Applies • GOTs (Government Off The Shelf) • Federal Contracts may require it • COTs (Commercial Off The Shelf) • Vendor wants to sell “secure” product • Consumers want products certified as “secure”.

  22. Evaluation Assurance Levels • Seven Levels • Levels can be augmented • Designated by “+” after EAL • Augmentation includes requirements from higher level • Features cannot be subtracted from an EAL

  23. Effective Assurance Levels

  24. 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

  25. 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

  26. Increasing levels of assurance requirements • Higher number--more stringent IA requirements • Example - • ACM_AUT.1 => Partial CM Automation • ACM_AUT.2 => Full CM Automation

  27. Protection Profiles • Security requirements for TOE category • Implementation-independent • Basis for TOE specs, products, documentation • Basis for TOE evaluations • Source • The Common Criteria • Outside source (e.g. NSA)

  28. Protection Profiles

  29. Summary • CC permits comparability between TOEs. • Common set of requirements for security functions • Common IA measures for security evaluation • CC addresses CIA, protecting against • C (confidentiality) unauthorized disclosure • I (integrity) unauthorized modification, or • A (availability) loss of use • CC applies to hardware, firmware or software.

  30. ACSI 33 • Australian Version

  31. Australian Communications-Electronic Security Instruction 33 (ACSI 33) • Developed by Defense Signals Directorate (DSD) • Guidance to Australian Gov’t agencies

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

  33. ACSI33 Contents

  34. 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

  35. Evaluated Products List • DSD maintains "Evaluated Products List" • Used ITSEC, now Common Criteria • 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

  36. Evaluation • Australian Version

  37. Evaluation Concerns • Functionality functions in system which enforce security • Assurance effectiveness and correctness of system’s construction and implementation

  38. Trusted Computing Base • “Trusted Computing Base” • Security-relevant hardware/software • Mediates all access between subjects & objects • is tamperproof • is validated

  39. Secure Computing SystemsCategories • Dedicated (Single-Level) Systems • System-High • Compartmented • Multi-Level Systems

  40. Dedicated (Single-Level) Systems • Subjects & objects w/ same classification • Relies on other security procedures • Almost any system at this level

  41. System-High • Need-to-know protection between users • System operates at highest level • All users cleared for that level • Basic access controls provide some data protection

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

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

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

  45. 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

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

  47. Asset Identification • ID Asset: tangible thing, suitable level of service, staff, information • ID Asset Owner

  48. Threat & Threat Likelihood Estimation • Threats to identified assets • Multiple threats per asset • Likely and/or disastrous threats • External threats • CERT reports • News • Previous experience • Legal requirements, etc. • Internal threats • use organization experience • Assign likelihood (probability) per threat • Document

More Related