Kritéria hodnocení důvěryhodného počítačového systému - Trusted Computer System Evaluation Criteria

Oranžová kniha

Kritéria hodnocení důvěryhodného počítačového systému (TCSEC) je Spojené státy Vláda oddělení obrany Norma (DoD), která stanoví základní požadavky pro hodnocení účinnosti zabezpečení počítače ovládací prvky zabudované do a počítačový systém. TCSEC byl použit k vyhodnocení, klasifikaci a výběru počítačových systémů uvažovaných pro zpracování, ukládání a vyhledávání citlivých nebo utajované informace.[1]

TCSEC, často označovaný jako Oranžová kniha, je středobodem DoD Rainbow Series publikace. Zpočátku vydáno v roce 1983 Národní centrum počítačové bezpečnosti (NCSC), rameno Národní bezpečnostní agentura, a poté aktualizován v roce 1985, TCSEC byl nakonec nahrazen Společná kritéria mezinárodní norma, původně publikovaná v roce 2005.[Citace je zapotřebí ]

Základní cíle a požadavky

Dne 24. října 2002 Oranžová kniha (aka DoDD 5200.28-STD) byl zrušen DoDD 8500.1, který byl později znovu vydán jako DoDI 8500.02, dne 14. března 2014.[2]

Politika

Zásady zabezpečení musí být explicitní, dobře definované a vynucené počítačovým systémem. Jsou specifikovány tři základní zásady zabezpečení:[3]

  • Povinná bezpečnostní politika - Vynucuje Řízení přístupu pravidla založená přímo na povolení jednotlivce, povolení informací a míře důvěrnosti požadovaných informací. Dalšími nepřímými faktory jsou fyzikální a environmentální. Tato zásada musí také přesně odrážet zákony, obecné zásady a další relevantní pokyny, z nichž jsou pravidla odvozena.
  • Označení - Systémy určené k prosazování povinné bezpečnostní politiky musí uchovávat a zachovávat integritu štítků řízení přístupu a zachovat štítky, pokud je objekt exportován.
  • Diskreční bezpečnostní politika - Prosazuje konzistentní soubor pravidel pro řízení a omezování přístupu na základě identifikovaných osob, u nichž bylo zjištěno, že je třeba tyto informace znát.

Odpovědnost

Je třeba vymáhat individuální odpovědnost bez ohledu na zásady. Musí existovat bezpečný prostředek, který zajistí přístup autorizovaného a kompetentního agenta, který poté může v přiměřené době a bez zbytečných obtíží vyhodnotit informace o odpovědnosti. Cíl odpovědnosti zahrnuje tři požadavky:[4]

  • Identifikace - Proces používaný k rozpoznání jednotlivého uživatele.
  • Ověření - Ověření oprávnění jednotlivého uživatele ke konkrétním kategoriím informací.
  • Auditování – Audit informace musí být selektivně uchovávány a chráněny, aby bylo možné dohledat akce ovlivňující zabezpečení k ověřenému jednotlivci.

Ujištění

Počítačový systém musí obsahovat hardwarové / softwarové mechanismy, které lze nezávisle vyhodnotit, aby poskytly dostatečnou záruku, že systém vynucuje výše uvedené požadavky. V širším smyslu musí záruka zahrnovat záruku, že důvěryhodná část systému funguje pouze podle plánu. K dosažení těchto cílů jsou zapotřebí dva typy záruk s příslušnými prvky:[5]

  • Zajišťovací mechanismy
  • Provozní zajištění: Systémová architektura, systémová integrita, analýza skrytých kanálů, důvěryhodná správa zařízení a důvěryhodná obnova
  • Zajištění životního cyklu: Testování zabezpečení, specifikace a ověření návrhu, správa konfigurace a distribuce důvěryhodného systému
  • Průběžné zajištění ochrany - Důvěryhodné mechanismy, které prosazují tyto základní požadavky, musí být neustále chráněny proti neoprávněné manipulaci nebo neoprávněným změnám.

Dokumentace

V rámci každé třídy se další sada dokumentace zaměřuje spíše na vývoj, nasazení a správu systému než na jeho schopnosti. Tato dokumentace obsahuje:[Citace je zapotřebí ]

  • Uživatelská příručka funkcí zabezpečení, příručka důvěryhodného zařízení, dokumentace k testování a dokumentace k návrhu

Divize a třídy

TCSEC definuje čtyři divize: D, C, B a A, kde divize A má nejvyšší zabezpečení. Každá divize představuje významný rozdíl v důvěře, kterou může jednotlivec nebo organizace vkládat do hodnoceného systému. Dále jsou divize C, B a A rozděleny do řady hierarchických subdivizí nazývaných třídy: C1, C2, B1, B2, B3 a A1.[6]

Každá divize a třída rozšiřuje nebo upravuje, jak je uvedeno, požadavky bezprostředně předchozí divize nebo třídy.[7]

D - Minimální ochrana

  • Vyhrazeno pro ty systémy, které byly hodnoceny, ale nesplňují požadavky na vyšší rozdělení.[8]

C - Diskreční ochrana

  • C1 - Diskreční ochrana zabezpečení[9]
    • Identifikace a autentizace
    • Oddělení uživatelů a údajů
    • Diskrétní řízení přístupu (DAC) schopný vynucovat omezení přístupu na individuálním základě
    • Požadovaná systémová dokumentace a uživatelské příručky
  • C2 - Řízená ochrana přístupu
    • Jemněji zrnitý DAC
    • Individuální odpovědnost prostřednictvím postupů přihlašování
    • Auditní stopy
    • Opětovné použití objektu
    • Izolace zdrojů
    • Příkladem systému je HP-UX

B - Povinná ochrana

  • B1 - Označená ochrana zabezpečení[10]
    • Neformální prohlášení o modelu bezpečnostní politiky
    • Štítky citlivosti dat
    • Povinná kontrola přístupu (MAC) přes vybrané předměty a objekty
    • Možnosti exportu štítků
    • Některé objevené nedostatky musí být odstraněny nebo jinak zmírněny
    • Specifikace návrhu a ověření
  • B2 - Strukturovaná ochrana
    • Model bezpečnostní politiky jasně definované a formálně zdokumentované
    • Vynucení DAC a MAC rozšířeno na všechny subjekty a objekty
    • Skryté kanály úložiště jsou analyzovány na výskyt a šířku pásma
    • Pečlivě strukturované do prvků kritických z hlediska ochrany a bez ochrany
    • Design a implementace umožňují komplexnější testování a kontrolu
    • Mechanismy ověřování jsou posíleny
    • Důvěryhodná správa zařízení je poskytována se segregací správce a provozovatele
    • Jsou zavedeny přísné ovládací prvky pro správu konfigurace
    • Role operátora a správce jsou odděleny.
    • Příkladem takového systému bylo Multics
  • B3 - Bezpečnostní domény
    • Splňuje referenční monitor požadavky
    • Strukturované tak, aby vylučovaly kód, který není nezbytný pro vynucování zásad zabezpečení
    • Významné systémové inženýrství směřující k minimalizaci složitosti
    • Je definována role správce zabezpečení
    • Auditovat události související s bezpečností
    • Automatický bezprostřední detekce narušení, oznámení a odpověď
    • Důvěryhodná cesta do TCB pro funkci autentizace uživatele
    • Důvěryhodné postupy obnovy systému
    • Skryté kanály časování jsou analyzovány na výskyt a šířku pásma
    • Příkladem takového systému je XTS-300, předchůdce XTS-400

A - Ověřená ochrana

  • A1 - ověřený design[11]
    • Funkčně shodné s B3
    • Formální design a techniky ověřování včetně formální specifikace nejvyšší úrovně
    • Formální řízení a distribuční postupy
    • Příklady systémů třídy A1 jsou systémy Honeywell SCOMP, Aesec GEMSOS a Boeing SNS Server. Dvě, které byly nevyhodnoceny, byla produkční platforma LOCK a zrušené bezpečnostní jádro DEC VAX.
  • Za A1
    • Systémová architektura ukazuje, že požadavky vlastní ochrany a úplnosti referenčních monitorů byly implementovány v Trusted Computing Base (TCB).
    • Testování zabezpečení automaticky generuje testovací případ z formální specifikace nejvyšší úrovně nebo formální specifikace nižší úrovně.
    • Formální specifikace a ověření je místo, kde se TCB ověřuje až na úroveň zdrojového kódu, pokud je to možné, pomocí formálních ověřovacích metod.
    • Trusted Design Environment je místo, kde je TCB navržen v důvěryhodném zařízení s pouze důvěryhodným (vymazaným) personálem.

Přizpůsobení tříd požadavkům na životní prostředí

Publikace s názvem „Army Regulation 380-19“ je příkladem průvodce určováním, která třída systému by měla být v dané situaci použita.[12]

Viz také

Reference

  1. ^ Lipner, Steve (2015). „Zrození a smrt oranžové knihy“. IEEE Annals of the History of Computing 37 č. 2 (2015): 19-31. Citováno z https://dx.doi.org/10.1109/MAHC.2015.27.
  2. ^ „INSTRUKCE ODBORU obrany - Kybernetická bezpečnost“ (PDF). www.dtic.mil. Archivovány od originál (PDF) dne 2014-04-29.
  3. ^ DOD 5200.28-STD „Kritéria hodnocení důvěryhodných počítačových systémů ministerstva obrany“, 1985, strana 3
  4. ^ DOD 5200.28-STD „Kritéria hodnocení důvěryhodných počítačových systémů ministerstva obrany“, 1985, strana 4
  5. ^ DOD 5200.28-STD „Kritéria hodnocení důvěryhodných počítačových systémů ministerstva obrany“, 1985, strana 4
  6. ^ DOD 5200.28-STD „Kritéria hodnocení důvěryhodných počítačových systémů Ministerstva obrany“, 1985
  7. ^ DOD 5200.28-STD "Kritéria hodnocení důvěryhodných počítačových systémů ministerstva obrany", 1985, strana 5
  8. ^ DOD 5200.28-STD „Kritéria hodnocení důvěryhodných počítačových systémů ministerstva obrany“, 1985, strana 9
  9. ^ DOD 5200.28-STD „Kritéria hodnocení důvěryhodných počítačových systémů ministerstva obrany“, 1985, strana 12
  10. ^ DOD 5200.28-STD „Kritéria hodnocení důvěryhodných počítačových systémů ministerstva obrany“, 1985, strana 20
  11. ^ DOD 5200.28-STD „Kritéria hodnocení důvěryhodných počítačových systémů ministerstva obrany“, 1985, strana 44
  12. ^ Nařízení armády 380-19. Citováno z https://fas.org/irp/doddir/army/r380_19.pdf.

externí odkazy