Cyber Resilience Act bez tajemnic: ryzyka, regulacje i podejście DevSecOps | #SiiTalks

Zaczęliśmy być wszyscy bombardowani dosyć wielkimi medialnymi informacjami o atakach hakerskich i o konsekwencjach tych ataków hakerskich. Gigantycznych konsekwencjach dla wielu wielkich firm. Wykonujemy właśnie pracę polegającą na zanalizowaniu i zweryfikowaniu i sprawdzeniu, gdzie są luki, gdzie są może jakieś wąskie gardła, gdzie są blokady, gdzie brakuje tych kroków związanych z security. Cześć! Witam Was wszystkich w kolejnym odcinku Sii Talks, formatu produkowanego przez Sii Polska. Dzisiaj poruszymy ważny temat Cyber Resilience Act, w skrócie CERA, czyli tematyki bardzo gorącej, dotyczącej nas wszystkich, bo związanej z cyberbezpieczeństwem.

Zanim przejdziemy do... Kiedy pierwszy raz usłyszałeś o tych unijnych regulacjach? Kiedy usłyszałeś o nowym paradygmacie przesuwania bezpieczeństwa w lewą stronę w procesie wytwarzania oprogramowania? Temat security, a tak naprawdę cyber security de facto został wymuszony przez rynek. Przez rynek dlatego, że oczywiście zaczęliśmy być wszyscy bombardowani dosyć wielkimi medialnymi informacjami o atakach hakerskich i o konsekwencjach tych ataków hakerskich. Gigantycznych konsekwencjach dla wielu wielkich firm, przede wszystkim medialnych, ale również prawnych i tak dalej.

Prawdopodobnie to był ten moment, gdzie również organizacje takie jak Unia Europejska uznały, że to już jest czas podnieść świadomość wszystkich konsumentów, jak ważnym tematem jest bezpieczeństwo i jak bardzo prosto to bezpieczeństwo ma przełożenie na każdego człowieka, bo wszyscy korzystamy z pewnych urządzeń, które po prostu dają dostęp do naszych bardzo prywatnych i poufnych danych. W przestrzeni medialnej jest bardzo głośno o bezpieczeństwie, bezpieczeństwie cyfrowym, atakach hakerskich. Gdybyś w 30 sekund powiedziała, czym jest Cyber Resilience Act, CERA? Cyber Resilience Act, czyli rozporządzenie unijne, ma za zadanie wprowadzić harmonizacyjne rozwiązanie dla wszystkich państw Unii Europejskiej dotyczące produktów z elementami cyfrowymi.

Tematem zarządu, tematem wielkich kar, tematem, nie wiem, jakichś problemów finansowych ze względu na to, że niektóre work-roundy nie dają się zastosować na samym końcu wytworzenia produktu, bo się na przykład okazuje, że coś po architekturze zostało źle zaplanowane, tak że no niestety, no to się już nie da i duże pieniądze są potrzebne, żeby po prostu wrócić do faktu praktycznego i sensownego zabezpieczenia produktu. To co opisałaś pokazuje, że już zespoły deweloperskie, testerskie mają tą świadomość i implementują potrzebne rozwiązania. Ale wracając do Cyber Resilience Act. Jakie są terminy? Kiedy powinniśmy być gotowi, by powiedzieć?

Że mamy zaimplementowane wymagania i one działają. Samo rozporządzenie Cyber Resilience Act weszło w życie w grudniu 2024 i od tego momentu stało się aktem obowiązującym. Tak jak powiedziałam, jest harmonizacyjnym regulacją w Unii Europejskiej, w związku z powyższym nie będzie się przekładało na żadne dodatkowe akty prawne w poszczególnych krajach, tylko już obowiązuje we wszystkich 27 krajach Unii. NAKOM jest oczywiście pierwszym okresem w ramach obowiązywania tego aktu. Jest tak zwany okres tranzycji, w którym firmy po prostu, producenci powinni się przygotować. Przygotować procesy, zrozumieć, wykonać swoją samą cenę przygotowania do spełniania wymogów wynikających z aktu.

Nie bez kozary mówię o Wielkiej Brytanii, bo tu mamy Unię Europejską i CERA, tam mamy PSTi. Jak te firmy, które działają na dwóch rynkach powinny się przygotować do dwóch różnych regulacji? Regulacja w Wielkiej Brytanii jest o wiele mniej rygorystyczna, natomiast jak najbardziej, tak jak mówisz, istnieje i to jest prawda, że jak gdyby wszelkie firmy... Kto chce wejść z produktem na rynek europejski, ale na przykład też na rynek Stanów Zjednoczonych, powinny zainteresować się dodatkowymi regulacjami obowiązującymi w tych krajach. I tak jak mówiłeś, w UK jest to PSTI, na przykład w Stanach mamy Cyber Trust Mark. Natomiast te regulacje czy te oczekiwania w stosunku do producentów w tych pozostałych krajach są mniej restrykcyjne, tam jest mniejszy reżim nałożony, tak?

Później na podstawie tego oczywiście, tak jak mówię, jest wykonywana analiza ryzyk. I teraz analiza ryzyk to jest znowu temat pochodzący z Cyber Resilience Actu, ale żeby wykonać analizę ryzyka, czyli taką biznesową analizę, to najpierw jest potrzebny threat analysis, czyli analiza zagrożeń. I to już jest element DevSecOps. Czyli jakby sprawdzamy, jakie są techniczne podatności, a potem jaki one mają wpływ tak naprawdę na biznes. Tak, bo być może biznes jest w stanie jakiś z tych ryzyk zmitykować poprzez przyjęcie do wiadomości, po prostu, bo nie jest jakby jakimś tam istotnym ryzykiem. Więc najpierw robimy taką analizę i weryfikujemy proces, a potem już wchodzimy faktycznie z integrowaniem, z sugerowaniem, jakie rozwiązania

Czego? Na przykład Secure Update over the year. To jest podstawa, żeby jak gdyby Cyber Resilience Act wymaga, Subskrybujcie kanał. To są bardzo często tematy, zaczynamy od Secure Updates. Secure Booty, czyli bootowanie urządzenia w odpowiedni sposób, tak? Startowanie jego. Potem właśnie analizy, czyli wdrażanie poszczególnych narzędzi właśnie, jak na przykład dostatecznej analizy kodu. Ale to nie znaczy, że tylko wdrożyć, trzeba rozumieć, co zrobić z efektami wypluwanymi przez te narzędzia, tak?

Oprócz tego, że oczywiście jakiś taki damage powiedzmy sobie medialny, czyli taki uszczerbek biznesowy jest na pewno olbrzymim faktem dla firm. No ale również wszystkie kary wynikające z zapisów będących już w tej chwili w Cyber Resilience Act. To są kary finansowe bardzo jakby tam dotkliwe. W związku z powyższym jakby no nikt nie uniknie. Od tego etapu zgodności z CRA w związku z powyższym trzeba wdrożyć jakiś model, który pomoże te wszystkie aspekty wykorzystać. No i od strony technicznej właśnie powiedziałabym przede wszystkim o tym, o aktualizacjach, czyli secure update, na przykład over the year.

Zamknijmy tę naszą rozmowę taką klamrą, najważniejszymi wnioskami. Może ja powiem, ty uzupełnisz. Cyber Resilience Act i wymagania dotyczące również UK wymaga systemowej zmiany, a nie jednorazowego audytu, przetestowania na koncie, przygotowania dokumentów. Zgadzasz się z tym? Zdecydowanie. Game changerem jest i właściwie jedyną możliwą zmianą jest zaimplementowanie całego procesu DevSecOps. On pomoże wypełnić normy, ale też zrobi nasz wewnętrzny compliance. DevSecOps to jest jeden z konceptów, natomiast jest najbliższy.