Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00033 003874 24089805 na godz. na dobę w sumie
wyszukaj dokładnie | pobierz wtyczkę
Bezpieczeństwo systemów informatycznych. Zasady i praktyka. Wydanie IV. Tom 2 - książka
Bezpieczeństwo systemów informatycznych. Zasady i praktyka. Wydanie IV. Tom 2 - książka
Autor: , Liczba stron: 624
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-283-4300-9 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> hacking >> bezpieczeństwo sieci
Porównaj ceny (książka, ebook, audiobook).
Czytaj online.
Komentuj

Bezpieczeństwo systemu informatycznego od dawna nie jest problemem wyłącznie administratora IT i jego zespołu. Różnorodność metod, socjotechnik i wyrafinowanych narzędzi wykorzystywanych do ataków oraz zacierania śladów sprawia, że zabezpieczenie usług czy zasobów musi być obowiązkiem całego personelu firmy - od prezesa po stażystę. Co więcej, bezpieczeństwo zasobów informatycznych wymaga systematycznej kontroli i systemowego podejścia, co wcale nie jest łatwym zadaniem. Z jednej strony polityka bezpieczeństwa informatycznego powinna zostać sprzężona z pozostałymi elementami strategii przedsiębiorstwa, z drugiej - podlegać ciągłej aktualizacji i przeglądom z uwagi na szybki rozwój technik ataków i ich nieprzewidywalność.

Ta książka jest drugim tomem znakomitego podręcznika projektowania, wdrażania i utrzymywania systemów bezpieczeństwa informatycznego. Poruszono w niej dość różnorodne zagadnienia: problemy zarządzania bezpieczeństwem systemu, algorytmy kryptograficzne i bezpieczeństwo sieci. Zaprezentowano różne podejścia do oceny ryzyka bezpieczeństwa, a także do tworzenia planów reagowania w przypadku wystąpienia zagrożeń, w tym klęski żywiołowej. Sporo uwagi poświęcono zapobieganiu szkodom wyrządzanym przez ludzi i reagowaniu na incydenty bezpieczeństwa. W przystępny sposób wyjaśniono standardy bezpieczeństwa sieci bezprzewodowych oraz systemów linuksowych i opartych na MS Windows. Książkę wzbogacono o szereg interesujących studiów przypadków, pytań sprawdzających, projektów i uzupełnień.

Najciekawsze zagadnienia:

Cyberbezpieczeństwo: tu nie ma miejsca na przeoczenia!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Tytuł oryginału: Computer Security: Principles and Practice (4th Edition) Tłumaczenie: Radosław Meryk (rozdz. 14 – 27, dod. A – K), Zdzisław Płoski (wstęp) ISBN: 978-83-283-4300-9 Authorized translation from the English language edition, entitled: COMPUTER SECURITY: PRINCIPLES AND PRACTICE, Fourth Edition; ISBN 0134794109; by William Stallings, and by Lawrie Brown, published by Pearson Education, Inc. Copyright © 2018, 2015, 2012, 2008 by Pearson Education, Inc. All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, incłuding photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc. Polish language edition published by HELION S.A. Copyright © 2019. Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli. Autor oraz Helion SA dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Helion SA nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. Helion SA ul. Kościuszki 1c, 44-100 Gliwice tel. 32 231 22 19, 32 230 98 63 e-mail: helion@helion.pl WWW: http://helion.pl (księgarnia internetowa, katalog książek) Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/bsiz42 Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. Printed in Poland. • Kup książkę • Poleć książkę • Oceń książkę • Księgarnia internetowa • Lubię to! » Nasza społeczność SPIS TREŚCI Przedmowa ................................................................................................................................. 9 Notacja ......................................................................................................................................21 O autorach ................................................................................................................................23 CZĘŚĆ III PROBLEMY ZARZĄDZANIA Rozdział 14. Zarządzanie bezpieczeństwem IT i ocena ryzyka ................................ 25 Zarządzanie bezpieczeństwem IT ........................................................................27 Kontekst organizacyjny i polityka bezpieczeństwa ...........................................30 Ocena ryzyka bezpieczeństwa ..............................................................................34 Szczegółowa analiza ryzyka bezpieczeństwa ......................................................38 Studium przypadku: Silver Star Mines ................................................................52 Podstawowe pojęcia, pytania sprawdzające i zadania .......................................58 14.1. 14.2. 14.3. 14.4. 14.5. 14.6. Rozdział 15. Środki, plany i procedury bezpieczeństwa IT ...................................... 61 15.1. Wdrażanie mechanizmów zarządzania bezpieczeństwem IT ..........................62 15.2. Środki bezpieczeństwa lub zabezpieczenia .........................................................63 15.3. Plan bezpieczeństwa IT .........................................................................................72 15.4. Wdrażanie zabezpieczeń .......................................................................................74 Monitorowanie zagrożeń ......................................................................................75 15.5. 15.6. Studium przypadku: Silver Star Mines ................................................................78 Podstawowe pojęcia, pytania sprawdzające i zadania .......................................81 15.7. Rozdział 16. Bezpieczeństwo fizyczne i środowiskowe ............................................. 83 Przegląd ...................................................................................................................85 Zagrożenia dla bezpieczeństwa fizycznego .........................................................85 Zapobieganie zagrożeniom fizycznym i środki łagodzące ...............................94 Odtwarzanie po naruszeniach bezpieczeństwa fizycznego ..............................98 Przykład: korporacyjna polityka bezpieczeństwa fizycznego ..........................99 Integracja bezpieczeństwa fizycznego i logicznego ...........................................99 Podstawowe pojęcia, pytania sprawdzające i zadania .....................................107 16.1. 16.2. 16.3. 16.4. 16.5. 16.6. 16.7. 5 Poleć książkęKup książkę 6 SPIS TREŚCI Rozdział 17. Bezpieczeństwo zasobów ludzkich ..................................................... 109 Świadomość bezpieczeństwa, szkolenie i edukacja .........................................110 Praktyki i zasady zatrudniania ...........................................................................117 Zasady korzystania z poczty e-mail i internetu ...............................................121 Zespoły reagowania na incydenty bezpieczeństwa komputerowego ............124 Podstawowe pojęcia, pytania sprawdzające i zadania .....................................132 17.1. 17.2. 17.3. 17.4. 17.5. Rozdział 18. Audyt bezpieczeństwa ......................................................................... 135 Architektura audytu bezpieczeństwa ................................................................137 Ślad audytu bezpieczeństwa ................................................................................143 Implementacja funkcji logowania ......................................................................148 Analiza śladu audytu bezpieczeństwa ...............................................................162 Zarządzanie informacjami o bezpieczeństwie i zdarzeniach .........................167 Podstawowe pojęcia, pytania sprawdzające i zadania .....................................169 18.1. 18.2. 18.3. 18.4. 18.5. 18.6. Rozdział 19. Aspekty prawne i etyczne .................................................................... 173 19.1. Cyberprzestępczość i przestępczość komputerowa .........................................174 19.2. Własność intelektualna .......................................................................................178 Prywatność ............................................................................................................186 19.3. 19.4. Kwestie etyczne ....................................................................................................194 Podstawowe pojęcia, pytania sprawdzające i zadania .....................................201 19.5. CZĘŚĆ IV ALGORYTMY KRYPTOGRAFICZNE Rozdział 20. Szyfrowanie symetryczne i poufność wiadomości ............................. 207 Zasady szyfrów symetrycznych ..........................................................................208 Standard DES ........................................................................................................214 Standard AES ........................................................................................................216 Szyfry strumieniowe i RC4 .................................................................................223 Tryby działania szyfrów blokowych ..................................................................228 Dystrybucja kluczy ...............................................................................................234 Podstawowe pojęcia, pytania sprawdzające i zadania .....................................236 20.1. 20.2. 20.3. 20.4. 20.5. 20.6. 20.7. Rozdział 21. Kryptografia klucza publicznego i uwierzytelnianie komunikatów ... 243 Bezpieczne funkcje haszowania .........................................................................244 HMAC ...................................................................................................................251 Szyfrowanie uwierzytelnione ..............................................................................255 Algorytm szyfrowania RSA z kluczem publicznym ........................................258 Algorytm Diffiego-Hellmana i inne algorytmy asymetryczne ......................265 Podstawowe pojęcia, pytania sprawdzające i zadania .....................................270 21.1. 21.2. 21.3. 21.4. 21.5. 21.6. Poleć książkęKup książkę SPIS TREŚCI 7 CZĘŚĆ V BEZPIECZEŃSTWO SIECI Rozdział 22. Protokoły i standardy bezpieczeństwa internetu ............................... 275 Bezpieczne wiadomości e-mail i S/MIME ........................................................276 Poczta DKIM ........................................................................................................280 Zabezpieczenia SSL i TLS ....................................................................................283 HTTPS ...................................................................................................................293 Bezpieczeństwo IPv4 i IPv6 ................................................................................294 Podstawowe pojęcia, pytania sprawdzające i zadania .....................................301 22.1. 22.2. 22.3. 22.4. 22.5. 22.6. Rozdział 23. Aplikacje do uwierzytelniania w internecie ....................................... 305 Kerberos ................................................................................................................306 X.509 ......................................................................................................................313 Infrastruktura klucza publicznego .....................................................................317 Podstawowe pojęcia, pytania sprawdzające i zadania .....................................320 23.1. 23.2. 23.3. 23.4. Rozdział 24. Bezpieczeństwo sieci bezprzewodowych ............................................ 323 Bezpieczeństwo sieci bezprzewodowych ..........................................................324 Bezpieczeństwo urządzeń mobilnych ...............................................................328 Przegląd sieci bezprzewodowych IEEE 802.11 ................................................333 Bezpieczeństwo sieci bezprzewodowych IEEE 802.11i ...................................341 Podstawowe pojęcia, pytania sprawdzające i zadania .....................................357 24.1. 24.2. 24.3. 24.4. 24.5. Rozdział 25. Bezpieczeństwo Linuksa ...................................................................... 361 25.1. Wprowadzenie .....................................................................................................362 Model bezpieczeństwa Linuksa ..........................................................................362 25.2. 25.3. DAC w szczegółach: bezpieczeństwo systemu plików ....................................364 25.4. Luki w systemie Linux .........................................................................................372 25.5. Wzmacnianie systemu Linux .............................................................................375 Bezpieczeństwo aplikacji .....................................................................................384 25.6. 25.7. Obligatoryjne mechanizmy kontroli dostępu ..................................................387 Literatura ...............................................................................................................394 25.8. Rozdział 26. Bezpieczeństwo systemu Windows ..................................................... 395 Podstawowa architektura bezpieczeństwa systemu Windows ......................396 Luki w systemie Windows ..................................................................................408 Mechanizmy obronne systemu Windows ........................................................409 Zabezpieczenia przeglądarki ..............................................................................420 Usługi kryptograficzne ........................................................................................422 Specyfikacja Common Criteria ..........................................................................424 Literatura ...............................................................................................................424 Podstawowe pojęcia i projekty ...........................................................................425 26.1. 26.2. 26.3. 26.4. 26.5. 26.6. 26.7. 26.8. Poleć książkęKup książkę 8 SPIS TREŚCI Rozdział 27. Środowiska zaufane i zabezpieczenia wielopoziomowe .................... 427 Model bezpieczeństwa komputerowego Bell-Lapadula ..................................429 Inne formalne modele bezpieczeństwa komputerowego ...............................440 Koncepcja systemów zaufanych .........................................................................447 Zastosowania zabezpieczeń wielopoziomowych .............................................451 Środowiska zaufane i moduł TPM ....................................................................458 Specyfikacja Common Criteria oceny bezpieczeństwa informatycznego ....463 Gwarancje i ocena ................................................................................................470 Literatura ...............................................................................................................476 Podstawowe pojęcia, pytania sprawdzające i zadania .....................................477 27.1. 27.2. 27.3. 27.4. 27.5. 27.6. 27.7. 27.8. 27.9. DODATKI Spis treści tomu 1. ............................................................................... 483 Dodatek A Projekty i inne ćwiczenia dla studentów uczących się bezpieczeństwa komputerów ......................................... 487 Dodatek B Wybrane elementy teorii liczb ............................................................ 495 Dodatek C Standardy i organizacje standaryzacyjne ........................................... 505 Dodatek D Generowanie liczb losowych i pseudolosowych ................................. 519 Dodatek E Kody uwierzytelniania komunikatów bazujące na szyfrach blokowych ......................................................... 531 Dodatek F Architektura protokołów TCP/IP ...................................................... 537 Dodatek G Konwersja Radix-64 ............................................................................ 545 Dodatek H System DNS ......................................................................................... 549 Dodatek I Zaniedbywanie miarodajności ............................................................ 561 Dodatek J SHA-3 ................................................................................................... 567 Słowniczek ........................................................................................... 585 Akronimy ............................................................................................. 595 Lista dokumentów NIST i ISO ............................................................ 597 Literatura ............................................................................................. 599 Skorowidz ............................................................................................ 613 Poleć książkęKup książkę ROZDZIAŁ AUDYT BEZPIECZEŃSTWA 18.1. Architektura audytu bezpieczeństwa Model audytu bezpieczeństwa i alarmów Funkcje audytu bezpieczeństwa Wymagania Wytyczne dotyczące wdrażania 18.2. Ślad audytu bezpieczeństwa Co zbierać? Ochrona danych z audytu 18.3. Wdrażanie funkcji logowania Logowanie na poziomie systemu Logowanie na poziomie aplikacji Biblioteki interpozycyjne Dynamiczne przepisywanie binarne 18.4. Analiza śladu audytu bezpieczeństwa Przygotowanie Przebieg czasowy Przegląd audytu Podejścia do analizy danych 18.5. Zarządzanie informacjami o bezpieczeństwie i zdarzeniami Systemy SIEM 18.6. Podstawowe pojęcia, pytania sprawdzające i zadania 135 Poleć książkęKup książkę 136 ROZDZIAŁ 18. AUDYT BEZPIECZEŃSTWA W TYM ROZDZIALE POZNASZ I ZROZUMIESZ:  elementy składowe architektury audytu bezpieczeństwa;  względne zalety różnych typów ścieżek z audytu bezpieczeństwa;  kluczowe zagadnienia związane z implementacją funkcji logowania na potrzeby audytu bezpieczeństwa;  proces analizy ścieżki audytu. Audyt bezpieczeństwa to forma audytu, która koncentruje się na bezpieczeństwie zaso- bów informatycznych (zasobów IT) organizacji. Jest to kluczowy mechanizm kompute- rowego bezpieczeństwa. Audyt bezpieczeństwa może:  Zapewnić o prawidłowym działaniu komputera pod względem bezpieczeństwa.  Wygenerować dane, które mogą być wykorzystane w analizie ataku „po fakcie”, bez względu na to, czy atak zakończył się powodzeniem, czy nie.  Dostarczyć mechanizmów oceny niedociągnięć w usłudze bezpieczeństwa.  Dostarczyć informacji, które można wykorzystać do zdefiniowania anormalnego zachowania.  Utrzymać rejestr informacji przydatnych w śledztwach komputerowych. Dwa kluczowe pojęcia to audyt bezpieczeństwa i ścieżki audytu bezpieczeństwa1 zdefiniowane w tabeli 18.1. Tabela 18.1. Terminologia związana z audytami bezpieczeństwa (RFC 4949) Audyt bezpieczeństwa Niezależny przegląd i analiza zapisów i działań systemu w celu określenia adekwatności zabezpieczeń w systemie, zapewnienia zgodności z ustaloną polityką bezpieczeństwa i procedurami, wykrywania naruszeń w usługach bezpieczeństwa oraz zalecenia zmian wykonywanych w ramach działań zaradczych. Podstawowym celem audytu jest ustalenie odpowiedzialności za elementy systemowe, które inicjują zdarzenia i działania związane z bezpieczeństwem lub biorą w nich udział. Dlatego potrzebne są środki do generowania i rejestrowania śladu audytu bezpieczeństwa oraz do przeglądania i analizowania ścieżek audytu w celu wykrycia i zbadania ataków i naruszeń w zabezpieczeniach. Ścieżka audytu bezpieczeństwa Chronologiczny zapis działań w systemie, wystarczający do odtworzenia i zbadania sekwencji zjawisk środowiskowych i działań lub czynności prowadzących do wykonania operacji, procedur lub zdarzeń w transakcji związanej z bezpieczeństwem — od zainicjowania do końcowych rezultatów. 1 Standard NIST SP 800-12 (An Introduction to Computer Security: The NIST Handbook z października 1995) wskazuje, że niektórzy eksperci ds. bezpieczeństwa rozróżniają ślad audytu od logu audytu w następujący sposób: log jest zapisem zdarzeń, które zaszły w konkretnym pakiecie oprogramowania, a ścieżka audytu to cała historia zdarzenia, często z wykorzystaniem wielu logów. Jednak w społeczności specjalistów bezpieczeństwa nie stosuje się powszechnie tej definicji. W tej książce nie dokonujemy takiego rozróżnienia. Poleć książkęKup książkę 18.1. ARCHITEKTURA AUDYTU BEZPIECZEŃSTWA 137 Proces generowania informacji audytu dostarcza danych, które mogą być przydatne w czasie rzeczywistym do wykrywania włamań; ten aspekt omówiono w rozdziale 8. W niniejszym rozdziale skupimy się na gromadzeniu, przechowywaniu i analizie da- nych związanych z bezpieczeństwem IT. Zaczniemy od ogólnego przeglądu zagadnień związanych z architekturą audytu bezpieczeństwa oraz pokazania, w jaki sposób odnosi się ona do działań towarzyszących wykrywaniu włamań. Następnie omówimy różne aspekty ścieżek audytu, znanych również jako logi audytu. Na koniec omówimy pro- blematykę analizy danych z audytu. 18.1. ARCHITEKTURA AUDYTU BEZPIECZEŃSTWA Dyskusję na temat audytu bezpieczeństwa rozpoczynamy od analizy elementów skła- dających się na jego architekturę. Najpierw zbadamy model, który prezentuje audyt bezpieczeństwa w szerszym kontekście. Następnie przyjrzymy się funkcjonalnemu po- działowi audytu bezpieczeństwa. Model audytu bezpieczeństwa i alarmów Rekomendacja X.816 ITU-T2 definiuje model, w którym wskazano elementy funkcji audytu bezpieczeństwa i ich związek z alarmami bezpieczeństwa. Ten model przedsta- wiono na rysunku 18.1. Oto jego kluczowe elementy:  Dyskryminator zdarzeń — wbudowana w oprogramowanie systemu logika, która monitoruje aktywność systemu i wykrywa związane z bezpieczeństwem zdarzenia skonfigurowane do wykrywania.  Rejestrator audytu — dla każdego wykrytego zdarzenia dyskryminator zdarzenia przesyła informacje do rejestratora audytu. W modelu zaprezentowano tę komuni- kację w formie komunikatu. Audyt można również realizować poprzez rejestrację zdarzeń w obszarze pamięci współdzielonej.  Procesor alarmów — niektóre zdarzenia wykryte przez dyskryminator zdarzeń są zdefiniowane jako alarmowe. W przypadku takich zdarzeń do procesora alarmów jest wysyłany alarm. Na tej podstawie procesor alarmów podejmuje określone dzia- łania. Te działania same w sobie są zdarzeniami, które można rejestrować, dlatego są przesyłane do rejestratora audytu.  Ścieżka audytu bezpieczeństwa — rejestrator audytu tworzy sformatowany zapis każdego zdarzenia i rejestruje go w ścieżce audytu bezpieczeństwa. 2 Telecommunication Standardization Sector of the International Telecommunications Union. Informacje dotyczące tej i innych instytucji tworzących standardy można znaleźć w dodatku C. Poleć książkęKup książkę 138 ROZDZIAŁ 18. AUDYT BEZPIECZEŃSTWA  Analizator audytu — ścieżka audytu bezpieczeństwa jest dostępna dla analizatora audytu. Ten, na podstawie wzorca działania, może zdefiniować nowe, podlegające audy- towi zdarzenie, które jest wysyłane do rejestratora audytu i może wygenerować alarm.  Archiwizator audytu — moduł oprogramowania, który okresowo wyodrębnia re- kordy ze ścieżki audytu w celu utworzenia stałego archiwum zdarzeń podlegających audytowi.  Archiwa — archiwa audytu są trwałym magazynem zdarzeń związanych z bezpie- czeństwem w tym systemie.  Dostawca audytu — dostawca audytu jest aplikacją i (lub) interfejsem użytkownika do ścieżki audytu.  Analizator ścieżki audytu — analizator ścieżki audytu to aplikacja lub użytkownik, który sprawdza ścieżkę audytu i archiwa audytu pod kątem historycznych trendów dla celów komputerowych śledztw oraz innych analiz.  Raporty bezpieczeństwa — analizator ścieżki audytu przygotowuje czytelne dla człowieka raporty bezpieczeństwa. Rysunek 18.1. Model audytu bezpieczeństwa i alarmów (X.816) Poleć książkęKup książkę 18.1. ARCHITEKTURA AUDYTU BEZPIECZEŃSTWA 139 Ten model ilustruje związek pomiędzy funkcjami audytu a funkcjami alarmowymi. Funkcja audytu tworzy rejestr zdefiniowanych przez administratora bezpieczeństwa zdarzeń związanych z bezpieczeństwem. Niektóre z tych zdarzeń mogą być rzeczywi- stymi naruszeniami bezpieczeństwa lub podejrzeniem naruszenia bezpieczeństwa. Takie zdarzenia są przekazywane za pośrednictwem alarmów do systemu wykrywania włamań lub zapory firewall. Tak jak jest w przypadku wykrywania włamań, w systemach rozproszonych może być przydatna rozproszona funkcja audytu, w której tworzone jest scentralizowane re- pozytorium. Dla usługi rozproszonego audytu potrzebne są dwa dodatkowe elementy logiczne (patrz rysunek 18.2):  Zbieracz śladu audytu (ang. audit trail collector) — moduł wchodzący w skład scentralizowanego systemu, który gromadzi zapisy ścieżki audytu z innych systemów i tworzy scaloną ścieżkę audytu.  Dyspozytor audytu — moduł, który przesyła zapisy ścieżki audytu z lokalnego sys- temu do centralnego modułu zbierania ścieżek audytu. Rysunek 18.2. Model rozproszonego śladu audytu (X.816) Funkcje audytu bezpieczeństwa Warto przyjrzeć się kolejnemu podziałowi mechanizmu audytu bezpieczeństwa, opra- cowanemu w ramach specyfikacji Common Criteria [CCPS12a]. Podział audytu bez- pieczeństwa na sześć głównych obszarów, z których każdy spełnia jedną lub więcej konkretnych funkcji, pokazano na rysunku 18.3:  Generowanie danych — identyfikuje poziom rejestrowania, wylicza typy możli- wych do zarejestrowania zdarzeń i identyfikuje minimalny zestaw dostarczanych informacji podlegających audytowi. Ta funkcja musi również rozwiązywać konflikt pomiędzy bezpieczeństwem a prywatnością i określać, dla których zdarzeń w wyni- kowym raporcie powinny się znaleźć dane tożsamości użytkownika powiązanego z działaniami. Poleć książkęKup książkę 140 ROZDZIAŁ 18. AUDYT BEZPIECZEŃSTWA Rysunek 18.3. Dekompozycja klas audytu kontroli zgodnie ze specyfikacją Common Criteria  Wybór zdarzeń — uwzględnienie lub wykluczenie zdarzenia z zestawu zdarzeń podlegających rejestrowaniu. Umożliwia to skonfigurowanie systemu na różnych poziomach szczegółowości, tak by uniknąć generowania nieprzydatnych raportów.  Przechowywanie zdarzeń — tworzenie i utrzymanie bezpiecznego śladu audytu. Funkcja przechowywania obejmuje mechanizmy zapewniające dostępność i zapo- biegające utracie danych ze ścieżki audytu.  Automatyczna odpowiedź — określa reakcje po wykryciu zdarzeń wskazujących na potencjalne naruszenia bezpieczeństwa. Poleć książkęKup książkę 18.1. ARCHITEKTURA AUDYTU BEZPIECZEŃSTWA 141  Analiza audytu — wykonywana za pośrednictwem zautomatyzowanych mechani- zmów analizy aktywności w systemie i danych audytu w poszukiwaniu naruszeń bezpieczeństwa. Ten komponent identyfikuje zestaw zdarzeń, których wystąpienie lub skumulowane wystąpienie wskazuje na potencjalne naruszenie bezpieczeństwa. W przypadku takich zdarzeń przeprowadza się analizę w celu ustalenia, czy doszło do naruszenia bezpieczeństwa. W tej analizie wykorzystuje się mechanizmy wykry- wanie anomalii i heurystykę ataków.  Przegląd audytu — dostępny dla uprawnionych użytkowników, którzy wspomagają proces przeglądania danych z audytu. Komponent przeglądu audytu może zawierać wybieraną funkcję przeglądania, która dostarcza możliwości wykonywania operacji wyszukiwania z wykorzystaniem jednego bądź wielu kryteriów powiązanych rela- cjami logicznymi (tzn. and, or), sortowaniem danych audytu oraz filtrowaniem da- nych audytu przed ich przeglądaniem. Uprawnienia do przeglądu audytu mogą być ograniczone dla wybranych użytkowników. Wymagania Na podstawie zbioru funkcjonalności sugerowanych przez rysunki 18.1 i 18.3 możemy opracować zestaw wymagań dotyczących audytu bezpieczeństwa. Pierwszym wymaga- niem jest zdefiniowanie zdarzeń. Administrator bezpieczeństwa powinien zdefiniować zestaw zdarzeń podlegających audytowi. Tym tematem zajmiemy się bardziej szczegó- łowo w następnym podrozdziale. Poniżej podajemy listę zaproponowaną w [CCPS12a]:  wprowadzenie obiektów w części oprogramowania związanej z bezpieczeństwem do przestrzeni adresowej podmiotu;  usuwanie obiektów;  przydzielanie lub odwoływanie uprawnień lub możliwości dostępu;  zmiany atrybutów podmiotu lub obiektu zabezpieczeń;  kontrole zasad wykonywane przez oprogramowanie zabezpieczające w wyniku żą- dania podmiotu;  korzystanie z praw dostępu w celu ominięcia sprawdzenia zasad;  wykorzystanie funkcji identyfikacji i uwierzytelniania;  czynności związane z bezpieczeństwem podjęte przez operatora i (lub) uprawnione- go użytkownika (np. wyłączenie mechanizmu zabezpieczeń);  importowanie (eksportowanie) danych z nośników wymiennych lub na nośniki wymienne (np. tworzenie wydruków, zapis na dyski magnetyczne bądź optyczne albo na przenośne urządzenia pamięci masowej USB). Poleć książkęKup książkę 142 ROZDZIAŁ 18. AUDYT BEZPIECZEŃSTWA Drugie wymaganie dotyczy dostępności w aplikacjach i oprogramowaniu systemo- wym odpowiednich haków pozwalających na wykrywanie zdarzeń. W celu zarejestro- wania odpowiednich działań należy dodać do systemu oprogramowanie monitorujące. Potrzebny jest również mechanizm nagrywania zdarzeń, który uwzględnia potrzebę zapewnienia bezpiecznej pamięci trwałej odpornej na zmodyfikowanie lub usunięcie. W celu analizy zebranych danych, a także w celu badania trendów w danych i anomalii mogą być wykorzystywane oprogramowanie, narzędzia i interfejsy do analizy zda- rzeń i ścieżek audytu. Istnieje dodatkowe wymaganie dotyczące bezpieczeństwa funkcji audytu. Przed obchodzeniem lub naruszeniem muszą być chronione nie tylko ścieżka audytu, ale całe oprogramowanie do obsługi audytu i pośrednia pamięć. System audytu powinien mieć minimalny wpływ na funkcjonalność. Wytyczne dotyczące wdrażania Przydatny zestaw wytycznych dotyczących audytu systemów informatycznych zawiera standard ISO3 27002 (Code of Practice for Information Security Management z paź- dziernika 2013 r.): 1. Wymagania audytu dotyczące dostępu do systemów i danych powinny zostać uzgod- nione z kierownictwem odpowiedniego szczebla zarządzania. 2. Zakres technicznych testów audytu powinien być uzgodniony i kontrolowany. 3. W testach kontrolnych powinien być wykorzystywany tylko dostęp do odczytu do oprogramowania i danych. 4. Dostęp do danych inny niż tylko do odczytu powinien być dozwolony tylko w przy- padku kopii pojedynczych plików systemowych, które powinny zostać usunięte po zakończeniu audytu lub — jeżeli w wymaganiach dotyczących dokumentacji audytu istnieje obowiązek przechowywania takich plików — objęte odpowiednią ochroną. 5. Należy zidentyfikować i uzgodnić wymagania dotyczące specjalnego lub dodatko- wego przetwarzania. 6. Testy kontrolne, które mogą wpływać na dostępność systemu, powinny być uru- chamiane poza godzinami pracy. 7. W celu utworzenia ścieżki referencyjnej wszystkie dostępy powinny być monitoro- wane i rejestrowane. 3 International Organization for Standardization. Więcej informacji na temat tej i innych instytucji tworzących standardy oraz listę dokumentów NIST i ISO można znaleźć w dodatku C. Poleć książkęKup książkę 18.2. ŚLAD AUDYTU BEZPIECZEŃSTWA 143 18.2. ŚLAD AUDYTU BEZPIECZEŃSTWA Ścieżki audytu zachowują rejestr aktywności w systemie. W tym podrozdziale zajmiemy się kwestiami dotyczącymi ścieżek audytu. Co zbierać? Wybór danych do zbierania zależy od wielu wymagań. Jednym z problemów jest ilość danych do zebrania, która zależy od zakresu obszarów zainteresowania i szczegółowo- ści gromadzonych danych. Należy zastosować kompromis pomiędzy objętością a wy- dajnością. Im więcej gromadzonych danych, tym większe obniżenie wydajności systemu. Większe ilości danych mogą również niepotrzebnie obciążać różne algorytmy używane do badania i analizy danych. Ponadto istnienie dużej ilości danych tworzy pokusę gene- rowania raportów bezpieczeństwa w nadmiernej liczbie lub objętości. Z uwagi na powyższe ostrzeżenia pierwszym wymaganiem biznesowym w pro- jektowaniu ścieżki audytu bezpieczeństwa jest wybór elementów danych do zebrania. Mogą to być:  Zdarzenia związane z korzystaniem z oprogramowania do audytów (tzn. z wszyst- kich komponentów z rysunku 18.1).  Zdarzenia związane z mechanizmami zabezpieczeń w systemie.  Wszelkie zdarzenia zbierane w celu wykorzystania przez różne mechanizmy wy- krywania zagrożeń i zapobiegania im. Obejmuje to elementy istotne dla działania mechanizmu wykrywania włamań oraz zapory firewall.  Zdarzenia związane z zarządzaniem systemem i jego działaniem.  Dostęp do systemu operacyjnego (np. za pośrednictwem wywołań systemowych podobnych do tych, które wyszczególniono w tabeli 8.2).  Dostęp do wybranych aplikacji.  Zdalny dostęp. Jednym z przykładów zdarzeń do wyboru może być sugerowana lista zdarzeń pod- legających audytowi pochodząca ze standardu X.816, którą zaprezentowano w tabeli 18.2. Standard wskazuje, że audytem powinny być objęte zarówno działania normalne, jak i nadzwyczajne; na przykład przedmiotem rejestrowania w ścieżce audytu może być każde żądanie połączenia, takie jak żądanie połączenia TCP, niezależnie od tego, czy było ono prawidłowe, czy nie, i niezależnie od tego, czy żądanie zostało zaakceptowane, czy nie. To jest bardzo istotna kwestia. Zbieranie danych do audytu wykracza poza po- trzebę generowania alarmów bezpieczeństwa lub wprowadzania danych do modułu za- pory firewall. Do identyfikowania normalnych i nienormalnych wzorców użycia, a zatem Poleć książkęKup książkę 144 ROZDZIAŁ 18. AUDYT BEZPIECZEŃSTWA Tabela 18.2. Zdarzenia podlegające audytowi sugerowane w X.816 Zdarzenia związane z bezpieczeństwem związane z konkretnym połączeniem • żądania połączenia; • potwierdzenia połączeń; • żądania rozłączenia; • potwierdzenia rozłączenia; • statystyki dotyczące połączenia. Zdarzenia związane z bezpieczeństwem związane z korzystaniem z usług zabezpieczeń • żądania usługi zabezpieczeń; • skorzystanie z mechanizmów zabezpieczeń; • alarmy bezpieczeństwa. Zdarzenia związane z bezpieczeństwem dotyczące zarządzania • operacje zarządzania; • powiadomienia związane z zarządzaniem. Lista zdarzeń podlegających audytowi powinna zawierać przynajmniej • odmowy dostępu; • uwierzytelnienia; • zmiany atrybutów; • tworzenie obiektów; • usunięcie obiektów; • modyfikowanie obiektów; • skorzystanie z uprawnień. W zakresie pojedynczych usług bezpieczeństwa ważne są następujące zdarzenia • uwierzytelnianie: weryfikacja pomyślna; • uwierzytelnianie: weryfikacja niepomyślna; • kontrola dostępu: decyzja o przyznaniu dostępu; • kontrola dostępu: decyzja o odmowie dostępu; • niezaprzeczalność: niezaprzeczalne pochodzenie wiadomości; • niezaprzeczalność: niezaprzeczalne odebranie wiadomości; • niezaprzeczalność: nieudane odrzucenie zdarzenia; • niezaprzeczalność: pomyślne odrzucenie zdarzenia; • integralność: użycie osłony; • integralność: użycie bez osłony; • integralność: pomyślna weryfikacja poprawności; • integralność: niepomyślna weryfikacja poprawności; • poufność: skorzystanie z ukrycia; • poufność: wykorzystanie ujawnienia; • audyt: wybór zdarzenia do audytu; • audyt: anulowanie wyboru zdarzenia do audytu; • audyt: zmiana kryteriów wyboru zdarzeń do audytu. spełniania roli danych wejściowych do analizy wykrywania włamań, mogą być uży- wane dane reprezentujące zachowania niewyzwalające alarmów. Ponadto w przypadku ataku może być potrzebna analiza całej aktywności w systemie. To pozwala zdiagnozo- wać atak i znaleźć właściwe środki zaradcze na przyszłość. Kolejną przydatną listę zdarzeń podlegających audytowi (patrz tabela 18.3) zesta- wiono w dokumencie standardu ISO 27002. Podobnie jak jest w X.816, standard ISO wyszczególnia zarówno zdarzenia autoryzowane, jak i nieautoryzowane, a także zda- rzenia wpływające na funkcje bezpieczeństwa systemu. Ponieważ administrator bezpieczeństwa projektuje zasady zbierania danych audytu, przydatne jest podzielenie ścieżki audytu na kategorie w celu dokonania selekcji ele- mentów danych do zebrania. Poniżej zaprezentujemy przydatne kategorie projektowa- nia ścieżek audytu. Poleć książkęKup książkę 18.2. ŚLAD AUDYTU BEZPIECZEŃSTWA 145 Tabela 18.3. Obszary monitorowania zasugerowane w standardzie ISO 27002 a) identyfikatory użytkowników b) operacje systemowe c) daty, godziny i szczegóły kluczowych zdarzeń, na przykład logowania i wylogowania użytkowników d) tożsamość urządzeń lub, jeśli to możliwe, lokalizacja, oraz identyfikator systemowy e) zapisy udanych i odrzuconych prób dostępu do systemu f) zapisy udanych i odrzuconych prób dostępu do danych oraz innych zasobów g) zmiany w konfiguracji systemu h) korzystanie z uprawnień i) korzystanie z narzędzi i aplikacji systemowych j) dostęp do plików i rodzaj dostępu k) adresy i protokoły sieciowe l) alarmy wywoływane przez system kontroli dostępu m) aktywacje i dezaktywacje systemów ochrony, takich jak systemy antywirusowe i systemy wykrywania intruzów n) zapisy transakcji dokonanych przez użytkowników w aplikacjach ŚCIEŻKI AUDYTU NA POZIOMIE SYSTEMU Zwykle są używane do monitorowania i optymalizacji wydajności systemu, ale mogą również spełniać funkcje audytu bezpieczeństwa. Niektóre aspekty polityki bezpieczeństwa egzekwuje sam system — na przykład dostęp do systemu. Ścieżka audytu na poziomie systemu powinna przechwytywać takie dane jak próby logowania, zarówno udane, jak i niepomyślne, używane urządzenia i wykonywane funkcje systemu operacyjnego. Dla audytu mogą być interesujące również inne funkcje na poziomie systemu — na przykład działanie systemu oraz wskaźniki wydajności sieci. Przykład ścieżki audytu na poziomie systemu dla systemu operacyjnego UNIX zaprezentowano na rysunku 18.4a, pochodzącym ze standardu NIST SP 800-12 (An Introduction to Computer Security: The NIST Handbook z października 1995). Polecenie shutdown kończy wszystkie procesy i przełącza system do trybu pojedynczego użytkownika. Polecenie su tworzy powłokę UNIX. ŚCIEŻKI AUDYTU NA POZIOMIE APLIKACJI Mogą służyć do wykrywania naruszeń bezpieczeństwa w aplikacji lub do wykrywania luk w interakcji aplikacji z systemem. W przypadku aplikacji o kluczowym znaczeniu lub takich, które dotyczą wrażliwych danych, ścieżka audytu na poziomie aplikacji może zapewniać pożądany poziom szczegółowości pozwalający na ocenę zagrożeń i skutków dla bezpieczeństwa. Na przykład w przypadku aplikacji e-mail ścieżka audytu może re- jestrować nadawcę i odbiorcę, rozmiar wiadomości i typy załączników. Ścieżka audytu dla interakcji z bazą danych za pomocą zapytań SQL (ang. Structured Query Language) może rejestrować użytkownika, typ transakcji, a nawet poszczególne tabele, wiersze, kolumny lub elementy danych, do których uzyskano dostęp. Poleć książkęKup książkę 146 ROZDZIAŁ 18. AUDYT BEZPIECZEŃSTWA Rysunek 18.4. Przykłady ścieżek audytu Na rysunku 18.4b zaprezentowano przykład ścieżki audytu na poziomie aplikacji dla systemu dostarczania poczty. ŚCIEŻKI AUDYTU NA POZIOMIE UŻYTKOWNIKA Zawierają rejestr aktywności pojedynczych użytkowników na przestrzeni czasu. Mogą być wykorzystywane do pociągania użytkowników do odpowiedzialności za ich działania. Takie ścieżki audytu są również użyteczne jako dane wejściowe do programów analitycznych, które potrafią zestawić zachowania normalne z zachowaniami odbiegającymi od normy. Ścieżka audytu na poziomie użytkownika może służyć do rejestrowania interakcji użytkownika z systemem — na przykład wydawanych poleceń, prób identyfikacji i uwie- rzytelniania, a także plików i zasobów, do których użytkownik uzyskał dostęp. W ścieżce audytu mogą również być przechowywane informacje o aplikacjach wykorzystywanych przez użytkownika. Poleć książkęKup książkę 18.2. ŚLAD AUDYTU BEZPIECZEŃSTWA 147 Przykład ścieżki audytu na poziomie użytkownika w systemie UNIX zaprezentowano na rysunku 18.4c. ŚCIEŻKI AUDYTU DOSTĘPU FIZYCZNEGO Mogą być generowane przez sprzęt zarządzający fizycznym dostępem. Następnie uzy- skane dane są przesyłane do centralnego hosta w celu dalszego przechowywania i analizy. Przykładami są systemy kart kluczy i systemy alarmowe. W standardzie NIST SP 800-12 zaprezentowano następujące przykłady danych, które mogą być przedmiotem zaintere- sowania audytów dostępu fizycznego:  Data i godzina, gdy próbowano uzyskać dostęp lub go uzyskano; ponadto powinny być zarejestrowane dane bramy lub drzwi, przez które próbowano uzyskać dostęp, oraz personalia osoby (lub identyfikator użytkownika) podejmującej próbę uzyska- nia dostępu do bramy lub drzwi.  Nieudane próby dostępu powinny być monitorowane i logowane w niekomputero- wych ścieżkach audytu, podobnie jak w przypadku ścieżek audytu systemów kom- puterowych. Jeśli ktoś próbuje uzyskać dostęp w niedozwolonych godzinach, należy o tym fakcie poinformować kierownictwo.  W rejestrowanych danych powinny się także znaleźć próby dodawania, modyfiko- wania lub usuwania fizycznych uprawnień dostępu (np. przyznanie nowemu pra- cownikowi dostępu do budynku lub przyznanie przeniesionego pracownikowi do- stępu do nowego biura [i, co oczywiste, usunięcie jego starych uprawnień dostępu, stosownie do przypadku]).  Podobnie jak jest w przypadku ścieżek audytu systemów i aplikacji, mechanizmy audytu niekomputerowych funkcji mogą być zaimplementowane tak, aby wysyłały komunikaty do personelu ochrony, wskazując na udane lub nieudane próby zdobycia dostępu do kontrolowanych przestrzeni. Aby nie obniżać czujności strażników lub osób monitorujących, zdarzenia dostępu nie powinny powodować wysyłania komunikatów na ekran ich monitorów. Osoby monitorujące powinny być informowane wyłącznie o sytuacjach wyjątkowych, na przykład o nieudanych próbach dostępu. Ochrona danych z audytu W dokumencie RFC 2196 (Site Security Handbook z 1997 roku) wymieniono trzy alter- natywne sposoby przechowywania zapisów z audytu:  plik na hoście do odczytu i zapisu;  urządzenie do jednokrotnego zapisu i wielokrotnego odczytu (np. CD-ROM lub DVD-ROM);  urządzenie wyłącznie do zapisu (np. drukarka). Poleć książkęKup książkę 148 ROZDZIAŁ 18. AUDYT BEZPIECZEŃSTWA Rejestrowanie w systemie plików jest stosunkowo łatwe do skonfigurowania i wy- maga najmniej zasobów. Dostęp do zapisów jest natychmiastowy, co może się przydać jako środek przeciwdziałania trwającemu atakowi. Jednak stosowanie takiego podejścia stwarza wiele zagrożeń. Jeśli napastnik uzyska uprzywilejowany dostęp do systemu, ścieżka audytu może zostać zmodyfikowana lub usunięta. Nagrywanie na płyty DVD-ROM lub stosowanie podobnej metody przechowywa- nia jest znacznie bezpieczniejsze, ale mniej wygodne. Konieczne jest ciągłe uzupełnianie nagrywalnych nośników. Dostęp do danych może być opóźniony. Logi drukowane dostarczają papierowej wersji ścieżki audytu, ale są niepraktyczne dla celów przechowywania szczegółowych danych audytu w rozbudowanych systemach lub systemach sieciowych. Dokument RFC 2196 sugeruje, że papierowy log może się przydać, gdy stały, dostępny natychmiast dziennik jest wymagany, nawet w przypadku awarii systemu. Ochrona ścieżki audytu obejmuje zarówno integralność, jak i poufność. Szczególnie ważna jest integralność, ponieważ intruz może próbować usunąć dowody włamania poprzez modyfikację ścieżki audytu. W przypadku logów w systemie plików prawdo- podobnie najlepszym sposobem zapewnienia integralności są podpisy cyfrowe. Inte- gralność automatycznie zapewniają urządzenia jednokrotnego zapisu — na przykład płyty DVD-ROM lub papier. Kolejnym środkiem zapewniającym integralność są silne mechanizmy kontroli dostępu. Poufność jest ważna w przypadku, gdy ścieżka audytu zawiera informacje użytkow- ników, które są poufne i nie powinny być ujawniane wszystkim użytkownikom, na przy- kład informacje o zmianach wynagrodzenia lub grupy wynagrodzenia. Do ochrony tego rodzaju informacji można wykorzystać mechanizmy silnej kontroli dostępu. Skutecz- nym środkiem jest szyfrowanie symetryczne (np. z wykorzystaniem algorytmu AES [ang. Advanced Encryption Standard] lub potrójnego algorytmu DES [ang. Data Encryp- tion Standard]). Klucz tajny musi być chroniony i dostępny tylko dla oprogramowania audytowego oraz pomocniczego oprogramowania do analizy audytu. Należy zwrócić uwagę, że mechanizmy integralności i poufności chronią dane ścież- ki audytu nie tylko w pamięci lokalnej, ale również podczas przesyłania do centralnego repozytorium. 18.3. IMPLEMENTACJA FUNKCJI LOGOWANIA Podstawę do stworzenia mechanizmu audytu bezpieczeństwa stanowi początkowe po- branie danych audytu. Wymaga to, aby oprogramowanie zawierało haki lub punkty przechwytu, które wyzwalają gromadzenie i zapisywanie danych w odpowiedzi na wy- brane wcześniej zdarzenia. Taka funkcja gromadzenia lub rejestrowania zależy od ro- dzaju oprogramowania i może być różna w zależności od wykorzystywanego systemu operacyjnego i aplikacji. W tym podrozdziale przyjrzymy się sposobom podejścia do implementacji funkcji logowania dla ścieżek audytu na poziomie systemu i na poziomie użytkownika oraz ścieżek audytu na poziomie aplikacji. Poleć książkęKup książkę Logowanie na poziomie systemu 18.3. IMPLEMENTACJA FUNKCJI LOGOWANIA 149 Znaczna część zadań logowania na poziomie systemu może być zaimplementowana przy użyciu istniejących urządzeń, które są częścią systemu operacyjnego. W tym punkcie pokrótce przyjrzymy się mechanizmowi logowania w systemie operacyjnym Windows, a następnie opiszemy mechanizm syslog w systemach operacyjnych z rodziny UNIX. DZIENNIK ZDARZEŃ SYSTEMU WINDOWS Zdarzenie w dzienniku zdarzeń systemu Windows to jednostka opisująca jakieś intere- sujące zdarzenia w systemie komputerowym. Zdarzenia zawierają liczbowy kod identy- fikacyjny, zestaw atrybutów (zadanie, kod operacyjny, poziom szczegółowości, wersja i słowa kluczowe) oraz opcjonalne dane dostarczone przez użytkownika. W systemie Windows dostępne są trzy typy logów zdarzeń:  Log zdarzeń systemowych — używany przez aplikacje działające z tożsamością kont usług systemowych (zainstalowanych usług systemowy), sterowniki, kompo- nenty lub aplikacje, które posługują się zdarzeniami związanymi z kondycją systemu komputerowego.  Log zdarzeń aplikacji — zdarzenia dla wszystkich aplikacji na poziomie użytkow- nika. Ten dziennik nie jest zabezpieczony i jest otwarty dla wszystkich aplikacji. Aplikacje, które logują obszerny zbiór informacji, powinny definiować dziennik specyficzny dla aplikacji.  Log zdarzeń bezpieczeństwa — log audytu systemu Windows. Ten log zdarzeń słu- ży wyłącznie do lokalnego użytku mechanizmu Windows Local Security Authority. W danych audytu mogą pojawiać się zdarzenia użytkownika tylko wtedy, gdy są ob- sługiwane przez wskazaną aplikację. W przypadku wszystkich logów zdarzeń lub ścieżek audytu informacje o zdarze- niach mogą być przechowywane w formacie XML. Listę informacji przechowywanych dla każdego zdarzenia zamieszczono w tabeli 18.4. Na rysunku 18.5 pokazano przykład danych eksportowanych z logu zdarzeń systemu Windows. Tabela 18.4. Elementy schematu zdarzeń systemu Windows Wartości właściwości zdarzenia zawierające dane binarne Diagnostyczne pole LevelName preprocesora WPP systemu Windows wykorzystywane w zdarzeniach debugowania w kanałach debugowania Dane binarne dostarczane przez log zdarzeń systemu Windows Poziom renderowany dla zdarzenia Kanał, na którym zostanie opublikowane renderowane zdarzenie Złożone dane dla parametru dostarczanego przez dostawcę zdarzenia Stopień istotności zdarzenia Diagnostyczne pole FormattedString preprocesora WPP systemu Windows wykorzystywane w zdarzeniach debugowania w kanałach debugowania Poleć książkęKup książkę 150 ROZDZIAŁ 18. AUDYT BEZPIECZEŃSTWA Komunikat renderowany dla zdarzenia Tabela 18.4. Elementy schematu zdarzeń systemu Windows — ciąg dalszy Diagnostyczne pole ComponentName preprocesora WPP używane w zdarzeniach debugowania Komputer, na którym miało miejsce zdarzenie Dwie 128-bitowe wartości, które można wykorzystać do wyszukiwania powiązanych zdarzeń Nazwa elementu danych zdarzenia, który spowodował błąd podczas przetwarzania danych zdarzenia Dane składające się na jedną część złożonego typu danych dostarczoną przez dostawcę zdarzenia Dane dla parametru dostarczonego przez dostawcę zdarzenia Wydawca zdarzenia, który opublikował renderowane Opkod, który zostanie wyrenderowany dla zdarzenia Działanie lub moment podczas działania, które było wykonywane w aplikacji w czasie, gdy zaistniało zdarzenie Elementy, które definiują zdarzenia instrumentacji Informacje o dostawcy, który opublikował zdarzenie Wartości właściwości zdarzeń preprocesora WPP systemu Windows Kod błędu, który został zgłoszony, gdy wystąpił błąd przetwarzania danych zdarzenia Strukturalna informacja opisująca jakieś interesujące zdarzenie w systemie Numer identyfikacyjny zdarzenia Informacje o procesie i wątku, w którym wystąpiło zdarzenie zdarzenie Informacje, które będą renderowane dla zdarzenia Identyfikator bezpieczeństwa użytkownika Pole SequenceNum preprocesora WPP systemu Windows używane w zdarzeniach debugowania w kanałach debugowania Pole SubComponentName preprocesora WPP systemu Windows używane w zdarzeniach debugowania w kanałach debugowania Informacje automatycznie wypełniane przez system po wystąpieniu zdarzenia lub w momencie jego zapisywania do pliku logu Zadanie, które zostanie wyrenderowane dla zdarzenia Informacje o czasie zdarzenia Binarne dane zdarzenia, które spowodowało błąd podczas przetwarzania danych związanych ze zdarzeniem Informacje o procesie i wątku, w których wystąpiło zdarzenie Zadanie z wartością symboliczną Pole FileLine preprocesora WPP systemu Windows używane w zdarzeniach debugowania w kanałach debugowania Pole FlagsName preprocesora WPP systemu Windows używane w zdarzeniach debugowania w kanałach debugowania Pole KernelTime preprocesora WPP systemu Windows używane w zdarzeniach debugowania w kanałach debugowania Słowa kluczowe, które zostaną wyrenderowane dla zdarzenia Słowa kluczowe używane przez zdarzenie Zdefiniowana przez dostawcę część, która może składać się z dowolnej prawidłowej zawartości XML komunikującej informacje o zdarzeniu Pole UserTime preprocesora WPP systemu Windows używane w zdarzeniach debugowania w kanałach debugowania Wersja zdarzenia Poleć książkęKup książkę 18.3. IMPLEMENTACJA FUNKCJI LOGOWANIA 151 Rysunek 18.5. Przykład wpisu w logu systemu Windows System Windows pozwala swym użytkownikom rejestrować dane audytu w dzie- więciu różnych kategoriach:  Zdarzenia logowania do kont — działania związane z uwierzytelnianiem użytkow- nika z punktu widzenia systemu, który zweryfikował próbę. Przykłady: przyznano autoryzację; żądanie żetonu uwierzytelniającego nie powiodło się; zmapowano konto do logowania; nie można zmapować konta logowania. Pojedyncze działania w tej kategorii nie dostarczają zbyt wielu danych, ale duża liczba niepowodzeń może wskazywać na trwające skanowanie portów, ataki siłowe na indywidualne konta lub rozprzestrzenianie się automatycznych eksploitów.  Zarządzanie kontami — działania administracyjne związana z tworzeniem, zarzą- dzaniem i usuwaniem indywidualnych kont i grup użytkowników. Przykłady: utwo- rzono konto użytkownika; próba zmiany hasła; usunięto konto użytkownika; dodano członka globalnej grupy bezpieczeństwa; zmieniono zasady domeny.  Dostęp do usług katalogowych — dostęp na poziomie użytkownika do dowolnego obiektu usługi Active Directory, dla którego zdefiniowano systemową listę kontroli dostępu (SACL). Lista SACL zawiera zbiór użytkowników i grup użytkowników, dla których wymagany jest szczegółowy audyt.  Zdarzenia logowania — działania związane z uwierzytelnianiem użytkownika, za- równo na komputerze lokalnym, jak i przez sieć, z poziomu systemu, z którego za- inicjowano działanie. Przykłady: pomyślne logowanie użytkownika; błąd logowania, nieznana nazwa użytkownika lub złe hasło; błąd logowania ze względu na wyłączenie konta; błąd logowania z powodu utraty ważności konta, użytkownik nieuprawniony do logowania się na tym komputerze; wylogowanie użytkownika; błąd logowania, konto zablokowane.  Dostęp do obiektów — dostęp na poziomie użytkownika do systemu plików i obiek- tów rejestru, które mają zdefiniowane systemowe listy kontroli dostępu (SACL). Zapewnia stosunkowo łatwy oraz zintegrowany z systemem operacyjnym sposób śledzenia dostępu do odczytu, jak również zmian we wrażliwych plikach. Przykłady: obiekt otwarty; obiekt usunięty. Poleć książkęKup książkę 152 ROZDZIAŁ 18. AUDYT BEZPIECZEŃSTWA  Zmiany zasad — zmiany administracyjne w zasadach dostępu, konfiguracji audytu i innych ustawieniach na poziomie systemu. Przykłady: przypisano uprawnienia użytkownika; nowa zaufana domena; zmodyfikowano politykę audytu.  Korzystanie z uprawnień — w systemie Windows istnieje pojęcie uprawnień użyt- kownika — szczegółowego zezwolenia na wykonywanie określonego zadania. Jeśli włączymy audyt korzystania z uprawnień, rejestrowane będą wszystkie przypadki dostępu użytkowników do określonych funkcji systemowych (tworzenie obiektów, debugowanie kodu wykonywalnego lub tworzenie kopii zapasowej systemu). Przykłady: dodano określone uprawnienia do tokenu dostępowego użytkownika (podczas logowania); użytkownik próbował wykonać uprzywilejowane działania usługi systemowej.  Śledzenie procesu — generuje szczegółowe informacje audytowe w momencie roz- poczynania i zakańczania procesów, aktywowania programów lub pośredniego do- stępu do obiektów. Przykłady: utworzono nowy proces; proces zakończył się; dane podlegające audytowi zostały zabezpieczone; dla danych podlegających audytowi usunięto zabezpieczenia; użytkownik próbował zainstalować usługę.  Zdarzenia systemowe — rejestruje informacje o zdarzeniach, które wpływają na dostępność i integralność systemu, w tym komunikaty podczas startu systemu oraz komunikat o zamknięciu systemu. Przykłady: system się uruchamia; system zamyka się; wyczerpanie się zasobów w podsystemie logowania; niektóre zapisy audyty zo- stały utracone; wyczyszczono log audytu. SYSLOG Syslog to uniwersalny mechanizm logowania dostępny we wszystkich wersjach systemów UNIX i Linux. Składa się z następujących elementów:  syslog() — interfejs API, do którego odwołuje się kilka standardowych narzędzi systemowych i który jest dostępny dla aplikacji.  logger — uniksowe polecenie służące do dodawania pojedynczych zapisów do loga systemowego.  /etc/syslog.conf — plik konfiguracyjny służący do kontroli logowania i routowania zdarzeń logu systemowego.  syslogd — demon systemowy służący do odbierania i routowania zdarzeń logu sys- temowego za pomocą wywołań syslog() i logger. W różnych implementacjach Uniksa dostępne są różne warianty mechanizmu syslog. Nie istnieje jednolity format logów obowiązujący dla wszystkich systemów. Mechanizm syslog dla systemu Linux przeanalizowano w rozdziale 25. W niniejszym rozdziale za- prezentujemy krótki przegląd niektórych funkcji związanych z mechanizmem syslog i przyjrzymy się protokołowi syslog. Poleć książkęKup książkę 18.3. IMPLEMENTACJA FUNKCJI LOGOWANIA 153 Podstawową usługą mechanizmu syslog w Uniksie jest możliwość przechwytywania wskazanych zdarzeń, mechanizm pamięci masowej oraz protokół przesyłania komuni- katów z innych maszyn do centralnego komputera, spełniający rolę serwera syslog. Oprócz tych podstawowych funkcji dostępne są również inne usługi, często jako pa- kiety zewnętrzne, a w niektórych przypadkach jako wbudowane moduły. Standard NIST SP 800-92 (Guide to Computer Security Log Management, z września 2006 r.) wy- szczególnia następujące najczęstsze funkcje dodatkowe:  Rozbudowane filtrowanie. Podstawowe implementacje mechanizmu syslog pozwa- lają na specyficzną obsługę wiadomości tylko w zależności od ich obiektu i priorytetu; nie pozwalają na dokładniejsze filtrowanie. Niektóre współczesne implementacje syslog oferują bardziej rozbudowane funkcje filtrowania, takie jak spersonalizowana obsługa komunikatów w zależności od hosta lub programu, który wygenerował ko- munikat, albo wyrażenia regularnego pasującego do zawartości wiadomości. Niektóre implementacje umożliwiają również zastosowanie wielu filtrów do pojedynczego komunikatu, co zapewnia bardziej złożone filtrowanie.  Analiza logów. Początkowo serwery syslog nie wykonywały żadnej analizy danych logów. Po prostu tworzyły framework danych logowania do rejestrowania i transmi- sji. Do analizy danych syslog administratorzy mogą wykorzystywać oddzielne pro- gramy dodatkowe. Niektóre implementacje mechanizmu syslog mają wbudowane ograniczone funkcjonalności analizy logów, takie jak zdolność korelowania wielu wpisów w logu.  Reakcja na zdarzenie. Niektóre implementacje syslog mogą inicjować działania w odpowiedzi na wystąpienie określonych zdarzeń. Przykłady działań obejmują wy- syłanie pułapek SNMP, ostrzeganie administratorów za pośrednictwem stron lub wiadomości e-mail oraz uruchomienie oddzielnego programu lub skryptu. Możliwe jest również utworzenie nowego komunikatu syslog, który wskazuje wykrycie okre- ślonego zdarzenia.  Alternatywne formaty komunikatów. Niektóre implementacje syslog mogą ak- ceptować dane w formatach innych niż syslog, na przykład jako pułapki SNMP. Może się to przydać do uzyskania danych zdarzeń bezpieczeństwa z hostów, które nie obsługują mechanizmu syslog i nie można tego zmienić.  Szyfrowanie plików logów. Niektóre implementacje syslog można skonfigurować tak, aby automatycznie szyfrowały pliki logów poddawane rotacji, co chroni ich po- ufność. Można to również osiągnąć za pomocą programów do szyfrowania dostęp- nych w systemie operacyjnym lub programów zewnętrznych.  Przechowywanie logów w bazie danych. W niektórych implementacjach wpisy w logach mogą być przechowywane zarówno w tradycyjnych plikach syslog, jak i w bazie danych. Przechowywanie wpisów logów w formacie bazy danych może być bardzo pomocne do późniejszej analizy. Poleć książkęKup książkę 154 ROZDZIAŁ 18. AUDYT BEZPIECZEŃSTWA  Ograniczanie tempa zapisu. Niektóre implementacje pozwalają ograniczać liczbę komunikatów syslog lub połączeń TCP z określonego źródła w podanym przedziale czasu. Jest to przydatne w zapobieganiu atakom DoS przeciwko serwerowi syslog, co mogłoby prowadzić do utraty komunikatów syslog z innych źródeł. Ponieważ tech- nika ta służy do celowego pomijania wiadomości ze źródła, które przytłacza serwer syslog, to podczas niekorzystnego zdarzenia, które generuje niezwykle dużą liczbę komunikatów, może prowadzić do utraty niektórych danych logu. Protokół syslog zapewnia transport umożliwiający wysyłanie w sieciach IP komuni- katów z powiadomieniami o zdarzeniach do mechanizmów zbierania komunikatów o zdarzeniach — znanych również jako serwery syslog. W ramach systemu możemy przeglądać proces przechwytywania i rejestrowania zdarzeń w kontekście różnych apli- kacji i obiektów systemowych wysyłających komunikaty do demona syslogd w celu ich zapisania w logu systemowym. Ponieważ każdy proces, aplikacja i implementacja sys- temu operacyjnego Unix może stosować inną konwencję formatowania dla rejestrowa- nych zdarzeń, protokół syslog udostępnia tylko bardzo ogólny format komunikatu do transmisji między systemami. Popularną wersję protokołu syslog bazującą na protokole TCP/IP pierwotnie opracowano dla dystrybucji BSD stworzonej na Uniwersytecie Kalifornijskim w Berkeley) systemu Unix. Wersję tę udokumentowano w dokumencie RFC 3164 (The BSD Syslog Protocol z 2001 roku). Następnie organizacja IETF opubli- kowała RFC 5424 (The Syslog Protocol, 2009), który ma być standardem internetowym i który różni się pewnymi szczegółami od wersji BSD. W dalszej części tego rozdziału opiszemy wersję BSD. Komunikaty w formacie syslog dystrybucji BSD składają się z trzech części:  PRI — składa się z kodu reprezentującego opisane później wartości komunikatu: funkcje (ang. facilities) i istotność (ang. severity).  Nagłówek — zawiera znacznik czasu i informacje o nazwie hosta lub adresie IP urządzenia.  Msg — składa się z dwóch pól: pole TAG to nazwa programu lub procesu, który wy- generował komunikat; CONTENT zawiera szczegóły wiadomości. Część Msg tradycyjnie była dowolnym komunikatem złożonym z drukowalnych znaków, który dostarcza pewnych, szczegółowych informacji o zdarzeniu. Kilka przykładów komunikatów syslog, z których wyłączono fragment PRI, pokazano na rysunku 18.6. Wszystkie wiadomości wysyłane do demona syslogd zawierają informacje o funkcji i istotności (patrz tabela 18.5). Funkcja identyfikuje aplikację lub komponent systemu, który wygenerował komunikat. Poleć książkęKup książkę 18.3. IMPLEMENTACJA FUNKCJI LOGOWANIA 155 Rysunek 18.6. Przykłady komunikatów syslog Tabela 18.5. Funkcje i poziomy istotności uniksowego mechanizmu Syslog (a) Funkcje Syslog Funkcja kern user mail daemon auth Syslogd lpr news uucp clock ftp ntp log audit log alert local0 – local7 Opis komunikatu (wygenerowany przez) jądro systemu proces użytkownika system e-mail demon systemowy, na przykład ftpd programy autoryzacyjne login, su i getty komunikaty generowane wewnętrznie przez demona syslogd system drukowania system News UseNet podsystem UUCP demon zegara demon FTP podsystem NTP zarezerwowany do użytku systemowego zarezerwowany do użytku systemowego do 8 zdefiniowanych lokalnie kategorii (b) poziomy istotności Syslog Istotność emerg alert crit err warning notice info debug Opis Najbardziej istotne komunikaty, na przykład natychmiastowe zamknięcie systemu Sytuacje w systemie wymagające natychmiastowej uwagi Sytuacje o znaczeniu krytycznym, takie jak awaria sprzętu lub oprogramowania Inne błędy systemowe; łatwe do naprawy Komunikaty ostrzegawcze Sytuacja nadzwyczajna, która zasługuje na zbadanie; znaczące zdarzenie, które zwykle jest częścią normalnej, codziennej pracy Komunikaty informacyjne Komunikaty do celów diagnostycznych Poleć książkęKup książkę 156 ROZDZIAŁ 18. AUDYT BEZPIECZEŃSTWA Istotność lub poziom komunikatu wskazuje względną ważność komunikatu. Można jej użyć do podstawowego filtrowania. Logowanie na poziomie aplikacji Aplikacje, szczególnie te wymagające określonego poziomu uprawnień, stwarzają pro- blemy bezpieczeństwa, które mogą nie zostać przechwycone przez dane audytu na po- ziomie systemu lub użytkownika. Słabe punkty aplikacji stanowią duży procent luk w zabezpieczeniach zgłaszanych na listach mailingowych. Rodzajem luki, który może być wykorzystany przez złośliwe oprogramowanie, jest brak dynamicznej kontroli da- nych wprowadzanych przez użytkownika, co umożliwia przepełnienie bufora (patrz rozdział 10). Przyczyną innych luk w zabezpieczeniach mogą być także błędy w logice aplikacji. Na przykład aplikacja z uprzywilejowanymi uprawnieniami może odczytywać i drukować określony plik. Błąd w aplikacji może pozwolić napastnikowi na skorzystanie z nieoczekiwanej interakcji ze środowiskiem powłoki, aby zmusić aplikację do odczytu i wydrukowania innego pliku, co skutkuje naruszeniem bezpieczeństwa. Audyt na poziomie systemu nie zapewnia szczegółowości pozwalającej na wychwy- cenie błędu w logice aplikacji. Ponadto systemy wykrywania intruzów szukają sygnatur ataków lub nietypowych zachowań, które w przypadku ataków bazujących na błędach w logice aplikacji nie pojawią się. Zarówno z punktu widzenia możliwości wykrycia, jak i audytu może być konieczne szczegółowe zbadanie zachowania
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Bezpieczeństwo systemów informatycznych. Zasady i praktyka. Wydanie IV. Tom 2
Autor: ,
Sklep
Format
Cena
Helion.pl Helion.pl
książka
99,00 zł
Idź do sklepu »

Opinie na temat publikacji:

Inne popularne pozycje z tej kategorii:

Czytaj również:

Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: