Nowelizacja Rekomendacji D tworzy nowy ład w dziedzinie zarządzania ryzykiem informatycznym w bankowości. Sygnity wspiera banki w spełnieniu wymogów rekomendacji, zapewniając sprawdzoną w praktyce metodykę oceny ryzyka, doświadczenie projektowe oraz dedykowane narzędzia wspierające analizy, audyty ibieżące raportowanie w tym zakresie.
Wiesław Wyszogrodzki, Manager Rozwoju Biznesu, Sektor Bankowo-Finansowy, Sygnity SA
Rekomendacja D Komisji Nadzoru Finansowego zawiera wiążące dla banków zalecenia dotyczące zarządzania bezpieczeństwem systemów informatycznych i ryzykiem operacyjnym w obszarach IT. Pierwotna Rekomendacja D, wydana w 2002 r., skupiała się na raportowaniu, pozostawiając bankom dużą swobodę w praktycznej implementacji zaleceń. Nowelizacja ze stycznia 2013 r. jest znacznie bardziej szczegółowa. Stawia wymóg formalizacji procesów, klasyfikacji systemów według znaczenia dla biznesu i bezpieczeństwa informacji oraz wyceny ryzyka. Zobowiązuje też banki do cyklicznej oceny stanu bezpieczeństwa i ryzyka w obszarach IT w formieaudytów zewnętrznych.
Celem nowelizacji Rekomendacji D jest urealnienie wyceny ryzyka operacyjnego w obszarach IT. Ostatecznym jej skutkiem ma byćodzwierciedlenie urealnionego ryzyka w rezerwach lub jego znacząca minimalizacja.Sygnity jest jedną z nielicznych firm potrafiących pomóc bankom w sprawnym wdrożeniu zaleceń zawartych w znowelizowanej Rekomendacji D. Firma ma doświadczenie w opisywaniu, szacowaniu i szczegółowym raportowaniu ryzykaw obszarach związanych z informatyką, a jednocześnie w audytach bezpieczeństwa. Posługuje się sprawdzoną metodyką oraz specjalistycznymi narzędziami do budowania modelu ryzyka i jego wyceny.
Od jakości, do wartości
Podział systemówwg istotności biznesowej jest pierwszym krokiem do wyceny ryzyka. Najłatwiej zrozumieć to na przykładzie systemu o najwyższej istotności. Największe ryzyko dotyczące takiego systemu to jego całkowita utrata. Jeśli, zupełnie hipotetycznie, bank nie podjąłby żadnych kroków, by ograniczyć ryzyko utraty systemu, byłabyona bardzo prawdopodobna i bank przestałby funkcjonować. Aby wycenić takie ryzyko, bank musiałby ustanowić rezerwy w wysokości swojej rynkowej wartości. Jeśli jednak bank ograniczy prawdopodobieństwo całkowitej utraty systemu, np. przez jego zwielokrotnienie, prawdopodobieństwo utraty staje się znacząco mniejsze.
Istnieje wiele metod dalszego ograniczania ryzyka, m.in. ośrodek zapasowy, kopiowanie synchroniczne, systematyczne kopiowanie całego środowiska.Po analizie wszystkich potencjalnych ryzyk dotyczących systemu na tle wdrożonych mechanizmów ochronnych, dla każdego ryzyka można ustalić prawdopodobieństwo jego materializacji, a w rezultacie dokonać ostatecznej, sumarycznej wyceny związanego z nim ryzyka. Stosowana do klasyfikowania systemów i wyceny ryzyka przez Sygnity metodyka Oceny Ryzyka Bezpieczeństwa systemów Informatycznych (ORBI) stosuje takie właśnie podejście.
Metodyka ORBI jest koncepcyjnie zgodna z zaleceniami normy ISO/IEC 27001:2005. Dzieli zasoby informatyczne banku na 4 klasy istotności dla biznesu, 4 klasy poufności oraz 5 klas dostępności. Klasy są zdefiniowane jednoznacznie i nie zachodzą na siebie. Stosując metodykę ORBI banki nie tylko zyskują przejrzystość w dziedzinie analizy i modelowania ryzyka, ale spełniają wprost postulaty Rekomendacji D, a dokładnie zawartej w niej rekomendacji 19, która postuluje, że: „Bank powinien klasyfikować systemy informatyczne i przetwarzane w nich informacje zgodnie z zasadami uwzględniającymi w szczególności wymagany dla tych systemów i informacji poziom bezpieczeństwa”.
Czytelny związek nakładów i efektów
Bezpieczeństwo informatyczne to dziedzina, w której trudno jest policzyć zwrot z inwestycji, co nie zmienia faktu, że jest ono dla biznesu bardzoistotna. Tymczasem nowa Rekomendacja D w powiązaniu z metodyką ORBI stwarza taką właśnie możliwość. Tworzy związek przyczynowo-skutkowy między nakładami na bezpieczeństwo systemów oraz efektami tych nakładów – w postaci redukcji ryzyka, a w konsekwencji wielkości rezerw obowiązkowych.
W rezultacie możliwe staje się biznesowe podejście do oceny wydatków na bezpieczeństwo systemów – coś, czego przez wiele lat bezskutecznie poszukiwali zarówno przedstawiciele obszarów biznesowych, jak i informatycznych.Wagętego faktu trudno przecenić. Pojawiły się nawet postulaty, by na kanwie bankowej Rekomendacji D powstały analogiczne regulacje dla sektora energetycznego.Powiązanie nakładów i efektów pozwala analizować portfel projektów związanych z bezpieczeństwem wprost pod kątem potencjału ograniczenia rezerw. Z perspektywy pojedynczego obszaru, środowiska czy systemu można łatwiej ustalić, który projekt ma priorytet.
Rekomendacja D daje podstawy do tego, by obszarem bezpieczeństwa informatycznego można było rzeczywiście zarządzać, a więc podejmować systematyczne działania, oparte na rzetelnej obserwacji i pomiarze. Rekomendacja nr 18 mówi: „W banku powinien funkcjonować sformalizowany, skuteczny system zarządzania bezpieczeństwem środowiska teleinformatycznego, obejmujący działania związane z identyfikacją, szacowaniem, kontrolą, przeciwdziałaniem, monitorowaniem i raportowaniem ryzyka w tym zakresie, zintegrowany z całościowym systemem zarządzania ryzykiem i bezpieczeństwem informacji w banku”.
Model danych dla ryzyka
W banku średniej wielkości działa co najmniej kilkadziesiąt systemów i aplikacji biznesowych, powiązanych ze sobą na wielu poziomach. Modelowanie ryzyka związanego z takim środowiskiem i wspierającą je infrastrukturą jest trudne pod każdym względem. Istnieje pokusa, by jako podstawę analizy ryzyka wykorzystać działające w bankach systemy do inwentaryzacji zasobów informatycznych. Niestety, nie tędy droga. Model danych na potrzeby inwentaryzacji nie odpowiada potrzebom analizy ryzyka ani pod względem struktury, ani zakresu. W analizie ryzyka kluczowe jest spojrzenie na systemy bankowe z perspektywy rozwiązań realizujących określone funkcje biznesowe, a nie wchodzące w ich skład elementy techniczne, jak serwery baz danych, środowiska portalowe, itp.
Do długofalowej systematyzacji zarządzania ryzykiem informatycznym potrzebne są dedykowane narzędzia. Sygnity wykorzystuje w swoich projektach oprogramowanieActuality Risk Assessment (ARA). Umożliwia ono uproszczony opis struktury logicznej systemów i zależności między nimi, a także ich współzależnościz innymi środowiskami. ARA pozwala skupić się na sednie, czyli zdefiniowaniu środowisk i ich klasyfikowaniu, bez wdawania się w szczegółowe właściwości obiektów czy detale konfiguracji.Nie jest to model, który da się aktualizować w sposób automatyczny poprzez skanowanie zasobów, niemniej – bardzo użyteczny z punktu widzenia celu, jakim jest syntetyczna analiza ryzyka.
Wykorzystanie dedykowanego rozwiązania ułatwia spełnienie postulatu znowelizowanej Rekomendacji D w tej części, która mówi o zapewnieniu wszystkim uprawnionym osobom dostępu do informacji związanej z ryzykiem w obszarach informatycznych. By zacytować dosłownie fragment rekomendacji 2: „W banku powinien funkcjonować sformalizowany system informacji zarządczej w zakresie obszarów technologii informacyjnej oraz bezpieczeństwa środowiska teleinformatycznego, zapewniający każdemu z odbiorców informacji właściwy poziom wiedzy o tych obszarach”.
Wsparcie dla cyklicznych audytów
Celem nowelizacjiRekomendacji Dnie jest skłonienie banków dozapewnienia pełnego bezpieczeństwa systemów informatycznych do końca 2014 r. Jest nim raczej zachęcenie banków do tego, by stworzyły trwałe ramy do systematycznej oceny poziomu bezpieczeństwa, rozumianego bardzo szeroko, a także do systematycznego doskonaleniarozwiązań i procedur w tym zakresie. Stąd właśnie postulat, by poziom ryzyka informatycznego podlegał cyklicznie audytom wykonywanym przez podmioty niezależne od banku.
W wykorzystywanym przez Sygnity systemie Actuality Risk Assessment (ARA)można definiować i uruchamiać procesy audytu obejmujące wybrane obszary lub systemy. Dla każdego audytu zapisywane są cele, zakres i rodzaj prac, zasoby do których wymagany jest dostęp, w tym np. dokumentacja i osoby prowadzące audyt. System umożliwia generowanie raportów przedstawiających bieżący status audytów w formie ogólnej lub w rozbiciu na środowiska albo inaczej zdefiniowane obszary. Pozwala także tworzyć raporty będące zestawieniami wyników audytu bieżącego z wynikami audytów historycznych.
Po zakończeniu audytu w systemie zapisywane są wnioski końcowe i zalecenia dotyczące potencjalnych działań korygujących. Dzięki nim, zgodnie z zaleceniami znowelizowanej Rekomendacji D, osoby odpowiedzialne za systemy oraz ryzyko w obszarach informatycznych otrzymują rzetelne informacje. Na tej podstawie mogą formułować wnioski o uruchomienie projektów zmian lub inwestycji niezbędnych do sprowadzenia ryzyka do poziomu akceptowanego przez zarząd. Kolejny audyt przyniesie odpowiedź na pytanie, czy przeprowadzone zmiany i inwestycje faktycznie przyczyniły się do redukcji ryzyka.
//
Wojciech Boczoń
