Sytuacja
Startup technologiczny z Wilna na Litwie, zatrudniający około 20 osób, tworzy produkt SaaS dla firm z sektora finansowego i ubezpieczeniowego. Zespół jest mocny w inżynierii, produkt działa w chmurze, a klienci to średnie i duże firmy na Litwie i w Skandynawii. Cykl sprzedaży jest długi, a każdy poważny klient przed podpisaniem umowy przesyła ankietę bezpieczeństwa: kilkadziesiąt lub kilkaset pytań o polityki, zarządzanie dostępem, zarządzanie incydentami, dostawców i ciągłość działania.
Punktem zwrotnym była przegrana w przetargu u skandynawskiego ubezpieczyciela. Produkt spodobał się kupującemu, ale prawie w każdym wierszu ankiety bezpieczeństwa odpowiedź brzmiała „nie mamy dokumentu, ale to robimy”, a konkurent miał certyfikat ISO 27001. Odpowiedź kupującego była uprzejma i jasna: wróćcie, gdy będziecie go mieli.
W firmie nie było nikogo odpowiedzialnego za bezpieczeństwo, a zatrudnianie takiej osoby tylko ze względu na ankietę nie miało sensu. Dyrektor techniczny (CTO) znał się na bezpieczeństwie, ale pisanie polityk, prowadzenie rejestru ryzyk i posługiwanie się językiem audytów nie należało do jego zadań, a ktoś musiał budować produkt. Potrzebny był ktoś, kto poprowadzi bezpieczeństwo jako funkcję, a nie jako projekt, i komu nie trzeba będzie płacić jak pracownikowi na pełnym etacie.
Czego potrzebowano
- System zarządzania bezpieczeństwem informacji zgodny z wymaganiami ISO 27001, dopasowany do firmy 20-osobowej, a nie do korporacji.
- Dokumenty, które można pokazać klientom: polityki, rejestr ryzyk, plan reagowania na incydenty, oceny dostawców.
- Możliwość wypełniania ankiet bezpieczeństwa klientów w kilka dni, a nie tygodni.
- Gotowość do audytu certyfikacyjnego w ciągu roku, aby przy kolejnym przetargu odpowiedź brzmiała przynajmniej „termin audytu wyznaczony”.
- Minimum czasu inżynierów, bo rozwój produktu nie może stanąć.
Co zrobiliśmy
Miesiąc 1: ocena i rejestr ryzyk
Zaczęliśmy od audytu bezpieczeństwa IT względem listy zabezpieczeń ISO 27001: co firma już robi w praktyce, co robi, ale nie ma udokumentowane, a czego brakuje w ogóle. Okazało się, że zabezpieczenia techniczne były lepsze, niż się spodziewaliśmy: przeglądy kodu, MFA, szyfrowanie, logi. Brakowało warstwy zarządczej: kto za co odpowiada, jak ocenia się ryzyka, jak obsługuje się incydenty i jak sprawdza się dostawców.
Razem z kierownictwem zbudowaliśmy rejestr ryzyk: około trzydziestu ryzyk z właścicielami, ocenami i uzgodnionymi działaniami. Rejestr stał się podstawą wszystkiego, co przyszło potem, bo audytor ISO 27001 w pierwszej kolejności pyta nie o polityki, lecz o to, skąd się wzięły.
Miesiące 2–3: polityki i procesy
Napisaliśmy czternaście polityk i procedur: politykę bezpieczeństwa informacji, zarządzanie dostępem, kryptografię, bezpieczne tworzenie oprogramowania, zarządzanie incydentami, ciągłość działania, zarządzanie dostawcami, zasady akceptowalnego użytkowania i inne. Każdy dokument ma kilka stron, osobę odpowiedzialną i datę przeglądu. Zasada była prosta: dokument opisuje tylko to, co firma faktycznie robi albo do czego zobowiązuje się od przyszłego tygodnia. Polityka, której nikt nie przestrzega, jest dla audytu gorsza niż jej brak.
Najtrudniejsza była ocena dostawców. Startup korzystał z kilkudziesięciu usług w chmurze, a część z nich opłacono kartą, bez żadnej umowy. Spisaliśmy je, uporządkowaliśmy według wrażliwości danych, zebraliśmy dowody bezpieczeństwa od dostawców usług krytycznych, a dwie usługi zastąpiliśmy takimi, które miały się czym wykazać.
Miesiąc 4: plan reagowania na incydenty i ćwiczenia
Plan zarządzania incydentami sprawdziliśmy podczas ćwiczenia symulacyjnego z udziałem całego zespołu: scenariusz zakładał wyciek kluczy dostępu w publicznym repozytorium kodu. Ćwiczenie pokazało, że nikt nie wiedział, kto informuje klientów i w jakim terminie. Rozszerzyliśmy plan i z wyprzedzeniem przygotowaliśmy szablony powiadomień dla klientów.
Miesiąc 5: biblioteka odpowiedzi i audyt wewnętrzny
Na podstawie polityk i rejestru ryzyk zbudowaliśmy bibliotekę odpowiedzi na najczęstsze pytania z ankiet klientów, z odnośnikami do dokumentów i dowodów. Przeprowadziliśmy audyt wewnętrzny względem wymagań ISO 27001 i zapisaliśmy niezgodności oraz plan ich usunięcia. Od tego momentu usługa vCISO jest kontynuowana jako stała: miesięczne spotkanie z zarządem, przegląd rejestru ryzyk, wypełnianie nowych ankiet i przygotowanie do audytu certyfikacyjnego.
Rezultat
Ankiety bezpieczeństwa klientów są teraz wypełniane w 3 dni robocze, wraz z przeglądem CTO. Wcześniej trwało to tygodnie i kończyło się pustymi wierszami. W ostatnich dwóch miesiącach wypełniono trzy ankiety, w tym jedną od klienta z tej samej branży, w której przegrano przetarg.
Firma ma 14 zatwierdzonych polityk i procedur, wszystkie z właścicielami i datami przeglądu, dostępne dla pracowników w jednym miejscu. Niezgodności z audytu wewnętrznego zostały zamknięte, gotowość do audytu certyfikacyjnego jest osiągnięta, a termin uzgodniony.
Liczba etatów ds. bezpieczeństwa w firmie wynosi 0. Funkcję bezpieczeństwa pełni vCISO w uzgodnionym wymiarze godzin miesięcznie, a inżynierowie wrócili do produktu. CTO wylicza, że przez pięć miesięcy poświęcił na bezpieczeństwo mniej czasu, niż wcześniej tracił na jedną przegraną ankietę.
Myśleliśmy, że ISO 27001 to sterta papierów dla dużych firm. Okazało się, że to po prostu lista pytań, na które i tak musieliśmy odpowiedzieć.
Co doradzilibyśmy w podobnej sytuacji
- Nie zaczynaj od szablonów polityk. Zacznij od rejestru ryzyk: polityki wynikają z niego w naturalny sposób, a audytor widzi to powiązanie.
- Opisuj tylko to, co faktycznie robisz. Audytor znajdzie dokument, którego nikt nie przestrzega, w pierwszej godzinie.
- Uporządkuj dostawców na wczesnym etapie: usługi w chmurze opłacane kartą to najczęstsza niezgodność w małych firmach technologicznych.
- Oddziel funkcję bezpieczeństwa od szefa inżynierii, nawet jeśli zna się na tym temacie. Jego czas kosztuje Cię produkt.
