Stel je voor dat je een nieuwe auto voor je gezin overweegt. Voordat u een aankoop doet, evalueert u de veiligheidsbeoordelingen, brandstofefficiëntie en betrouwbaarheid. U kunt het zelfs nemen voor een proefrit om ervoor te zorgen dat het aan uw behoeften voldoet. Dezelfde aanpak moet worden toegepast op software- en hardwareproducten voordat ze worden geïntegreerd in de omgeving van een organisatie. Net zoals u geen auto zou kopen zonder de veiligheidsfuncties te kennen, moet u geen software implementeren zonder de risico’s te begrijpen die het introduceert.
De stijgende dreiging van aanvallen van supply chain
Cybercriminelen hebben erkend dat in plaats van een organisatie frontaal aan te vallen, ze door de supply chain van de software kunnen infiltreren-zoals vervalste onderdelen in een assemblagelijn. Volgens de Sonatype State of the Software Supply Chain Report 2024 infiltreren aanvallers open-source ecosystemen met een alarmerend tempo, met meer dan 512.847 kwaadaardige pakketten die vorig jaar alleen zijn gedetecteerd-een stijging van 156% ten opzichte van het voorgaande jaar. Traditionele beveiligingstools en processen missen deze bedreigingen vaak, waardoor organisaties onvoorbereid zijn.
Een belangrijk voorbeeld in 2024 was een jaarlange supply chain-aanval die werd ontdekt in de Python-pakketindex (PYPI). Aanvallers uploadden kwaadaardige pakketten vermomd als legitieme AI Chatbot -tools, in de hoop ontwikkelaars te misleiden om ze in hun projecten te integreren. Deze pakketten bevatten schadelijke code die is ontworpen om gevoelige gegevens te stelen en externe opdrachten op geïnfecteerde systemen uit te voeren. Omdat PYPI op grote schaal wordt gebruikt in verschillende industrieën, had deze aanval het potentieel om duizenden toepassingen in gevaar te brengen voordat beveiligingsonderzoekers bij Kaspersky de kwaadaardige activiteit hadden gedetecteerd en rapporteerden. Dit incident benadrukt hoe aanvallers in toenemende mate gebruik maken van vertrouwde repositories om malware te distribueren, waardoor de noodzaak van extra diepgaande maatregelen bij het evalueren van software wordt versterkt.
Een hands-on benadering van risicobeoordeling: testbeveiligingstests
Organisaties hebben een gestructureerde en herhaalbare manier nodig om software en hardwarerisico’s te evalueren voordat ze in hun omgeving worden geïntroduceerd. Dit proces, bekend als productbeveiligingstests (PST),, gaat over het beantwoorden van belangrijke vragen:
- Welke risico’s introduceert dit product in mijn netwerk?
- Moeten we dit product gebruiken, of is er een veiliger alternatief?
- Als we het gebruiken, welke mitigaties moeten worden aangebracht om het risico te minimaliseren?
PST gaat niet alleen over scannen op kwetsbaarheden – het gaat over het begrijpen van hoe een product zich gedraagt in uw specifieke omgeving en het bepalen van de algehele risico -impact. Gezien het enorme aantal externe componenten die in het moderne IT worden gebruikt, is het onrealistisch om elk softwarepakket gelijk te onderzoeken. In plaats daarvan moeten beveiligingsteams prioriteit geven aan hun inspanningen op basis van de impact van zakelijke impact en het aanvallen van oppervlakte -blootstelling. Toepassingen met een hoog geschrifte die vaak communiceren met externe services moeten testen van productbeveiliging ondergaan, terwijl applicaties met een lagere risico kunnen worden beoordeeld via geautomatiseerde of minder resource-intensieve methoden. Of het nu wordt gedaan vóór de implementatie of als een retrospectieve analyse, een gestructureerde benadering van PST zorgt ervoor dat organisaties zich richten op het eerst veiligstellen van de meest kritische activa met behoud van de algehele systeemintegriteit.
Leren om rood te denken, handel blauw
De SANS SEC568 -cursus is ontworpen om praktische vaardigheden op te bouwen in PST. Het richt zich op black-box-testen, een methode die real-world omstandigheden simuleert waarbij de broncode niet beschikbaar is. Dit maakt het zeer van toepassing op het evalueren van producten van derden waar organisaties geen directe controle over hebben. De cursus volgt op het principe van denken rood, handel blauw – door aanstootgevende tactieken te leren, kunnen organisaties zich beter tegen hen verdedigen.
Hoewel productbeveiligingstests nooit een inbreuk op een derde partij buiten uw controle zullen voorkomen, is het noodzakelijk om organisaties in staat te stellen geïnformeerde beslissingen te nemen over hun verdedigende houding en responsstrategie. Veel organisaties volgen een standaardproces van het identificeren van een behoefte, het selecteren van een product en het implementeren van het zonder een diepe beveiligingsevaluatie. Dit gebrek aan controle kan hen laten klauteren om de impact te bepalen wanneer een aanval van de supply chain optreedt.
Door PST in het besluitvormingsproces op te nemen, krijgen beveiligingsteams kritische documentatie, waaronder afhankelijkheidsmapping, bedreigingsmodellen en specifieke mitigaties die zijn afgestemd op de gebruikte technologie. Deze proactieve benadering vermindert onzekerheid, waardoor snellere en effectievere reacties mogelijk zijn wanneer kwetsbaarheden naar voren komen. In plaats van uitsluitend te vertrouwen op brede industriële mitigaties, kunnen organisaties met PST -documentatie gerichte beveiligingscontroles implementeren die het risico minimaliseren voordat er zelfs een inbreuk plaatsvindt.
Wie maakt gebruik van productbeveiligingstests?
Ongeacht de functie, leidt het hebben van een sterke basis in productbeveiligingstests tot een betere beveiligingshouding en paraatheid binnen de hele organisatie. Hoewel de voor de hand liggende pasvorm testen van productbeveiliging is dat deze methoden kunnen benutten om software van derden te evalueren, evenals hun eigen interne producten-is productbeveiligingstests niet beperkt tot één specifieke rol. Dit is een waardevolle vaardigheden die verschillende posities binnen een organisatie verbetert. Beveiligingsauditors kunnen PST gebruiken om evaluaties aan te passen aan de unieke risico’s en nalevingsbehoeften van een organisatie, terwijl penetratietesters verder kunnen gaan dan eenvoudige kwetsbaarheidsscans om onbekende protocollen en eigen software te analyseren. Toepassingsontwikkelaars profiteren van het begrijpen van hoe aanvallers beveiligingsfouten exploiteren, waardoor ze vanaf het begin een veilige code kunnen schrijven, terwijl SOC -analisten deze vaardigheden kunnen gebruiken om bedreigingen te detecteren en te verminderen die door nieuwe software en hardware worden geïntroduceerd. Zelfs besluitvormers krijgen inzicht van PST, omdat het hen helpt geïnformeerde keuzes te maken over risico’s, beveiligingsinvesteringen en mitigatiestrategieën. Het is belangrijk om te onthouden dat het onmogelijk is om te detecteren, beperken, exploiteren of ontwikkelen wat we niet begrijpen.
Om praktische ervaring op te doen in productbeveiligingstests, overweeg dan om Sec568 bij te wonen in Orlando van 13-18 april 2024. Deze training zal de technische basis bieden die nodig is om software en hardwarebeveiliging effectief te beoordelen. Net als het nemen van een auto voor een testrit voor het kopen, stelt het toepassen van een gestructureerde aanpak op productbeveiligingstests organisaties in staat om potentiële risico’s volledig te begrijpen vóór de implementatie. Door een herhaalbare methode te volgen, kunnen beveiligingsteams risico’s verminderen en beter voorbereid zijn op toekomstige bedreigingen.
Opmerking: Dit artikel is vakkundig geschreven en bijgedragen door Douglas McKee, de uitvoerend directeur van Threat Research bij Sonicwall, evenals de hoofdauteur en instructeur voor SANS SEC568.
