ISO 27001 – Vedlegg A.14: Systemanskaffelse, utvikling og vedlikehold

Hva er formålet med vedlegg A.14.1?

Vedlegg A.14.1 handler om sikkerhetskrav til informasjonssystemer. Målet i dette vedlegg A-området er å sikre at informasjonssikkerhet er en integrert del av informasjonssystemer gjennom hele livssyklusen. Dette omfatter også kravene til informasjonssystemer som leverer tjenester over offentlige nett.

ISO 27001:2013 tar for seg livssyklusen gjennom A.14.1.1 til A.14.1.3, og det er en viktig del av styringssystemet for informasjonssikkerhet (ISMS), spesielt hvis du ønsker å oppnå ISO 27001-sertifisering.

A.14.1.1 Analyse og spesifikasjon av krav til informasjonssikkerhet

Informasjonssikkerhetsrelaterte krav må inkluderes i alle krav til nye informasjonssystemer eller forbedringer av eksisterende informasjonssystemer. Dette kan skje ved siden av A.6.1.5 som en del av informasjonssikkerheten i prosjekter og bør ta hensyn til verdien av informasjonen som er i fare, som kan samsvare med informasjonsklassifiseringsordningen i A.8.2.1.

I enhver ny systemutvikling eller endring av eksisterende systemer er det viktig å forstå hva forretningskravene til sikkerhetskontroller er ved å gjøre en risikovurdering. Dette bør gjøres før valg av eller igangsetting av utvikling av en løsning. Sikkerhetshensyn bør skje fra tidligst mulig mulighet for å sikre at de riktige kravene er identifisert før løsningsvalg starter.

Sikkerhetskravene bør dokumenteres og avtales slik at de kan refereres etter hvert som løsningen anskaffes eller utvikles. Det er ikke god praksis å velge eller utvikle en løsning og deretter vurdere sikkerhetsnivået i etterkant. Dette fører ofte til høyere risiko og kostnader og kan også forårsake problemer i gjeldende lovgivning som GDPR som oppmuntrer til en sikker designfilosofi og teknikker som Data Protection Privacy Impact Assessments (DPIA). Det er også mange nettsteder som tar til orde for sikker utviklingspraksis og viktige prinsipper for vurdering, slik som de som forespeiles av National Cyber ​​Security Center (NCSC). ISO 27002 inkluderer også implementeringsveiledning. Alle prinsippene som følges bør dokumenteres.

Revisor vil se etter at sikkerhet vurderes i alle stadier av et prosjekts livssyklus, for et nytt system eller endringer i et eksisterende system. De vil også forvente å se hensyn til konfidensialitet, integritet og tilgjengelighet som et minimum før valg- eller utviklingsprosessen starter.

A.14.1.2 Sikring av applikasjonstjenester på offentlige nettverk

Informasjonen som er involvert i applikasjonstjenester som går over offentlige nettverk, må beskyttes mot uredelig aktivitet, kontraktstvist og uautorisert avsløring og modifikasjon. For tjenester som tilbys over et offentlig nettverk, som internett, er det viktig å forstå risikonivåene og forretningskravene for å beskytte informasjon. Nok en gang er det viktig å vurdere konfidensialitet, integritet og tilgjengelighet.

Når økonomiske transaksjoner eller sensitive personopplysninger utgjør en del av tjenesten, er det spesielt viktig å vurdere sikkerhet for å minimere risikoen for uredelig aktivitet der GDPR-krav til kryptering og andre sikkerhetstiltak må være minimumskravene. Når de er operative, er det viktig å sikre at slike tjenester hele tiden overvåkes for angrep eller uønsket aktivitet. Revisor vil forvente å se hensynet til «hvor sikre» applikasjonstjenester over offentlige nettverk må være, med beslutninger basert på risikovurdering og andre lovmessige, regulatoriske og kontraktsmessige krav.

A.14.1.3 Beskytte applikasjonstjenester-transaksjoner

Informasjon involvert i applikasjonstjenestetransaksjoner må beskyttes for å forhindre ufullstendig overføring, feilruting, uautorisert meldingsendring, uautorisert avsløring, uautorisert meldingsduplisering eller avspilling. Ytterligere beskyttelse vil sannsynligvis sikre applikasjonstjenestetransaksjoner (ikke nødvendigvis bare økonomiske transaksjoner). Disse kan inkludere; Bruk av elektroniske signaturer, Bruk av kryptering; og bruk av sikre protokoller. Den pågående overvåkingen av slike transaksjoner på en så nær sanntids måte vil sannsynligvis også være nødvendig.

Hva er formålet med vedlegg A.14.2?

Vedlegg A.14.2 handler om sikkerhet i utviklings- og støtteprosesser. Målet i dette vedlegg A-området er å sikre at informasjonssikkerhet utformes og implementeres innenfor utviklingslivssyklusen til informasjonssystemene.

A.14.2.1 Sikker utviklingspolitikk

Regler for utvikling av programvare og systemer bør etableres og anvendes på utviklingen i organisasjonen. En sikker utviklingspolicy brukes for å sikre at utviklingsmiljøene i seg selv er sikre og at prosessene for utvikling og implementering av systemer og systemendringer oppmuntrer til bruk av sikker koding og utviklingspraksis.

Slike retningslinjer vil inkludere å vise hvordan sikkerhet må vurderes i alle stadier av utviklingslivssyklusen fra design til live implementering. Spesifikke kodespråk og utviklingsverktøy har ulike sårbarheter og krever forskjellige «herding»-teknikker tilsvarende, og det er viktig at disse identifiseres og avtales og utviklere gjøres oppmerksomme på sitt ansvar for å følge dem.

Overensstemmende retningslinjer vil adressere sikkerhetskontrollpunkter under utvikling; sikre depoter; sikkerhet i versjonskontroll; kunnskap om applikasjonssikkerhet; og utvikleres evne til å unngå sårbarheter, og deretter finne og fikse dem når de oppstår. Revisor vil se her for å se at sikkerhetshensyn er passende for risikonivået for systemene som utvikles eller endres, og at de som utfører utviklingen forstår behovet for å inkludere sikkerhetshensyn gjennom hele utviklingens livssyklus. Sterk innledende screening ved ansettelse av disse ferdighetene, inlife management og opplæring av ressurser er avgjørende, og praksis som parprogrammering, fagfellevurderinger og uavhengig kvalitetssikring, kodevurderinger og testing er alle positive egenskaper.

A.14.2.2 Kontrollprosedyrer for systemendring

Endringer i systemer innenfor utviklingslivssyklusen må kontrolleres ved bruk av formelle endringskontrollprosedyrer. Systemendringskontrollprosedyrer bør integreres med, tilpasses og støtte operasjonell endringskontroll. Formelle prosedyrer for endringsadministrasjon er utformet for å redusere risikoen for utilsiktet eller bevisst utvikling av sårbarheter som kan tillate at systemene kompromitteres når endringene er satt i drift. For systemendringskontroll er det viktig at systemeier forstår hvilke endringer som gjøres i systemet deres, hvorfor og av hvem. Det er deres ansvar å sikre at systemene deres ikke blir kompromittert gjennom dårlig eller ondsinnet utvikling.

De bør derfor være med på å fastsette reglene for autorisasjon og pre-live testing og kontroll. Det kreves revisjonslogger for å gi bevis for riktig bruk av endringsprosedyrer. ISO 27002 dokumenterer mange aspekter ved endringskontroll som bør inkluderes, alt fra enkel dokumentasjon av endringene til vurdering av tidspunktet for distribusjon for å unngå negativ forretningspåvirkning. Denne kontrollen samsvarer som andre i A.14 også med dokumenterte prosedyrer i A.12.1.2.

A.14.2.3 Teknisk gjennomgang av applikasjoner etter endringer i driftsplattformen

Når driftsplattformer endres, må forretningskritiske applikasjoner gjennomgås og testes for å sikre at det ikke er noen negativ innvirkning på organisasjonens drift eller sikkerhet. Når operativsystemplattformer endres, er det vanlig at enkelte applikasjoner kan ha kompatibilitetsproblemer. Det er derfor viktig å teste operativsystemendringer i et utviklings- eller testmiljø der kritiske forretningsapplikasjoner kan sjekkes for kompatibilitet med det endrede operativsystemet. Prosedyrer for kontroll og testing av operativsystemendringer bør følge standard endringsstyringskontroll.

A.14.2.4 Restriksjoner på endringer i programvarepakker

Modifikasjoner av programvarepakker må frarådes, begrenses til nødvendige endringer, og alle endringer bør kontrolleres strengt. Leverandørleverte programvarepakker er designet for massemarkedet og er egentlig ikke designet for organisasjoner som gjør sine egne endringer i dem. Faktisk er det meste av tiden muligheten til å gjøre slike endringer låst av leverandøren og tilpasning begrenset til innenfor pakken. Når åpen kildekode-programvare brukes, er det langt mer sannsynlig at endringer kan gjøres av organisasjonen, men dette bør begrenses og kontrolleres for å sikre at endringene som gjøres ikke har en negativ innvirkning på den interne integriteten eller sikkerheten til organisasjonen. programvare.

A.14.2.5 Sikkert systemtekniske prinsipper

Prinsipper for å konstruere sikre systemer må etableres, dokumenteres, vedlikeholdes og brukes på all implementering av informasjonssystem. Sikker programvareutviklingsprinsipper eksisterer på både generelle nivåer og spesifikke for utviklingsplattformer og kodespråk. Uansett hvor utviklingen gjennomføres, bør hensynet til valg og anvendelse av slike prinsipper vurderes, vurderes, formelt dokumenteres og pålegges. Revisor vil ønske å se at som med mange kontroller, vurderes bruken av systemtekniske prinsipper opp mot de identifiserte risikonivåene og vil lete etter bevis som støtter de valgene som er tatt.

A.14.2.6 Sikkert utviklingsmiljø

Organisasjoner må etablere og på passende måte beskytte sikre utviklingsmiljøer for systemutvikling og integrasjonsarbeid som dekker hele systemutviklingens livssyklus. Utviklingsmiljøer må beskyttes for å sikre ondsinnet eller utilsiktet utvikling og oppdatering av kode som kan skape sårbarheter eller kompromittere konfidensialitet, integritet og tilgjengelighet. Beskyttelseskrav bør bestemmes ut fra risikovurdering, forretningskrav og andre interne og eksterne krav, inkludert lovgivning, forskrifter, kontraktsavtaler eller retningslinjer. Spesielt hvis noen form for live-data brukes i utviklingsmiljøer, må de beskyttes og kontrolleres spesielt.

A.14.2.7 Utkontraktert utvikling

Organisasjonen skal overvåke og overvåke aktiviteten til outsourcet systemutvikling. Der system- og programvareutvikling er outsourcet enten helt eller delvis til eksterne parter skal sikkerhetskravene spesifiseres i kontrakt eller vedlagt avtale. Det er her vedlegg A 15.1 er viktig å ha korrekt samt A.13.2.4 for taushetsplikt og konfidensialitet.

Det er også viktig å overvåke og overvåke utviklingen for å få sikkerhet for at organisatoriske standarder og krav til sikkerhet innenfor systemer oppnås. Avhengig av hvor innebygde outsource-partnere er i organisasjonen, spesielt hvis ansatte er lokalisert i organisasjonslokaler, er det viktig å inkludere sine ansatte i sikkerhetsopplæring og bevisstgjøringsprogrammer og kommunikasjon. Det er avgjørende å sikre at den interne sikkerhetspraksisen til outsourcepartneren, f.eks. medarbeiderkontroll, minst oppfyller forsikringskrav som er relevante for risikonivåene knyttet til utviklingen de skal jobbe med.

Revisor vil se etter at der outsourcing brukes, er det bevis på due diligence før, under og etter at oppdraget til outsourcepartneren er utført, og inkluderer hensyn til informasjonssikkerhetsbestemmelser.

A.14.2.8 Systemsikkerhetstesting

Testing av sikkerhetsfunksjonalitet må utføres under utvikling. Spesifikk testing av sikkerhetsfunksjonalitet for enhver utvikling må utføres og signeres av en passende myndighet med sikkerhetskompetanse og -ansvar. Sikkerhetstesting forventede utfall bør dokumenteres før testing starter og bør være basert på forretningskrav til sikkerhet. Revisor vil ønske å se at det er bevis for at sikkerhetsspesifikk testing er utført i enhver utvikling som er sikkerhetsrelevant.

A.14.2.9 Systemaksepttesting

Det må etableres aksepttestingsprogrammer og tilhørende kriterier for nye informasjonssystemer, oppgraderinger og nye versjoner. For aksepttesting bør testene og kriteriene for å demonstrere en vellykket test designes og utvikles basert på forretningskrav før tester utføres. Aksepttesting bør også inkludere sikkerhetstesting. Revisor vil se etter bevis som viser at kriterier og metoder for akseptansetesting er utformet i henhold til forretningskrav og inkluderer bestemmelser for sikkerhetsaksepttesting.

Hva er formålet med vedlegg A.14.3?

Vedlegg A.14.3 handler om testdata. Målet i dette vedlegg A-området er å sikre beskyttelse av data som brukes til testing.

A.14.3.1 Beskyttelse av testdata

Testdata må velges nøye, beskyttes og kontrolleres. Testdata bør ideelt sett opprettes i en generisk form uten relasjon til live systemdata. Det er imidlertid anerkjent at live data ofte må brukes for å utføre nøyaktig testing. Der live data brukes til testing bør det være; Anonymisert så langt det er mulig; Nøye valgt og sikret for testperioden; Sikkert slettet når testen er fullført. Bruk av live data må forhåndsautoriseres, logges og overvåkes. Revisor vil forvente å se robuste prosedyrer på plass for å beskytte data som brukes i testmiljøer, spesielt hvis dette er helt eller delvis live data.

Mer hjelp om ISO 27001-kravene og vedlegg A-kontroller finner du i ISMS.online Virtual Coach som utfyller våre rammeverk, verktøy og policyinnhold.