ISO 27001 – Bilaga A.14: Systemförvärv, utveckling och underhåll

Vad är syftet med bilaga A.14.1?

Bilaga A.14.1 handlar om säkerhetskrav för informationssystem. Målet i detta bilaga A-område är att säkerställa att informationssäkerhet är en integrerad del av informationssystem över hela livscykeln. Detta inkluderar även kraven på informationssystem som tillhandahåller tjänster över publika nät.

ISO 27001:2013 tar upp livscykeln genom A.14.1.1 till A.14.1.3 och det är en viktig del av ledningssystemet för informationssäkerhet (ISMS), särskilt om du vill uppnå ISO 27001-certifiering.

A.14.1.1 Analys och specifikation av krav på informationssäkerhet

Informationssäkerhetsrelaterade krav måste inkluderas i alla krav på nya informationssystem eller förbättringar av befintliga informationssystem. Detta kan ske vid sidan av A.6.1.5 som en del av informationssäkerheten i projekt och bör ta hänsyn till värdet av den information som riskerar att vara i linje med informationsklassificeringssystemet i A.8.2.1.

I varje ny systemutveckling eller förändring av befintliga system är det viktigt att förstå vilka affärskrav som finns för säkerhetskontroller genom att göra en riskbedömning. Detta bör göras innan man väljer eller påbörjar utvecklingen av en lösning. Säkerhetsöverväganden bör ske från tidigast möjliga tillfälle för att säkerställa att de korrekta kraven identifieras innan lösningsvalet påbörjas.

Säkerhetskraven bör dokumenteras och överenskommas så att de kan refereras till när lösningen upphandlas eller utvecklas. Det är inte bra att välja eller utveckla en lösning och sedan bedöma nivån på säkerhetskapaciteten i efterhand. Detta leder ofta till högre risker och kostnader och kan också orsaka problem i tillämplig lagstiftning som GDPR som uppmuntrar en säker designfilosofi och tekniker som Data Protection Privacy Impact Assessments (DPIA). Det finns också många webbplatser som förespråkar säker utvecklingsmetoder och viktiga principer för övervägande, såsom de som förespråkas av National Cyber ​​Security Center (NCSC). ISO 27002 inkluderar även implementeringsvägledning. Alla principer som följs bör dokumenteras.

Revisorn kommer att se till att säkerhet övervägs i alla skeden av ett projekts livscykel, för ett nytt system eller ändringar av ett befintligt system. De förväntar sig också att se övervägande för konfidentialitet, integritet och tillgänglighet åtminstone innan urvals- eller utvecklingsprocessen påbörjas.

A.14.1.2 Säkra applikationstjänster på publika nätverk

Informationen som är involverad i applikationstjänster som passerar över offentliga nätverk måste skyddas från bedräglig verksamhet, avtalskonflikter och obehörigt avslöjande och modifiering. För tjänster som tillhandahålls över ett offentligt nätverk, som internet, är det viktigt att förstå risknivåerna och affärskraven för att skydda information. Återigen är det viktigt att tänka på sekretess, integritet och tillgänglighet.

När finansiella transaktioner eller känslig personlig information ingår i tjänsten är det särskilt viktigt att tänka på säkerheten för att minimera risken för bedräglig verksamhet där GDPR-krav för kryptering och andra skyddsåtgärder behöver vara minimikraven. När de väl är i drift är det viktigt att säkerställa att sådana tjänster ständigt övervakas för attacker eller oönskad aktivitet. Revisorn förväntar sig att se övervägandet om "hur säkra" applikationstjänster över publika nät måste vara, med beslut baserade på riskbedömning och andra lagar, regulatoriska och kontraktuella krav.

A.14.1.3 Skydda applikationstjänstertransaktioner

Information som är inblandad i applikationstjänsttransaktioner måste skyddas för att förhindra ofullständig överföring, feldirigering, obehörig ändring av meddelanden, obehörigt avslöjande, otillåten meddelandeduplicering eller uppspelning. Ytterligare skydd kommer sannolikt att säkra applikationstjänsttransaktioner (inte nödvändigtvis bara finansiella transaktioner). Dessa kan inkludera; Användning av elektroniska signaturer, Användning av kryptering; och Användning av säkra protokoll. Det kommer sannolikt också att krävas löpande övervakning av sådana transaktioner så nära realtid som möjligt.

Vad är syftet med bilaga A.14.2?

Bilaga A.14.2 handlar om säkerhet i utvecklings- och stödprocesser. Målet i detta bilaga A-område är att säkerställa att informationssäkerhet utformas och implementeras inom informationssystemens utvecklingslivscykel.

A.14.2.1 Säker utvecklingspolicy

Regler för utveckling av mjukvara och system bör fastställas och tillämpas på utvecklingen inom organisationen. En säker utvecklingspolicy används för att säkerställa att utvecklingsmiljöer i sig är säkra och att processerna för att utveckla och implementera system och systemförändringar uppmuntrar användningen av säker kodning och utvecklingsmetoder.

Sådana policyer kommer att inkludera att visa hur säkerhet måste beaktas i alla stadier av utvecklingens livscykel från design till liveimplementering. Specifika kodspråk och utvecklingsverktyg har olika sårbarheter och kräver olika ”härdningstekniker” i enlighet med detta och det är viktigt att dessa identifieras och kommer överens och utvecklare görs medvetna om sitt ansvar att följa dem.

Kompatibla policyer kommer att ta itu med säkerhetskontrollpunkter under utveckling; säkra förråd; säkerhet i versionskontroll; kunskap om applikationssäkerhet; och utvecklarnas förmåga att undvika sårbarheter och sedan hitta och åtgärda dem när de uppstår. Revisorn kommer att titta här för att se att säkerhetsöverväganden är lämpliga för risknivån för de system som utvecklas eller förändras och att de som utvecklar förstår behovet av att inkludera säkerhetsöverväganden under hela utvecklingens livscykel. Stark initial screening vid anställning av dessa färdigheter, inlife management och utbildning av resurser är avgörande och praxis som parprogrammering, peer reviews och oberoende kvalitetssäkring, kodgranskning och testning är alla positiva egenskaper.

A.14.2.2 Kontrollprocedurer för systemändringar

Ändringar av system inom utvecklingslivscykeln måste kontrolleras genom användning av formella ändringskontrollprocedurer. Systemförändringskontrollprocedurer bör integreras med, anpassas till och stödja operativ förändringskontroll. Formella ändringshanteringsprocedurer är utformade för att minska risken för oavsiktlig eller avsiktlig utveckling av sårbarheter som kan göra att system äventyras när ändringarna har satts i drift. För systemändringskontroll är det viktigt att systemägaren förstår vilka ändringar som görs i deras system, varför och av vem. Det är deras ansvar att se till att deras system inte äventyras genom dålig eller skadlig utveckling.

De bör därför vara delaktiga i fastställandet av reglerna för godkännande och pre-live testing och kontroll. Revisionsloggar krävs för att ge bevis på korrekt användning av ändringsprocedurer. ISO 27002 dokumenterar många aspekter av förändringskontroll som bör inkluderas, allt från enkel dokumentation av ändringarna till övervägande av tiden för implementering för att undvika negativa affärseffekter. Denna kontroll liksom andra i A.14 överensstämmer också med dokumenterade procedurer i A.12.1.2.

A.14.2.3 Teknisk granskning av applikationer efter operativa plattformsändringar

När operativa plattformar ändras måste affärskritiska applikationer granskas och testas för att säkerställa att det inte finns någon negativ inverkan på organisationens verksamhet eller säkerhet. När operativsystemsplattformar ändras är det vanligt att vissa applikationer kan ha kompatibilitetsproblem. Det är därför viktigt att testa operativsystemändringar i en utvecklings- eller testmiljö där kritiska affärsapplikationer kan kontrolleras för kompatibilitet med det ändrade operativsystemet. Rutiner för kontroll och testning av ändringar av operativsystem bör följa standardkontroll för ändringshantering.

A.14.2.4 Restriktioner för ändringar av programvarupaket

Ändringar av mjukvarupaket måste avskräckas, begränsas till nödvändiga ändringar och alla ändringar bör kontrolleras strikt. Leverantörslevererade mjukvarupaket är designade för massmarknaden och är egentligen inte designade för organisationer som gör sina egna ändringar av dem. Faktum är att för det mesta är möjligheten att göra sådana ändringar låst av leverantören och anpassning begränsad till inom paketet. När programvara med öppen källkod används är det mycket mer sannolikt att förändringar kan göras av organisationen, men detta bör begränsas och kontrolleras för att säkerställa att de ändringar som görs inte har en negativ inverkan på den interna integriteten eller säkerheten hos programvara.

A.14.2.5 Säkra systemtekniska principer

Principer för att konstruera säkra system måste upprättas, dokumenteras, underhållas och tillämpas på alla insatser för implementering av informationssystem. Säkra mjukvarutekniska principer finns på både allmänna nivåer och specifika för utvecklingsplattformar och kodningsspråk. Varhelst utveckling genomförs bör överväganden för val och tillämpning av sådana principer övervägas, bedömas, formellt dokumenteras och föreskrivas. Revisorn kommer att vilja se att användningen av systemtekniska principer, som med många kontroller, övervägs mot de identifierade risknivåerna och kommer att leta efter bevis som stödjer de val som gjorts.

A.14.2.6 Säker utvecklingsmiljö

Organisationer måste etablera och på lämpligt sätt skydda säkra utvecklingsmiljöer för systemutveckling och integrationsinsatser som täcker hela systemutvecklingens livscykel. Utvecklingsmiljöer måste skyddas för att säkerställa skadlig eller oavsiktlig utveckling och uppdatering av kod som kan skapa sårbarheter eller äventyra konfidentialitet, integritet och tillgänglighet. Skyddskrav bör fastställas utifrån riskbedömning, affärskrav och andra interna och externa krav, inklusive lagstiftning, förordningar, avtal eller policyer. I synnerhet om någon form av livedata används i utvecklingsmiljöer måste den skyddas och kontrolleras särskilt.

A.14.2.7 Utlagd utveckling

Organisationen måste övervaka och övervaka aktiviteten för outsourcad systemutveckling. Där system- och mjukvaruutveckling helt eller delvis läggs ut på externa parter ska säkerhetskraven anges i avtal eller bifogat avtal. Det är här bilaga A 15.1 är viktig att ha korrekt samt A.13.2.4 för tystnadsplikt och konfidentialitet.

Det är också viktigt att övervaka och följa utvecklingen för att säkerställa att organisationsstandarder och krav på säkerhet inom system uppnås. Beroende på hur inbäddade outsourcingpartners är inom organisationen, särskilt om personalen är placerad i organisationens lokaler, är det viktigt att inkludera sin personal i säkerhetsmedvetandeutbildning och medvetenhetsprogram och kommunikation. Det är avgörande att säkerställa att outsourcapartnerns interna säkerhetspraxis, t.ex. personalkontroll, åtminstone uppfyller säkerhetskrav som är relevanta för risknivåerna relaterade till utvecklingen de kommer att arbeta med.

Revisorn kommer att se till att där outsourcing används, det finns bevis på due diligence före, under och efter att uppdraget med outsourcingpartnern har genomförts och inkluderar hänsyn till informationssäkerhetsbestämmelser.

A.14.2.8 Systemsäkerhetstestning

Testning av säkerhetsfunktionalitet behöver utföras under utvecklingen. Specifik testning av säkerhetsfunktionalitet för varje utveckling måste utföras och signeras av en lämplig myndighet med säkerhetskompetens och säkerhetsansvar. Förväntade utfall av säkerhetstestning bör dokumenteras innan testning påbörjas och bör baseras på affärsmässiga krav på säkerhet. Revisorn kommer att vilja se att det finns bevis för att säkerhetsspecifika tester har utförts i varje utveckling som är säkerhetsrelevant.

A.14.2.9 Systemacceptanstestning

Program för acceptanstestning och relaterade kriterier måste fastställas för nya informationssystem, uppgraderingar och nya versioner. För acceptanstestning bör testerna och kriterierna för att visa ett framgångsrikt test utformas och utvecklas utifrån affärskrav innan tester genomförs. Acceptanstestning bör även omfatta säkerhetstestning. Revisorn kommer att leta efter bevis som visar att kriterier och metoder för acceptanstestning har utformats i enlighet med affärskrav och inkluderar bestämmelser för säkerhetsacceptanstestning.

Vad är syftet med bilaga A.14.3?

Bilaga A.14.3 handlar om testdata. Syftet med detta område i bilaga A är att säkerställa skyddet av data som används för testning.

A.14.3.1 Skydd av testdata

Testdata måste väljas noggrant, skyddas och kontrolleras. Testdata bör helst skapas i en generisk form utan någon relation till live systemdata. Det är dock känt att livedata ofta måste användas för att utföra korrekta tester. Där livedata används för testning bör det vara; Anonymiserad så långt det är möjligt; Noggrant utvalda och säkrade för testperioden; Säkert raderad när testningen är klar. Användning av livedata måste förauktoriseras, loggas och övervakas. Revisorn förväntar sig att se robusta rutiner på plats för att skydda data som används i testmiljöer, särskilt om detta är helt eller delvis livedata.

Mer hjälp om ISO 27001-kraven och bilaga A-kontroller finns i ISMS.online Virtual Coach som kompletterar våra ramverk, verktyg och policyinnehåll.