Rekomendacja D: małe i średnie instytucje finansowe mają jeszcze wiele do zrobienia

Udostępnij Ikona facebook Ikona LinkedIn Ikona twitter

plonka.pawel.01.150x196Już tylko 3 tygodnie mają banki na wykonanie analizy luk w swoich systemach IT i przedstawienie do KNF harmonogramu działań naprawczych w związku z Rekomendacją D.  Niestety wiele małych i średniej wielkości instytucji finansowych dopiero zaczyna prace w tym zakresie, popełniając błędy i ryzykując odrzuceniem harmonogramów przez KNF.

Uprawnienia dostępu, ciągłość działania i zarządzanie

Rekomendacja D to temat, który jest obecnie na ustach wszystkich szefów Działów IT i Bezpieczeństwa  w instytucjach finansowych w Polsce. Do końca czerwca muszą oni zakończyć audyty dotyczące zarządzania obszarem technologii informacyjnej. Ich efektem mają być szczegółowe diagnozy luk, oraz propozycje niezbędnych wdrożeń naprawczych, które już jesienią będą skrupulatnie weryfikowane przez KNF.

Mimo, że Rekomendacja D obejmuje wiele strategicznych obszarów zarządczo-biznesowych to większość z nich skupia się właśnie na obszarze IT. To w tym zakresie banki i instytucje finansowe rozwijają się najszybciej oferując nowe usługi. Jest też niestety druga strona medalu. Nowe kanały udostępniania danych klientom, większa wymiana informacji wrażliwych pomiędzy różnymi departamentami banków czy chociażby sama ilość danych, które muszą być dostępne 24/7 sprawiają, że z roku na rok pojawia się coraz więcej niebezpieczeństw dla Klientów, ale też dla ciągłości operacyjnej samych instytucji.

Właśnie te zagrożenia są elementami, na które KNF w swojej najnowszej rekomendacji zwraca największą uwagę. Przede wszystkim chodzi o zasady dotyczące zarządzania infrastrukturą teleinformatyczną, oraz dostępem do danych i informacji. Duży nacisk położono również na system zarządzania ciągłością działania. W szczególności kontrolę planów awaryjnych oraz audyt stosowanych rozwiązań i procedur, które są obszarem bardzo zaniedbanym przez wiele instytucji finansowych albo jedynie pozornie zagospodarowanym.

Duże, średnie, małe…

Rekomendacja D – aktualizowana po 10 latach – w gruncie rzeczy dostosowuje stosowane rozwiązania IT do obecnych realiów i zagrożeń, szczególnie w dobie bankowości elektronicznej. Jednak jej wdrożenie może stanowić duże wyzwanie. O ile duże instytucje finansowe są do tego przygotowane – posiadają specjalne komórki zajmujące się od wielu miesięcy tym zadaniem, oraz w wielu przypadkach uczestniczyły w konsultacjach związanych z opracowywaniem rekomendacji  –  to w przypadku małych i średnich podmiotów można zauważyć brak pełnej wiedzy na temat niezbędnych działań, które owocuje podejściem „kupimy coś gotowego” ale „zrobi to nasz informatyk w wolnej chwili”.

Wiele błędów popełnianych jest już na początku procesu wdrożeniowego, podczas planowania  tego procesu i dokonywania analizy „stanu wyjściowego”. Wynika to niestety z częstego braku doświadczenia działów IT w przekładaniu prawniczego języka Rekomendacji D i jej założeń na język konkretnych obszarów i rozwiązań teleinformatycznych.

Ten etap jest szczególnie istotny, bo potencjalne błędy rzutują na prawidłowość dalszego wdrażania oraz doboru rozwiązań.  Odpowiednie, a co ważne, wiarygodne zlokalizowanie luk pozwala dobrać optymalne rozwiązania i skupić się na obszarach, które wymagają zmian.

Jedną z częstych nieprawidłowości jest prowadzenie audytów we własnym zakresie przez działy IT tych instytucji. Tym samym często działy IT audytują same siebie i swoje procedury.  Takie podejście może być jednym z pierwszych zarzutów ze strony KNF do przedstawionych wniosków z analiz oraz rekomendacji. Podważa bowiem wiarygodność przeprowadzonych audytów.

Inne ważne elementy przy projektowaniu analiz w ramach wdrażania wytycznych Rekomendacji D to:

  • precyzyjne określenie akceptowanego przez bank/instytucje poziomu ryzyka w zakresie systemów informatycznych,
  • ustanowienie podstawowych upoważnień i mechanizmów podległości, w tym w odniesieniu do procedur zgłaszania przypadków wystąpienia incydentów wpływających na bezpieczeństwo, kondycję finansową lub reputację banku (np. przypadków penetracji sieci, złamania zasad bezpieczeństwa przez pracowników oraz wszelkich poważnych przypadków niewłaściwego użycia sprzętu komputerowego),
  • uwzględnienie unikalnych czynników ryzyka związanych z zapewnieniem bezpieczeństwa, integralności i dostępności produktów i usług bankowości elektronicznej oraz wymaganie, aby strony trzecie, którym banki zleciły sprawy podstawowych systemów lub aplikacji, podejmowały te same kroki.

Na co zwrócić szczególną uwagę?

Dotychczas prowadzone audyty wykazują, że wdrożenie Rekomendacji D może rzeczywiście bardzo pozytywnie wpłynąć na poziom bezpieczeństwa systemów bankowych. Szczególnie 3 obszary mogą stanowić prawdziwą stopę achillesową tych instytucji. Mimo, że wydawać się mogą one drugorzędne, to stanowią realne zagrożenie dla bezpieczeństwa danych jak też zdolności do zachowania ciągłości operacyjnej w przypadku awarii. Wśród tych obszarów podwyższonego ryzyka wymienić należy:

  • kwestia bezpieczeństwa przechowywanych danych w kontekście zagrożenia awarią lub ich utratą – w większości przypadków backup traktowany jest jedynie jako procedura przechowywania kopii zapasowych, natomiast wiele do życzenia pozostawiają procedury disaster recovery. To one dopiero zapewniają rzeczywiste, szybkie i kompleksowe „podniesienie systemu” lub też uzyskanie dostępu do danych w przypadku awarii.
  • kwestia nadawania i kontroli uprawnień do szczególnie wrażliwych danych lub aplikacji pracownikom instytucji finansowych – w wielu przypadkach brak jest jednolitych procedur związanych z nadawaniem i stopniowaniem uprawnień, ale także – co szczególnie niebezpieczne – z ich aktualizacją. Przykładem jest duża instytucja finansowa, w której w czasie audytu wykryto kilka kont z wysokim priorytetem uprawnień, nieużywanych od ponad roku stanowiących furtkę do systemu i tym samym poważną lukę dla bezpieczeństwa przechowanych danych.
  • kwestia nielegalnego bądź niepożądanego oprogramowania instalowanego na stacjach roboczych przez użytkowników – bardzo często tego typu oprogramowanie stanowi realne zagrożenie dla bezpieczeństwa danych zarówno w kontekście ukrytych wirusów czy trojanów jak też furtki do ujawniania czy „wynoszenia” danych wrażliwych. Audyty wykazały poza popularnymi komunikatorami Gadu Gadu czy Skype także wiele aplikacji służących rozrywce.

Paweł Płonka
IT Projects Sales Advisor
Infonet Projekt