Przegląd bezpieczeństwa w wielu firmach zaczyna się od tego samego rytuału: na stół trafia diagram architektury. Widać na nim centra danych, chmurę, zapory sieciowe, centrum operacji bezpieczeństwa i kopie zapasowe. Wszystko na swoim miejscu. A jednak z perspektywy integratora trzeba powiedzieć przewrotnie: najważniejsze rzeczy są na tych diagramach niewidoczne.

To, co klienci pokazują, jest oczywiście potrzebne. Problem w tym, że o przetrwaniu kryzysu technologicznego lub geopolitycznego decydują elementy ukryte pod spodem, których żaden diagram nie przedstawia.

Pierwszym jest realna kontrola nad środowiskiem. Formalnie każda firma jakąś kontrolę deklaruje. Realna kontrola oznacza, że organizacja rzeczywiście panuje nad tym, co działa w jej środowisku, kto ma do niego dostęp i co się w nim zmienia. Między deklaracją a rzeczywistością bywa przepaść, której na schemacie nie widać.

Drugim jest wiedza o zależnościach systemów. Diagram pokazuje elementy, ale rzadko pokazuje, co od czego naprawdę zależy: który proces stanie, gdy padnie konkretna usługa, i które zależności ciągną się do zewnętrznych dostawców. W kryzysie to właśnie nieznane zależności najbardziej wydłużają przestój, bo każdą odkrywa się dopiero wtedy, gdy przestaje działać.

Trzecim jest zdolność do działania w trybie degradacji. Chodzi o umiejętność prowadzenia najważniejszych procesów wtedy, gdy część środowiska nie działa: wolniej, ręcznie, w okrojonym zakresie, ale bez zatrzymania firmy. Tej zdolności nie da się narysować. Można ją tylko zbudować i przećwiczyć.

Czwartym, szczególnym elementem są kompetencje decyzyjne, czyli zdolność podejmowania decyzji w trybie zagrożenia na podstawie przesłanek określonych wcześniej w procedurach. Kryzys nie czeka na zwołanie komitetu. Organizacja, która nie ustaliła zawczasu, kto decyduje i na jakiej podstawie, traci w kryzysie najcenniejszy zasób, czyli czas. Bez tej zdolności cyberodporność jest tylko zbiorem narzędzi i papierowych procedur.

Te cztery elementy łączy jedno. Nie kupuje się ich razem ze sprzętem i nie widać ich podczas prezentacji architektury. Widać je dopiero w działaniu, najczęściej wtedy, gdy dzieje się coś poważnego. Dlatego ocena odporności wyłącznie na podstawie diagramu zawsze będzie oceną niepełną.

Jest jeszcze jeden powód, dla którego te elementy umykają uwadze. Wszystkie cztery są zdolnościami organizacji, a nie produktami. Nie mają wersji, ceny ani daty wdrożenia, więc nie trafiają do budżetów i harmonogramów. A to, co nie ma pozycji w arkuszu, łatwo uznać za załatwione.

Dla zarządu i osób odpowiedzialnych za IT płynie z tego prosty postulat. Obok przeglądu tego, co widać, warto regularnie robić przegląd tego, czego nie widać: kontroli, zależności, trybu degradacji i gotowości decyzyjnej. Każdemu z tych obszarów poświęcamy osobne materiały tej serii, bo każdy zasługuje na własną rozmowę.

Diagram architektury pozostanie ważnym narzędziem i nikt nie namawia do jego porzucenia. Warto tylko pamiętać, co przedstawia: zasoby, nie zdolności. A kryzys egzaminuje właśnie zdolności.