1 / 54

Standaryzacja bezpieczeństwa

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

bowie
Download Presentation

Standaryzacja bezpieczeństwa

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. Standaryzacja bezpieczeństwa

  2. Plan wykładu • Potrzeba standaryzacji • Standaryzacja bezpieczeństwa • Historia • Pomarańczowa książka • ITSEC • Common Criteria • Podsumowanie

  3. Plan wykładu • Potrzeba standaryzacji • Standaryzacja bezpieczeństwa • Historia • Pomarańczowa książka • ITSEC • Common Criteria • Podsumowanie

  4. Potrzeba standaryzacji Wiele zagadnień technicznych wymaga standaryzacji, na przykład: • Bezpieczeństwo samochodów • Technologie sieci LAN • Kategorie okablowania

  5. Plan wykładu • Potrzeba standaryzacji • Standaryzacja bezpieczeństwa • Historia • Pomarańczowa książka • ITSEC • Common Criteria • Podsumowanie

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

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

  8. Plan wykładu • Potrzeba standaryzacji • Standaryzacja bezpieczeństwa • Historia • Pomarańczowa książka • ITSEC • Common Criteria • Podsumowanie

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

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

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

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

  13. Plan wykładu • Potrzeba standaryzacji • Standaryzacja bezpieczeństwa • Historia • Pomarańczowa książka • ITSEC • Common Criteria • Podsumowanie

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

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

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

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

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

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

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

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

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

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

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

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

  26. 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ę

  27. 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ę

  28. 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ść

  29. Plan wykładu • Potrzeba standaryzacji • Standaryzacja bezpieczeństwa • Historia • Pomarańczowa książka • ITSEC • Common Criteria • Podsumowanie

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

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

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

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

  34. Plan wykładu • Potrzeba standaryzacji • Standaryzacja bezpieczeństwa • Historia • Pomarańczowa książka • ITSEC • Common Criteria • Podsumowanie

  35. 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)

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

  37. 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)

  38. Wymogi bezpieczeństwa

  39. Wymogi bezpieczeństwa

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

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

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

  43. 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)

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

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

  46. 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ę

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

  48. Wymogi poziomów EAL

  49. Stosowanie Common Criteria

  50. Koszty i czas uzyskania EAL2, EAL3 oraz EAL4

More Related