ISO 27001 – Bijlage A.14: Systeemaankoop, ontwikkeling en onderhoud

Wat is het doel van bijlage A.14.1?

Bijlage A.14.1 gaat over beveiligingseisen van informatiesystemen. De doelstelling op dit gebied van bijlage A is ervoor te zorgen dat informatiebeveiliging een integraal onderdeel is van informatiesystemen gedurende de gehele levenscyclus. Hieronder vallen ook de eisen voor informatiesystemen die diensten verlenen via openbare netwerken.

ISO 27001:2013 behandelt de levenscyclus van A.14.1.1 tot A.14.1.3 en is een belangrijk onderdeel van het informatiebeveiligingsbeheersysteem (ISMS), vooral als u de ISO 27001-certificering wilt behalen.

A.14.1.1 Analyse en specificatie van informatiebeveiligingsvereisten

Informatiebeveiligingsgerelateerde eisen moeten worden opgenomen in alle eisen voor nieuwe informatiesystemen of verbeteringen aan bestaande informatiesystemen. Dit kan naast A.6.1.5 gebeuren als onderdeel van de informatiebeveiliging in projecten en er moet rekening worden gehouden met de waarde van de informatie die gevaar loopt, wat zou kunnen aansluiten bij het informatieclassificatieschema in A.8.2.1.

Bij elke nieuwe systeemontwikkeling of wijziging van bestaande systemen is het belangrijk om te begrijpen wat de zakelijke vereisten voor beveiligingscontroles zijn door een risicobeoordeling uit te voeren. Dit dient te gebeuren voorafgaand aan de selectie of aanvang van de ontwikkeling van een oplossing. Beveiligingsoverwegingen moeten zo vroeg mogelijk plaatsvinden om ervoor te zorgen dat de juiste vereisten worden geïdentificeerd voordat de selectie van oplossingen begint.

De beveiligingsvereisten moeten worden gedocumenteerd en overeengekomen, zodat er naar kan worden verwezen wanneer de oplossing wordt aangeschaft of ontwikkeld. Het is geen goede gewoonte om een ​​oplossing te selecteren of te ontwikkelen en daarna het beveiligingsniveau te beoordelen. Dit leidt vaak tot hogere risico's en kosten en kan ook problemen veroorzaken in de toepasselijke wetgeving, zoals de AVG, die een 'secure by design'-filosofie en technieken zoals Data Protection Privacy Impact Assessments (DPIA) aanmoedigt. Er zijn ook talloze websites die pleiten voor veilige ontwikkelingspraktijken en belangrijke principes die in overweging moeten worden genomen, zoals die bepleit door het National Cyber ​​Security Center (NCSC). ISO 27002 bevat ook implementatierichtlijnen. Elk van de principes die worden gevolgd, moet worden gedocumenteerd.

De auditor zal erop toezien dat er in alle fasen van de levenscyclus van een project rekening wordt gehouden met beveiliging, voor een nieuw systeem of voor wijzigingen aan een bestaand systeem. Ze verwachten ook dat er minimaal rekening wordt gehouden met vertrouwelijkheid, integriteit en beschikbaarheid voordat het selectie- of ontwikkelingsproces begint.

A.14.1.2 Applicatieservices op openbare netwerken beveiligen

De informatie die betrokken is bij applicatiediensten die via openbare netwerken gaan, moet worden beschermd tegen frauduleuze activiteiten, contractgeschillen en ongeoorloofde openbaarmaking en wijziging. Voor diensten die via een openbaar netwerk, zoals internet, worden geleverd, is het belangrijk om de risiconiveaus en de zakelijke vereisten voor het beschermen van informatie te begrijpen. Nogmaals, het is belangrijk om rekening te houden met vertrouwelijkheid, integriteit en beschikbaarheid.

Wanneer financiële transacties of gevoelige persoonlijke informatie deel uitmaken van de service, is het vooral belangrijk om rekening te houden met beveiliging om het risico op frauduleuze activiteiten te minimaliseren, waarbij AVG-vereisten voor encryptie en andere waarborgen de minimumvereisten moeten zijn. Eenmaal operationeel is het belangrijk ervoor te zorgen dat dergelijke diensten voortdurend worden gecontroleerd op aanvallen of ongewenste activiteiten. De auditor zal verwachten dat er aandacht wordt besteed aan “hoe veilig” applicatiediensten via openbare netwerken moeten zijn, waarbij beslissingen worden genomen op basis van risicobeoordeling en andere wettelijke, regelgevende en contractuele vereisten.

A.14.1.3 Transacties van applicatieservices beschermen

Informatie die betrokken is bij transacties met applicatiediensten moet worden beschermd om onvolledige verzending, verkeerde routering, ongeoorloofde wijziging van berichten, ongeoorloofde openbaarmaking, ongeoorloofde verdubbeling of herhaling van berichten te voorkomen. Extra bescherming zal waarschijnlijk de transacties van applicatieservices beveiligen (niet noodzakelijkerwijs alleen financiële transacties). Deze kunnen omvatten; Gebruik van elektronische handtekeningen, Gebruik van encryptie; en Gebruik van veilige protocollen. Het is waarschijnlijk ook vereist dat dergelijke transacties voortdurend in realtime worden gemonitord.

Wat is het doel van bijlage A.14.2?

Bijlage A.14.2 gaat over de beveiliging van ontwikkelings- en ondersteuningsprocessen. Het doel op dit gebied van bijlage A is ervoor te zorgen dat informatiebeveiliging wordt ontworpen en geïmplementeerd binnen de ontwikkelingslevenscyclus van informatiesystemen.

A.14.2.1 Beleid voor veilige ontwikkeling

Regels voor de ontwikkeling van software en systemen moeten worden vastgesteld en toegepast op ontwikkelingen binnen de organisatie. Een veilig ontwikkelingsbeleid wordt gebruikt om ervoor te zorgen dat ontwikkelomgevingen zelf veilig zijn en dat de processen voor het ontwikkelen en implementeren van systemen en systeemveranderingen het gebruik van veilige codering en ontwikkelingspraktijken aanmoedigen.

Dergelijk beleid zal onder meer laten zien hoe met beveiliging rekening moet worden gehouden in alle stadia van de ontwikkelingslevenscyclus, van ontwerp tot en met live-implementatie. Specifieke codeertalen en ontwikkelingstools hebben verschillende kwetsbaarheden en vereisen dienovereenkomstig verschillende “verhardings”-technieken. Het is belangrijk dat deze worden geïdentificeerd en overeengekomen en dat ontwikkelaars bewust worden gemaakt van hun verantwoordelijkheden om ze te volgen.

Conform beleid zal tijdens de ontwikkeling veiligheidscontrolepunten aanpakken; beveiligde opslagplaatsen; beveiliging in versiebeheer; kennis van applicatiebeveiliging; en het vermogen van ontwikkelaars om kwetsbaarheden te vermijden, en deze vervolgens te vinden en op te lossen wanneer ze zich voordoen. De auditor zal hier kijken om te zien of beveiligingsoverwegingen passend zijn voor het risiconiveau voor de systemen die worden ontwikkeld of gewijzigd, en dat degenen die de ontwikkeling uitvoeren de noodzaak begrijpen om gedurende de gehele ontwikkelingslevenscyclus beveiligingsoverwegingen mee te nemen. Een sterke initiële screening bij het aannemen van deze vaardigheden, inlife management en training van middelen is essentieel en praktijken als pair programming, peer reviews en onafhankelijke kwaliteitsborging, code reviews en testen zijn allemaal positieve eigenschappen.

A.14.2.2 Procedures voor controle op systeemwijzigingen

Wijzigingen aan systemen binnen de ontwikkelingslevenscyclus moeten worden beheerst door het gebruik van formele wijzigingscontroleprocedures. Procedures voor systeemwijzigingscontrole moeten integreren met, afgestemd zijn op en ondersteuning bieden voor operationele wijzigingscontrole. Formele procedures voor wijzigingsbeheer zijn ontworpen om het risico te verminderen van de onbedoelde of opzettelijke ontwikkeling van kwetsbaarheden waardoor systemen in gevaar kunnen worden gebracht zodra de wijzigingen live zijn gezet. Voor het beheer van systeemwijzigingen is het belangrijk dat de systeemeigenaar begrijpt welke wijzigingen in zijn systeem worden aangebracht, waarom en door wie. Het is hun verantwoordelijkheid om ervoor te zorgen dat hun systemen niet worden aangetast door slechte of kwaadwillige ontwikkeling.

Zij moeten daarom worden betrokken bij het vaststellen van de regels voor autorisatie en pre-live testen en controleren. Auditlogboeken zijn vereist om bewijs te leveren van het juiste gebruik van wijzigingsprocedures. ISO 27002 documenteert vele aspecten van wijzigingsbeheer die moeten worden opgenomen, variërend van eenvoudige documentatie van de wijzigingen tot het overwegen van de implementatietijd om negatieve gevolgen voor het bedrijf te voorkomen. Deze controle, net als andere in A.14, komt ook overeen met de gedocumenteerde procedures in A.12.1.2.

A.14.2.3 Technische beoordeling van applicaties na wijzigingen in het operationele platform

Wanneer besturingsplatforms worden gewijzigd, moeten bedrijfskritische applicaties worden beoordeeld en getest om er zeker van te zijn dat er geen nadelige gevolgen zijn voor de bedrijfsvoering of de beveiliging van de organisatie. Wanneer besturingssysteemplatforms worden gewijzigd, is het gebruikelijk dat sommige applicaties compatibiliteitsproblemen hebben. Het is daarom belangrijk om wijzigingen in het besturingssysteem te testen in een ontwikkel- of testomgeving waar kritische bedrijfsapplicaties kunnen worden gecontroleerd op compatibiliteit met het gewijzigde besturingssysteem. Procedures voor het controleren en testen van wijzigingen in het besturingssysteem moeten de standaard wijzigingsbeheercontrole volgen.

A.14.2.4 Beperkingen op wijzigingen aan softwarepakketten

Wijzigingen aan softwarepakketten moeten worden ontmoedigd, beperkt tot noodzakelijke wijzigingen en alle wijzigingen moeten strikt worden gecontroleerd. Door leveranciers geleverde softwarepakketten zijn ontworpen voor de massamarkt en zijn niet echt ontworpen voor organisaties die er zelf wijzigingen in aanbrengen. In feite is de mogelijkheid om dergelijke wijzigingen aan te brengen meestal uitgesloten door de leverancier en is aanpassing beperkt tot binnen het pakket. Wanneer open source-software wordt gebruikt, is de kans veel groter dat er wijzigingen kunnen worden aangebracht door de organisatie. Dit moet echter worden beperkt en gecontroleerd om ervoor te zorgen dat de aangebrachte wijzigingen geen negatieve gevolgen hebben voor de interne integriteit of veiligheid van de organisatie. software.

A.14.2.5 Principes van veilige systeemtechniek

Principes voor het ontwerpen van veilige systemen moeten worden vastgesteld, gedocumenteerd, onderhouden en toegepast bij alle inspanningen om informatiesystemen te implementeren. Principes voor veilige software-engineering bestaan ​​zowel op algemeen niveau als specifiek voor ontwikkelingsplatforms en codeertalen. Overal waar ontwikkeling plaatsvindt, moet aandacht voor de selectie en toepassing van dergelijke principes worden overwogen, beoordeeld, formeel gedocumenteerd en verplicht gesteld. De auditor zal willen zien dat, zoals bij veel controles, het gebruik van system engineering-principes wordt afgewogen tegen de geïdentificeerde risiconiveaus en zal op zoek gaan naar bewijsmateriaal ter ondersteuning van de gemaakte keuzes.

A.14.2.6 Veilige ontwikkelomgeving

Organisaties moeten veilige ontwikkelomgevingen opzetten en op passende wijze beschermen voor inspanningen op het gebied van systeemontwikkeling en -integratie die de gehele levenscyclus van systeemontwikkeling bestrijken. Ontwikkelomgevingen moeten worden beschermd om de kwaadwillige of onbedoelde ontwikkeling en update van code te garanderen die kwetsbaarheden kan veroorzaken of de vertrouwelijkheid, integriteit en beschikbaarheid in gevaar kan brengen. Beschermingsvereisten moeten worden bepaald op basis van risicobeoordeling, zakelijke vereisten en andere interne en externe vereisten, waaronder wetgeving, regelgeving, contractuele overeenkomsten of beleid. Als er in ontwikkelomgevingen enige vorm van live data wordt gebruikt, moet deze vooral worden beschermd en gecontroleerd.

A.14.2.7 Uitbestede ontwikkeling

De organisatie moet toezicht houden op de activiteiten van uitbestede systeemontwikkeling. Bij het geheel of gedeeltelijk uitbesteden van systeem- en softwareontwikkeling aan externe partijen dienen de beveiligingseisen vastgelegd te worden in een contract of bijgevoegde overeenkomst. Dit is waar het belangrijk is dat bijlage A 15.1 correct is, evenals A.13.2.4 voor geheimhouding en vertrouwelijkheid.

Het is ook belangrijk om de ontwikkeling te begeleiden en te monitoren om er zeker van te zijn dat de organisatorische normen en vereisten voor beveiliging binnen systemen worden bereikt. Afhankelijk van hoe ingebed de outsourcingpartners zijn binnen de organisatie, vooral als het personeel zich in de organisatiegebouwen bevindt, is het belangrijk om hun personeel te betrekken bij beveiligingsbewustzijnstrainingen, bewustmakingsprogramma's en -communicatie. Het is van cruciaal belang om ervoor te zorgen dat de interne beveiligingspraktijken van de uitbestede partner, bijvoorbeeld het doorlichten van personeel, op zijn minst voldoen aan de zekerheidsvereisten die relevant zijn voor de risiconiveaus die verband houden met de ontwikkelingen waaraan zij zullen werken.

De auditor zal erop toezien dat wanneer uitbesteding wordt toegepast, er sprake is van due diligence vóór, tijdens en nadat de opdracht van de uitbestede partner is uitgevoerd en dat er rekening wordt gehouden met bepalingen op het gebied van informatiebeveiliging.

A.14.2.8 Testen van systeembeveiliging

Tijdens de ontwikkeling moet de beveiligingsfunctionaliteit worden getest. Specifieke tests van de beveiligingsfunctionaliteit voor elke ontwikkeling moeten worden uitgevoerd en ondertekend door een bevoegde autoriteit met beveiligingscompetentie en verantwoordelijkheid. De verwachte resultaten van beveiligingstests moeten worden gedocumenteerd voordat het testen begint en moeten gebaseerd zijn op zakelijke vereisten voor beveiliging. De auditor zal willen zien dat er bewijs is dat beveiligingsspecifieke tests zijn uitgevoerd bij elke ontwikkeling die relevant is voor de beveiliging.

A.14.2.9 Systeemacceptatietests

Voor nieuwe informatiesystemen, upgrades en nieuwe versies moeten acceptatietestprogramma's en gerelateerde criteria worden opgesteld. Voor acceptatietesten moeten de tests en de criteria voor het aantonen van een succesvolle test worden ontworpen en ontwikkeld op basis van zakelijke vereisten voordat de tests worden uitgevoerd. Acceptatietests moeten ook beveiligingstests omvatten. De auditor zal op zoek gaan naar bewijs waaruit blijkt dat de criteria en methoden voor acceptatietests zijn ontworpen in overeenstemming met de zakelijke vereisten en dat er voorzieningen zijn opgenomen voor acceptatietests op het gebied van beveiliging.

Wat is het doel van bijlage A.14.3?

Bijlage A.14.3 gaat over testgegevens. Het doel op dit gebied van bijlage A is het waarborgen van de bescherming van gegevens die voor tests worden gebruikt.

A.14.3.1 Bescherming van testgegevens

Testgegevens moeten zorgvuldig worden geselecteerd, beschermd en gecontroleerd. Testgegevens moeten idealiter in een generieke vorm worden aangemaakt, zonder enige relatie met live systeemgegevens. Er wordt echter erkend dat vaak live gegevens moeten worden gebruikt om nauwkeurige tests uit te voeren. Wanneer live gegevens worden gebruikt voor het testen, zou dit het geval moeten zijn; Voor zover mogelijk geanonimiseerd; Zorgvuldig geselecteerd en beveiligd voor de testperiode; Veilig verwijderd wanneer het testen is voltooid. Het gebruik van livegegevens moet vooraf worden geautoriseerd, geregistreerd en gecontroleerd. De auditor verwacht robuuste procedures te zien om de gegevens die in testomgevingen worden gebruikt te beschermen, vooral als dit geheel of gedeeltelijk live gegevens zijn.

Meer hulp over de ISO 27001-vereisten en bijlage A-controles kunt u vinden in de ISMS.online Virtual Coach, die een aanvulling vormt op onze raamwerken, hulpmiddelen en beleidsinhoud.