Trots att utrustning för operativ teknik har har fått ökad uppmärksamhet under det senaste årtiondet – både från säkerhetsexperter och angripare – så tillämpar branschen fortfarande inte principerna för hur it-säkerhet byggs in från grunden.

– Genom att utnyttja dessa sårbarheter kan angripare som genom nätverket har access till en del av utrustningen exekvera kod på distans, förändra logiken, filerna eller de fasta programmen i OT-utrustning, kringgå autentisering, kompromettera inloggningsuppgifter, ställa till med funktionsförlust eller drabba driften på många andra sätt, skriver forskare på it-säkerhetsföretaget Forescout i rapporten OT:Icefall.

De upptäckta säkerhetsproblemen beror på osäkra tekniska protokoll, svag tillämpning av kryptografi eller trasiga autentiseringsupplägg, osäkra mekanismer för uppdatering av fasta program och bristfälligt skyddad inbyggd funktion som kan missbrukas för exekvering av kod på distans. 14 procent av de avslöjade sårbarheterna kan leda till exekvering av kod på distans och 21 procent kan användas för manipulering av fasta program.

En annan tankeväckande upptäckt var att många av de sårbara anordningarna hade certifierats i enlighet med olika standarder som gäller för OT-miljöer. Till exempel IEC 62443, NERC CIP, NIST SP 800-82, IEC 51408/CC, IEC 62351, DNP3 Security, CIP Security och Modbus Security.

”Även om dessa standardbaserade satsningar på förstärkning förvisso har bidragit till viktiga förbättringar inom områden som utveckling av säkerhetsprogram, riskhantering och verksamhet för design och integrering på arkitekturnivå, så har satsningarna inte varit lika framgångsrika när det gäller att få fram mogna utvecklingslivscykler för individuella system och komponenter”, konstaterar forskarna.

OT har en historia av inbyggd osäkerhet

Forskarna på Forescout gör jämförelser mellan sina resultat och de som gjordes av Project Basecamp. Det var ett projekt som för tio år sedan var inriktat på att hitta inbyggda problem i fjärrkontrollterminaler, programmerbara styrsystem och andra styrenheter som ingår i Scada-system (supervisory control and data acquisition) som används i industriella anläggningar.

Efter upptäckten av avancerade hot som Stuxnet, utvecklade av stater för angrepp mot programmerbara styrsystem (PLC:er), bestämde sig forskarna som deltagit i Project Basecamp för att förändra det som de kallade för ”ett decennium av overksamhet” bland tillverkare av industriella styrsystem och ägare av styrsystem efter 9/11. Ett decennium senare visar OT:Icefall att samma problem i många fall, till exempel dunkla, företagsspecifika protokoll som saknar korrekt autentisering och kryptering, fortfarande är allmänt förekommande i den utrustning som hanterar vår kritiska infrastruktur.

”Produkterna som påverkas av OT:Icefall är kända som vanligt förekommande i branscher som är grunden för kritisk infrastruktur som olja och gas, kemisk industri, kärnkraft, generering och distribution av elkraft, tillverkningsindustri, behandling och distribution av vatten, gruvdrift och fastighetsautomatisering”, skriver Forescout-forskarna i rapporten:

”Många av dessa produkter säljs som ’secure by design’ eller har certifierats i enlighet med standarder för OT-säkerhet.”

Samtidigt som detta tillstånd av osäkerhet som standard har fått fortleva i OT-världen har attackerna bara blivit fler och mer avancerade. Efter Stuxnet har vi upplevt Industroyer-attacken som orsakade strömavbrott i Ukraina 2016, skadeprogrammet Triton som användes i försök att sabotera petrokemiska anläggningar i Saudiarabien 2017, Industroyer2 som användes mot ett elkraftverk i Ukraina nu i år samt verktygslådan Incontroller Apt. Dragos, ett it-säkerhetsföretag inriktat på industriella system, har kartlagt 19 hotgrupper) inriktade på industriella miljöer. Tre av dem upptäcktes i fjol och visade sig kunna komma in i industriella styrsystem och nätverk.

Bristerna som upptäckts i OT:Icefall drabbar utrustning från Bently Nevada, Emerson, Honeywell, JTEKT, Motorola, Omron, Phoenix Contact, Siemens och Yokogawa. Det gäller tillståndsövervakning, distribuerade styrsystem (DCS), arbetsstationer för ingenjörer, fjärrstyrningsenheter, programmerbara styrsystem, styrsystem för byggnader, säkerhetsinstrumenterade system (SIS), Scada-system, protokoll och även exekverbar kod.

Den exekverbara koden är mjukvaran som tolkar och exekverar ladderdiagrammet – koden som konstruktörerna skriver för hur indata och utdata för utrustningen ska hanteras. Koden ProconOS från Phoenix Contact, för att ta ett exempel, används i flera programmerbara styrsystem från olika leverantörer. Det gör att bristerna som har upptäckts i det – avsaknad av kryptografisk autentisering av inläst logik – en potentiell risk i leveranskedjan, vilket kan leda till manipulation av kodexekveringen.

”Eftersom det saknas stycklistor för mjukvaran, och på grund av leveranskedjans komplexitet, är det ofta inte alltid så klart vilken exekveringskod ett visst programmerbart styrsystem använder”, skriver forskarna i rapporten:

”Koden brukar finnas i olika versioner med motsvarande skillnader i protokoll, och de är underkastade beslut av den faktiska tillverkaren. En tillverkare av programmerbara styrsystem kan välja att köra koden, men inte protokollet. Den kan föredra ett eget protokoll, eller välja att köra protokollet genom en annan port än standard, eller kanske välja att märka om eller göra om exekveringskoden helt och hållet. Så länge det inte finns proaktiva, samordnade satsningar från leverantörer, CVE-organ och CERT för spridning av kunskaper av sårbarheter i leveranskedjan till alla som påverkas kommer säkerhetsbranschen att vara tvungen att återupptäcka dem med jämna mellanrum och slumpmässigt. Det leder till CVE-dubbleringar och komplicerar analysen av ursprung.” (CVE – Common vulnerabilities and exposures – är standardiserade namn på sårbarheter.)

Till exempel var två CVE:er som tidigare tilldelats problem i ProconOS-koden – CVE-2014-9195 och CVE-2019-9201 – bara förknippade med det programmerbara styrsystemet Phoenix Contact, men de drabbade även andra leverantörer. Ett problem upptäcktes senare i styrsystem från Yokogawa Stardom. Det fick beteckningen CVE-2016-4860, men det var i själva verket samma som CVE-2014-9195, allt enligt undersökningen. Problemet förvärras ytterligare av det faktum att många inbyggda säkerhetsproblem i stil med de som nämns i OT:Icefall inte har fått några CVE-id alls. De sågs inte som traditionella sårbarheter, och därför blev det svårt för kunderna att spåra dem.

Att motverka sårbarheter i OT-utrustning

Forescout-teamet samarbetade med USA:s cybersäkerhetsmyndighet Cisa under arbetet, och har gett ut egna råd angående några av problemen. Alla som har OT-utrustning bör installera patchar och uppdateringar av fasta program när tillverkarna gör dem tillgängliga. Men att korrigera några av de upptäckta problemen kan kräva avsevärda ansträngningar och ändringar, så leverantörerna kanske inte tar itu med dem snart. Medan vi väntar rekommenderar Forescout-teamet dessa motverkande åtgärder:

  • Hitta och inventera sårbar utrustning. Visibilitetslösningar för nätverk gör att man kan upptäcka sårbar utrustning i nätverket och sedan vidta lämpliga åtgärder..
  • Se till att det finns segmentering och korrekt nätverkshygien så att riskerna med sårbar utrustning motverkas. Begränsa möjligheterna till extern kommunikation och isolera eller stäng in sårbar utrustning i särskilda zoner ifall de inte kan patchas, eller tills de kan patchas. Se över brandväggsregler, särskilt frilistade OT-protokoll, i samråd med expertis. En del leverantörer kan erbjuda dedikerade brandväggar och switchar med protokollkänsliga säkerhetsfunktioner.
  • Bevaka patchar från berörda leverantörer av utrustning och ta fram en åtgärdsplan för företagets sårbara utrustning. Väg riskerna för verksamheten mot kraven på obruten drift.
  • Övervaka all trafik i nätverket för misstänkta aktiviteter som försöker utnyttja inbyggda säkerhetsbrister. Använd övervakningssystem med kapacitet för djup paketinspektion för att varsko säkerhetspersonalen om sådant, så att lämpliga motåtgärder kan vidtas.
  • Gå aktivt in för att skaffa produkter som har säkerhet inbyggd från grunden och migrera till sådana produkter om de finns och om det är möjligt. Utvärdera säkerhetshållningen gällande utrustning genom att ta med säkerhetsutvärdering i kravlistorna för inköp.
  • Dra nytta av inbyggda förstärkningsmöjligheter som mekaniska lägesomställare på styrsystem så att det krävs mänsklig medverkan för att riskfyllda tekniska åtgärder ska kunna utföras. En del leverantörer kan erbjuda nyckelfärdiga lösningar som kan simulera sådana möjligheter på nätverksnivå för multipla styrsystem. Varhelst det är möjligt, aktivera aviseringar på lägesomställningar i övervakningssystem.
  • Sträva efter konsekvensreduktion genom att följa metoderna Cyber-PHA och CCE. Detta är viktigt för att hantera inte bara sannolikheten för, utan också effekterna av incidenter.