Oops! An Error Occurred
Back-end server is faulty or not available
ISO/IEC 27001:2022 Q&A
De nieuwe standaard voor informatiebeveiliging: 38 vragen en antwoorden
Alles wat u moet weten over "The New Kid on the Block" voor informatiebeveiliging.
- Wat houden de nieuwe controles in?
- Wanneer moeten we overstappen op de nieuwe standaard?
- Waar kan ik een lijst vinden van oude en nieuwe overeenkomsten?
- ... en nog 35 andere!
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.
Oops! An Error Occurred
Back-end server is faulty or not available
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.
Aanbevolen voor u
Detectie en preventie in het beheer van informatiebeveiliging
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.
Oops! An Error Occurred
Back-end server is faulty or not available
Oops! An Error Occurred
Back-end server is faulty or not available
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.
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.
Vragen?
Neem contact met ons op!
Zonder verplichting en gratis.
