Zapraszamy do wysłuchania odcinka podcastu, w którym Damian Niklewicz z firmy ESKOM rozmawia z Markiem Graczykiem, managerem ds. cyberbezpieczeństwa. W tym odcinku przybliżamy temat Security Operations Center (SOC), wyjaśniając, czym jest, dlaczego odgrywa kluczową rolę w zapewnianiu bezpieczeństwa informatycznego oraz jak działa w praktyce. Dowiecie się, z jakich elementów składa się SOC, jakie procedury i narzędzia wspierają monitorowanie zagrożeń, jak wygląda reagowanie na incydenty oraz jakie znaczenie mają poszczególne linie wsparcia. Poruszymy również kwestie związane z analizą ryzyka, normami ISO oraz praktycznymi wyzwaniami, z jakimi mierzą się organizacje wdrażające systemy cyberbezpieczeństwa. To solidna dawka wiedzy dla wszystkich zainteresowanych ochroną danych i bezpieczeństwem IT.
Damian Niklewicz: Cześć, tu Damian Niklewicz z firmy ESKOM, dzisiaj jest ze mną Marek Graczyk, manager cyberbezpieczeństwa w Eskom. Cześć Marku.
Marek Graczyk: Cześć Damian, cieszę się, że możemy dzisiaj się spotkać i porozmawiać na frapujący dosyć temat i bardzo aktualny.
Damian Niklewicz: Tak, dzisiaj będziemy rozmawiali o SOC-u. Ja tak krótko w dwóch zdaniach powiem, że to jest Security Operations Center, różnie to różni ludzie nazywają.
Marek Graczyk: Centrum Operacji Bezpieczeństwa, to się próbuje jakoś spolszczać, ale spolszczać, przepraszam, ale przyznam szczerze, że nasza branża jednak mocno jest osadzona w języku angielskim i wydaje mi się, że to Centrum Operacji Bezpieczeństwa chyba się jeszcze w najbliższym czasie nie przyjmie, dlatego też mówimy o Security Operations Center, o SOC-u i tym się posługujemy.
Damian Niklewicz: Tak, właśnie. Co to takiego jest ten SOC i dlaczego jest taki ważny?
Marek Graczyk: No to już w Twoim pytaniu jest teza, że jest ważny. Rzeczywiście jest ważny. Security Operations Center to można powiedzieć pewien, organizacja, infrastruktura, ale nie tylko infrastruktura, która służy monitorowaniu bezpieczeństwa, ujmując to dosyć ogólnie organizacji, firmy, banku, firmy ubezpieczeniowej, ale też np. szpitala, np. firmy energetycznej czy dostawcy Internetu. Oczywiście to może być każda inna również firma z innej branży. Ta infrastruktura czy też te rozwiązania to jest jakby zestaw takich i narzędzi, i działań, których cel można powiedzieć jest jeden, monitorować bezpieczeństwo infrastruktury informatycznej, czy też w ogóle bezpieczeństwo informatyczne takiej organizacji.
Damian Niklewicz: Jak byś mógł powiedzieć z czego taki SOC powinien się składać?
Marek Graczyk: No tak jak powiedziałem to jest zarazem i narzędzia i jakby działania związane z tymi narzędziami. Jak mamy w organizacji, w firmie mamy infrastrukturę informatyczną, bardziej rozbudowaną, mniej rozbudowaną, no to często w takich organizacjach używamy różnych narzędzi np. do monitorowania tego jak ta infrastruktura informatyczna działa, pracuje, czy odpowiednie zasoby zapewniamy, żeby realizować procesy biznesowe, do których infrastruktura informatyczna, procesy informatyczne są wykorzystywane. I to jest takie monitorowanie powiedzmy twojego środowiska i zasobów i twojego sprzętu. Natomiast takim nieco wyższym poziomem, o ile tu można w takich poziomach ustawiać, ale spróbujmy, jest monitorowanie tego wszystkiego pod kątem bezpieczeństwa, czyli sprawdzanie np. czy do twojej mniej lub bardziej rozbudowanej infrastruktury próbuje mieć dostęp w sposób nieuprawniony ktoś, kto tego dostępu nie powinien mieć, czy w twoim środowisku dzieją się jakieś takie, mają miejsce takie zdarzenia, które powinny cię np. zastanawiać czy niepokoić. Powiedzmy sobie ktoś się próbuje 15 razy w krótkim czasie zalogować do jakiegoś systemu, a jeszcze na dodatek loguje się z powiedzmy sobie jakiegoś dziwnego adresu IP, który może wzbudzać swoje wątpliwości. Więc jakby to jest monitorowanie, w tym SOC-u monitorujemy wszystko to, co może się przerodzić. Takie zdarzenia, które mogą się przerodzić w incydenty. Incydenty, które w jakiś sposób zagrażają twojej firmie, bo na koniec można powiedzieć, że na końcu, no to i procesy informatyczne, narzędzia, to co masz służy prowadzeniu przez ciebie biznesu. Więc SOC jest po to, żeby monitorować czy nie dzieje się nic złego, nic dziwnego, bo czasami może być to po prostu coś dziwnego, co wpływa na prowadzenie przez ciebie biznesu. Tak gdybym szukał takiej czy definicji, czy takiego bardzo ogólnego ujęcia tematu.
Damian Niklewicz: A co, jeżeli coś złego się dzieje, coś dziwnego. Powiedzmy, że raz to będzie jakiś przypadkowy scenariusz jakiegoś zderzenia, a innym razem faktycznie nie wiem, zdajemy sobie sprawę, że mamy jakiegoś mola w organizacji i ktoś wykrada nam dane. To co wtedy?
Marek Graczyk: Oczywiście możemy takie rzeczy monitorować, starać się monitorować i po to jest właśnie SOC takim narzędziem, bo nie uciekniemy od narzędzi. Tak jak powiedziałem, że SOC to procedury, organizacja, ale też narzędzia. Takim głównym narzędziem, które jest wykorzystywane to są systemy typu SIEM. Ich celem jest właśnie zbierać dane z różnych miejsc w organizacji. Mówię tutaj miejsca, tak naprawdę mam na myśli różne systemy. Zbierać w jedno miejsce po to, żeby można przeprowadzić analizę według tak zwanych przyjętych scenariuszy. Te informacje jak zbieramy? Zbieramy logi. Sercem każdego SIEM, każdego narzędzia jest narzędzie, które zbiera ze wszystkich miejsc w systemach informatycznych logi. Jak wiemy dobrze, te logi powstają wszędzie, jest ich bardzo dużo. Oczywiście też cała filozofia, czy też dobre stworzenie SOC-a polega na tym, żeby analizować i zbierać tylko te logiki, które coś ci mogą powiedzieć o organizacji. Więc ten SIEM zbiera informacje i te informacje możesz analizować w oparciu o różne tak zwane scenariusze. Scenariusz to jest to, co się dzieje, to co się może dziać w organizacji i jest OK. A jeżeli odbiega od tego scenariusza, to znaczy, że nie do końca jest OK. Można też te scenariusze w drugą stronę ustawić, jeżeli np. trzymamy się tego najprostszego, możliwego przykładu do logowania. Można przyjąć, i tak się zazwyczaj przyjmuje, że gdzieś się próbujesz zalogować. Raz ci się nie udało, myślisz sobie, o kurczę, zmieniłem hasło, to spróbuję z tym. Logujesz się drugi raz, myślisz sobie, nie no, pewnie tam na początku to jest jednak wielka litera. I tak zazwyczaj trzy, cztery razy próbujesz. Zazwyczaj, mówimy tutaj oczywiście o statystyce, zazwyczaj się okazuje, że po tych czterech razach albo sprawdzisz to hasło w menedżerze haseł, albo już nie będziesz się dalej logował, tylko sprawdzisz jakąś historię, będziesz jakoś to weryfikował. Ale np. wyobraźmy sobie, że w ciągu minuty 50 razy próbujesz się gdzieś zalogować. No to mamy taki scenariusz w Security Operations Center, najprostszy, mówię, to jest najprostszy scenariusz, który mówi, każde takie zdarzenie, gdzie ktoś albo coś, no bo najczęściej jest to coś, tak, maszyna, próbuje się do jakiegoś systemu zalogować więcej niż ileś razy, no jest przynajmniej podejrzany, tak. Oczywiście specyfika każdej organizacji jest inna. Może się okazać, że no 50 razy na sekundę to już raczej maszyna się loguje, no ale powiedzmy 15 razy na minutę, to już to już jest wynik, który jest osiągalny przez człowieka i wtedy możesz się zastanowić, czy to jest zdarzenie, które Cię powinno niepokoić, jeżeli tak to jest ten incydent, ale może specyfika Twojej pracy jest taka, czy pracy tej organizacji, że może się zdarzyć, że nie wiem, są wypłaty, są jakieś kwestie księgowe, trzeba szybko się tam zalogować gdzieś do systemu i to nie powinno budzić Twoich wątpliwości. SOC to też nie jest tak, że to nie jest, wiesz, taki program, który odpalasz i on już raz, wiesz, go uruchomisz i on działa, on wymaga bardzo wiele tak zwanego dostrajania, tak, sprawdzania, jakie zdarzenia kwalifikujemy jako takie, które powinny nas zastanawiać, które zdarzenia są na pewno takie, że powinniśmy coś podjąć, jakieś działania. Zbieramy dane w tym SIEM-ie z różnych miejsc i analizujemy je w oparciu o scenariusze, jakie sobie przyjęliśmy.
Damian Niklewicz: Jasne, a jakbyś mógł trochę więcej powiedzieć o tym, co się dzieje w momencie, kiedy na przykład wiemy, że jest ten użytkownik, który 15 razy wpisuje hasło i najczęściej powinniśmy być w stanie nawet sprawdzić, który użytkownik i moglibyśmy nawet do niego zadzwonić. To można by powiedzieć, że takie reagowanie na te incydenty, czy to też wchodzi w skład tego SOC-a?
Marek Graczyk: Absolutnie tak i to jest, powiedziałbym, trudno tutaj mówić, która część jest ważniejsza, bo SOC to jest jakby całość, natomiast poruszyłeś tutaj bardzo ważną kwestię z doświadczenia i z praktyki, a współpracujemy z różnymi organizacjami, tak jak powiedziałem, komercyjnymi, bankami, firmami ubezpieczeniowymi, ale również takimi organizacjami jak szpitale, jak wodociągi, firmy energetyczne. Te ostatnie podmioty, te trzy, które wymieniłem są objęte taką ustawą, część ustawą o krajowym systemie cyberbezpieczeństwa, część tych podmiotów w ogóle ustawowo jest zobowiązana do tego, żeby pewne działania związane z bezpieczeństwem prowadzić. Dlaczego o tym mówię, bo często jak rozmawiamy z takimi organizacjami, to stykamy się, ja się stykam i inni nasi koledzy inżynierowie z taką sytuacją, że ktoś mówi, no ale my mamy taki program, my go uruchomiliśmy, no i on te logi to zbiera i tam czasem się zajrzy, tak w te logi. To już jest coś, ale to oczywiście nie jest SOC, bo to o czym powiedziałeś, właśnie to reagowanie, tak. Coś się wydarza i nawet już według tego scenariusza mamy podejrzenie, że jest to coś złego. No tylko pytanie, co zrobić, jak to się wydarza o 23.15 np. Albo co częściej ma miejsce gdzieś o 4 nad ranem, takich dziwnych, można powiedzieć, godzinach. No coś powinno się wydarzyć w odpowiedzi na to zdarzenie, tak. I tutaj mówimy o tej części organizacyjnej SOC, tak. Narzędzie, zbieranie informacji, alertowanie, tak. Różne są narzędzia, o nich też możemy troszkę powiedzieć, no ale gdzieś tam się zapala ta pomarańczowa lampka i co się dzieje dalej. No dalej powinien ktoś zareagować. W SOC-ach zazwyczaj dzielimy to, są różne koncepcje, ale taka dominująca jest taka, że dzielimy to wsparcie w ramach Security Operation Center na tak zwane linie, linie wsparcia. Pierwsza linia to są specjaliści, którzy oczywiście 24 godziny na dobę przez 7 dni w tygodniu, ten taki tryb 24 na 7, którym się często… 365 dni w roku. Tak, 24 łamane przez 7, przez 365. No to jest człowiek, który albo ludzie, tak, bo to zależy od wielkości takiego Security Operation Center, którzy… Jak się zapali ta pomarańczowa lampka, tak mówiąc już bardzo obrazowo, to muszą zareagować, tak? Albo są sami w stanie powiedzieć, jakiego rodzaju zdarzenie miało miejsce i czy jest to incydent. Co więcej, jak mają scenariusze, to scenariusze też przewidują metody reagowania. Można przyjąć na przykład, że, przepraszam, w przypadku tych piętnastu logowań, już przytrzymajmy tego przykładu, taki operator pierwszej linii, taki specjalista, który jest na pierwszej linii wsparcia ma napisane w scenariuszu nie wnikaj, co tam się dalej dzieje, piętnaście razy w ciągu minuty ktoś się loguje, blokuj konto na pół godziny, tak? Może to być blokowanie konta na pięć minut, może to być zablokowanie konta do, powiedzmy sobie, godziny ósmej rano, tej przysłowiowej ósmej rano, kiedy przychodzi pracownik organizacji i powie tak, okej, to ja rozumiem, kto się logował i dlaczego, zwalniamy tą blokadę, tak? Więc ta pierwsza linia reaguje zgodnie ze scenariuszem, tam jest potrzebny człowiek, który już pewne działania podejmie. No ale oczywiście może się zdarzyć coś takiego, takie zdarzenie, które zostanie zakwalifikowane jako incydent, że ten operator pierwszej linii powie, no nie wiem, dziwne, nie mam wzorca na to, nie rozumiem tego. Przekazuje to wyżej, do tak zwanej drugiej linii, tam już są inżynierowie wyspecjalizowani, którzy też w odpowiednim czasie, bo tutaj czas ma znaczenie, tak? Zazwyczaj w SOC-u przyjmuje się pewne parametry, jeśli się coś wydarzy, zapali się pomarańczowa lampka, jest 15 na przykład minut na pierwszej linii, żeby podjąć decyzję. Decyzję albo taką, albo taką. Albo samodzielnie ten operator sobie radzi, mówimy o tym, że zamyka taki incydent, rozwiązuje go, tak? A jeżeli przekracza to, to co jest w scenariuszu, przekracza to jego wiedzę i przekracza to czas, no to przekazuje do drugiej linii. A druga linia to są inżynierowie, którzy, no działają jakby, czasami się mówi tak z angielska, o myśleniu poza, out of the box, myśleniu poza tam kwadrat, tak? Taki człowiek ma już, niekoniecznie patrzy wyłącznie na scenariusze, ale jest w stanie w oparciu o swoją wiedzę specjalistyczną, no też przeanalizować co się dzieje, tak? I rozwiązać takie zdarzenie, taki incydent, zaproponować coś nieszablonowego. Jest jeszcze trzecia linia, która to jest, to już są takie bardzo wyspecjalizowane działania związane na przykład z analizą powłamaniową. Ktoś się do nas włamał, jakiś port mieliśmy niezamknięty, ktoś coś tam pozyskał z organizacji, nie do końca wiemy, jak on to zrobił, nie do końca wiemy co wyciągnął, mówiąc tak bardzo potocznie. To wtedy jest ta trzecia linia, to już są bardzo wyspecjalizowani ludzie, którzy są w stanie na podstawie wszystkich zapisów z Security Operations Center, z narzędzia, z innych miejsc.
Damian Niklewicz: Ci na trzeciej linii to już siedzą w kapturach, tak?
Marek Graczyk: No to tak się przyjmuje, ci na drugiej czasami też mają kaptury, ale to już są naprawdę wysoko wyspecjalizowani. Więc te trzy linie, bo pytałeś o to, no to są ludzie, to są ludzie. Oczywiście możemy powiedzieć, że rozwiązania AI, sztuczna inteligencja będą nas tutaj wspomagać i rzeczywiście nas tu wspomagają. Myślę, że dzisiaj nie będziemy szczególnie tego tematu eksplorować, natomiast ciągle w takim normalnie działającym SOC-u są ludzie na różnych poziomach, którzy w określonych czasach reagują. I dlaczego o tym tak dużo mówię, już jakby skrócę, dlatego że najczęściej popełniany błąd w organizacjach polega na tym, że ktoś powie tak, mam różne dziedzinowe oprogramowania, ten do zarządzania hasłami, to do zarządzania dostępem, to do zarządzania danymi, no to sobie jeszcze zainstaluję taki SIEM właśnie program, który w zasadzie będzie mi zbierał te logi i mam odhaczone bezpieczeństwo. To zupełnie nie, to jest połowa, a nawet jak niektórzy przekornie mówią, mniejsza połowa całego rozwiązania, całego systemu.
Damian Niklewicz: Dobrze, czyli podsumowując, mamy tą część powiedzmy infrastrukturalną, systemową, tego SIEM-a, kolektor logów, czy tą sztuczną inteligencję, no i mamy tych ludzi, pierwszą, drugą, trzecią linię. Czy to musi działać 24 godziny na dobę, 365 dni w tygodniu, czy można na przykład, nie wiem, od 8 do 16, czy to miałoby sens?
Marek Graczyk: To jest pytanie, w takich przypadkach zazwyczaj używa się słowa czy odpowiedzi wytrychu, to zależy. No i ja też powiem, to zależy. Czasami problemu, o ile to jest w ogóle problem, zdecydować, czy 24 na 7 na 365, czyli cały czas, przez cały rok, rozwiązuje się sam, w tym sensie, że tak jak powiedziałem przed chwilą, są organizacje typu właśnie szpitale, firmy energetyczne, wodociągi, gdzie ustawa, w tym przypadku w Polsce ustawa KSC, Krajowym Systemie Cyberbezpieczeństwa, za chwilę będziemy mieć kolejną wersję tej ustawy, bardzo restrykcyjnie regulującą niektóre obszary. Czasami masz w ustawie napisane, chcesz, nie chcesz, musisz. Czasami jest tak, że powiedzmy firma komercyjna powie tak, a ja nie podlegam żadnej ustawie, nie jestem podmiotem, który jest regulowany, nie jestem bankiem, nie jestem firmą ubezpieczeniową, nie mam nad sobą komisji nadzoru finansowego, nic mnie nie reguluje. No ale pytanie, można sobie zadać takie pytanie, no dobrze, czy złoczyńcy pracują zgodnie, tu zażartuję trochę z kodeksem pracy, że to od 8 do 16, a potem mają fajrant? No nie, no nie, no wiemy dobrze, że takie zdarzenia, poza tym specyfika, tak? Specyfika jest taka, że u nas jest teraz powiedzmy sobie południe, a gdzieś jest godzina powiedzmy siedemnasta, tak? I wtedy ktoś za parę godzin będzie nad ranem miał czas, żeby usiąść i spróbować dostać się do naszego systemu, który a u nas będzie północ wtedy, tak? Więc mówiąc krótko, te systemy powinny są, powinien działać dwadzieścia cztery na siedem. Oczywiście tutaj można dzielić włos na czworo, jak powiedzą niektórzy i powiedzieć tak, można też te zdarzenia, które mają miejsce w naszych systemach w pewien sposób rankingować i rzeczywiście tak to wygląda, bo ze względu na to jakiego rodzaju oprogramowanie SIEM mamy wdrożone, są open source’owe, dobrze działające, są komercyjnie, komercyjne, dobrze działające, to tam w tych narzędziach można gdzieś takim suwakiem ustalić, że pewne zdarzenia mają mniejszy priorytet albo mniejszą dolegliwość, niektóre mają powiedzmy sobie średnią, ale są takie zdarzenia, które mają wysoki priorytet i tymi się powinniśmy zajmować bezzwłocznie. Więc można powiedzieć tak, że jak taki SOC mam już uruchomiony, on działa, no to gdzieś te decyzje w oparciu o zadane parametry są podejmowane i powiedzmy sobie do operatora trafiają rzeczy naprawdę istotne, krytyczne, jak mówimy, a te mniej krytyczne, jakie sobie zdefiniujemy, mogą na przykład poczekać do tej ósmej rano, aż przyjdzie ktoś do firmy i je rozwiąże. Natomiast co do zasady SOC powinien działać 24 na 7 na 365, natomiast jest tak, rzadziej, ale się zdarza, że niektóre firmy, o ile są duże, mają duży dział IT, dużo wewnętrznie ludzi, jeżeli współpracują na przykład nie wiem z nami, mówią tak, to my od tej przysłowiowej ósmej do szesnastej to mamy swój monitor swoich ludzi i oni się tutaj zajmują tym, co się dzieje, a wy w tym przypadku ESKOM przejmijcie tą ochronę od tej szesnastej do godziny ósmej następnego dnia, chociaż muszę powiedzieć, że częściej mówimy tutaj o ochronie takiej, której my, to nasza pierwsza linia, druga i trzecia działa w trybie 24 na 7.
Damian Niklewicz: Powiedziałeś, że mamy organizacje jakby dwa rodzaje. Te, które na przykład podlegają pod ustawę o tym Krajowym Systemie Cyberbezpieczeństwa, czyli są przykładowymi operatorami usług kluczowych. Natomiast są też takie organizacje, które nie są objęte żadnymi powiedzmy restrykcjami, ale są już na tyle duże i na tyle uświadomione, że też wdrożą tego SOC-a. To pytanie, na co powinny zwracać uwagę te drugie? Czym się powinny kierować?
Marek Graczyk: Znaczy ja myślę, że już pewne sytuacje, powiedziałbym społeczne i polityczne, tutaj nie sposób nie wspomnieć na przykład konflikcie, który jest u naszej granicy. Już jakby nie wchodząc w ten obszar i tematykę, jakby pokazały, że różne organizacje w krajach, które nie są ze sobą, że tak powiem w dużej przyjaźni, tak bardzo postaram się to dyplomatycznie ująć, no może się tak zdarzyć, że cybernetycznie czy też zdalnie ktoś może próbować na te nasze organizacje próbować wpływać. Dlatego myślę, że w przypadku organizacji również komercyjnych, o których mówisz, ta świadomość, że musimy monitorować bezpieczeństwo już jest na tyle duża, że to nie jest pytanie czy, no to jest pytanie, czy już mam wdrożonego SOC-a, czy jeszcze nie mam wdrożonego SOC-a. Na co powinny zwracać uwagę. Mówiąc krótko, to jakie znaczenie dla biznesu mają dane, mają informacje, a jest poniekąd truizmem, ale to prawda, że we wszystkich biznesach, o jakich możemy pomyśleć, te informacje gdzieś stanowią bardzo ważną część. Zanim uruchomimy SOC-a, to nie jest tak, że uruchamiamy go tak od razu. Często, żeby nie powiedzieć zawsze, powinniśmy wykonać tak taką analizę ryzyka i właśnie zastanowić się, czy ryzyka związane z informacjami, z ich przetwarzaniem, czyli wszędzie tam, gdzie wykorzystujemy infrastrukturę IT są na tyle istotne, że powinniśmy się nimi zająć i zabezpieczyć. Może podam taki przykład. Jeżeli prowadzisz taki, jak to się mówi, oldschoolowy warsztat mechaniczny, gdzie tylko tym pilnikiem tam piłujesz coś i jakby komputer jeden masz tylko po to, żeby sobie pocztę sprawdzić, bo tak wpływają do ciebie zamówienia i masz pięciu pracowników, którzy w tym warsztacie mechanicznym pracują, nie masz żadnych systemów IT, tak naprawdę to musisz mieć tylko oświetlenie, żeby pracować i pilnik. Tutaj analiza ryzyka może pokaże, że niespecjalnie jakoś informatycznie można twojej firmie zaszkodzić, tylko ja specjalnie podaję taki przykład, który można sobie wyobrazić, ale których jest niewiele. żeby pokazać, że tak naprawdę większość naszej pracy, czy jesteśmy, pracujemy w małej firmie, czy dużej, jest uzależniona od systemów IT. I wszędzie tam należy taką analizę ryzyka wykonać i z tej analizy ryzyka wynika, jak istotne są informacje, które systemy są istotne, jeżeli chodzi o tak zwaną ciągłość działania. Co się zdarzy, jak na przykład ten system X przestanie u nas działać. Jeżeli się tak okaże, że ten system nie działa, możemy się, nie wiem, posiłkować pracą w oparciu o zeszyt i długopis i tak pracować przez tydzień, no to powiem szczerze, być może ktoś powie, no to nie myślcie tutaj o takich zaawansowanych rzeczach jak SOC, ale w każdym innym przypadku to już się zastanówcie, ile was kosztuje to, że te systemy, czy ten system nie będzie działał. Bo z SOC-iem Security Operation Center, jak z każdym rozwiązaniem IT, no gdzieś się zastanawiasz, ile cię to kosztuje i ile ci to zaoszczędza, tak? Więc to jest coś, na co organizacje powinny zwrócić uwagę. Czy brak tego SOC-a mi się opłaca? Znaczy, co będzie, jak nie będę miał SOC-a i co będzie, jak jednak jakieś zagrożenia się zmaterializują? Także analiza ryzyka jest tu podstawą.
Damian Niklewicz: Analiza ryzyka, czy inaczej po angielsku, tak jak SOC, to BIA, czyli Business Impact Analysis, jest częścią planu ciągłości działania, kiedy to najpierw robimy i tu mamy na przykład różne normy i standardy, tak jak norma ISO do analizy ryzyka, do planu, do ciągłości działania to jest 22301. Czy są jakieś inne normy, standardy, procedury, które właśnie mogłyby pomóc nie tym firmom, które obsługiwane są przez ustawę, jeszcze raz, które mogłyby pomóc tym firmom, które nie podlegają pod ustawę.
Marek Graczyk: Tak, znaczy tu poruszyłeś parę ważnych kwestii, bo ja tak mówię o analizie ryzyka, tą analizę ryzyka czasami się przeprowadza w firmach w taki sposób powiedziałbym dorywczy, taki z doskoku, natomiast ty powiedziałeś…
Damian Niklewicz: Tak, jeszcze dopowiem, że o SIEM-ie będziemy mieli oddzielny materiał, tak samo o samym planie ciągłości działania. Tutaj jakby wyjaśniłem, bo to są wszystko narzędzia połączone.
Marek Graczyk: Tak, znaczy to jest w ramach tego systemu, o którym mówiłem, to może rozwikłajmy te skróty. Znaczy analizę ryzyka, bo to jest tak, tak naprawdę jak myślisz o SOC-u, po co on jest, no to chodzi o to, żeby ci firma działała. Mówiąc już tak najprościej, żebyś robił swoje, realizował swój biznes, swoje procesy biznesowe. Więc robi się rzeczywiście coś, co się nazywa business impact analysis, analiza, tu akurat to spolszczenie jakby jest, niektórzy się nim posługują. Jest adekwatne, tak. Analiza wpływu na biznes. Musisz się zastanowić, no masz ileś procesów w firmie, musisz się zastanowić, które są kluczowe, bo wszystkich nie będziesz analizował i musisz się zastanowić, w których z tych kluczowych procesów, jeżeli chodzi o twoją infrastrukturę i narzędzia IT, te narzędzia, ta infrastruktura odgrywa ważną rolę. Jak sobie to wszystko przeanalizujesz i sobie pogrupujesz, to wtedy robisz analizę ryzyka i się zastanawiasz, jakie zdarzenia mogą wpłynąć i jak mogą wpłynąć na te procesy biznesowe. Czyli robisz business impact analysis, analizę wpływu na biznes, potem robisz analizę ryzyka. To jest tak naprawdę ćwiczenie pod tytułem, jak zagwarantować ciągłość działania mojej organizacji. I to rzeczywiście, jak to zrobić, taką analizę ryzyka i wpływu na biznes? No to cóż, ktoś już wymyślił pewne rozwiązania. To jest norma, którą przywołałeś, ISO 22301. W ogóle, jeżeli chodzi o organizację ładu informatycznego w firmie, najczęściej firmy posiłkują się dobrze już w Polsce ugruntowaną normą ISO 27001. Pytasz, czy są jakieś inne. Oczywiście, że są. Normy ISO są mocno rozpowszechnione i ugruntowane w Polsce, w Europie i przyjmuje się, w ustawie raz się to pojawiało, teraz będzie nowa ustawa, być może się pojawi odesłanie takie wprost do tych norm, być może nie, zobaczymy. Natomiast to jest takie nasze, powiedziałbym, europejskie podejście. W Stanach Zjednoczonych Amerykanie mają swoją taką ramę odniesienia, jak to się mówi, NIST. NIST, który definiuje też wiele standardów. Tak naprawdę są to pewne standardy, które mówią, ten obszar twojej firmy w zakresie IT powinien być zorganizowany tak, powinieneś robić to, najlepsze praktyki są takie. Są jeszcze inne koncepcje. COBIT, CIS to są, tutaj nie będziemy bardzo szczegółowo wchodzić w szczegóły tych poszczególnych rozwiązań. Natomiast są to pewne, powiedziałbym, ramy odniesienia, nic mi lepszego do głowy nie przychodzi. Taki standard, taka checklista już upraszczająca według której się porównujesz. No ISO jest bardzo dobrą checklistą, to jest standard ISO 27001 lekko odświeżony i znowelizowany dwa lata temu, a przyjęty w Polsce rok temu, który jest bardziej już unowocześniony i dla Ciebie jest to taka w dużym uproszczeniu checklista, żeby sprawdzić jak moja organizacja wypada na tle tych zabezpieczeń czy tych wymagań, które są. Więc tych standardów jest dużo, w Polsce przyjmuje się najczęściej odwołanie do ISO i jednego, i drugiego.
Damian Niklewicz: Jakie zdarzyły Ci się najfajniejsze, najciekawsze incydenty, na które musiałeś reagować?
Marek Graczyk: No nie wiem, czy incydenty same w sobie są ciekawe. No często jest tak, czy smaczek, to może w pierwszych incydentach, a potem też taka obserwacja, która płynie z praktyki, z praktyki wdrażania przez nas, przez ESKOM, Security Operations Center u wielu klientów, na ciekawsze incydenty. No myślę tak, najprostszy, czyli logowania bardzo dziwne, nie wiem, skanowania portów na przykład, jeżeli już tak technicznie patrzymy, niepozamykanych różnych, czyli takich dziwnych miejsc, przez które możemy wejść do organizacji. Dużo jest na przykład, wiele firm ciągle jeszcze ma swoje strony firmowe WWW utrzymywane w pewnego rodzaju oprogramowaniu, którego nie będę tutaj z nazwy wymieniał, które jest idealną tarczą strzelniczą dla wszelkich osób, które próbują coś tam pozmieniać na stronie albo do firmy się dostać. I jeszcze jedną rzecz bym powiedział, jeśli chodzi o tą drugą stronę, czyli o tych, którzy próbują się do nas, nie wiem, włamać, coś od nas wyciągnąć, mówię tutaj o organizacjach, zawsze na to zwracamy uwagę, że ten rodzaj działalności już nie wymaga naprawdę skończenia studiów magisterskich z informatyki, tylko wymaga znajomości prostych, zautomatyzowanych, dających się pobrać z ogólnodostępnych stron narzędzi, lekkiego zdefiniowania parametrów w tych narzędziach i próby wykonywania bardzo prostych rzeczy. Pytasz mnie o takie ulubione incydenty, czy ciekawe? No cóż, mogę powiedzieć, że tak zwanym evergreenem już od wielu sezonów są proste próby wymuszeń na przykład mailowych, czyli phishing, najprostszy mailowy phishing, jakieś dziwne komunikaty, takie, które, wiesz, jak czytasz, to Ci się wydaje, że on jest dla Ciebie, do Twojej firmy, do Twojej specyfiki, a to są ogólne, automatyczne komunikaty, które są lekko gdzieś tam profilowane. Tego jest bardzo dużo i tego nie będzie mniej, ponieważ narzędzia, które umożliwiają prowadzenie tego typu działań, jest ich coraz więcej i są coraz prostsze w obsłudze. Natomiast powiedziałem o takiej obserwacji płynącej z wdrażania Security Operations Center w wielu organizacjach. Często, jak wchodzimy do organizacji, ktoś mówi, dobra, to weźcie nam tego SOC-a tutaj, zróbcie. A mówimy, dobrze, no to zanim będziemy tutaj o tym rozmawiać, to kiedy wykonywaliście ostatnio skany podatności, tak? Jakie macie procedury tutaj? Okazuje się, mówiąc krótko, że próbujemy budować dom, zaczynając od dachu. Więc często, zanim my w ogóle przejdziemy do tworzenia SOC-a, no to musimy wykonać wiele czynności bardziej, że tak powiem, prostych, które są nieodzowne, jeżeli mówimy o zapewnieniu bezpieczeństwa. Bo powiedz mi, po co mamy wdrożyć tego, uruchomić SIEM-a, zdefiniować SOC-a i go uruchomić? Jak na przykład na pytanie o skany podatności ktoś mówi, a pamiętam, przed covidem był jeszcze jeden skan. To są działania, które powinny być wykonywane cyklicznie. Raz na kwartał, raz na miesiąc, no niektórzy mówią dwa razy do roku. Na co jeszcze zwróciłbym uwagę, a to jest obserwacja z praktyki. Z praktyki, czyli z wielu wdrożeń, jakie wykonujemy. Mówiąc metaforycznie, nie zaczynajmy budowy domu od dachu, tak? Często jak trafiamy do organizacji, ktoś mówi, dobra, zróbcie, to musimy mieć SOC-a, robimy. No to mówimy, okej, no ale kiedy robiliście ostatnie skany podatności, tak? Jakie macie procedury w tym zakresie? Co z backupem? Robicie świetnie, odtwarzacie, testujecie? No nie, no to może to. Więc dlatego ten SOC nazywam dachem, że on powinien być zwiększeniem, tak? Całej budowli. Czasami są organizacje, które bardzo w sposób taki powiedziałbym przyczynkarski monitorują swoją infrastrukturę, jeżeli chodzi o wydajność. Mówimy, to zróbcie to, zróbcie to i dalej na tym budujemy bezpieczeństwo, bo powiedz mi, jak nie robimy skanów podatności, nie wiemy, gdzie są podatności w naszym oprogramowaniu, no to potem, jak uruchomimy tego SOC-a, to jak to inżynierowie często mówią, wszystko będzie ćwierkać, wszystko się będzie palić na czerwono, bo na przykład system wykryje czy narzędzie wykryje podatność wysokiego poziomu, a tu chodzi o to, żeby zaktualizować, tak? Dane urządzenie, zaktualizować firmware, zrobić, nie wiem, spatchować, czyli gdzieś tam łaty wgrać. Więc to jest rzecz, którą obserwujemy i o tym zawsze mówię. Zaczynajmy od fundamentu, a nie od dachu.
Damian Niklewicz: To wydaje mi się, że…, że opowiedzieliśmy krótko, czym ten SOC jest. Zapraszamy do kontaktu z nami i dziękuję ci, Marku, za tę zwięzłą opowieść.
Marek Graczyk: Mógłbym jeszcze dłużej, ale mam nadzieję, że najważniejsze kwestie przekazałem. Dzięki, Damian.
Damian Niklewicz: Dzięki. Cześć.