ISO 27001 – Bijlage A.12: Operationele beveiliging

Wat is het doel van bijlage A.12.1?

Bijlage A.12.1 gaat over operationele procedures en verantwoordelijkheden. Het doel van dit bijlage A-gebied is het garanderen van een correcte en veilige werking van informatieverwerkingsfaciliteiten. Het is een belangrijk onderdeel van het informatiebeveiligingsbeheersysteem (ISMS), vooral als u de ISO 27001-certificering wilt behalen. Laten we deze vereisten en wat ze betekenen nu wat dieper begrijpen.

A.12.1.1 Gedocumenteerde operationele procedures

Bedieningsprocedures moeten worden gedocumenteerd en vervolgens beschikbaar worden gesteld aan alle gebruikers die ze nodig hebben. Gedocumenteerde operationele procedures helpen bij het garanderen van een consistente en effectieve werking van systemen voor nieuw personeel of veranderende resources, en kunnen vaak van cruciaal belang zijn voor noodherstel, bedrijfscontinuïteit en wanneer de beschikbaarheid van personeel in gevaar komt. Wanneer informatiesystemen “op de cloud gebaseerd” zijn, worden traditionele operationele activiteiten zoals het opstarten, afsluiten, back-uppen enz. van het systeem minder relevant en kunnen deze vaak worden uitbesteed aan een cloudprovider. In meer traditionele computeromgevingen en -architecturen zijn operationele procedures veel vaker vereist.

Het is belangrijk dat documenten in een correcte en actuele staat worden gehouden en daarom moeten worden onderworpen aan formeel verandermanagement en periodieke beoordelingsprocedures. Dit is van cruciaal belang, aangezien de auditor hier specifiek naar zal kijken.

We krijgen vaak de vraag hoeveel details er nodig zijn en welke onderdelen van het bedrijf gedocumenteerde procedures nodig hebben. Kies voor een aanpak met gezond verstand. Als u bijvoorbeeld over echte personeelsstabiliteit beschikt, de impliciete procedures zeer goed worden begrepen en er veerkracht aanwezig is in de hele resourcepool, kunnen eenvoudige opsommingen voldoende zijn om een ​​gedocumenteerde procedure in de stijl van een checklist te vormen.

Op dezelfde manier wilt u, als procedures evolueren of regelmatig veranderen, bijvoorbeeld vanwege snelle groei, beschikken over procedures die ook gemakkelijk en snel kunnen worden bijgewerkt. Ook als er veel nieuwe middelen worden toegevoegd en het gebied risico's en complexiteit met zich meebrengt, kan er meer diepgang in de procedures nodig zijn, zodat het ondubbelzinnig is over wat, wanneer, hoe, wie enz.

De gebieden van het bedrijf waarmee rekening moet worden gehouden voor gedocumenteerde procedures moeten de gebieden zijn waar uw informatiemiddelen gevaar lopen door onjuist gebruik, wat uiteraard zal worden geïdentificeerd als onderdeel van de risicobeoordeling in overeenstemming met 6.1. Dat kan softwareontwikkeling, IT-beheer, financiële boekhouding, klantenbeheer, advies- of productiewerkzaamheden enz. omvatten, afhankelijk van de aard van het bedrijf.

A.12.1.2 Wijzigingsbeheer

De organisatie, bedrijfsprocedures, informatieverwerkingsfaciliteiten en systemen die van invloed zijn op de informatiebeveiliging moeten worden beheerst. Goed gecontroleerd wijzigingsbeheer is in de meeste omgevingen van essentieel belang om ervoor te zorgen dat wijzigingen passend, effectief en op de juiste manier geautoriseerd zijn en op een zodanige manier worden uitgevoerd dat de kans op kwaadwillige of onbedoelde compromittering wordt geminimaliseerd. Verandermanagement is van toepassing op de hele organisatie, haar processen, informatieverwerkingsfaciliteiten, netwerken, systemen en applicaties.

Auditlogboeken zijn vereist om bewijs te leveren van het juiste gebruik van wijzigingsprocedures. De auditor zal erop willen wijzen dat wijzigingsprocedures niet al te ingewikkeld hoeven te zijn, maar passend moeten zijn bij de aard van de verandering die wordt overwogen. U kunt eenvoudigweg bewijsmateriaal vastleggen van wijzigingen en wijzigingen in het versiebeheer, of een veel diepgaander, complexer wijzigingsbeheer uitvoeren en omscholing en communicatie omvatten, evenals aanzienlijkere investerings- en aftekenprocessen.

A.12.1.3 Capaciteitsbeheer

Het gebruik van hulpbronnen moet worden gemonitord en afgestemd en er moeten projecties worden gemaakt van toekomstige capaciteitsvereisten om de vereiste systeemprestaties te garanderen om aan de bedrijfsdoelstellingen te voldoen. Capaciteitsbeheer kijkt doorgaans naar drie primaire typen; Gegevensopslagcapaciteit – (bijv. in databasesystemen, bestandsopslagruimten enz.); Verwerkingscapaciteit – (bijv. voldoende rekenkracht om tijdige verwerkingsoperaties te garanderen); en communicatiecapaciteit – (vaak “bandbreedte” genoemd om ervoor te zorgen dat de communicatie tijdig plaatsvindt).

Capaciteitsmanagement moet ook; Proactief – bijvoorbeeld het inzetten van capaciteitsoverwegingen als onderdeel van verandermanagement; Reactief – bijvoorbeeld triggers en waarschuwingen voor wanneer het capaciteitsgebruik een kritiek punt bereikt, zodat tijdige verhogingen, tijdelijk of permanent, kunnen worden doorgevoerd.

A.12.1.4 Scheiding van ontwikkelings-, test- en operationele omgevingen

Goed beleid voor ontwikkelings-, test- en operationele omgevingen zou bevestigen dat deze gescheiden moeten worden om de risico's van ongeoorloofde toegang of wijzigingen in de operationele omgeving te verminderen. Het gescheiden houden van ontwikkel-, test- en live operationele IT-omgevingen is een goede gewoonte, omdat dit helpt bij het scheiden van taken en ongeautoriseerde toegang tot de live omgeving en gegevens. Veranderingen en nieuwe ontwikkelingen moeten grondig worden getest in een aparte ruimte voordat ze worden ingezet in de live operationele omgeving.

Idealiter zou ontwikkelingspersoneel geen toegang moeten hebben tot de live-omgeving, maar dit is misschien niet mogelijk, vooral niet in kleine organisaties. Eenmaal gescheiden is het belangrijk om te controleren of testers niet per ongeluk (of opzettelijk) testomgevingen als live gebruiken. De auditor zal controleren of ontwikkelings-, test- en live-omgevingen gescheiden zijn en of er formele procedures zijn, inclusief passende autorisatieniveaus voor het verplaatsen van veranderingen en ontwikkelingen van de ene omgeving naar de andere.

Wat is het doel van bijlage A.12.2?

Bijlage A.12.2 gaat over bescherming tegen malware. Het doel hiervan is ervoor te zorgen dat informatie en informatieverwerkingsfaciliteiten worden beschermd tegen malware.

A.12.2.1 Controles tegen malware

Er moeten detectie-, preventie- en herstelcontroles worden geïmplementeerd ter bescherming tegen malware, gecombineerd met het juiste gebruikersbewustzijn. Dit is een onderdeel waarover de meeste organisaties een bepaald niveau van bewustzijn, begrip en implementatie hebben. Bescherming tegen malware kan echter een aantal verschillende vormen aannemen, afgezien van de voor de hand liggende “antivirussoftware”.

Andere controles, zoals beperkingen rond het gebruik van verwisselbare media of beperkingen op de installatie van software door gebruikers – die het gebruik van ongeautoriseerde software helpen voorkomen – zijn ook waardevol. Het tijdig patchen van bekende systeem- en softwarekwetsbaarheden is ook van cruciaal belang. Vaak zijn virussen ontworpen om te zoeken naar niet-gepatchte systemen en software waarin bekende kwetsbaarheden zich kunnen bevinden. Het is belangrijk dat eventuele malwarebescherming up-to-date wordt gehouden, zowel wat betreft relevante ‘handtekeningbestanden’ als de software zelf.

Wat is het doel van bijlage A.12.3?

Bijlage A.12.3 gaat over back-up. Het doel is om te beschermen tegen verlies van gegevens.

A.12.3.1 Informatieback-up

Om de waardevolle informatie tegen verlies te beschermen, beschrijft een goede controle hoe back-ups van informatie, software en systeemimages regelmatig moeten worden gemaakt en getest volgens een overeengekomen back-upbeleid.

Back-upregimes moeten worden ontworpen op basis van de bedrijfsvereisten en risiconiveaus met betrekking tot de onbeschikbaarheid van informatie. Het is dus belangrijk om ervoor te zorgen dat dergelijke regimes daadwerkelijke behoeften ondersteunen en niet alleen maar zijn “wij maken back-ups”. Wanneer back-ups worden gemaakt, moet de informatie minimaal op hetzelfde niveau worden beschermd als de live-gegevens en moet deze buiten de live-omgeving worden opgeslagen om het risico te minimaliseren dat een enkel compromis zowel de live-omgeving als de back-ups kapot maakt.

Het regelmatig testen van back-ups is van cruciaal belang om ervoor te zorgen dat herstelwerkzaamheden succesvol zijn en tijdig worden uitgevoerd. Het monitoren en vastleggen van back-ups moet worden geïmplementeerd om ervoor te zorgen dat deze plaatsvinden in overeenstemming met het back-upbeleid. Slimme auditors zullen rapporten willen zien over mislukte back-ups en tests die zijn uitgevoerd om er zeker van te zijn dat ze werken zoals verwacht. Er moet een back-upbeleid worden overwogen rond wat, waar vandaan en waarheen, wie, wanneer – rekening houdend met kantoor- en thuiswerkers, mobiel enz. waar er overwegingen zijn over mobiele en verwijderingsopslagback-ups die verhoogde risico’s met zich meebrengen in het geval van verlies dat mogelijk is aangepakt via encryptie of andere controles.

Wat is het doel van bijlage A.12.4?

Bijlage A.12.4 gaat over logging en monitoring. Het doel in dit bijlage A-gebied is het vastleggen van gebeurtenissen en het genereren van bewijsmateriaal.

A.12.4.1 Gebeurtenisregistratie

Gebeurtenislogboeken waarin gebruikersactiviteiten, uitzonderingen, fouten en informatiebeveiligingsgebeurtenissen worden vastgelegd, moeten regelmatig worden aangemaakt, bijgehouden en beoordeeld. Registratie- en monitoringmechanismen vormen een belangrijk onderdeel van een ‘diepgaande verdediging’-strategie voor beveiligingsbeheer, omdat ze zowel detectie- als onderzoeksmogelijkheden bieden. Er kunnen allerlei soorten gebeurtenislogboeken nodig zijn, bijvoorbeeld systeemlogboeken, toegangscontrolelogboeken, enz., vooral met betrekking tot incidentbeheer en audits. Logboeken zullen vaak potentieel grote hoeveelheden informatie moeten opslaan, dus het is belangrijk dat er capaciteitsoverwegingen worden gemaakt.

A.12.4.2 Bescherming van loginformatie

Logfaciliteiten en loginformatie moeten worden beschermd tegen manipulatie en ongeoorloofde toegang. Het is ook van cruciaal belang om ervoor te zorgen dat logboeken op een veilige en manipulatiebestendige manier worden opgeslagen, zodat elk bewijsmateriaal dat daaruit voortkomt op een bewijsbare manier kan worden bewezen. Dit is vooral belangrijk bij elke vorm van juridische procedures met betrekking tot bewijsmateriaal uit het logboek. Omdat logs potentieel grote hoeveelheden gevoelige gegevens kunnen bevatten, is het belangrijk dat deze adequaat worden beschermd en beveiligd. Het is ook belangrijk om te overwegen dat als de logs persoonlijk identificeerbare informatie bevatten, wat vrijwel zeker het geval zal zijn, zoals gebruikers-ID en de acties die door die UID worden uitgevoerd, deze waarschijnlijk onder de vereisten van de wetgeving inzake gegevensbescherming en privacy vallen, inclusief het bewaren van gegevens. .

A.12.4.3 Beheerder- en operatorlogboeken

Een goede controle beschrijft hoe alle activiteiten van de systeembeheerder en systeemoperator moeten worden vastgelegd en dat de logboeken moeten worden beschermd en regelmatig moeten worden beoordeeld. Er moet speciale aandacht worden besteed aan hogere niveaus van logboekregistratie voor geprivilegieerde accounts, zoals systeembeheerders en operators.

A.12.4.4 Kloksynchronisatie

De klokken van alle relevante informatieverwerkende systemen binnen een organisatie of beveiligingsdomein moeten worden gesynchroniseerd met één referentietijdbron. Synchronisatie van de systeemklok is belangrijk, vooral bij het aantonen van gebeurtenissen als onderdeel van een onderzoek of juridische procedure, omdat het vaak onmogelijk of zeer moeilijk is om “oorzaak en gevolg” te bewijzen als klokken niet correct zijn gesynchroniseerd. De auditor zal er bijzondere aandacht aan besteden om er zeker van te zijn dat dit is gebeurd.

Wat is het doel van bijlage A.12.5?

Bijlage A.12.5 gaat over de beheersing van operationele software. Het doel op dit gebied van bijlage A is het waarborgen van de integriteit van operationele systemen.

A.12.5.1 Installatie van software op besturingssystemen

Er moeten procedures worden geïmplementeerd om de installatie van software op operationele systemen te controleren. Zoals bij elke beveiligingsgerelateerde controle is het belangrijk dat de installatie van software op operationele systemen formeel wordt gecontroleerd. Hoewel dit misschien niet altijd mogelijk is, vooral niet in kleine organisaties, blijft het principe waar. Problemen die verband houden met de ongepaste installatie of wijziging van software op operationele systemen kunnen zijn: Met malware geïnfecteerde software wordt geïnstalleerd; Capaciteitsproblemen; of Software die ervoor kan zorgen dat kwaadaardige insideractiviteiten worden geïnstalleerd (bijvoorbeeld hacktools). Naast het beperken en beperken van de installatie van software op operationele systemen, is het ook belangrijk om de legitieme installatie formeel te controleren.

Het is een goede praktijk om waar mogelijk te garanderen dat bijvoorbeeld; Formeel veranderingsmanagement heeft plaatsgevonden, inclusief passende autorisatieniveaus; Er zijn procedures voor terugdraaiing; en Eerdere versies van software en wijzigingsgeschiedenis worden veilig bewaard. Bij elke verandering moet rekening worden gehouden met zowel de bedrijfsvereisten als de beveiligingsvereisten en -risico's, in overeenstemming met de formele procedures voor veranderingsbeheer. De auditor verwacht dat hij gegevens ziet van softwarewijzigingen en installaties die zijn bijgehouden en die hij wil inspecteren/bemonsteren.

Wat is het doel van bijlage A.12.6?

Bijlage A.12.6 gaat over technisch kwetsbaarheidsbeheer. Het doel op dit gebied van bijlage A is het voorkomen van misbruik van technische kwetsbaarheden.

A.12.6.1 Beheer van technische kwetsbaarheden

Informatie over technische kwetsbaarheden van de gebruikte informatiesystemen moet tijdig worden verkregen, de blootstelling van de organisatie aan dergelijke kwetsbaarheden moet worden geëvalueerd en passende maatregelen moeten worden genomen om het daarmee samenhangende risico aan te pakken. Elke kwetsbaarheid is een zwakte in de beveiliging en moet effectief en efficiënt worden aangepakt als de risiconiveaus onaanvaardbaar zijn. Technische kwetsbaarheden vormen de kern van veel grote inbreuken op de beveiliging die in de media worden gemeld (en van inbreuken die dat niet zijn!) en daarom is het van essentieel belang dat er formeel beheerde processen op een adequaat en proportioneel niveau aanwezig zijn.

Er moet een evenwicht zijn tussen de veiligheidsvereiste van het zo snel mogelijk implementeren van kwetsbaarheidspatches en de veiligheidsvereiste van het voldoende testen van patches om de voortdurende beschikbaarheid en integriteit van systemen en het minimaliseren van incompatibiliteiten te garanderen. Bewustzijn kan ook een belangrijke rol spelen en het is daarom verstandig om een ​​communicatiestrategie te hebben die betrekking heeft op het informeren van gebruikers wanneer er kwetsbaarheden bestaan ​​die tot op zekere hoogte kunnen worden beheerd door gebruikersgedrag. De auditor verwacht te zien dat er processen zijn voor het identificeren en detecteren van kwetsbaarheden, vooral op kritieke systemen of systemen die gevoelige of geheime informatie verwerken of opslaan.

A.12.6.2 Beperkingen op software-installatie

Er moeten regels worden opgesteld en geïmplementeerd die de installatie van software door gebruikers regelen. Deze controle heeft betrekking op het beperken van de mogelijkheid van gebruikers om software te installeren, vooral op lokale apparaten (werkstations, laptops enz.). De installatie van software door gebruikers brengt een aantal bedreigingen en kwetsbaarheden met zich mee, waaronder de dreiging van de introductie van malware en de mogelijke inbreuk op de wetgeving inzake softwarelicenties/IER. Idealiter zouden gebruikers geen software op organisatieapparatuur kunnen installeren, maar er kunnen zakelijke of praktische redenen zijn waarom dit niet mogelijk is.

Als volledige beperking niet mogelijk is, is het een goede gewoonte om op een ‘witte lijst’ te zetten welke software mag worden geïnstalleerd. De auditor gaat na welke beperkingen er zijn gesteld aan de installatie van software door gebruikers. Als er dan geen volledige beperking is geïmplementeerd, zullen ze bewijs willen zien dat de risico's volledig zijn beoordeeld en dat waar mogelijk aanvullende controles zoals regelmatige software-audits zijn geïmplementeerd en regelmatig worden gebruikt.

Wat is het doel van bijlage A.12.7?

Bijlage A.12.7 gaat over informatiesystemen en auditoverwegingen. De doelstelling op dit gebied van bijlage A is het minimaliseren van de impact van auditactiviteiten op operationele systemen.

A.12.7.1 Auditcontroles van informatiesystemen

Auditvereisten en activiteiten met betrekking tot de verificatie van operationele systemen moeten zorgvuldig worden gepland en overeengekomen om verstoringen van de bedrijfsprocessen tot een minimum te beperken. Bij het uitvoeren van tests en auditactiviteiten (bijvoorbeeld kwetsbaarheidsscans, penetratietests enz.) op operationele systemen moet er rekening mee worden gehouden dat de activiteiten geen negatieve gevolgen ondervinden. Bovendien moeten de reikwijdte en diepgang van de tests worden gedefinieerd. Dergelijke audits of tests van operationele systemen moeten plaatsvinden via een formeel en op passende wijze geautoriseerd proces. De auditor zal op zoek gaan naar bewijs dat de planning van de tests en het testniveau via een formeel proces zijn overeengekomen en geautoriseerd.