Co powinno być chronione?
" Stanowiska komputerowe
" Infrastruktura sieciowa
Co powinno być chronione?
" System operacyjny
" Usługi narzędziowe
" Aplikacje u\
ytkowe
Poziom bezpieczeństwa Poziom bezpieczeństwa
" Nie istnieje system absolutnie bezpieczny:
- System jest dostatecznie bezpieczny, jeśli agresor
- nie mo\
emy przewidzieć wszystkich mo\
liwych
rezygnuje z ataku, gdy\
:
zagro\
eń;
" sforsowanie zabezpieczeń jest zbyt
- szybki rozwój technologii implikuje powstawanie
czasochłonne;
coraz to nowych zagro\
eń;
- czas reakcji na nowe zagro\
enia nie jest zerowy; " atak jest nieopłacalny, poniesione nakłady
- ludzka niedoskonałość, w szczególności omylność
przekraczają ewentualne zyski.
projektantów; programistów, u\
ytkowników
- Nie mo\
na udowodnić, ze system jest bezpieczny.
systemów informatycznych, skutkuje błędami w
- Mo\
na tylko wykazać, pokazując metodę ataku,
oprogramowaniu oraz niewłaściwym lub
słabości w bezpieczeństwie.
niefrasobliwym jego wykorzystaniem.
Strategie ataku
Strategie ataku
" Agresor na ogół nie pokonuje zabezpieczeń,
Agresor mo\
e wykorzystać:
tylko je obchodzi.
" chwilową nieobecność u\
ytkownika;
" Skuteczny atak na aktywny mechanizm
" boczne wejście do systemu, stworzone w
zabezpieczeń jest raczej czasochłonny i
celu  ułatwienia jego pielęgnacji;
stosowany tylko w ostateczności.
" publicznie dostępne informacje o
" Zwykle mniej kosztowne i szybsze jest
u\
ywanym oprogramowaniu;
znalezienie luki w oprogramowaniu i wtargniecie
" podstęp, udawanie pracownika serwisu,
do systemu  z boku .
dostawcy;
" Większość ataków przeprowadzana jest  od
" wymuszenie, szanta\
;
środka organizacji , czyli przez zaufanych
" przeszukanie śmieci, wyrzucanej makulatury
u\
ytkowników, którzy łatwiej mogą znalez
ć i
lub nośników danych.
wykorzystać luki w bezpieczeństwie.
1
Linie obrony Linie obrony
" Brak symptomów ataku nie oznacza, ze system
" Mo\
liwe jest obejście ka\
dego mechanizmu
zabezpieczeń. nie został zaatakowany.
" Zabezpieczenia powinny być konstruowane
wielopoziomowo:
" Zaobserwowanie ataku nie jest trywialne nawet w
- złamanie jednej linii obrony nie powinno umo\
liwiać
systemie poprawnie monitorowanym.
wtargnięcia do systemu;
- np. ochrona sieci ściana ogniowa (ang. firewall) nie
" Symptomy ataku zwykle występują dopiero po
zwalnia od tworzenia aplikacji odpornych na ataki z
jego zakończeniu, kiedy to mo\
e być zbyt póz
no
sieci zewnętrznej.
by przeprowadzać akcje ratunkowa, kiedy
" Przejrzysta i modularna konstrukcja systemu ułatwia
ucierpiały ju\
newralgiczne składniki systemu,
ochronę.
poufne dane lub reputacja firmy.
" Wzrost poziomu bezpieczeństwa odbywa się kosztem
wygody u\
ytkowników.
Przykłady chronionych zasobów
Strategia bezpieczeństwa
" Sprzęt komputerowy
" O bezpieczeństwie nale\
y myśleć juz od początku
etapu projektowania systemu informatycznego lub " Infrastruktura sieciowa
aplikacji.
" Wydruki
" Błędy lub zaniedbania popełnione na etapie " Strategiczne dane
projektowania są trudne do naprawienia w
" Kopie zapasowe
póz
niejszych fazach projektu.
" Wersje instalacyjne oprogramowania
" Nale\
y udzielić odpowiedzi na pytania:
" Dane osobowe
 Co chronić (określenie zasobów)? " Dane audytu
" Zdrowie pracowników
 Przed czym chronić (identyfikacja zagro\
eń)?
" Prywatność pracowników
 Ile czasu, wysiłku i pieniędzy mo\
na poświęcić na
" Zdolności produkcyjne
ochronę (oszacowanie ryzyka, analiza kosztów i
zysku)? " Wizerunek publiczny i reputacja
Przykładowe zagro\
enia
Normy i zalecenia zarządzania
bezpieczeństwem
" Włamywacze komputerowi
" Norma ISO/IEC Technical Report 13335 (ratyfikowana w
" Infekcje wirusami
naszym kraju jako PN-I-13335) obejmuje:
" Błędy w programach
" TR 13335-1  terminologia i modele;
" TR 13335-2  metodyka planowania i prowadzenia analizy
" Nieuczciwi pracownicy lub personel zewnętrzny
ryzyka, specyfikacja wymagań stanowisk pracy związanych
" Kradzie\
nośników danych, komputerów (równie\
w podró\
y z bezpieczeństwem systemów informatycznych;
" TR 13335-3  techniki zarządzania bezpieczeństwem:
słu\
bowej)
- zarządzanie ochroną informacji,
" Utrata mo\
liwości korzystania z łączy telekomunikacyjnych
- zarządzanie konfiguracja systemów IT,
" Bankructwo firmy serwisowej lub producenta sprzętu
- zarządzanie zmianami;
" Choroba administratora lub kierownika projektu (jednoczesna
" TR 13335-4  metodyka doboru zabezpieczeń;
" choroba wielu osób) " WD 13335-5  zabezpieczanie połączeń z sieciami
zewnętrznymi.
" Powódz
, po\
ar
2
Elementarna ochrona stacji roboczej
Podstawowe środki ostro\
ności
" Uniemo\
liwienie startowania systemu z nośników
wymiennych
" W celu zminimalizowania podatności na
" Ograniczenie wykorzystania przestrzeni lokalnych
dysków twardych
typowe ataki nale\
y stosować
" Ograniczenie stosowania nośników wymiennych
elementarne zasady  higieny osobistej .
(stacji dyskietek, nagrywarek)
" Rejestracja prób dostępu do systemu i ich
" Dotyczą one wszystkich komponentów limitowanie (kontrola, kto i kiedy korzystał z
systemu)
systemu informatycznego, stanowisk
" Bezpieczne kasowanie poufnych danych
komputerowych, infrastruktury sieciowej,
" Uniemo\
liwienie usunięcia lub wyłączenia
usług aplikacyjnych.
zabezpieczeń, np. antywirusowych
" Konsekwentna polityka haseł u\
ytkowników
Elementarna ochrona sieci lokalnej Elementarna ochrona usług sieciowych
" Usuniecie z systemu wszystkich usług
" Dobór medium i topologii gwiazdy
zbędnych, najlepiej poprzez całkowite
(okablowanie strukturalne)
odinstalowanie, a co najmniej  dezaktywacje
" Fizyczna ochrona pomieszczeń z węzłami
" Zastąpienie usług niezbędnych odpowiednikami
sieci i serwerami
o podwy\
szonym bezpieczeństwie, jeśli to
" Zdefiniowanie listy stanowisk, z których dany
mo\
liwe i takie odpowiedniki są dostępne
u\
ytkownik mo\
e uzyskać dostęp do
" Kontrola dostępu do pozostałych usług, np.
systemu (adresy MAC lub IP) poprzez ścianę ogniowa (ang. firewall)
" Usuwanie nieu\
ywanych kont u\
ytkowników
Zasada naturalnego styku z
Zło\
oność problemu stosowania
u\
ytkownikiem
zabezpieczeń
" Broniący stoi na gorszej pozycji ni\
agresor.
" Zabezpieczenie nie mo\
ne być postrzegane
" Asymetria: przez u\
ytkowników jako nienaturalny element
systemu, stanowiący utrudnienie w ich pracy.
- aby skutecznie zabezpieczyć system nale\
y
usunąć wszystkie słabości;
" Jeśli wprowadzony zostanie nawet najbardziej
- aby skutecznie zaatakować  wystarczy znalez
ć
wyrafinowany mechanizm bezpieczeństwa,
jedną.
którego jednak stosowanie będzie wymagało od
" Kontekst otoczenia systemu  bezpieczeństwo
u\
ytkowników dodatkowo zbyt obcią\
ających ich
powinno być rozwa\
ane w kontekście nie
(czasochłonnych) operacji, to wkrótce wypracują
pojedynczego systemu informatycznego, ale całego
oni sposób jego permanentnego obejścia.
otoczenia, w którym on się znajduje.
" Zarządzanie i pielęgnacja  zabezpieczenie
W efekcie mechanizm stanie się bezu\
yteczny
systemu nie jest pojedyncza operacja, ale ciągłym
procesem.
3
Zasada domyślnej odmowy dostępu
Zasada minimalnego przywileju
" Jeśli na podstawie zdefiniowanych reguł
" U\
ytkownikom nale\
y udzielać uprawnień
postępowania mechanizmy obrony nie potrafią
w sposób zgodny z polityką
jawnie rozstrzygnąć, jaka decyzje podjąć wobec
bezpieczeństwa  tylko i wyłącznie takich,
analizowanych operacji (np. nadchodzacego
które są niezbędne do zrealizowania ich
pakietu protokołu komunikacyjnego), to decyzja
pracy.
ostateczna powinna być odmowa dostępu
(odrzucenie pakietu).
" Zmianie zakresu obowiązków u\
ytkownika
powinna towarzyszyć zmiana zakresu " Wiele urządzeń i protokołów jest jednak domyślnie
konfigurowanych inaczej, czy to w celu wygody
uprawnień.
u\
ytkownika, czy z zało\
enia wynikającego z ich
funkcji (por. trasowanie (ang. routing)).
Autoryzacja
Filozofie przydziału uprawnień
" Zasób (obiekt)  jednostka, do której dostęp
podlega kontroli, np. program, plik, relacja bazy
" Wszystko jest dozwolone.
danych, cała baza danych, ale te\
obiekty o
" Wszystko, co nie jest (jawnie) zabronione,
wysokiej  granulacji , np. poszczególne krotki
jest dozwolone.
bazy danych.
" Podmiot  byt uzyskujący dostęp do zasobu, np.
" Wszystko, co nie jest (jawnie) dozwolone,
u\
ytkownik, grupa u\
ytkowników, terminal,
jest zabronione.
komputer, aplikacja, proces.
" Wszystko jest zabronione.
" Prawa dostępu  dopuszczalne sposoby
wykorzystania zasobu przez podmiot.
Uznaniowa kontrola dostępu
Ścisła kontrola dostępu
" Właściciel zasobu mo\
e decydować o jego
atrybutach i uprawnieniach innych u\
ytkowników
" Precyzyjne reguły dostępu automatycznie
względem tego zasobu. Oferuje u\
ytkownikom du\
ą
wymuszają uprawnienia.
elastyczność i swobodę współdzielenia zasobów.
" Powszechnym zagro\
eniem jest niefrasobliwość " Nawet właściciel zasobu nie mo\
e
przydziału uprawnień (np. wynikająca z
dysponować prawami dostępu.
nieświadomości lub zaniedbań) i niewystarczająca
ochrona zasobów.
" Pozwala łatwiej zrealizować (narzucić) silną
" Najczęściej uprawnienia obejmują operacje odczytu i
politykę bezpieczeństwa i konsekwentnie
zapisu danych oraz uruchamiania programu, np.
stosować ja do całości zasobów.
stosowane w systemach uniksowych atrybuty rwx.
4
Ścisła kontrola dostępu, cd. Ścisła kontrola dostępu, cd.
" Poziomy zaufania
" Na zbiorze etykiet ochrony danych określona jest
ogólnie dostępne < do u\
ytku wewnętrznego <
relacja wra\
liwości, np.:
< tylko dyrekcja < tylko zarząd
(poufne, {OSOBOWE}) < (tajne, {OSOBOWE})
albo
(tajne, {SZYFROWANE}) <
jawne < poufne < tajne < ściśle tajne (ściśle tajne, {SZYFROWANE, MILITARNE})
" Kategorie informacji " Jest to relacja częściowego porządku. Przykładowo
mo\
e nie być określona relacja pomiędzy etykieta
FINANSOWE, OSOBOWE, SZYFROWANE,
(ściśle tajne, {SZYFROWANE, MILITARNE}) a
STRATEGICZNE ( MILITARNE)
etykietą
" Etykiety ochrony danych składają się z poziomu
(tajne, {FINANSOWE, SZYFROWANE})
zaufania i kategorii informacji, np.:
(tajne, {SZYFROWANE})
(ściśle tajne, {SZYFROWANE, MILITARNE})
Klasy bezpieczeństwa systemów
Reguły ścisłej kontroli dostępu
komputerowych
" Trusted Computer System Evaluation Criteria (TCSEC
" U\
ytkownik mo\
e uruchomić tylko proces,
Orange Book):
który posiada etykietę niewiększa od jego - standard opracowany w USA;
- pierwszy powszechny taki standard w skali światowej;
aktualnej etykiety.
- obowiązywał w latach 1985  2000;
" Proces mo\
e czytać tylko dane o etykiecie
- stał się podstawą opracowania podobnych norm w Europie
i na świecie;
niewiększej od jego aktualnej etykiety.
- bardzo często nawet współcześnie znajduje się odwołania
do certyfikatów tego standardu.
" Proces mo\
e tworzyć tylko dane o
" Information Technology Security Evaluation Criteria
etykiecie niemniejszej od jego aktualnej
(ITSEC):
- standard opracowany przez Unie Europejska;
etykiety.
- obowiązywał w latach 1991  1997;
- powstał głównie na podstawie angielskiego
CESG2/DTIEC, francuskiego SCSSI i niemieckiego ZSIEC.
Klasy bezpieczeństwa systemów
Klasy TCSEC
komputerowych
" D:
- minimalna ochrona (właściwie jej brak);
" Common Criteria Assurance Levels (EAL): - systemy poddane ocenie, ale nie spełniające wymagań
wy\
szych klas.
- aktualnie obowiązujący standard;
" C1:
- biedacy w istocie złączeniem ITSEC, TCSEC oraz
- identyfikacja i uwierzytelnianie u\
ytkowników;
kanadyjskiego CTCPEC;
- u\
ytkownicy i zasoby posiadają unikalne identyfikatory;
- od 1996 powszechnie znany jako Common
- ochrona za pomocą haseł;
Criteria for Information Technology Security
- kontrola dostępu na poziomie: właściciel, grupa, pozostali
Evaluation (CCITSE);
u\
ytkownicy;
- http://www.commoncriteria.org ;
- ochrona systemowych obszarów pamięci.
- od 1999 roku zaakceptowany jako " C2:
międzynarodowa norma ISO 15408. - mo\
liwość rozró\
niania pojedynczych u\
ytkowników;
- automatyczne czyszczenie przydzielanych obszarów
" Uzyskanie certyfikatu przynale\
ności do klasy
pamięci;
bezpieczeństwa jest operacją formalną i odpłatną.
- wymagana mo\
liwość rejestracji dostępu do zasobu (ang.
audit).
5
Klasy TCSEC
Klasy TCSEC
" B1:
- etykietowane poziomy ochrony.
" B2:
" A1:
- precyzyjnie zdefiniowany i udokumentowany model
bezpieczeństwa;
- formalny opis systemu umo\
liwiający
- ochrona strukturalna  jadro ochrony;
przeprowadzenie analizy poprawności
- weryfikacja autentyczności danych i procesów;
- informowanie u\
ytkownika o dokonywanej przez jego proces implementacji;
zmianie poziomu ochrony;
- formalne procedury analizy i weryfikacji
- wykrywanie zamaskowanych kanałów komunikacyjnych;
- ścisła rejestracja operacji.
projektu i implementacji systemu.
" B3:
- kontrola wszystkich przeprowadzanych przez u\
ytkownika
operacji;
- domeny ochronne;
- aktywna kontrola pracy systemu;
- bezpieczne przeładowanie systemu.
Poziomy pewności EAL Poziomy pewności EAL
EAL0: EAL3:
brak pewności. " produkt testowany metodycznie i sprawdzany;
EAL1: " analiza bezpieczeństwa wykorzystująca metodę  szarej
skrzynki , tj. selektywne niezale\
ne potwierdzanie wyników
" produkt testowany funkcjonalnie;
testów producenta;
" analiza bezpieczeństwa wykorzystująca specyfikacje
" wymagania związane ze środowiskiem produkcji i
funkcji interfejsu w celu zrozumienia zachowania systemu;
zarządzaniem konfiguracją.
" niezale\
ne testowanie funkcji bezpieczeństwa.
EAL4:
EAL2:
" produkt metodycznie projektowany, testowany i sprawdzany;
" produkt testowany strukturalnie;
" analiza bezpieczeństwa wykorzystująca niskopoziomowy
" analiza bezpieczeństwa wykorzystująca wysokopoziomowy
projekt modułów systemu;
opis projektu podsystemów;
" niezale\
ne wyszukiwanie luk w systemie;
" dowody testowania przez producenta i wyszukiwania
" model \
ycia, automatyczne zarządzanie konfiguracją.
oczywistych słabych punktów.
Poziomy pewności EAL Poziomy pewności EAL
EAL6:
" produkt z projektem półformalnie weryfikowanym i testowany;
EAL5:
" projektowanie modularne, warstwowe;
" produkt projektowany półformalnie i testowany;
" poszukiwanie luk musi wykazać wysoka odporność na atak
" pełna analiza implementacji;
penetracyjny;
" pewność na podstawie modelu formalnego i półformalnej
" systematyczna analiza ukrytych kanałów;
prezentacji
" zaostrzone rygory środowiska produkcji i zarządzania
specyfikacji funkcjonalnej i wysokopoziomowego opisu;
konfiguracją.
" poszukiwanie luk musi wykazać względną odporność na atak
EAL7:
penetracyjny;
" produkt z projektem formalnie weryfikowanym i testowany;
" analiza ukrytych kanałów;
" formalne podejście do specyfikowania, projektowania i
" modularność projektu.
dokumentowania systemu;
" kompletne niezale\
ne testowanie i weryfikacja testów
producenta;
" minimalizacja zło\
oności projektu
6
Kompatybilność standardów
Przynale\
ność popularnych systemów do
klas bezpieczeństwa
bezpieczeństwa
7