Business Continuity Plan “oczami” PolishAPI oraz (Wytycznych) EBA

Temat bezpieczeństwa informacji jest ostatnio bardzo „na topie”. Szczególnie, że coraz więcej podmiotów zainteresowanych jest integracją z bankami przy użyciu API. W ostatnich dwóch (klik1; klik2) artykułach przeszliśmy przez pierwsze dziewięć rekomendacji grupy ds. Polish API przy Związku Banków Polskich. Czas na kolejne. Tym razem nieco o zapewnieniu ciągłości działania i zarządzaniu ryzykiem operacyjnym i bezpieczeństwa, a także cyberbezpieczeństwie (nieco więcej na ten temat w tym artykule). W dużej mierze odniesiemy się także do wytycznych EBA w sprawie ryzyk operacyjnych oraz bezpieczeństwa, które są bardziej szczegółowe niż wytyczne grupy ds. PolishAPI.

Jednym z ważnych elementów jest zapewnienie, że w przypadku ewentualnych awarii (lub innych incydentów operacyjnych) podmiot (zarówno Third Party Providers, jak i banki) będzie w stanie przywrócić normalne funkcjonowanie usługi lub usług. Innymi słowy, taki podmiot musi wdrożyć tzw. Business Continuity Plan (plan ciągłości działania), które po wdrożeniu powinny podlegać regularnym przeglądom (szczególnie, że przykładowo wersja oprogramowania „krytycznego” może zmieniać się bardzo dynamicznie).

Czym są BCP?

Najprościej rzecz ujmując to plany zapewnienia, że istotne/krytyczne funkcje instytucji zostaną przywrócone tak szybko jak to możliwe w przypadku wystąpienia zdarzenia/incydentu (najczęściej o niskim prawdopodobieństwie wystąpienia). Plany przygotowuje się w oparciu o wyniki wpływu na biznes, tzw. Business Impact Analysis oraz oceny ryzyka dokonanej zgodnie z odpowiednią metodologią (pomocne będą Wytyczne EBA w sprawie ryzyk operacyjnych i bezpieczeństwa – w szczególności wytyczna 6.2). Istotne jest to, że plany ciągłości działania mogą być również częścią umów outsourcingowy, jeżeli podmiot zamierza powierzyć wykonywanie określonych funkcji krytycznych lub istotnych (więcej na ten temat w tym artykule).

Od czego zacząć?

Od wspomnianej już analizy ryzyka oraz analizy wpływu na biznes, przy czym zaznaczyć należy, że jest to element szerszego Systemu Zarządzania Ryzykiem, choć może być on odrębnym procesem (wszystko zależy od przyjętego modelu biznesowego oraz jego skali).

Kwestię tę porusza rekomendacja 4.13 grupy PolishAPI oraz wytyczna 3 (wspomniane wytyczne EBA). Generalnie dostawca (bank czy TPP) musi mieć odpowiednie procesy testowania bezpieczeństwa (zarówno infrastruktury, jak i oprogramowania czy też samej sieci) oraz analizy i ograniczenia (a także akceptowania) określonych ryzyk związanych z wykorzystywaniem m.in. standardu PolishAPI, ale i pozostałych komponentów systemów bezpieczeństwa. Opiera się to na identyfikacji luk bezpieczeństwa (nieco więcej o cyberbezpieczeństwie w tym artykule) oraz procedury ich eliminacji. W dalszej kolejności obejmuje to konieczność regularnego „patchowania” oprogramowania (aktualizowania), przy czym krytyczność określonych poprawek może wymuszać szybszą reakcję (te zasady powinny zostać odpowiednio opisane).

Następnym ważnym elementem będzie przeprowadzanie regularnych vulnerability tests, czyli testów podatności na określone zagrożenia (te mogą być utożsamiane z testami penetracyjnymi – te w rekomendacji PolishAPI są oddzielone). Testy powinny odbywać się w oparciu o metodykę własną lub branżową, np. OWASP. Generalnie zaleca się przeprowadzanie takich testów co najmniej raz w roku, jednak ze względu na zmieniające się otoczenie (i nowe metody cyberataków) rekomendowanym rozwiązaniem będzie testowanie przy okazji „krytycznych” modyfikacji i/lub po poważnych incydentach.

Grupa PolishAPI rekomenduje także wykorzystanie odpowiednich technik wykrywania i zapobiegania włamaniom. To z kolei prowadzi do konieczności wdrożenia odpowiedniego systemu monitorowania ruchu sieciowego i wykrywania takich zachowań użytkowników, które mogą świadczyć o potencjalnym ataku.

Patrząc nieco szerzej, podmiot powinien dokonać odpowiedniej identyfikacji funkcji biznesowych oraz procesów je wspomagających (np. informatycznych) oraz zasobów i sklasyfikować je jako znaczące (lub inne). Należy dodatkowo opracować scenariusze wariantowe, które pozwolą na dokonanie oceny konkretnych ryzyk operacyjnych i bezpieczeństwa (i nadania im odpowiedniej wagi). W efekcie można podjąć ewentualne działania w zakresie konieczności wprowadzenia modyfikacji środków bezpieczeństwa czy technologii. Taka identyfikacja spełnia również wymóg Business Impact Analysis.

Mamy ryzyka, mamy ich wagę. Co dalej?

Przeprowadzenie powyższych analiz umożliwia przygotowanie BCP. Rekomendacje PolishAPI wskazują na konieczność zachowania jednolitej struktury planów, aby były ze sobą spójne (podział BCP może wynikać chociażby z charakteru określonych zagrożeń (fizyczne, katastrofy naturalne czy cyberataki). Podlegać one muszą regularnemu sprawdzaniu oraz ewentualnym korektom i ocenie.

Plan ciągłości działania powinien zawierać co najmniej listę procesów krytycznych (z uwzględnieniem informacji czy dana funkcja lub proces podlegają outsourcingowi (warto skorelować taki plan z rejestrem umów outsourcingowych). Do procesów tych należy przypisać priorytety (np. wysoki, średni, niski) oraz czasami reakcji (RPO – Recovery Point Objective oraz RTO – Recovery Time Objective). BCP to także opis tego jak podmiot będzie funkcjonował w przypadku wystąpienia sytuacji kryzysowej (co obejmuje wskazanie osób odpowiedzialnych za poszczególne czynności – w tym kontakt z regulatorem i komunikację z klientami), a także jakie działania zostaną podjęte (np. jakie awaryjne rozwiązania można uruchomić, aby częściowo zapewnić funkcjonalność systemów).

Scenariusze

Rekomendacja grupy ds. PolishAPI milczy w tej kwestii, ale warto odnieść się kolejny raz do Wytycznych EBA. Zgodnie z wytyczną 6.4 w BCP powinno rozważyć się różne scenariusze, w tym skrajne (choć prawdopodobne) i ocenić potencjalny wpływ tych scenariuszy na funkcjonowanie podmiotu. Z jednej strony jest to element zarządzania ryzykiem, a z drugiej jest to szerszy zakres informacji na potrzeby BCP. W oparciu o te scenariusze należy dodatkowo wypracować plany działania (naprawy). Szczególnym przypadkiem będą też tzw. Exit Plans, które przygotowuje się na potrzeby umów outsourcingowych na funkcje krytyczne/istotne.

Takie plany naprawy powinny skupiać się na wpływie wystąpienia incydentu na działanie kluczowych funkcji, procesów, systemów transakcji i współzależności. Powinny podlegać one aktualizacji po przeprowadzeniu testów penetracyjnych. Takie scenariusze (lub całe BCP) powinny być udostępniane jednostkom biznesowym i technologicznym, a przynajmniej powinny być one łatwo dostępne. To drugie rozwiązanie jest o tyle zasadne, że patrząc przez pryzmat realizacji zasady „deny all” dostęp do tego typu dokumentów/informacji powinien być ograniczony.

Jeszcze chwilkę o testowaniu

Samo stworzenie BCP to niestety za mało. Bardzo ważne jest zapewnienie, że organizacja jest przygotowana na wystąpienie tego typu zdarzeń. Dlatego tak istotne jest sprawdzenie czy pracownicy, systemy i infrastruktura są „przygotowani” na wystąpienie sytuacji kryzysowych (co obejmuje również odpowiednią komunikację). Takie testy powinny odbywać się co najmniej raz w roku i obejmować scenariusze przedstawione w planie (mogą one oczywiście odbywać się na zasadzie stress-testów i z użyciem podobnej metodologii). Istotne jest, aby po ich przeprowadzeniu wyciągnąć odpowiednie wnioski i dostosować BCP.