zDodatek B ¨ Szablony planu zabezpieczeń 359
Data.
Unikalny identyfikator i nazwa przyznana dla systemu.
Organizacja odpowiedzialna za system.
Nazwisko osoby znającej system lub właściciela systemu:
t nazwisko,
t stanowisko,
t adres,
t telefon,
t adres e-mail.
Nazwisko osoby odpowiedzialnej za bezpieczeństwo systemu:
Jeśli wybrano więcej niż jeden status, należy podać części systemu, jakie obejmuje dany status:
t operacyjny;
t w konstrukcji;
t przechodzi poważną modyfikację.
t Opisać funkcję lub cel aplikacji oraz przetwarzane przez nią informacje.
t Opisać proces przetwarzania przez aplikację od wejścia do systemu do wyjścia z niego.
t Opisać sposób organizacji użytkowników (wewnętrznych i zewnętrznych) oraz obsługiwany typ danych i przetwarzania.
t 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.).
t Opisać główną platformę komputerową oraz podstawowe komponenty systemu, włączając w to osprzęt, oprogramowanie oraz zasoby komunikacyjne.
t Dołączyć informacje o wszystkich programach chroniących system i informacje.
t Podać listę połączonych systemów oraz ich identyfikatory (jeśli stosowane).
t 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.
t 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.
t 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.
t 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.
t 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.
t 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.
t Wymienić wszystkie niezależne przeglądy zabezpieczeń systemu, jakie zostały wykonane w ciągu ostatnich trzech lat.
t 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.
t 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.
t 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.
t 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.
t Ustalić fazę (fazy) cyklu życia systemu lub jego poszczególnych części.
t Opisać sposób zapewnienia bezpieczeństwa w fazie (fazach) cyklu życia, w której obecnie znajduje się system.
t Umieścić odnośnik do oceny wrażliwości znajdującej się w sekcji Wrażliwość przechowywanych informacji.
t Czy w czasie projektowania systemu zidentyfikowano wymagania pod względem bezpieczeństwa?
t Czy przed dostarczeniem systemu stworzono odpowiednie kontrole zabezpieczeń wraz z powiązanymi procedurami badania i testowania?
t Czy dokumenty ofertowe (na przykład zapytanie ofertowe) zawierały wymagania pod względem zabezpieczeń oraz procedur badawczych i testowych?
t 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?
t 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ń?
t 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?
t Czy po zakończeniu projektowania dodano jakieś środki kontroli zabezpieczeń?
t Czy aplikacja przeszła badania techniczne w celu sprawdzenia, czy spełnia wymagania pod względem prawa, regulacji, zasad i standardów?
t Czy aplikacja uzyskała certyfikaty i akredytacje? Kiedy? Jeśli system nie uzyskał jeszcze autoryzacji, podać datę wysłania prośby o autoryzację.
Plan zabezpieczeń dokumentuje czynności zabezpieczające wymagane w tej fazie.
t 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.
t Czy wrażliwe dane są szyfrowane?
t W jaki sposób informacje są usuwane i kasowane z systemu?
t Czy informacje lub nośniki są oczyszczane, nadpisywane, rozmagnesowywane czy niszczone?
t Podać datę autoryzacji, nazwisko i stanowisko menedżera, który autoryzuje przetwarzanie informacji w systemie.
t Jeśli nie uzyskano autoryzacji, podać nazwisko i stanowisko menedżera, który prosi o zgodę na działanie oraz datę tej prośby.
t Czy wszystkie stanowiska zostały zbadane pod kątem poziomu wrażliwości?
t Czy wszyscy użytkownicy odbyli szkolenie odpowiadające stanowisku, które zostało im przydzielone?
t Czy dostęp użytkowników został ograniczony do minimalnego poziomu, wymaganego do wykonania pracy?
t Czy istnieje system zamawiania, zakładania, wydawania i zamykania kont użytkowników?
t Czy krytyczne funkcje zostały rozdzielone między różne osoby (podział obowiązków)?
t Jakie mechanizmy zastosowano, aby użytkownicy byli odpowiedzialni za swoje postępowanie? Opisać te mechanizmy.
t Jakie są procedury przyjaznego i nieprzyjaznego zakończenia procesu?
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.
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.
t 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?
t Procedury, dzięki którym nieautoryzowane osoby nie mogą odczytać, skopiować, zmienić ani ukraść wydrukowanych lub elektronicznych informacji.
t Procedury, dzięki którym tylko autoryzowani użytkownicy mogą pobrać, odebrać lub dostarczyć informacje wejściowe i wyjściowe oraz nośniki.
t Śledzenie odbioru ważnych danych wejściowych i wyjściowych.
t Procedury ograniczające dostęp do urządzeń wyjściowych.
t Procedury i środki kontroli przy transporcie lub wysyłce nośników i wydruków.
t Zewnętrzny lub wewnętrzny system znakowania wrażliwości informacji.
t 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).
t Kontrola śladów do celów zarządzania inwentarzem.
t Procedury i środki kontroli fizycznej i środowiskowej ochrony miejsca przechowywania nośników i biblioteki.
t Procedury czyszczenia nośników elektronicznych w celu ponownego użycia (na przykład nadpisanie lub rozmagnesowanie nośników elektronicznych).
t Procedury kontrolowanego przechowywania, obsługi i zniszczenia uszkodzonych nośników lub takich, które nie mogą być wyczyszczone w celu ponownego użycia.
t Procedury fizycznego zniszczenia wydruków, które nie są już potrzebne.
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.
t Wszystkie umowy dotyczące obsługi archiwizacji (na przykład kontrakt z komercyjnym dostawcą usług).
t Udokumentowane procedury archiwizacji, włączając ich częstotliwość (codziennie, tygodniowo, miesięcznie) oraz zakres (pełna kopia awaryjna, kopia przyrostowa lub różnicowa).
t Miejsce przechowywania kopii zapasowych oraz liczbę utrzymywanych generacji kopii zapasowych.
t Czy istnieją przetestowane plany zapasowe na wypadek wystąpienia groźnego zdarzenia? Jak często są testowane?
t Czy wszyscy pracownicy zostali przeszkoleni w zakresie swoich ról i odpowiedzialności pod względem planów awaryjnych, ratunkowych i na wypadek katastrofy?
t Zasięg procedur archiwizacji (na przykład, co jest archiwizowane).
t Czy oprogramowanie zostało napisane w firmie lub na zamówienie?
t Czy oprogramowanie należy do organizacji? Czy oprogramowanie zostało otrzymane z innego biura?
t 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?
t ...
maras16