9.6 KiB
#iso27002/2022/NL
Standard: ISO 27002:2022 NL
+------------------------+----------------------------------------------------+----------------------+----------------------------------------------------------------+---------------------+ | Type | Informatie- | Cybersecurity- | Operationele | Beveiligings- | | | | | | | | beheersmaatregel | beveiligings- | concepten | capaciteiten | domeinen | | | | | | | | | eigenschappen | | | | +========================+====================================================+======================+================================================================+=====================+ | #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Toepassingsbeveili- ging #Systeem-_en_net- werkbeveiliging | #Bescherming | +------------------------+----------------------------------------------------+----------------------+----------------------------------------------------------------+---------------------+
Beheersmaatregel
Er behoren principes voor veilig coderen te worden toegepast op softwareontwikkeling.
Doel
Waarborgen dat veilige software wordt geschreven waardoor het aantal potentiële informatiebeveiligingskwetsbaarheden in de software wordt beperkt.
Richtlijn
Algemeen
De organisatie behoort organisatiebrede processen op te stellen om te voorzien in goede governance voor veilig coderenr behoort een minimale nullijn wat betreft beveiliging te worden vastgesteld en toegepastn aanvulling hierop behoren dergelijke processen en governance te worden uitgebreid tot softwarecomponenten van derden en opensourcesoftware.
De organisatie behoort te monitoren op dreigingen in de echte wereld en actueel advies en actuele informatie over kwetsbaarheden in software als richtlijn om de principes voor veilig coderen van de organisatie door middel van continue verbetering en voortdurend leren te sturenit kan bijdragen aan het garanderen dat er doeltreffende praktijken voor veilig coderen worden geïmplementeerd als tegenhanger tegen het snel veranderende dreigingslandschap.
Planning en voorafgaand aan het coderen
Principes voor veilig coderen behoren zowel voor nieuwe ontwikkelingen als bij hergebruikscenario's te worden gebruikteze principes behoren te worden toegepast op ontwikkelingsactiviteiten binnen de organisatie en voor producten en diensten die de organisatie aan anderen leverte planning en de voorwaarden voorafgaand aan het coderen behoren het volgende te omvatten:
a) organisatiespecifieke verwachtingen en goedgekeurde principes voor veilig coderen die zowel voor interne als voor uitbestede codeontwikkelingen behoren te worden gebruikt;
b) gebruikelijke en historische codeerpraktijken en -gebreken die tot kwetsbaarheden in de informatiebeveiliging leiden;
c) ontwikkelinstrumenten, zoals geïntegreerde ontwikkelomgevingen (IDE's), configureren om te helpen het maken van veilige code af te dwingen;
d) richtlijnen volgen die door de aanbieders van ontwikkelinstrumenten en uitvoeringsomgevingen worden gegeven, al naargelang de situatie;
e) onderhoud en gebruik van actuele ontwikkelinstrumenten (bijvompilers);
f) de kwalificatie van ontwikkelaars voor het schrijven van veilige code;
g) veilig ontwerp en veilige architectuur, met inbegrip van het opstellen van dreigingsmodellen;
h) normen voor veilig coderen en waar relevant het gebruik ervan verplicht stellen;
i) het gebruik van beheerste omgevingen voor ontwikkeling.
Tijdens het coderen
Overwegingen tijdens het coderen behoren te zijn:
a) veilige coderingspraktijken die specifiek zijn voor de programmeertalen en -technieken die worden gebruikt;
b) veilige programmeertechnieken gebruiken zoals 'pair programming' (programmeren in duo's), 'refactoring' (code herstructureren), 'peer review' (beoordeling door collega's), beveiligingsiteraties en testgestuurde ontwikkeling;
c) gestructureerde programmeertechnieken gebruiken;
d) code documenteren en programmeerfouten verwijderen die anders misbruik van kwetsbaarheden in de informatiebeveiliging mogelijk kunnen maken;
e) het gebruik van onveilige ontwerptechnieken (bijvoorbeeld het gebruik van hardgecodeerde wachtwoorden, niet-goedgekeurde codesamples en niet-geauthenticeerde webdiensten) verbieden.
Er behoort tijdens en na het ontwikkelen te worden getest (zie 8.29). Met procedures voor het statisch testen van de beveiliging van toepassingen (SAST) kunnen beveiligingslekken in software worden geïdentificeerd.
Alvorens software operationeel te maken, behoort:
a) het aanvalsoppervlak en het beginsel van het 'least privilege' (minste voorrechten) te worden geëvalueerd;
b) een analyse te worden uitgevoerd op de meest voorkomende programmeerfouten en te worden gedocumenteerd dat deze zijn hersteld.
Beoordeling en onderhoud
Nadat de code operationeel is gemaakt:
a) behoren updates op beveiligde wijze te worden verpakt en ingezet;
b) behoren gemelde kwetsbaarheden in de informatiebeveiliging te worden opgepakt (zie 8.8)
c) behoren logbestanden te worden bijgehouden van fouten en vermeende aanvallen en behoren de logbestanden regelmatig te worden beoordeeld om de code zo nodig aan te passen;
d) behoort de broncode te worden beschermd tegen toegang en manipulatie door onbevoegden (bijvoor gebruik te maken van configuratiebeheerinstrumenten, die meestal functies als toegangsbeveiliging en versiebeheer bieden).
Als er gebruikgemaakt wordt van externe instrumenten en bibliotheken, behoort de organisatie na te denken over:
a) het bewerkstelligen dat externe bibliotheken worden beheerd (bijvoor een inventarislijst bij te houden van bibliotheken die worden gebruikt en de desbetreffende versies) en regelmatig worden bijgewerkt met releasecycli;
b) het selecteren, autoriseren en hergebruiken van goed gecontroleerde componenten, met name authenticatie- en cryptografische componenten;
c) de licentie, beveiliging en historie van externe componenten;
d) het bewerkstelligen dat software kan worden onderhouden, wordt getraceerd en afkomstig is van beproefde, gerenommeerde bronnen;
e) het op voldoende lange termijn beschikbaar zijn van ontwikkelmiddelen en artefacten.
Als het nodig is een softwarepakket te wijzigen, behoren de volgende punten in overweging te worden genomen:
a) het risico dat ingebouwde beheersmaatregelen en integriteitsprocessen gecompromitteerd raken;
b) of het al dan niet nodig is toestemming van de leverancier te verkrijgen;
c) de mogelijkheid om de vereiste wijzigingen van de aanbieder als standaard programma-updates te verkrijgen;
d) de impact als de organisatie verantwoordelijk wordt gehouden voor het toekomstig onderhoud van de software als gevolg van de veranderingen;
e) compatibiliteit met andere software die in gebruik is.
Overige informatie
Een leidend principe is bewerkstelligen dat beveiligingsrelevante code wordt aangeroepen wanneer dat nodig is en deze bestand is tegen manipulatierogramma's die worden geïnstalleerd op basis van gecompileerde binaire code hebben deze eigenschappen ook, maar alleen voor gegevens die binnen de toepassing worden bewaardoor geïnterpreteerde talen werkt het concept alleen wanneer de code wordt uitgevoerd op een server waartoe de gebruikers en de processen die er gebruik van maken verder geen toegang hebben en de gegevens ervan in een op vergelijkbare wijze beschermde database worden bewaarde geïnterpreteerde code kan bijvoorbeeld worden uitgevoerd op een clouddienst waar beheerdersrechten vereist zijn voor toegang tot de code op zichergelijke toegang door een beheerder behoort te worden beschermd door beveiligingsmechanismen zoals just-in- timebeheerprincipes en krachtige authenticatiendien de eigenaar van een toepassing op afstand via de server toegang kan maken tot scripts, kan een aanvaller dat in principe ookebservers behoren dusdanig te worden geconfigureerd dat het doorzoeken van directory's in dergelijke gevallen niet mogelijk is.
Het is het beste om er bij het ontwerpen van een toepassingscode vanuit te gaan dat deze code altijd het doelwit is van aanvallen, als gevolg van fouten of door kwaadwillige opzetovendien kunnen kritische toepassingen zo worden ontworpen dat ze bestand zijn tegen interne fouten of storingeno kan bijvoorbeeld de output van een complex algoritme worden gecontroleerd om te garanderen dat deze binnen veilige grenzen ligt voordat de gegevens worden gebruikt in een toepassing zoals een veiligheids- of financieel kritische toepassinge code die de grenscontroles uitvoert, is eenvoudig en daarom veel gemakkelijker om de juistheid ermee aan te tonen.
Bepaalde internettoepassingen zijn gevoelig voor allerlei kwetsbaarheden die worden veroorzaakt door slecht ontwerp en slecht coderen, zoals injectieaanvallen op databases en 'cross-site scripting'- aanvallenij deze aanvallen kunnen verzoeken worden gemanipuleerd om misbruik te maken van de webserverfunctionaliteit.
Meer informatie over het evalueren van ICT-beveiliging is te vinden in de ISO/IEC 15408-reeks.