Vijf methoden om codeondertekening beter te beveiligen

We leven in een gedigitaliseerde wereld die in toenemende mate op softwarecode draait. Vrijwel elk aspect van ons leven is nu doordrongen van software - van de dingen die we dagelijks gebruiken tot de kritieke infrastructuren van onze samenleving. Tegelijkertijd worden hackers steeds vernuftiger in de kunst van het verspreiden van malware. Een berucht voorbeeld daarvan is de SolarWinds-aanval, waarbij ruim 18.000 klanten schade opliepen omdat zij vertrouwden op de software van SolarWinds. Zij vertrouwden die software, omdat deze digitaal was ondertekend en geverifieerd met behulp van een zogeheten code signing machine-identiteit.

Deze aanvalsmethode - waarbij hackers malware aan software toevoegen bij de ontwikkeling zodat deze in legitieme software-updates terechtkomt - is niet nieuw. De geraffineerdheid en impact van dit soort aanvallen is echter bijzonder succesvol gebleken en heeft anderen al geïnspireerd het ook te proberen. Het is daarom belangrijk dat bedrijven dit proberen te voorkomen. Hoewel er natuurlijk geen wondermiddel bestaat, is het aanscherpen van de processen een belangrijke stap.

Code signing: oplossing of probleem?
Hoe kun je voorkomen dat malware wordt opgenomen in de software die je ontwikkelt? Bij de aanval van SolarWinds vertrouwden organisaties erop dat wanneer SolarWinds hun software bouwde, deze vrij zou zijn van kwaadaardige code. Ze hadden impliciet vertrouwen in de ondertekende software die ze ontvingen, omdat er geen bewijs was dat ermee geknoeid was.

Hoewel er geen eenduidige oplossing is om zo’n slimme aanval te voorkomen, kunnen strengere procedures voor het ondertekenen van codes wel degelijk helpen. Code signing-certificaten zijn namelijk machine-identiteiten die ontwikkelaars in staat stellen te bewijzen dat een stuk software authentiek is. Door apps, containers, software of embedded firmware digitaal te ondertekenen met een privésleutel, wordt aan eindgebruikers het bewijs geleverd dat de code afkomstig is van een betrouwbare en legitieme bron. Als machine-identiteiten voor het ondertekenen van code echter slecht worden beveiligd en in handen vallen van aanvallers, kan dit ernstige consequenties hebben. De machine-identiteit is dan namelijk als een wapen te gebruiken waarmee hackers de processen voor het ondertekenen van code kunnen ondermijnen, terwijl ze er toch betrouwbaar uitzien.

Enkele decennia geleden beschermden bedrijven hun software-omgevingen door het proces volledig te sandboxen, zonder netwerktoegang van buitenaf. Elke broncode die binnenkwam werd gescand door verschillende AV-engines om er zeker van te zijn dat daarin geen bekende kwetsbaarheden aanwezig waren. Hoewel dit ten koste ging van gemak en snelheid, kon zo het best mogelijke product worden ontwikkeld. Dit is echter niet langer uitvoerbaar, gezien de snelheid van ontwikkelaars en de planning van bedrijven voor digitale transformatie. Als we echter geen volledig offline systeem hebben om software te bouwen, hoe kunnen we dan onze 'always online' pijplijn van software ontwikkelen en leveren beter beveiligen?

Eén manier om de ontwikkelpijplijn beter te beveiligen is door deze te vergrendelen en alleen software toe te laten die specifiek goedgekeurd is voor installatie in de supply chain. Er is dan echter nog geen reden waarom een statische lijst van goedgekeurde binaries met geldige handtekeningen niet moet worden gecontroleerd, alvorens deze te gaan gebruiken. Ten tweede moeten procedures voor het ondertekenen van codes worden verscherpt om het strikte aantal softwareprogramma’s op een werkplek af te dwingen, en ervoor te zorgen dat alleen vertrouwde code wordt uitgevoerd. Dan mag alleen door de verkoper goedgekeurde software deel uitmaken van de ontwikkelomgeving en zou geïnstalleerde malware (zoals in de SolarWinds-aanval) niet kunnen worden uitgevoerd.

Maatregelen die toekomstige aanvallen helpen voorkomen
Zoals bij elke inbraak bestaat er geen toverformule die de SolarWinds-aanval en de daaropvolgende broncodewijzigingen kan voorkomen. Een aanpak gebaseerd op meerlaagse beveiliging is altijd goed voor de totale beveiliging van systemen en software. Van de netwerklaag tot iedereen die toegang heeft tot broncode. Maar ook het controleren van de code tot het leveren van een product waarvan organisaties kunnen bewijzen dat het afkomstig is van hun vertrouwde ontwikkelsysteem. Dit geheel moet worden geaudit, gecontroleerd en onderhouden met alle risico's in het achterhoofd.

Het tempo van DevOps-pijplijnen heeft de beveiligingsuitdaging al voorbij onze menselijke snelheid en controle gebracht. Organisaties kunnen tegenwoordig dus niet meer vertrouwen op handmatige processen en checklists, om er zeker van te zijn dat ze de juiste software draaien en dat daarin geen ongeoorloofde wijzigingen zijn aangebracht. Toch zijn er vijf maatregelen die securityprofessionals kunnen nemen om hun procedures voor codeondertekening te verbeteren, zonder de totale systeembeveiliging te beïnvloeden:

• Gecentraliseerde beveiliging van sleutels
Door de opslag van alle private sleutels van een organisatie te centraliseren, hoeft men zich geen zorgen meer te maken over onbevoegde kopieën van sleutels voor codeondertekening.
• Goedkeuring wie waar mag tekenen
Organisaties hebben een workflow voor de goedkeuring nodig, zodat zij kunnen configureren welke gebruikers code mogen ondertekenen en op welke systemen zij toestemming hebben om het ondertekenen uit te voeren voor de centraal opgeslagen sleutels.
• Goedkeuring op het moment van ondertekening
Zodra u een gebruiker en een systeem hebt goedgekeurd om software te ondertekenen, wat ondertekenen ze dan eigenlijk? Het is ook belangrijk een goedkeuringsproces te definiëren dat een beheerder in staat stelt ondertekeningen te controleren alvorens goed te keuren.
• Ondertekening controleren, zelfs in een sterk geautomatiseerde CI/CD-pijplijn
Goedkeurings- en ondertekeningsacties moeten worden toegewezen aan systeemaccounts en worden gecontroleerd en gepland. Automatisering is nodig om ontwikkelaars in staat te stellen tijdig te leveren en er tegelijkertijd voor te zorgen dat ze de richtlijnen hebben om aan te tonen dat ze controle hebben over het ondertekeningsproces.
• Auditing en rapportage
Kunnen auditen en bewijzen dat het beleid en ‘best practices’ worden gevolgd, is belangrijk voor het gebruik van code signing in elke software supply chain. Organisaties moeten zowel een register bijhouden van alle activiteiten voor code signing, als de goedkeuring ervan. Daarmee is het risico op aanvallen door opportunistische cyberaanvallers sterk te beperken.

Elke organisatie die software ontwikkelt en securityverantwoordelijken doen er verstandig aan te evalueren hoe zij machine-identiteiten beter kunnen beveiligen. Dit gaat verder dan het verbeteren van beveiligingsmaatregelen die enkel gericht zijn op het reduceren van kwetsbaarheden in de code. Het hele ontwikkelproces moet worden beveiligd met machine-identiteiten, die ook allemaal moeten worden beheerd. Dit betekent inzicht in alle ondertekeningscertificaten die men toepast, informatie over hoe ze worden gebruikt en automatisering om de volledige levenscyclus ervan te beheren. Zonder deze maatregelen kunnen hackers zich succesvol blijven richten op code-signing processen.

Tony Hadfield is Director Solutions Architect bij Venafi.