ISO 27001 – Bylae A.14: Stelselverkryging, ontwikkeling en instandhouding

Wat is die doel van Aanhangsel A.14.1?

Bylae A.14.1 handel oor sekuriteitsvereistes van inligtingstelsels. Die doelwit in hierdie Bylae A-area is om te verseker dat inligtingsekuriteit 'n integrale deel van inligtingstelsels oor die hele lewensiklus is. Dit sluit ook die vereistes vir inligtingstelsels in wat dienste oor openbare netwerke verskaf.

ISO 27001:2013 spreek die lewensiklus deur A.14.1.1 tot A.14.1.3 aan en dit is 'n belangrike deel van die inligtingsekuriteitbestuurstelsel (ISMS), veral as jy ISO 27001-sertifisering wil behaal.

A.14.1.1 Ontleding en spesifikasie van inligtingsekuriteitvereistes

Inligtingsekuriteitverwante vereistes moet ingesluit word in enige vereistes vir nuwe inligtingstelsels of verbeterings aan bestaande inligtingstelsels. Dit kan saam met A.6.1.5 gebeur as deel van die inligtingsekuriteit in projekte en moet die waarde van die inligting wat in gevaar is, in ag neem wat kan ooreenstem met die inligtingsklassifikasieskema in A.8.2.1.

In enige nuwe stelselontwikkeling of verandering aan bestaande stelsels, is dit belangrik om te verstaan ​​wat die besigheidsvereistes vir sekuriteitskontroles is deur 'n risikobepaling te doen. Dit moet gedoen word voor die keuse van of 'n aanvang met die ontwikkeling van 'n oplossing. Sekuriteitsoorwegings moet van die vroegste moontlike geleentheid gebeur om te verseker dat die korrekte vereistes geïdentifiseer word voordat oplossingseleksie begin.

Die sekuriteitsvereistes moet gedokumenteer en ooreengekom word sodat daar na verwys kan word soos die oplossing verkry of ontwikkel word. Dit is nie goeie praktyk om 'n oplossing te kies of te ontwikkel en dan die vlak van sekuriteitsvermoë daarna te assesseer nie. Dit lei dikwels tot hoër risiko's en koste en kan ook probleme veroorsaak in toepaslike wetgewing soos GDPR wat 'n veilige deur ontwerp filosofie en tegnieke soos Data Protection Privaatheidsimpak Assesserings (DPIA) aanmoedig. Daar is ook talle webwerwe wat veilige ontwikkelingspraktyke en sleutelbeginsels vir oorweging voorstaan, soos dié wat deur die Nasionale Kuberveiligheidsentrum (NCSC) voorgestaan ​​word. ISO 27002 sluit ook implementeringsleiding in. Enige van die beginsels wat gevolg word, moet gedokumenteer word.

Die ouditeur sal kyk om te sien dat sekuriteit in alle stadiums van 'n projeklewensiklus oorweeg word, vir 'n nuwe stelsel of veranderinge aan 'n bestaande stelsel. Hulle sal ook verwag om oorweging vir vertroulikheid, integriteit en beskikbaarheid ten minste te sien voordat die keurings- of ontwikkelingsproses begin.

A.14.1.2 Beveiliging van toepassingsdienste op openbare netwerke

Die inligting betrokke by toepassingsdienste wat oor openbare netwerke gaan, moet beskerm word teen bedrieglike aktiwiteite, kontrakgeskil en ongemagtigde openbaarmaking en wysiging. Vir dienste wat oor 'n openbare netwerk gelewer word, soos die internet, is dit belangrik om die betrokke risikovlakke en die besigheidsvereistes vir die beskerming van inligting te verstaan. Weereens is dit belangrik om vertroulikheid, integriteit en beskikbaarheid in ag te neem.

Wanneer finansiële transaksies of sensitiewe persoonlike inligting deel van die diens vorm, is dit veral belangrik om sekuriteit te oorweeg om die risiko van bedrieglike aktiwiteite te minimaliseer waar GDPR-vereistes vir enkripsie en ander beveiligingsmaatreëls die minimum vereistes moet wees. Sodra dit in werking is, is dit belangrik om te verseker dat sulke dienste voortdurend gemonitor word vir aanval of ongewenste aktiwiteit. Die ouditeur sal verwag om die oorweging te sien vir "hoe veilig" toepassingsdienste oor openbare netwerke moet wees, met besluite gebaseer op risikobepaling en ander wetlike, regulatoriese en kontraktuele vereistes.

A.14.1.3 Beskerming van toepassingsdienstetransaksies

Inligting betrokke by aansoekdienstransaksies moet beskerm word om onvolledige versending, verkeerde roetering, ongemagtigde boodskapverandering, ongemagtigde openbaarmaking, ongemagtigde boodskapduplisering of herhaling te voorkom. Bykomende beskerming sal waarskynlik toepassingsdienstransaksies beveilig (nie noodwendig net finansiële transaksies nie). Dit kan insluit; Gebruik van elektroniese handtekeninge, Gebruik van enkripsie; en Gebruik van veilige protokolle. Die deurlopende monitering van sulke transaksies in so naby aan intydse wyse sal waarskynlik ook nodig wees.

Wat is die doel van Aanhangsel A.14.2?

Bylae A.14.2 handel oor sekuriteit in ontwikkeling en ondersteuningsprosesse. Die doelwit in hierdie Bylae A-area is om te verseker dat inligtingsekuriteit binne die ontwikkelingslewensiklus van inligtingstelsels ontwerp en geïmplementeer word.

A.14.2.1 Beleid vir veilige ontwikkeling

Reëls vir die ontwikkeling van sagteware en stelsels moet vasgestel word en toegepas word op ontwikkelings binne die organisasie. 'n Veilige ontwikkelingsbeleid word gebruik om te verseker dat ontwikkelingsomgewings self veilig is en dat die prosesse vir die ontwikkeling en implementering van stelsels en stelselveranderings die gebruik van veilige kodering en ontwikkelingspraktyke aanmoedig.

Sulke beleide sal insluit om te wys hoe sekuriteit in alle stadiums van die ontwikkelingslewensiklus van ontwerp tot lewendige implementering oorweeg moet word. Spesifieke koderingstale en ontwikkelingsinstrumente het verskillende kwesbaarhede en vereis dienooreenkomstig verskillende “verhardingstegnieke” en dit is belangrik dat dit geïdentifiseer en ooreengekom word en ontwikkelaars bewus gemaak word van hul verantwoordelikhede om dit te volg.

Voldoende beleide sal sekuriteitskontrolepunte tydens ontwikkeling aanspreek; veilige bewaarplekke; sekuriteit in weergawebeheer; toepassing sekuriteit kennis; en ontwikkelaars se vermoë om kwesbaarhede te vermy en dit dan te vind en reg te stel wanneer dit voorkom. Die ouditeur sal hier kyk om te sien dat sekuriteitsoorwegings gepas is vir die vlak van risiko vir die stelsels wat ontwikkel of verander word en dat diegene wat die ontwikkeling doen die behoefte verstaan ​​om sekuriteitsoorwegings regdeur die ontwikkelingslewensiklus in te sluit. Sterk aanvanklike keuring in die aanstelling van hierdie vaardighede, lewensbestuur en opleiding van hulpbronne is noodsaaklik en praktyke soos paarprogrammering, ewekniebeoordelings en onafhanklike gehalteversekering, kodebeoordelings en -toetsing is almal positiewe eienskappe.

A.14.2.2 Stelselveranderingsbeheerprosedures

Veranderinge aan stelsels binne die ontwikkelingslewensiklus moet beheer word deur die gebruik van formele veranderingsbeheerprosedures. Stelselveranderingsbeheerprosedures moet met operasionele veranderingsbeheer integreer, in lyn wees met en ondersteun. Formele veranderingsbestuursprosedures is ontwerp om die risiko van toevallige of doelbewuste ontwikkeling van kwesbaarhede te verminder wat kan toelaat dat stelsels gekompromitteer word sodra die veranderinge in werking gestel is. Vir stelselveranderingsbeheer is dit belangrik dat die stelseleienaar verstaan ​​watter veranderinge aan hul stelsel aangebring word, hoekom en deur wie. Dit is hul verantwoordelikheid om te verseker dat hul stelsels nie deur swak of kwaadwillige ontwikkeling gekompromitteer word nie.

Hulle moet dus betrokke wees by die opstel van die reëls vir magtiging en voor-lewendige toetsing en kontrolering. Ouditlogboeke word vereis om bewys te lewer van die korrekte gebruik van veranderingsprosedures. ISO 27002 dokumenteer baie aspekte van veranderingsbeheer wat ingesluit moet word, wat wissel van eenvoudige dokumentasie van die veranderinge tot oorweging van die tyd vir ontplooiing om negatiewe besigheidsimpak te vermy. Hierdie beheer, soos ander in A.14, strook ook met gedokumenteerde prosedures in A.12.1.2.

A.14.2.3 Tegniese oorsig van toepassings na bedryfsplatformveranderings

Wanneer bedryfsplatforms verander word, moet besigheidskritiese toepassings hersien en getoets word om te verseker dat daar geen nadelige impak op die organisatoriese bedrywighede of sekuriteit is nie. Wanneer bedryfstelselplatforms verander word, is dit algemeen dat sommige toepassings versoenbaarheidsprobleme kan hê. Dit is dus belangrik om bedryfstelselveranderinge te toets in 'n ontwikkeling- of toetsomgewing waar kritieke besigheidstoepassings nagegaan kan word vir versoenbaarheid met die veranderde bedryfstelsel. Prosedures vir beheer en toetsing van bedryfstelselveranderinge moet standaard veranderingsbestuurbeheer volg.

A.14.2.4 Beperkings op veranderinge aan sagtewarepakkette

Wysigings aan sagtewarepakkette moet ontmoedig word, beperk word tot die nodige veranderinge en alle veranderinge moet streng beheer word. Sagtewarepakkette wat deur verskaffers verskaf word, is ontwerp vir die massamark en is nie regtig ontwerp vir organisasies wat hul eie veranderinge daaraan maak nie. In werklikheid word die vermoë om sulke veranderinge aan te bring meestal deur die verskaffer uitgesluit en aanpassing beperk tot binne die pakket. Waar oopbronsagteware gebruik word, is dit baie meer waarskynlik dat veranderinge deur die organisasie aangebring kan word, maar dit moet beperk en beheer word om te verseker dat die veranderinge wat gemaak word nie 'n nadelige impak op die interne integriteit of sekuriteit van die sagteware.

A.14.2.5 Veilige Stelselingenieursbeginsels

Beginsels vir die ingenieurswese van veilige stelsels moet vasgestel, gedokumenteer, in stand gehou en toegepas word op enige inligtingstelselimplementeringspogings. Veilige sagteware-ingenieursbeginsels bestaan ​​op beide algemene vlakke en spesifiek vir ontwikkelingsplatforms en koderingstale. Waar ontwikkeling ook al uitgevoer word, moet oorweging vir die keuse en toepassing van sulke beginsels oorweeg, beoordeel, formeel gedokumenteer en gemandatiseer word. Die ouditeur sal wil sien dat soos met baie beheermaatreëls, die gebruik van stelselingenieursbeginsels oorweeg word teen die risikovlakke wat geïdentifiseer is en sal op soek wees na bewyse om die keuses wat gemaak is, te ondersteun.

A.14.2.6 Veilige Ontwikkelingsomgewing

Organisasies moet veilige ontwikkelingsomgewings daarstel en toepaslik beskerm vir stelselontwikkeling en integrasiepogings wat die hele stelselontwikkelingslewensiklus dek. Ontwikkelingsomgewings moet beskerm word om die kwaadwillige of toevallige ontwikkeling en opdatering van kode te verseker wat kwesbaarhede kan skep of vertroulikheid, integriteit en beskikbaarheid kan benadeel. Beskermingsvereistes moet bepaal word uit risikobepaling, besigheidsvereistes en ander interne en eksterne vereistes, insluitend wetgewing, regulasies, kontraktuele ooreenkomste of beleide. In die besonder, as enige vorm van lewendige data in ontwikkelingsomgewings gebruik word, moet dit veral beskerm en beheer word.

A.14.2.7 Uitgekontrakteerde Ontwikkeling

Die organisasie moet toesig hou oor en monitor die aktiwiteit van uitgekontrakteerde stelselontwikkeling. Waar stelsel- en sagteware-ontwikkeling óf geheel óf gedeeltelik aan eksterne partye uitgekontrakteer word, moet die sekuriteitsvereistes in 'n kontrak of aangehegte ooreenkoms gespesifiseer word. Dit is waar Bylae A 15.1 belangrik is om korrek te hê asook A.13.2.4 vir nie-openbaarmaking en vertroulikheid.

Dit is ook belangrik om toesig te hou oor en ontwikkeling te monitor om versekering te verkry dat organisatoriese standaarde en vereistes vir sekuriteit binne stelsels bereik word. Afhangende van hoe ingebedde uitkontrakteringsvennote binne die organisasie is, veral as personeel op organisatoriese persele geleë is, is dit belangrik om hul personeel by sekuriteitsbewusmakingsopleiding en -bewusmakingsprogramme en kommunikasie in te sluit. Dit is van kritieke belang om te verseker dat die interne sekuriteitspraktyke van die uitkontrakteringsvennoot, bv. personeelkontrole, ten minste voldoen aan versekeringsvereistes wat relevant is tot die risikovlakke wat verband hou met die ontwikkelings waaraan hulle sal werk.

Die ouditeur sal kyk om te sien dat waar uitkontraktering gebruik word, daar bewyse is van omsigtigheidsondersoek voor, tydens en na die aanstelling van die uitkontrakteringsvennoot uitgevoer is en sluit oorweging vir inligtingsekuriteitsbepalings in.

A.14.2.8 Stelselveiligheidstoetsing

Toetsing van sekuriteitsfunksies moet tydens ontwikkeling uitgevoer word. Spesifieke toetsing van sekuriteitsfunksies vir enige ontwikkeling moet uitgevoer en afgeteken word deur 'n toepaslike owerheid met sekuriteitsbevoegdheid en -verantwoordelikheid. Sekuriteitstoets verwagte uitkomste moet gedokumenteer word voordat toetsing begin en moet gebaseer wees op besigheidsvereistes vir sekuriteit. Die ouditeur sal wil sien dat daar bewyse is dat sekuriteitspesifieke toetsing uitgevoer is in enige ontwikkeling wat sekuriteitsrelevant is.

A.14.2.9 Stelselaanvaardingstoetsing

Aanvaardingstoetsprogramme en verwante kriteria moet vasgestel word vir nuwe inligtingstelsels, opgraderings en nuwe weergawes. Vir aanvaardingstoetsing moet die toetse en die kriteria om 'n suksesvolle toets te demonstreer ontwerp en ontwikkel word op grond van besigheidsvereistes voordat toetse uitgevoer word. Aanvaardingstoetsing moet ook sekuriteitstoetse insluit. Die ouditeur sal op soek wees na bewyse wat toon dat aanvaardingstoetskriteria en -metodes volgens besigheidsvereistes ontwerp is en bepalings vir sekuriteitsaanvaardingstoetsing insluit.

Wat is die doel van Aanhangsel A.14.3?

Bylae A.14.3 handel oor toetsdata. Die doel in hierdie Bylae A-area is om die beskerming van data wat vir toetsing gebruik word, te verseker.

A.14.3.1 Beskerming van toetsdata

Toetsdata moet versigtig gekies, beskerm en beheer word. Toetsdata moet ideaal in 'n generiese vorm geskep word met geen verband met lewendige stelseldata nie. Dit word egter erken dat regstreekse data dikwels gebruik moet word om akkurate toetsing uit te voer. Waar lewendige data vir toetsing gebruik word, moet dit wees; So ver moontlik geanonimiseer; Noukeurig gekies en beveilig vir die tydperk van toetsing; Veilig uitgevee wanneer die toets voltooi is. Gebruik van lewendige data moet vooraf goedgekeur, aangeteken en gemonitor word. Die ouditeur sal verwag om robuuste prosedures in plek te sien om data te beskerm wat in toetsomgewings gebruik word, veral as dit heeltemal of gedeeltelik lewendige data is.

Meer hulp oor die ISO 27001-vereistes en Bylae A-kontroles kan gevind word in die ISMS.online Virtual Coach wat ons raamwerke, gereedskap en beleidsinhoud aanvul.