Kogo dotyczy Rekomendacja D, czy można ją sobie zwyczajnie kupić?

Do końca czerwca 2014 roku instytucje finansowe musiały przedstawić Komisji Nadzoru Finansowego harmonogram wdrożenia dostosowania do Rekomendacji D. Aktualizacja wytycznych KNF nie jest przypadkowym ruchem. Komisja zdała sobie sprawę ze zmian zachodzących w dziedzinie bezpieczeństwa zasobów IT. Tym bardziej w tak wrażliwym obszarze, w jakim działają instytucje finansowe. Niestety, mimo bardzo ścisłych terminów wyznaczonych przez KNF i dużej wagi zagadnienia część podmiotów pozostawia sprawę dostosowania do wymogów Rekomendacji na ostatnią chwilę, nie do końca chyba rozumiejąc intencję wprowadzenia regulacji ani jej istotę. O tym, kogo dotyczy Rekomendacja D, dlaczego nie jest to kolejne zadanie dla działu IT oraz czy można ją sobie zwyczajnie kupić, rozmawiamy z Andrzejem Kawińskim z Instytutu Analiz i Prognoz Rynkowych.

- Skąd pomysł na wprowadzenie Rekomendacji D?

AK: Z obecnej rzeczywistości. Rekomendacja D to bardzo słuszne posunięcie KNF mające na celu dostosowanie wymogów bezpieczeństwa, stawianych instytucjom finansowym, do obecnych realiów. Po dziesięciu latach funkcjonowania Rekomendacji Komisja doszła do wniosku, że zmiany, które zaszły w dziedzinie zbierania, analizowania i przechowywania danych – rosnąca popularność chmury obliczeniowej czy outsourcingu IT (np. kolokacji serwerów) – są tak duże, że nie należy dłużej zwlekać. Stąd całe to „zamieszanie” z Rekomendacją D. Trzeba pamiętać, że mówiąc o instytucjach finansowych, mamy na myśli organizacje, które coraz rzadziej obracają obecnie rzeczywistą gotówką, którą można bezpiecznie ukryć w skarbcu albo sejfie. Dzisiejsza bankowość to informatyka, czyli dane zapisane w systemach komputerowych. Podobnie jak w przypadku gotówki, „cyfrowym pieniądzom” także należy zapewnić odpowiednie bezpieczeństwo. Ponadto instytucje finansowe bardzo często dysponują też zbiorami danych swoich klientów. Także te zasoby trzeba odpowiednio chronić.

- Kogo dotyczy wymóg dostosowania się?

AK: Całego sektora finansowego, od małego lokalnego banku po gigantycznych liderów rynku. Od instytucji, w ramach których działa kilka osób, do tych zrzeszających tysiące pracowników i setki tysięcy klientów. Rekomendacja D nie rozróżnia na mniejsze i większe podmioty, ale wprowadza definicję zasady proporcjonalności. Tak więc zarówno małe lokalne banki, jak i największe instytucje finansowe w Polsce są zobowiązane do wdrożenia Rekomendacji D.

Jak pokazuje praktyka, duże banki na ogół są dość poprawnie zabezpieczone i mają świadomość ryzyka określonego w Rekomendacji D, jednak w mniejszych instytucjach, np. bankach spółdzielczych, poziom wiedzy nie zawsze jest wystarczający. Wciąż mówimy o bezpieczeństwie, ale trzeba pamiętać, że jest ono bardzo istotnym, ale tylko jednym z wielu aspektów Rekomendacji D.

- Dlaczego Rekomendacja D to nie „problem” działu IT?

AK: Rekomendacja D została skierowana do Zarządów Banku i obejmuje swoim zakresem obszar działania czterech departamentów: Informatyki, Ryzyka, Biznesu i Bezpieczeństwa. Mimo że w nazwie rekomendacji pojawia się słowo „Teleinformatyka”, zadekretowanie tego dokumentu do działu IT jest błędem. Regulator dużo uwagi poświęcił na definicję współpracy pomiędzy wymienionymi powyżej obszarami działania banku. Rekomendacja określa również odpowiedzialność zarówno po stronie Zarządu Banku, jak i Rady Nadzorczej. Zarząd może oczywiście zlecić swoim pracownikom pewne oceny stanu rzeczy i wystosowanie sugestii odnośnie proponowanych działań naprawczych, dostosowujących infrastrukturę do wymogów. Lepszym pomysłem byłoby jednak zlecenie tych zadań firmie zewnętrznej, która dokona niezależnego audytu.
Komisja Nadzoru Finansowego oczekuje bowiem, że wdrożenie Rekomendacji D zostanie potwierdzone przez wykonanie niezależnego audytu.

- W internecie bez trudu znaleźć można ogłoszenia sugerujące możliwość szybkiego załatwienia sprawy Rekomendacji D poprzez zakupienie odpowiednich rozwiązań. Czy to rzeczywiście wyjście z sytuacji?

AK: Kupowanie gotowych rozwiązań rozumiane jako kupowanie dokumentacji nie ma według mnie większego sensu. Nie to jest istotą Rekomendacji D. Dostosowanie musi być kompleksowe – zakładać osiągnięcie pewnego założonego poziomu bezpieczeństwa, ustalać reguły komunikacji i współpracy między działami instytucji oraz zapewniać skuteczne scenariusze i procedury na wypadek awarii. Nie wystarczy więc kupić dokumentacji i położyć na półkę. Procedury opracowane na potrzeby - co warto podkreślić - konkretnych instytucji muszą być praktyczne. Tym bardziej że jednym z celów Rekomendacji D jest budowanie świadomości zagrożeń. Potraktowanie jej więc jako kolejnej przeszkody w rozkładzie dnia nie jest wskazane.

Jakoś można sobie jednak pomóc. Wyjściem - do przemyślenia dla instytucji, które chcą dostosować się do wymogów Rekomendacji D - może być skorzystanie z outsourcingu zasobów IT. Oczywiście, Rekomendacja nie zmusza nikogo do kupowania konkretnych rozwiązań, ale w pewnym sensie premiuje rzetelnych dostawców rozwiązań IT. Tacy dostawcy mogą bowiem zaoferować usługi, które spełniają wymogi stawiane instytucjom w ramach Rekomendacji D, a zatem likwidują lub zmniejszają ryzyko związane z funkcjonowaniem IT. Przykładem z przeciwnego bieguna może być natomiast skorzystanie z usług pocztowych któregoś z publicznych dostawców. Nie podważając zalet takiego rozwiązania, należy podkreślić, że nie spełnia ono wymogów Rekomendacji i nie może stanowić preferowanego rozwiązania pocztowego dla banków. Nie da się nim bowiem lokalnie zarządzać, co stanowi jeden z warunków bezpieczeństwa wg Rekomendacji D.

- O czym należy pamiętać, przygotowując harmonogram działań wdrożeniowych Rekomendacji D?

AK: Przygotowując harmonogram działań wdrożeniowych, warto pamiętać, że Rekomendacja D jest bardzo istotna, mimo chwilowego zamieszania, które wprowadza. Rozbudza świadomość zagrożeń wynikających z szybkiego rozwoju technologii teleinformatycznych i ich szerokiego zastosowania w sektorze finansowym. Nie ma w zamyśle wyhamować tego postępu, tylko uzmysłowić instytucjom finansowym, jak ważne jest jednoczesne dbanie o minimalizowanie zagrożeń płynących z ich zastosowania.

DLP expert magazyn
DLP expert 2/2014


Tekst pochodzi z magazynu DLP expert 2/2014 (9)- który bezpłatnie można pobrać tutaj: https://www.dlp-expert.pl/magazine

Źródło: Redakcja