Supply Chain-risico's hebben u in de steek gelaten? Blijf kalm en word strategisch!

De beveiligingsindustrie wordt collectief gek als er nieuwe kwetsbaarheden in software worden ontdekt. OpenSSL is geen uitzondering, en eind oktober en begin november 2022 overweldigden twee nieuwe kwetsbaarheden de nieuwsfeeds. Ontdekking en onthulling zijn slechts het begin van deze oneindige cyclus van kwetsbaarheden. Getroffen organisaties worden geconfronteerd met herstel, wat vooral pijnlijk is voor degenen in de frontlinie van IT. Beveiligingsleiders moeten een effectieve cyberbeveiligingsstrategie handhaven om een ​​deel van het lawaai over nieuwe kwetsbaarheden te filteren, de gevolgen voor toeleveringsketens te herkennen en hun bedrijfsmiddelen dienovereenkomstig te beveiligen.

Aanvallen op de toeleveringsketen gaan niet weg

In ongeveer een jaar tijd hebben we te maken gehad met ernstige kwetsbaarheden in componenten, waaronder log4j, Spring Framework en OpenSSL. Exploitatie van oudere kwetsbaarheden houdt ook nooit op bij implementaties die verkeerd zijn geconfigureerd of die gebruikmaken van bekende kwetsbare afhankelijkheden. In november 2022 hoorde het publiek van een aanvalscampagne tegen de federale civiele uitvoerende macht (FCEB), toe te schrijven aan een door de staat gesteunde Iraanse dreiging. Deze Amerikaanse federale entiteit draaide de VMware Horizon-infrastructuur die de Log4Shell-kwetsbaarheid bevatte, die diende als de eerste aanvalsvector. FCEB werd getroffen door een complexe aanvalsketen met onder meer laterale verplaatsing, gecompromitteerde inloggegevens, systeemcompromissen, netwerkpersistentie, omzeiling van eindpuntbescherming en cryptojacking.

Organisaties kunnen zich afvragen "waarom überhaupt OSS consumeren?" na beveiligingsincidenten van kwetsbare pakketten zoals OpenSSL of Log4j. Aanvallen op de toeleveringsketen blijven stijgen omdat hergebruik van componenten "zakelijk gezien verstandig" is voor partners en leveranciers. We engineeren systemen door bestaande code opnieuw te gebruiken in plaats van vanaf nul te bouwen. Dit is om de technische inspanning te verminderen, operationeel te schalen en snel te leveren. Open source software (OSS) wordt over het algemeen als betrouwbaar beschouwd vanwege de publieke aandacht die het ontvangt. Software verandert echter voortdurend en problemen ontstaan ​​door codeerfouten of gekoppelde afhankelijkheden. Nieuwe problemen worden ook ontdekt door de evolutie van test- en exploitatietechnieken.

Kwetsbaarheden in de toeleveringsketen aanpakken

Organisaties hebben de juiste tooling en processen nodig om moderne ontwerpen te beveiligen. Traditionele benaderingen, zoals kwetsbaarheidsbeheer of point-in-time-beoordelingen alleen, kunnen het niet bijbenen. Regelgeving kan deze benaderingen nog steeds toestaan, waardoor de kloof tussen 'veilig' en 'compliant' blijft bestaan. De meeste organisaties streven naar een zekere mate van DevOps-volwassenheid. "Continu" en "geautomatiseerd" zijn gemeenschappelijke kenmerken van DevOps-praktijken. Beveiligingsprocessen zouden niet moeten verschillen. Beveiligingsleiders moeten de focus behouden tijdens de bouw-, leverings- en runtimefasen als onderdeel van hun beveiligingsstrategie:

• Continu scannen in CI/CD: Streef ernaar build-pijplijnen te beveiligen (dwz shift-links), maar erken dat u niet alle code en geneste code kunt scannen. Succes met shift-links-benaderingen wordt beperkt door scannerefficiëntie, correlatie van scanneroutput, automatisering van releasebeslissingen en scannervoltooiing binnen releasevensters. Tooling zou moeten helpen bij het prioriteren van risico's van bevindingen. Niet alle bevindingen zijn bruikbaar en kwetsbaarheden kunnen mogelijk niet worden misbruikt in uw architectuur.

• Continu scannen tijdens bezorging: Compromis van componenten en omgevingsafwijkingen vinden plaats. Applicaties, infrastructuur en workloads moeten worden gescand terwijl ze worden afgeleverd, voor het geval er iets in de digitale toeleveringsketen is gecompromitteerd wanneer ze afkomstig zijn uit registers of opslagplaatsen en worden opgestart.

• Continu scannen in runtime: Runtime-beveiliging is het startpunt van veel beveiligingsprogramma's en beveiligingsmonitoring vormt de basis van de meeste inspanningen op het gebied van cyberbeveiliging. U hebt echter mechanismen nodig die telemetrie in alle soorten omgevingen kunnen verzamelen en correleren, inclusief cloud-, container- en Kubernetes-omgevingen. Inzichten die tijdens runtime worden verzameld, moeten worden teruggekoppeld naar eerdere bouw- en leveringsfasen. Identiteit en service-interacties

• Geef prioriteit aan kwetsbaarheden die tijdens runtime worden blootgelegd: Alle organisaties worstelen met het hebben van voldoende tijd en middelen om alles te scannen en op te lossen. Prioriteiten stellen op basis van risico's is van fundamenteel belang voor het werken met beveiligingsprogramma's. Blootstelling aan internet is slechts één factor. Een andere is de ernst van de kwetsbaarheid, en organisaties richten zich vaak op problemen met een hoge en kritieke ernst, aangezien deze de meeste impact hebben. Deze aanpak kan nog steeds de cycli van technische en beveiligingsteams verspillen, omdat ze mogelijk achter kwetsbaarheden aanzitten die tijdens runtime nooit worden geladen en die niet kunnen worden misbruikt. Gebruik runtime-intelligentie om te verifiëren welke pakketten daadwerkelijk worden geladen in actieve applicaties en infrastructuur om het daadwerkelijke beveiligingsrisico voor uw organisatie te kennen.

We hebben gecreëerd productspecifieke begeleiding om klanten door de recente OpenSSL-gekte te loodsen.

De nieuwste OpenSSL-kwetsbaarheid en Log4Shell herinneren ons aan de noodzaak van paraatheid op het gebied van cyberbeveiliging en een effectieve beveiligingsstrategie. We moeten niet vergeten dat CVE-ID's slechts die bekende problemen zijn in openbare software of hardware. Veel kwetsbaarheden worden niet gerapporteerd, met name zwakheden in code van eigen bodem of verkeerde configuraties van de omgeving. Uw cyberbeveiligingsstrategie moet rekening houden met gedistribueerde en diverse technologie van moderne ontwerpen. U hebt een gemoderniseerd programma voor beheer van kwetsbaarheden nodig dat runtime-inzichten gebruikt om prioriteit te geven aan herstelwerkzaamheden voor technische teams. U hebt ook dreigingsdetectie- en responsmogelijkheden nodig die signalen uit verschillende omgevingen correleren om verrassingen te voorkomen.

Over de auteur

Michael Isbitski, Director of Cybersecurity Strategy bij Sysdig, doet al meer dan vijf jaar onderzoek naar en adviseert over cybersecurity. Hij is bedreven in cloudbeveiliging, containerbeveiliging, Kubernetes-beveiliging, API-beveiliging, beveiligingstests, mobiele beveiliging, applicatiebescherming en veilige continue levering. Hij heeft wereldwijd talloze organisaties begeleid bij hun beveiligingsinitiatieven en de ondersteuning van hun bedrijf.

Voorafgaand aan zijn onderzoeks- en advieservaring leerde Mike veel harde lessen in de frontlinie van IT met meer dan 20 jaar praktijk- en leiderschapservaring gericht op applicatiebeveiliging, kwetsbaarheidsbeheer, bedrijfsarchitectuur en systeemengineering.