dodatek B

Dodatek B

Szablony planu zabezpieczeń Plan zabezpieczeń głównej aplikacji Identyfikacja systemu Data.

Nazwa systemu Unikalny identyfikator i nazwa przyznana dla systemu.

Odpowiedzialna organizacja Organizacja odpowiedzialna za system.

Informacje kontaktowe Nazwisko osoby znającej system lub właściciela systemu:
nazwisko,
stanowisko,
adres,
telefon,
adres e-mail.

Przydział odpowiedzialności za zabezpieczenia Nazwisko osoby odpowiedzialnej za bezpieczeństwo systemu:
nazwisko,
stanowisko,

D:\KISIU\PDFy\Chudy\KsiąŜki\Hack wars doc\hack wars tom 2 [ PL ]\hack wars tom 2 [ PL ]\dodatek B.doc

357

358

Hack Wars. Tom 2. Na tropie hakerów
adres,
telefon,
adres e-mail.

Status operacyjny systemu Jeśli wybrano więcej niŜ jeden status, naleŜy podać części systemu, jakie obejmuje dany status:
operacyjny;
w konstrukcji;
przechodzi powaŜną modyfikację.

Ogólny opis i cele
Opisać funkcję lub cel aplikacji oraz przetwarzane przez nią informacje.
Opisać proces przetwarzania przez aplikację od wejścia do systemu do wyjścia

z niego.
Opisać sposób organizacji uŜytkowników (wewnętrznych i zewnętrznych)

oraz obsługiwany typ danych i przetwarzania.

Środowisko systemu
Przedstawić ogólny opis techniczny systemu. NaleŜy dołączyć opis wszystkich

czynników środowiskowych i technicznych, które budzą pewne zastrzeŜenia pod względem zabezpieczeń (takie jak połączenia modemowe, otwarta sieć itp.).
Opisać główną platformę komputerową oraz podstawowe komponenty

systemu, włączając w to osprzęt, oprogramowanie oraz zasoby komunikacyjne.
Dołączyć informacje o wszystkich programach chroniących system i informacje.

Połączenia systemu i współdzielenie informacji
Podać listę połączonych systemów oraz ich identyfikatory (jeśli stosowane).
W przypadku połączenia z zewnętrznym systemem, który nie jest objęty

przez plan zabezpieczeń, naleŜy krótko omówić wszystkie niezbędne kwestie związane z zabezpieczeniami.
Przed połączeniem z innymi systemami oraz współdzieleniem wraŜliwych

danych i informacji naleŜy uzyskać pisemną autoryzację. Opisać zasady zachowania, które muszą być zachowane w połączonych systemach. Do planu zabezpieczeń dołączyć opis tych zasad lub omówić je w tej sekcji.

Prawo, regulacje i zasady mające wpływ na system
Zamieścić listę wszystkich praw, regulacji i zasad, które ustanawiają

konkretne wymagania wobec poufności, integralności i dostępności informacji i danych w systemie.

358

D:\KISIU\PDFy\Chudy\KsiąŜki\Hack wars doc\hack wars tom 2 [ PL ]\hack wars tom 2 [ PL ]\dodatek B.doc

Dodatek B ♦ Szablony planu zabezpieczeń

359

Ogólny opis wraŜliwości informacji
Ogólnie opisać informacje obsługiwane przez system, a takŜe konieczność

wprowadzenia środków ochronnych. Te informacje muszą się odnosić do wszystkich trzech podstawowych wymagań dotyczących zabezpieczeń — dostępności, integralności i poufności. Dla kaŜdej z trzech kategorii (dostępności, integralności i poufności) wskazać, czy wymagania pod względem zabezpieczeń są wysokie, średnie lub niskie.
Dołączyć oszacowanie ryzyka oraz wielkości szkód spowodowanych

przez utratę, niewłaściwe uŜycie, nieautoryzowany dostęp lub modyfikację informacji w systemie.

Kontrola kierownicza Ocena i zarządzanie ryzykiem
Opisać metodologię oceny poziomu ryzyka, jaka została uŜyta do identyfikacji

zagroŜeń i słabych stron systemu. Dołączyć datę wykonania oceny ryzyka systemu. Jeśli dla danego systemu nie wykonano oceny ryzyka, naleŜy dołączyć datę (miesiąc i rok) przewidywanego wykonania takiej analizy.

Przegląd środków kontroli zabezpieczeń
Wymienić wszystkie niezaleŜne przeglądy zabezpieczeń systemu, jakie

zostały wykonane w ciągu ostatnich trzech lat.
Dołączyć informacje o typie wykonywanej oceny zabezpieczeń i osobie,

która ją przeprowadzała, a takŜe przedstawić cel badania, jego wyniki oraz działania, które zostały podjęte dzięki badaniu.

Zasady zachowania
Dla kaŜdego systemu naleŜy utworzyć pisemny zestaw zasad zachowania.

Zasady zachowania powinny być udostępnione wszystkim uŜytkownikom, zanim uzyskają dostęp do systemu. Zaleca się, aby zasady zawierały stronę z podpisami, na której uŜytkownik musi potwierdzić odbiór zasad.
Jasno zdefiniować odpowiedzialność i oczekiwania względem wszystkich

osób, które uzyskują dostęp do systemu. W zasadach naleŜy zawrzeć informacje o konsekwencjach niewłaściwego zachowania lub nieprzestrzegania zasad. Dołączyć niezbędne limity połączeń z innymi systemami.
Jako załącznik umieścić zasady zachowania dla systemu, a w tej sekcji

powinien znaleźć się numer właściwego załącznika. MoŜliwe jest takŜe dołączenie zasad do tej sekcji.

Planowanie zabezpieczeń w cyklu Ŝycia
Ustalić fazę (fazy) cyklu Ŝycia systemu lub jego poszczególnych części.

D:\KISIU\PDFy\Chudy\KsiąŜki\Hack wars doc\hack wars tom 2 [ PL ]\hack wars tom 2 [ PL ]\dodatek B.doc

359

360

Hack Wars. Tom 2. Na tropie hakerów
Opisać sposób zapewnienia bezpieczeństwa w fazie (fazach) cyklu Ŝycia,

w której obecnie znajduje się system.

Faza inicjacji
Umieścić odnośnik do oceny wraŜliwości znajdującej się w sekcji WraŜliwość

przechowywanych informacji.

Faza rozwoju i przejęcia
Czy w czasie projektowania systemu zidentyfikowano wymagania pod

względem bezpieczeństwa?
Czy przed dostarczeniem systemu stworzono odpowiednie kontrole

zabezpieczeń wraz z powiązanymi procedurami badania i testowania?
Czy dokumenty ofertowe (na przykład zapytanie ofertowe) zawierały wymagania

pod względem zabezpieczeń oraz procedur badawczych i testowych?
Czy te wymagania umoŜliwiają aktualizację zabezpieczeń w razie pojawienia

się nowych zagroŜeń i słabych punktów oraz w przypadku wdroŜenia nowych technologii?
Jeśli zakupiono komercyjną aplikację lub jeśli aplikacja zawiera typowe

komercyjne programy, to czy zidentyfikowano i dołączono do specyfikacji przejęcia ich wymagania wobec zabezpieczeń?

Faza implementacji
Czy wykonano przegląd projektu oraz testy systemowe przed rozpoczęciem

pracy przez system? Czy testy zostały w pełni udokumentowane? Czy system otrzymał niezbędne certyfikaty?
Czy po zakończeniu projektowania dodano jakieś środki kontroli zabezpieczeń?
Czy aplikacja przeszła badania techniczne w celu sprawdzenia, czy spełnia

wymagania pod względem prawa, regulacji, zasad i standardów?
Czy aplikacja uzyskała certyfikaty i akredytacje? Kiedy? Jeśli system nie

uzyskał jeszcze autoryzacji, podać datę wysłania prośby o autoryzację.

Faza działania i obsługi Plan zabezpieczeń dokumentuje czynności zabezpieczające wymagane w tej fazie.

Faza usuwania
W jaki sposób informacje są przenoszone do innego systemu, archiwizowane,

usuwane lub niszczone? Omówić środki kontroli uŜywane do zapewnienia poufności informacji.
Czy wraŜliwe dane są szyfrowane?
W jaki sposób informacje są usuwane i kasowane z systemu?

360

D:\KISIU\PDFy\Chudy\KsiąŜki\Hack wars doc\hack wars tom 2 [ PL ]\hack wars tom 2 [ PL ]\dodatek B.doc

Dodatek B ♦ Szablony planu zabezpieczeń

361


Czy informacje lub nośniki są oczyszczane, nadpisywane,

rozmagnesowywane czy niszczone?

Autoryzacja działania
Podać datę autoryzacji, nazwisko i stanowisko menedŜera, który autoryzuje

przetwarzanie informacji w systemie.
Jeśli nie uzyskano autoryzacji, podać nazwisko i stanowisko menedŜera,

który prosi o zgodę na działanie oraz datę tej prośby.

Kontrola operacyjna Bezpieczeństwo personelu
Czy wszystkie stanowiska zostały zbadane pod kątem poziomu wraŜliwości?
Czy wszyscy uŜytkownicy odbyli szkolenie odpowiadające stanowisku, które

zostało im przydzielone?
Czy dostęp uŜytkowników został ograniczony do minimalnego poziomu,

wymaganego do wykonania pracy?
Czy istnieje system zamawiania, zakładania, wydawania i zamykania kont

uŜytkowników?
Czy krytyczne funkcje zostały rozdzielone między róŜne osoby (podział

obowiązków)?
Jakie mechanizmy zastosowano, aby uŜytkownicy byli odpowiedzialni

za swoje postępowanie? Opisać te mechanizmy.
Jakie są procedury przyjaznego i nieprzyjaznego zakończenia procesu?

Ochrona fizyczna i środowiskowa Opisać fizyczne zabezpieczenia obszaru, na którym aplikacja wykonuje przetwarzanie informacji (na przykład blokady terminali, ogrodzenie wokół budynków lub terenów organizacji itp.). NaleŜy omówić takie czynniki, jak kontrola dostępu, bezpieczeństwo poŜarowe, awaria systemów wsparcia, zawalenie budynku, awaria kanalizacji, przechwycenie danych oraz systemy mobilne i przenośne.

Kontrola produkcyjna oraz kontrola wejścia i wyjścia Opisać środki kontroli uŜywane do oznaczania, klasyfikowania, przetwarzania, przechowywania oraz usuwania informacji i nośników wejściowych i wyjściowych, a takŜe procedury etykietowania i dystrybucji informacji oraz nośników. Przedstawić listę środków kontroli do monitowania instalacji i aktualizacji oprogramowania aplikacji. Zamieścić opis stosowanych procedur, które obsługują działanie aplikacji. PoniŜej znajduje się kilka przykładów tematów, które powinny zostać omówione.
Wsparcie dla uŜytkowników: Czy istnieje komórka lub grupa ludzi zajmująca

się pomocą uŜytkownikom, która potrafi udzielić porady lub zareagować

D:\KISIU\PDFy\Chudy\KsiąŜki\Hack wars doc\hack wars tom 2 [ PL ]\hack wars tom 2 [ PL ]\dodatek B.doc

361

362

Hack Wars. Tom 2. Na tropie hakerów

na naruszenie bezpieczeństwa w określonym terminie? Czy istnieją procedury, takie jak opisane poniŜej, które dokumentują sposób rozpoznawania, rozwiązywania i raportowania takich zdarzeń lub problemów?
Procedury, dzięki którym nieautoryzowane osoby nie mogą odczytać, skopiować,

zmienić ani ukraść wydrukowanych lub elektronicznych informacji.
Procedury, dzięki którym tylko autoryzowani uŜytkownicy mogą pobrać,

odebrać lub dostarczyć informacje wejściowe i wyjściowe oraz nośniki.
Śledzenie odbioru waŜnych danych wejściowych i wyjściowych.
Procedury ograniczające dostęp do urządzeń wyjściowych.
Procedury i środki kontroli przy transporcie lub wysyłce nośników i wydruków.
Zewnętrzny lub wewnętrzny system znakowania wraŜliwości informacji.
Zewnętrzny system znakowania z instrukcjami dotyczącymi sposobu

traktowania (na przykład identyfikatory dziennika lub inwentarza, kontrolowany dostęp, specjalne instrukcje dotyczące przechowywania, daty wysłania lub zniszczenia).
Kontrola śladów do celów zarządzania inwentarzem.
Procedury i środki kontroli fizycznej i środowiskowej ochrony miejsca

przechowywania nośników i biblioteki.
Procedury czyszczenia nośników elektronicznych w celu ponownego uŜycia

(na przykład nadpisanie lub rozmagnesowanie nośników elektronicznych).
Procedury kontrolowanego przechowywania, obsługi i zniszczenia

uszkodzonych nośników lub takich, które nie mogą być wyczyszczone w celu ponownego uŜycia.
Procedury fizycznego zniszczenia wydruków, które nie są juŜ potrzebne.

Planowanie awaryjne Krótko opisać procedury (plan zapasowy), które pozwolą na kontynuację działania aplikacji, jeśli system obsługi IT stanie się niedostępny. Jeśli formalny plan zapasowy został w pełni utworzony, naleŜy umieścić odnośnik do niego. Kopia planu zapasowego moŜe być dołączona jako załącznik. W tej sekcji naleŜy dołączyć wymienione poniŜej elementy.
Wszystkie umowy dotyczące obsługi archiwizacji (na przykład kontrakt

z komercyjnym dostawcą usług).
Udokumentowane procedury archiwizacji, włączając ich częstotliwość

(codziennie, tygodniowo, miesięcznie) oraz zakres (pełna kopia awaryjna, kopia przyrostowa lub róŜnicowa).
Miejsce przechowywania kopii zapasowych oraz liczbę utrzymywanych

generacji kopii zapasowych.

362

D:\KISIU\PDFy\Chudy\KsiąŜki\Hack wars doc\hack wars tom 2 [ PL ]\hack wars tom 2 [ PL ]\dodatek B.doc

Dodatek B ♦ Szablony planu zabezpieczeń

363


Czy istnieją przetestowane plany zapasowe na wypadek wystąpienia groźnego

zdarzenia? Jak często są testowane?
Czy wszyscy pracownicy zostali przeszkoleni w zakresie swoich ról

i odpowiedzialności pod względem planów awaryjnych, ratunkowych i na wypadek katastrofy?
Zasięg procedur archiwizacji (na przykład, co jest archiwizowane).

Kontrola obsługi oprogramowania
Czy oprogramowanie zostało napisane w firmie lub na zamówienie?
Czy oprogramowanie naleŜy do organizacji? Czy oprogramowanie zostało

otrzymane z innego biura?
Czy oprogramowanie jest produktem komercyjnym, objętym prawami

autorskimi, lub typu shareware? Czy zakupiono wystarczająco duŜo licencji dla wszystkich systemów, na których będzie wykorzystywana ta aplikacja?
Czy istnieje formalny proces kontroli zmian dla aplikacji; a jeśli tak,

czy wymaga on przetestowania i zatwierdzenia wszystkich zmian w oprogramowaniu, zanim zostanie ono wdroŜone do uŜycia?
Czy dane testowe były danymi rzeczywistymi, czy spreparowanymi?
Czy wszystkie zmiany w oprogramowaniu są udokumentowane?
Czy wszystkie wyniki testów zostały udokumentowane?
Czy zainstalowano wszystkie niezbędne poprawki?
Czy zasady organizacji nie pozwalają na nielegalne uŜycie oprogramowania

objętego prawami autorskimi lub typu shareware?
Czy wykonywane są okresowe kontrole komputerów uŜytkowników pod

względem instalacji tylko legalnych kopii programów, na które posiadana jest licencja?
Jakie programy i procedury są wykorzystywane w celu zabezpieczenia przed

nielegalnym uŜyciem oprogramowania?
Czy istnieje zarządzanie gwarancjami na oprogramowanie w celu

minimalizacji kosztów aktualizacji, uzyskania zwrotu kosztów lub wymiany wadliwych produktów?

Kontrola waŜności i integralności danych
Czy zainstalowano oprogramowanie do wykrywania i eliminacji wirusów?

Jeśli tak, to czy istnieją procedury do aktualizacji plików podpisów wirusów, automatycznego lub ręcznego skanowania antywirusowego oraz usuwania wirusów i tworzenia raportów?
Czy stosowane są przez system procedury kontrolne — na przykład sumy

kontrolne, sumy hash i liczniki rekordów? NaleŜy dołączyć opis działań podjętych w celu usunięcia wszelkich niezgodności.

D:\KISIU\PDFy\Chudy\KsiąŜki\Hack wars doc\hack wars tom 2 [ PL ]\hack wars tom 2 [ PL ]\dodatek B.doc

363

364

Hack Wars. Tom 2. Na tropie hakerów
Czy uŜywane są narzędzia do sprawdzania i łamania haseł?
Czy aplikacje korzystają z programów do weryfikacji integralności w celu

wyszukania dowodów na manipulację danymi, błędów oraz pominięć?
Czy w systemie zainstalowano narzędzia do wykrywania włamań?
Czy uŜywana jest funkcja monitorowania wydajności systemu w celu analizy

dzienników wydajności systemu w czasie rzeczywistym, wyszukiwania problemów z dostępnością (włączając w to aktywne ataki) oraz awarii lub spowolnienia pracy systemu i sieci?
Czy w systemie są wykonywane testy penetracji? Jeśli tak, to jakie procedury

są stosowane w celu zapewnienia prawidłowego wykonywania takich testów?
Czy aplikacja uŜywa funkcji uwierzytelniania wiadomości w celu upewnienia

się, czy nadawca wiadomości jest znany, a wiadomość nie została zmieniona w czasie transmisji?

Dokumentacja Dokumentacja systemu obejmuje opisy sprzętu i programów, zasady, standardy, procedury oraz akceptacje odnoszące się do bezpieczeństwa zautomatyzowanego systemu informatycznego (aplikacja oraz system obsługi, na którym jest ona wykonywana). NaleŜy tu takŜe dołączyć opis procedur archiwizacji oraz planu zapasowego, a takŜe opis procedur uŜytkownika i operatora.
Przedstawić listę dokumentacji aplikacji (dokumentacja sprzętu i programów

od producenta, wymagania funkcjonalne, plan zabezpieczeń, plan zabezpieczeń systemu ogólnego wsparcia, podręczniki aplikacji, dokumentacja wyników testów, standardowe procedury operacyjne, procedury awaryjne, plany zapasowe, zasady i procedury uŜytkownika, ocena ryzyka, dokumenty i oświadczenia o certyfikatach i akredytacji, przeglądy weryfikacyjne i inspekcje).

Znajomość zabezpieczeń i szkolenia
Opisać program świadomości aplikacji (plakaty, foldery i inne).
Opisać typ i częstotliwość szkoleń w zakresie obsługi danej aplikacji i systemu

ogólnego wsparcia, przeprowadzanych dla pracowników oraz osób współpracujących (seminaria, warsztaty, zajęcia w klasach, grupy dyskusyjne, odgrywanie ról oraz szkolenie w trakcie pracy).
Opisać procedurę sprawdzania, czy pracownicy i osoby współpracujące

przeszły niezbędne szkolenia.

Kontrola techniczna Identyfikacja i uwierzytelnianie
Opisać mechanizmy kontroli uwierzytelniania dla głównej aplikacji.
Opisać metodę uwierzytelniania uŜytkowników (hasło, token lub cechy

biometryczne).

364

D:\KISIU\PDFy\Chudy\KsiąŜki\Hack wars doc\hack wars tom 2 [ PL ]\hack wars tom 2 [ PL ]\dodatek B.doc

Dodatek B ♦ Szablony planu zabezpieczeń

365


Jeśli stosowany jest system haseł, podać następujące informacje:


dozwolony zestaw znaków;




długość hasła (minimalna i maksymalna);




okres upływu waŜności hasła oraz sposób wymuszania jego zmiany;




liczba niedozwolonych generacji starych haseł;




procedury zmiany hasła;




procedury obsługi zagubionych haseł;




procedury obsługi naruszenia systemu haseł.


Wskazać częstotliwość zmiany haseł, opisać sposób wymuszenia zmiany

hasła (na przykład przez program lub administratora systemu) oraz podać osobę, która zmienia hasło (uŜytkownik, system lub administrator systemu).
Opisać sposób obsługi poszczególnych kont i kontroli śladów (na przykład,

czy hasła są powiązane z identyfikatorem uŜytkownika, który jest przydzielony tylko dla jednej osoby) przez mechanizm kontroli dostępu.
Opisać techniki własnego zabezpieczenia mechanizmu uwierzytelniania

uŜytkownika (na przykład, czy hasła są przesyłane i przechowywane przy uŜyciu jednokierunkowego szyfrowania tak, Ŝe nikt, włączając w to administratora, nie moŜe odczytać haseł w czystym tekście; czy hasła są generowane automatycznie; czy hasła są porównywane ze słownikiem niedozwolonych haseł; czy hasła są szyfrowane w czasie przesyłania).
Podać liczbę nieudanych prób dostępu, jaka moŜe wystąpić dla danego

identyfikatora uŜytkownika lub miejsca dostępu (terminal lub port), a takŜe opisać działania, jakie zostaną podjęte po przekroczeniu limitu.
Opisać procedurę weryfikacji, czy zostały zmienione wszystkie domyślne

hasła administratorów, które ustawiono systemowo.
Opisać procedury ograniczania skryptów dostępowych z dołączonym hasłem

(na przykład, czy skrypty z dołączonym hasłem są zabronione lub dozwolone tylko dla aplikacji wsadowych).
Opisać wszystkie zasady, które pozwalają na pominięcie wymagań

dotyczących uwierzytelniania uŜytkownika, technologie „pojedynczego podpisu” (na przykład bezpośrednie połączenie dwóch komputerów, serwery uwierzytelniania, identyfikator „uŜytkownik do hosta” oraz identyfikatory grup uŜytkowników), a takŜe wszystkie środki kontroli naruszenia uwierzytelniania.
Czy uŜywane są podpisy cyfrowe, czy elektroniczne? Jeśli tak, naleŜy opisać

uŜywane standardy a takŜe procedury zarządzania kluczami — generowanie, dystrybucja, przechowywanie i usuwanie.

Logiczna kontrola dostępu
Omówić środki kontroli, które są stosowane do autoryzacji lub ograniczenia

działalności uŜytkowników i personelu systemowego w ramach aplikacji. Opisać funkcje sprzętu lub oprogramowania, które zostały utworzone w celu

D:\KISIU\PDFy\Chudy\KsiąŜki\Hack wars doc\hack wars tom 2 [ PL ]\hack wars tom 2 [ PL ]\dodatek B.doc

365

366

Hack Wars. Tom 2. Na tropie hakerów

umoŜliwienia tylko autoryzowanego dostępu do aplikacji lub wewnątrz niej, do ograniczenia działań uŜytkowników tylko do autoryzowanych transakcji i funkcji, a takŜe do wykrywania nieautoryzowanych działań (na przykład listy kontroli dostępu ACL).
Opisać sposób przyznawania uprawnień dostępowych. Czy przywileje są

przydzielane w oparciu o wykonywane zadania?
Opisać moŜliwość utworzenia przez aplikację listy kontroli dostępu ACL

lub rejestru.
Opisać sposób, w jaki ogranicza się uŜytkownikom aplikacji dostęp do

systemu operacyjnego, innych aplikacji lub innych zasobów systemowych, które nie są wymagane podczas wykonywania przez nich swoich obowiązków.
Opisać środki kontroli uŜywane do wykrywania nieautoryzowanych prób

transakcji przez autoryzowanych lub nieautoryzowanych uŜytkowników. Podać wszystkie ograniczenia, które uniemoŜliwiają uŜytkownikom uzyskanie dostępu do systemu lub aplikacji poza normalnymi godzinami pracy lub w czasie weekendów. NaleŜy wymienić zastosowane ograniczenia.
Wskazać, po jakim okresie braku aktywności uŜytkownika system automatycznie

oczyszcza wyświetlany obraz, a po jakim czasie system automatycznie odłącza nieaktywnych uŜytkowników lub wymaga od nich ponownego podania unikalnego hasła w celu przyłączenia do systemu lub aplikacji.
Wskazać, czy jest stosowane szyfrowanie jako część procedur kontroli

dostępu do systemu lub aplikacji w celu uniemoŜliwienia nieautoryzowanego dostępu do wraŜliwych plików.
Uzasadnić decyzję o uŜyciu banerów ostrzegawczych lub ich braku; dołączyć

przykłady uŜywanych banerów.

Kontrola dostępu publicznego Jeśli osoby z zewnątrz uzyskują dostęp do głównej aplikacji, naleŜy opisać zastosowane dodatkowe środki kontroli, uŜywane do zabezpieczenia integralności aplikacji oraz zabezpieczenia przetwarzanych informacji. Takie środki kontroli obejmują rozdzielenie informacji udostępnianych osobom z zewnątrz od oficjalnych plików organizacji. Inne środki kontroli mogą obejmować:
pewną formę identyfikacji i uwierzytelniania;
kontrolę dostępu w celu ograniczenia elementów, jakie uŜytkownik moŜe

czytać, zapisywać, modyfikować lub usuwać;
środki kontroli uniemoŜliwiające uŜytkownikom z zewnątrz modyfikację

informacji w systemie;
podpisy cyfrowe;
płytę CD-ROM z informacjami, które mają być dystrybuowane na zewnątrz;
umieszczenie w oddzielnym systemie kopii informacji do publicznego dostępu;
ograniczenie osobom z zewnątrz dostępu do działających baz danych;

366

D:\KISIU\PDFy\Chudy\KsiąŜki\Hack wars doc\hack wars tom 2 [ PL ]\hack wars tom 2 [ PL ]\dodatek B.doc

Dodatek B ♦ Szablony planu zabezpieczeń

367


weryfikację czy udostępniane na zewnątrz programy i informacje są wolne

od wirusów;
kontrolę śladów oraz poufność uŜytkowników;
dostępność systemu i danych;
analizę prawną.

Śledzenie śladów
Czy funkcja śledzenia śladów współpracuje z funkcją obsługi kont, dzięki

czemu moŜna uzyskać zapis działań uŜytkownika?
Czy funkcja śledzenia śladów obejmuje wystarczająco duŜo informacji,

aby ustalić typ zdarzeń i ich sprawcę? NaleŜy tu umieścić typ zdarzenia, datę wystąpienia zdarzenia, identyfikator uŜytkownika powiązany ze zdarzeniem oraz program lub polecenie uŜyte do rozpoczęcia zdarzenia.
Czy dostęp do dzienników funkcji śledzenia jest ściśle kontrolowany?
Czy zapewniona jest poufność informacji funkcji śledzenia śladów, jeśli

na przykład są zapisywane osobiste dane uŜytkowników?
Jak często są przeglądane dane funkcji śledzenia śladów? Czy istnieją zasady

takiego przeglądu?
Czy właściwy administrator na poziomie systemu lub aplikacji przegląda

dane funkcji śledzenia śladów, badając znany problem systemu albo aplikacji, znany przypadek naruszenia istniejących wymagań przez uŜytkownika lub niewyjaśniony problem związany z systemem lub uŜytkownikiem?

Plan zabezpieczeń systemu ogólnego wsparcia Identyfikacja systemu Data.

Nazwa systemu Unikalny identyfikator i nazwa przyznana dla systemu.

Odpowiedzialna organizacja Organizacja odpowiedzialna za system.

Informacje kontaktowe Nazwisko osoby znającej system lub właściciela systemu:
nazwisko,
stanowisko,

D:\KISIU\PDFy\Chudy\KsiąŜki\Hack wars doc\hack wars tom 2 [ PL ]\hack wars tom 2 [ PL ]\dodatek B.doc

367

368

Hack Wars. Tom 2. Na tropie hakerów
adres,
telefon,
adres e-mail.

Przydział odpowiedzialności za zabezpieczenia Nazwisko osoby odpowiedzialnej za bezpieczeństwo systemu:
nazwisko,
stanowisko,
adres,
telefon,
adres e-mail.

Status operacyjny systemu Jeśli wybrano więcej niŜ jeden status, naleŜy podać części systemu, jakie obejmuje dany status:
operacyjny;
w konstrukcji;
przechodzi powaŜną modyfikację.

Ogólny opis i cele
Opisać funkcję lub cel systemu oraz przetwarzane przez niego informacje.
Opisać proces przetwarzania przez aplikację od wejścia do systemu do wyjścia

z niego.
Opisać sposób organizacji uŜytkowników (wewnętrznych i zewnętrznych)

oraz obsługiwany typ danych i przetwarzania.
Przedstawić listę wszystkich aplikacji obsługiwanych przez system ogólnego

wsparcia. Opisać funkcje kaŜdej aplikacji oraz przetwarzane przez nią informacje.

Środowisko systemu
Przedstawić ogólny opis techniczny systemu. NaleŜy dołączyć opis wszystkich

czynników środowiskowych i technicznych, które budzą pewne zastrzeŜenia pod względem zabezpieczeń (takie jak połączenia modemowe, otwarta sieć itp.).
Opisać główną platformę komputerową oraz podstawowe komponenty

systemu, włączając w to osprzęt, oprogramowanie oraz zasoby komunikacyjne.
Dołączyć informacje o wszystkich programach chroniących system

i informacje.

368

D:\KISIU\PDFy\Chudy\KsiąŜki\Hack wars doc\hack wars tom 2 [ PL ]\hack wars tom 2 [ PL ]\dodatek B.doc

Dodatek B ♦ Szablony planu zabezpieczeń

369

Połączenia systemu i współdzielenie informacji
Podać listę połączonych systemów oraz ich identyfikatory (jeśli stosowane).
W przypadku połączenia z zewnętrznym systemem, który nie jest objęty

planem zabezpieczeń, naleŜy krótko omówić wszystkie niezbędne kwestie związane z zabezpieczeniami.
Przed połączeniem z innymi systemami oraz współdzieleniem wraŜliwych

danych i informacji naleŜy uzyskać pisemną autoryzację. Opisać zasady zachowania, które muszą być zachowane przez połączone systemy. Do planu zabezpieczeń dołączyć opis tych zasad lub omówić je w tej sekcji.

Prawo, regulacje i zasady mające wpływ na system
Zamieścić listę wszystkich praw, regulacji i zasad, które ustanawiają konkretne

wymagania dotyczące poufności, integralności oraz dostępności informacji i danych w systemie.

Ogólny opis wraŜliwości informacji
Ogólnie opisać informacje obsługiwane przez system, a takŜe konieczność

wprowadzenia środków ochronnych. Te informacje muszą się odnosić do wszystkich trzech podstawowych wymagań w zakresie zabezpieczeń — dostępności, integralności i poufności. Dla kaŜdej z trzech kategorii (dostępności, integralności i poufności) wskazać, czy wymagania pod względem zabezpieczeń są wysokie, średnie lub niskie.
Dołączyć oszacowanie ryzyka oraz wielkości szkód spowodowanych

przez utratę, niewłaściwe uŜycie, nieautoryzowany dostęp lub modyfikację informacji w systemie.

Kontrola kierownicza Ocena i zarządzanie ryzykiem
Opisać metodologię oceny poziomu ryzyka, jaka została uŜyta do identyfikacji

zagroŜeń i słabych stron systemu. Dołączyć datę wykonania oceny ryzyka systemu. Jeśli dla danego systemu nie wykonano oceny ryzyka, naleŜy dołączyć datę (miesiąc i rok) przewidywanego wykonania takiej analizy.

Przegląd środków kontroli zabezpieczeń
Wymienić wszystkie niezaleŜne przeglądy zabezpieczeń systemu, jakie

zostały wykonane w ciągu ostatnich trzech lat.
Dołączyć informacje o typie wykonywanej oceny zabezpieczeń i osobie,

która ją przeprowadzała, a takŜe przedstawić cel badania, jego wyniki oraz działania, które zostały podjęte dzięki badaniu.

D:\KISIU\PDFy\Chudy\KsiąŜki\Hack wars doc\hack wars tom 2 [ PL ]\hack wars tom 2 [ PL ]\dodatek B.doc

369

370

Hack Wars. Tom 2. Na tropie hakerów

Zasady zachowania
Dla kaŜdego systemu naleŜy utworzyć pisemny zestaw zasad zachowania.

Zasady zachowania powinny być udostępnione wszystkim uŜytkownikom, zanim uzyskają oni dostęp do systemu. Zaleca się, aby zasady zawierały stronę z podpisami, na której uŜytkownik musi potwierdzić odbiór zasad.
Jasno zdefiniować odpowiedzialność i oczekiwane zachowanie wszystkich

osób, które uzyskują dostęp do systemu. W zasadach naleŜy zawrzeć informacje o konsekwencjach niewłaściwego zachowania lub nieprzestrzegania zasad. Dołączyć niezbędne limity połączeń z innymi systemami.
Jako załącznik umieścić zasady zachowania dla systemu, a w tej sekcji

powinien znaleźć się numer właściwego załącznika. MoŜliwe jest takŜe dołączenie zasad do tej sekcji.

Planowanie zabezpieczeń w cyklu Ŝycia
Ustalić fazę (fazy) cyklu Ŝycia systemu lub jego poszczególnych części.
Opisać sposób zapewnienia bezpieczeństwa w fazie (fazach) cyklu Ŝycia,

w której obecnie znajduje się system.

Faza inicjacji
Umieścić odnośnik do oceny wraŜliwości znajdującej się w sekcji WraŜliwość

przechowywanych informacji.

Faza rozwoju i przejęcia
Czy w czasie projektowania systemu zidentyfikowano wymagania dotyczące

bezpieczeństwa?
Czy przed dostarczeniem systemu utworzono odpowiednie kontrole

zabezpieczeń wraz z powiązanymi procedurami badania i testowania?
Czy dokumenty ofertowe (na przykład zapytanie ofertowe) zawierały

wymagania dotyczące zabezpieczeń oraz procedur badawczych i testowych?
Czy te wymagania umoŜliwiają aktualizację zabezpieczeń w razie pojawienia

się nowych zagroŜeń i słabych punktów oraz w przypadku wdroŜenia nowych technologii?
Jeśli zakupiono komercyjną aplikację lub aplikacja zawiera typowe komercyjne

programy, to czy zidentyfikowano i dołączono do specyfikacji przejęcia ich wymagania wobec zabezpieczeń?

Faza implementacji
Czy wykonano przegląd projektu oraz testy systemowe przed rozpoczęciem

pracy przez system? Czy testy zostały w pełni udokumentowane? Czy system otrzymał niezbędne certyfikaty?
Czy po zakończeniu projektowania dodano jakieś środki kontroli

zabezpieczeń?

370

D:\KISIU\PDFy\Chudy\KsiąŜki\Hack wars doc\hack wars tom 2 [ PL ]\hack wars tom 2 [ PL ]\dodatek B.doc

Dodatek B ♦ Szablony planu zabezpieczeń

371


Czy aplikacja przeszła badania techniczne w celu sprawdzenia, czy spełnia

wymagania prawa, regulacji, zasad i standardów?
Czy aplikacja uzyskała certyfikaty i akredytacje? Kiedy? Jeśli system nie

uzyskał jeszcze autoryzacji, podać datę wysłania prośby o autoryzację.

Faza działania i obsługi Plan zabezpieczeń dokumentuje czynności zabezpieczające wymagane w tej fazie.

Faza usuwania
W jaki sposób informacje są przenoszone do innego systemu, archiwizowane,

usuwane lub niszczone? Omówić środki kontroli uŜywane do zapewnienia poufności informacji.
Czy wraŜliwe dane są szyfrowane?
W jaki sposób informacje są usuwane z systemu i kasowane w nim?
Czy informacje lub nośniki są oczyszczane, nadpisywane,

rozmagnesowywane czy niszczone?

Autoryzacja działania
Podać datę autoryzacji, nazwisko i stanowisko menedŜera, który autoryzuje

przetwarzanie informacji w systemie.
Jeśli nie uzyskano autoryzacji, podać nazwisko i stanowisko menedŜera, który

prosi o zgodę na działanie oraz datę tej prośby.

Kontrola operacyjna Bezpieczeństwo personelu
Czy wszystkie stanowiska zostały zbadane pod kątem poziomu wraŜliwości?
Czy wszyscy uŜytkownicy zostali przeszkoleni na poziomie stanowiska, które

im przydzielono?
Czy dostęp uŜytkowników został ograniczony do minimalnego poziomu,

wymaganego do wykonania pracy?
Czy istnieje system zamawiania, zakładania, wydawania i zamykania kont

uŜytkowników?
Czy krytyczne funkcje zostały rozdzielone między róŜne osoby (podział

obowiązków)?
Jakie mechanizmy zastosowano, aby uŜytkownicy byli odpowiedzialni

za swoje postępowanie? Opisać takie mechanizmy.
Jakie są procedury przyjaznego i nieprzyjaznego zakończenia procesu?

D:\KISIU\PDFy\Chudy\KsiąŜki\Hack wars doc\hack wars tom 2 [ PL ]\hack wars tom 2 [ PL ]\dodatek B.doc

371

372

Hack Wars. Tom 2. Na tropie hakerów

Ochrona fizyczna i środowiskowa Opisać fizyczne zabezpieczenia systemu. Opisać obszar, na którym odbywa się przetwarzanie informacji (na przykład blokady terminali, ogrodzenie wokół budynków lub terenów organizacji itp.). NaleŜy omówić takie czynniki, jak kontrola dostępu, bezpieczeństwo poŜarowe, awaria systemów wsparcia, zawalenie budynku, awaria kanalizacji, przechwycenie danych oraz systemy mobilne i przenośne.

Kontrola produkcyjna oraz kontrola wejścia i wyjścia Opisać środki kontroli uŜywane do oznaczania, traktowania, przetwarzania, przechowywania oraz usuwania informacji i nośników wejściowych i wyjściowych, a takŜe procedury etykietowania i dystrybucji informacji i nośników. Przedstawić listę środków kontroli do monitorowania instalacji i aktualizacji oprogramowania aplikacji. Zamieścić opis stosowanych procedur, które obsługują działanie aplikacji. PoniŜej znajduje się kilka przykładów tematów, które powinny zostać omówione.
Wsparcie dla uŜytkowników: Czy istnieje komórka lub grupa ludzi zajmująca

się pomocą dla uŜytkowników?
Procedury, dzięki którym nieautoryzowane osoby nie mogą odczytać,

skopiować, zmienić ani ukraść wydrukowanych lub elektronicznych informacji.
Procedury, dzięki którym tylko autoryzowani uŜytkownicy mogą pobrać,

odebrać lub dostarczyć informacje wejściowe i wyjściowe oraz nośniki.
Śledzenie odbioru waŜnych danych wejściowych i wyjściowych.
Procedury ograniczające dostęp do urządzeń wyjściowych.
Procedury i środki kontroli przy transporcie lub wysyłce nośników i wydruków.
Zewnętrzny lub wewnętrzny system znakowania wraŜliwości informacji.
Zewnętrzny system znakowania z instrukcjami dotyczącymi sposobu

traktowania (na przykład identyfikatory dziennika lub inwentarza, kontrolowany dostęp, specjalne instrukcje dotyczące przechowywania, data wysłania lub zniszczenia).
Kontrola śladów do celów zarządzania inwentarzem.
Procedury i środki kontroli fizycznej i środowiskowej ochrony miejsca

przechowywania nośników i biblioteki.
Procedury czyszczenia nośników elektronicznych w celu ponownego uŜycia

(na przykład nadpisanie lub rozmagnesowanie nośników elektronicznych).
Procedury kontrolowanego przechowywania, obsługi i zniszczenia uszkodzonych

nośników lub takich, które nie mogą być wyczyszczone w celu ponownego uŜycia.
Procedury fizycznego zniszczenia wydruków, które nie są juŜ potrzebne.

372

D:\KISIU\PDFy\Chudy\KsiąŜki\Hack wars doc\hack wars tom 2 [ PL ]\hack wars tom 2 [ PL ]\dodatek B.doc

Dodatek B ♦ Szablony planu zabezpieczeń

373

Planowanie awaryjne Krótko opisać procedury (plan zapasowy), które pozwolą na kontynuację obsługi przez system wszystkich krytycznych aplikacji w przypadku wystąpienia katastrofy. Jeśli formalny plan zapasowy został w pełni utworzony, naleŜy umieścić odnośnik do niego. Kopia planu zapasowego moŜe być załącznikiem. W tej sekcji naleŜy dołączyć następujące, wymienione poniŜej, elementy.
Wszystkie umowy o obsługę archiwizacji (na przykład kontrakt z komercyjnym

dostawcą usług).
Udokumentowane procedury archiwizacji, włączając ich częstotliwość

(codziennie, tygodniowo, miesięcznie) oraz zakres (pełna kopia awaryjna, kopia przyrostowa lub róŜnicowa).
Miejsce przechowywania kopii zapasowych oraz liczbę utrzymywanych

generacji kopii zapasowych.
Czy istnieją przetestowane plany zapasowe na wypadek wystąpienia groźnego

zdarzenia? Jak często są testowane?
Czy wszyscy pracownicy zostali przeszkoleni w zakresie swoich ról

i odpowiedzialności dotyczących planów awaryjnych, ratunkowych i na wypadek katastrofy?

Kontrola obsługi sprzętu i oprogramowania Te środki kontroli obejmują:
restrykcje oraz środki kontroli osób wykonujących obsługę lub naprawę systemu;
specjalne procedury pozwalające na zapewnienie odpowiedniej wydajności

naprawy i obsługi;
procedury stosowane dla elementów serwisowanych na miejscu oraz poza

organizacją (na przykład towarzyszenie serwisantom, oczyszczanie nośników zabieranych z biura);
procedury stosowane do kontroli usług zdalnej obsługi, kiedy procedury

diagnostyczne lub serwisowe są wykonywane przy uŜyciu mediów telekomunikacyjnych;
kontrola wersji, która pozwala na powiązanie komponentów systemu

z właściwą wersją systemu;
procedury testowania i zatwierdzania komponentów systemu (system

operacyjny, inny system, narzędzia i aplikacje) przed przekazaniem do uŜytku;
analizy wpływu efektu proponowanych zmian na istniejące środki kontroli

zabezpieczeń, co obejmuje takŜe wymagane szkolenia zarówno dla techników, jak i uŜytkowników, odnoszące się do proponowanej zmiany w oprogramowaniu lub sprzęcie;
procedury zmiany identyfikacji, akceptacji i dokumentacji;

D:\KISIU\PDFy\Chudy\KsiąŜki\Hack wars doc\hack wars tom 2 [ PL ]\hack wars tom 2 [ PL ]\dodatek B.doc

373

374

Hack Wars. Tom 2. Na tropie hakerów
procedury pozwalające upewnić się, czy plany zapasowe i powiązana

dokumentacja jest aktualizowana wraz ze zmianami systemu;
ustalenie, czy dane testowe były danymi rzeczywistymi, czy spreparowanymi;
zasady organizacji dotyczące nielegalnego uŜycia oprogramowania objętego

prawami autorskimi lub typu shareware.

Kontrola integralności
Czy zainstalowano oprogramowanie do wykrywania i eliminacji wirusów?

Jeśli tak, to czy istnieją procedury do aktualizacji plików podpisów wirusów, automatycznego lub ręcznego skanowania antywirusowego oraz usuwania wirusów i tworzenia raportów?
Czy stosowane są przez system procedury kontrolne — na przykład sumy

kontrolne, sumy hash i liczniki rekordów? NaleŜy dołączyć opis działań podjętych w celu usunięcia wszelkich niezgodności.
Czy uŜywane są narzędzia do sprawdzania i łamania haseł?
Czy aplikacje korzystają z programów do weryfikacji integralności w celu

wyszukania dowodów na manipulację danymi, błędów oraz pominięć?
Czy w systemie zainstalowano narzędzia do wykrywania włamania?
Czy uŜywana jest funkcja monitorowania wydajności systemu w celu analizy

dzienników wydajności systemu w czasie rzeczywistym, wyszukiwania problemów z dostępnością (włączając w to aktywne ataki) oraz awarii lub spowolnienia pracy systemu i sieci?
Czy w systemie są wykonywane testy penetracji? Jeśli tak, to jakie procedury

są stosowane w celu zapewnienia prawidłowego wykonywania takich testów?
Czy system uŜywa funkcji uwierzytelniania wiadomości w celu upewnienia

się, czy nadawca wiadomości jest znany, a wiadomość nie została zmieniona w czasie transmisji?

Dokumentacja Dokumentacja systemu obejmuje opisy sprzętu i programów, zasady, standardy, procedury oraz akceptacje odnoszące się do bezpieczeństwa zautomatyzowanego systemu informatycznego (aplikacja oraz system obsługi, na którym jest ona wykonywana). NaleŜy tu takŜe dołączyć opis procedur archiwizacji oraz planu zapasowego, a takŜe opis procedur uŜytkownika i operatora.
Przedstawić listę dokumentacji systemu (dokumentacja sprzętu i programów

producenta, wymagania funkcjonalne, plan zabezpieczeń, plan zabezpieczeń systemu ogólnego wsparcia, podręczniki aplikacji, dokumentacja wyników testów, standardowe procedury operacyjne, procedury awaryjne, plany zapasowe, zasady i procedury uŜytkownika, ocena ryzyka, dokumenty i oświadczenia o certyfikatach i akredytacji, przeglądy weryfikacyjne i inspekcje).

374

D:\KISIU\PDFy\Chudy\KsiąŜki\Hack wars doc\hack wars tom 2 [ PL ]\hack wars tom 2 [ PL ]\dodatek B.doc

Dodatek B ♦ Szablony planu zabezpieczeń

375

Znajomość zabezpieczeń i szkolenia
Opisać program świadomości systemu (plakaty, foldery i inne).
Opisać typ i częstotliwość szkoleń w zakresie obsługi systemu ogólnego

wsparcia, przeprowadzanych dla pracowników oraz osób współpracujących (seminaria, warsztaty, zajęcia w klasach, grupy dyskusyjne, odgrywanie ról oraz szkolenie w trakcie pracy).
Opisać procedurę sprawdzania, czy pracownicy i osoby współpracujące

przeszły niezbędne szkolenia.

MoŜliwość zgłaszania wypadków naruszenia bezpieczeństwa
Czy istnieją procedury zgłaszania naruszeń bezpieczeństwa, obsługiwane

przez personel organizacji lub na zewnątrz?
Czy istnieją procedury rozpoznawania i reakcji na takie zdarzenia (na przykład,

które pliki i dzienniki powinny być zachowane, z kim i kiedy naleŜy się skontaktować)?
Kto odbiera i odpowiada na alarmy i informacje o poprawkach

oprogramowania lub o zbadanych słabych punktach?
Jakie stosuje się środki zabezpieczające (na przykład narzędzia do wykrywania

włamania, zautomatyzowane dzienniki kontroli, testy penetracji)?

Kontrola techniczna Identyfikacja i uwierzytelnianie
Opisać metodę uwierzytelniania uŜytkowników (hasło, token lub cechy

biometryczne).
Jeśli stosowany jest system haseł, podaj następujące informacje:


dozwolony zestaw znaków;




długość hasła (minimalna i maksymalna);




okres upływu waŜności hasła oraz sposób wymuszania jego zmiany;




liczbę niedozwolonych generacji starych haseł;




procedury zmiany hasła;




procedury obsługi zagubionych haseł;




procedury obsługi naruszenia systemu haseł.


Opisać procedury szkolenia uŜytkowników oraz uŜyte materiały.
Wskazać częstotliwość zmiany haseł, opisać sposób wymuszenia zmiany

hasła (na przykład przez program lub administratora systemu) oraz podać osobę, która zmienia hasło (uŜytkownik, system lub administrator systemu).

D:\KISIU\PDFy\Chudy\KsiąŜki\Hack wars doc\hack wars tom 2 [ PL ]\hack wars tom 2 [ PL ]\dodatek B.doc

375

376

Hack Wars. Tom 2. Na tropie hakerów
Opisać stosowane sposoby kontroli cech biometrycznych. NaleŜy dołączyć

opis sposobu implementacji tych sposobów w systemie.
Opisać uŜywane przez system środki kontroli tokenów oraz sposób ich

implementacji.
Opisać poziom wymuszania mechanizmu kontroli dostępu (sieć, system

operacyjny lub aplikacja).
Opisać sposób obsługi poszczególnych kont i kontroli śladów (na przykład,

czy hasła są powiązane z identyfikatorem uŜytkownika, który jest przydzielony tylko dla jednej osoby) przez mechanizm kontroli dostępu.
Opisać techniki własnego zabezpieczenia mechanizmu uwierzytelniania

uŜytkownika (na przykład, czy hasła są przesyłane i przechowywane przy uŜyciu jednokierunkowego szyfrowania tak, Ŝe nikt, włączając w to administratora, nie moŜe odczytać haseł w czystym tekście; czy hasła są generowane automatycznie; czy hasła są porównywane ze słownikiem niedozwolonych haseł; czy hasła są szyfrowane w czasie przesyłania).
Podać liczbę nieudanych prób dostępu, jaka moŜe wystąpić dla danego

identyfikatora uŜytkownika lub miejsca dostępu (terminal lub port), a takŜe opisać działania, jakie zostaną podjęte po przekroczeniu limitu.
Opisać procedurę weryfikacji, czy zostały zmienione wszystkie domyślne

hasła administratorów ustawionych systemowo.
Opisać procedury ograniczania skryptów dostępowych z dołączonym hasłem

(na przykład, czy skrypty z dołączonym hasłem są zabronione lub dozwolone tylko dla aplikacji wsadowych).
Opisać wszystkie zasady, które pozwalają na pominięcie wymagań dotyczących

uwierzytelniania uŜytkownika, technologie „pojedynczego podpisu” (na przykład bezpośrednie połączenie dwóch komputerów, serwery uwierzytelniania, identyfikator „uŜytkownik do hosta” oraz identyfikatory grup uŜytkowników), a takŜe wszystkie środki kontroli naruszenia uwierzytelniania.

Logiczna kontrola dostępu
Omówić środki kontroli, które są stosowane do autoryzacji lub ograniczenia

działalności uŜytkowników lub personelu systemowego w ramach aplikacji. Opisać funkcje sprzętu lub oprogramowania, które zostały utworzone w celu umoŜliwienia tylko autoryzowanego dostępu do aplikacji lub wewnątrz niej, do ograniczenia działań uŜytkowników tylko do autoryzowanych transakcji i funkcji, a takŜe do wykrywania nieautoryzowanych działań (na przykład listy kontroli dostępu ACL).
Opisać sposób przyznawania uprawnień dostępowych. Czy przywileje są

przydzielane w oparciu o wykonywane zadania?
Opisać moŜliwość utworzenia przez aplikację listy kontroli dostępu ACL

lub rejestru.

376

D:\KISIU\PDFy\Chudy\KsiąŜki\Hack wars doc\hack wars tom 2 [ PL ]\hack wars tom 2 [ PL ]\dodatek B.doc

Dodatek B ♦ Szablony planu zabezpieczeń

377


Opisać sposób, w jaki ogranicza się uŜytkownikom aplikacji dostęp do

systemu operacyjnego, innych aplikacji lub innych zasobów systemowych, które nie są wymagane podczas wykonywania przez nich swoich obowiązków.
Opisać środki kontroli uŜywane do wykrywania nieautoryzowanych prób

transakcji przez autoryzowanych lub nieautoryzowanych uŜytkowników. Opisać wszystkie ograniczenia, które uniemoŜliwiają uŜytkownikom uzyskanie dostępu do systemu lub aplikacji poza normalnymi godzinami pracy lub w czasie weekendów. NaleŜy opisać zastosowane ograniczenia.
Wskazać, po jakim okresie braku aktywności uŜytkownika system automatycznie

oczyszcza wyświetlany obraz, a po jakim czasie system automatycznie odłącza nieaktywnych uŜytkowników lub wymaga od nich ponownego podania unikalnego hasła w celu przyłączenia się do systemu lub aplikacji.
Wskazać, czy do uniemoŜliwienia nieautoryzowanego dostępu do wraŜliwych

plików jest stosowane szyfrowanie jako część procedur kontroli dostępu do systemu lub aplikacji.
Uzasadnić decyzję o uŜyciu banerów ostrzegawczych lub ich braku; dołączyć

przykłady uŜywanych banerów.

Śledzenie śladów
Czy funkcja śledzenia śladów współpracuje z funkcją obsługi kont, dzięki

czemu moŜna uzyskać zapis działań uŜytkownika?
Czy funkcja śledzenia śladów została zaprojektowana i wdroŜona w celu

zapisywania niezbędnych informacji, które mogą pomóc w wykrywaniu włamania?
Czy funkcja śledzenia śladów obejmuje wystarczająco duŜo informacji,

aby ustalić typ zdarzeń i ich sprawcę? NaleŜy tu umieścić typ zdarzenia, datę wystąpienia zdarzenia, identyfikator uŜytkownika powiązany ze zdarzeniem oraz program lub polecenie uŜyte do rozpoczęcia zdarzenia.
Czy dostęp do dzienników funkcji śledzenia jest ściśle kontrolowany?
Czy zapewniona jest poufność informacji funkcji śledzenia śladów, jeśli

na przykład są zapisywane osobiste dane uŜytkowników?
Jak często są przeglądane dane funkcji śledzenia śladów? Czy istnieją zasady

takiego przeglądu?
Czy właściwy administrator na poziomie systemu lub aplikacji przegląda

dane funkcji śledzenia śladów, badając znany problem systemu albo aplikacji, znany przypadek naruszenia istniejących wymagań przez uŜytkownika lub niewyjaśniony problem związany z systemem lub uŜytkownikiem?

D:\KISIU\PDFy\Chudy\KsiąŜki\Hack wars doc\hack wars tom 2 [ PL ]\hack wars tom 2 [ PL ]\dodatek B.doc

377

378

378

Hack Wars. Tom 2. Na tropie hakerów

D:\KISIU\PDFy\Chudy\KsiąŜki\Hack wars doc\hack wars tom 2 [ PL ]\hack wars tom 2 [ PL ]\dodatek B.doc