Jak "Zhackować" Politykę Bezpieczeństwa Zarządu?

securitybeztabu.pl 2 lat temu

Na czym polega polityka bezpieczeństwa zarządu?

Trudność polega na tym, iż zarządy najczęściej ignorują problemy związane z bezpieczeństwem. Temat ten traktowany jest po macoszemu, w stylu: „Jakoś to będzie, przecież już coś zrobiliśmy”.

Również bardzo popularna jest opinia, iż na bezpieczeństwie się nie zarabia. Przed postawieniem takiej tezy należy zadać pytanie – Czy bezpieczeństwo daje pieniądze?

Jak przekonać zarząd?

Zacznijmy od początku. Często od nas – informatyków, administratorów, opsów, devopsów, securitasów, bezpieczników, pracowników czy konsultantów – zależy bezpieczeństwo danej firmy. Zarząd nie musi wiedzieć wszystkiego, ani znać się na wszystkim, więc pozwólmy na dawanie narzędzi, które będą przemawiały w języku zarządu.

Skąd takie wnioski? Uczestniczyłem ostatnio w kilku audytach, również przy tworzeniu raportów i zestawień odnośnie bezpieczeństwa w danych organizacjach. Zapoznawałem się również z takimi dokumentami – zarówno publicznymi, jak i częściowo ocenzurowanymi.

Jakie są zalety tego podejścia?

Aby móc iść do zarządu, pytając przy tym: „Możemy zwiększyć działanie na polu bezpieczeństwa?” musimy być świadomi, iż to pytanie zawiera w sobie ukryte koszty – grosik tu, godzina tu, kilka etatów, modernizację infrastruktury wraz z procedurami itd. Kłóci się to z tym, iż bezpieczeństwo daje pieniądze, ponieważ wiąże się jedynie z wydatkami. W takim razie, jak to zrobić?

Przykład z życia wzięty

Można zrobić to, co zrobiła organizacja, którą poznałem jakiś czas temu. Za bezpieczeństwo odpowiadają „ludzie z IT” – odpowiadający za ERP, pocztę elektroniczną czy różnorakie systemy. Żyją w firmie od dłuższego czasu, znają jej specyfikę, zajmowali się koordynowaniem pracy zdalnej w czasie pandemii COVID-19.

Takie osoby często nie dostają odpowiedzi zwrotnej dotyczącej ich działań. Z drugiej strony potrzebują, aby ktoś z zewnątrz przyjrzał się jak wygląda obecna sytuacja w organizacji. Wtedy pojawia się zapotrzebowanie na dokument, który można roboczo nazwać Raportem stanu zastanego. Określa on to, jak dana organizacja funkcjonuje tu i teraz – angielskie „as it is”. Takie dokumenty tworzy się różnorako, ale składają się z trzech elementów.

Raport stanu zastanego – z czego się składa?

Opis bezpieczeństwa – procedury, procesy, operacyjność. Mówi o tym jakie zabezpieczenia są używane w organizacji.

Strona techniczna – programy, systemy. Środowisko stricte informatyczne opisujące hardware i software.

Człowiek – jest to po prostu brutalne sprawdzenie, jak powyższe aspekty są skonfigurowane. Zaliczają się do tego np. przejrzenie konfiguracji lub testy penetracyjne. Liczy się praktyczny aspekt.

W skrócie:

Dokumenty

Opisanie infrastruktury

Sprawdzenie w praktyce działania

Wracamy do naszego punktu wyjściowego – dokument, który opisze jak to wygląda, tworzony jest na podstawie tych trzech elementów. Dokument, który ostatnio tworzyłem i przedstawiałem zarządowi, nie zawierał elementu sprawdzenia konfiguracji. Nie chcieli tego zrobić, nie było to konieczne. Nie wiem, nie wnikałem. Nie było to przedmiotem kontraktu. W zakresie procedur też było ich stosunkowo kilka – była jedynie częściowa dokumentacja. Natomiast było bardzo dużo dokumentacji, która dotyczyła tego jak wygląda serwerownia, jak wyglądają punkty końcowe (endpointy), jak działają serwery i połączenie sieciowe, poczta elektroniczna, gdzie jest DNS itd. Te wszystkie elementy, o które człowiek specjalizujący się w informatyce dba na co dzień, aby zapewnić bezpieczeństwo w firmie. Bezpieczeństwo rozumiane jako dostępność, czyli żeby wszystko działało zarówno dziś, jutro, pojutrze…

W ramach tworzenia takiego dokumentu trzeba było wyciągnąć jakieś wnioski – zarówno pojedyncze, jak i dotyczące konkretnego obszaru. Były nimi:

Stan serwerowni
Zmiana serwerów ze względu na kończące się gwarancje czy serwisowanie
Sugestia sprawdzenia hardeningowej części, czyli przejrzenie konfiguracji, ponieważ nie była uwzględniona w raporcie. Było to poza zakresem działań (w języku bezpieczeników – out of scope).

Doszło do momentu, kiedy zarząd chciał usłyszeć wnioski, podsumowanie prac. I teraz, jak zhackować podejście do bezpieczeństwa, strategię bezpieczeństwa zarządu?

Tu jest sekret: trzeba mówić „po zarządowemu”. Na czym to polega, tak w telegraficznym skrócie? Mam nadzieję, iż niczym Cię tu nie zaskoczę, ale jednak chciałbym to zasygnalizować.

Pytania zarządu

Jednym z pytań zarządu, które padło było: Czy już jest bezpiecznie?

No oczywiście, iż już jest bezpiecznie. Warto zrobić to i owo, jakieś rady powstały, zespół je zbudował, są włożone do dokumentu. Panowie z IT to wszystko wiedzą, iż część rzeczy jest nierealnych, część prostych, część wymagających, część można zrobić dziś, jutro itd.

Drugie pytanie ze strony zarządu: Ile zarząd powinien wydać pieniędzy na bezpieczeństwo?

I tu się zaczyna zagwozdka, ponieważ nie masz zielonego pojęcia, ile wydali do tej pory i jakie mają możliwości finansowania. Nie znasz tej sytuacji w stu procentach, bo przedmiotem sprawdzenia nie było przetestowanie tego środowiska. Chodziło głównie o bezpieczeństwo, więc ciężko jest odpowiedzieć, iż „kilo firewalla” tu, czy jeszcze „dwa metry procedury” tam, a może jeszcze cztery szkolenia dla kogoś. Brakuje tak szczegółowych danych, dlatego ciężko jest skwantyfikować konkretną kwotą, ile to ma kosztować.

Następne pytanie: Ile organizacje, takie jak nasza, wydają na bezpieczeństwo?

Jest to jeszcze trudniejsze pytanie, ponieważ nie wszystkie organizacje mówią głośno ile wydają. Wiemy, ile wydają w kierunku naszego projektu, ale takich jak my są dziesiątki na rynku. Firmy korzystają zaś z usług różnych organizacji. zwykle nie mamy pojęcia ile zarabiają lub jakie są koszty kadr. Ciężko to zmierzyć i doprowadzić do języka zarządu, który pyta: „Proszę pana, jaki procent budżetu powinniśmy przeznaczyć na IT?”. Nie da się.

Inne podejście: Czy jest jakiś benchmark w stosunku do tego, jak podobne firmy do naszej zajmują się tematem?

No i znowu – nie da się tego powiedzieć w ten sposób. Nie da się dać zarządowi odpowiedzi w ich języku od strony kwot i procentów. Da się jednak zrobić coś innego. Coś, co widziałem wielokrotnie, ale nie do końca było dobrze robione.

Przykład z życia wzięty

Spotkanie IT z zarządem. Padają pytania: „Panowie, ile tym razem chcecie pieniędzy do wydania? Jaki budżet chcielibyście, żeby kupić sobie te zabawki? Ile musimy na was wydać, żebyście mogli pracować i abyśmy my mogli pracować?”.

Pojawia się odpowiedź, iż jeszcze trzeba kupić to i tamto, jeszcze 20 godzin, jeszcze konsultanta itd. Robi się z tego ileś rzeczy, za które zapłacić musi dany inwestor. Aby zhackować zarząd, trzeba znacząco poprawić jedną rzecz – uzasadnienie. Nie dlatego, iż my tego potrzebujemy albo sypie się poprzednie. To nie przemawia do zarządu. Zarząd hackuje się od innej strony, choć nie wiem czy zarządy polubią mnie za to, co powiedziałem przed chwilą.

Metody hackowania zarządu

Najistotniejsze jest dostosowanie języka do tego, którym się posługuje zarząd. Posługuje się on językiem ryzyka, szans czy okoliczności. To jest ich podwórko. Podwórko osób, które zarządzają. Kwota jaką zarząd będzie chciał przeznaczyć na bezpieczeństwo, niezależnie od tego jaka jest, prawdopodobnie będzie optymalizowana. Tak się robi w biznesie – próbuje się wszystko negocjować, podzielić koszty przez dwa, pięć lub dziesięć. W takim razie, jakie jest rozwiązanie?

Warto przedstawić to od strony zagrożeń czy ryzyka. Co się wydarzy, kiedy nie zainwestujemy? Ważne jest również, aby nie opierać się na języku informatyka – serwer przestanie nam pracować, sieć nie będzie odpowiadać itd. Warto zerknąć na to, jakimi kryteriami zarząd może podejmować decyzje.

Pokażę również rozwiązanie sytuacji, kiedy pojawiają się pytania o benchmarki, kwoty i procenty. Te pytania nie miały odpowiedzi z jednej prostego względu – w bezpieczeństwie nie da się tego jasno zmierzyć lub porównać firmy do firmy. Jedna mała różnica między dwiema z pozoru takimi samymi organizacjami powoduje, iż tutaj Axance może pasować, a gdzieś indziej nie.

Kiedy zastosowałem tę metodę, coś zaiskrzyło między zarządem i IT. Weszliśmy na ścieżkę, która pokazuje jakie ryzyka będą ukrócone poprzez konkretną operację, którą planujemy wykonać. Pewna organizacja rozważała dokupienie dodatkowego miejsca w chmurze. Zarówno obecna, jak i ta która miała zostać zakupiona, były za małe dla danej firmy. Należało kupić drugą, piątą… – brak szczegółowych danych. Językiem zarządu – trzeba wydać pieniądze. W jaki sposób przekonać do tego zarząd?

Przykładowa rozmowa z zarządem

Dział IT: Jeśli nie dokonamy tego typu inwestycji, nie zrealizujemy tego projektu według takiego planu, problem będzie polegał na tym, iż prędzej czy później przyjdą do nas nasi partnerzy biznesowi, klienci, rada nadzorcza i zapytają: „Dlaczego w waszym sklepie internetowym nic się nie da kupić?”.

Zarząd: Jak to nie da się nic kupić?

Dział IT: Wchodzę na stronę internetową, próbuję dodać do koszyka nasz produkt i muszę czekać, aby to dodało się do koszyka. Nie działa to tak jak powinno.

Tego typu informacja – argument, iż przestanie to działać tak jak trzeba, iż poniesiemy szerokie konsekwencje – dopiero to będzie przemawiało. Jest to zupełnie inne niż to, iż „po prostu wysypie” i nie będzie działać. W jednym z projektów widziałem informację, iż jeżeli dokonamy tej inwestycji, zredukujemy jakieś konkretne zagrożenia.

Zróżnicowanie zagrożeń

Każda organizacja mierzy się z rożnymi zagrożeniami i inny sposób do nich podchodzi. Dla jednych zagrożenia są bardzo konkretne, np. wyciek danych jakiegoś typu jest niezwykle groźny. Dla innych – „Nie wiem, o czym pan mówi, to chyba dla nas nieistotne.” Innymi słowy każda organizacja ma różnorodne zagrożenia. Niby nic nowego, ale warto to podkreślić. Warto przez ten pryzmat patrzeć na zarządzanie środowiskiem, nowe projekty na całościowe zarządzanie bezpieczeństwem. Każda organizacja powinna znać konkretne, obliczone, sprawdzone zagrożenia, przeciwko którym chce działać. To jest podstawa choćby takiego książkowego bezpieczeństwa.

Określ najpierw, przed czym chcesz się chronić. Co Ci grozi? Jakich konsekwencji chcesz uniknąć?

Kolejny punkt – Gdzie masz te informacje? Jak jest zbudowane to środowisko?

Najważniejsza jest świadomość tego, przed czym chcesz się chronić. Dla jednej firmy firewall za 2 miliony dolarów to za mało, za zaś dla innej firewall za 2 tysiące złotych będzie wystarczającym wydatkiem.

Podsumowanie

Pamiętajmy o tym, iż o ile opisujemy jakiś projekt lub inwestycję, pokazujmy językiem zarządu co przyniesie dane przedsięwzięcie, jak i czego unikniemy. najważniejsze jest pokazanie odpowiedzi na pytanie: Ale po co ja mam w to inwestować?

Odpowiedź powinna być następująca – organizacja uniknie tego i tamtego, unika takiej odpowiedzialności i ryzyka, na tyle policzonych, skwantyfikowanych – voilà! o ile będziesz realizował tego typu audyt, miej najpierw konkretny cel.

Druga rzecz – zastanów się, czy na pewno chcesz sprawdzać, pentestować to środowisko. Czy nie będzie lepsze „puścić” kogoś, żeby sprawdził konfiguracje. Być może wnioski ci podpowiedzą, iż tych procedur jest za mało – wy chcecie więcej, powiedzieliście to podczas rozmów roboczych. A później można to ładnie spiąć różnymi wnioskami, przedstawić to zarządowi, zaopiniować u nich. Stworzyć długą strategię, pod którą zarząd się podpisze, zaakceptuje ją.

To co najistotniejsze, przedstaw swoje argumenty takim językiem, aby druga strona chciała tego wysłuchać i była w stanie to zrozumieć po swojemu – dlaczego ma to zrobić, czego uniknie i co istotne, gdzie może „pobawić się” ryzykiem. Im więcej takich danych, tym więcej decyzji.