Opracowanie analizy ryzyka bezpieczeństwa informacji bez wiedzy zdobytej podczas cyklicznie prowadzonych testów i przeglądów graniczy z cudem. Tylko testy dają pełną wiedzę nt. stanu faktycznego bezpieczeństwa informacji.
Nadal mamy do czynienia z bankami, w których temat testowania traktowany jest jak piąte koło u wozu !!! Czy zatem zalecenia jakie dajemy po przeprowadzeniu audytu w konkretnym środowisku banku, w którym stwierdzamy braki dotyczące bezpieczeństwa, mają sens?
Mają sens – o ile są traktowane poważnie i szybko wprowadzane w życie.
Trzy lata temu wykonując audyt bezpieczeństwa w jednym z banków spółdzielczych stwierdziliśmy braki w infrastrukturze nadzorującej przekroczenie warunków skrajnych w serwerowni. Bank wykonał zalecenie, zainstalował wskazane brakujące czujniki, które zostały wpięte do centrali powiadamiającej osoby uprawnione o incydentach. Po trzech latach i ponownym audycie placówek tego banku okazało się, że omawiane czujniki uratowały niezwykle cenną serwerownię przed zalaniem. Tuż nad serwerownią rozszczelniła się rura, doprowadzająca wodę do znajdującej się tam łazienki. Obecnie nie ma śladu po zalaniu, czujniki zadziałały, a informujący nas o tym zdarzeniu pracownik banku stwierdził, że warto było szybko dostosować się do zalecenia.
Zainstalowanie czujników, central szczytujących i konfiguracja systemu powiadomień wiąże się z niewielkim wydatkiem finansowym w stosunku do ewentualnych strat, jakie mogą powstać w zalanych serwerach, macierzach routerach a przede wszystkim ogromnych strat utraty danych.
Aby móc skutecznie i na czas identyfikować potencjalne podatności, konieczne jest cykliczne prowadzenia pełnego zakresu:
- testów
- przeglądów
- ocen
- analiz
bezpieczeństwa informacji.
Do tego typu działań zaliczamy:
- prowadzenie analiz luk, które mogą skutecznie zidentyfikować ewentualne podatności jako odstępstwa od wyznaczonych i obowiązujących standardów bezpieczeństwa informacji środowiska ICT
- prowadzenie przeglądów zgodności
- audyty wewnętrzne
- niezależne audyty zewnętrzne
- przeglądy bezpieczeństwa fizycznego
Analizując głębiej stan bezpieczeństwa informacji środowiska ICT należy:
- prowadzić cykliczne testy podatności
- wykonać próbę dostania się do środowiska banku z zewnętrznej infrastruktury, aby móc określić jej słabe punkty, hasła admin, otwarte porty itd.
- wykonywać testy i przeglądy kodu źródłowego – jeszcze nie spotkaliśmy się z raportem z przeprowadzenia podobnego testu, który powinien potwierdzić stan bezpieczeństwa kodu źródłowego systemu, który pracuje w infrastrukturze banku lub inny system udostępniany przez dostawcę zewnętrznego w modelu chmury.
Bank musi posiadać opracowane i wdrożone ramy testowania bezpieczeństwa informacji środowiska ICT, które potwierdzają stabilność i skuteczność wdrożonych środków bezpieczeństwa, a tym samym dają wykładnię dla oceny ryzyka dotyczącego technologii i bezpieczeństwa ICT. |
Testy powinny:
- być prowadzone przez niezależnych audytorów niezwiązanych z audytowaną organizacją ani z pracownikami banku. Dodatkowo audytor nie powinien być powiązany ze środowiskiem produkcyjnym systemu pracującego w banku.
- obejmować skanowanie podatności i powinny być ukierunkowane na zagrożenia określone w procesie analizy ryzyka
- być prowadzone po zmianie w infrastrukturze, w razie większych incydentów itd.
- ich rolą jest stwierdzenie podatności, które należy jak najszybciej korygować do stanu zapewniającego pełne bezpieczeństwo
- być prowadzone i powtarzane na bieżąco. W odniesieniu do systemów krytycznych testy należy prowadzić raz w roku. Systemy inne niż krytyczne muszą być testowane minimum raz na 3 lata.
Zapraszamy Państwa na szkolenia:
https://edu.servus-comp.pl/pl
Zapraszamy Państwa do zapoznania się na naszą ofertą:
https://premiumbank.zadbajobezpieczenstwo.p
Zapraszamy do kontaktu. Chętnie odpowiemy na każde pytanie.
Dodaj komentarz
Musisz się zalogować, aby móc dodać komentarz.