Standaryzacja bezpieczeństwa

Plan wykładu

• Potrzeba standaryzacji• Standaryzacja bezpieczeństwa• Historia• Pomarańczowa książka• ITSEC• Common Criteria• Podsumowanie

Plan wykładu

• Potrzeba standaryzacji• Standaryzacja bezpieczeństwa• Historia• Pomarańczowa książka• ITSEC• Common Criteria• Podsumowanie

Potrzeba standaryzacji

Wiele zagadnień technicznych wymaga standaryzacji, na przykład:

• Bezpieczeństwo samochodów

• Technologie sieci LAN

• Kategorie okablowania

Plan wykładu

• Potrzeba standaryzacji• Standaryzacja bezpieczeństwa• Historia• Pomarańczowa książka• ITSEC• Common Criteria• Podsumowanie

Po co standaryzować bezpieczeństwo?

• Możliwość oceny poziomu bezpieczeństwa oprogramowania, sprzętu

• Możliwość porównania produktów różnych producentów• Niektóre sektory mają szczególne wymagania dotyczące

bezpieczeństwa (wojsko, służby specjalne, opieka medyczna, energetyka jądrowa, itd.)

• Narzucenia wymogów już na etapie projektowania nowych technologii, oprogramowania, sprzętu

• Możliwość analizy systemów informatycznych i teleinformatycznych pod kątem bezpieczeństwa

Jak standaryzować bezpieczeństwo – różne problemy?• Metody pomiaru poziomu bezpieczeństwa, jak wyrażać

ten poziom, jak porównywać bezpieczeństwo dwóch produktów

• Możliwe zagrożenia i naruszenia bezpieczeństwa – część z nich nie jest jeszcze znana, ale system ma być przed nimi zabezpieczony

• Ujednolicenie nomenklatury i pojęć związanych z bezpieczeństwem

• „Bezpieczeństwo to proces, nie produkt” - Bruce Schneier

Plan wykładu

• Potrzeba standaryzacji• Standaryzacja bezpieczeństwa• Historia• Pomarańczowa książka• ITSEC• Common Criteria• Podsumowanie

Historia

• 1976 – model polityki bezpieczeństwa opracowany przez Bell i La Padul

• 1983 – Departament Obrony Stanów Zjednoczonych stworzył dokument Trusted Computer System Evaluation Criteria (TCSEC), potocznie nazywany pomarańczową książką (ang. orange book)

• 1988 – powołanie w ISO (ang. International Organization for Standardization) grupy zajmującej się bezpieczeństwem JTC 1/SC 27: IT Security techniques

Historia

• 1990 – Francja, Niemcy, Holandia i Wielka Brytania wydają wspólny dokument dotyczący bezpieczeństwa Information Technology Security Evaluation Criteria (ITSEC)

• 1991 –Komisja Europejska przyjmuje dokument ITSEC ver. 1.2

• 1993 – w Kanadzie zostaje opublikowany dokument CTCPEC (Canadian Trusted Computer Product Evaluation Criteria), który powstał z połączenia amerykańskiego TCSEC (pomarańczowa księga) oraz europejskiego ITSEC

Historia

• 1993 – w USA zostaje przyjęty dokument Federal Criteria for Information Technology Security (FC) ver 1.0

• 1993 – rozpoczęto prace na dokumentem nazwanym Common Criteria (CC) łączącym cechy dotychczas opracowanych standardów TCSEC, ITSEC, CTCPEC, FC (http://www.commoncriteriaportal.org)

• 1996 – publikacja dokument CC ver. 1.0• 1998 – publikacja dokumentu CC ver. 2.0• 1998 – podpisana umowa przez Kanadę, Francję,

Niemcy USA, o wzajemnym uznawaniu certyfikacji według CC

Historia

• 1999 – ISO przyjmuje CC 2.1 jako standard ISO/IEC 15408

• 2000 – ISO publikuje jako ISO/IEC 17799:2000 brytyjski standard BS 7799 Information technology - Security techniques - Code of practice for information security management

• 2005 – ISO publikuje CC 2.3 jako standard ISO/IEC 15408 http://standards.iso.org/ittf/PubliclyAvailableStandards/

• 2005 – ISO publikuje standardy serii 27000 dotyczące bezpieczeństwa http://www.27000.org/

• 2007 – zostaje opublikowany dokument CC ver. 3.1

Plan wykładu

• Potrzeba standaryzacji• Standaryzacja bezpieczeństwa• Historia• Pomarańczowa książka• ITSEC• Common Criteria• Podsumowanie

TCSEC - Pomarańczowa książka

• W 1983 roku Departament Obrony Stanów Zjednoczonych stworzył dokument nazwany oficjalnie Trusted Computer System Evaluation Criteria (TCSEC), potocznie zwany pomarańczową książką (ang. orange book)

• W 1985 roku dokument został uaktualniony

Model polityki bezpieczeństwa

• W standardzie The Orange Book wykorzystywany jest formalny model polityki bezpieczeństwa podany przez Bell i La Padula w 1976 r. (http://csrc.nist.gov/publications/history/bell76.pdf)

• Model ten, z wykorzystaniem matematyki (teorii zbiorów), definiuje pojęcia stanu bezpieczeństwa i elementarnych trybów dostępu do obiektu oraz określa zasady przyznawania podmiotom określonych trybów dostępu do obiektów

Model polityki bezpieczeństwa

• Aby rozszerzyć kryteria oceny bezpieczeństwa również na systemy bez jądra ochrony wprowadzono pojęcie TCB (ang. Trusted Computing Base)

• TCB jest sercem bezpiecznego systemu komputerowego zawierającym wszystkie elementy odpowiedzialne za realizację polityki bezpieczeństwa i wspieranie izolacji obiektów systemu objętych ochroną

• TCB zawiera sprzęt i oprogramowanie krytyczne dla ochrony systemu i musi być zaprojektowane i zaimplementowane tak, aby zapewniać założony poziom ochrony

• TCB powinna mieć na tyle prostą strukturę, aby możliwe było wykonanie testów i analiz, dających odpowiedź na pytanie, czy system jest godny zaufania

Wymogi bezpieczeństwa

• Polityka bezpieczeństwa. Musi istnieć jasna i dobrze zdefiniowana polityka bezpieczeństwa systemu. Ponadto muszą istnieć mechanizmy wymuszające jej realizację

• Opis obiektów. Dla każdego obiektu systemu muszą być określone następujące informacje: poziom ochrony, do którego obiekt należy (tzn. obiekty muszą być w systemie poklasyfikowane wg kryterium bezpieczeństwa) oraz prawa dostępu podmiotów, które mogą starać się o dostęp do obiektu

• Identyfikacja. Podmioty muszą posiadać nazwę, aby możliwa była ich identyfikacja

Wymogi bezpieczeństwa

• Audyt. Informacje pochodzące z audytu muszą być gromadzone, rejestrowane i przechowywane w bezpieczny sposób w celu umożliwienia wykonania dokładnej analizy ewentualnych zagrożeń

• Pewność. System komputerowy musi zawierać sprzętowe i/lub programowe mechanizmy zabezpieczeń, które można w sposób niezależny ocenić pod względem spełniania wymogów

• Ciągła ochrona. Mechanizmy ochrony muszą być stale chronione przed nieautoryzowanym dostępem. W przeciwnym wypadku niemożliwe jest utrzymanie odpowiedniego poziomu ochrony

Ocena bezpieczeństwa komputerowego

• Ocena poziomu bezpieczeństwa systemu na bazie pomarańczowej księgi polega na zakwalifikowaniu go do którejś ze zdefiniowanych klas

• W standardzie określono siedem poziomów bezpieczeństwa

• Różne poziomy określają różne sposoby zabezpieczania sprzętu, oprogramowania i danych

• Wyższe poziomy bezpieczeństwa zawierają wszystkie cechy poziomów niższych

Klasa D

• Klasa D (ang. Minimal protection) to najniższy poziom bezpieczeństwa. Poziom nie wymaga certyfikacji, bowiem oznacza brak jakichkolwiek zabezpieczeń. Do tej grupy należy system DOS

Klasa C1

• Klasa C1 stosuje ochroną dyskrecjonalną (ang. Discretionary security protection), polegającą na separacji użytkowników i danych za pomocą praw dostępu

• Uzyskany poziom bezpieczeństwa pozwala użytkownikom chronić dane, uniemożliwiając innym użytkownikom ich odczyt, modyfikowanie lub usuwanie

Klasa C1

Systemy C1 muszą spełniać następujące wymagania: • System musi umożliwiać definiowanie dostępu do

obiektów poprzez indywidualne i grupowe prawa dostępu

• Dostęp do systemu ma być kontrolowany poprzez uwierzytelnianie

• Muszą być dostępne narzędzia umożliwiające sprawdzenie integralności systemu

• Mechanizmy zabezpieczające muszą być przetestowane i działać zgodnie z instrukcją

• Wymagana jest dokumentacja i sporządzenia testów systemu

Klasa C2

• Systemy klasy C2 (ang. Controlled access protection) mają lepszy poziom ochrony niż dla klasy C1 dzięki wprowadzanie dodatkowych procedur.

• Wiele sieciowych systemów operacyjnych posiada klasę C2, np. Novell NetWare 4.x

• Jest to poziom wystarczający dla zastosowań biznesowych, administracyjnych

• Jednak dla poważniejszych zastosowań (wojsko, służby specjalne, bezpieczeństwo energetyczne) wymagane są systemy klas B

Klasa C2

Systemy klasy C2 muszą spełniać wymagania postawione dla klasy C1 oraz następujące warunki dodatkowe:

• Istnieje gwarancja, że obiekty systemu, używane wielokrotnie, nie zostawiają śladów działalności poprzedniego użytkownika (np. w pamięci operacyjnej systemu)

• Możliwe jest nasłuchiwanie systemu i śledzenia wydarzeń zachodzących w systemie (mechanizm audytu)

Klasa B1

• Systemy klasy B1 (ang. Labeled security protection) posiadają wszystkie właściwości systemów klasy C2

• Klasa B1 zapewnia kontrolę dostępu do obiektów systemu opartą na zabezpieczeniu obowiązkowym (ang. Mandatory protection)

• Wprowadzony jest etykietowanie podmiotów i obiektów (opisywania ich właściwości w systemie bezpieczeństwa)

• Klasa B1 ta obsługuje bezpieczeństwo na kilku poziomach takich jak na przykład "tajne" i "ściśle tajne"

Klasa B2

• W klasie B2 (ang. Structured protection) TCB oparta jest na jasno zdefiniowanej i udokumentowanej polityce bezpieczeństwa

• Ponadto TCB musi być podzielona na część krytyczną pod względem ochrony (ang. protection-critical) i resztę

• TCB ma posiadać dobrze zdefiniowany interfejs i być łatwy w testowaniu

• Wzmocnione muszą być mechanizmy uwierzytelniania oraz narzędzia administrowania

• System musi być względnie odporny na penetrację

Klasa B3

• W klasie B3 (ang. Security domains) zminimalizowana jest złożoność TCB w celu umożliwienia wykonania dokładniejszych analiz

• System posiada silne wsparcie dla administracji bezpieczeństwem

• Mechanizm audytu rozszerzono do reagowania na sygnały związane z bezpieczeństwem

• Wymagane jest opracowanie procedur odtwarzania stanu systemu

• System jest wysoce odporny na penetrację

Klasa A1

• Grupa A (ang. Verified design) obejmuje systemy posiadające zweryfikowane zabezpieczenia

• Jest to najwyższy poziom bezpieczeństwa• Klasa A1 jest równoważna klasie B3, zapewniając przy

tym większą pewność systemu• Cała konfiguracja sprzętowo-programowa wymaga

matematycznej weryfikacji• Sprzęt i oprogramowanie musi podlegać specjalnej

ochronie w trakcie transportu dla jego nienaruszalność

Plan wykładu

• Potrzeba standaryzacji• Standaryzacja bezpieczeństwa• Historia• Pomarańczowa książka• ITSEC• Common Criteria• Podsumowanie

ITSEC

• W 1991 roku dzięki staraniom Komisji Europejskiej został opublikowany dokument ITSEC (ang. Information Technology Security Evaluation Crirteria)

• W tym dokumencie systemy komputerowe podzielone są na 10 klas funkcjonalności ze względu na funkcjonalność i pewność

• ITSEC definiuje 7 poziomów pewności od E0 (najmniej pewny) do E6 (najbardziej pewny)

• Każdy wyższy poziom pewności zawiera wymagania poziomu poprzedniego oraz wymagania dodatkowe

Funkcjonalności bezpieczeństwa

• Identification and Authentication – kontrola dostępu do systemu (identyfikacja i uwierzytelnianie)

• Access Control – kontrola dostępu do obiektów• Accountability – odpowiedzialność• Audit – nasłuch• Object Reuse – ponowne wykorzystanie obiektów• Accuracy – wierność (integralność danych, detekcja i

prewencja)• Reliability of Service – niezawodność pracy• Data Exchange – wymiana danych

Klasy funkcjonalności ITSEC

• Klasy F-C1, F-C2, F-B1, F-B2, F-B3– odpowiadają odpowiednio klasom C1, C2, B1, B2, B3 pomarańczowe księgi

• Klasa F-IN – zwiększone wymagania dotyczące integralności

• Klasa F-AV – zwiększone wymagania dotyczące niezawodności

• Klasa F-DI – zwiększone wymagania dotyczące integralności danych w sieciach telekomunikacyjnych

• Klasa F-DC – zwiększone wymagania dotyczące tajności danych

• Klasa F-DX – zwiększone wymagania dotyczące tajności danych i integralności danych

Poziomy pewności ITSEC

• E0 – brak odpowiedniej pewności• E1 – istnienie nieformalnego opisu architektury

bezpieczeństwa• E2 – nieformalny opis koncepcji szczegółowej, dowody

testów, kontrola konfiguracji i proces nadzoru dystrybucji• E3 – dostarczenie szczegółowej koncepcji i kodu

źródłowego• E4 – istnienie formalnego modelu polityki

bezpieczeństwa• E5 – ścisła relacja między opisem formalnym koncepcji

szczegółowej i kodem źródłowym• E6 – istnienie formalnego opisu architektury

bezpieczeństwa kompatybilnej z modelem formalnym polityki bezpieczeństwa

Plan wykładu

• Potrzeba standaryzacji• Standaryzacja bezpieczeństwa• Historia• Pomarańczowa książka• ITSEC• Common Criteria• Podsumowanie

Common Criteria

• Prace nad dokumentem Common Criteria (CC) integrującym wcześniejsze standardy z różnych krajów rozpoczęto w 1993 r

• Obecnie ten dokument w wersji 2.3 jest przyjęte przez ISO jako norma ISO/IEC 15408

• Wiele krajów podpisało umowę o wzajemnym uznawaniu certyfikacji według standardów CC

• Standard definiuje poziomy bezpieczeństwa EAL (ang. Evaluation Assurance Level)

Common Criteria

• CC umożliwia ujednolicone sposób oceny bezpieczeństwa systemów informatycznych

• CC stosowane są dla oceny oprogramowania i sprzętu• CC to zbiór informacji na temat schematów konstrukcji

wymagań związanych z bezpieczeństwem• Popularyzacja CC umożliwi konsumentom porównanie

oferowanych produktów pod względem bezpieczeństwa, a producentom ułatwi opracowywanie produktów spełniających wymagania związane z bezpieczeństwem

Wymogi bezpieczeństwa

W CC zdefiniowano 8 klas wymogów bezpieczeństwa:• Configuration Management (zarządzanie konfiguracją)• Guidance Documents (dokumentacja)• Vulnerability Assessment (ocena podatności)• Delivery and Operation (dostarczenie i użytkowanie)• Life Cycle Support (zarządzanie cyklem życia)• Assurance Maintenance (zapewnienie bezpieczeństwa)• Development (rozwój)• Tests (testy)

Wymogi bezpieczeństwa

Wymogi bezpieczeństwa

Poziomy bezpieczeństwa

• Standard CC definiuje 7 poziomów bezpieczeństwa EAL (ang. Evaluation Assurance Level) od EAL1 (najsłabszy) do EAL7 (najbezpieczniejszy)

• Poszczególne poziomy mają przypisane odpowiednie wartości wymogów bezpieczeństwa odzwierciedlające szczegółowe warunki, które muszą być spełnione na danym poziomie EAL

EAL1 – Functionally tested

• Poziom EAL1 jest stosowany gdy wymagany jest pewien poziom bezpieczeństwa, ale zagrożenia dla TOE (ang. Target of Evaluation) są stosunkowo małe

• Testy odbywają się bez asysty producenta• Niezależne testowanie według specyfikacji produktu• Analiza dokumentacji produktu• Poziom EAL1 daje gwarancje, że TOE zapewnia

bezpieczeństwo na poziomie wymienionym w dokumentacji

EAL2: Structurally tested

• Poziom EAL2 wymaga dodatkowej współpracy z producentem związanej z dostarczeniem informacji o projektowaniu i testowaniu TOE, ale nie powinno to wymagać od producenta więcej wysiłku niż ma to miejsce w porównywalnej działalności komercyjnej (znacznie zwiększonych kosztów i nakładów czasu)

• Producent powinien przetestować TOE pod kątem bezpieczeństwa i dokonać analizy wyników

• Weryfikacja wyników testów przeprowadzonych przez producenta

• Wymagane procedury bezpiecznej dostawy TOE• Poziom EAL2 daje słaby i średni poziom bezpieczeństwa

EAL3: Methodically tested and checked

• Poziom EAL3 umożliwia sumiennemu producentowi zyskać jak największe bezpieczeństwo na podstawie odpowiedniej procedury rozwoju TOE bez potrzeby poważniejszych zmian w procedurze rozwoju

• EAL3 jest stosowany kiedy producent lub użytkownik wymaga średniego poziomu bezpieczeństwa dokładnie zbadanego i potwierdzonego w niezależnym źródle

• Stosowany jest testowanie cech związanych z bezpieczeństwem za pomocą metody „szarego pudełka” (ang. grey box)

EAL4: Methodically designed, tested and reviewed

• EAL4 zapewnia maksymalne bezpieczeństwo wynikające z dokładnego stosowania standardowych zasad bezpieczeństwa nie wymagających specjalistycznej wiedzy

• EAL4 to najwyższy poziomem, do którego ekonomicznie jest uzasadniona modernizacja istniejącego produktu

• Wprowadzenie EAL4 może oznaczać dodatkowe koszty• Wymagana dokładna analiza bezpieczeństwa

obejmująca analizę etapów projektowania, implementacji, konfiguracji TOE

• Niezbędne przeprowadzenie testów bezpieczeństwa i potwierdzenie wybranych testów wykonanych przez producenta

EAL5: Semi-formally designed and tested

• EAL5 zapewnia maksymalne bezpieczeństwo wynikające z dokładnego stosowania standardowych zasad bezpieczeństwa wraz ze specjalistyczną wiedzę na średnim poziomie

• TOE zazwyczaj jest odpowiednio projektowane, aby osiągnąć ten poziom

• Poziom EAL5 jest stosowany kiedy wymagany jest wysoki poziom niezależnie potwierdzonego bezpieczeństwa jednocześnie bez wysokich kosztów związanych ze stosowaniem wyspecjalizowanych technik bezpieczeństwa

• Wymagana analiza poszczególnych elementów TOE na podstawie modeli semiformalnych

• Niezbędna analiza ukrytych elementów TOE

EAL6: Semi-formally verified design and tested

• EAL6 zapewnia wysokie bezpieczeństwo wynikające ze stosowania zaawansowanych technik bezpieczeństwa

• Produkt na poziomie EAL6 może być stosowany do ochrony wartościowych zasobów podlegającym znaczącemu ryzyku, dla których poniesienie znacznych dodatkowych kosztów jest uzasadnione

• Wymagane dodatkowe analizy elementów TOE wspomagane budową modeli semiformalnych i formalnych

• Analiza warstwowa bezpieczeństwa• Niezbędne dodatkowe funkcjonalności TOE

wspomagające konfigurację

EAL7: Formally verified design and tested

• Poziom EAL7 jest stosowany dla TOE wymagającego bezpieczeństwa przy ekstremalnie wysokich zagrożeniach

• EAL7 jest obecnie ograniczony do TOE przeznaczonym dla zadań bezpieczeństwa i podatnych na formalną analizę

• Analiza poszczególnych zagadnień bezpieczeństwa na podstawie formalnych modeli

• Dokładne testowanie za pomocą metody „białego pudełka” (ang. white box)

• Niezbędna najwyższa odporność na ataki

Wymogi poziomów EAL

Stosowanie Common Criteria

Koszty i czas uzyskania EAL2, EAL3 oraz EAL4

Przykłady poziomu EAL dla różnych produktów

• Microsoft Windows 2003 and Microsoft Windows XP ocena: EAL4+

• Windows 2000 (with SP3) ocena: EAL4+• Database Engine of Microsoft SQL Server 2005

Enterprise Edition (English) SP1, Version/Build 9.00.2047.00 ocena: EAL1

• Hewlett-Packard HP-UX 11i ocena: EAL4+• Oracle Database 10g Enterprise Edition ocena: EAL4+• Solaris™ 10 Release 11/06 ocena: EAL4+

Common Criteria - dyskusja

• Proces oceny produktu według CC jest bardzo kosztowny i nie zawsze skutkuje podniesieniem bezpieczeństwa ocenianego produktu

• Na niższych poziomach EAL ocena polega głównie na analizie dokumentacji, a nie technicznych aspektów produktu

• Proces oceny może być na tyle czasochłonny, że po zakończeniu produkt jest mało atrakcyjny lub uległ znacznej modyfikacji wymuszającej ponowną ocenę

• Przemysł ma niewielki wpływ na określanie sposobu oceny bezpieczeństwa

Plan wykładu

• Potrzeba standaryzacji• Standaryzacja bezpieczeństwa• Historia• Pomarańczowa książka• ITSEC• Common Criteria• Podsumowanie

Podsumowanie

• Standaryzacja bezpieczeństwa systemów informatycznych i teleinformatycznych wynika z rozwoju, popularności i znaczenia tych systemów

• Wymogi dotyczące bezpieczeństwa stanowią obecnie podstawowy cel projektantów i producentów

• Możliwość oceny bezpieczeństwa systemów informatycznych i teleinformatycznych według ustalonych standardów ułatwia życie producentom i użytkownikom

• Rosnące zagrożenia i wymagania dotyczące bezpieczeństwa powoduje coraz większy stopień skomplikowania standardów oceny bezpieczeństwa