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)