NIS2 efterlevelse for OT kan virke skræmmende og uoverskueligt - men man kommer rigtigt langt med en helt lavpraktisk tilgang uden store projekter og analyser... IT og OT sikkerhed er reelt set det samme, så tag udgangspunkt i CIS anbefalingerne, lav en screening, og tag fat på de største GAP's først!!
Med dette udgangspunkt har jeg været involveret i mange sager, omkring OT-sikkerhed. Sager der typisk er udløst af den brændende platform NIS2 direktivet har skabt. ...og risikobilledet er som hovedregel det samme (i prioriteret rækkefølge):
- Forældede / legacy systemer eller udstyr
- Manglende netværkssegregering
- Manglende adgangsstyring til OT-systemer og enheder
- Manglende sikkerhedskopiering af konfigurationer
- Mangelfuld eller ingen logning
Målet med denne - og følgende artikler - er at afmystificere compliance arbejdet og pege på vej til løsninger der virker i praksis, og som giver værdi for driften i det daglige! I denne omgang ser vi på Forældede / legacy systemer eller udstyr og Manglende netværkssegregering. Hvad betyder det - og hvad bør man gøre?
Der er naturligvis ofte mange andre findings, men i stort set alle sager jeg har været involveret i - er #1 til #4 topscorerne som risikofaktorer, mens #5 er særligt vigtig af hensyn til NIS2.
Bemærk: dette er rene 'cyber' risikomomenter - og derfor er de uomtvisteligt omfattet af NIS2. Men NIS2 rækker bredere ud, da det dækker den generelle evne til at opretholde produktion, og have sikker viden om sårbarheder. Det betyder - i mine øjne - at også fysiske produktionsanlæg, deres resiliens og nøddrift, er omfattet af NIS2 direktivet - men det er der ikke generel enighed om i branchen.
- Detaljer
- Skrevet af: Frank Jumppanen Andersen
- Kategori: compliance
- Visninger: 107
Der har altid været en udfordring med at gøre sikkerhedscompliance arbejdet relevant og værdiskabende for de operative mennesker i IT-drift - og med god grund!
De rammer man navigerer compliance efter - som f.eks ISO 2700x - er som hovedregel udarbejdet af proces og organisations mennesker, der ikke rigtigt har fingrene i de tekniske detaljer. De er ud af samme familie som ISO 900x - og fokuserer i meget høj grad på at de processer der fører frem til tiltag og korrigerende handlinger. Det vil sige de giver 'styrende' instruktioner og rammer - og ikke egentligt 'praktisk anvisende' vejledning.
Det er ikke et optimalt udgangspunkt når man gerne vil have operative mennesker til at gå ind i processen - og gerne tage ejerskab for den. Her er der brug for konkrete krav og retningslinier. Alt andet er bare træls papirarbejde for stemplets skyld. Jeg tænker at mange (som mig selv) oplever, at dem der i sidste ende skal godkende resultaterne (om det er intern / ekstern audit - eller revisorer) alligevel ikke kan gennemskue realiteterne bag de præsenterede resultater - så bare det ser pænt ud.... Det er altså op til vores egen samvittighed og ordentlighed, at sikre at disse resultater baserer sig på noget reelt.
Men min erfaring er også at de steder hvor man rent faktisk får indarbejdet de 'rigtige' rutiner som en del af det daglige driftarbejde, dér opnår man reelle forbedringer omkring styring af IT-sikkerheden, får fuld værdi gennem gennemskuelighed i operationen - og oven i købet langt bedre afstemning i forhold til forretningens behov.
...for - når man ser forbi alt det trælse med standarder, politikker, processer og procedurer - så er compliance reelt meget simpelt:
Compliance er at dokumentere at man faktisk gør det man siger man vil gøre!
Længere er den ikke! Og dét giver jo indlysende mening for de fleste
- Detaljer
- Skrevet af: Frank Jumppanen Andersen
- Kategori: compliance
- Visninger: 375
