540 likes | 733 Views
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
E N D
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ństwaInformation 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ędnieodporny 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. InformationTechnology 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)
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 dokumentacjiproduktu • 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