Współpraca z biznesem

Porozumienie działu bezpieczeństwa z dyrekcją i zarządem nie jest proste, gdyż obie strony mówią zupełnie innym językiem. Aby menedżer zrozumiał zagadnienia związane m.in. z ochroną krytycznych aplikacji, a następnie podjął dobrą dla firmy decyzję, musi otrzymać informacje dostarczone w zrozumiały dla niego sposób – w języku finansów i procesów.

Michał Stankiewicz wyjaśnia: „Jeśli spytamy się biznesu, czy aplikacja jest krytyczna, to odpowie, że tak. Gdy przygotujemy założenia zabezpieczeń i podliczymy koszty, może okazać się, że taka aplikacja staje się nierentowna. Gdybyśmy zastosowali dla każdej z nich wymagania na poziomie C4, I4 i A4, czyli bardzo wysokie, to taka aplikacja musiałaby mieć własne data center z opcją disaster recovery, monitoring przez 24 godz. na dobę, comiesięczne audyty kodów i testy penetracyjne. Byłoby to bardzo drogie, czasami nieuzasadnione w porównaniu z wypracowanym zyskiem. Należy zatem dostarczyć menedżerom informację, którą zrozumieją. Najlepiej oszacować ryzyko nie poprzez poziomy high, medium low, ale po prostu podać kwotę, jaką można stracić. Naszym największym sukcesem jest fakt, że biznes jest świadomy potrzeb dotyczących bezpieczeństwa, nie traktuje nas jako przeszkody w rozwoju i chce korzystać z naszych usług oraz informacji”.

Zobacz również:

• Ta ustawa przybliża moment, w którym TikTok zostanie zablokowany w USA
• Najważniejsze zagrożenia wykorzystania modelu SaaS

Te same zasady dla wszystkich

Zasady związane z ochroną, znajdowaniem podatności oraz minimalizacją ich skutków należy stosować także do zasobów i produktów spoza firmowego działu IT. Model ten umożliwia zmniejszenie ryzyka związanego ze zdarzeniami, których nikt przedtem nie brał pod uwagę.

Michał Stankiewicz wspomina: „Zasadę testowania podatności nowych rozwiązań stosujemy z żelazną konsekwencją i rygorystycznie sprawdzamy także same systemy bezpieczeństwa, w tym dostarczane przez globalnych dostawców. Nasz specjalista znalazł krytyczne luki w bezpieczeństwie systemów, które miały służyć do zapewnienia bezpieczeństwa innych urządzeń i aplikacji. Po tym zdarzeniu producent zaprosił do nas swojego specjalistę, który był zdziwiony tym, co robimy. Wspomniał, że oni sprzedają te systemy do różnych instytucji, w tym ministerstw obrony, ale nikt nigdy takiej luki nie wykrył ani nie zgłosił. Na pytanie o przeprowadzane testy odpowiedział, że klienci po prostu przeczytali materiały producenta. Czasem widzimy próby przełamania naszych zabezpieczeń z zewnątrz, są to próby bardziej lub mniej profesjonalne, każdą z nich analizujemy i zdążyło się nam poprawiać błędy w trakcie takich działań”.

Długofalowe zaplanowane działania

Początkowo działania związane z zapewnieniem bezpieczeństwa podejmuje się ad hoc, załatwiając najpilniejsze zdarzenia i potrzeby. Docelowo powinno być to działanie procesowe, częściowo zautomatyzowane i wpisane w normalne zadania wszystkich działów – od deweloperskiego przy tworzeniu aplikacji, przez IT, które zapewnia jej eksploatację, aż do biznesu.

Michał Stankiewicz mówi: „Początkowo testowaliśmy każdą nową aplikację i naprawialiśmy krytyczne luki w bezpieczeństwie. Dość szybko przeszliśmy do profesjonalnego dwuczęściowego modelu. Pierwsza część jest związana z automatycznymi testami wyszukującymi m.in. brak odpowiednich poprawek bezpieczeństwa. Wynikiem testów jest dostarczenie zgłoszeń serwisowych, które są następnie obsługiwane przez IT. Druga część procesu opiera się na umiejętnościach pentesterów. Dostarczane wyniki testów penetracyjnych i wyciągane z nich wnioski służą do poprawy bezpieczeństwa w firmie. Proces ten stosujemy standardowo, także do systemów dostarczanych przez firmy zewnętrzne. Zamiast doraźnych akcji należy stosować dopracowany proces, który pozwoli na określeniu poziomu bezpieczeństwa dla każdej aplikacji biznesowej w sposób spójny z jej rozwojem i utrzymaniem”.