Przenikanie się obszarów bezpieczeństwa fizycznego oraz IT na stałe wpisało się w nasze codzienne obowiązki. Czy tego chcemy, czy nie, prędzej czy później na naszej drodze pojawią się aspekty związane z każdym z nich. Dlatego warto przyjrzeć się zbieżności, która przejawia się tym, że dla każdego projektu dotyczącego bezpieczeństw należy przygotować także… odpowiednią dokumentację IT. I tu bardzo często pojawiają się pewne wyzwania.
Tomasz Dacka

Dojrzałe środowiska wypracowały swoje standardy oraz wytyczne, jak sobie z tymi wyzwaniami radzić. Mimo to nawet jeśli owa dokumentacja została przygotowana z dbałością i starannością, to realizacją zadań zajmują się ludzie, którzy z definicji nie lubią robić tego, na czym się dobrze nie znają. Dlatego bardzo często na etapie przygotowywania projektów pojawiają się ludzie-mosty, łączący ze sobą świat security i IT.

Dwa światy, dwie dokumentacje? Dwa podejścia?

Dokumentacja projektowa prowadzona przez obszar bezpieczeństwa fizycznego skupia się na aspektach stricte z nimi związanych. Można tam znaleźć analizę ryzyka, opis funkcjonalny, rzuty z rozmieszczeniem urządzeń, tabele z zestawieniem danych związanych z urządzeniami typu kamery, kontrolery, NVR-y czy oprogramowanie. Niemniej żadne z tych urządzeń nie pracuje w próżni, są one osadzone w architekturze IT, bardzo często połączone z innymi systemami, usługami IT. Rodzi to potrzebę sporządzenia dokumentacji z obszaru informatycznego, a te z reguły wymagają od nas szerszej wiedzy i dużej dokładności w przedstawianiu danych. Tu pojawiają się pytania: czy zatem potrzebne będą dwie dokumentacje? Najprawdopodobniej tak. Czy mój wkład będzie wymagany w obydwu? Oczywiście. Jak mam sobie z tym poradzić?

Zainteresowane strony

Jeśli musimy upiec naprawdę duży tort i przyozdobić go tzw. compliance (rozumianym jako zapewnienie zgodności działalności z normami, zaleceniami lub stosownymi praktykami), staje się oczywiste, że sami zrobić tego nie możemy. Dlatego tak ważne, aby wskazać (to wcale nie jest proste zadanie) oraz zebrać (kolejne żmudne działanie) wszystkich zainteresowanych. To pierwszy krok do koordynacji dwóch (lub więcej) obszarów. I gdyby tutaj kończyły się tzw. schody, byłoby dobrze, najtrudniejsze jednak jest rozdzielenie obowiązków pomiędzy dane komórki, zespoły. Bardzo często jest to nawet niewykonalne, a powodów jest mnóstwo. Warto jednak takie spotkania organizować, aby poznać możliwości, a przede wszystkim oczekiwania wszystkich zainteresowanych. Dowiemy się wtedy, jakie konkretne dane/aktywności będą potrzebne z naszej strony, kto może nas wspierać i kiedy (oraz jak często) będziemy się spotykać, aby zsynchronizować zadania. W mojej ocenie takie otwierające spotkanie z branżą IT powinno nastąpić jak najszybciej. Dlaczego? Ponieważ zyskujemy świadomość i z tą wiedzą możemy wykonać kolejne kroki podczas następnych aktywności:

• spróbować swoich sił,
• zatrudnić do pomocy kompetentne osoby spoza działu (z wewnątrz lub zewnątrz organizacji),
• przerzucić wymagania np. na wykonawcę, integratora (należy tu jednak pamiętać, że koordynacja wciąż jest po naszej stronie).

W momencie tworzenia dokumentacji przetargowej, zakupowej itp., uzbrojeni w nabytą wiedzę jesteśmy w stanie stworzyć wymagania ściśle nawiązujące do obszaru IT. Nie oznacza to (znam to z własnego doświadczenia), że instalator/integrator zrobi wszystko za nas, otwiera to jednak pole do dyskusji oraz punkt do wsparcia w niektórych aspektach wdrożenia systemów.

Gra do jednej bramki

Wymagania IT będą do nas spływać zazwyczaj równolegle do prowadzonych prac fizycznych, a bardzo często nawet jeszcze przed ich rozpoczęciem. Może nawet wystąpić sytuacja, że nie będziemy mogli uruchomić wiertarki przed spełnieniem szeregu wymagań IT. Projekty informatyczne są zazwyczaj prowadzone wedle pewnych metodologii, bez względu na to, jaki konkretny model wykorzystują. Na tym etapie warto przygotować się do tego, że możemy zmierzyć się z modelem, który został stworzony stricte na potrzeby Software Development Lifecycle (SDLC – cykl życia oprogramowania, czyli proces, z którego korzystają programiści do tworzenia i dostarczania aplikacji w ramach uzgodnionego terminu i budżetu), podczas gdy nasze projekty rzadko zakładają tworzenie własnego oprogramowania, raczej bazują na rozwiązaniach już gotowych, z tzw. półki. Mimo to będziemy musieli się do tego dostosować, co nie powinno stanowić problemu przy naszej jasnej deklaracji na samym początku koordynacji.

Najistotniejszą kwestią na początku jest podzielenie się naszymi wymaganiami biznesowymi co do samej aplikacji, czyli generalnie rzecz ujmując, wytłumaczenie, dlaczego i w jakim zakresie wdrażamy dany system. Pomoże to ustalić wspólny mianownik i da punkt referencyjny do dalszych dyskusji.

Powinniśmy również być gotowi na to, że cały proces wdrożeniowy zostanie podzielony na pewne etapy, bramki. Przy każdym etapie będą wymagane różne informacje oraz inny poziom ich szczegółowości. Ogólnie proces można podzielić na trzy główne bramki:

Bramka nr 1. Przedstawienie założeń biznesowych oraz koncepcji rozwiązania

Bramka nr 2. Przedstawienie architektury rozwiązania (to, jak chcemy budować system)

Bramka nr 3. Przedstawienie systemu gotowego do oddania (to, jak zbudowaliśmy system)

Ważne jest również, że przez wszystkie bramki przechodzi się wspólnie jako zespół. Każda bramka wymaga innego zaangażowania i położenia nacisku na inne aspekty, jednak koordynacja zapewniająca przepływ informacji odgrywa tutaj ważną rolę.

Przejście przez poszczególne bramki będzie możliwe po uzyskaniu pewnych zgód interesariuszy. Uzyskuje się je przeważnie poprzez prezentację zaawansowania swoich prac oraz zgodność z obowiązującymi politykami IT.

Czego się spodziewać?

System zarządzania materiałem wizyjnym (VMS) czy system kontroli dostępu (SKD) jako systemy IT podlegają dokładnie takim samym wymaganiom jak inne systemy ze świata informatycznego, nawet jeśli projektowane i wdrażane są w trochę inny sposób. Generalnie każdy z systemów musi zmierzyć się z wymaganiami IT z trzech różnych dziedzin:

1. architektury IT,
2. cyberbezpieczeństwa, bezpieczeństwa informacji,
3. utrzymania i oddania do użytku.

Każda z wymienionych dziedzin będzie miała swoje wymagania, wspomniany wcześniej compliance oraz dokumenty do uzupełnienia.

Architektura będzie od nas wymagała informacji na temat, w jaki sposób chcemy wdrażać system. Mogą tutaj paść pytania o wykorzystanie sieci korporacyjnej lub wdrożenie na zupełnie oddzielnej sieci. Wszystkie interfejsy łączące dane segmenty sieci muszą zostać wskazane i opisane. Mniej ważny będzie tu typ kamery czy NVR, a ważniejszy może być łańcuch dostaw, informacje na temat producenta (czy np. wykonuje testy penetracyjne, czy posiada własny system zarządzania ryzykiem itp.).

Istotną kwestią jest fakt, czy chcemy łączyć się z innymi systemami, usługami korporacyjnymi, takimi jak Active Directory czy systemy ticketowe (utrzymaniowe).
Ważna jest także odpowiedź na pytanie, na jakiej architekturze będzie bazować nasz projekt:

1. on-premise: wszystkie urządzenia oraz dostępy zamkną się w naszej własnej architekturze w danym miejscu;
2. wykorzystanie usług chmurowych: być może chcemy, aby system (z wyjątkiem urządzeń końcowych) pracował w chmurze;
3. hybryda: chcemy połączenia dwóch powyższych punktów, dzieląc system na część pracującą w danym obiekcie oraz część wyniesioną do chmury (np. interfejs użytkownika).

Każdy wybór będzie pociągał za sobą inny zbiór wymagań i trochę inną drogę do ich spełnienia. Dlatego jest tak kluczowy już na samym początku koordynacji.

Nie unikniemy też różnego rodzaju szacowań ze strony zespołów cyberbezpieczeństwa. Niekiedy jest to naprawdę długa lista wymagań, co do których musimy się ustosunkować. Dlatego tak ważne, aby docelowego dostawcę wybierać uważnie, ponieważ wsparcie producenta/dostawcy będzie tutaj odgrywać kluczową rolę. Zazwyczaj weryfikacji poddaje się dostawcę, łańcuch dostaw oraz samo rozwiązanie i aplikację danego rozwiązania.

Utrzymanie aplikacji w środowisku IT to proces złożony. Zwykle jest to zbiór wielu aktywności (a zatem i dokumentów) składających się na obraz całości. Jako specjaliści od bezpieczeństwa fizycznego/technicznego, ale i biznesowi właściciele projektu będziemy tutaj obarczeni dużą odpowiedzialnością za wkład merytoryczny. Najczęściej zadawane pytania mogą brzmieć następująco:

1. Kto jest odpowiedzialny za utrzymanie danego segmentu systemu?
2. Czy mamy wdrożone umowy SLA (Service Level Agreement, SLA – umowa o gwarantowanym poziomie świadczenia usług)?
3. Czy system został zintegrowany z system ticketowym?
4. Jaki jest model obsługi zgłoszeń serwisowych?
5. Jaki jest model wprowadzania zmian?
6. Pomoc przy wdrożeniu systemu badającego stan techniczny systemu (monitoring systemu).
7. Pomoc przy wdrożeniu dokumentu dotyczącego reagowania na incydenty i zachowania ciągłości działania.
8. Jaki jest model dostępu do systemu?

Detale

Organizacja infrastruktury IT nie leży po stronie działów bezpieczeństwa fizycznego, niemniej jednak wkład merytoryczny z naszej strony bywa kluczowy, szczególnie jeśli niejako „dołączamy się” do sieci już istniejącej. Koordynacja oraz transparentność w przekazywaniu danych jest tutaj wskazana, m.in. przy:

• Określaniu zapotrzebowania na liczbę portów – sprawa, która na pierwszy rzut oka wydaje się banalnie prosta, w rzeczywistości może okazać się problematyczna. Szczególnie systemy CCTV lubią wykorzystywać dużą liczbę portów w przełącznikach. Sieci IT natomiast są budowane w oparciu o konkretne modele z dedykowaną konfiguracją. Domówienie nowych urządzeń w trybie ad hoc może być niemożliwe. Pociąga to za sobą nie tylko koszty, ale także długi czas oczekiwania na dostawę.
• Wskazaniu przepustowości rozwiązania – tutaj sprawa wygląda podobnie do tej omawianej powyżej. Kamery o wysokiej rozdzielczości, nawet przy wykorzystaniu nowoczesnych kodeków obrazu, generują strumień danych, który z punktu widzenia sieci jest „ciężki”. Gdy liczba kamer się zwiększa, wyzwanie gwałtownie wzrasta. I jakkolwiek ruch wewnętrzny w sieci zazwyczaj da się okiełznać, to ten na zewnątrz (np. przy rozwiązaniach czysto chmurowych lub hybrydowych) zaczyna być problematyczny. W czasach pędu do chmury, nie zawsze podpartego technicznymi analizami, takie podejście może okazać się niewykonalne.
• Wskazaniu wszystkich interfejsów – większość producentów rozwiązań proponuje swoje usługi, które w części są dostępne przez instancje chmurowe. Z punktu widzenia cyberbezpieczeństwa jest niezwykle ważne, aby wskazać dokładną architekturę naszego rozwiązania tak, aby można było zidentyfikować wszystkie potencjalne wektory ataku.
• Omówieniu szyfrowania oraz przepływu danych – idąc krok dalej, niezmiernie istotne jest opisanie tego, w jaki sposób dane od urządzeń końcowych, tj. kamery czy karty kontroli dostępu, trafiają do serwerów, instancji chmurowych, użytkowników końcowych. Jakich protokołów używamy, ruch jest jedno- czy dwustronny, jakie mechanizmy szyfrowania zostały wprowadzone w naszej aplikacji?
• Omówieniu segmentacji oraz segregacji sieci – zazwyczaj systemy bezpieczeństwa powinny pracować w oddzielnych podsieciach wraz z opisanymi i wdrożonymi regułami omawiającymi, w jaki sposób odbywa się komunikacja pomiędzy nimi.

W odniesieniu do wszystkich omówionych kwestii kluczowe znaczenie ma nasz wkład merytoryczny. Zdaję sobie sprawę, że nie jest to zadanie proste ani przyjemne i wymaga od nas wyjścia poza pewną strefę komfortu. Pozwala jednak świadomie budować rozwiązania, które mają szansę się obronić i to nie tylko przed audytem. Uważam również, że to nam, jako właścicielom biznesowym, powinno najbardziej zależeć na zgodności z wymaganiami oraz na jak najkrótszym czasie wdrożenia. Faza przygotowania do projektu jest kluczową, aspekty ściśle związane ze światem IT mogą zostać łatwo pominięte ze względu na natłok informacji „z naszego podwórka”. Należy jednak pamiętać, że są one tak samo istotne przy wdrożeniu, jak wybór odpowiednich kamer czy oprogramowania, stanowią przecież fundament, na którym każdy system jest budowany. ⦁

Tomasz Dacka

Ekspert bezpieczeństwa fizycznego. Z branżą związany ponad 12-letnim doświadczeniem, zwolennik holistycznego podejścia do zarządzania bezpieczeństwem. Prywatnie entuzjasta architektury przedwojennej Warszawy.

Zobacz poprzednie artykuły tego autora:

Odporność w bezpieczeństwie
Higiena bezpiecznej pracy zdalnej
Konwergencja bezpieczeństwa
Zarządzanie projektem – wprowadzenie w tematykę
Zarządzanie projektem – poszczególne etapy