Ryzyko związane z łańcuchem dostaw cię przygnębiło? Zachowaj spokój i obierz strategię!

Branża bezpieczeństwa zbiorowo traci rozum, gdy w oprogramowaniu odkrywane są nowe luki. OpenSSL nie jest wyjątkiem, a pod koniec października i na początku listopada 2022 r. w kanałach informacyjnych pojawiły się dwie nowe luki w zabezpieczeniach. Odkrycie i ujawnienie to dopiero początek tego niekończącego się cyklu luk w zabezpieczeniach. Dotknięte organizacje muszą stawić czoła remediacji, co jest szczególnie bolesne dla tych, którzy znajdują się na pierwszej linii IT. Liderzy ds. bezpieczeństwa muszą utrzymywać skuteczną strategię cyberbezpieczeństwa, aby pomóc odfiltrować część szumu dotyczącego nowych luk w zabezpieczeniach, rozpoznać wpływ na łańcuchy dostaw i odpowiednio zabezpieczyć swoje aktywa.

Ataki w łańcuchu dostaw nie znikają

W ciągu mniej więcej roku cierpieliśmy z powodu poważnych luk w komponentach, w tym log4j, Spring Framework, OpenSSL. Eksploatacja starszych luk również nigdy nie ustaje w implementacjach, które są źle skonfigurowane lub które wykorzystują znane podatne na ataki zależności. W listopadzie 2022 roku opinia publiczna dowiedziała się o an atak na Federalny Cywilny Oddział Wykonawczy (FCEB), co można przypisać sponsorowanemu przez państwo zagrożeniu ze strony Iranu. Ten amerykański podmiot federalny korzystał z infrastruktury VMware Horizon, która zawierała lukę w zabezpieczeniach Log4Shell, która posłużyła jako początkowy wektor ataku. FCEB został dotknięty złożonym łańcuchem ataków, który obejmował ruch boczny, naruszenie poświadczeń, naruszenie bezpieczeństwa systemu, trwałość sieci, obejście ochrony punktów końcowych i przechwytywanie kryptowalut.

Organizacje mogą zapytać „po co w ogóle korzystać z OSS?” po incydentach bezpieczeństwa z wrażliwych pakietów, takich jak OpenSSL lub Log4j. Ataki w łańcuchu dostaw nadal mają tendencję wzrostową, ponieważ ponowne wykorzystanie komponentów ma „rozsądny biznes” dla partnerów i dostawców. Projektujemy systemy, zmieniając przeznaczenie istniejącego kodu, zamiast budować od zera. Ma to na celu zmniejszenie nakładów pracy inżynierów, skalowanie operacyjne i szybkie dostarczanie. Oprogramowanie open source (OSS) jest ogólnie uważane za godne zaufania ze względu na publiczną kontrolę, jaką otrzymuje. Jednak oprogramowanie ciągle się zmienia, a problemy wynikają z błędów w kodowaniu lub powiązanych zależności. Dzięki ewolucji technik testowania i eksploatacji odkrywane są również nowe problemy.

Eliminowanie słabych punktów w łańcuchu dostaw

Organizacje potrzebują odpowiednich narzędzi i procesów, aby zabezpieczyć nowoczesne projekty. Tradycyjne podejścia, takie jak zarządzanie podatnościami na zagrożenia lub ocena punktowa w czasie, nie nadążają. Przepisy mogą nadal zezwalać na takie podejście, co utrwala podział na „bezpieczne” i „zgodne”. Większość organizacji dąży do osiągnięcia pewnego poziomu dojrzałości DevOps. „Ciągłe” i „zautomatyzowane” to wspólne cechy praktyk DevOps. Procesy bezpieczeństwa nie powinny się różnić. Liderzy ds. bezpieczeństwa muszą zachować koncentrację na wszystkich etapach tworzenia, dostarczania i uruchamiania w ramach swojej strategii bezpieczeństwa:

• Ciągłe skanowanie w trybie CI/CD: Staraj się zabezpieczyć potoki kompilacji (tj. Shift-lewo), ale pamiętaj, że nie będziesz w stanie przeskanować całego kodu i kodu zagnieżdżonego. Sukces w podejściu z przesunięciem w lewo jest ograniczony przez skuteczność skanera, korelację danych wyjściowych skanera, automatyzację decyzji o wydaniach i ukończenie skanera w oknach wydania. Oprzyrządowanie powinno pomóc w ustaleniu priorytetów ryzyka ustaleń. Nie wszystkie ustalenia można wykorzystać, a luki w zabezpieczeniach mogą nie nadawać się do wykorzystania w Twojej architekturze.

• Skanuj w sposób ciągły podczas dostarczania: Zdarzają się kompromisy w zakresie komponentów i dryfowanie środowiska. Aplikacje, infrastruktura i obciążenia powinny być skanowane podczas dostarczania na wypadek, gdyby coś zostało naruszone w cyfrowym łańcuchu dostaw podczas pozyskiwania z rejestrów lub repozytoriów i uruchamiania.

• Skanuj w sposób ciągły w czasie wykonywania: Bezpieczeństwo środowiska uruchomieniowego jest punktem wyjścia wielu programów zabezpieczających, a monitorowanie bezpieczeństwa stanowi podstawę większości działań związanych z cyberbezpieczeństwem. Potrzebujesz jednak mechanizmów, które mogą zbierać i korelować dane telemetryczne we wszystkich typach środowisk, w tym środowiskach chmurowych, kontenerowych i Kubernetes. Informacje zebrane w czasie wykonywania powinny być przekazywane z powrotem do wcześniejszych etapów tworzenia i dostarczania. Interakcje tożsamości i usług

• Nadaj priorytet lukom ujawnionym w czasie wykonywania: Wszystkie organizacje borykają się z problemem posiadania wystarczającej ilości czasu i zasobów, aby wszystko przeskanować i naprawić. Priorytety oparte na ryzyku mają fundamentalne znaczenie dla pracy programu bezpieczeństwa. Ekspozycja w Internecie to tylko jeden z czynników. Innym problemem jest stopień istotności luk w zabezpieczeniach, a organizacje często koncentrują się na problemach o wysokim i krytycznym znaczeniu, ponieważ uważa się, że mają one największy wpływ. Takie podejście może nadal marnować cykle pracy zespołów inżynieryjnych i bezpieczeństwa, ponieważ mogą one ścigać luki w zabezpieczeniach, które nigdy nie są ładowane w czasie wykonywania i których nie można wykorzystać. Korzystaj z analizy środowiska uruchomieniowego, aby sprawdzać, jakie pakiety są faktycznie ładowane w uruchomionych aplikacjach i infrastrukturze, aby poznać rzeczywiste zagrożenie dla bezpieczeństwa Twojej organizacji.

Stworzyliśmy wskazówki dotyczące konkretnego produktu aby przeprowadzić klientów przez ostatnie szaleństwo OpenSSL.

Najnowsza luka OpenSSL i Log4Shell przypominają nam o potrzebie gotowości na cyberbezpieczeństwo i skutecznej strategii bezpieczeństwa. Musimy pamiętać, że identyfikatory CVE to tylko te znane problemy w publicznym oprogramowaniu lub sprzęcie. Wiele luk w zabezpieczeniach nie jest zgłaszanych, w szczególności niedociągnięcia w kodzie własnym lub błędne konfiguracje środowiska. Twoja strategia cyberbezpieczeństwa musi uwzględniać rozproszoną i zróżnicowaną technologię nowoczesnych projektów. Potrzebujesz zmodernizowanego programu do zarządzania lukami w zabezpieczeniach, który wykorzystuje spostrzeżenia środowiska uruchomieniowego do ustalania priorytetów prac naprawczych dla zespołów inżynierskich. Potrzebne są również funkcje wykrywania zagrożeń i reagowania na nie, które korelują sygnały w różnych środowiskach, aby uniknąć niespodzianek.

O autorze

Michael Isbitski, dyrektor ds. strategii cyberbezpieczeństwa w firmie Sysdig, od ponad pięciu lat zajmuje się badaniami i doradza w zakresie cyberbezpieczeństwa. Jest zorientowany w bezpieczeństwie chmury, bezpieczeństwie kontenerów, bezpieczeństwie Kubernetes, bezpieczeństwie API, testowaniu bezpieczeństwa, bezpieczeństwie mobilnym, ochronie aplikacji i bezpiecznym ciągłym dostarczaniu. Kierował niezliczonymi organizacjami na całym świecie w ich inicjatywach związanych z bezpieczeństwem i wspierał ich biznes.

Przed podjęciem pracy badawczej i doradczej Mike wyciągnął wiele trudnych lekcji na pierwszej linii frontu IT dzięki ponad 20-letniemu doświadczeniu praktycznemu i kierowniczemu, koncentrując się na bezpieczeństwie aplikacji, zarządzaniu lukami w zabezpieczeniach, architekturze korporacyjnej i inżynierii systemów.