Ocena bezpieczeństwa rozwiązań IT w instytucji finansowej

Zarządzanie ryzykiem IT nie jest prostym zadaniem nawet w małej organizacji bez skomplikowanej, wielopokoleniowej historii wdrożeń. Jak zatem podejść do tego problemu w banku z bagażem historii systemów i doświadczeń?

Skala międzynarodowej instytucji finansowej potrafi przytłoczyć. Różnorodność rodzajów działalności, ilość klientów, pracowników, portfolio produktów, poziom skomplikowania środowiska IT, procesów, struktury organizacyjnej, długu technologicznego. Jak więc w tego typu instytucje, często z historią sięgającą parę dekad lub wręcz wieków wstecz, wmontować komponent odpowiadający za bezpieczeństwo informacji? Odpowiadając na to pytanie należy wyjaśnić na wstępie kilka zagadnień. Jak wygląda środowisko IT w instytucji finansowej? W jakim kontekście funkcjonuje dział bezpieczeństwa informacji? Jak wygląda struktura takiego działu i podział obowiązków? W jaki sposób dział bezpieczeństwa powinien angażować się w nowe projekty, które z nich powinien oceniać i według jakich kryteriów? Celem artykułu jest próba odpowiedzenia na te pytania, wraz z przytoczeniem konkretnych problemów oraz przykładów rozwiązań.

Przed dalszą lekturą pozwalam sobie na kilka zastrzeżeń: w tekście zamiennie będą stosowane terminy polskojęzyczne i anglojęzyczne. Nie będę również stosował konkretnych nazw procesów, stanowisk i jednostek organizacyjnych. Wynika to z faktu, że każda organizacja stosuje inną terminologię w tym obszarze. Kilka nazw własnych się jednak pojawi, ale tylko aby uczynić tekst bardziej czytelnym i przejrzystym. Terminy: instytucja, instytucja finansowa i organizacja będą stosowane zamiennie. Termin „analiza”, na potrzeby artykułu, będzie odnosił się do procesu wstępnej analizy projektu, termin „ocena” zaś do oceny bezpieczeństwa danego rozwiązania. Artykuł opiera się o praktyki i standardy stosowane w brytyjskim sektorze finansowym, więc nie poruszam tutaj (poza jednym wyjątkiem), kwestii rekomendacji D wydanej przez KNF. Ostatnie zastrzeżenie – przedstawiony proces nie jest żadnego rodzaju niezależnym audytem, dlatego też analityk może sobie pozwolić na precyzyjne rekomendacje odnoszące się do konkretnych systemów, rozwiązań, dostawców itd. 

Środowisko IT

W większości przypadków środowisko IT to bardzo heterogeniczny i wielowarstwowy twór, którego architektura ewoluowała wiele lat. Wpływ na nią miały również różnorakie strategie organizacji, przejęcia innych podmiotów i fuzje, cięcia kosztów i napływy kapitału, wszelakie trendy w świecie sprzętu i wytwarzania oprogramowania oraz częste zmiany na różnych szczeblach zarządczych. Na środowisko IT w instytucjach finansowych składają się m.in. potężne farmy mainframe’ów, stanowiące jego szkielet. Wokół nich funkcjonuje rozbudowany system rozwiązań klasy midrange (np. różnego rodzaju bram sieciowych lub rozwiązań wspierających analitykę biznesową), a także – kluczowe z punktu widzenia modelu biznesowego – aplikacje webowe dostarczające usługi klientom, hurtownie danych czy systemy CRM. Są to także setki systemów wspierających obsługę działania organizacji, począwszy od systemów helpdeskowych, poprzez kadrowo-płacowe, po komunikatory i pakiety biurowe – coraz częściej hostowane w środowisku chmurowym. Warto dodać, że każdy z wymienionych obszarów jest realizowany przez rozliczne i różnorodne technologie, często przestarzałe, pozbawione wsparcia oraz choćby szczątkowej dokumentacji. Retencja wiedzy jest problemem w każdej dużej instytucji, zwłaszcza w kontekście działu IT.

Kontekst organizacyjny

Największą popularność, w szeroko pojętej branży finansowej, zdobyły dwa modele funkcjonowania działu bezpieczeństwa informacji. Pierwszy z nich zakłada, że „bezpieczników” należy traktować jako element pionu technologii. Pod szefa działu IT zostaje podporządkowany szef działu bezpieczeństwa informacji (CISO, CSO [1]) a wraz z nim cała struktura tego działu. Niesie to za sobą dalekosiężne implikacje. Więcej na ten temat zainteresowani odnajdą w publikacjach stowarzyszeń branżowych, takich jak ISACA lub ISC2 [2]. Drugi model zakłada wyłączenie działu bezpieczeństwa jako oddzielnego pionu, raportującego bezpośrednio do prezesa lub rady nadzorczej. Większość organizacji orbituje pomiędzy tymi dwoma modelami, zbliżając się do pierwszego lub drugiego podejścia. Warto podkreślić, że podobnie jak w akapicie dotyczącym środowiska IT, modele funkcjonowania pionu bezpieczeństwa w organizacji mogą się zmieniać w czasie.

Kolejnym istotnym elementem składowym kontekstu organizacyjnego jest wewnętrzna struktura działu bezpieczeństwa informacji. Na potrzeby tego artykułu przyjęto, że struktura, w której realizowany jest proces oceny bezpieczeństwa rozwiązań IT wygląda jak na poniższym schemacie. Nie jest to model ogólnobranżowy ani dobra praktyka. Niemniej jednak raport „Structuring the Chief Information Security Officer Organization”, wydany przez Software Engineering Institute [3], definiuje Architekturę Bezpieczeństwa jako jedną z funkcji roli CISO, odpowiadającą za utrzymanie i rozwój tejże [4].

W tym modelu wszelkie kompetencje powiązane z szeroko rozumianym bezpieczeństwem zostały powierzone CISO (również bezpieczeństwo fizyczne). W jego strukturach znajduje się zespół Architektury Bezpieczeństwa, który odpowiada (jako jeden z komponentów) za bezpieczny rozwój i utrzymanie środowiska IT w instytucji finansowej. Na temat zadań tego zespołu więcej w publikacji brytyjskiego National Cyber Security Centre „How the NCSC thinks about security architecture” [5]. Praktyczne dostosowanie i ocena istniejących oraz wdrażanych rozwiązań technologicznych pod kątem modelu przyjętego przez Architekturę Bezpieczeństwa jest rolą zespołu Oceny Bezpieczeństwa Informacyjnego. Proces takiej oceny jest głównym tematem rozważań zawartych w tym artykule.

Wstępna selekcja

Ze względu na charakter środowiska IT oraz otoczenia bliższego (konkurencja i klienci) i dalszego (m.in. regulatorzy) organizacji, codziennie prowadzone są w niej setki projektów [6]. Aby zapewnić efektywne wsparcie dla tych najbardziej kluczowych, należy wprowadzić swego rodzaju „sito”, przez które wszystkie projekty [7] powinny przejść. Jeśli dany projekt ma na celu implementację przeanalizowanego już rozwiązania, przy zachowaniu wszelkich warunków bez zmian, nie powinien być on ponownie analizowany [8]. Zawsze jednak tego typu decyzje należy podejmować po konsultacji z managerem lub sponsorem projektu.

Proces wstępnej analizy opiera się na konkretnych kryteriach. Oto kilka przykładów, na których można bazować w twórczy sposób:

• kryterium operacyjne: czy rozwiązania wdrażane przez projekt mogą mieć znaczący wpływ na funkcjonowanie organizacji?
• kryterium reputacyjne: czy rozwiązania wdrażane przez projekt mogą mieć znaczący negatywny wpływ na reputację organizacji? jeśli tak, to jak duży i jakie będą potencjalne koszty?
• kryterium regulacyjne: czy rozwiązania wdrażane przez projekt mogą potencjalnie naruszać regulacje krajowe i międzynarodowe?

Sposób ewaluacji powyższych kryteriów oraz wartości, w jakich mogą być wyrażane, nie są tematem tego artykułu. Z praktyki jednak wiadomo, że najpopularniejszy przelicznik to pieniądze lub czas. Taka wstępna analiza wpływu na biznes może być wyrażona w formie jakościowej, ilościowej lub mieszanej. Z punktu widzenia bezpieczeństwa istotne jest również, by taka ocena uwzględniała, jakie informacje będzie przetwarzał potencjalny system i jak te informacje są sklasyfikowane (np. ze względu na poufność). Innymi słowy, jest to wstępne „sito”, przez które przechodzą projekty, które następnie są lub nie są poddawane ocenie.

Po tym wstępnym „sicie” nadal pozostaje sporo pracy do wykonania. Dlaczego nie możemy od razu rozpocząć procesu oceny? Jest to skutkiem różnic w postrzeganiu rzeczywistości przez „bezpieczników” a interesariuszy projektu. Z perspektywy zespołu odpowiadającego za ocenę bezpieczeństwa zdarza się, że dane rozwiązanie jest przeszacowane lub niedoszacowane. Przeszacowanie polega na przypisaniu danemu projektowi zbyt wysokich wartości w procesie wstępnej oceny, innymi słowy projekt ocenia, że rozwiązanie jest krytyczne dla organizacji, podczas gdy z punktu widzenia bezpieczeństwa tak nie jest. Analogicznie należy rozumieć niedoszacowanie. Jest to sytuacja, w której projektowi przypisano, zdaniem zespołu oceny bezpieczeństwa, zbyt niskie wartości. W obu przypadkach powinno się przeprowadzić konsultacje z interesariuszami projektu oraz wyjaśnić wszelkie istniejące wątpliwości. Ten etap współpracy z projektem ma na celu określenie, czy wyniki wstępnej analizy zostaną skorygowane, czy też osoby prowadzące projekt przedstawią uzasadnione powody, dla których wyniki analizy są takie, a nie inne. Jak widać elementem istotnym w pracy analityka są kompetencje miękkie, niezbędne do tego rodzaju konsultacji.

Określenie charakterystyki i zakresu przedmiotu oceny

Zakładając, że etap „sita” jest już zakończony, w kolejnym kroku należy zgromadzić więcej informacji o przedmiocie oceny. Określenie charakterystyki i zakresu przedmiotu oceny opiera się głównie na analizie dokumentacji, organizacji spotkań i korespondencji z kierownikiem projektu oraz zespołem wdrożeniowym. Celem tej pracy jest określenie charakteru projektu. Oto kilka przykładów takich charakterystyk:

• migracja do chmury publicznej systemu odpowiadającego za obsługę łańcucha dostaw;
• przeniesienie grupy użytkowników do nowej domeny AD [9] oraz wygaszenie starej;
• modernizacja infrastruktury fizycznej wraz z aktualizacją OS [10] do najnowszej wersji;
• nowe funkcje w aplikacji mobilnej;
• wdrożenie SSO [11] dla systemu obsługującego urlopy;
• implementacja nowego IAM-a [12] w dziale HR.

Określenie potencjalnych zagrożeń

Po określeniu zakresu i charakterystyki przedmiotu oceny rozpoczyna się proces określania potencjalnych zagrożeń. Zapożyczając słownictwo ze świata testów penetracyjnych, określana jest tak zwana powierzchnia ataku (z eng. attack surface). Jest to suma punktów, które potencjalny atakujący może wykorzystać do przejęcia kontroli nad systemem lub dokonania innych naruszeń bezpieczeństwa. Jedną z ról polityki bezpieczeństwa i dokumentów z nią związanych jest wskazanie dróg i sposobów redukowania tej „powierzchni”. Mowa tu o całej gamie środków, procesów, rozwiązań technologicznych i istniejących już zabezpieczeń. Na potrzeby artykułu te mechanizmy kontrolne zbiorczo nazwane będą „kontrolkami” lub „kontrolami”.

Ocena bezpieczeństwa rozwiązania technologicznego

Na tym etapie dokonywana jest ocena doboru kontrolek oraz poprawności ich zaprojektowania. Nie jest oceniana ich efektywność. Dlaczego? Ponieważ projekt jest jeszcze w fazie wdrożenia lub wcześniejszej, więc nie ma możliwości pobrania próbek i zbadania efektywności mechanizmów kontrolnych. Proces jest czasochłonny, ponieważ osoba zajmująca się oceną bezpieczeństwa często musi pozyskać wiedzę na temat stosowanych przez projekt komponentów, ich konfiguracji, rozwiązań związanych z bezpieczeństwem, stosowanej przez projekt metodyki tworzenia oprogramowania (organizacja może mieć ich wiele, czasem projekty podążają swoją własną ścieżką, bez wsparcia jakiejkolwiek metodyki) i budowania rozwiązań IT, podejścia i logiki biznesowej systemu. Często konieczne jest również odtworzenie i przygotowanie diagramu przepływu informacji [13] oraz ustalenie jak elementy warstwy aplikacyjnej są mapowane na infrastrukturę. Wiedza tego typu jest rozsiana po całej organizacji, również poza działem technologii.

Swego rodzaju wyzwaniem jest również określenie modelowego rozwiązania, do którego ma się odnosić projekt. W najprostszych przypadkach instytucja zapewnia analitykowi pewien udokumentowany standard lub schemat, który potem może służyć jako punkt odniesienia w procesie oceny. Przykładem takiego schematu jest standardowa konfiguracja serwera druku. Jednakże najprostsze przypadki to rzadkość. Najczęściej do oceny trafiają wielkoskalowe, skomplikowanie i wielofazowe projekty. Dzieje się tak, ponieważ to tego rodzaju rozwiązania spełniają kryteria progowe wynikające z analizy wstępnej. W wielu przypadkach są to unikalne systemy ze swoimi unikalnymi problemami. Dlatego tak istotne w pracy analityka zajmującego się oceną bezpieczeństwa jest ciągła edukacja i rozwój. Stoi przed nim zadanie nie tylko oceny bezpieczeństwa rozwiązania, ale także zbudowania lub doprecyzowania modelu odniesienia, dzięki któremu taka ocena może zostać przeprowadzona. Często z pomocą przychodzi tutaj szereg rozwiązań organizacyjnych, proceduralnych lub technicznych, nie zawsze jednak są one w stanie odpowiedzieć precyzyjnie na pytania, które analityk zadaje sobie na co dzień. Warto je postrzegać raczej jako rodzaj drogowskazu, wskazanie generalnego podejścia, ułatwiające podjęcie dalszych kroków, ale nie definiujące te kroki. Istnienie tego typu „szarej strefy” wynika z faktu, że żadna organizacja nie jest w stanie wyspecyfikować i określić wszystkich przypadków, z jakimi może się zetknąć analityk w toku swojej pracy. Innymi słowy, w heterogenicznym i nieustannie zmiennym środowisku IT nie ma możliwości, aby zawsze istniała „procedura” lub „model” oceny każdego przypadku. Analityk sam musi taki model wypracować.

Rozbieżności od ustalonych mechanizmów lub dobrych praktyk, a także ich braki są konsultowane z kierownikiem projektu i osobami odpowiadającymi za dany fragment projektu. To, czego nie można poprawić przed „go-live” lub co świadomie zostało pominięte (np. jako decyzja biznesowa), jest podsumowywane w formie raportu wraz z rekomendacjami.

Usystematyzowane podejście

Na potrzeby artykułu przyjmę uproszczoną metodykę oceny bezpieczeństwa, opartą częściowo na Standard of Good Practise (dalej jako SoGP) [14]. Zakłada ona cztery fazy oceny:

Faza „Questions” – faza, w której tworzy się swoisty profil/opis ocenianego rozwiązania za pomocą pytań doprecyzowujących. Wiedza tu zdobyta jest wykorzystywana w fazie „Threats”.

Faza „Threats” – faza, w której określa się zagrożenia dla ocenianego systemu. Etap ten jest ściśle powiązany z kontrolkami (etap „Controls”). Warto jednak wyraźnie podkreślić, że modelowanie zagrożeń to oddzielny i krytyczny etap w procesie oceny bezpieczeństwa. Analityk może skorzystać w tej fazie z listy predefiniowanych, wysokopoziomowych zagrożeń. Proces nie ogranicza go jednak do tej palety, w każdym momencie jest możliwe dodanie nowych zagrożeń jako elementu oceny. Standard SoGP zawiera szeroką paletę potencjalnych zagrożeń wraz z algorytmem ich doboru, zainteresowanych odsyłam do publikacji ISF. Alternatywnie polecam zapoznać się ze metodą STRIDE.

Faza “Controls” – faza, w której określane są modelowe kontrole, mające zapobiegać zagrożeniom. Bazując na standardzie SoGP i zestawie mechanizmów kontrolnych tam zawartych, można określić model odniesienia, o którym wspominałem w jednym z akapitów powyżej. Tego typu model jest punktem referencyjnym. Rozbieżności od modelu są opisywane w raporcie jako potencjalne ryzyka.

Faza “Reports” – faza, w której tworzony jest raport dla kierownika i sponsora projektu, zawierający rozbieżności między stanem oczekiwanym a rzeczywistym, wraz z rekomendacjami.

Praktyczny przykład

Po teoretycznym wstępie zaprezentuję w kilku akapitach poniżej konkretny przykład oceny bezpieczeństwa. Będzie on zawierał wiele uproszczeń, jednakże celem artykuł jest jedynie ramowa prezentacja procesu.

Przedmiotem oceny bezpieczeństwa będzie wdrożenie systemu kadrowo-płacowego w instytucji finansowej. Kadry jako sponsor projektu planują zastąpienie nim obecnego rozwiązania. Projekt jest częścią szerszego portfolio, obejmującego zmiany organizacyjne w pionie księgowo-kadrowym. Przyjmując kryteria opisane kilka akapitów powyżej, analiza wstępna wskazuje, że system jest krytyczny pod kątem uwarunkowań regulacyjnych, istotny dla działalności operacyjnej organizacji i nieistotny z punktu widzenia jej reputacji [15]. System ma obsługiwać pracowników z całego kraju, jest to około 10 tys. osób.

Ten zestaw informacji dostarczany jest dedykowanemu analitykowi wraz z kontaktami do kierownika projektu i osoby odpowiadającej za wdrożenie od strony technologicznej. Analityk rozpoczyna swą pracę od przeanalizowania dokumentacji projektowej, w tym w szczególności od opisu funkcjonalnego i technicznego rozwiązania. Z tego obrazu wyłaniają się kolejne elementy układanki. System ma być swoistym „kombajnem” kadrowo-płacowym, obsługującym m.in. wystawianie pasków płacowych, proces oceny rocznej dla pracowników, proces nadawania nagród rocznych i uznaniowych, wnioski urlopowe, zwolnienia lekarskie, procesy wspierające JML [16] i wiele innych.

W oparciu o pozyskane informacje analityk rewiduje wyniki wstępnej analizy przeprowadzonej przez sponsorów projektu. Rozpatrywany system realizuje pomocnicze [17], ale również krytyczne zadania dla organizacji. Przetwarza także dane osobowe (w tym dane wrażliwe dotyczące zwolnień lekarskich), dane kadrowo-płacowe i tajemnice przedsiębiorstwa (m.in. wysokość płac, informacje o awansach pracowniczych i premiach) oraz uczestniczy częściowo w procesie wypłat wynagrodzeń. Analityk wraca więc do managera projektu i jego sponsorów w celu ponownego przedyskutowania analizy wpływu i jej wyników. Interesariusze projektu argumentują, że najbardziej krytyczne procesy mogą być ad-hoc wykonywane na papierze lub mailowo, tak więc organizacja nie będzie miała do czynienia z nagłym wstrzymaniem wynagrodzeń lub chaosem w zwolnieniach lekarskich. Dyskusja przynosi konsensus: potencjalne problemy związane z implementacją i późniejszym działaniem systemu dla reputacji organizacji zostają ocenione jako krytyczne. Bez zmian pozostaje wynik analizy wpływu systemu na działalność operacyjną – procesy zależne od systemu, jak już zostało powiedziane, mogą być realizowane w inny sposób. Dla przypomnienia dodam, że analizujemy tu narzędzie do obsługi procesu, a nie sam proces.

W toku dalszych prac analityk pozyskuje informacje istotne z punktu widzenia oceny rozwiązania pod kątem bezpieczeństwa i modelowania zagrożeń. Przygotowuje zestaw pytań, który doprecyzowuje informacje zawarte w dokumentacji [18]. Oto przykłady takich pytań (na potrzeby artykułu pytania są prezentowane wraz z odpowiedziami):

• Gdzie system będzie hostowany? – wewnętrznie, data center organizacji;
• Kto tworzy rozwiązanie? – jest to tzw. „Inhouse development”, czyli zespół programistów pracujących w firmie;
• Kto będzie utrzymywał system? – Dział Utrzymania i Dział IT;
• Kto będzie zarządzał systemem? – zespół wyznaczony przez sponsorów projektu, obecnie na etapie tworzenia;
• Jakie technologie i komponenty będą wykorzystywane? – infrastruktura wirtualna we własnym data center, 3x RHEL [19] jako OS, Oracle Database jako RDBMS [20], aplikacja webowa tworzona w Javie, API REST jako interfejs pomiędzy warstwą aplikacyjną a backendem;
• Czy system będzie dostępny spoza sieci wewnętrznej? – nie, wyłącznie z sieci wewnętrznej organizacji.

Powyższe informacje pozwalają na ukończenie pierwszej fazy oceny („Questions”) i przejście do kolejnej, czyli określenia zagrożeń („Threats”) i mechanizmów kontrolnych („Controls”). Analityk najczęściej wykonuję tę pracę przez kilka dni lub tygodni, będąc w stałym kontakcie z projektem. Na potrzeby artykułu praca ta zostanie nieco skondensowana. Zagrożenia prezentowane poniżej są jedynie przykładami. Metodyka SoGP zakłada istnienie ponad 160 kontrolek, analogicznie jak w przypadku zagrożeń, w przytoczonym przykładzie skupiamy się zaledwie na kilku związanych z zarządzaniem dostępem, cyklem życia oprogramowania i monitorowaniem systemu. Obie fazy – „Controls” i „Threats” – są opisane wspólnie, ponieważ są od siebie ściśle zależne. W przykładzie uwzględniono istotną dobrą praktykę, która powinna być stosowana zarówno w procesie oceny, jak i ogólnie w procesie projektowania systemów. Jest to „defense in depth”. Mowa o podejściu, w którym wiele mechanizmów zabezpieczających odpowiada na jedno lub kilka zagrożeń, choćby częściowo. Ale zawsze powinniśmy mieć więcej niż jeden mechanizm. Jak to wygląda w praktyce? Rzućmy okiem na tabelę prezentującą wybrane zagrożenia i kontrole:

Jak widać powyżej, system w pełni kontroluje dostęp użytkowników. Z perspektywy użytkownika: każdy zalogowany do sieci korporacyjnej nie musi oddzielnie logować się do nowej aplikacji HR. Projekt może sobie na to pozwolić, ponieważ wszyscy użytkownicy są pracownikami firmy i posiadają konta domenowe (system nie obsługuje kontraktorów). Tabela w kilku przypadkach zawiera powtarzające się zagrożenia lub mechanizmy kontrolne. Wynika to z relacji wiele do wielu, o której pisałem w poprzednim akapicie. Warto zaznaczyć, że ostatni wiersz zawiera tylko jedną kontrolkę, jednak każdy standard CIS zawiera wiele setek stron rekomendacji. Analityk ujął zgodność z CIS jako jedną „meta” kontrolkę. Na koniec dodajmy, że testy penetracyjne infrastruktury nie wykazały znaczących podatności.

W ten sposób analityk nakreślił funkcjonujące zabezpieczenia. Odnalazł również kilka problemów. Oto pierwszy z nich: w odróżnieniu od testów penetracyjnych infrastruktury, testy penetracyjne warstwy aplikacji wskazały jako problem nieaktualne biblioteki, z których korzystano podczas tworzenia oprogramowania, a także możliwość zdalnego wykonania kodu poprzez usługę Java Debug Wire Protocol (odpowiednio CVSS 8.0 i 8.9 [22]). Drugi problem to wykorzystywanie danych produkcyjnych na środowiskach testowych. Z uwagi na presję czasu i brak rąk do pracy projekt nie przygotował danych testowych ani też nie zanonimizował danych przed ich użyciem w ramach testów. Analityk, w toku pracy z dokumentacją i diagramami opisującymi przepływ danych, ustalił również, że system jest punktem krytycznym dla wielu procesów (pomijając te, które sponsorzy określili jako wykonalne przy użyciu dokumentacji papierowej lub mailowej). Oznacza to, że w przypadku awarii nie da się go zastąpić w żaden sposób innym systemem i wpływa znacząco na inne systemy. W toku dalszej pracy ustalono, że system korzysta z JWK [23] w zakresie autoryzacji i autentykacji dostępu do interfejsu API REST. Projekt nie jest w stanie potwierdzić, że klucz prywatny jest przechowywany w bezpieczny sposób (JWK korzysta z RSA do podpisywania tokenów). Jest to znaczący problem, jednak organizacja posiada narzędzia i rozwiązania służące do obsługi tego typu kluczy (dla zainteresowanych: rozwiązania klasy credential vault). Ostatnim z zauważonych problemów jest brak zapewnienia odpowiedniej rozdzielności obowiązków (SoD [24]) między rolami kierownika i użytkownika działu kadr i płac w procesie rekrutacji nowych pracowników. Część z kroków w tym procesie była zdublowana pomiędzy tymi rolami.

Finałem pracy naszego analityka jest przygotowanie raportu z procesu oceny bezpieczeństwa. Dokument taki zawiera między innymi krótkie podsumowanie przeglądu, dokładny opis problemów i ryzyk z nimi związanych oraz rekomendacje dotyczące ich likwidacji lub ograniczania. Rekomendacje te powinny być precyzyjne i konkretne oraz dopasowane do specyfiki organizacji. Powinno się unikać ogólnych i generycznych stwierdzeń w rodzaju: „Należy wdrożyć odpowiednie mechanizmy służące zapewnieniu poufności danych”. Rekomendacje powinny wskazywać na konieczne działania naprawcze z szerokiego wachlarza, jak choćby zmiany organizacyjne dla zapewnienia rozdziału obowiązków, aktualizacje bibliotek oprogramowania, wdrożenie dodatkowych komponentów, zmiana konfiguracji, zmiana architektury rozwiązania albo wykonanie dodatkowych, bardziej szczegółowych testów jak przegląd kodu źródłowego aplikacji.

Raport powinien zostać sprawdzony przez innego członka zespołu lub zespół QA oraz przekazany stronie zainteresowanej do akceptacji. W ramach tego procesu na dokument nanosi się korekty, przedyskutowuje ponownie odnalezione problemy i wstępnie je wycenia. Projekt może zdecydować się na zlikwidowanie znalezionych problemów, częściowo zredukować ryzyko lub je zaakceptować. Sponsor projektu (jako finansujący) decyduje, czy problemy zostaną usunięte przed uruchomieniem systemu. W skrajnych przypadkach może to wymagać przemodelowania architektury rozwiązania, zmiany dostawcy lub wstrzymania projektu do czasu opracowania rozwiązania. Jeśli zostanie podjęta inna decyzja, projekt jest zobowiązany do formalnej akceptacji ryzyka, zgodnie z obowiązującym w organizacji procesem. Analityk może być zaangażowany w proces usuwania odnalezionych luk i problemów jako konsultant. Jego rolą jest też końcowe określenie, w jakim stopniu mechanizmy kontrolne zredukowały ryzyko, jeśli projekt podejmuje się wdrożenia takich mechanizmów. W tym miejscu kończy się proces oceny bezpieczeństwa.

Powyżej opisana sytuacja odnosi się do modelu, w którym dział bezpieczeństwa jest elementem pionu technologii. Wówczas mandat CISO, a co za tym idzie, osób związanych z oceną bezpieczeństwa, nie pozwala im na zatrzymanie projektu w obliczu istotnych ryzyk wykazanych przez analityka. Decyduje biznes, czyli sponsor projektu. W drugim modelu, gdzie dział bezpieczeństwa jest wyłączony spod pionu technologii i raportuje bezpośrednio do zarządu, często jest możliwe wstrzymanie wdrożenia. Dzieje się to dzięki większej niezależności od pionu realizującego projekt (technologia) oraz sponsorów projektu. 

Podsumowanie

Uważny czytelnik na pewno zauważył wiele niuansów, które nie zostały w tekście poruszone lub były poruszone w niewielkim stopniu. Celem artykułu było jednak jedynie zarysowanie i uproszczone przedstawienie wybranych procesów, jakie mogą funkcjonować w instytucji finansowej w zakresie bezpieczeństwa. Warto zaznaczyć, że jest to tylko jeden z wielu modeli, w dodatku opisany wyłącznie w kontekście jednego typu organizacji i w odniesieniu do uwarunkowań brytyjskich. Niemniej jednak instytucje finansowe, zarówno brytyjskie, jak i polskie, mogą stanowić swego rodzaju punkt odniesienia dla innych branż. Jest ku temu kilka powodów:

• Jest to sektor ściśle prawnie uregulowany, istnieje szereg regulacji ogólnych i podmiotów je kontrolujących (np. UODO, UOKiK), jak też wyspecjalizowanych (np. UKNF w Polsce, FCA i PRA w Wielkiej Brytanii).
• Działalność finansowa zawsze wiąże się z przetwarzaniem danych osobowych. W obliczu wejścia w życie dyrektywy PSD2 wszelkie dane klientów (w tym osobowe) muszą zostać udostępnione podmiotom trzecim. Nakłada to na instytucje finansowe kolejne wymogi związane z zapewnieniem bezpieczeństwa środowiska IT i danych.
• Bardzo często działalność takich organizacji wymaga wymiany danych z szeregiem instytucji (np. UKNF) i podmiotów prywatnych (np. VISA, Mastercard, Bloomberg, Reuters), z czego też wynika wiele wyzwań związanych z bezpieczeństwem.
• Cała branża opiera się na danych. Przytłaczająca większość transferów finansowych to transfery danych. Dlatego systemy informatyczne służące do przetwarzania danych są kluczowym i krytycznym aktywem takich organizacji.
• Większość istotnych instytucji finansowych w Polsce jest elementem Krajowego Systemu Cyberbezpieczeństwa [25], co za tym idzie musi spełniać szereg wymagań związanych nie tylko z prawem bankowym, ogólnymi regulacjami, jak i RODO, ale również ustawą o Krajowym Systemie Cyberbezpieczeństwa (KSC), którą można traktować jako regulację ściśle nastawioną na zapewnienie bezpieczeństwa i ciągłości działania całej instytucji [26].

Wdrożenie procesu oceny bezpieczeństwa przynosi ze sobą wiele zalet, zwłaszcza w kontekście jego funkcjonowania. Oto kilka z nich:

• porządkuje on wiedzę w zakresie bezpieczeństwa ocenianego rozwiązania;
• jest sformalizowanym i udokumentowanym procesem, co zapewnia powtarzalność rezultatów i ułatwia porównywanie wyników pracy;
• rezultaty jego funkcjonowania stanowią spójny zbiór informacji, który z czasem może stać się fundamentem dla sformalizowanego procesu zarządzania wiedzą w obszarze bezpieczeństwa i technologii; pozwala to projektom na korzystanie z tego zasobu oraz poprawia to ogólną kulturę bezpieczeństwa w organizacji;
• wspiera całe spektrum projektów w instytucji (proces jest na tyle uniwersalny i elastyczny).

Do dyskusji pozostaje ocena tego procesu. Jak widać powyżej, tego rodzaju podejście przynosi ze sobą szereg korzyści. Do sprawnego działania wymaga jednak dużego zaangażowania ze strony specjalistów ds. bezpieczeństwa, osób odpowiadających za projekt oraz osób na stanowiskach decyzyjnych. Sprawdza się tu generalna zasada rządząca wieloma procesami biznesowymi w każdej organizacji – za ich jakość odpowiadają ludzie, nie procedury.

Artur Orłowski