Waarom elke organisatie best practices voor codeondertekening moet volgen

Het versterken van de beveiliging van een organisatie is in de loop der tijd van cruciaal belang, aangezien er regelmatig nieuwe infiltratietechnieken worden ontdekt. ​​Aanvallen kunnen via verschillende aanvalsvectoren plaatsvinden, en een van de meest voorkomende aanvallen is het misbruiken van codeondertekening . Deze aanvallen worden op diverse manieren uitgevoerd, maar er zijn methoden om de beveiliging tegen dit soort aanvallen te versterken. Door de beste praktijken voor codeondertekening te volgen, kunt u de beveiliging van uw organisatie tegen deze aanvallen verbeteren.

Waarom u de beste werkwijzen voor codeondertekening moet volgen

Zoals veel organisaties weten, behoren supply chain-aanvallen tot de meest voorkomende soorten aanvallen van tegenwoordig. Supply chain-aanvallen worden uitgevoerd op organisaties die dagelijks met een groot aantal kleinere organisaties samenwerken. Hiermee bedoel ik dat supply chain-aanvallen zich richten op organisaties die software of tools leveren aan een aantal kleinere organisaties. Dit stelt cybercriminelen in staat om een ​​tool of softwareonderdeel van één organisatie te infecteren en zo alle kleinere organisaties die die tool gebruiken te besmetten. Supply chain-aanvallen die zich richten op codeondertekening compromitteren specifiek het software-updateproces zelf, zoals bij SolarWinds (2020), waar een build-pipeline werd gecompromitteerd en malware werd ondertekend met een legitiem certificaat vóór distributie, of het 3CX-incident (2023), waar een vergelijkbaar patroon van build-compromis ervoor zorgde dat malware werd verspreid als een vertrouwde, ondertekende update.

De beste praktijken voor codeondertekening als operationeel model, gedefinieerd: geen checklist die eenmalig moet worden doorgenomen, maar afdwingbare controles, HSM-ondersteunde sleutels, op rollen gebaseerde toegang met functiescheiding, verplichte goedkeuringen, geplande rotatie, fraudebestendige auditlogboeken, geteste intrekking en buildisolatie, die een ondertekeningsplatform automatisch afdwingt in plaats van dat individuen eraan moeten denken een beleidsdocument te volgen.

Key Takeaways

• Een beleidsdocument is geen controlemechanisme. Best practices verminderen risico's alleen wanneer een platform ze automatisch afdwingt, bijvoorbeeld door middel van HSM-sleutelopslag, verplichte goedkeuringspoorten en toegangsbeperkingen die niet door een individu kunnen worden omzeild.
• Deze pagina beschrijft de businesscase en de volledige set besturingselementen op een beknopt niveau. Voor een gedetailleerde implementatiehandleiding, zie Best practices voor codeondertekening in de SDLCOm te meten waar uw organisatie zich momenteel bevindt, zie Volwassenheid van codeondertekening onthuld en de bijbehorende zelfbeoordelingsscorekaart.

Codeondertekening in de industrie

Hoewel code signing geen nieuwe technologie is, aangezien bedrijven het al jaren gebruiken, worden er nog steeds regelmatig hiaten in code signing-technieken aangetroffen. Hoewel dit niet gerelateerd is aan code signing, werd er onlangs een kwetsbaarheid ontdekt in de Java-programmeertaal: de Log4J-kwetsbaarheid, die al jaren in Java-code voorkomt. Deze kwetsbaarheid, hoewel pas recent ontdekt, vormt de basis van het merendeel van de Java-code op internet.

Deze recente kwetsbaarheid heeft de meeste bedrijven wereldwijd in paniek gebracht bij hun pogingen om deze kwetsbaarheid te patchen. Veel van deze organisaties zullen hun beveiliging moeten verbeteren vanwege deze kwetsbaarheid en up-to-date moeten blijven met updates van Java zodra er een officiële patch uitkomt. Dit type kwetsbaarheid is de reden waarom het zo belangrijk is om uw systemen up-to-date te houden met de best practices voor codeondertekening, aangezien een dergelijke grote kwetsbaarheid in de toekomst mogelijk ontdekt zal worden.

Top beste praktijken voor codeondertekening

Hieronder volgen de controles die de beste praktijken voor codeondertekening omzetten in een afdwingbaar werkmodel, en niet slechts in een beleidsdocument.

• HSM-ondersteunde sleutels: Privésleutels die worden gebruikt voor certificaten voor het ondertekenen van code moeten worden opgeslagen in een hardwarebeveiligingsmodule (HSM), niet op een bestandssysteem, in een script of in omgevingsvariabelen. Een HSM vereist fysieke toegang en de juiste inloggegevens om een ​​sleutel te extraheren. Daarom heeft het CA/Browser Forum sinds 1 juni 2023 het gebruik van een HSM of gelijkwaardige hardware (minimaal FIPS 140-2 niveau 2 of Common Criteria EAL 4+) verplicht gesteld voor alle publiekelijk vertrouwde certificaten voor het ondertekenen van code.
• Op rollen gebaseerde toegangscontrole en functiescheiding: De toegang tot ondertekeningssleutels en de HSM moet worden beperkt volgens het principe van minimale bevoegdheden, en de persoon die een build kan starten, mag niet dezelfde persoon zijn die de ondertekening ervan kan goedkeuren. Deze scheiding voorkomt dat één gecompromitteerd account eenzijdig kwaadaardige code ondertekent en verspreidt.
• Verplichte goedkeuringsworkflows: Elke ondertekeningsaanvraag, behalve voor standaard testbuilds, moet goedkeuring vereisen van een tweede, vertrouwde instantie voordat de handtekening wordt toegepast. Dit is de beveiligingsmaatregel die een interne dreiging of een gecompromitteerde pipeline detecteert die probeert een ongeautoriseerde update door een verder legitiem ondertekeningsproces te loodsen.
• Geplande sleutelrotatie: Sleutels moeten volgens een vast schema worden geroteerd, niet alleen naar aanleiding van een vermoedelijke inbreuk, waardoor de periode waarin een sleutel kwetsbaar is, wordt verkort als deze ongemerkt wordt gecompromitteerd.
• Auditlogboeken die fraudebestendig zijn: Elke ondertekeningsgebeurtenis moet worden vastgelegd met de hash van het artefact, de sleutelidentificatie, de goedkeurende persoon en het tijdstempel. Dit maakt een inbreuk op de codeondertekening forensisch traceerbaar in plaats van een mysterie, en is wat compliance-frameworks zoals SOC 2 en NIST verwachten te zien tijdens een audit.
• Geteste intrekkingsprocedures: Een gedocumenteerd en geoefend intrekkingsproces is belangrijk omdat de CA/Browser Forum vereist dat sleutels binnen 24 uur na een bevestigde inbreuk worden ingetrokken. Het ontwikkelen van die mogelijkheid tijdens een daadwerkelijk incident, in plaats van ervoor, kost waardevolle reactietijd.
• Tijdstempeling: Elke digitale handtekening moet een RFC 3161-tijdstempel bevatten, zodat ondertekende software verifieerbaar blijft nadat het certificaat is verlopen. Dit is steeds belangrijker nu publiekelijk vertrouwde codeondertekeningscertificaten een maximale geldigheidsduur van 460 dagen hebben.
• Bouwisolatie: Het ondertekenen moet plaatsvinden in een speciaal daarvoor bestemde, beveiligde omgeving die uitsluitend voor dat doel wordt gebruikt, en niet op een algemene computer waarop andere software draait die het aanvalsoppervlak vergroot en niets met het ondertekenen zelf te maken heeft.

Veelgestelde Vragen / FAQ

Is een schriftelijk vastgelegd beleid voor codeondertekening voldoende om een ​​audit te doorstaan?

Nee. Auditors verwachten steeds vaker bewijs dat de controles door het platform worden afgedwongen, en niet alleen documentatie, fraudebestendige logboeken, HSM-verklaringen en goedkeuringsdocumenten waaruit blijkt dat het beleid is gevolgd, en niet alleen opgeschreven.

Welke van deze werkwijzen is het belangrijkst als we er maar één als eerste kunnen implementeren?

Sleutelopslag met HSM-ondersteuning. Dit is de feitelijke basisvereiste van het CA/Browser Forum, en alle andere controles (goedkeuringen, rotatie, auditregistratie) gaan ervan uit dat de sleutel zelf niet onbeschermd op een bestandssysteem staat.

Hoe weet ik hoe mijn organisatie momenteel staat ten opzichte van deze praktijken?

Zie Code Signing Maturity Uncovered voor een zelfbeoordelingsscorekaart met betrekking tot sleutelbeheer, toegangscontrole, intrekking, build-isolatie en audit trail.

Conclusie

Zoals u kunt zien, is het versterken van de beveiliging waar mogelijk van groot belang om de continue veiligheid van een organisatie te waarborgen. Het volgen van best practices op alle gebieden van computerbeveiliging is cruciaal, aangezien een grote kwetsbaarheid zoals de log4j-vulnerabiliteit op elk moment door elke organisatie kan worden ontdekt. ​​Een andere goede manier om ervoor te zorgen dat een organisatie best practices volgt, is door het cybersecuritynieuws te volgen en ervoor te zorgen dat patches of nieuwe methoden voor het beveiligen van systemen indien nodig worden bijgewerkt. Ga voor meer informatie over de implementatie van ons codeondertekeningsproduct naar onze website www.encryptionconsulting.com.