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