Wprowadzenie: Zarządzanie podatnością na zagrożenia oparte na ryzyku w ramach ustawy o odporności cybernetycznej
Współczesne zespoły wiedzą już, że naprawienie każdej luki jest niemożliwe. Najważniejsze jest naprawienie tych właściwych. Dlatego zarządzanie podatnością oparte na ryzyku stało się preferowanym podejściem dla zespołów DevSecOps. Jednak w Unii Europejskiej nie jest to już tylko najlepsza praktyka. Ustawa o odporności cybernetycznej wprowadza konkretne obowiązki prawne, zwłaszcza gdy oprogramowanie obejmuje problemy wymienione w CISKatalog znanych luk w zabezpieczeniach.
W tym nowym kontekście priorytetyzacja luk w zabezpieczeniach przenosi się z wyboru bezpieczeństwa na wymóg zgodności. Zespoły muszą udowodnić, że rozumieją, które luki są aktywnie wykorzystywane i jak podejmują decyzję, co naprawić w pierwszej kolejności.
Zarządzanie podatnościami w oparciu o ryzyko i znane wykorzystywane luki
Zarządzanie podatnościami oparte na ryzyku koncentruje się na rzeczywistym narażeniu, a nie na surowej dotkliwości. Zamiast traktować wszystkie CVE jednakowo, zespoły ustalają priorytety na podstawie stopnia wykorzystania, dostępności i wpływu.
To tutaj znane wykorzystywane luki w zabezpieczeniach odgrywają kluczową rolę. Kiedy CVE pojawia się w CISKatalog znanych luk w zabezpieczeniachPotwierdza to, że atakujący już go używają w rzeczywistych środowiskach. Ten sygnał ma znacznie większą wagę niż teoretyczny wynik.
Jeśli chcesz uzyskać głębsze wyjaśnienie tego, czym są KEV i jak je zidentyfikować, możesz przeczytać nasz wcześniejszy wpis Znane, wykorzystywane luki w zabezpieczeniach: co należy naprawić w pierwszej kolejnościW tym artykule skupiamy się na tym, jak KEV wpisują się w modele zgodności i priorytetyzacji w ramach Ustawa o odporności cybernetycznej.
Czego naprawdę wymaga ustawa o odporności cybernetycznej
Ustawa o odporności cybernetycznej ustanawia obowiązkowe obowiązki w zakresie cyberbezpieczeństwa dla produktów z elementami cyfrowymi sprzedawanych w UE. Zgodnie z oficjalną dokumentacją UE:
- https://www.european-cyber-resilience-act.com/
- https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
Producenci muszą:
- Identyfikuj i usuwaj luki w zabezpieczeniach w całym cyklu życia produktu
- Zapobiegaj wysyłce oprogramowania za pomocą znane wykorzystywane luki w zabezpieczeniach
- Wdroż terminowe działania naprawcze po ustaleniu stopnia wykorzystania
- Zachowaj dowody radzenia sobie z lukami w zabezpieczeniachcisjony
Innymi słowy, gdy pojawi się luka w zabezpieczeniach, CISKatalog znanych luk w zabezpieczeniachignorowanie tego tworzy zarówno ryzyko bezpieczeństwa, jak i regulacyjne.
Czym jest ustawa o odporności cybernetycznej (CRA)
Ustawa o odporności cybernetycznej to rozporządzenie UE, które określa obowiązkowe wymogi dotyczące cyberbezpieczeństwa dla oprogramowania i produktów cyfrowych sprzedawanych w Europie. Wymaga od dostawców zarządzania lukami w zabezpieczeniach w całym cyklu życia produktu i unikania udostępniania oprogramowania z znane wykorzystywane luki w zabezpieczeniach.
Lista kontrolna priorytetyzacji luk w zabezpieczeniach CRA Ready
| Wymaganie | Czego oczekuje CRA | Najlepsze praktyki dla zespołów |
|---|---|---|
| Świadomość wykorzystania | Zapobiegaj wysyłce oprogramowania ze znanymi lukami w zabezpieczeniach | Automatyczne dopasowywanie wyników do CISKatalog znanych luk w zabezpieczeniach |
| Priorytetyzacja oparta na ryzyku | Skoncentruj się na lukach, które stwarzają realne zagrożenie bezpieczeństwa | Połącz KEV, EPSS, dostępność i ekspozycję aktywów |
| Terminowa naprawa | Zastosuj poprawki bez zbędnej zwłoki, gdy tylko dowiesz się o naruszeniu | Zdefiniuj teraz umowy SLA dotyczące osiągalnych KEV i wyegzekwuj je CI/CD |
| Ciągłe monitorowanie | Radzenie sobie z lukami w zabezpieczeniach przez cały cykl życia produktu | Przeprowadzaj ciągłe skanowanie kodu, zależności i pipelines |
| Kontrole wydania | Unikaj wypuszczania produktów z aktywnymi, wykorzystywanymi lukami | Blokuj scalanie lub wdrażanie, gdy KEV wpływają na dostępny kod |
| Decisidentyfikowalność jonów | Udowodnij, jak podatnośćcisjony zostały wykonane | Prowadź dzienniki audytu w celu wykrywania, ustalania priorytetów i podejmowania działań naprawczych |
| Integracja programistów | Środki bezpieczeństwa nie mogą zakłócać przepływu prac programistycznych | Priorytetyzacja powierzchni bezpośrednio w pull requests i CI pipelines |
| Odpowiedzialność za cykl życia | Zapewnij bezpieczeństwo po zwolnieniu | Śledź zmiany KEV i EPSS dla dostarczonych wersji |
Dlaczego KEV są kluczowe dla zgodności z przepisami CRA
CISKatalog znanych luk w zabezpieczeniach Zawiera listę luk w zabezpieczeniach (CVE), które atakujący już wykorzystują w praktyce. Innymi słowy, eliminuje niejednoznaczność priorytetyzacji.
Zamiast pytać „Czy można to wykorzystać?”, zespoły muszą teraz zadać sobie znacznie bardziej bezpośrednie pytanie:
„Czy to już jest wykorzystywane i czy mimo wszystko to wysyłamy?”
Zgodnie z ustawą o odporności cybernetycznej (Cyber Resilience Act) to rozróżnienie ma znaczenie prawne. W rezultacie, KEV stają się najsilniejszym bodźcem do zawierania umów SLA dotyczących napraw i blokowania wydań. W tym kontekście zarządzanie podatnościami oparte na ryzyku naturalnie wpisuje się w oczekiwania regulacyjne.
CVSS, EPSS i KEV służą różnym celom
Aby prawidłowo ustalić priorytety, zespoły muszą najpierw zrozumieć, co tak naprawdę przedstawia każdy sygnał.
- CVSS pokazuje potencjalny wpływ
- EPS szacuje prawdopodobieństwo eksploatacji
- CISKatalog znanych luk w zabezpieczeniach potwierdza, że eksploatacja już ma miejsce
Każda metryka rozpatrywana osobno może wprowadzać w błąd. Jednak gdy zespoły używają ich razem, zyskują znacznie jaśniejszy kontekst. Z tego powodu połączenie tych sygnałów stanowi podstawę skutecznego zarządzania podatnościami opartego na ryzyku.
Zarządzanie podatnościami oparte na ryzyku w praktyce
W praktyce model ustalania priorytetów oparty na ryzyku przebiega według jasnego i powtarzalnego schematu.
- Wykrywaj luki w kodzie i zależnościach
- Sprawdź mecze z CISKatalog znanych luk w zabezpieczeniach
- Oceń prawdopodobieństwo wykorzystania luk w zabezpieczeniach za pomocą EPSS
- Sprawdź dostępność w swojej aplikacji lub pipeline
- Zastosuj reguły naprawcze na podstawie narażenia i roli produktu
W rezultacie zespoły przestają traktować listy luk w zabezpieczeniach jako statyczne zaległości i zaczynają traktować je jako konkretne dane dotyczące bezpieczeństwa.cisJony.
Różne modele priorytetyzacji stosowane obecnie przez zespoły
Nie wszystkie zespoły traktują ryzyko w ten sam sposób. Zazwyczaj, w rzeczywistych środowiskach widzimy trzy powszechne modele.
1. Model „najpierw powaga”
Zespoły naprawiają problemy bazując wyłącznie na CVSS.
Ten model jest łatwy do wdrożenia, jednak generuje on sporo szumu informacyjnego i nie spełnia oczekiwań Ustawy o Cyberodporności.
2. Model oparty na prawdopodobieństwie
Zespoły wykorzystują EPSS, aby przewidywać, co atakujący mogą wykorzystać w następnej kolejności.
To podejście poprawia koncentrację. Mimo to nadal pomija luki, które atakujący już wykorzystują.
3. Model świadomy eksploatacji
Zespoły łączą EPSS z CISKatalog znanych luk w zabezpieczeniach i kontekst techniczny.
Natomiast model ten najlepiej wspiera zarządzanie podatnością na ryzyko i jest bezpośrednio powiązany z obowiązkami CRA.
W jaki sposób Xygeni wdraża priorytetyzację gotowości CRA
Xygeni pomaga zespołom przekształcić regulacje w codzienny proces pracy.
Zamiast polegając tylko na dashboards, Xygeni wymusza decisjony dokładnie tam, gdzie zachodzą zmiany w kodzie. W rezultacie, ustalanie priorytetów staje się automatyczne i spójne.
Kluczowe możliwości obejmują:
- Automatyczna korelacja z CISKatalog znanych luk w zabezpieczeniach
- Ocena prawdopodobieństwa wykorzystania potencjału na podstawie EPSS
- Analiza dostępności w celu potwierdzenia rzeczywistego narażenia
- Guardrails ten blok łączy się lub zwalnia, gdy KEV wpływają na dostępny kod
- Zautomatyzowana naprawa za pomocą zabezpieczeń pull requests
- Pełne dzienniki audytu w celu zademonstrowania Ustawa o odporności cybernetycznej spełnienie
Krótko mówiąc, zespoły nie tylko dostrzegają ryzyko. Działają w sposób powtarzalny i możliwy do zweryfikowania.
Przykład Dev to Dev: KEV blokujący wydanie
Wyobraź sobie, że aktualizacja zależności wprowadza CVE.
- Luka pojawia się w CISKatalog znanych luk w zabezpieczeniach
- Xygeni wykrywa to podczas pull request
- Analiza dostępności potwierdza wykonanie ścieżki kodu
- Guardrails zablokuj scalanie automatycznie
- Bot proponuje bezpieczną aktualizację i przeprowadza testy
Deweloper rozwiązuje problem w ramach tego samego procesu. Wersja pozostaje zgodna z wymaganiami. Nie są wymagane żadne spotkania.
Innymi słowy, jest to zarządzanie podatnościami oparte na ryzyku, stosowane dokładnie tam, gdzie pracują programiści.
Dlaczego to ma znaczenie poza zgodnością
Chociaż Ustawa o odporności cybernetycznej zapoczątkowało tę zmianę, korzyści idą dalej.
Zespoły, które priorytetowo traktują wykorzystanie KEV, EPSS i kontekstu:
- Zmniejsz zmęczenie czujnością
- Skróć czas naprawy
- Unikaj łatek awaryjnych
- Dostarczaj bezpieczniejsze oprogramowanie z pewnością
Ogólnie rzecz biorąc, przestrzeganie zasad jest naturalną konsekwencją właściwego dbania o bezpieczeństwo.
Podsumowanie: CRA wprowadza obowiązkowe zarządzanie oparte na ryzyku
Ustawa o odporności cybernetycznej Formalizuje to, czego zespoły ds. bezpieczeństwa nauczyły się już na własnej skórze. Nie wszystkie luki w zabezpieczeniach mają takie samo znaczenie.
CISKatalog znanych luk w zabezpieczeniach Definiuje, czego atakujący używają dzisiaj. EPSS przewiduje, czego użyją następnym razem. Kontekst pokazuje, czy ma to na Ciebie wpływ.
Razem tworzą nowoczesne zarządzanie podatnością oparte na ryzyku.
Xygeni pomaga zespołom stosować ten model w sposób ciągły, automatyczny i w sposób akceptowany przez programistów.
O autorze
Scenariusz Fatima Said, Menedżer ds. marketingu treści specjalizujący się w bezpieczeństwie aplikacji w Bezpieczeństwo Xygeni.
Fátima tworzy przyjazne dla programistów treści oparte na badaniach na temat AppSec, ASPMi DevSecOps. Przekłada złożone koncepcje techniczne na jasne, praktyczne wnioski, które łączą innowacje w dziedzinie cyberbezpieczeństwa z wpływem na biznes.
