standaryzacja bezpieczeństwa
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
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