Polityka Bezpieczeństwa Systemów Informatycznych powinna we wstępie opisywać przyjętą metodykę, czyli w tym przypadku zaznaczyć, że szczegółowe reguły bezpieczeństwa są określone w dokumentach polityk bezpieczeństwa poszczególnych systemów informatycznych. Część środkową powinien stanowić zestaw zasad i regulacji bezpieczeństwa w formie przyjętej do ich prezentacji. Oczywiście, zasady te mogą być podawane w kolejności, w jakiej występują w części dotyczącej wymagań.

Warto pamiętać, że dokument polityki bezpieczeństwa powinien wyrażać realną troskę o bezpieczeństwo zasobów. Z tego względu należy dokonać analizy zagrożeń i wartości zasobów. Analizy te są składowymi procesu analizy ryzyka, której dokonanie warunkuje poprawność nie tylko kreowania strategii i polityki bezpieczeństwa, lecz również dobór odpowiednich mechanizmów technicznych, fizycznych, programowych i organizacyjnych zabezpieczeń. Ten element Polityki Bezpieczeństwa nie może być dostępny jako publiczny, jest on zawsze opisem słabości systemu, nawet gdy system oparty jest na standardowych i ogólnie dostępnych mechanizmach bezpieczeństwa.

Etap 3. Procedury Bezpieczeństwa Systemów Informatycznych

Procedury Bezpieczeństwa Systemów Informatycznych są realizacją Strategii i Polityki Bezpieczeństwa. Powstać powinny wtedy, gdy w systemie jest w pełni wdrożony mechanizm bezpieczeństwa fizycznego i technicznego.

Procedury bezpieczeństwa łączą w logiczną całość funkcjonalność systemu informatycznego z mechanizmami bezpieczeństwa w ten sposób, że każda ewentualność zachowania (wyboru) użytkownika systemu jest przewidziana poprzez stosowny algorytm procedury bądź też procedura nakazuje odwołanie się do innego dokumentu bądź reakcji.

Najistotniejsze jest, aby procedury spełniały swoje zadanie i były zrozumiałe. Nie znaczy to, że muszą być krótkie i pisane prostym językiem. Procedury dedykowane są dla określonych grup użytkowników, których poziom zrozumienia ich treści łatwo przewidzieć. Nie należy oczekiwać, że użytkownicy zapamiętają treść procedur. Ten tok rozumowania może doprowadzić do sytuacji, gdy osoba opracowująca standardy bezpieczeństwa będzie się starała zminimalizować ilość treści przekazywanych przez procedury w celu łatwiejszego ich zapamiętania przez użytkownika, pozostawiając jednocześnie wiele różnorodnych możliwości interpretacji zapisów i niejednoznacznych nakazów postępowania. Zadajmy sobie pytanie: kiedy procedura jest przydatna? Odpowiedź jest niezwykle prosta - jedynie w sytuacjach w niej określonych. Przykładem może być rozbudowana procedura (system) przechowywania haseł administracyjnych do systemów informatycznych. Celem procedury jest zagwarantowanie ciągłej dostępności do kont administracyjnych systemu. W sytuacji gdy zachodzi potrzeba użycia konta administracyjnego podczas nieobecności administratora systemu, zainteresowana grupa osób (wyszczególnionych w procedurze) postępuje krok po kroku wg procedury. W tej sytuacji istotne jest jedynie, by użytkownicy - administratorzy wiedzieli o istnieniu procedury oraz sytuacjach, kiedy należy ją zastosować, jej treść natomiast mogą wykonywać dopiero w momencie, gdy jest to niezbędne. Oczywiście, procedury powinny być dostępne wszystkim użytkownikom systemów informatycznych, którzy w dowolnym momencie mogą zapoznać się z ich treścią.

Kierując się zasadą, iż mają one spełnić określone zadanie, należy opracować systematyczną i standardową formę przekazu.

Opracowując procedury bezpieczeństwa, warto podzielić je na grupy odbiorców. Jedna z grup procedur powinna być przeznaczona dla wszystkich użytkowników. W tej grupie zazwyczaj pojawiają się procedury reagowania w sytuacjach awaryjnych, procedury audytu przestrzegania Zasad Bezpieczeństwa danego systemu lub procesu oraz zestaw procedur informowania o sytuacjach krytycznych.

Następne grupy przeznaczone są dla funkcjonalnych grup użytkowników lub rejonów systemu. Najczęściej stosowany jest podział na grupy: administratorów, użytkowników końcowych oraz osób, które są związane z systemem specjalnymi klauzulami (np. poufności).

Procedury muszą być zrozumiałe. Jednym elementem jest język procedury, który jest uzależniony z jednej strony od odbiorcy, z drugiej - od osoby ją tworzącej. Większość spośród procedur jest przewidziana w odniesieniu do sytuacji awaryjnych lub zdarzeń nadzwyczajnych (dla standardowego użytkownika systemu informatycznego zmiana hasła dostępu lub wykonanie kopii awaryjnej nie jest codziennością), a w wielu przypadkach istotną rolę odgrywa czas wykonania procedury. Aby to osiągnąć, należy wypracować standardowy opis procedury i jej podział. Jeżeli wszystkie procedury przeznaczone dla danej grupy użytkowników będą składały się z trzech części np. jej cel, zakres stosowania i treść, pozbędziemy się sytuacji, gdy zakłopotany użytkownik będzie błądził w jej strukturze zamiast wprowadzać w życie założone postanowienia.

Mechanizmy bezpieczeństwa wymagają uwzględnienia konieczności wprowadzania zmian. Procedury dobrze przygotowane, przemyślane i przyjęte będą aktualizowane jedynie w miejscach, w których opisują postępowanie z mechanizmami technicznymi i fizycznymi, takimi jak rozpoczęcie pracy z systemem lub zasady migracji kluczy do kas pancernych. Nie powinny one zmieniać swej treści w stosunku do zasad organizacyjnych, z wyjątkiem zmian wynikających z modyfikacji Strategii lub Polityki Bezpieczeństwa.

Aleksander Poniewierski jest kierownikiem Zabezpieczeń Systemów Informatycznych Netia Telekom SA.