Rozdział 4. ¨ Powiązanie mechanizmów zabezpieczających 259
W tym miejscu połączymy ze sobą wszystkie informacje dotyczące zespołu Tiger Team z poprzednich rozdziałów w celu sformułowania najlepszych zasad bezpieczeństwa, strategii, która pomoże Ci wykonać kolejne kroki. Tak jak w przypadku skutecznej zmiany platformy, integracji infrastruktury lub implementacji ważnego oprogramowania, konieczne będzie przygotowanie wstępnej dokumentacji planowania. Poświęcenie czasu na opracowanie szkicu zawierającego kolejne procedury do wykonania pomoże uniknąć ogromnej liczby błędów i niekonsekwencji. Pamiętając o tym, przyjrzyjmy się rekomendowanym programom przedstawionym w tej części i zastosujmy te, które odnoszą się do naszych wymagań w czasie tworzenia własnej polityki zabezpieczeń.
Zasady bezpieczeństwa technologii informatycznej są w centrum zainteresowania wielu osób zarówno w sektorze publicznym, jak i prywatnym. Każdy chce zabezpieczyć siebie i swoje informacje przed coraz częściej zdarzającymi się atakami hakerów. Mocne zasady bezpieczeństwa stanowią podstawę skutecznej obrony w tej dziedzinie. Pierwsza część tego rozdziału zawiera wyjątki z jednego z najważniejszych dokumentów poświęconych zapewnianiu bezpieczeństwa, aby pomóc Ci w utworzeniu własnych zasad. Jest to napisany w 1998 roku przez Marianne Swanson, specjalistkę w Dziale Bezpieczeństwa Komputerów, dla Państwowego Instytutu Standaryzacji i Technologii (National Institute of Standards Technology — NIST) Przewodnik po tworzeniu planów zabezpieczeń systemów technologii informatycznej (Guide to Developing Security Plans for Information Technology Systems). Biorąc pod uwagę konieczność zabezpieczenia państwowych tajnych informacji, usług i infrastruktury, te zalecenia mogą być uważane za cenne zasady, w oparciu o nie należy utworzyć plan lub politykę dla dowolnej organizacji.
Opisane w tym dokumencie i przedstawione tutaj elementy polityki zabezpieczeń obejmują:
t tworzenie planu,
t analizy,
t procedury niezbędne do wdrożenia opracowanej polityki zabezpieczeń.
Przewodnik po tworzeniu planów zabezpieczeń systemów technologii informatycznej został napisany dla pracowników amerykańskich agencji rządowych, ale ten materiał może być z powodzeniem wykorzystany w innych sektorach.
Ten rozdział powinien być traktowany jako zbiór wszystkich informacji przedstawionych dotąd w obu tomach tej książki.
Celem opracowania zasad bezpieczeństwa systemu jest poprawienie zabezpieczeń zasobów technologii informatycznej (IT). Wszystkie systemy rządowe i większość korporacyjnych cechuje pewien poziom wrażliwości i dlatego wymagają zabezpieczeń, które stanowią część polityki dobrego zarządzania. Zabezpieczenie systemu musi być udokumentowane w planie zabezpieczeń systemu.
Celem jest zapewnienie informacji o ogólnych wymaganiach bezpieczeństwa systemu oraz opisanie środków, które są już wykorzystywane lub będą użyte w celu spełnienia tychże wymagań. Schemat zabezpieczeń systemu przedstawia również dane o odpowiedzialności poszczególnych osób oraz oczekiwane zachowania wszystkich mających dostęp do systemu. Opis zabezpieczeń powinien być traktowany jako dokumentacja strukturalnego procesu planowania niezbędnych i efektywnych pod względem kosztów zabezpieczeń systemu. W planie powinny znaleźć się sugestie różnych menedżerów, których obowiązki są związane z systemem, włączając w to właścicieli informacji, operatora systemu oraz menedżera zabezpieczeń systemu. Możliwe jest dołączenie do podstawowego opracowania dodatkowych informacji oraz zmiana jego struktury i organizacji w zależności od potrzeb firmy, pod warunkiem jednak, iż główne części dokumentu są wyczerpujące i łatwe do odnalezienia. Aby plany w wystarczającym stopniu odzwierciedlały zabezpieczenia zasobów, przedstawiciel kierownictwa musi autoryzować system w celu umożliwienia obróbki informacji lub działania. Taka autoryzacja zapewnia bardzo ważną kontrolę jakości. Przez autoryzację procesu w systemie menedżer akceptuje powiązane z nim ryzyko.
Autoryzacja kadry zarządzającej powinna być oparta o ocenę kontroli kierowniczej, operacyjnej oraz technicznej. Ponieważ plan zabezpieczeń ustanawia i dokumentuje kontrolę zabezpieczeń, powinien stać się podstawą do autoryzacji, uzupełnioną w razie potrzeby dodatkowymi badaniami. Oprócz tego, okresowy przegląd kontroli powinien mieć wpływ na podobną autoryzację w przyszłości. Ponowna autoryzacja powinna mieć miejsce przed znaczącą zmianą w obróbce danych, ale nie rzadziej niż trzy razy do roku. Powinna odbywać się częściej w przypadku stwierdzenia większego ryzyka lub możliwości wystąpienia znaczących szkód.
Szybko zmieniające się środowisko techniczne zmusza organizacje do adaptacji minimalnego zestawu kontroli kierowniczej w celu zabezpieczenia własnych zasobów technologii informatycznej (IT). Ta kontrola kierowana jest na poszczególnych użytkowników IT w celu odzwierciedlenia dystrybuowanej natury współczesnej technologii. Kontrola techniczna i operacyjna uzupełnia kontrolę kierowniczą. Wszystkie te rodzaje kontroli muszą ze sobą współgrać, aby były efektywne.
Plany systemu zabezpieczeń muszą obejmować wszystkie aplikacje i systemy, które mają znaleźć się w kategorii „głównych aplikacji” lub „systemu ogólnego wsparcia”. Konkretne plany zabezpieczeń dla pozostałych aplikacji nie są wymagane, ponieważ kontrola zabezpieczeń dla tych programów i aplikacji będzie zapewniana przez systemy ogólnego wsparcia, na których działają. Na przykład używany w całym dziale system zarządzania finansami będzie aplikacją główną, wymagającą własnego planu zabezpieczeń. Lokalny program, zaprojektowany do śledzenia wydatków i ich porównywania z budżetem biura, nie musi być uważany za aplikację główną, a jego obsługą zajmie się plan systemu ogólnego wsparcia dla systemu automatyzacji biura lub sieci lokalnej LAN. Standardowe oprogramowanie komercyjne (takie jak edytor tekstu, program do poczty elektronicznej, różnego rodzaju narzędzia i programy do ogólnego stosowania) zwykle nie jest traktowane jako główna aplikacja, dlatego obejmuje je plan systemu ogólnego wsparcia, na którym jest zainstalowane.
Celem planu systemu zabezpieczeń jest:
t zapewnienie przeglądu wymagań w stosunku do zabezpieczeń systemu oraz opis odbywających się lub zaplanowanych kontroli w celu spełnienia tych wymagań,
t opisanie odpowiedzialności i oczekiwanego zachowania wszystkich osób, które mają dostęp do systemu.
Właściciel systemu jest odpowiedzialny za przygotowanie planu zabezpieczeń oraz jego wprowadzenie i monitorowanie skuteczności. W planie zabezpieczeń powinny znaleźć się sugestie różnych osób, których odpowiedzialność jest związana z systemem, włączając w to końcowych użytkowników, właścicieli informacji, administratora systemu oraz menedżera zabezpieczeń systemu.
Ten dokument został opracowany tylko jako wzór i nie powinien być uważany za jedyny możliwy format. Standardowe podejście jednak nie tylko ułatwia tworzenie planu, udostępniając przykłady, ale i pomaga przy jego sprawdzaniu. Poziom szczegółów zamieszczonych w planie powinien odpowiadać znaczeniu oraz wartości systemu dla misji organizacji (oznacza to, iż bardziej szczegółowy plan jest wymagany w systemach krytycznych dla pracy organizacji). Plan zabezpieczeń powinien w pełni identyfikować i opisywać obecnie odbywające się i zaplanowane kontrole dla systemu. Taki plan powinien również zawierać zasady zachowania.
Przed realizacją planu zabezpieczeń należy zebrać niezależne porady i komentarze na jego temat. Takie uwagi mogą pochodzić od osób pracujących w organizacji lub poza nią, które nie są odpowiedzialne za tworzenie, implementację lub obsługę systemu. Tacy doradcy nie powinni należeć do grona osób tworzących raporty dla właściciela systemu; wymagana jest również odpowiednia wiedza lub doświadczenie, co zapewnia ujęcie w planie niezbędnych informacji, a także spełnienie wymagań i standardów polityki bezpieczeństwa firmy. Wybrane osoby to na przykład menedżer programu zabezpieczeń IT w firmie, menedżerowie IT innych systemów, współpracownicy z zewnątrz lub pracownicy z innych organizacji rządowych.
Ten przewodnik może być wykorzystany na dwa różne sposoby. Po pierwsze, powinien być używany przez osoby odpowiedzialne za bezpieczeństwo IT na poziomie systemu oraz poziomie organizacyjnym. Dokument ma być przewodnikiem w czasie tworzenia planów zabezpieczeń i jest napisany konkretnie dla osób, które mają mało doświadczenia w zakresie bezpieczeństwa komputerowego. Może być również używany jako dokument kontrolny przez rewidentów, menedżerów i specjalistów zajmujących się bezpieczeństwem IT. Przedstawiono tu ogólne koncepcje, które można zastosować w firmach sektora prywatnego i publicznego.
Po utworzeniu plan zabezpieczeń będzie zawierał informacje techniczne o systemie, jego wymaganiach pod względem zabezpieczeń, a także kontrole prowadzone w celu ochrony przed ryzykiem i wrażliwością systemu. Zanim zostanie utworzony plan, należy wybrać jego typ odpowiedni dla danego systemu. Ta część rozdziału przeprowadzi czytelnika przez analizę systemu w celu ustalenia zakresu i typu systemu.
Zdefiniowanie „systemu” dla potrzeb tego przewodnika wymaga analizy zakresu systemu i odpowiedzialności w organizacji. System to otoczone logicznymi granicami zestawy procesów, komunikacji, przechowywania danych oraz powiązanych zasobów. Elementy te stanowią pojedynczy system, który wymaga planu zabezpieczeń. Każdy element systemu musi:
t znaleźć się w tym samym zakresie bezpośredniej kontroli kierowniczej,
t mieć tę samą funkcję lub cel misji,
t mieć praktycznie taką samą charakterystykę działania oraz potrzeby pod względem zabezpieczeń,
t znajdować się w tym samym ogólnym środowisku operacyjnym.
Wszystkie elementy systemu nie muszą być ze sobą fizycznie połączone (na przykład grupa wolnostojących komputerów osobistych w biurze; grupa pecetów umieszczonych w domach pracowników, które podlegają określonym zasadom programu zdalnej pracy; grupa przenośnych komputerów, które są używane przez osoby wymagające w swej pracy mobilności; system z wieloma identycznymi konfiguracjami, które są zainstalowane w miejscach z identycznymi zabezpieczeniami oraz w takim samym środowisku).
Kolejnym krokiem jest umieszczenie każdego systemu w kategorii „głównej aplikacji” lub „systemu ogólnego wsparcia”. Wszystkie aplikacje powinny być objęte planem zabezpieczeń. Może to być konkretny plan, jeśli dana aplikacja została oznaczona jako główna, lub plan zabezpieczeń ogólnego systemu wsparcia. System może być oznaczony jako główna aplikacja, nawet jeśli jest również obsługiwany przez system oznaczony jako system ogólnego wsparcia. Na przykład sieć LAN może być określona jako system ogólnego wsparcia i mieć własny plan zabezpieczeń. System księgowy może być oznaczony jako główna aplikacja, nawet jeśli jest obsługiwany przez zasoby komputerowe i komunikacyjne sieci LAN. W tym przykładzie główna aplikacja wymaga dodatkowych zabezpieczeń ze względu na wrażliwość informacji, jakie przetwarza. Jeśli dla głównej aplikacji, która jest obsługiwana przez system ogólnego wsparcia, wymagany jest własny plan zabezpieczeń, konieczna jest koordynacja obu planów.
Wszystkie aplikacje rządowe i większość korporacyjnych stanowią wartość dla ich właściciela, dlatego wymagają pewnego poziomu zabezpieczeń. Niektóre aplikacje wymagają specjalnego nadzoru kierownictwa ze względu na przetwarzane lub przesyłane informacje, a także z powodu ich znaczenia dla organizacji.
Organizacje powinny rozwijać swoje umiejętności w zakresie ustalania głównych aplikacji oraz upewnić się, czy wymagania zabezpieczeń dla pozostałych aplikacji zostały omówione jako część planu zabezpieczeń dla właściwego systemu ogólnego wsparcia.
Główne aplikacje to systemy wykonujące jasno zdefiniowane funkcje, dla których można zidentyfikować warunki i potrzeby dotyczące zabezpieczeń (na przykład system elektronicznego przesyłania przelewów). Główna aplikacja może składać się z wielu oddzielnych programów i urządzeń oraz komponentów telekomunikacyjnych. Te komponenty mogą być pojedynczym programem lub kombinacją sprzętu i oprogramowania, której głównym celem jest obsługa konkretnej funkcji związanej z pracą firmy. Aplikacja główna może także składać się z wielu oddzielnych aplikacji, jeśli wszystkie z nich są związane z jedną funkcją (na przykład obsługa wynagrodzeń lub danych pracowników). Jeśli system jest zdefiniowany jako aplikacja główna, która działa na innym systemie ogólnego wsparcia w organizacji:
t powiadom właściciela systemu, że aplikacja ma krytyczne znaczenie lub zawiera wrażliwe informacje, a także udostępnij konkretne wymagania pod względem zabezpieczeń,
t udostępnij operatorowi systemu ogólnego wsparcia kopię planu zabezpieczeń głównej aplikacji,
t poproś o kopię planu zabezpieczeń systemu ogólnego wsparcia i upewnij się, czy zapewnia on właściwe zabezpieczenia dla aplikacji i informacji,
t do części Środowiska systemu planu zabezpieczeń systemu ogólnego wsparcia dołącz informacje zawierające unikalną nazwę oraz identyfikator.
System ogólnego wsparcia składa się z połączonych zasobów informacyjnych, znajdujących się w zakresie tej samej bezpośredniej kontroli kierowniczej, które oferują tę samą funkcjonalność. System ogólnego wsparcia zwykle obejmuje osprzęt, oprogramowanie, informacje, dane, aplikacje, komunikację oraz ludzi, a także zapewnia obsługę wielu użytkowników lub aplikacji. Dla przykładu system ogólnego wsparcia to:
t sieć LAN, włączając w to inteligentne terminalne, które obsługują biuro oddziału,
t sieć szkieletowa infrastruktury,
t sieć komunikacji,
t centrum obróbki danych działu, włączając w to system operacyjny i narzędzia,
t usługa obróbki współdzielonych informacji w organizacji.
Główna aplikacja może działać w systemie ogólnego wsparcia. Plan dla takiego systemu powinien zawierać informacje o planach głównych aplikacji w części Ogólny opis i cele.
Pozostała część tego dokumentu ma pomóc w tworzeniu planu zabezpieczeń. Wszystkie plany zabezpieczeń powinny być oznakowane, traktowane i kontrolowane co najmniej na poziomie wrażliwości zależnym od polityki firmy. Oprócz tego, wszystkie plany zabezpieczeń powinny zawierać datę ostatniej modyfikacji w celu prostego śledzenia i zatwierdzania zmian. Umieszczenie powyższych danych na każdej stronie planu zabezpieczeń może być przydatne, jeśli aktualizacje mają być dokonywane przez wymianę stron. Wszystkie plany rozpoczynają się od poniższej części o nazwie Identyfikacja systemu.
Pierwsza część planu udostępnia podstawowe informacje identyfikujące system. Musi ...
bzyk268