ISO 27001 – Vedlegg A.12: Driftssikkerhet

Hva er formålet med vedlegg A.12.1?

Vedlegg A.12.1 handler om operasjonelle prosedyrer og ansvar. Målet med dette vedlegg A-området er å sikre korrekt og sikker drift av informasjonsbehandlingsanlegg. Det er en viktig del av styringssystemet for informasjonssikkerhet (ISMS), spesielt hvis du ønsker å oppnå ISO 27001-sertifisering. La oss forstå disse kravene og hva de betyr i litt mer dybde nå.

A.12.1.1 Dokumenterte driftsprosedyrer

Driftsprosedyrer skal dokumenteres og deretter gjøres tilgjengelig for alle brukere som trenger dem. Dokumenterte driftsprosedyrer bidrar til å sikre konsistent og effektiv drift av systemer for nye ansatte eller skiftende ressurser, og kan ofte være kritiske for katastrofegjenoppretting, forretningskontinuitet og for når tilgjengeligheten av ansatte er kompromittert. Der informasjonssystemer er "skybaserte" blir tradisjonelle operasjonelle aktiviteter som systemoppstart, nedleggelse, backup etc mindre relevante og kan ofte outsources til en skyleverandør. I mer tradisjonelle datamiljøer og arkitekturer er det mye mer sannsynlig at det kreves driftsprosedyrer.

Det er viktig at dokumenter oppbevares i en korrekt og oppdatert tilstand og bør derfor være gjenstand for formell endringsstyring og periodiske gjennomgangsprosedyrer – dette er nøkkelen, da revisor spesifikt vil se etter dette.

Vi får ofte spørsmål om hvor mye detaljer som trengs, og hvilke områder av virksomheten som må ha dokumenterte prosedyrer. Ta en sunn fornuft tilnærming. For eksempel, hvis du har reell stabstabilitet, de implisitte prosedyrene er veldig godt forstått og motstandskraften er på plass i den ressurspoolen, kan enkle punktpunkter være nok til å danne en dokumentert prosedyre i sjekklistestil.

Tilsvarende hvis prosedyrer utvikler seg eller endres regelmessig, f.eks. på grunn av rask vekst, vil du også ha prosedyrer som enkelt og raskt kan oppdateres. Igjen hvis mange nye ressurser legges til og området har risiko og kompleksitet rundt seg, kan det være behov for mer dybde i prosedyrene, slik at det er entydig om hva, når, hvordan, hvem osv.

Områdene i virksomheten som må vurderes for dokumenterte prosedyrer bør være der informasjonsmidlene dine er i fare ved feildrift, som selvfølgelig vil bli identifisert som en del av risikovurderingen i tråd med 6.1. Det kan inkludere programvareutvikling, IT-administrasjon, gjennom til finansregnskap, kundeadministrasjon, rådgivning eller produksjonsarbeid osv. avhengig av virksomhetens art.

A.12.1.2 Endringsledelse

Organisasjonen, forretningsprosedyrer, informasjonsbehandlingsanlegg og systemer som påvirker informasjonssikkerheten må kontrolleres. Riktig kontrollert endringsledelse er avgjørende i de fleste miljøer for å sikre at endringer er hensiktsmessige, effektive, riktig autorisert og utført på en slik måte at muligheten for enten ondsinnet eller utilsiktet kompromiss minimeres. Endringsledelse gjelder på tvers av organisasjonen, dens prosesser, informasjonsbehandlingsfasiliteter, nettverk, systemer og applikasjoner.

Det kreves revisjonslogger for å gi bevis for riktig bruk av endringsprosedyrer. Revisor vil påpeke at endringsprosedyrer ikke trenger å være altfor kompliserte, men må passe til karakteren av endringen som vurderes. Du kan ganske enkelt fange bevis på endringer og versjonskontrollendringer mens du går, eller drive mye dypere og mer kompleks endringshåndtering og inkludere omskolering og kommunikasjon, samt ha mer betydelige investeringer og avmeldingsprosesser.

A.12.1.3 Kapasitetsstyring

Ressursbruken må overvåkes, justeres og fremskrives av fremtidige kapasitetskrav for å sikre den nødvendige systemytelsen for å oppfylle forretningsmålene. Kapasitetsstyring ser typisk på tre primærtyper; Datalagringskapasitet – (f.eks. i databasesystemer, fillagringsområder osv.); Prosessorkraftkapasitet – (f.eks. tilstrekkelig beregningskraft for å sikre rettidig behandlingsoperasjoner.); og kommunikasjonskapasitet - (ofte referert til som "båndbredde" for å sikre at kommunikasjon skjer i tide).

Kapasitetsstyring må også være; Proaktiv – for eksempel å bruke kapasitetshensyn som en del av endringsledelse; Re-aktiv – f.eks. utløsere og varsler for når kapasitetsbruken når et kritisk punkt slik at rettidige økninger, midlertidige eller permanente kan gjøres.

A.12.1.4 Separasjon av utviklings-, test- og driftsmiljøer

Gode ​​retningslinjer for utvikling, testing og driftsmiljøer vil bekrefte at de må skilles for å redusere risikoen for uautorisert tilgang eller endringer i driftsmiljøet. Det er god praksis å holde utviklings-, testings- og live-operative IT-miljøer adskilt, da dette hjelper med oppgaveseparering og uautorisert tilgang til live-miljøet og dataene. Endringer og nye utviklinger bør testes grundig i et eget område før de distribueres til det aktive driftsmiljøet.

Ideelt sett bør ikke utviklingspersonell ha tilgang til live-miljøet, men dette er kanskje ikke mulig, spesielt i små organisasjoner. Når de er adskilt, er det viktig å sjekke at testere ikke ved et uhell (eller bevisst) bruker testmiljøer som live. Revisor vil kontrollere at utviklings-, test- og livemiljøer er atskilt og at det er formelle prosedyrer inkludert passende autorisasjonsnivåer for å flytte endringer og utviklinger fra ett miljø til et annet.

Hva er formålet med vedlegg A.12.2?

Vedlegg A.12.2 handler om beskyttelse mot skadelig programvare. Målet her er å sikre at informasjons- og informasjonsbehandlingsfasiliteter er beskyttet mot skadelig programvare.

A.12.2.1 Kontroller mot skadelig programvare

Deteksjons-, forebyggings- og gjenopprettingskontroller for å beskytte mot skadelig programvare må implementeres, kombinert med riktig brukerbevissthet. Dette er en del som de fleste organisasjoner har en viss grad av bevissthet, forståelse og implementering om. Imidlertid kan beskyttelse mot skadelig programvare ha en rekke forskjellige former bortsett fra den åpenbare "antivirusprogramvaren".

Andre kontroller som restriksjoner rundt bruk av flyttbare medier eller restriksjoner på installasjon av programvare av brukere – som bidrar til å forhindre bruk av uautorisert programvare – er også verdifulle. Patching av kjente system- og programvaresårbarheter i tide er også kritisk. Ofte er virus utviklet for å lete etter uopprettede systemer og programvare der kjente sårbarheter kan ligge. Det er viktig at eventuell beskyttelse mot skadelig programvare holdes oppdatert, både når det gjelder relevante "signaturfiler" og selve programvaren.

Hva er formålet med vedlegg A.12.3?

Vedlegg A.12.3 handler om backup. Målet er å beskytte mot tap av data.

A.12.3.1 Informasjonssikkerhetskopiering

For å beskytte den verdifulle informasjonen mot tap, beskriver en god kontroll hvordan sikkerhetskopier av informasjon, programvare og systembilder skal tas og testes jevnlig i henhold til en avtalt sikkerhetskopipolicy.

Sikkerhetskopieringsregimer må utformes i henhold til forretningskrav og risikonivåer knyttet til utilgjengelighet av informasjon, så det er viktig å sikre at slike regimer støtter faktiske behov i stedet for bare å være "vi gjør sikkerhetskopier". Når det tas sikkerhetskopier, bør informasjonen minimum beskyttes på samme nivå som live-data og bør lagres borte fra live-miljøet for å minimere risikoen for at et enkelt kompromiss tar ned både live-miljøet og sikkerhetskopiene.

Regelmessig testing av sikkerhetskopier er avgjørende for å sikre at restaureringer vil lykkes og oppnås i tide. Overvåking og registrering av sikkerhetskopier bør implementeres for å sikre at de skjer i tråd med sikkerhetskopieringspolicyen. Smarte revisorer vil ønske å se rapporter om mislykkede sikkerhetskopier og tester utført for å sikre at de fungerer som forventet. Sikkerhetskopieringspolicyer må vurderes rundt hva, hvor fra og hvor til, hvem, når – med tanke på kontor- og hjemmearbeidere, mobil osv. der det er hensyn til mobil- og fjerningslagringssikkerhetskopier som har økt risiko ved tap som kan være adressert gjennom kryptering eller andre kontroller.

Hva er formålet med vedlegg A.12.4?

Vedlegg A.12.4 handler om logging og overvåking. Målet i dette vedlegg A-området er å registrere hendelser og generere bevis.

A.12.4.1 Hendelseslogging

Hendelseslogger som registrerer brukeraktiviteter, unntak, feil og informasjonssikkerhetshendelser må produseres, oppbevares og gjennomgås regelmessig. Logg- og overvåkingsmekanismer utgjør en viktig del av en "defence-in-depth"-strategi for sikkerhetsstyring ved å tilby både detektiv- og etterforskningsevner. Hendelseslogger av alle typer, f.eks. systemlogger, tilgangskontrolllogger, etc., kan være nødvendig, spesielt når det gjelder hendelseshåndtering og revisjon. Logger vil ofte trenge å lagre potensielt store mengder informasjon, så det er viktig at kapasitetshensyn gjøres.

A.12.4.2 Beskyttelse av logginformasjon

Logganlegg og logginformasjon skal beskyttes mot tukling og uautorisert tilgang. Det er også viktig å sørge for at logger lagres på en sikker og manipulasjonssikker måte, slik at alle bevis som stammer fra dem kan bevises på en beviselig måte. Dette er spesielt viktig i enhver form for rettssak knyttet til bevis fra loggen. Fordi logger potensielt inneholder store mengder sensitive data, er det viktig at de er beskyttet og sikret tilstrekkelig. Det er også viktig å tenke på at hvis loggene inneholder personlig identifiserbar informasjon, som de nesten helt sikkert vil, som bruker-ID og handlingene utført av den UID-en, vil de sannsynligvis falle inn under kravene i databeskyttelses- og personvernlovgivningen, inkludert datalagring .

A.12.4.3 Administrator- og operatørlogger

En god kontroll beskriver hvordan eventuelle systemadministratorer og systemoperatøraktiviteter må logges og loggene beskyttes og gjennomgås regelmessig. Spesiell vurdering bør tas til høyere nivåer av logging for privilegerte kontoer som systemadministratorer og operatører.

A.12.4.4 Klokkesynkronisering

Klokkene til alle relevante informasjonsbehandlingssystemer innenfor en organisasjon eller sikkerhetsdomene må synkroniseres til en enkelt referansetidskilde. Synkronisering av systemklokken er viktig, spesielt når man beviser hendelser som en del av en etterforskning eller rettslig prosess, da det ofte er umulig eller svært vanskelig å bevise "årsak og virkning" hvis klokkene ikke er riktig synkronisert. Revisor vil være spesielt oppmerksom på at dette er gjort.

Hva er formålet med vedlegg A.12.5?

Vedlegg A.12.5 handler om kontroll av operativ programvare. Målet i dette vedlegg A-området er å sikre integriteten til operasjonelle systemer.

A.12.5.1 Installasjon av programvare på operasjonelle systemer

Det må implementeres prosedyrer for å kontrollere installasjon av programvare på driftssystemer. Som med all sikkerhetsrelatert kontroll er det viktig at installasjonen av programvare på driftssystemer er formelt kontrollert. Selv om dette kanskje ikke alltid er mulig, spesielt i små organisasjoner, forblir prinsippet sant. Problemer knyttet til upassende installasjon eller endring av programvare på operasjonelle systemer kan omfatte; Programvare infisert med skadelig programvare blir installert; Kapasitetsproblemer; eller Programvare som kan gjøre det mulig å installere skadelig innsideaktivitet (f.eks. hackingverktøy). Utover å begrense og begrense installasjonen av programvare på operasjonelle systemer, er det også viktig å formelt kontrollere den legitime installasjonen.

Det er god praksis å sikre der det er mulig at f.eks. Formell endringsledelse har funnet sted, inkludert passende autorisasjonsnivåer; Tilbakeføringsprosedyrer er på plass; og tidligere versjoner av programvare og endringshistorikk oppbevares sikkert. Hver endring bør vurdere både forretningskravene og sikkerhetskravene og risikoene i tråd med formelle prosedyrer for endringshåndtering. Revisor vil forvente å se journal over programvareendringer og installasjoner som er oppbevart, som de vil ønske å inspisere/prøveprøve.

Hva er formålet med vedlegg A.12.6?

Vedlegg A.12.6 handler om teknisk sårbarhetshåndtering. Målet i dette vedlegg A-området er å forhindre utnyttelse av tekniske sårbarheter.

A.12.6.1 Håndtering av tekniske sårbarheter

Informasjon om tekniske sårbarheter ved informasjonssystemer som brukes må innhentes i tide, organisasjonens eksponering for slike sårbarheter vurderes og passende tiltak iverksettes for å håndtere den tilhørende risikoen. Enhver sårbarhet er en svakhet i sikkerhetsbeskyttelsen og må håndteres effektivt der risikonivåer er uakseptable. Tekniske sårbarheter har vært kjernen i mange store sikkerhetsbrudd rapportert i media (og de som ikke er det!), og det er derfor viktig at den formelle administrerte prosessen er på plass på et tilstrekkelig og forholdsmessig nivå.

Det må være en balanse mellom sikkerhetskravet til å implementere sårbarhetsoppdateringer så raskt som mulig og sikkerhetskravet til å teste patcher tilstrekkelig til å sikre fortsatt tilgjengelighet og integritet til systemene og minimalisering av inkompatibiliteter. Bevissthet kan også spille en viktig rolle og det er derfor fornuftig å ha en kommunikasjonsstrategi knyttet til å oppdatere brukere når det eksisterer sårbarheter som til en viss grad kan håndteres gjennom brukeratferd. Revisor vil forvente å se at prosesser for å identifisere og oppdage sårbarheter er på plass, spesielt på kritiske systemer eller de som behandler eller lagrer sensitiv eller klassifisert informasjon.

A.12.6.2 Restriksjoner på programvareinstallasjon

Regler for installasjon av programvare av brukere må etableres og implementeres. Denne kontrollen gjelder å begrense brukernes mulighet til å installere programvare, spesielt på lokale enheter (arbeidsstasjoner, bærbare datamaskiner osv.). Installasjon av programvare av brukere reiser en rekke trusler og sårbarheter, inkludert trusselen om introduksjon av skadelig programvare og potensielt brudd på programvarelisens/IPR-lover. Ideelt sett vil brukere ikke kunne installere programvare på organisasjonsutstyr, men det kan være forretningsmessige eller praktiske årsaker til at dette ikke er mulig.

Der full begrensning ikke er mulig, er det god praksis å "hviteliste" hvilken programvare som kan installeres. Revisor vil sjekke hvilke begrensninger som er lagt på installasjon av programvare av brukere. Deretter, der full restriksjon ikke er implementert, vil de ønske å se bevis på at risikoen er fullstendig vurdert, og der det er mulig, har komplementære kontroller som regelmessige programvarerevisjoner blitt implementert og brukes regelmessig.

Hva er formålet med vedlegg A.12.7?

Vedlegg A.12.7 handler om informasjonssystemer og revisjonshensyn. Målet i dette vedlegg A-området er å minimere virkningen av revisjonsaktiviteter på operasjonelle systemer.

A.12.7.1 Revisjonskontroller for informasjonssystemer

Revisjonskrav og aktiviteter som involverer verifisering av driftssystemer må planlegges nøye og avtales for å minimere forstyrrelser i forretningsprosessene. Når man utfører tester og revisjonsaktiviteter (f.eks. sårbarhetsskanninger, penetrasjonstester osv.) på operasjonelle systemer, må det tas hensyn til å sikre at driften ikke påvirkes negativt. I tillegg må omfanget og dybden av testingen defineres. Enhver slik revisjon eller testing av driftssystemer må skje gjennom en formell og hensiktsmessig autorisert prosess. Revisor vil se etter bevis på at planlegging av tester og testnivå er avtalt og autorisert gjennom en formell prosess.