jak-nie-zabezpieczac-it-e-commerce

Jak (nie) zabezpieczać IT / e-Commerce?

Mówi się, że są tylko dwa rodzaje firm: te, które zostały shakowane i te, które dopiero zostaną. Dzisiaj będzie (niestety) o tych pierwszych dla tych drugich.

Przyznam Ci się, że to jeden z trudniejszych artykułów, z jakim przyszło mi się zmierzyć na blogu X-Coding IT Studio. Z jednej strony wiem, że przygotowałem materiał, który może pomóc naprawdę wielu firmom. Z drugiej strony ten sam materiał powstał jako nasz plan naprawczy, który jest reakcją na skuteczny atak hakerski. Nie muszę chyba (?) dodawać, kto był ofiarą.

Mimo osobistego konfliktu wewnętrznego, postanowiłem podzielić się ze światem tym przykrym case study z dwóch powodów:

  1. „Pracujemy zespołowo, rzetelnie i otwarcie” – to druga z pięciu wartości firmy. Kiedy spisywaliśmy je, obiecaliśmy sobie nigdy nie zamiatać spraw pod dywan. Jasne, moglibyśmy ten jeden raz spróbować, w końcu takie rzeczy się dzieją na co dzień, ale co dalej? No i kiedy mamy zdać nasz egzamin, jeśli nie właśnie w takiej sytuacji?
  2. Staramy się być organizacją antykruchą, to znaczy reagować na problem w taki sposób, żeby już nigdy nie wystąpił. Tym razem poświęciliśmy na to naprawę 300% naszej energii. Dzieląc się tą wiedzą, mam nadzieję, że ktoś skorzysta i nie będzie musiał uczyć się na własnych błędach.

Co właściwie się stało

Opowiem Ci, jak może wyglądać atak hakerski na naszym przykładzie. W tym wypadku stwierdzenie „dramat w trzech aktach” jest najlepszym określeniem, na jakie wpadłem.

Finał. Zacznijmy od najnowszych wydarzeń. W momencie, kiedy skończył się atak, okazało się, że naprawdę niewiele zabrakło, a pozbylibyśmy się wszystkich danych z kilku serwerów. Możemy mówić o sporym szczęściu, bo proces szyfrowania danych szedłby sobie w najlepsze i zakończył się , gdyby tylko wystarczyło miejsca na dysku. Jeśli nie znasz ataków typu ransomware, to polegają one na tym, że specjalny skrypt szyfruje wszystkie dane a na koniec sam się usuwa, przez co nie ma możliwości odwrócenia tego procesu (no chyba że odgadniesz klucz, ale to w praktyce niemożliwe).

Po co komuś szyfrować dane? Bo często ich odzyskanie jest bezcenne i to w skrócie „model biznesowy” osób odpowiedzialnych za takie działanie.

Na szczęście skrypt się nie zakończył na żadnym z serwerów, na których został uruchomiony, więc „posprzątanie” tego całego bałaganu było co prawda czasochłonne, ale w pełni wykonalne. W zasadzie większość zdolności operacyjnej uzyskaliśmy w ten sam dzień, a pełną po dwóch.

Szczególnie zwracam tutaj uwagę na początek relacji. „Okazało się” i „spore szczęście” to zwroty, które bardzo dobrze odzwierciedlają naszą bezwładność w obliczu całej tej sytuacji.

Kilka godzin wcześniej. 4 serwery (dwa nasze i dwa zewnętrzne) zaczynają zachowywać się dziwnie. Wszystko muli. Jeden projekt przestaje działać. Chwilę po nim drugi. Okazuje się, że w tym pierwszym zniknęła baza danych.

To był właśnie ten przykry moment, w którym dotarły do nas tak naprawdę trzy rzeczy:

  • jesteśmy w środku ataku i nie wiemy co się dzieje,
  • biorąc pod uwagę sam przebieg, nie było to działanie automatu,
  • rozproszenie (różne serwery) sugeruje, że całość musi mieć związek bezpośrednio z nami.

Warto w tym miejscu rozwinąć trochę ostatni punkt. Biorąc pod uwagę, że nie wszystkie serwery były naszymi wewnętrznymi, byliśmy pewni, że atak musiał być powiązany z nami – albo atak na nasz serwer pozwolił bezpośrednio na atak na inny, albo wiedza o innym serwerze była inspiracją do podjęcia próby włamania. Zrzucenie tego na przypadek byłoby naiwne.

2 tygodnie wcześniej. Analiza powłamaniowa (o której trochę później) wykazała, że cała impreza u nas zaczęła się mniej więcej dwa tygodnie wcześniej. Wyrok (który do teraz dzwoni mi w uszach) – wyciekł jeden z naszych systemów wewnętrznych.

W X-Coding IT Studio, jak w każdej innej firmie, trudności się zdarzają. Ta sytuacja nagle zyskała rangę co najmniej TOP3, a mówimy tutaj o 10-letniej firmie.

Mam teraz dla Ciebie ćwiczenie – nieważne, czy jesteś agencją taką, jak my, czy sklepem internetowym, czy jeszcze innym biznesem. Zrób sobie szybki rachunek sumienia, jak niebezpieczna będzie sytuacja, w której ktoś dostaje dostęp do Twojego systemu (np. CRM)? Ile jest tam na przykład informacji o dostępach?

Mam poczucie, że akurat ten egzamin zdaliśmy zadziwiająco dobrze, bo ostatecznie mamy podejrzenie tylko co do jednego złamania zabezpieczeń właśnie w ten sposób. Ale uwierz mi, pierwsza myśl była o wiele bardziej ponura. Gdybym miał to zobrazować, to wyszło trochę tak, jak gdyby złodziej ukradł Ci kluczyki do samochodu i udało mu się zabrać tylko radio.

Dlaczego się stało?

Tyle o przebiegu.

Trudno mi doliczyć, ile godzin poświęciliśmy na weryfikację wszystkich logów na serwerze (sami oraz przy wsparciu dwóch firm, które zajmują się tym profesjonalnie). Cele były dwa: poznać przebieg wydarzeń i zrozumieć, gdzie popełniliśmy błąd.

O pierwszym Ci opowiedziałem. Błąd też się odnalazł. W jednym momencie zaistniały trzy rzeczy:

  • hasło do aplikacji w miejscu na serwerze, w którym nie powinno go być (lub miejsce nie powinno być dostępne),
  • podatność aplikacji na wgranie backdoora,
  • podatność środowiska na użycie backdoora.

Dwa z trzech powodów to my.

Proszę, żebyś jeszcze raz przeczytał te trzy punkty. Teraz spróbuj ocenić sprawę obiektywnie – czy to jest bardzo duży kaliber?

Według mnie nie. Nie zrozum mnie źle, to nie próba wybielenia się. Ale umówmy się, że to nie był błąd w stylu „zrzut bazy danych dostępny w publicznym katalogu” (chociaż i takie błędy zdarzało nam się historycznie znaleźć). Oczywiście efekt ma większe znaczenie niż powód i w tym sensie to nieważne, czemu serwer nie był akurat wtedy aktualny i czemu to hasło było w tym miejscu. Ale zwróć uwagę, że nie trzeba wcale wielkich uchybień, do dużej wtopy wystarczy nawet odpowiednia konfiguracja kilku małych.

Co z tym zrobiliśmy?

Do tego momentu artykuł miał wydźwięk wyłącznie destruktywny. Jeśli się zestresowałeś, to znaczy, że osiągnąłem swój cel, bo jest szansa, że poniższy plan działania spowoduje, że więcej niż jedna agencja stanie się naprawdę bezpieczna.

1. Odpowiedzialność informacyjna

Celowo nie używam słowa „obowiązek”, bo chcę uniknąć skojarzenia, że coś zrobiliśmy z „musu”. Równocześnie uruchomiliśmy trzy kanały informacyjne:

  1. Klienci – z każdym klientem, niezależnie od tego czy miał prawo, czy nie miał prawa być pokrzywdzony, porozmawialiśmy i przekazaliśmy bardzo dokładnie, jak wyglądają sprawy. Ochrona naszych klientów to nasza największa odpowiedzialność.
  2. RODO – każdy wyciek to jakieś dane osobowe. Nie chcąc samodzielnie oceniać ich wrażliwości, sprawę od razu zgłosiliśmy do RODO.
  3. Policja – czego byśmy nie powiedzieli, trzeba pamiętać, że wydarzyło się przestępstwo. I chociaż nie upatrujemy wielkich szans, sprawa została zgłoszona organom ścigania.

Jeśli przytrafi Ci się taka sytuacja, pamiętaj koniecznie o wszystkich trzech. Strategia unikania rozmowy, czy wręcz tuszowania sprawy, ma bardzo krótki termin ważności.

2. Wielkie sprzątanie

W zasadzie równolegle do rozmów uruchomiliśmy proces najpierw zmiany, a później posprzątania wszystkich wrażliwych dostępów, które mogły wpaść w niepowołane ręce. Szczególnie musieliśmy w bardzo krótkim czasie:

  1. Odnaleźć wszystkie dostępy, które ktoś kiedyś mógł zostawić w naszym systemie,
  2. Usunąć zapisy,
  3. Zmienić wszystkie dane dostępowe,
  4. Usunąć publiczny dostęp do linków, które były do znalezienia w systemie (np. Google Docs).

Możesz sobie wyobrazić, ilu systemów dotyczyła akcja i jak szybko musiała się zmaterializować. Ja zwrócę uwagę na jeszcze jedną ważną rzecz, która być może nie jest widoczna na pierwszy rzut oka. Otóż wszystko pochłonęłoby o wiele mniej stresu, gdyby tylko pilnować haseł. To w praktyce jest niewykonalne w stu procentach, ale na pewno warto podjąć taką próbę. Więc jeśli masz gdzieś pozapisywane hasła na Wiki, w dokumentach Google, czy ktoś je sobie zapisał na kartce i przykleił na monitorze, to właśnie jest dobry moment, żeby przestać.

3. Audyt bezpieczeństwa

Analiza powłamaniowa i audyt bezpieczeństwa serwerów, które „się złamały” musiał nastąpić tak szybko, jak poprzednie dwa punkty. W końcu uzyskanie zdolności operacyjnej na skompromitowanej architekturze to proszenie się o dodatkowe kłopoty.

Dlatego wyłączyliśmy wszystko, bez czego można było żyć, zabezpieczyliśmy to, bez czego nie można i w międzyczasie uruchomiliśmy dwa niezależne audyty, o których wspomniałem już wcześniej. Celem było usunięcie do końca wszystkich podatności i przygotowanie planu podniesienia zabezpieczeń.

Ten krok usuwania podatności niestety jest często pomijany i firmy zatrzymują się na zaleczeniu objawów i podniesieniu bezpieczeństwa. To trochę, jak zbudować wielki mur i zostawić otwarte drzwi. Bez sensu.

4. Wdrożenie planu naprawczego

Dochodzimy do najważniejszej części artykułu, a więc naszych kroków, które podjęliśmy, żeby być w przyszłości mniej „wrażliwi” i przy okazji porad dla Ciebie, żebyś mógł uczyć się na naszych błędach.

  1. Ograniczenie dostępów do serwerów – to świetny przykład chodzenia na skróty. Bo ktoś kiedyś nie miał jak wygenerować klucza, więc na jakimś serwerze wyłączymy na chwilę logowanie kluczem. Cytując Edgara Allana Poe – „Nevermore”. Sprawdziliśmy wszystkie serwery, którymi administrujemy i ograniczyliśmy możliwość logowania się do minimum przy maksimum bezpieczeństwa.
  2. Posprzątanie danych – przejrzeliśmy wszystkie projekty i wszystkie serwery pod kątem danych, które przechowują (na przykład kawałek bazy produkcyjnej na serwerze testowym). Wszystko zostało pousuwane lub zanonimizowane.
  3. Usunięcie wszystkich haseł i dostępów – wdrażamy obecnie systemowy sposób na bezpieczne zarządzanie hasłami, który w wystarczający sposób zabezpieczy dostęp do haseł przez osoby nieuprawnione.
  4. Wdrożenie 2FA – two-factor authentication to dodatkowe zabezpieczenie logowania jednorazowym kodem, który jest możliwy do wygenerowania tylko na autoryzowanym przez użytkownika urządzeniu. Wdrażamy ten sposób logowania wszędzie tam, gdzie technologia na to pozwala. Jeżeli masz system, który przechowuje hasła to jest to na pewno must have w tamtym miejscu
  5. Rozdzielenie serwerów – chcemy uniknąć sytuacji, w której przełamanie jednego systemu umożliwia dostęp do drugiego. Rozdzielenie systemów na pewno będzie znacząco zmniejszało takie ryzyko, dlatego wdrażamy model „jeden serwer – jedna usługa”.
  6. Wdrożenie VPN – jeśli system jest tylko na nasz użytek, zostanie ukryty za firmowym VPN.
  7. Cykliczne ręczne i automatyczne testy wszystkich środowisk – będziemy poddawać cyklicznej kontroli bezpieczeństwa dosłownie wszystko, co mamy w opiece. Jeśli trafi nam się nowa podatność, chcemy się o tym dowiedzieć pierwsi.
  8. Wdrożenie polityki bezpieczeństwa – wdrażamy obecnie zestaw reguł bezpieczeństwa i dostępów, dzięki któremu będziemy mieli lepszą kontrolę nad udzielonymi dostępami i jednocześnie zbiór zasad, które pozwolą nam utrzymać pewien standard.
  9. Komunikacja wewnętrzna – wszystko, co teraz wdrażamy, trafi jako instrukcja do onboardingu nowych pracowników. Obecni pracownicy zostaną przeszkoleni i będą mieli realny wpływ na dalszy rozwój zabezpieczeń.

Chciałbym powiedzieć, że punkty x,y,z są super ważne, a g,i,k można sobie podarować. Ale tak nie jest.

Powiem więcej. Taka polityka nie ma prawa zadziałać, jeśli nie wykażesz się odpowiednią determinacją w jej realizacji. To znaczy, jeśli nie potraktujesz bezpieczeństwa jako proces. W końcu wszystko zacznie rdzewieć i znowu ktoś „na chwilę” da komuś dostęp, albo na szybko zainstaluje projekt na pierwszym serwerze z brzegu i nie poświęci wystarczającej uwagi do zabezpieczeń.

Co dalej?

Chciałbym powiedzieć, że dzięki zmianom będziemy „premium”.

Ale to nie będzie prawda.

Dzięki zmianom będziemy tacy, jacy powinniśmy być od samego początku. Jestem pewien jednego – w naszym przypadku to był pierwszy raz od 10 lat i nie muszę Cię przekonywać, że jesteśmy cholernie zmotywowani, żeby był tym ostatnim. A wszystkim czytającym życzę, żeby nigdy nie musieli pisać takiego artykułu.