Veilig coderen - Uitdagingen voor informatiebeveiliging

• Kwetsbaarheden in code
• Open source code en aanvallen in de toeleveringsketen
• Informatiebeveiligingscontrole 8.28 veilige codering
• Principes van veilige codering
• Conclusie
• Herziening van ISO 27001: wat betekent de update voor uw certificering?
• DQS - Eenvoudig gebruik van beveiliging.

Informatiebeveiligingscontrole 8.28 veilige codering

Om het softwareontwikkelingsproces tijdig te waarborgen heeft de Internationale Organisatie voor Normalisatie (ISO - comité ISO/IEC JTC 1/SC 27) "Secure Coding" als nieuwe controle 8.28 opgenomen in de nieuwe ISO/IEC 27002 en ISO/IEC 27001:2022, Annex A normen. Het doel van de technische maatregel voor veilige codering is de preventieve bescherming van software.

Al in de schrijffase wordt op basis van procedurele voorschriften een minimaal beveiligingsniveau gecreëerd, waardoor het aantal potentiële beveiligingskwetsbaarheden in de software tot een minimum wordt beperkt. Het regelgevingskader voor het genereren van veilige code moet holistisch worden toegepast, zowel op de eigen programmacode als op software van derden en open source bronnen. Belangrijke beginselen voor de uitvoering zijn Security by Design en Least Privilege, waarmee ook bij de codering rekening moet worden gehouden.

Beginselen van veilige codering

In maatregel 8.28 komen de zogenaamde beginselen van veilige codering verscheidene malen aan de orde. Richtlijnen over wat deze zouden kunnen zijn, worden gegeven door tal van organisaties en instituten die regelmatig gidsen en beste praktijken voor veilige codering uitbrengen. Dit zijn bijvoorbeeld de Secure Coding Practices van de OWASP Foundation, de Secure Coding Standards van het Computer Emergency Response Team (CERT) van het Software Engineering Institute (SEI), en de catalogus van maatregelen voor de beveiliging van webapplicaties van het Duitse BSI. Ondanks de verschillende bronnen vertonen de uitwerkingen veel parallellen, bijvoorbeeld met betrekking tot de volgende punten:

• Validatie van gegevensinvoer
• Beveiliging van authenticatie en wachtwoordbeheer
• Veilige toegangscontrole
• Eenvoudige, transparante code
• Duurzaam geteste cryptografische maatregelen en componenten
• Foutafhandeling en logboekregistratie
• Gegevensbescherming
• Modellering van bedreigingen

In de ISO/ISO 27002:2022-norm zijn de aanbevolen acties voor controle 8.28 onderverdeeld in drie delen, "Planning en precoding", "Tijdens het coderen" en "Verificatie en onderhoud", waarvan de kern hieronder wordt geschetst.

Kwetsbaarheden in code

Besturingssysteemsoftware, toepassingssoftware of firmware in een embedded systeem zijn elementaire onderdelen van elke digitale infrastructuur. De toenemende versnelling en tijdsdruk in digitaliseringsprojecten leiden echter vaak tot verwaarlozing van dwingende informatiebeveiligingsaspecten. De ontwikkelingseisen voor software zijn meestal functiegericht en leggen de nadruk op constructieve aspecten, zodat de destructieve kijk op potentiële beveiligingskwetsbaarheden meestal haaks staat op de eigenlijke ontwikkelingsdoelstellingen: het ontbreekt veel programmeurs simpelweg ook aan een gestructureerde en aangescherpte kijk op cyberbeveiliging.

Onder deze omstandigheden hebben ontwikkelingsteams het moeilijk om de codering van hun software voortdurend te herzien en consequent te beveiligen, zoals blijkt uit de vele kwetsbaarheden die de non-profit MITRE Corporation elk jaar publiceert in haar CVE-lijst (Common Vulnerabilities and Exposures). De regelmatige beveiligingspatches van zelfs bekende softwarefabrikanten zijn een indicatie van de Sisypheïsche taak om veiligheidsrelevante bugs te dichten, laat staan ze te identificeren voordat ze op de markt worden gebracht.

Open broncode - een speciaal geval

Bij het coderen van zelfontwikkelde software nemen programmeurs graag hun toevlucht tot open source bibliotheken en modules. De praktische voordelen liggen voor de hand: als je het wiel niet steeds opnieuw hoeft uit te vinden, profiteer je van deze technologieboost, snelle ontwikkeling, lagere ontwikkelingskosten, meer transparantie door open broncode, en hogere interoperabiliteit door open normen en interfaces.

Er wordt ook vaak gezegd dat code uit open source een hoge mate van veiligheid biedt omdat de code door vele gebruikers is gevalideerd en de zwerm intelligentie van de open source gemeenschap een snelle en efficiënte bug fixing mogelijk maakt.

In de praktijk moet dit vertrouwen nu gedifferentieerd en kritisch worden beoordeeld. Het ernstigste voorbeeld is het zero-day beveiligingslek Log4Shell in de veelgebruikte logbibliotheek Log4J voor Java-toepassingen, dat in november 2021 werd ontdekt. U hebt wellicht gehoord van het rode waarschuwingsniveau dat door het Duitse Bundesamt für Informationssicherheit (BSI) is afgegeven voor Log4Shell. De Log4J-bibliotheek, verspreid als een betrouwbaar werkende quasi-standaard via de Apache Foundation, heeft zich sinds 2013 in veel systemen gevestigd - waaronder bekende webdiensten zoals Amazon AWS.

De complexiteit van deze goed ontwikkelde en ook onderhouden bibliotheken biedt impliciet krachtige functionaliteiten waarvan een importerende ontwikkelaar zich in zijn eigen gecombineerde nieuwe ontwikkeling vaak niet bewust is, maar die door aanvallers kunnen worden uitgebuit.

Een andere onveiligheidsfactor van open source componenten zijn de zogenaamde supply chain attacks, d.w.z. bedoelde ingebouwde kwetsbaarheden door kwaadwillenden die zich voordoen als deel van de open source gemeenschap en helpen bij de ontwikkeling van de code. Een dergelijke kwetsbaarheid is voor hackers een uiterst efficiënte manier om een groot aantal downstream gebruikersorganisaties aan te vallen. Geen wonder dus dat deze aanvalsvector snel groeit: een Sonatype-studie stelde een toename van 650% vast bij een vergelijking tussen 2020 en 2021.

Planning en precoding

Zowel de ontwikkeling van nieuwe code als het hergebruik van code vereist de toepassing van veilige codeerprincipes - ongeacht of de code wordt geschreven voor interne software of voor externe producten en diensten. Dit vereist de evaluatie van de organisatiespecifieke verwachtingen en de definitie van erkende principes vooraf. Bovendien wordt bij aanbevolen acties voor planning en precoding rekening gehouden met bekende gangbare en historische codeerpraktijken en fouten die tot kwetsbaarheden kunnen leiden.

De configuratie van ontwikkeltools, zoals regelgebaseerde in geïntegreerde ontwikkelingsomgevingen (IDE), moet de creatie van veilige code afdwingen. Van cruciaal belang is de kwalificatie van ontwikkelaars en hun bekendheid met veilige architecturen en programmeringsnormen. De opname van deskundigheid op het gebied van informatiebeveiliging in het ontwikkelingsteam is vanzelfsprekend.

Tijdens het coderingsproces

Tijdens het codeerproces spelen codeerpraktijken en gestructureerde programmeertechnieken een primaire rol, waarbij rekening wordt gehouden met de specifieke use case en de beveiligingsbehoeften daarvan. Onveilige ontwerptechnieken - bijvoorbeeld harde wachtwoorden - moeten consequent worden verboden. Code moet adequaat worden gedocumenteerd en beoordeeld om beveiligingsfouten zo goed mogelijk te elimineren. Codecontrole moet zowel tijdens als na de ontwikkeling plaatsvinden, via statische applicatiebeveiligingstests (SAST) of iets dergelijks. Statische testmethoden ondersteunen de "shift left"-aanpak ("test vroeg en vaak") door in de levenscyclus naar links te schuiven door zichtbare code vroeg te testen op regelconformiteit.

Dit maakt vroege identificatie mogelijk van besmette code, verbindingen met bestanden of specifieke objectklassen, of hiaten op applicatieniveau die kunnen worden misbruikt voor onopgemerkte interactie met programma's van derden als exploiteerbare kwetsbaarheden. Voordat de software in gebruik wordt genomen, vereist controle 8.28 een evaluatie van aanvalsoppervlakken en de toepassing van het beginsel van de laagste rechten. De uitgevoerde analyse van de meest voorkomende programmeerfouten en de documentatie van hun correctie moeten worden geëvalueerd.

Verificatie en onderhoud

Ook nadat de software live is gegaan, blijft het onderwerp veilige codering relevant. Dit omvat zowel veilige updates als controles op bekende kwetsbaarheden in de eigen code. Bovendien moeten fouten en vermoedelijke aanvallen worden gedocumenteerd, zodat noodzakelijke aanpassingen snel kunnen worden doorgevoerd. In ieder geval moet ongeoorloofde toegang tot de broncode op betrouwbare wijze worden voorkomen door geschikte hulpmiddelen.

Open broncode

Op het gebied van verificatie en onderhoud bevat maatregel 8.28 bovendien expliciete instructies voor het gebruik van externe hulpmiddelen en bibliotheken, zoals openbronsoftware. Deze codecomponenten moeten worden beheerd, bijgewerkt en bijgehouden in inventarissen. Dit kan bijvoorbeeld via een Software Bill of Material (SBOM). Een SBOM is een formele, gestructureerde registratie van de pakketten en bibliotheken van software en hun onderlinge relaties en binnen de toeleveringsketen, met name om hergebruikte code en open source componenten bij te houden. De SBOM ondersteunt de onderhoudbaarheid van software en gerichte beveiligingsupdates.

Conclusie

Veilige code is een elementaire basis om potentiële aanvallen een halt toe te roepen. De nieuwe Control 8.28 houdt rekening met dit lang gekoesterde inzicht en verhoogt de sleutelrol van veilige codering in haar belang voor informatiebeveiliging. Aangezien de maatregel echter een groot aantal gedetailleerde aanbevelingen voor maatregelen omvat en technisch veeleisend is, zal de uitvoering ervan een relatief grote inspanning vergen - hiermee moet reeds in de planningsfase rekening worden gehouden.

Met de professionele visie van onze ervaren auditors ondersteunen wij u bij de conforme uitvoering van de maatregel. Met onze audit- en certificeringsexpertise van meer dan 35 jaar zijn wij uw ideale aanspreekpartner en helpen wij u graag bij het thema informatiebeveiliging en certificering volgens de ISO/IEC 27001:2022-normen.

Herziening van ISO 27001: wat betekent de update voor uw certificering?

ISO/IEC 27001:2022 is gepubliceerd op 25 oktober 2022. Dit resulteert in de volgende deadlines en tijdschema's voor gebruikers om over te stappen:

ISO/IEC 27001:2022 certificeringsgereedheid

• Verwacht vanaf mei 2023 (afhankelijk van de Duitse accreditatie-instelling GmbH (DAkkS)).

Laatste datum voor initiële/hercertificeringsaudits volgens de "oude" ISO 27001:2013

• Na 31 oktober 2023 zal DQS alleen nog initiële en hercertificeringsaudits uitvoeren volgens de nieuwe norm ISO/IEC 27001:2022.

Overgang van alle bestaande certificaten van de "oude" ISO/IEC 27001:2013 naar de nieuwe ISO/IEC 27001:2022

• Er is een overgangsperiode van drie jaar vanaf 31 oktober 2022
• Certificaten die zijn afgegeven volgens ISO/IEC 27001:2013 of DIN EN ISO/IEC 27001:2017 blijven geldig tot uiterlijk 31 oktober 2025, of moeten op die datum worden ingetrokken.

DQS: Simply leveraging Quality.

Door de overgangstermijnen hebben bedrijven voldoende tijd om hun ISMS aan te passen aan de nieuwe eisen en te laten certificeren. De duur en de inspanningen van het hele veranderingsproces mogen echter niet onderschat worden - zeker als u niet over voldoende gespecialiseerd personeel beschikt. Als u het zekere voor het onzekere wilt nemen, moet u de kwestie eerder vroeger dan later aanpakken en zo nodig een beroep doen op ervaren specialisten.

Als audit- en certificeringsdeskundigen met meer dan 35 jaar expertise ondersteunen wij u graag bij de evaluatie van uw huidige status, eventueel als onderdeel van een delta-audit. Ontdek van onze talrijke ervaren auditors de belangrijkste veranderingen en hun relevantie voor uw organisatie. Samen bespreken we uw verbeterpotentieel en ondersteunen we u tot u uw nieuwe certificaat ontvangt. Profiteer van onze competentie in informatiebeveiliging! Wij horen graag van u.