Jak przygotować postawę bezpieczeństwa na due diligence inwestora

dlaczego bezpieczeństwo pojawia się w due diligence i ile kosztuje bałagan

Inwestorzy na etapie Series A i B kupują przyszłe zwroty, a luki w bezpieczeństwie to kategoria ryzyka, która może nadgryzać te zwroty już po wpłynięciu pieniędzy. Naruszenie dotyczące danych klientów może wywołać odpływ klientów, ekspozycję regulacyjną wynikającą z RODO i cios w reputację, który spada na cap table. Dlatego doradca prowadzący due diligence techniczne zadaje jedno skupione pytanie. Czy ta firma zarządza dostępem i danymi na tyle dobrze, że ryzyko jest akceptowalne, czy są luki na tyle duże, że zmieniają warunki.

Koszt bałaganu rzadko objawia się jako „nie". Objawia się na trzy cichsze sposoby. Pierwszy to harmonogram: czysty data room pozwala doradcy zweryfikować i przejść dalej, podczas gdy niekompletny generuje kolejne prośby o informacje, z których każda dodaje dni. Drugi to pozycja negocjacyjna: ustalenia odkryte podczas due diligence stają się powodem, żeby wrócić do warunków, dołożyć warunki do zamknięcia albo wstrzymać część transzy do czasu naprawy. Trzeci to zaufanie: founder, który potrafi przedstawić aktualny, dokładny obraz dostępu i powiedzieć wprost „to jest solidne, to naprawiamy, to jest data", czytany jest jako ktoś, kto dobrze prowadzi firmę. Founder zaskoczony własnymi ustaleniami czytany jest jako ktoś, kto nie panuje nad środowiskiem. Nic z tego nie wymaga ciężkiego programu bezpieczeństwa. Wymaga, żebyś potrafił odpowiadać na podstawowe pytania dowodami, nie zapewnieniami.

co sprawdzają inwestorzy i ich doradcy

Due diligence techniczne dla wczesnej firmy B2B SaaS jest zwykle proporcjonalne. Doradca nie audytuje cię pod kątem standardu certyfikacyjnego, sprawdza, czy podstawy są na miejscu i czy nic w twojej historii albo środowisku nie grozi tym, że stanie się problemem.

kontrola dostępu i tożsamość

Tu żyje większość tarcia na wczesnym etapie, i to obszar, który ten przewodnik waży najmocniej. Doradca chce zrozumieć, kto ma dostęp do czego. Konkretnie: kto ma dostęp do systemów produkcyjnych, kodu i danych klientów, i czy ta lista odpowiada osobom, które powinny go mieć; czy uwierzytelnianie wieloskładnikowe jest wymuszone na kontach, które mają znaczenie, a nie tylko dostępne; co dzieje się, gdy ktoś odchodzi, i jak szybko offboarding faktycznie odbiera dostęp; jak obsługiwane są konta administracyjne i czy są przypisane indywidualnie, czy współdzielone; oraz czy dostęp podąża za least privilege, czy ludzie i integracje trzymają szerokie uprawnienia nagromadzone z czasem. Te pytania są konkretne i weryfikowalne. Dlatego doradcy zaczynają właśnie tutaj.

ochrona danych i prywatność

Dla europejskiej firmy SaaS przetwarzającej dane klientów, postawa wobec RODO jest częścią due diligence. Doradca zwykle chce zobaczyć aktualny rejestr czynności przetwarzania, listę podprocesorów z umowami powierzenia, jasne oświadczenie o rezydencji danych oraz obraz retencji i usuwania pokazujący, że dane są przechowywane tylko tak długo, jak potrzeba, i że wnioski o usunięcie mogą zostać spełnione.

własność IP i kodu

Inwestorzy kupują produkt, a produktem jest kod. Chcą pewności, że firma faktycznie go posiada: umowy z kontrybutorami i przeniesienia praw obejmujące każdego pracownika i kontraktora, który pisał kod, dostęp do repozytorium łącznie z byłymi kontrybutorami, którzy mogą wciąż go mieć, oraz czy sekrety takie jak dane uwierzytelniające, klucze API czy tokeny są zacommitowane w historii repozytorium.

historia incydentów

Doradca zapyta, czy mieliście incydent bezpieczeństwa albo naruszenie, a jeśli tak, jak go obsłużyliście. Incydent w przeszłości nie dyskwalifikuje, liczy się to, jak zareagowaliście. Udokumentowana reakcja, jasna naprawa i dowód, że luka została zamknięta, dobrze świadczą o firmie. Nieujawniony incydent, który wypływa później, to poważny problem, bo dotyka zaufania.

postawa compliance

Dla większości firm na etapie Series A raport SOC 2 albo certyfikat ISO 27001 nie jest jeszcze oczekiwany. Oczekiwana jest wiarygodna odpowiedź o tym, gdzie stoicie i dokąd zmierzacie. Jeśli macie SOC 2 Type II, to skraca rozmowę. Jeśli nie, jasny plan z harmonogramem jest rozsądną odpowiedzią.

podstawy bezpieczeństwa produktu

Doradca sprawdza, czy produkt odzwierciedla solidne praktyki: szyfrowanie danych w tranzycie i w spoczynku, rozsądne podejście do zarządzania podatnościami, higienę zależności i proces developmentu obejmujący przegląd bezpieczeństwa. Na etapie Series A poprzeczką jest kompetencja, nie dojrzałość.

sekcja bezpieczeństwa w data roomie

Sekcja bezpieczeństwa istnieje po to, żeby doradca mógł szybko zweryfikować twoją postawę. Zorganizuj ją tak, żeby mógł znaleźć dowody bez pytania cię o nie. Celem jest, żeby ktoś, kto nigdy z tobą nie rozmawiał, mógł przeczytać folder i wyjść z dokładnym obrazem. Użyteczna struktura:

Przegląd. Jednostronicowe podsumowanie bezpieczeństwa dla inwestora (opisane niżej), na górze, żeby doradca przeczytał streszczenie przed szczegółami. Krótki diagram architektury pokazujący, gdzie żyją i płyną dane klientów.

Dostęp i tożsamość. Aktualna lista tego, kto ma dostęp do produkcji, kodu i danych klientów, z rolą i uzasadnieniem. Dowód, że MFA jest wymuszone w systemach, które mają znaczenie, na przykład eksport konfiguracji dostawcy tożsamości albo podsumowanie pokrycia. Twój proces offboardingu, spisany, z dowodem, że jest przestrzegany; niedawny przykład odejścia z odebranym i opatrzonym datą dostępem jest mocniejszy niż sam dokument polityki. Inwentarz kont administracyjnych i serwisowych, z nazwanym właścicielem dla każdego.

Ochrona danych. Rejestr czynności przetwarzania, lista podprocesorów z umowami powierzenia, podsumowanie retencji i usuwania danych oraz oświadczenie o rezydencji danych.

Polityki i proces. Polityka bezpieczeństwa informacji, polityka kontroli dostępu i plan reagowania na incydenty. Mogą być krótkie; dwustronicowa polityka, która jest przestrzegana, bije dwudziestostronicową, której nikt nie czyta. Twój status compliance i plan, z harmonogramem, jeśli certyfikacja jest w toku.

Historia incydentów. Oświadczenie o wszelkich przeszłych incydentach i o tym, jak każdy z nich obsłużono, albo jasne oświadczenie, że ich nie było.

Bezpieczeństwo produktu. Podsumowanie szyfrowania, zarządzania podatnościami i praktyk bezpiecznego developmentu. Wyniki dowolnego niedawnego testu penetracyjnego, z notatką o tym, jak zaadresowano ustalenia.

Zasada przewijająca się przez to wszystko: dowód ponad zapewnienie. „Wymuszamy MFA" to twierdzenie. Eksport konfiguracji pokazujący, że jest wymuszone, to dowód. Doradcy weryfikują, a folder zbudowany pod weryfikację idzie szybciej.

jednostronicowe podsumowanie bezpieczeństwa dla inwestora

Ta jedna strona to najbardziej użyteczny artefakt, jaki możesz przygotować. To jednostronicowe podsumowanie wykonawcze twojej postawy bezpieczeństwa, napisane dla czytelnika bez specjalistycznej wiedzy, które pozwala partnerowi albo doradcy uchwycić twoją pozycję w dwie minuty. Co się na niej znajduje:

Postawa tożsamości i dostępu. Kilka linijek o tym, jak kontrolowany jest dostęp: wymuszenie MFA, jak dostęp jest przyznawany i odbierany, jak obsługiwane są konta administracyjne i czy prowadzicie okresowe przeglądy dostępów.

Ochrona danych. Gdzie żyją dane klientów, jak są chronione w tranzycie i w spoczynku, wasza postawa wobec RODO w skrócie oraz stanowisko wobec podprocesorów i rezydencji danych, po jednym zdaniu na każde.

Status compliance. Gdzie stoicie z SOC 2 albo ISO 27001, a jeśli certyfikacja jest w toku, docelowa data.

Krótka narracja „co robimy i kiedy". To część, którą pomija większość founderów, i część, która buduje najwięcej zaufania. Dwie albo trzy linijki nazywające luki, o których wiecie, i daty, kiedy je zamykacie. Doradca nie oczekuje, że firma na etapie Series A ma wszystko dopięte. Oczekuje, że znacie własne luki i macie plan. Nazwanie luki samodzielnie, z datą, jest dużo mocniejsze niż to, żeby znalazł ją za was doradca.

częste sygnały ostrzegawcze i jak je najpierw wyjaśnić

Pewne ustalenia wypływają niemal w każdym procesie due diligence dla firmy SaaS na wczesnym etapie. Każde z nich to coś, co możesz znaleźć i naprawić, zanim zrobi to doradca.

Dostęp osierocony po byłych pracownikach i kontraktorach. Konta, które wciąż działają dla osób, które odeszły. To najczęstsze pojedyncze ustalenie i najczystszy sygnał słabej dyscypliny dostępu. Żeby to wyjaśnić: pobierz aktualną listę każdego konta w dostawcy tożsamości, repozytoriach kodu, platformach chmurowych i kluczowych narzędziach SaaS, porównaj ją z aktualnym stanem zatrudnienia i usuń wszystko, co należy do osoby, która odeszła. Potem utrzymuj listę aktualną.

Brak procesu offboardingu. Odbieranie dostępu odbywa się ad hoc i różni się w zależności od tego, kto odchodzi. Naprawą jest spisana, powtarzalna checklista obejmująca każdy system, uruchamiana w momencie, gdy odejście staje się wiadome.

Współdzielone konta administracyjne. Jeden login administratora używany przez kilka osób albo konto root, którego hasło zna cały zespół. To łamie przypisywalność. Zastąp współdzielone konta indywidualnie przypisanymi, wymuś MFA na każdym i zarezerwuj dane uwierzytelniające break-glass dla prawdziwych sytuacji awaryjnych, z logowanym dostępem.

Częściowe MFA. MFA włączone dla niektórych kont albo systemów, ale niewymuszone wszędzie tam, gdzie ma znaczenie. Wymuś MFA na wszystkich kontach z dostępem do produkcji, kodu i danych klientów, i bądź w stanie pokazać to pokrycie, a nie tylko je zadeklarować.

Konta serwisowe, których nikt nie posiada. Tożsamości maszynowe (NHI) łączące systemy, uruchamiające automatyzację albo trzymające dostęp do API, założone przez kogoś, kto od tamtej pory odszedł, teraz niosące szerokie uprawnienia. Zinwentaryzuj je, przypisz właściciela do każdego, zawęź uprawnienia do tego, czego wymaga funkcja, i wyłącz te, których cel się zakończył.

Szeroki dostęp do repozytorium. Każdy w firmie, łącznie z osobami spoza inżynierii i byłymi kontrybutorami, ma dostęp do pełnego kodu. Ogranicz dostęp do repozytorium do tych, którzy go potrzebują, usuń byłych kontrybutorów i przeskanuj historię repozytorium pod kątem zacommitowanych sekretów. Każde dane uwierzytelniające znalezione w historii należy traktować jako ujawnione i zrotować, bo usunięcie pliku nie unieważnia klucza, który ktoś już skopiował.

uczciwa sekwencja: ustal, napraw, udokumentuj

Pod presją rundy pojawia się pokusa, żeby najpierw napisać data room, a zweryfikować później. Oprzyj się jej. Dokumentowanie postawy, której nie zweryfikowałeś, to jeden błąd, który potrafi zamienić punkt tarcia w problem zaufania. Jeśli doradca przetestuje twierdzenie i się nie utrzyma, każde inne twierdzenie staje się podejrzane. Zrób to w kolejności.

Najpierw ustal rzeczywisty stan. Zanim napiszesz choć słowo, zdobądź dokładny obraz tego, kto ma dostęp do czego. Pobierz rzeczywiste listy z dostawcy tożsamości, repozytoriów, platform chmurowych i kluczowych narzędzi SaaS. Porównaj z aktualnym stanem zatrudnienia. Przypisz konta administracyjne i serwisowe do nazwanych właścicieli. Pierwsze przejście jest zwykle niewygodne, bo niemal zawsze są konta i granty, o których nikt nie pamiętał. Ta niewygoda jest tu celem.

Napraw luki o dużym wpływie. Nie musisz zamknąć wszystkiego przed rundą. Musisz zamknąć to, co naprawdę ryzykowne, i to, co doradca oznaczy: dostęp osierocony, współdzielone konta admina, częściowe MFA i konta serwisowe bez właściciela z szerokimi uprawnieniami. Pracuj od największej ekspozycji w dół.

Potem udokumentuj. Gdy stan jest zweryfikowany, a luki o dużym wpływie naprawione, napisz sekcję data roomu i jednostronicowe podsumowanie tak, żeby odzwierciedlały to, co faktycznie prawdziwe. Teraz każde twierdzenie jest poparte dowodem, narracja „co robimy i kiedy" jest uczciwa, a te kilka pozostałych luk jest nazwanych z datami, nie ukrytych. Ta sekwencja kosztuje trochę czasu na starcie i oszczędza dużo więcej w trakcie rundy, bo eliminuje najgorszy scenariusz: bycie zaprzeczonym przez własne środowisko przed ludźmi, którzy decydują o twojej wycenie.