ENISA: Secure by Design and Default Playbook

Podejście ENISA opiera się na systematycznym uwzględnianiu bezpieczeństwa już na wczesnych etapach rozwoju, zgodnie z zasadą określaną w terminologii technicznej jako „Shift Left”. Wymagania dotyczące bezpieczeństwa nie są zatem uwzględniane dopiero na etapie testowania lub eksploatacji, lecz już podczas definiowania wymagań, projektowania architektury i wyboru technologii.

To podejście zorientowane na cykl życia obejmuje etapy Requirements, Design, Implementation, Verification, Deployment, Maintenance i Disposal, które w wersji 1.0 zostały również doprecyzowane pod względem merytorycznym.

ENISA wyjaśnia ponadto, że procesy te należy rozumieć jako grupy działań, a nie jako obowiązkowy model sekwencyjny. Mogą się one nakładać, przebiegać iteracyjnie i być powtarzane w całym cyklu życia produktu. Na przykład w środowiskach zwinnych wymagania bezpieczeństwa mogą być rejestrowane i stopniowo dopracowywane za pomocą elementów backlogu, historyjek użytkownika, kryteriów akceptacji oraz Definition of Done.

Dzięki temu terminologia jest lepiej dostosowana do typowych procesów rozwoju oraz do takich dokumentów odniesienia jak IEC 62443 i IEC 61508.

Wersja końcowa po raz pierwszy wyraźnie definiuje również „Intended Outcomes”, których nie było jeszcze w pełnym zakresie w projekcie poddanym konsultacjom:

• mniej powtarzających się podatności;
• bezpieczne konfiguracje domyślne;
• wcześniejsze wykrywanie ryzyka;
• lepsza kontrola łańcucha dostaw oprogramowania;
• szybsze zarządzanie podatnościami;
• większa cyberodporność w całym cyklu życia produktu.

Playbook porządkuje wymagania w ramach 22 zasad, podzielonych na kategorie Secure by Design i Secure by Default. Zasady te są powiązane z konkretnymi środkami technicznymi, wymaganiami dotyczącymi dowodów oraz kryteriami zatwierdzania.

Do najważniejszych elementów technicznych należą ustrukturyzowane modelowanie zagrożeń, bezpieczne architektury oprogramowania oparte na uznanych zasadach, takich jak Least Privilege i Defense in Depth, bezpieczne konfiguracje domyślne oraz ciągłe zarządzanie podatnościami. Uzupełniają je wymagania dotyczące monitorowania, reagowania na incydenty (Incident Response) i zdolności do odtworzenia sprawności. Odporność jest tym samym traktowana jako integralny element eksploatacji.

Innowacyjnym elementem jest koncepcja początkowo określana jako „Machine-Readable Security Manifest”, która w wersji 1.0 została rozszerzona i zmieniona na „Machine-processable Attestation”. Jej celem jest umożliwienie ustrukturyzowanego i maszynowo przetwarzalnego dokumentowania środków bezpieczeństwa oraz odpowiednich dowodów. Dzięki temu również weryfikacja zgodności może być w większym stopniu automatyzowana i skalowana.

Oprócz środków technicznych ENISA podkreśla także znaczenie aspektów organizacyjnych, takich jak jasny podział odpowiedzialności, uwzględnianie bezpieczeństwa przy podejmowaniu decyzji dotyczących produktu oraz zabezpieczenie łańcucha dostaw. Bezpieczeństwo staje się zatem zadaniem interdyscyplinarnym, obejmującym rozwój, eksploatację i zarządzanie.

Ogólnie rzecz biorąc, Playbook oznacza zmianę paradygmatu: cyberbezpieczeństwo przestaje być dodatkową funkcją wdrażaną na późniejszym etapie, a staje się integralnym i weryfikowalnym elementem całego cyklu życia produktu. Dla producentów oznacza to nie tylko bardziej rygorystyczne wymagania regulacyjne, lecz również konieczność odpowiedniego dostosowania procesów rozwoju.

Główne przesłanie jest jasne: cyberbezpieczeństwo jest procesem ciągłym, a nie jednorazową funkcją produktu.
 

Playbook definiuje 22 konkretne zasady, podzielone na Secure by Design (14 zasad) i Secure by Default (osiem zasad).

Każda z 22 zasad została szczegółowo opisana w rozdziale 4 dokumentu ENISA, zatytułowanym Playbook, z uwzględnieniem takich kryteriów jak cel, techniczne elementy wdrożenia, wymagane dowody oraz kryteria zatwierdzania.

Celem jest przełożenie zasad bezpieczeństwa z poziomu koncepcyjnego na konkretne praktyki inżynieryjne i operacyjne. Dla każdej zasady opisano działania wdrożeniowe oraz weryfikowalne kryteria, dzięki czemu bezpieczeństwo staje się mierzalnym i podlegającym audytowi elementem procesu rozwoju.

Wszystkie 22 zasady mają jednolitą strukturę:

• Zasada: koncepcja bezpieczeństwa, która ma zostać wdrożona, np. hardening, kontrola dostępu lub możliwość aktualizacji.
• Cel: rezultat, który ma zostać osiągnięty, oraz rodzaje błędów lub ryzyka, które mają zostać ograniczone.
• Lista kontrolna: działania o największym znaczeniu, zaprojektowane tak, aby mogły być wdrażane również przez małe zespoły lub zespoły dysponujące ograniczonymi zasobami.
• Minimalne dowody: konkretne elementy, takie jak konfiguracje, logi, wyniki testów lub SBOM, potwierdzające wdrożenie środków.
• Kryteria zatwierdzania: sformalizowane kryteria typu pass/fail, które mogą być sprawdzane automatycznie w procesach wydawania wersji w celu zapewnienia wymaganego poziomu bezpieczeństwa.

W projektowaniu architektury i sieci OT kluczową rolę odgrywa konsekwentna segmentacja systemów przemysłowych. Podstawę stanowi model stref i kanałów komunikacyjnych (zones and conduits) oparty na serii norm IEC 62443, który dzieli instalację na wyraźnie wyodrębnione strefy bezpieczeństwa i umożliwia kontrolowanie komunikacji między nimi.

Konieczne jest również wyraźne oddzielenie sieci IT i OT, aby utrudnić atakującym przemieszczanie się pomiędzy sieciami oraz ograniczyć skutki incydentów bezpieczeństwa.

Fizyczne oddzielenie określane jako „air gap” nie powinno być jednak samo w sobie traktowane jako gwarancja bezpieczeństwa. Rzeczywiście niezbędne połączenia – na przykład do celów konserwacji, monitorowania lub integracji danych – powinny zostać jednoznacznie zidentyfikowane i zabezpieczone za pomocą kontrolowanych punktów przejścia. Możliwe środki obejmują zapory sieciowe, bramy protokołów i monitorowane interfejsy.

Szczególną uwagę należy poświęcić zabezpieczeniu dostępu zdalnego, który w środowiskach przemysłowych jest często niezbędny. Dostęp taki powinien odbywać się wyłącznie za pośrednictwem odpowiednio zabezpieczonych mechanizmów, np. połączeń VPN w połączeniu z uwierzytelnianiem wieloskładnikowym oraz dedykowanymi jump hostami, aby uniknąć bezpośredniego dostępu do systemów krytycznych.

*Jump host to specjalnie zabezpieczony system pełniący funkcję centralnego, kontrolowanego punktu dostępu, który umożliwia bezpieczne połączenie z sieci zewnętrznej, np. z Internetu, z chronionymi systemami wewnętrznymi.

W środowiskach OT modelowanie zagrożeń powinno być na stałe zintegrowane z procesem inżynieryjnym. Należy przy tym systematycznie uwzględniać typowe scenariusze ataków charakterystyczne dla systemów przemysłowych.

Należy do nich na przykład celowa manipulacja logiką sterownika PLC, która może bezpośrednio wpływać na procesy fizyczne.

Należy również uwzględniać ryzyko wynikające z niezabezpieczonych lub nieprawidłowo skonfigurowanych przemysłowych protokołów komunikacyjnych, takich jak Modbus czy OPC UA, jeżeli ich mechanizmy bezpieczeństwa nie zostały odpowiednio wdrożone.

Kolejnym istotnym scenariuszem jest ruch lateralny za pośrednictwem inżynierskich stacji roboczych. Często pełnią one funkcję systemów łączących sieci IT i OT, przez co mogą stanowić szczególnie atrakcyjny cel dla atakujących. Coraz większego znaczenia nabierają również ataki na łańcuch dostaw, np. za pośrednictwem skompromitowanego firmware’u lub zmanipulowanych mechanizmów aktualizacji.

Modelowanie zagrożeń w środowiskach OT powinno zatem wykraczać poza klasyczną analizę bezpieczeństwa IT i koniecznie uwzględniać również wpływ na procesy fizyczne oraz funkcje związane z bezpieczeństwem funkcjonalnym (Safety). Tylko w ten sposób można realistycznie ocenić profil ryzyka systemów przemysłowych i zastosować odpowiednie środki.
 

Playbook określa osiem kluczowych działań w zakresie zarządzania ryzykiem i bezpieczeństwa operacyjnego, które powinny być realizowane jako procesy ciągłe.

Obejmują one w szczególności:

• systematyczne zarządzanie podatnościami w celu ich ciągłego identyfikowania i usuwania;
• ustrukturyzowane procesy reagowania na incydenty umożliwiające szybką i skoordynowaną reakcję;
• niezawodne strategie tworzenia kopii zapasowych i odtwarzania, służące utrzymaniu lub przywróceniu zdolności operacyjnej w przypadku awarii lub incydentu;
• monitorowanie bezpieczeństwa i rejestrowanie zdarzeń w celu wczesnego wykrywania ataków i umożliwienia ich identyfikowalnej analizy.

Kluczową rolę odgrywa tutaj odporność. Nie jest ona rozumiana wyłącznie jako cel architektury systemu, lecz jako zdolność operacyjna, którą należy wdrażać, weryfikować i stale doskonalić podczas eksploatacji.
 

Jedną z najważniejszych nowości w wersji 1.0 jest rozdział „Progressive Adoption of the Playbooks”. ENISA przedstawia w nim pragmatyczne podejście, które umożliwia przedsiębiorstwom – w szczególności małym i średnim przedsiębiorstwom (MŚP) – stopniowe integrowanie 22 zasad Secure by Design i Secure by Default z procesami rozwoju.

ENISA wyjaśnia jednak, że stopniowe wdrażanie dotyczy wyłącznie praktycznej realizacji poszczególnych środków. Obowiązki prawne, na przykład wynikające z aktu o cyberodporności (CRA), nie mogą być z tego powodu odraczane. Proponowana kolejność stanowi jedynie wskazówkę umożliwiającą uporządkowane wdrażanie środków z uwzględnieniem dostępnych zasobów.

ENISA proponuje podejście składające się z trzech etapów.

1. Określenie kontekstu i priorytetów

W pierwszej kolejności producenci powinni przeanalizować kontekst produktu, przewidywane warunki użytkowania oraz najważniejsze ryzyka związane z cyberbezpieczeństwem.

Za pomocą analizy ryzyka i Threat Modelling identyfikuje się istotne zagrożenia, Trust Boundaries oraz cele bezpieczeństwa. Na tej podstawie można ustalić priorytety niezbędnych środków oraz odpowiednio określić zakres wdrożenia.

2. Stworzenie technicznych podstaw bezpieczeństwa

W drugim etapie ENISA zaleca stworzenie technicznych podstaw inżynieryjnych, obejmujących w szczególności:

• bezpieczne tworzenie i weryfikację oprogramowania;
• rejestrowanie zdarzeń, monitorowanie i alarmowanie;
• zarządzanie podatnościami i poprawkami;
• środki służące zabezpieczeniu łańcucha dostaw oprogramowania.

W zależności od rodzaju produktu należy ponadto wdrożyć istotne funkcje Secure by Default, takie jak restrykcyjne domyślne uprawnienia dostępu, bezpieczne protokoły komunikacyjne, unikalne tożsamości urządzeń oraz automatyczne aktualizacje zabezpieczeń.

Kolejne zasady Playbooka są następnie ustalane według priorytetów w zależności od zidentyfikowanego ryzyka i kontekstu produktu.

3. Ciągłe podnoszenie poziomu bezpieczeństwa

Po stworzeniu solidnych podstaw można stopniowo wdrażać kolejne zasady Secure by Design i Secure by Default.

Celem jest ciągłe zwiększanie dojrzałości środków bezpieczeństwa, poprawa ich spójności oraz automatyzacja jak największej liczby procesów. ENISA zaleca jednocześnie regularną ocenę postępów na podstawie odpowiednich wskaźników i dowodów.

Podsumowując, koncepcja Progressive Adoption stanowi praktyczne podejście do stopniowego wdrażania Secure by Design. Przedsiębiorstwa nie muszą wdrażać wszystkich środków jednocześnie, lecz mogą postępować w sposób oparty na ryzyku i stopniowo rozwijać swoje procesy bezpieczeństwa.

Zwłaszcza dla MŚP podejście to stanowi praktyczną możliwość systematycznego i trwałego integrowania wymagań aktu o cyberodporności z procesem rozwoju produktów, bez ograniczania celu, jakim jest osiągnięcie pełnej zgodności.

Wersja 1.0 wyraźnie zaleca ponadto stosowanie OWASP Software Assurance Maturity Model (SAMM) jako możliwego modelu dojrzałości na potrzeby organizacyjnego wdrażania Secure by Design.

Model ten umożliwia systematyczne strukturyzowanie i stopniowe rozwijanie działań związanych z bezpieczeństwem w całym cyklu życia oprogramowania. W szczególności obszary takie jak Threat Assessment i Security Requirements pokazują, w jaki sposób zidentyfikowane zagrożenia można przełożyć na weryfikowalne wymagania bezpieczeństwa.
 

W wersji 1.0 koncepcja początkowo określana jako Machine-Readable Security Manifest (MRSM) została rozwinięta i przekształcona w Machine-processable Attestation.

W wersji końcowej ENISA częściowo odchodzi zatem od konkretnej koncepcji MRSM i opisuje bardziej ogólnie maszynowo przetwarzalne poświadczenia dotyczące bezpieczeństwa. Dzięki temu koncepcja staje się bardziej otwarta technologicznie i może obejmować formaty inne niż pojedynczy Security Manifest.

Podejście to służy przedstawianiu dowodów dotyczących bezpieczeństwa w ustrukturyzowanej formie, która może być przetwarzana automatycznie. Celem jest systematyczne i identyfikowalne dokumentowanie spełnienia wymagań bezpieczeństwa.

Koncepcja łączy deklaracje dotyczące bezpieczeństwa (Security Claims) z konkretnymi dowodami technicznymi, takimi jak dane konfiguracyjne, wyniki testów czy logi. W ten sposób powstaje solidna i możliwa do zautomatyzowania podstawa do oceny poziomu bezpieczeństwa produktu.

Szczególnie istotną korzyścią jest możliwość wspierania zautomatyzowanych kontroli zgodności, na przykład podczas audytów. Machine-processable Attestation odnosi się zatem do jednego z kluczowych wyzwań związanych z wymaganiami regulacyjnymi: zapewnienia weryfikowalnej, a jednocześnie skalowalnej dokumentacji zgodności, która wykracza poza wyłącznie statyczne lub ręcznie przygotowywane dowody.
 

W załączniku C do Playbooka przedstawiono bezpośrednie powiązanie 22 zasad bezpieczeństwa z wymaganiami określonymi w załączniku I do aktu o cyberodporności (CRA).

Dla producentów oznacza to konieczność wdrażania i dokumentowania środków bezpieczeństwa w całym cyklu życia produktu, aktywnego zarządzania podatnościami oraz udostępniania wymaganych aktualizacji zabezpieczeń.

Cyberbezpieczeństwo staje się tym samym wiążącym wymaganiem regulacyjnym, a nie opcjonalnym elementem produktu. Sam CRA określa zasadnicze wymagania w zakresie cyberbezpieczeństwa dotyczące zarówno produktów z elementami cyfrowymi, jak i procesów obsługi podatności przez producentów.