Wat zijn de beste werkwijzen voor codeondertekening en hoe implementeer je deze?

Bij cybersecurity en de beveiliging van een organisatie is het essentieel om op alle mogelijke scenario's voorbereid te zijn. Een van de belangrijkste vormen hiervan, met name voor organisaties die software ontwikkelen en distribueren naar klanten, is codeondertekening. In de kern is codeondertekening een relatief eenvoudig proces. Een software-uitgever of -distributeur wil code ontwikkelen die door een klant gebruikt kan worden, maar moet er eerst voor zorgen dat de gebruiker de code kan vertrouwen. Dit is waar codeondertekening om de hoek komt kijken. Eerst wordt een sleutelpaar gegenereerd door een vertrouwde, meestal externe, Public Key Infrastructure (PKI) met behulp van een zogenaamde Certificate Signing Request (CSR).

Een Certificate Signing Request (CSR) verzoekt om een ​​certificaat te genereren en te ondertekenen door een vertrouwde PKI en dit te koppelen aan een sleutelpaar. Een sleutelpaar bestaat uit een publieke sleutel en een privésleutel die, zoals de namen al aangeven, respectievelijk publiek en privé beschikbaar zijn.

De CSR en het sleutelpaar worden vervolgens naar de certificeringsinstantie van de PKI gestuurd, waar de identiteit van de gebruiker wordt geverifieerd. Na deze verificatie wordt de CSR zelf geauthenticeerd en wordt de publieke sleutel gekoppeld aan de identiteit van de aanvrager. Zodra de CA de koppeling heeft ondertekend, ontstaat er een geldig codeondertekeningscertificaat. De aanvrager ontvangt vervolgens het certificaat en kan beginnen met het ondertekenen van code.

Zodra het codeondertekeningscertificaat is aangemaakt, begint het daadwerkelijke codeondertekeningsproces. Eerst wordt de te ondertekenen code gehasht met behulp van een hash- algoritme. Een hash-algoritme neemt een bestand als invoer en genereert een hash-digest.

Een hash digest is een reeks cijfers en letters die uniek is op basis van de inhoud van een bestand. Als een bestand ook maar één letter zou wijzigen, zou de hash digest er compleet anders uitzien. De hash en de privésleutel van het certificaat worden vervolgens doorgegeven aan een ondertekeningsalgoritme en creëren een handtekening. De handtekening wordt vervolgens aan de code gekoppeld en naar de gebruiker verzonden. Voordat we ingaan op de best practices voor code signing, kijken we kort waarom code signing zo belangrijk is.

Het belang van codeondertekening

Codeondertekening is essentieel voor de beveiliging van veel organisaties. Als een aanvaller de mogelijkheid om code met malware te ondertekenen, kan stelen, loopt de reputatie van uw organisatie gevaar. Bovendien kunnen de geldigheid van de software en de ontwikkelaar ervan worden geverifieerd via codeondertekening. Dit opent ook de deur naar grote applicatiewinkels.

De grootste app stores vereisen het gebruik van code signing voor applicaties die in deze app stores worden gebruikt. Dit stelt veel kleinere applicatie-eigenaren in staat om hun apps via het eenvoudige proces van code signing in de grote app stores te krijgen. Nu we weten waarom code signing zo belangrijk is, laten we eens kijken naar de best practices voor code signing.

Aanbevolen procedures voor codeondertekening

• Virusscannen

  Een belangrijk onderdeel van elke codeondertekening is dat er malware- en virusscans aanwezig zijn. Virusscans moeten worden uitgevoerd wanneer het bestand wordt geüpload om te worden gehasht. Virusscans zijn zo belangrijk omdat malware die in code zit en vervolgens wordt gehasht, mogelijk onopgemerkt blijft tijdens het ondertekeningsproces.

  Zodra de code is ondertekend en goedgekeurd door uw organisatie, met malware erin, installeert een gebruiker die code zonder aarzelen op zijn computer, aangezien een vertrouwde organisatie de ondertekende code heeft goedgekeurd. Eenmaal gedownload, kan de malware de computer van de gebruiker infecteren, waardoor uw organisatie een slechte naam krijgt en gebruikers die die organisatie vertrouwden, schade ondervinden. Het is het beste om een ​​tool voor codeondertekening te kiezen die kan worden geïntegreerd met de reeds aanwezige virus- en malwarescans van uw organisatie.

• Veilige opslag van privésleutels

  Een van de meest kwetsbare onderdelen van het codeondertekeningsproces is de privésleutel die aan het certificaat is gekoppeld. Als deze niet goed is beveiligd, is het hele codeondertekeningsproces voor niets. Zodra de sleutel is gestolen, kan een kwaadwillende die sleutel gebruiken om zijn eigen code te ondertekenen onder de naam van de organisatie. Gebruikers denken dan dat het betrouwbare software is, terwijl dat niet zo is. Vervolgens kunnen ze code versturen die zogenaamd afkomstig is van uw organisatie en vol zit met malware. Hierdoor raken alle gebruikers die de software downloaden en gebruiken geïnfecteerd. De afgelopen jaren hebben veel supply chain-aanvallen op deze manier plaatsgevonden. Met onvoldoende beveiliging van de privésleutels konden kwaadwillenden deze sleutels bemachtigen en code ondertekenen met malware erin.

  De code werd vervolgens naar serviceproviders gestuurd, die elk duizenden gebruikers hebben die deze software in verschillende bedrijven gebruiken. De malware kon vervolgens al deze gebruikers infecteren, waardoor de aanvallers informatie, geld en meer konden stelen. Softwarematige opslag van sleutels is mogelijk, maar is veel minder veilig dan hardwarematige opslag. Het wordt aanbevolen om een ​​codeondertekeningsoplossing te kiezen die gebruikmaakt van een hardwarematige opslagmethode, zoals een Hardware Security Module (HSM) . Deze slaan sleutels zo veilig op dat een aanvaller het apparaat zelf zou moeten stelen voordat hij erin kan inbreken om de sleutels te bemachtigen. Tegen die tijd zouden de sleutels echter al geroteerd of onbruikbaar gemaakt kunnen zijn.

• Secundaire verificatie

  Andere tools kunnen worden gebruikt in combinatie met codeondertekening om ervoor te zorgen dat alle ondertekeningen veilig blijven. Tools zoals Active Directory, multifactorauthenticatie, tweefactorauthenticatie en meer zijn geweldige manieren om bij te houden wie code kan ondertekenen en wanneer. Met deze tools moet een gebruiker niet alleen inloggen met een wachtwoord, maar ook met een tweede verificatielaag voordat hij een webpagina opent om codeondertekeningssleutelparen aan te maken en vóór het daadwerkelijke ondertekeningsproces. Dit voorkomt dat aanvallers van buitenaf ondertekenen wanneer ze dat niet zouden moeten doen en kan ook eventuele interne bedreigingen binnen een organisatie in kaart brengen. Elk codeondertekeningsproduct dat door een organisatie wordt gebruikt, zou een vorm van secundaire verificatie moeten gebruiken om ervoor te zorgen dat de maximale beveiliging aanwezig is om de door die organisatie verzonden informatie te beschermen.

• Tijdstempeling

  Het gebruik van tijdstempels is een andere belangrijke tool die wordt gebruikt in het proces van codeondertekening. Tijdstempels houden in dat er een specifieke tijd en datum wordt vastgelegd tijdens het ondertekenen, met als doel het loggen en volgen van ondertekeningsprocessen. Dit gebeurt meestal door contact te maken met een tijdstempelserver tijdens het codeondertekeningsproces. Deze tijdstempel helpt bij de volgende best practice die ik zal bespreken: het loggen van ondertekeningsbewerkingen.

• Bestandsregistratie

  Een andere belangrijke factor bij codeondertekening is het loggen van elke codeondertekeningsbewerking en andere gerelateerde taken. Bewerkingen zoals het aanmaken van een sleutelpaar, het aanmaken van een codeondertekeningscertificaat, het daadwerkelijk ondertekenen van code en het wijzigen van codeondertekeningscertificaten of sleutelparen moeten allemaal worden gelogd voor toekomstig gebruik. Door logs op één locatie op te slaan, kunnen auditors de processen bekijken die hebben plaatsgevonden en vastleggen wat er binnen de codeondertekeningstool gebeurt.

  Bovendien is het belangrijk om deze logs te hebben als er een interne of externe bedreiging optreedt. Zo kan een organisatie de processen volgen die hebben plaatsgevonden en achterhalen wie wat heeft ondertekend. Logging kan ook worden gebruikt om te voorkomen dat een kwaadwillende ontwikkelaar midden in een proces ondertekent. Als een ondertekeningsproces niet door de juiste teams wordt goedgekeurd, kan het worden gestopt voordat het te laat is.

• Sleutel- en certificaatbeheer

  Om de veiligheid van uw sleutels te garanderen, is het essentieel om een ​​sterk sleutel- en certificaatbeheersysteem te hebben.

  • Beperk herhaald sleutelgebruik

    Sleutelrotatie is een techniek die het gebruik van een bepaalde sleutel vermindert. Het is het proces waarbij een bestaande ondertekeningssleutel wordt ingetrokken en vervangen door een nieuw gegenereerde cryptografische sleutel. Door uw sleutels regelmatig te roteren, minimaliseert u het risico, aangezien het gebruik van een sleutel voor meerdere ondertekeningen een kwetsbaarheid creëert.

    Bij een inbreuk wordt alle software die met die sleutel is ondertekend ongeldig. Aanvallers kunnen dit misbruiken en u kwetsbaarder maken voor een softwarelek door malware te verspreiden die vermomd is als legitieme software.

  • Gecompromitteerde certificaten intrekken

    Certificaatintrekking is het proces waarbij het gebruik van een certificaat wordt stopgezet voordat de geldigheidsduur is verstreken. Het stoppen van het gebruik van het gecompromitteerde certificaat is essentieel, omdat ongeautoriseerde partijen dan geen kwaadaardige code meer kunnen ondertekenen onder de naam van uw bedrijf.

    Als u vermoedt dat er een breuk in uw sleutel of certificaat is opgetreden, is het van groot belang dat u actie onderneemt. U kunt bijvoorbeeld contact opnemen met uw certificeringsinstantie (CA) en het certificaat intrekken om te voorkomen dat deze sleutel wordt gebruikt voor codeondertekening.

• Gestroomlijnd ondertekeningsproces

  Automatisering van ondertekening moet worden geïmplementeerd om de efficiëntie van de workflow en ontwikkeling te behouden, zodat het minder tijd kost vanwege minder menselijke factoren:

  • Verschil tussen testondertekening en releaseondertekening

    Om te voorkomen dat ongeteste code per ongeluk wordt vrijgegeven, kan onderscheid worden gemaakt tussen testondertekening en releaseondertekening. Testondertekening is alleen voor intern gebruik om binnen het bedrijf of de organisatie in te checken, maar niet voor klanten, terwijl releaseondertekening de uiteindelijke status is die naar klanten wordt geïmplementeerd.

    Dit kan op veel manieren worden bereikt, bijvoorbeeld door verschillende certificaten te gebruiken of een duidelijke naam voor de ondertekeningen voor testen en vrijgeven.

  • CI/CD en codeondertekening

    De CI/CD-pijplijn is volledig geautomatiseerd en begeleidt u van ontwikkeling tot implementatie. Dit omvat het bouwen, testen, ondertekenen en implementeren. Codeondertekening geïntegreerd met uw Software Development Lifecycle (SDLC) bespaart tijd en bevordert de consistentie.

    Handmatig code ondertekenen kan tijdrovend en foutgevoelig zijn, vooral bij grotere projecten met meerdere ontwikkelaars. De aanschaf van een geautomatiseerd codeondertekeningsproces met behulp van een CI/CD-pipeline zou het proces versnellen en het risico op menselijke fouten verminderen.

• Geavanceerde beveiligingsmaatregelen

  Voorkomen is beter dan genezen; daarvoor is waakzaamheid en proactieve maatregelen tegen evoluerende beveiligingsrisico's essentieel. Hieronder vindt u enkele geavanceerde beveiligingsmaatregelen tegen het ondertekenen van schadelijke code.

  • Blijf op de hoogte

    Code Signing is een domein dat met de tijd mee moet gaan; de broncode moet betrouwbaar en up-to-date zijn. Verouderde cryptografische algoritmen kunnen het doelwit zijn van nieuwe aanvallen, waardoor uw codesigningprotocol onbruikbaar wordt.

    Evalueer en upgrade regelmatig de cryptografische standaarden van uw organisatie om ervoor te zorgen dat ze overeenkomen met de meest recente best practices.

  • Vergelijk ondertekeningen

    De bestaande omstandigheden en de dreiging van codemanipulatie maken het noodzakelijk om de ene ondertekening met de andere te vergelijken, om de betrouwbaarheid van de broncode voor de gebruiker te waarborgen. De vergelijking van de ondertekening van verschillende serverbuilds kan worden gebruikt om te controleren op verschillen en zo bronnen van misbruik aan het licht te brengen.

    Verschillen in ondertekening weerspiegelen ongeautoriseerde wijzigingen of criminele pogingen om de bron te vullen met malware om gevoelige informatie te verkrijgen. De uitkomst van dergelijke controles wordt een "motie van vertrouwen" als twee of meer ondertekeningsbuilds een gelijkwaardig resultaat opleveren, wat een veilige gebruikersomgeving vertegenwoordigt.

Conclusie

Als u zich afvraagt ​​waar u toegang kunt krijgen tot een tool voor codeondertekening, hoeft u niet verder te zoeken dan Encryption Consulting. Bij Encryption Consulting hebben we een tool voor codeondertekening genaamd Code Sign Secure . Onze tool maakt gebruik van alle verschillende best practices die in deze blog worden genoemd, en meer. Onze tool gebruikt hardwarebeveiligingsmodules om privésleutels met betrekking tot codeondertekeningscertificaten veilig te bewaren . We gebruiken ook Active Directory om in te loggen op onze website om sleutels en certificaten aan te maken, en MultiFactor Authentication, wat nodig is voordat er code kan worden ondertekend. We gebruiken ook op rollen gebaseerd toegangsbeheer, zodat alleen degenen met de juiste machtigingen toegang hebben tot ons product voor codeondertekening. Ten slotte scannen we bestanden op virussen voordat ze worden gehasht, voorzien we elke aangemaakte handtekening van een tijdstempel en hebben we een gecentraliseerd logboek dat toegankelijk is via onze website.

Voor meer informatie over Code Sign Secure, of om onze Proof of Concept uit te proberen, kunt u contact opnemen met CodeSigning solution.