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

Bij cybersecurity en de beveiliging van een organisatie is het essentieel om voorbereid te zijn op elke eventualiteit. Een van de belangrijkste vormen hiervan, met name bij organisaties die software ontwikkelen en distribueren naar klanten, is codeondertekening. In essentie is codeondertekening een relatief eenvoudig proces. Een software-uitgever of -distributeur wil code creëren om te versturen naar een klant, maar moet er eerst voor zorgen dat de code betrouwbaar is voor de gebruiker. Hier komt codeondertekening om de hoek kijken. Eerst wordt een sleutelpaar gegenereerd op basis van een vertrouwde, meestal externe, Publieke Sleutel Infrastructuur (PKI) met behulp van iets dat een Certificate Signing Request heet.

A Verzoek tot ondertekening van een certificaat, of CSR, vereist dat een certificaat wordt gegenereerd en ondertekend door een vertrouwde PKI en gekoppeld aan een sleutelpaar. Een sleutelpaar bestaat uit een publieke sleutel en een privésleutel die, zoals de namen al aangeven, respectievelijk openbaar en privé beschikbaar zijn.

De CSR en het sleutelpaar worden vervolgens naar de certificeringsinstantie van de PKI gestuurd en de identiteit van de gebruiker wordt door de Certificate Authority, of CA. Na deze verificatie wordt de CSR zelf geauthenticeerd en wordt de openbare sleutel gebundeld met de identiteit van de aanvrager. Zo ontstaat een geldig codeondertekeningscertificaat zodra de CA de bundel ondertekent. De aanvrager ontvangt vervolgens het certificaat en kan beginnen met het ondertekenen van code.

Zodra het codeondertekeningscertificaat is aangemaakt, begint het codeondertekeningsproces pas echt. Eerst wordt de te ondertekenen code gehasht via een hashing algoritme. Een hash-algoritme neemt een bestand als invoer en maakt 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 verzonden naar serviceproviders, die elk duizenden gebruikers hebben die deze software gebruiken in meerdere bedrijven. De malware kon vervolgens al deze gebruikers infecteren, waardoor de aanvallers informatie, geld en meer konden stelen. Softwarematige sleutelopslag is mogelijk, maar is veel minder veilig dan hardwarematige sleutelopslag. Het is aan te raden om een ​​codeondertekeningsoplossing te kiezen op basis van het gebruik van een hardwarematige opslagmethode, zoals een HardwarebeveiligingsmoduleDeze sleutels worden zo veilig opgeslagen dat een aanvaller eerst het apparaat zelf moet stelen voordat hij het apparaat kan kraken om de sleutels te stelen. Op dat moment kunnen de sleutels worden gedraaid of onbruikbaar worden gemaakt, waardoor ze niet meer bruikbaar 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 codeondertekeningstool, hoeft u niet verder te zoeken dan Encryption Consulting. Encryptie ConsultingWe hebben een codeondertekeningstool genaamd Code Sign SecureOnze tool maakt gebruik van alle verschillende best practices die in deze blog worden genoemd, en meer. Onze tool gebruikt Hardwarebeveiligingsmodules om privésleutels veilig te beveiligen met betrekking tot certificaten voor codeondertekeningWe gebruiken Active Directory ook om in te loggen op onze website om sleutels en certificaten aan te maken, en om gebruik te maken van multifactorauthenticatie, wat noodzakelijk is voordat code wordt ondertekend. We maken ook gebruik van rolgebaseerde toegangscontrole, zodat alleen gebruikers met de juiste rechten ons codeondertekeningsproduct kunnen gebruiken. Tot slot gebruiken we virusscans voordat een bestand wordt gehasht, voorzien we elke handtekening die wordt aangemaakt van een tijdstempel en hebben we een gecentraliseerde logging die toegankelijk is via onze webpagina.

Voor meer informatie over Code Sign Secure of om ons Proof of Concept te proberen, kunt u contact opnemen met CodeSigning-oplossing.