Sök

Nyhetsbrev OT-Säkerhet #29 - Säker PLC, CIS Controls och OPC UA

Vad levererade egentligen projektet "Top 20 Secure PLC Coding Practices"? Går det att använda den nya versionen av CIS Controls för OT? Hur får man vilken brandvägg som helst att bryta ihop? Hur förstår man säkerheten i OPC UA? Dessa spännande frågor svarar jag på i ett sprillans nytt nyhetsbrev!

Om det är första gången du läser ett av mina nyhetsbrev kanske du undrar vad det där "OT" är som jag pratar om? OT står för Operational Technology vilket är ett syskon till IT, Information Technology. Med IT använder man teknik för att hantera information. Inom OT använder man liknande teknik men för "Operations", alltså att få fysiska saker under kontroll. Det kan exempelvis vara att styra maskiner i en fabrik, elproduktionen i ett kraftverk eller kemiska processer i ett raffinaderi. Inom IT är fokus ofta på att skydda hemligheter men inom OT blir det oftast viktigast att hålla en funktion tillgänglig och korrekt. Det innebär att säkerhetsarbetet kommer se väldigt annorlunda ut, vilket är anledningen till mina texter. Jag skrev nyligen ett inlägg på Atea-bloggen som förklarar mer.


Jag vill ge er ett stort tack för alla trevliga mejl jag får med frågor, förslag och uppmuntrande ord. Som vanligt vill jag gärna att du delar med dig av nyhetsbrevet till kollegor som kan vara intresserade! Ju fler som läser, desto bättre möjligheter får jag att producera bra innehåll framöver! Om du vill ha nyhetsbrevet i inkorgen i fortsättningen är det bara att dra ett mejl till mig på mats.karlsson-landre@atea.se. Jag lovar att din mejladress inte används till något annat än detta!


Du hittar alla tidigare utgåvor av nyhetsbrevet på www.ot-säkerhet.se. När det kommer nytt material så annonserar jag det på en massa ställen: min Linkedin-profil, i en egen LinkedIn grupp, i Facebook-gruppen Säkerhetsbubblan, på Twitter och på en egen Facebook-sida. Du kan också prenumerera via RSS på www.ot-säkerhet.se. Framöver kommer också vissa artiklar från nyhetsbreven publiceras på Ateas officiella blogg tillsammans med en del annat som jag skriver där.

Ge mig gärna mothugg, frågor eller förslag på LinkedIn där den här utgåvan delades. Tänk på att du kan hjälpa mig, mer än du kanske tror, genom att trycka "like" på artikeln och genom att dela den vidare. Tack för hjälpen!

Säker PLC-programmering?

Jag har teasat om det här ögonblicket i ett antal tidigare nyhetsbrev och nu är det här! Den 15:e juni släpptes det första skarpa resultatet från projektet "The Top 20 Secure PLC Coding Practices Project". Det här får väl sägas vara ett unikt, viktigt och roligt projekt som tydligen uppstod i samband med S4-konferensen förra året. Det har varit en rejäl gruppinsats som Sarah Fluchs var en av ledarna för. Jag rekommenderar att du läser hennes egna ord för att verkligen förstå bakgrunden och storheten i detta projekt!

Det här är verkligen ett OT-säkerhetsprojekt ända ut i fingerspetsarna. De har skapat en samling goda idéer för hur man programmerar sina PLCer med målet att höja säkerhet och tillförlitlighet ur en massa olika perspektiv. Det allmänna tänket är faktiskt lite likt CIS Controls även om innehåll och fokus är helt annorlunda. Syftet ligger väl egentligen närmare OWASPs rekommendationer för säker programmering.

Missförstå nu inte det här som att PLCn plötsligt ska kunna försvara sig mot en hacker! Nej, det handlar i första hand om att låta PLCn gör lite mer av det den redan är bra på, att hålla koll på att saker beter sig rätt och att vara väldigt stabil. Man kan väl grovt summera de tjugo punkterna i tre kategorier:

  • Validera att det som händer i den fysiska processen faktiskt borde kunna hända och att information som hanteras är korrekt. Tar rörelser rätt tid? I vilket tillstånd ska vi sätta processen efter en omstart? Är de indata vi får fysiskt möjliga? Är de inställningar som operatören gör rimliga? Här är det väldigt likt vad OWASP gör för säker IT-programmering.

  • Hur man skriver PLC-kod: modularisering, hantering av registerblock men också att faktiskt använda PLCn för all hantering istället för att som man ser ibland, låta MES-system eller liknande ta över delar av den fysiska hanteringen.

  • Härdning och robusthet: Kontroll av checksummor, blockering av oanvända ingångar och protokoll eller att begränsa åtkomst till funktioner från andra system.

Men sedan finns det faktiskt en del möjligheter till självförsvar också. En del moderna PLCer kan exempelvis hålla koll på sin egen minnesanvändning eller på cykeltiderna för programmen. Eftersom de tenderar att vara väldigt stabila över tid så kan det vara värt att larma om de plötsligt förändras, eftersom det skulle vara ett tydligt tecken på att någon förändrat någonting.

Dokumentet är föredömligt lättläst och kortfattat. Det är i egentligen en lista rätt och upp ner där var och en av de tjugo rekommendationerna på en till fyra sidor var. För var och en beskrivs:

  • Själva rekommendationen

  • Vad syftet med den är

  • Vem den vänder sig till

  • Väldigt jordnära vägledning

  • Exempel på hur den kan implementeras i PLCer från olika tillverkare

  • Argument för varför detta är en god idé för säkerhet, pålitlighet och underhåll

  • Referenser till MITRE ATT&CK for ICS och ISA 62443.

Tydligen diskuterar man med gruppen som driver "MITRE CWE" om att samarbeta mer framåt vilket ju skulle kunna vara både smart och spännande. Det finns ju en del uppenbara beröringspunkter. I dokumentet hittar du apropå det även en bra korsreferenslista till ISA 62443, MITRE ATT&CK och till CWE som kan vara värdefull.


Det här är ett projekt som kommer påverka hur PLC-tillverkarna beter sig framöver. Vi kan nog räkna med att de kommer göra allt för att underlätta användningen av de tjugo åtgärderna.


Peka dina kollegor som hanterar PLCer i vardagen till det här nyhetsbrevet och till projektet. De kanske inte ser sig som programmerare men det är de faktiskt. Vivek Ponnada skrev en bra artikel om just detta: https://www.linkedin.com/pulse/what-has-ladder-logic-got-do-cwe-vivek-ponnada/. Du hittar projektet på deras sprillans nya sida: https://www.plc-security.com/ . Vill du läsa vad andra skriver om projektet finns en bra artikel av Kelly Jackson Higgins på DarkReading.


Jag kommer med stor sannolikhet återkomma till det här ämnet i framtida nyhetsbrev om ni läsare är intresserade? Hör av dig! Har du åsikter om innehållet så vill jag väldigt gärna höra dem!

CIS Controls

Det här är fjärde delen i min serie om standarder och ramverk. Första avsnittet handlade om ISA/IEC 62443 och finns i nyhetsbrev #26. I nyhetsbrev #27 kan du läsa del två där jag tittar på NAMUR NOA. I förra nyhetsbrevet tittade jag på NIST CSF, NIST 800-53 och NIST 800-82 men du fick också lite mer om NOA. Har du önskemål om vad jag ska ta upp framöver så får du väldigt gärna höra av dig!


För några veckor sedan fick vi version 8 av "CIS Controls". Kärt barn har många namn, genom åren har vi även kallat den "CIS CSC, Critical Security Controls, CIS 20, CCS CSC, SANS Top 20 och CAG 20". Det här är helt enkelt en sammanställning av de absolut viktigaste IT-säkerhetsförmågorna och är tänkt att passa alla typer av organisationer. Fram tills nu har det varit 20 förmågor men från version 8 har man byggt om strukturen lite och gått ner till 18 stycken:

  1. Inventory and Control of Enterprise Assets

  2. Inventory and Control of Software Assets

  3. Data Protection

  4. Secure Configuration of Enterprise Assets and Software

  5. Account Management

  6. Access Control Management

  7. Continuous Vulnerability Management

  8. Audit Log Management

  9. Email Web Browser and Protections

  10. Malware Defenses

  11. Data Recovery

  12. Network Infrastructure Management

  13. Network Monitoring and Defense

  14. Security Awareness and Skills Training

  15. Service Provider Management

  16. Application Software Security

  17. Incident Response Management

  18. Penetration Testing

För var och en av de 18 förmågorna får vi en genomgång av varför den är så viktig att den kvalar in bland de 18, ett antal rutiner och verktyg som behövs för att förmågan ska bli effektiv och ett antal handgripliga åtgärder som skapar själva förmågan.

Totalt är det 153 åtgärder. "Hur ska man välja i en så lång lista?" är en berättigad fråga som har ett utmärkt svar... En viktig skillnad från tidigare versioner är att man sedan version 7.1 inte längre säger att förmågorna står i prioritetsordning. De har istället numera prioriterat åtgärderna i tre kategorier, IG1, IG2 och IG3. IG1 betraktas som "hygiennivån" som alla organisationer borde uppfylla. IG2 och IG3 bygger sedan vidare på det för större och mer riskutsatta organisationer. Personligen tycker jag steget från prioriterade förmågor till prioriterade åtgärder är helt rätt. MEN! För oss med OT-fokus är min bedömning av indelningen i de tre grupperna inte riktigt matchar vad jag normalt skulle sätta som prioritering.

Jag ska inte dyka ner i en generell genomgång av CIS Controls 8 utan rekommenderar att du tar en titt på det arbete som Christoffer Strömblad gör. Han är inte helt färdig när detta skrivs men det är på väg att bli en ambitiös genomgång av det nya upplägget inklusive översättningar till svenska vilket kan vara väldigt användbart! Tack för ditt hårda arbete Christoffer!

Har det här något med OT-säkerhet att göra då? Nix - inte på pappret! Begrepp som "OT", "ICS" eller "SCADA" nämns knappt alls. Det närmaste vi kommer är några få rader om man ska tänka på "IoT" vilket inkluderar "Industriella styrsystem". Men varför tar jag upp det här i så fall? Jo, därför att jag tycker att CIS Controls är fantastiskt användbar även om man har sina OT-glasögon på sig. Den ersätter på inget vis ISA 62443 och NIST 800-82 men den pekar fortfarande på viktiga prioriteringar, förmågor och åtgärder som är helt rätt för de flesta organisationer med OT-verksamhet!

Personligen tycker jag steget från prioriterade förmågor till prioriterade åtgärder är helt rätt. MEN! För oss med OT-fokus är min bedömning av indelningen i de tre grupperna inte riktigt matchar vad jag normalt skulle sätta som prioritering för OT-organisationer. Framför allt är det vissa åtgärder i IG2 som jag tycker är rena hygienåtgärder om man sysslar med OT. Det gäller framför allt inom förmågorna "Network Monitoring and Defense" och "Application Software Security" som helt saknar åtgärder i IG1. Men i slutändan skulle jag nog ändå gå igenom alla åtgärderna för att hitta de som är viktigast för min organisation, det är ändå bara 153 stycken.


Dels är det ju förstås så att det blir allt mer "IT" även inom "OT", vilket gör ett strukturerat IT-säkerhetsarbete jätteviktigt för OT-säkerheten. Men det är ju också så att ALLA de 18 förmågorna är helt relevanta även om man enbart stirrar på sina OT-system! Jag tycker personligen att det faktiskt är ett plus att tvingas tänka "Vad betyder det här för OT?" eftersom man hjälps hitta nya vinklar på både hot, sårbarheter och åtgärder. Vi kan ta några exempel även om jag lätt hittar OT-vinklar på alla arton:

1. Inventory and Control of Enterprise Assets och 2. Inventory and Control of Software Assets

De här två är ju egentligen helt avgörande för allt säkerhetsarbete, oavsett vad man sysslar med. Det ställer krav på ordning och reda i konstruktions- och ändringsprocesser. Det är också det här behovet som är en av drivkrafterna bakom det stora intresset för verktyg från företag som Nozomi Networks, Dragos och Radiflow. För att försvara något måste man veta att man har det. Definitivt en helt avgörande förmåga inom OT som man tycker de flesta OT-verksamheter borde vara duktiga på men i praktiken är det (i min personliga erfarenhet) snarare tvärt om...

3. Data Protection

Men den här är väl ändå inte så användbar för OT? Nej, det kan man tycka men börjar man titta på de åtgärder som ingår i här kan man hitta en del viktiga saker för OT. En vansinnigt viktig åtgärd är hanteringen av bärbara lagringsmedia. Väl värt att fundera på både rutiner och kanske verktyg för skanning av USB-minnen i stil med Impex från svenska Sysctl.


4. Secure Configuration of Enterprise Assets and Software

Definitivt en stor punkt på OT-sidan! När vi köper ny OT-utrustning har de ofta stöd för en massa bra säkerhetsfunktionalitet men det är tyvärr (i min erfarenhet) väldigt vanligt att man inte använder dem. Här är det skärpning som gäller!


7. Continuous Vulnerability Management

Med den takt som sårbarheter offentliggörs nu för tiden är det helt avgörande att man blir aktiv i hanteringen av viktiga rättningar. Här blir man ju dessutom helt beroende av att förmågorna 1 och 2 fungerar som de ska!

13. Network Monitoring and Defense

Här återkommer vi ju mycket till de verktyg som hjälper oss med punkt 1 och 2. Om vi av olika skäl inte kan använda alla de verktyg vi är vana vid från IT-världen för att STOPPA anggrepp får vi lägga desto mer krut på att att UPPTÄCKA märkligheter! Vi kanske dessutom kan använda OT-anpassade skydd i stil med