ISO 27001 – Bilaga A.12: Driftsäkerhet

Vad är syftet med bilaga A.12.1?

Bilaga A.12.1 handlar om operativa rutiner och ansvar. Syftet med detta område i bilaga A är att säkerställa korrekt och säker drift av informationsbehandlingsanläggningar. Det är en viktig del av ledningssystemet för informationssäkerhet (ISMS), särskilt om du vill uppnå ISO 27001-certifiering. Låt oss förstå dessa krav och vad de betyder lite mer på djupet nu.

A.12.1.1 Dokumenterade driftsprocedurer

Driftsrutiner måste dokumenteras och sedan göras tillgängliga för alla användare som behöver dem. Dokumenterade driftsrutiner hjälper till att säkerställa konsekvent och effektiv drift av system för ny personal eller förändrade resurser, och kan ofta vara avgörande för katastrofåterställning, affärskontinuitet och för när personaltillgängligheten äventyras. Där informationssystem är "molnbaserade" blir traditionella operativa aktiviteter som systemstart, avstängning, backup etc mindre relevanta och kan ofta läggas ut på en molnleverantör. I mer traditionella datormiljöer och arkitekturer är det mycket mer sannolikt att driftprocedurer krävs.

Det är viktigt att dokument upprätthålls i ett korrekt och aktuellt skick och bör därför vara föremål för formell förändringshantering och periodiska granskningsförfaranden – detta är nyckeln, eftersom revisorn specifikt kommer att titta på detta.

Vi får ofta frågor om hur mycket detaljer som behövs och vilka delar av verksamheten som behöver ha dokumenterade rutiner. Ta ett sunt förnuft. Till exempel, om du har verklig personalstabilitet, de implicita procedurerna är mycket väl förstådda och motståndskraften är på plats i den resurspoolen, kan enkla punktpunkter räcka för att skapa en dokumenterad procedure i checklista.

På samma sätt om procedurer utvecklas eller regelbundet ändras, t.ex. på grund av snabb tillväxt, vill du ha procedurer som också enkelt och snabbt kan uppdateras. Återigen om massor av nya resurser läggs till och området har risk och komplexitet kring sig, så kan det behövas mer djup i procedurerna så det är entydigt om vad, när, hur, vem etc.

De områden av verksamheten som behöver beaktas för dokumenterade rutiner bör vara där dina informationstillgångar är i riskzonen genom felaktig drift, vilket givetvis kommer att identifieras som en del av riskbedömningen i linje med 6.1. Det kan inkludera mjukvaruutveckling, IT-hantering, till finansiell redovisning, kundhantering, konsult- eller tillverkningsarbete etc beroende på verksamhetens karaktär.

A.12.1.2 Förändringshantering

Organisation, affärsrutiner, informationsbehandlingsanläggningar och system som påverkar informationssäkerheten behöver kontrolleras. Korrekt kontrollerad förändringshantering är väsentlig i de flesta miljöer för att säkerställa att ändringar är lämpliga, effektiva, korrekt auktoriserade och utförda på ett sådant sätt att möjligheten för antingen uppsåtlig eller oavsiktlig kompromiss minimeras. Förändringshantering gäller över hela organisationen, dess processer, informationsbehandlingsanläggningar, nätverk, system och applikationer.

Revisionsloggar krävs för att ge bevis på korrekt användning av ändringsprocedurer. Revisorn kommer att vilja påpeka att förändringsprocedurer inte behöver vara alltför komplicerade, utan måste vara anpassade till den typ av förändring som övervägs. Du kan helt enkelt fånga bevis på ändringar och versionskontrolländringar allt eftersom, eller driva mycket djupare och mer komplex förändringshantering och inkludera omskolning och kommunikation samt ha mer betydande investerings- och sign-off-processer.

A.12.1.3 Kapacitetshantering

Resursanvändningen måste övervakas, trimmas och prognoser göras av framtida kapacitetskrav för att säkerställa den systemprestanda som krävs för att uppfylla affärsmålen. Kapacitetshantering tittar vanligtvis på tre primära typer; Datalagringskapacitet – (t.ex. i databassystem, fillagringsutrymmen etc.); Bearbetningskapacitet – (t.ex. tillräcklig beräkningskraft för att säkerställa att bearbetningen sker i rätt tid.); och kommunikationskapacitet – (kallas ofta för "bandbredd" för att säkerställa att kommunikation sker i rätt tid).

Kapacitetshantering måste också vara; Proaktiv – till exempel att använda kapacitetsöverväganden som en del av förändringsledning; Re-active – t.ex. triggers och varningar för när kapacitetsanvändningen når en kritisk punkt så att snabba ökningar, tillfälliga eller permanenta kan göras.

A.12.1.4 Separation av utvecklings-, test- och operativa miljöer

Bra policyer för utvecklings-, test- och driftsmiljöer skulle bekräfta att de måste separeras för att minska riskerna för obehörig åtkomst eller förändringar av den operativa miljön. Att hålla isär utvecklings-, testnings- och liveoperativa IT-miljöer är god praxis eftersom detta hjälper till med åtskillnad av arbetsuppgifter och obehörig åtkomst till livemiljön och data. Förändringar och nya utvecklingar bör testas noggrant i ett separat område innan de distribueras till den levande operativa miljön.

Helst ska utvecklingspersonal inte ha tillgång till den levande miljön, men detta kanske inte är möjligt, särskilt i små organisationer. När de väl är åtskilda är det viktigt att kontrollera att testare inte av misstag (eller avsiktligt) använder testmiljöer som live. Revisorn kommer att kontrollera att utvecklings-, test- och livemiljöer är åtskilda och att det finns formella rutiner inklusive lämpliga behörighetsnivåer för att flytta förändringar och utvecklingar från en miljö till en annan.

Vad är syftet med bilaga A.12.2?

Bilaga A.12.2 handlar om skydd mot skadlig programvara. Målet här är att säkerställa att informations- och informationsbehandlingsanläggningar är skyddade mot skadlig programvara.

A.12.2.1 Kontroller mot skadlig programvara

Detektions-, förebyggande- och återställningskontroller för att skydda mot skadlig programvara måste implementeras, kombinerat med lämplig användarmedvetenhet. Detta är ett avsnitt som de flesta organisationer har en viss nivå av medvetenhet, förståelse och implementering om. Skydd mot skadlig programvara kan dock ta ett antal olika former förutom den uppenbara "antivirusmjukvaran".

Andra kontroller som begränsningar kring användningen av flyttbara media eller begränsningar av användarnas installation av programvara – som hjälper till att förhindra användning av obehörig programvara – är också värdefulla. Det är också viktigt att patcha kända sårbarheter i system och programvara i tid. Ofta är virus utformade för att leta efter oparpade system och programvara där kända sårbarheter kan finnas. Det är viktigt att allt skydd mot skadlig programvara hålls uppdaterat, både vad gäller relevanta "signaturfiler" och själva programvaran.

Vad är syftet med bilaga A.12.3?

Bilaga A.12.3 handlar om backup. Målet är att skydda mot förlust av data.

A.12.3.1 Säkerhetskopiering av information

För att skydda den värdefulla informationen mot förlust beskriver en god kontroll hur säkerhetskopior av information, mjukvara och systembilder ska tas och testas regelbundet enligt en överenskommen backuppolicy.

Säkerhetskopieringsregimer måste utformas i enlighet med affärskrav och risknivåer relaterade till otillgänglighet av information, så det är viktigt att säkerställa att sådana regimer stöder faktiska behov snarare än att bara vara "vi gör säkerhetskopior". När säkerhetskopior tas bör informationen minst skyddas på samma nivå som livedata och bör lagras borta från livemiljön för att minimera risken för att en enda kompromiss tar ner både livemiljön och säkerhetskopiorna.

Regelbundna tester av säkerhetskopior är avgörande för att säkerställa att återställningar kommer att bli framgångsrika och uppnås i tid. Övervakning och inspelning av säkerhetskopior bör implementeras för att säkerställa att de sker i linje med säkerhetskopieringspolicyn. Smarta revisorer kommer att vilja se rapporter om misslyckade säkerhetskopior och tester som görs för att säkerställa att de fungerar som förväntat. Säkerhetskopieringspolicyer måste övervägas kring vad, varifrån och var till, vem, när – med hänsyn till kontor och hemarbetare, mobil etc där det finns överväganden om mobila och borttagningslagringssäkerhetskopior som har ökade risker i händelse av förlust som kan vara adresseras genom kryptering eller andra kontroller.

Vad är syftet med bilaga A.12.4?

Bilaga A.12.4 handlar om loggning och övervakning. Målet i detta bilaga A-område är att registrera händelser och generera bevis.

A.12.4.1 Händelseloggning

Händelseloggar som registrerar användaraktiviteter, undantag, fel och informationssäkerhetshändelser måste produceras, föras och granskas regelbundet. Loggnings- och övervakningsmekanismer utgör en viktig del av en "djupförsvarsstrategi" för säkerhetshantering genom att tillhandahålla både detektiv- och utredningskapacitet. Händelseloggar av alla slag, t.ex. systemloggar, loggar för åtkomstkontroll etc., kan krävas, särskilt när det gäller incidenthantering och revision. Loggar kommer ofta att behöva lagra potentiellt stora mängder information så det är viktigt att kapacitetsöverväganden görs.

A.12.4.2 Skydd av logginformation

Loggningsanläggningar och logginformation måste skyddas mot manipulering och obehörig åtkomst. Det är också viktigt att se till att loggar lagras på ett säkert och manipuleringssäkert sätt så att alla bevis som härrör från dem kan bevisas på ett bevisbart sätt. Detta är särskilt viktigt i alla former av rättsliga förfaranden som rör bevis från loggen. Eftersom loggar potentiellt innehåller stora mängder känslig data är det viktigt att de skyddas och säkras på ett adekvat sätt. Det är också viktigt att tänka på att om loggarna innehåller personligt identifierbar information, vilket de nästan säkert kommer att göra, såsom användar-ID och de åtgärder som utförs av det UID:t, kommer de sannolikt att falla under kraven i dataskydds- och integritetslagstiftningen inklusive datalagring .

A.12.4.3 Administratörs- och operatörsloggar

En bra kontroll beskriver hur eventuella systemadministratörer och systemoperatörsaktiviteter behöver loggas och loggarna skyddas och regelbundet granskas. Särskild hänsyn bör tas till högre nivåer av loggning för privilegierade konton som systemadministratörer och operatörer.

A.12.4.4 Klocksynkronisering

Klockorna för alla relevanta informationsbehandlingssystem inom en organisation eller säkerhetsdomän måste synkroniseras till en enda referenstidskälla. Systemklocksynkronisering är viktig, särskilt när man bevisar händelser som en del av en utredning eller rättslig process eftersom det ofta är omöjligt eller mycket svårt att bevisa "orsak & verkan" om klockorna inte synkroniseras korrekt. Revisorn kommer att ägna särskild uppmärksamhet åt att säkerställa att detta har gjorts.

Vad är syftet med bilaga A.12.5?

Bilaga A.12.5 handlar om styrning av operativ programvara. Målet i detta bilaga A-område är att säkerställa driftssystemens integritet.

A.12.5.1 Installation av programvara på operativa system

Rutiner måste implementeras för att kontrollera installationen av programvara på operativa system. Som med all säkerhetsrelaterad kontroll är det viktigt att installationen av programvara på operativa system är formellt kontrollerad. Även om detta kanske inte alltid är möjligt, särskilt i små organisationer, förblir principen sann. Frågor relaterade till olämplig installation eller ändring av programvara på operativa system kan inkludera; Skadlig programvara installeras; Kapacitetsfrågor; eller Programvara som kan möjliggöra installation av skadlig insideraktivitet (t.ex. hackverktyg). Förutom att begränsa och begränsa installationen av programvara på operativa system är det också viktigt att formellt kontrollera den legitima installationen.

Det är god praxis att när så är möjligt se till att t.ex. Formell förändringshantering har ägt rum, inklusive lämpliga behörighetsnivåer; Återställningsprocedurer finns på plats; och Tidigare versioner av programvara och ändringshistorik förvaras säkert. Varje förändring bör ta hänsyn till både affärskraven och säkerhetskraven och riskerna i linje med formella förändringshanteringsprocedurer. Revisorn kommer att förvänta sig att se register över mjukvaruförändringar och installationer som har sparats, som de kommer att vilja inspektera/prova.

Vad är syftet med bilaga A.12.6?

Bilaga A.12.6 handlar om teknisk sårbarhetshantering. Målet i detta bilaga A-område är att förhindra utnyttjande av tekniska sårbarheter.

A.12.6.1 Hantering av tekniska sårbarheter

Information om tekniska sårbarheter i informationssystem som används måste erhållas i god tid, organisationens exponering för sådana sårbarheter utvärderas och lämpliga åtgärder vidtas för att hantera den förknippade risken. Varje sårbarhet är en svaghet i säkerhetsskyddet och måste hanteras effektivt och effektivt där risknivåerna är oacceptabla. Tekniska sårbarheter har varit kärnan i många stora säkerhetsintrång som rapporterats i media (och de som inte är det!) och därför är det viktigt att den formella hanterade processen är på plats på en adekvat och proportionerlig nivå.

Det måste finnas en balans mellan säkerhetskravet för att implementera sårbarhetskorrigeringar så snabbt som möjligt och säkerhetskravet att testa patchar tillräckligt för att säkerställa fortsatt tillgänglighet och integritet hos systemen och minimering av inkompatibiliteter. Medvetenhet kan också spela en viktig roll och det är därför klokt att ha en kommunikationsstrategi för att uppdatera användare när sårbarheter finns som till viss del kan hanteras genom användarbeteenden. Revisorn förväntar sig att se att processer för att identifiera och upptäcka sårbarheter finns på plats, särskilt på kritiska system eller de som behandlar eller lagrar känslig eller sekretessbelagd information.

A.12.6.2 Begränsningar för programvaruinstallation

Regler som styr användarnas installation av programvara måste upprättas och implementeras. Denna kontroll avser att begränsa användarnas möjlighet att installera programvara, särskilt på lokala enheter (arbetsstationer, bärbara datorer etc). Installation av programvara av användare väcker ett antal hot och sårbarheter, inklusive hotet om introduktion av skadlig programvara och det potentiella brottet mot mjukvarulicenser/IPR-lagar. Helst skulle användare inte kunna installera någon programvara på organisationsutrustning, men det kan finnas affärsmässiga eller praktiska skäl till varför detta inte är möjligt.

Om fullständig begränsning inte är möjlig är det god praxis att "vitlista" vilken programvara som kan installeras. Revisorn kommer att kontrollera vilka restriktioner som har lagts på installationen av programvara av användare. Sedan, där fullständig begränsning inte implementeras, kommer de att vilja se bevis för att riskerna har utvärderats fullt ut och där det är möjligt har kompletterande kontroller som regelbundna mjukvarurevisioner implementerats och används regelbundet.

Vad är syftet med bilaga A.12.7?

Bilaga A.12.7 handlar om informationssystem och revisionsöverväganden. Målet i detta bilaga A-område är att minimera inverkan av revisionsverksamhet på operativa system.

A.12.7.1 Revisionskontroller för informationssystem

Revisionskrav och aktiviteter som involverar verifiering av verksamhetssystem måste planeras noggrant och komma överens om för att minimera störningar i affärsprocesserna. Närhelst man utför tester och revisionsaktiviteter (t.ex. sårbarhetsskanningar, penetrationstester etc) på operativa system, måste man överväga att säkerställa att verksamheten inte påverkas negativt. Dessutom måste testningens omfattning och djup definieras. All sådan revision eller testning av operativa system måste ske genom en formell och på lämpligt sätt auktoriserad process. Revisorn kommer att leta efter bevis för att schemaläggningen av tester och testnivån är överenskommen och godkänd genom en formell process.