Twój SOC 2 to nie Twoje bezpieczeństwo

Każdy założyciel fintech w końcu ma tę samą rozmowę ze swoim pierwszym klientem enterprise. Klient prosi o SOC 2. Założyciel go zleca. Sześć miesięcy i czterdzieści tysięcy dolarów później audyt zamyka się czysto i deal zamyka się razem z nim.

Potem mija rok, produkt rośnie i pewnego spokojnego wtorku zespół bezpieczeństwa znajduje coś, czego tam nie powinno być. Audyt był czysty. System nie był.

To nie jest oskarżenie SOC 2. To uczciwy opis tego, czym SOC 2 jest i czym nie jest — i gdzie żyje luka między nimi.

Co SOC 2 faktycznie poświadcza

Audyt SOC 2 Type II potwierdza, że masz kontrole na miejscu i że te kontrole działały zgodnie z projektem przez okno — zazwyczaj trzy, sześć lub dwanaście miesięcy. To jest audyt procesu. Audytor sprawdza, że robisz to, co mówią Twoje polityki.

Polityki piszesz Ty. Zakres definiujesz Ty. Audytor sprawdza, że przestrzegałeś własnych zasad.

To jest naprawdę wartościowe. Oznacza, że kupujący może zapytać „czy logujesz dostęp?" i ufać odpowiedzi. Oznacza, że regulator może zobaczyć, że traktujesz kontrole poważnie. Oznacza, że sąd, jeśli do tego dojdzie, może zobaczyć, że wykazałeś rozsądną staranność.

Co nie oznacza — że kontrole, które napisałeś, są wystarczające; że model zagrożeń, który sobie wyobraziłeś, odpowiada temu, z którym faktycznie się mierzysz; lub że implementacja tych kontroli jest wolna od błędów.

Problem dwóch systemów

Systemy fintech zazwyczaj mają dwie postawy bezpieczeństwa działające równolegle.

Pierwsza to zadeklarowana postawa — co mówią Twoje polityki, co opisują Twoje runbooki, co widzi audytor. To jest to, co SOC 2 poświadcza.

Druga to żywa postawa — co faktycznie dzieje się w produkcji o 3:00 w nocy, gdy inżynier on-call reaguje na incydent. Jak wygląda środowisko staging po sześciu miesiącach „posprzątamy to później." Co faktycznie robi SDK strony trzeciej obsługujące tokenizację Twojej karty.

Większość naruszeń nie dzieje się, bo zadeklarowana postawa była zła. Dzieje się, bo żywa postawa odchyliła się od niej i nikt tego nie zauważył.

Co faktycznie zrobić

Trzy nawyki zamykają tę lukę.

Traktuj audyt jako podłogę, nie sufit. Audytor sprawdza, że logujesz dostęp. Dobrze. Następnie zapytaj: czy logujemy właściwe rzeczy? Czy przeglądamy logi? Czy działania zdeterminowanego insajdera wyróżniałyby się, czy byłyby niewidoczne w szumie? SOC 2 nie zada tego pytania. Ty powinieneś.

Przeprowadzaj ćwiczenia bezpieczeństwa na żywym systemie. Tabletop prawdziwego incydentu co kwartał. Ćwiczenie red-team rocznie. Każ komuś spoza zespołu spróbować wyeksfiltrować dane testowe używając tylko publicznych informacji. Ćwiczenia, które znajdują najwięcej, to zazwyczaj te celujące w lukę między runbookiem a rzeczywistością.

Zwracaj szczególną uwagę na nudny dryf. Nowy SDK dodany bez przeglądu bezpieczeństwa. Baza staging zasiania snapshotem produkcji. Uprawnienia vendora rozszerzone „tymczasowo" i nigdy nieodwężone. Ten dryf jest tym, czego audyty nie widzą — i czego naruszenia bezpieczeństwa dokonują.

Uczciwy pitch

Czysty SOC 2 jest konieczny. Nie jest wystarczający. Agencje i konsultanci traktujący go jako linię mety — a jest ich wielu — sprzedają Ci audyt, nie bezpieczeństwo.

Gdy dostarczamy systemy fintech, dostarczamy do żywej postawy, nie do zadeklarowanej. Audyt zazwyczaj zamyka się czysto jako efekt uboczny. W takiej kolejności ta praca musi się odbywać.