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,

• 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.

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.

• 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?

• 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ć 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.

• 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.

• 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).

• 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 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;

• 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,

• 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.

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.

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ń?

• 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?

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.

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;

• 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).

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).

• 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.

• 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?

358 Hack Wars. Tom 2. Na tropie hakerów

zDodatek B ♦ Szablony planu zabezpieczeń 359

358 C:\Biezace\Hack Wars\hack wars 2\9 makieta\dodatek B.doc

C:\Biezace\Hack Wars\hack wars 2\9 makieta\dodatek B.doc 359

C:\Biezace\Hack Wars\hack wars 2\9 makieta\dodatek B.doc 357

---