ISO 27001 – Bilag A.12: Driftssikkerhed

Hvad er formålet med bilag A.12.1?

Bilag A.12.1 handler om operationelle procedurer og ansvar. Formålet med dette bilag A-område er at sikre korrekt og sikker drift af informationsbehandlingsfaciliteter. Det er en vigtig del af informationssikkerhedsstyringssystemet (ISMS), især hvis du gerne vil opnå ISO 27001-certificering. Lad os forstå disse krav, og hvad de betyder i lidt mere dybde nu.

A.12.1.1 Dokumenterede driftsprocedurer

Driftsprocedurer skal dokumenteres og derefter gøres tilgængelige for alle brugere, der har brug for dem. Dokumenterede driftsprocedurer hjælper med at sikre ensartet og effektiv drift af systemer for nye medarbejdere eller skiftende ressourcer og kan ofte være kritiske for katastrofeoprettelse, forretningskontinuitet og for når personaletilgængeligheden er kompromitteret. Hvor informationssystemer er "sky-baserede" bliver traditionelle operationelle aktiviteter såsom systemstart, nedlukning, backup osv. mindre relevante og kan ofte outsources til en cloud-udbyder. I mere traditionelle computermiljøer og arkitekturer er det meget mere sandsynligt, at der kræves driftsprocedurer.

Det er vigtigt, at dokumenter vedligeholdes i en korrekt og aktuel stand og bør derfor være underlagt formel ændringsstyring og periodiske revisionsprocedurer – dette er nøglen, da revisor specifikt vil se på dette.

Vi bliver ofte spurgt om, hvor mange detaljer der er nødvendige, og hvilke områder af virksomheden der skal have dokumenterede procedurer. Tag en sund fornuft tilgang. For eksempel, hvis du har reel personalestabilitet, de implicitte procedurer er meget velforståede og modstandskraften er på plads på tværs af den ressourcepulje, kan simple punktopstillinger være nok til at danne en tjeklistestil dokumenteret procedure.

På samme måde, hvis procedurer udvikler sig eller regelmæssigt ændres, f.eks. på grund af hurtig vækst, vil du gerne have procedurer, der også nemt og hurtigt kan opdateres. Igen, hvis der kommer masser af nye ressourcer til, og området har risiko og kompleksitet omkring sig, så kan der være behov for mere dybde i procedurerne, så det er entydigt om hvad, hvornår, hvordan, hvem osv.

De områder af forretningen, der skal tages i betragtning ved dokumenterede procedurer, bør være, hvor dine informationsaktiver er i fare ved fejlbetjening, hvilket naturligvis vil blive identificeret som en del af risikovurderingen i overensstemmelse med 6.1. Det kan omfatte softwareudvikling, IT-styring, frem til finansielt regnskab, kundestyring, rådgivning eller fremstillingsarbejde osv. afhængigt af virksomhedens art.

A.12.1.2 Forandringsledelse

Organisationen, forretningsgange, informationsbehandlingsfaciliteter og systemer, der påvirker informationssikkerheden, skal kontrolleres. Korrekt kontrolleret ændringsstyring er afgørende i de fleste miljøer for at sikre, at ændringer er passende, effektive, korrekt autoriserede og udført på en sådan måde, at muligheden for enten ondsindet eller utilsigtet kompromittering minimeres. Forandringsledelse gælder på tværs af organisationen, dens processer, informationsbehandlingsfaciliteter, netværk, systemer og applikationer.

Der kræves revisionslogfiler for at give bevis for den korrekte brug af ændringsprocedurer. Revisor vil gerne påpege, at ændringsprocedurer ikke behøver at være alt for komplicerede, men skal passe til karakteren af ​​den ændring, der overvejes. Du kan simpelthen indhente beviser for ændringer og versionskontrolændringer, mens du går, eller drive meget dybere mere kompleks ændringsstyring og inkludere omskoling og kommunikation samt have mere betydelige investerings- og afmeldingsprocesser.

A.12.1.3 Kapacitetsstyring

Brugen af ​​ressourcer skal overvåges, tunes og fremskrives af fremtidige kapacitetskrav for at sikre den påkrævede systemydelse for at opfylde forretningsmålene. Kapacitetsstyring ser typisk på tre primære typer; Datalagringskapacitet – (f.eks. i databasesystemer, fillagerområder osv.); Processorkapacitet – (f.eks. tilstrækkelig beregningskraft til at sikre rettidig behandlingsoperationer.); og kommunikationskapacitet – (ofte omtalt som "båndbredde" for at sikre, at kommunikation sker rettidigt).

Kapacitetsstyring skal også være; Proaktiv – for eksempel at bruge kapacitetshensyn som led i forandringsledelse; Re-aktiv – f.eks. udløsere og advarsler for, når kapacitetsforbruget er ved at nå et kritisk punkt, så rettidige stigninger, midlertidige eller permanente kan foretages.

A.12.1.4 Adskillelse af udviklings-, test- og driftsmiljøer

Gode ​​politikker for udviklings-, test- og driftsmiljøer vil bekræfte, at de skal adskilles for at reducere risikoen for uautoriseret adgang eller ændringer i driftsmiljøet. At holde udvikling, test og live operationelle it-miljøer adskilt er god praksis, da dette hjælper med adskillelse af opgaver og uautoriseret adgang til live-miljøet og data. Ændringer og nye udviklinger bør testes grundigt i et separat område, før de implementeres i det levende driftsmiljø.

Ideelt set bør udviklingspersonale ikke have adgang til det levende miljø, men det er måske ikke muligt, især i små organisationer. Når de er adskilt, er det vigtigt at kontrollere, at testere ikke ved et uheld (eller bevidst) bruger testmiljøer som live. Revisoren vil kontrollere, at udviklings-, test- og livemiljøer er adskilte, og at der er formelle procedurer, herunder passende autorisationsniveauer til at flytte ændringer og udviklinger fra et miljø til et andet.

Hvad er formålet med bilag A.12.2?

Bilag A.12.2 handler om beskyttelse mod malware. Målet her er at sikre, at informations- og informationsbehandlingsfaciliteter er beskyttet mod malware.

A.12.2.1 Kontroller mod malware

Detektions-, forebyggelses- og gendannelseskontroller for at beskytte mod malware skal implementeres, kombineret med den relevante brugerbevidsthed. Dette er et afsnit, som de fleste organisationer har en vis grad af bevidsthed, forståelse og implementering om. Beskyttelse mod malware kan dog antage en række forskellige former bortset fra den åbenlyse "antivirussoftware".

Andre kontroller som f.eks. restriktioner omkring brugen af ​​flytbare medier eller restriktioner for brugernes installation af software – der hjælper med at forhindre brugen af ​​uautoriseret software – er også værdifulde. Patching af kendte system- og softwaresårbarheder rettidigt er også kritisk. Vira er ofte designet til at lede efter upatchede systemer og software, hvori kendte sårbarheder kan findes. Det er vigtigt, at enhver malwarebeskyttelse holdes opdateret, både med hensyn til relevante "signaturfiler" og selve softwaren.

Hvad er formålet med bilag A.12.3?

Bilag A.12.3 handler om backup. Formålet er at beskytte mod tab af data.

A.12.3.1 Sikkerhedskopiering af oplysninger

For at beskytte den værdifulde information mod tab, beskriver en god kontrol, hvordan sikkerhedskopier af information, software og systembilleder skal tages og testes løbende i henhold til en aftalt backuppolitik.

Sikkerhedskopieringsregimer skal designes i overensstemmelse med forretningskrav og risikoniveauer i forbindelse med utilgængelighed af information, så det er vigtigt at sikre, at sådanne regimer understøtter faktiske behov i stedet for blot at være "vi laver backups". Når der tages sikkerhedskopier, skal informationen minimum beskyttes på samme niveau som live-data og bør opbevares væk fra det levende miljø for at minimere risikoen for, at et enkelt kompromis fjerner både live-miljøet og sikkerhedskopierne.

Regelmæssig test af sikkerhedskopier er afgørende for at sikre, at gendannelser bliver succesfulde og opnås rettidigt. Overvågning og registrering af sikkerhedskopier bør implementeres for at sikre, at de sker i overensstemmelse med sikkerhedskopieringspolitikken. Smarte revisorer vil gerne se rapporter om mislykkede sikkerhedskopieringer og test udført for at sikre, at de fungerer som forventet. Sikkerhedskopieringspolitikker skal overvejes omkring hvad, hvorfra og hvor til, hvem, hvornår – under hensyntagen til kontor- og hjemmearbejdere, mobil osv., hvor der er overvejelser om sikkerhedskopiering af mobil og fjernelse af lager, der har øget risiko i tilfælde af tab, der evt. adresseres gennem kryptering eller andre kontroller.

Hvad er formålet med bilag A.12.4?

Bilag A.12.4 handler om logning og overvågning. Formålet med dette bilag A-område er at registrere hændelser og frembringe beviser.

A.12.4.1 Hændelseslogning

Hændelseslogs, der registrerer brugeraktiviteter, undtagelser, fejl og informationssikkerhedshændelser, skal produceres, opbevares og gennemgås regelmæssigt. Lognings- og overvågningsmekanismer udgør en vigtig del af en "defence-in-depth"-strategi for sikkerhedsstyring ved at tilbyde både detektiv- og efterforskningsmuligheder. Eventlogs af alle typer, f.eks. systemlogs, adgangskontrollogs osv., kan være påkrævet, især vedrørende hændelsesstyring og revision. Logs vil ofte skulle gemme potentielt enorme mængder information, så det er vigtigt, at der tages kapacitetsovervejelser.

A.12.4.2 Beskyttelse af logoplysninger

Logningsfaciliteter og logoplysninger skal beskyttes mod manipulation og uautoriseret adgang. Det er også afgørende at sikre, at logfiler opbevares på en sikker og manipulationssikker måde, så ethvert bevis, der stammer fra dem, kan bevises på en beviselig måde. Dette er især vigtigt i enhver form for retssager vedrørende bevismateriale fra loggen. Fordi logfiler potentielt indeholder store mængder følsomme data, er det vigtigt, at de er beskyttet og sikret tilstrækkeligt. Det er også vigtigt at overveje, at hvis logfilerne indeholder personligt identificerbare oplysninger, som de næsten helt sikkert vil, såsom bruger-id og de handlinger, der udføres af det pågældende UID, vil de sandsynligvis falde ind under kravene i databeskyttelses- og privatlivslovgivningen, herunder dataopbevaring .

A.12.4.3 Administrator- og operatørlogfiler

En god kontrol beskriver, hvordan eventuelle systemadministratorer og systemoperatøraktiviteter skal logges og loggene beskyttes og regelmæssigt gennemgås. Der bør tages særligt hensyn til højere niveauer af logning for privilegerede konti såsom systemadministratorer og operatører.

A.12.4.4 Ursynkronisering

Urene for alle relevante informationsbehandlingssystemer inden for en organisation eller sikkerhedsdomæne skal synkroniseres til en enkelt referencetidskilde. Synkronisering af systemur er vigtig, især når der bevises hændelser som en del af en undersøgelse eller retssag, da det ofte er umuligt eller meget svært at bevise "årsag og virkning", hvis ure ikke er synkroniseret korrekt. Revisor vil være særlig opmærksom på at sikre, at dette er sket.

Hvad er formålet med bilag A.12.5?

Bilag A.12.5 handler om styring af operationel software. Målet i dette bilag A-område er at sikre integriteten af ​​operationelle systemer.

A.12.5.1 Installation af software på operationelle systemer

Der skal implementeres procedurer for at kontrollere installationen af ​​software på driftssystemer. Som med enhver sikkerhedsrelateret kontrol er det vigtigt, at installationen af ​​software på driftssystemer er formelt kontrolleret. Selvom dette måske ikke altid er muligt, især i små organisationer, forbliver princippet sandt. Problemer relateret til uhensigtsmæssig installation eller ændring af software på driftssystemer kan omfatte; Malware-inficeret software bliver installeret; Kapacitetsproblemer; eller Software, der kan gøre det muligt at installere ondsindet insideraktivitet (f.eks. hackingværktøjer). Ud over at begrænse og begrænse installationen af ​​software på operationelle systemer, er det også vigtigt formelt at kontrollere den lovlige installation.

Det er god praksis at sikre, hvor det er muligt, at f.eks. Formel forandringsledelse har fundet sted, herunder passende autorisationsniveauer; Procedurer for tilbagerulning er på plads; og tidligere versioner af software og ændringshistorik opbevares sikkert. Hver ændring bør tage hensyn til både forretningskravene og sikkerhedskravene og -risici i overensstemmelse med formelle ændringsstyringsprocedurer. Revisor vil forvente at se optegnelser over softwareændringer og installationer, der er blevet opbevaret, som de ønsker at inspicere/prøveprøver.

Hvad er formålet med bilag A.12.6?

Bilag A.12.6 handler om teknisk sårbarhedshåndtering. Målet i dette bilag A-område er at forhindre udnyttelse af tekniske sårbarheder.

A.12.6.1 Håndtering af tekniske sårbarheder

Oplysninger om tekniske sårbarheder i de anvendte informationssystemer skal indhentes rettidigt, organisationens eksponering for sådanne sårbarheder skal evalueres, og passende foranstaltninger skal træffes for at imødegå den tilknyttede risiko. Enhver sårbarhed er en svaghed i sikkerhedsbeskyttelsen og skal håndteres effektivt, hvor risikoniveauerne er uacceptable. Tekniske sårbarheder har været kernen i mange store sikkerhedsbrud, der er rapporteret i medierne (og dem, der ikke er det!), og det er derfor vigtigt, at en formel styret proces er på plads på et passende og forholdsmæssigt niveau.

Der skal være en balance mellem sikkerhedskravet til at implementere sårbarhedsrettelser så hurtigt som muligt og sikkerhedskravet til at teste patches tilstrækkeligt til at sikre systemernes fortsatte tilgængelighed og integritet og minimering af inkompatibiliteter. Bevidsthed kan også spille en vigtig rolle, og det er derfor fornuftigt at have en kommunikationsstrategi i forhold til opdatering af brugere, når der eksisterer sårbarheder, som til en vis grad kan håndteres gennem brugeradfærd. Revisor vil forvente at se, at processer til at identificere og opdage sårbarheder er på plads, især på kritiske systemer eller dem, der behandler eller opbevarer følsomme eller klassificerede oplysninger.

A.12.6.2 Begrænsninger for softwareinstallation

Regler for brugernes installation af software skal etableres og implementeres. Denne kontrol vedrører begrænsning af brugernes mulighed for at installere software, især på lokale enheder (arbejdsstationer, bærbare computere osv.). Installation af software af brugere rejser en række trusler og sårbarheder, herunder truslen om introduktion af malware og det potentielle brud på softwarelicens/IPR-lovgivningen. Ideelt set ville brugere ikke være i stand til at installere software på organisatorisk udstyr, men der kan være forretningsmæssige eller praktiske årsager til, at dette ikke er muligt.

Hvor fuld begrænsning ikke er mulig, er det god praksis at "hvidliste", hvilken software der kan installeres. Revisoren vil kontrollere, hvilke begrænsninger der er lagt på brugernes installation af software. Så, hvor fuld begrænsning ikke er implementeret, vil de gerne se beviser for, at risiciene er blevet fuldt vurderet, og hvor det er muligt, er supplerende kontroller, såsom regelmæssige softwareaudits, blevet implementeret og bliver regelmæssigt brugt.

Hvad er formålet med bilag A.12.7?

Bilag A.12.7 handler om informationssystemer og revisionsovervejelser. Målet i dette bilag A-område er at minimere revisionsaktiviteternes indvirkning på operationelle systemer.

A.12.7.1 Revision af informationssystemer

Revisionskrav og aktiviteter, der involverer verifikation af driftssystemer, skal planlægges omhyggeligt og aftales for at minimere forstyrrelser i forretningsprocesserne. Når der udføres test og revisionsaktiviteter (f.eks. sårbarhedsscanninger, penetrationstest osv.) på operationelle systemer, skal der tages hensyn til at sikre, at driften ikke påvirkes negativt. Derudover skal omfanget og dybden af ​​testen defineres. Enhver sådan revision eller afprøvning af driftssystemer skal ske gennem en formel og passende autoriseret proces. Revisor vil lede efter bevis for, at planlægningen af ​​tests og testniveauet er aftalt og godkendt gennem en formel proces.