Jak odpowiadać na kwestionariusz bezpieczeństwa dostawcy (SIG Lite, CAIQ i formularze własne)

czym są te kwestionariusze

Kwestionariusz bezpieczeństwa dostawcy, często skracany do VSQ, to uporządkowany zestaw pytań, który klient wysyła, żeby ocenić bezpieczeństwo dostawcy przed podpisaniem albo odnowieniem umowy. Pytania dotyczą tego, jak chronisz dane, zarządzasz dostępem, reagujesz na incydenty i rozwijasz oprogramowanie. Osoba przeglądająca odpowiedzi decyduje na ich podstawie, czy spełniasz wymagany poziom, jakie ryzyka odnotować i co zapisać w umowie.

Są trzy formaty. SIG i SIG Lite: kwestionariusz Standardized Information Gathering prowadzi Shared Assessments, organizacja branżowa zajmująca się ryzykiem po stronie dostawców zewnętrznych. Pełny SIG jest obszerny i dogłębnie pokrywa wiele obszarów kontroli, a SIG Lite to krótsza wersja do lżejszej oceny albo pierwszego podejścia. CAIQ: Consensus Assessments Initiative Questionnaire pochodzi od Cloud Security Alliance, odwołuje się do CSA Cloud Controls Matrix i jest zbudowany pod dostawców chmury i SaaS, z odpowiedziami zwykle w formacie tak, nie albo nie dotyczy plus kolumna na uwagi. Wielu dostawców SaaS wypełnia go i publikuje w rejestrze CSA STAR. Kwestionariusze własne: wielu klientów wysyła swój arkusz, często złożony z wewnętrznej polityki, fragmentów SIG i CAIQ oraz wniosków z ostatniego incydentu. We wszystkich trzech powtarzają się te same pytania u podstaw. Kiedy raz dobrze odpowiesz na sekcję kontroli dostępu w SIG Lite, masz gotową większość tego, o co zapyta CAIQ albo formularz własny w temacie dostępu, i właśnie to nakładanie się sprawia, że warto zbudować bibliotekę odpowiedzi.

dlaczego go dostałeś

Dostałeś kwestionariusz, bo proces bezpieczeństwa albo zakupów u klienta wymaga go, zanim dopuszczą cię jako dostawcę. To zarządzanie ryzykiem stron trzecich: większe organizacje odpowiadają za bezpieczeństwo dostawców, którzy mają dostęp do ich danych, a kwestionariusz to sposób udokumentowania, że to sprawdziły. Zwykle uruchamia się, gdy masz zacząć przetwarzać ich dane, połączyć się z ich systemami albo wejść w istotny dla nich proces; gdy ich audytorzy w ramach SOC 2, ISO 27001, DORA albo NIS2 wymagają oceny dostawców; albo gdy transakcja przekroczyła próg wielkości lub wrażliwości. Nic z tego nie jest oceną ciebie. Oznacza, że transakcja jest na tyle realna, że włączył się ich dział ryzyka. Jasna, uczciwa i dobrze udokumentowana odpowiedź przyspiesza transakcję, odpowiedź mętna albo wymijająca ją spowalnia.

zasada: odpowiadaj na podstawie dowodów

Najbardziej przydatny nawyk to odpowiadanie na podstawie dowodów, nie z pamięci ani z szacunku. Przy każdej odpowiedzi powinieneś umieć wskazać to, co ją potwierdza: ustawienie konfiguracyjne, log, dokument polityki, eksport, zrzut ekranu. Jeśli nie masz na co wskazać, jeszcze nie znasz odpowiedzi. To ważne, bo osoba przeglądająca może poprosić o ten dowód, a odpowiedź, którą potrafisz poprzeć, przetrwa dopytywanie, w przeciwieństwie do odpowiedzi zmyślonej. Złapanie na jednej sfabrykowanej odpowiedzi sprawia, że cała reszta przestaje być wiarygodna.

To też właściwie ustawia sens odpowiedzi „nie wiemy". Kiedy nikt w zespole nie potrafi odpowiedzieć na podstawie dowodów, uczciwe odczytanie tego nie brzmi „jesteśmy niebezpieczni", tylko „obecnie tego nie widzimy". To dwa różne problemy: pierwszy wymaga kontroli, drugi widoczności, a widoczność zwykle da się zdobyć szybciej. Na pytanie w rodzaju „jaki procent kont ma wymuszone MFA" można odpowiedzieć w chwili, gdy widzisz rzeczywisty stan w swoim dostawcy tożsamości i aplikacjach. Wiele zespołów nigdy nie wyciągnęło takiego widoku, więc szacuje, a szacunek wychodzi błędny. Rozwiązaniem jest sprawdzić, nie lepiej zgadywać.

obszary pytań i jak podejść do każdego

Jeśli odrzucić różnice w formatowaniu, większość kwestionariuszy pokrywa tę samą garstkę obszarów. Kontrola dostępu i tożsamość to obszar o najwyższej częstotliwości pytań i pokrywany najgłębiej, z pytaniami o pokrycie MFA, szybkość offboardingu, least privilege, cykliczne przeglądy dostępów oraz sposób zarządzania kontami administracyjnymi i uprzywilejowanymi. Odpowiadaj na podstawie rzeczywistego stanu w swoim dostawcy tożsamości i połączonych aplikacjach, nie na podstawie polityki, bo polityka mówi, że MFA jest wymagane, a dowody pokazują, ile kont faktycznie je ma, łącznie z tymi poza SSO. Ochrona danych obejmuje szyfrowanie w spoczynku i w tranzycie, retencję i usuwanie oraz podprocesorów. Odpowiedzi o szyfrowaniu to zwykle konkretna konfiguracja, retencja wymaga spisanego harmonogramu zgodnego z tym, co systemy faktycznie robią, a podprocesorzy wymagają aktualnej, prawdziwej listy. Reagowanie na incydenty obejmuje to, czy masz spisany plan, jak wykrywasz incydenty i jakie masz terminy powiadomień. Uczciwe odpowiedzi są tu binarne i możliwe do zweryfikowania. Ciągłość działania i backupy obejmują częstotliwość backupów, ich lokalizację, testowane przywracanie i cele odtworzeniowe, a pytanie, na którym łapie się zespoły, brzmi, czy przywracanie faktycznie było testowane. Bezpieczny rozwój oprogramowania obejmuje code review, zarządzanie zależnościami i podatnościami oraz obsługę sekretów, na co odpowiadasz na podstawie swojego rzeczywistego pipeline'u, nie aspiracji do dobrych praktyk. Status zgodności obejmuje stan SOC 2 i ISO 27001 oraz zgodność z RODO, gdzie liczy się precyzja: raport SOC 2 Type II to coś innego niż „pracujemy nad SOC 2", co z kolei różni się od „stosujemy się do zasad SOC 2". Wzorzec we wszystkich sześciu obszarach jest ten sam: znajdź rzeczywisty stan, napisz odpowiedź, którą on potwierdza, i trzymaj dowód w miejscu, z którego możesz go przedstawić.

przykłady: dziesięć pytań i wzorcowe odpowiedzi

Chodzi tu o kształt dobrej odpowiedzi, nie o gotowe słowa do skopiowania. Dostosuj je do własnego rzeczywistego stanu.

Czy MFA jest wymuszone dla wszystkich użytkowników? „MFA jest wymuszone przez naszego dostawcę tożsamości dla wszystkich kont, które logują się przez SSO, co obejmuje większość pracowników i aplikacji. Określony zestaw aplikacji poza SSO śledzimy osobno i rozszerzamy na nie wymuszone MFA według spisanego harmonogramu. Aktualne pokrycie i pozostałą listę udostępniamy na żądanie." To odpowiedź oparta na rzeczywistym stanie, która nazywa lukę zamiast deklarować bezwarunkowe „tak", któremu przeczyłaby lista aplikacji.

Jak szybko usuwacie dostęp, gdy pracownik odchodzi? „Odejście pracownika uruchamia nasz proces offboardingu tego samego dnia roboczego. Dostęp do kluczowych systemów zarządzanych przez naszego dostawcę tożsamości jest odbierany w tym samym oknie czasowym. Dla aplikacji, które nie są jeszcze zintegrowane z katalogiem, odbieranie dostępu przebiega według checklisty i kończy się w ciągu [twoje deklarowane okno czasowe]. Kompletność offboardingu sprawdzamy w ramach naszych cyklicznych przeglądów dostępów." To rozróżnia ścieżkę zintegrowaną od ręcznej, w której dostęp zwykle się utrzymuje dłużej.

Czy stosujecie zasadę least privilege? „Dostęp przyznajemy na podstawie roli i ograniczamy stały dostęp administracyjny do określonego zestawu kont. Prowadzimy cykliczne przeglądy dostępów, w których właściciele zasobów potwierdzają albo cofają dostęp każdego konta. Nie mamy jeszcze ciągłego, zautomatyzowanego egzekwowania least privilege, więc naszą główną kontrolą jest cykl przeglądów. Zapisy z przeglądów udostępniamy na żądanie." To uczciwie opisuje kontrolę i wprost mówi, czym ona nie jest.

Jak często prowadzicie przeglądy dostępów? „Dostęp uprzywilejowany i wysokiego ryzyka przeglądamy co kwartał, a standardowy dostęp użytkowników co pół roku. Przeglądy prowadzą właściciele zasobów, decyzje są zapisywane, a cofnięcia dostępu wykonujemy w określonym oknie czasowym. Zapis z naszego ostatniego przeglądu możemy udostępnić pod NDA." To podaje częstotliwość, właściciela procesu i dowód.

Czy dane klientów są szyfrowane w spoczynku i w tranzycie? „Dane w tranzycie szyfrujemy przy użyciu TLS 1.2 lub wyższego we wszystkich połączeniach zewnętrznych. Dane w spoczynku szyfrujemy przy użyciu zarządzanego szyfrowania naszego dostawcy chmury, zgodnie ze standardem [standard stosowany przez twojego dostawcę]. Szczegóły konfiguracji szyfrowania i dokumentację naszego dostawcy udostępniamy na żądanie." Odpowiedzi o szyfrowaniu powinny być konkretne, te mętne czytane są jako niepewność.

Czy prowadzicie aktualną listę podprocesorów? „Tak. Prowadzimy listę podprocesorów obejmującą każdą stronę trzecią przetwarzającą dane klientów w naszym imieniu, cel przetwarzania i lokalizację przetwarzania. Aktualną listę udostępniamy na żądanie, a o istotnych zmianach informujemy klientów zgodnie z zapisami naszej umowy powierzenia (DPA)." Jeśli nie masz takiej listy, uczciwa odpowiedź brzmi, że ją kompletujesz, z podaną datą.

Czy macie spisany plan reagowania na incydenty? „Tak. Mamy spisany plan reagowania na incydenty obejmujący wykrywanie, klasyfikację, ograniczanie skutków, powiadamianie klientów i przegląd po incydencie. Plan definiuje role i ścieżki eskalacji. Możemy omówić plan na rozmowie i udostępnić jego wersję z wyczarnionymi fragmentami pod NDA." Jeśli plan jeszcze nie istnieje, nie deklaruj, że istnieje.

Jaki jest wasz termin powiadomienia klientów po potwierdzonym incydencie? „Przy incydencie dotyczącym danych klientów powiadamiamy dotkniętych klientów bez zbędnej zwłoki i w ciągu [twoje deklarowane okno czasowe] od potwierdzenia. Konkretne zobowiązanie zapisane jest w naszych warunkach umownych. Nasz plan reagowania na incydenty definiuje kroki prowadzące do powiadomienia." Podaj okno czasowe, które realnie dotrzymasz pod presją.

Jak zarządzacie sekretami i danymi uwierzytelniającymi w procesie developmentu? „Sekrety przechowujemy w dedykowanym secrets managerze i nie trafiają one do repozytorium kodu. Dostęp do sekretów jest ograniczony rolą, a repozytoria skanujemy pod kątem przypadkowo scommitowanych danych uwierzytelniających. Rotacja przebiega według określonego procesu dla [przypadków, które faktycznie rotujesz]. Konfigurację możemy omówić na żądanie." To wynika z pipeline'u, nie z aspiracji zapisanej w polityce.

Jaki jest wasz aktualny status SOC 2 lub ISO 27001? „Obecnie nie mamy raportu SOC 2 Type II. Zrealizowaliśmy [twój faktyczny etap, na przykład ocenę gotowości] i celujemy w [typ raportu] do [data]. W międzyczasie możemy udostępnić nasze polityki bezpieczeństwa i odpowiadać bezpośrednio na konkretne pytania o kontrole." Precyzyjny status jest lepszy niż wykręt. Osoby przeglądające czytają „stosujemy się do zasad SOC 2" jako „nie mamy raportu".

jak postąpić z pytaniem, na które nie możesz odpowiedzieć twierdząco

Trafisz na pytania, przy których uczciwa odpowiedź dziś brzmi nie, albo jeszcze nie. Złym ruchem jest napisać tak i liczyć, że nikt nie sprawdzi. Dobry ruch to opisanie aktualnego stanu, planu i harmonogramu. Mocna odpowiedź o luce ma trzy części: co jest prawdą teraz, co z tym robisz i kiedy będzie gotowe. Na przykład: „Obecnie nie wymuszamy MFA na zestawie aplikacji poza SSO. Zinwentaryzowaliśmy te aplikacje i wprowadzamy na nich wymuszone MFA według harmonogramu, który kończy się do [data]". Kupujący akceptują uczciwe luki z planem naprawy znacznie częściej, niż się wydaje, bo osoby przeglądające widzą na co dzień prawdziwe środowiska i wiedzą, że żaden dostawca z segmentu mid-market nie ma idealnych wszystkich kontroli. Sprawdzają, czy znasz swój własny stan i czy nim zarządzasz. Pewne siebie „tak", które później okazuje się nieprawdą, sygnalizuje coś przeciwnego, a gdy jedna odpowiedź zostanie zdemaskowana jako nieprawdziwa, cała reszta jest czytana z podejrzliwością. Jest też powód kontraktowy, żeby być precyzyjnym: odpowiedzi z kwestionariusza mogą trafić jako odniesienie do umowy, a odpowiedź, która zawyża twoje kontrole, staje się oświadczeniem, za którym możesz nie być w stanie później stanąć.

budowanie biblioteki odpowiedzi wielokrotnego użytku

Pierwszy kwestionariusz idzie wolno, bo dopiero odkrywasz własne odpowiedzi w trakcie ich pisania. Praca wykonana raz nie powinna być powtarzana. Biblioteka odpowiedzi to uporządkowany zbiór standardowych pytań i zatwierdzonych odpowiedzi, z których każda jest powiązana z dowodem, który ją potwierdza. Gdy przychodzi nowy kwestionariusz, większość z niego pokrywa się z odpowiedziami, które już masz, więc je wykorzystujesz ponownie, piszesz tylko naprawdę nowe pytania, a odpowiedź, która wcześniej zajmowała tygodnie, teraz zajmuje godziny. Kilka rzeczy sprawia, że biblioteka działa: jeden właściciel i jedno źródło, żeby kanoniczne odpowiedzi nie rozjeżdżały się i sobie nie przeczyły; dowód powiązany z każdą odpowiedzią, żebyś mógł go przedstawić bez gorączkowego szukania; data aktualności przy każdej odpowiedzi, sprawdzana cyklicznie, bo odpowiedź o MFA prawdziwa dwa kwartały temu może już nie być aktualna; oraz mapa między formatami, czyli organizowanie odpowiedzi według obszaru, a nie układu jednego konkretnego kwestionariusza, tak żeby ta sama odpowiedź o kontroli dostępu obsłużyła SIG Lite, CAIQ i formularz własny. Biblioteka to też miejsce, w którym odpowiadanie na podstawie dowodów najbardziej się opłaca, bo jej odświeżanie sprowadza się do ponownego sprawdzenia dowodów, a zalogowane luki stają się bieżącym planem, który w kolejnych cyklach przesuwa odpowiedzi z „jeszcze nie, oto plan" do „tak, oto dowód".

dlaczego odpowiedzi o dostępie i tożsamości są najtrudniejsze

Ze wszystkich obszarów to dostęp i tożsamość firmy pokrywają najsłabszymi odpowiedziami, i rzadko dlatego, że mniej im na tym zależy. Powód jest taki, że nie widzą rzeczywistego stanu dostępu w swoich systemach, więc odpowiadają na podstawie polityki i nadziei. Szyfrowanie to konfiguracja, więc da się je zweryfikować. Backup albo się wykonał, albo nie. Ale dostęp jest rozproszony między dostawcę tożsamości, dziesiątki aplikacji SaaS, z których każda ma własną listę użytkowników i model ról, konsole chmurowe, konta serwisowe niebędące niczyją własnością i integracje przyznane przy wdrożeniu, których nikt nigdy nie przejrzał. Prawdziwa odpowiedź na pytanie „jaki procent kont ma wymuszone MFA" albo „ilu byłych pracowników wciąż ma gdzieś dostęp" wymaga wyciągnięcia i zestawienia stanu ze wszystkich tych miejsc, a większość zespołów nigdy tego nie zrobiła, więc odpowiada na podstawie polityki, a polityka i rzeczywistość dawno się rozjechały. Dlatego właśnie przy pytaniach o dostęp blefowanie jest najbardziej kuszące i najbardziej niebezpieczne: „MFA jest wymuszone dla wszystkich użytkowników" łatwo się pisze i często jest to nieprawda, bo konta poza SSO to dokładnie te, o których autor zapomniał. Uczciwa droga jest tu taka sama jak wszędzie indziej, tylko trudniejsza do przejścia: zobacz rzeczywisty stan, zanim odpowiesz.