ISO 27001 – Bilag A.14: Systemanskaffelse, udvikling og vedligeholdelse

Hvad er formålet med bilag A.14.1?

Bilag A.14.1 handler om sikkerhedskrav til informationssystemer. Målet i dette bilag A-område er at sikre, at informationssikkerhed er en integreret del af informationssystemer på tværs af hele livscyklussen. Dette omfatter også kravene til informationssystemer, der leverer tjenester over offentlige netværk.

ISO 27001:2013 omhandler livscyklussen gennem A.14.1.1 til A.14.1.3, og det er en vigtig del af informationssikkerhedsstyringssystemet (ISMS), især hvis du gerne vil opnå ISO 27001-certificering.

A.14.1.1 Analyse og specifikation af krav til informationssikkerhed

Informationssikkerhedsrelaterede krav skal medtages i alle krav til nye informationssystemer eller forbedringer af eksisterende informationssystemer. Dette kan ske sideløbende med A.6.1.5 som en del af informationssikkerheden i projekter og bør tage højde for værdien af ​​den information, der er i fare, som kunne være i overensstemmelse med informationsklassifikationsordningen i A.8.2.1.

I enhver ny systemudvikling eller ændring af eksisterende systemer er det vigtigt at forstå, hvad forretningskravene til sikkerhedskontrol er ved at lave en risikovurdering. Dette bør gøres før valget af eller påbegyndelse af udviklingen af ​​en løsning. Sikkerhedshensyn bør ske fra den tidligst mulige mulighed for at sikre, at de korrekte krav er identificeret, før løsningsvalget påbegyndes.

Sikkerhedskravene bør dokumenteres og aftales, så de kan refereres i takt med, at løsningen indkøbes eller udvikles. Det er ikke god praksis at vælge eller udvikle en løsning og derefter vurdere niveauet af sikkerhedskapacitet bagefter. Dette fører ofte til højere risici og omkostninger og kan også forårsage problemer i gældende lovgivning såsom GDPR, som tilskynder til en sikker by design-filosofi og teknikker såsom Data Protection Privacy Impact Assessments (DPIA). Der er også adskillige websteder, der går ind for sikker udviklingspraksis og nøgleprincipper til overvejelse, såsom dem, der anbefales af National Cyber ​​Security Center (NCSC). ISO 27002 omfatter også implementeringsvejledning. Enhver af de principper, der følges, skal dokumenteres.

Revisor vil se på, at sikkerhed overvejes i alle faser af et projekts livscyklus, for et nyt system eller ændringer af et eksisterende system. De vil også forvente, at der tages hensyn til fortrolighed, integritet og tilgængelighed som et minimum, inden udvælgelsen eller udviklingsprocessen påbegyndes.

A.14.1.2 Sikring af applikationstjenester på offentlige netværk

De oplysninger, der er involveret i applikationstjenester, der passerer over offentlige netværk, skal beskyttes mod svigagtig aktivitet, kontraktstridigheder og uautoriseret offentliggørelse og ændring. For tjenester, der leveres over et offentligt netværk, såsom internettet, er det vigtigt at forstå de involverede risikoniveauer og forretningskravene til beskyttelse af information. Endnu en gang er det vigtigt at overveje fortrolighed, integritet og tilgængelighed.

Når finansielle transaktioner eller følsomme personoplysninger indgår i tjenesten, er det særligt vigtigt at overveje sikkerheden for at minimere risikoen for svigagtig aktivitet, hvor GDPR-krav til kryptering og andre sikkerhedsforanstaltninger skal være minimumskravene. Når de er operationelle, er det vigtigt at sikre, at sådanne tjenester konstant overvåges for angreb eller uønsket aktivitet. Revisor vil forvente at se hensynet til "hvor sikre" applikationstjenester over offentlige netværk skal være, med beslutninger baseret på risikovurdering og andre lovmæssige, regulatoriske og kontraktmæssige krav.

A.14.1.3 Beskyttelse af Application Services-transaktioner

Oplysninger involveret i applikationstjenestetransaktioner skal beskyttes for at forhindre ufuldstændig transmission, fejldirigering, uautoriseret meddelelsesændring, uautoriseret videregivelse, uautoriseret meddelelsesduplikering eller genafspilning. Yderligere beskyttelse vil sandsynligvis sikre applikationstjenestetransaktioner (ikke nødvendigvis kun finansielle transaktioner). Disse kan omfatte; Brug af elektroniske signaturer, Brug af kryptering; og brug af sikre protokoller. Der vil sandsynligvis også være behov for løbende overvågning af sådanne transaktioner så tæt på realtid.

Hvad er formålet med bilag A.14.2?

Bilag A.14.2 handler om sikkerhed i udviklings- og supportprocesser. Formålet med dette bilag A-område er at sikre, at informationssikkerheden er designet og implementeret inden for informationssystemernes udviklingslivscyklus.

A.14.2.1 Politik for sikker udvikling

Regler for udvikling af software og systemer bør etableres og anvendes på udviklingen i organisationen. En sikker udviklingspolitik anvendes til at sikre, at udviklingsmiljøer i sig selv er sikre, og at processerne for udvikling og implementering af systemer og systemændringer tilskynder til brug af sikker kodning og udviklingspraksis.

Sådanne politikker vil omfatte at vise, hvordan sikkerhed skal overvejes på alle stadier af udviklingens livscyklus fra design til live implementering. Specifikke kodesprog og udviklingsværktøjer har forskellige sårbarheder og kræver forskellige "hærdningsteknikker" i overensstemmelse hermed, og det er vigtigt, at disse identificeres og aftales, og udviklere gøres opmærksomme på deres ansvar for at følge dem.

Overensstemmende politikker vil adressere sikkerhedskontrolpunkter under udvikling; sikre depoter; sikkerhed i versionskontrol; viden om applikationssikkerhed; og udvikleres evne til at undgå sårbarheder og derefter finde og rette dem, når de opstår. Revisoren vil kigge her for at se, at sikkerhedshensyn er passende i forhold til risikoniveauet for de systemer, der udvikles eller ændres, og at dem, der udfører udviklingen, forstår behovet for at medtage sikkerhedsovervejelser gennem hele udviklingens livscyklus. Stærk indledende screening ved ansættelse af disse færdigheder, inlife-ledelse og træning af ressourcer er afgørende, og praksis som parprogrammering, peer reviews og uafhængig kvalitetssikring, kodegennemgang og test er alle positive egenskaber.

A.14.2.2 Systemændringskontrolprocedurer

Ændringer af systemer inden for udviklingens livscyklus skal styres ved brug af formelle ændringskontrolprocedurer. Systemændringskontrolprocedurer bør integreres med, tilpasses til og understøtte operationel ændringskontrol. Formelle ændringsstyringsprocedurer er designet til at reducere risikoen for utilsigtet eller bevidst udvikling af sårbarheder, der kan gøre det muligt at kompromittere systemer, når ændringerne er sat live. For systemændringskontrol er det vigtigt, at systemejeren forstår, hvilke ændringer der foretages i deres system, hvorfor og af hvem. Det er deres ansvar at sikre, at deres systemer ikke kompromitteres gennem dårlig eller ondsindet udvikling.

De bør derfor inddrages i fastsættelsen af ​​reglerne for godkendelse og pre-live test og kontrol. Der kræves revisionslogfiler for at give bevis for den korrekte brug af ændringsprocedurer. ISO 27002 dokumenterer mange aspekter af ændringskontrol, der bør inkluderes, lige fra simpel dokumentation af ændringerne til overvejelse af tidspunktet for implementering for at undgå negativ forretningspåvirkning. Denne kontrol er ligesom andre i A.14 også på linje med dokumenterede procedurer i A.12.1.2.

A.14.2.3 Teknisk gennemgang af applikationer efter ændringer af driftsplatformen

Når driftsplatforme ændres, skal forretningskritiske applikationer gennemgås og testes for at sikre, at der ikke er nogen negativ indvirkning på den organisatoriske drift eller sikkerhed. Når operativsystemplatforme ændres, er det almindeligt, at nogle applikationer kan have kompatibilitetsproblemer. Det er derfor vigtigt at teste operativsystemændringer i et udviklings- eller testmiljø, hvor kritiske forretningsapplikationer kan kontrolleres for kompatibilitet med det ændrede operativsystem. Procedurer for kontrol og test af operativsystemændringer bør følge standard ændringsstyringskontrol.

A.14.2.4 Begrænsninger for ændringer af softwarepakker

Ændringer af softwarepakker skal frarådes, begrænses til nødvendige ændringer, og alle ændringer bør kontrolleres strengt. Leverandørleverede softwarepakker er designet til massemarkedet og er egentlig ikke designet til organisationer, der foretager deres egne ændringer i dem. Faktisk er muligheden for at foretage sådanne ændringer for det meste spærret af leverandøren og tilpasning begrænset til inden for pakken. Hvor open source-software bruges, er det langt mere sandsynligt, at ændringer kan foretages af organisationen, men dette bør begrænses og kontrolleres for at sikre, at de foretagne ændringer ikke har en negativ indvirkning på den interne integritet eller sikkerhed af software.

A.14.2.5 Principper for sikker systemkonstruktion

Principper for konstruktion af sikre systemer skal etableres, dokumenteres, vedligeholdes og anvendes på enhver indsats for implementering af informationssystem. Sikker software engineering principper findes på både generelle niveauer og specifikke for udviklingsplatforme og kodningssprog. Uanset hvor der udføres udvikling, bør overvejelser om udvælgelse og anvendelse af sådanne principper overvejes, vurderes, formelt dokumenteres og pålægges mandat. Revisoren vil gerne se, at brugen af ​​systemtekniske principper, som med mange kontroller, vurderes i forhold til de identificerede risikoniveauer og vil lede efter beviser til støtte for de trufne valg.

A.14.2.6 Sikkert udviklingsmiljø

Organisationer skal etablere og passende beskytte sikre udviklingsmiljøer til systemudviklings- og integrationsindsats, der dækker hele systemudviklingens livscyklus. Udviklingsmiljøer skal beskyttes for at sikre ondsindet eller utilsigtet udvikling og opdatering af kode, der kan skabe sårbarheder eller kompromittere fortrolighed, integritet og tilgængelighed. Beskyttelseskrav bør bestemmes ud fra risikovurdering, forretningskrav og andre interne og eksterne krav, herunder lovgivning, regulering, kontraktlige aftaler eller politikker. Især hvis nogen form for live-data bruges i udviklingsmiljøer, skal de beskyttes og kontrolleres særligt.

A.14.2.7 Udliciteret udvikling

Organisationen skal overvåge og overvåge aktiviteten af ​​outsourcet systemudvikling. Hvor system- og softwareudvikling outsources enten helt eller delvist til eksterne parter, skal sikkerhedskravene specificeres i en kontrakt eller vedhæftet aftale. Det er her, bilag A 15.1 er vigtigt at have korrekt samt A.13.2.4 for hemmeligholdelse og fortrolighed.

Det er også vigtigt at overvåge og overvåge udviklingen for at opnå sikkerhed for, at organisatoriske standarder og krav til sikkerhed i systemer opnås. Afhængigt af hvor integrerede outsource-partnere er i organisationen, især hvis personalet er placeret i organisationens lokaler, er det vigtigt at inkludere deres personale i sikkerhedsbevidsthedstræning og -bevidsthedsprogrammer og kommunikation. Det er afgørende at sikre, at outsourcepartnerens interne sikkerhedspraksis, f.eks. personalekontrol, i det mindste opfylder sikkerhedskrav, der er relevante for de risikoniveauer, der er relateret til den udvikling, de vil arbejde på.

Revisor vil se på, at der, hvor outsourcing anvendes, er dokumentation for due diligence før, under og efter, at outsourcepartnerens engagement er blevet udført, og omfatter hensyn til informationssikkerhedsbestemmelser.

A.14.2.8 Systemsikkerhedstest

Test af sikkerhedsfunktionalitet skal udføres under udvikling. Specifik test af sikkerhedsfunktionalitet for enhver udvikling skal udføres og underskrives af en passende myndighed med sikkerhedskompetence og -ansvar. Sikkerhedstests forventede resultater bør dokumenteres, før testning påbegyndes, og bør være baseret på forretningskrav til sikkerhed. Revisor vil gerne se, at der er dokumentation for, at sikkerhedsspecifik test er blevet udført i enhver udvikling, der er sikkerhedsrelevant.

A.14.2.9 Systemaccepttest

Der skal etableres accepttestprogrammer og relaterede kriterier for nye informationssystemer, opgraderinger og nye versioner. Til accepttest bør testene og kriterierne for at demonstrere en vellykket test designes og udvikles baseret på forretningskrav, før testene udføres. Accepttest bør også omfatte sikkerhedstest. Revisoren vil lede efter beviser, der viser, at kriterier og metoder for accepttestning er designet i overensstemmelse med forretningskrav og omfatter bestemmelser om sikkerhedsaccepttest.

Hvad er formålet med bilag A.14.3?

Bilag A.14.3 handler om testdata. Formålet med dette bilag A-område er at sikre beskyttelsen af ​​data, der anvendes til testning.

A.14.3.1 Beskyttelse af testdata

Testdata skal udvælges omhyggeligt, beskyttes og kontrolleres. Testdata bør ideelt set oprettes i en generisk form uden relation til live systemdata. Det er dog anerkendt, at live-data ofte skal bruges til at udføre nøjagtige tests. Hvor levende data bruges til test, bør det være; Anonymiseret så vidt muligt; Omhyggeligt udvalgt og sikret i testperioden; Slettes sikkert, når testen er færdig. Brug af live data skal forhåndsgodkendes, logges og overvåges. Revisor vil forvente at se robuste procedurer på plads til at beskytte data, der bruges i testmiljøer, især hvis dette er helt eller delvist live-data.

Mere hjælp til ISO 27001-kravene og bilag A-kontroller kan findes i ISMS.online Virtual Coach, som supplerer vores rammer, værktøjer og politikindhold.