Snesevis af designfejl i OT-produkter

OT:ICEFALL-rapporten viser, at producenter af operationel teknologi er nødt til at forbedre sikkerheden på deres enheder.

Et nyt forskningsprojekt har afdækket 56 sårbarheder i operationelle teknologienheder (OT) fra 10 forskellige leverandører, som alle stammer fra designet eller funktionalitet snarere end programmeringsfejl. Dette fremhæver, at på trods af den øgede opmærksomhed, denne type kritiske enheder har modtaget i løbet af det sidste årti fra både sikkerhedsanalytikere og hackere, følger branchen stadig ikke grundlæggende principper for sikkert design.

“Udnyttelse af disse sårbarheder, kan hackere med netværksadgang til en målenhed eksternt udføre kode, ændre logikken, filer eller firmware på OT-enheder, omgå godkendelse, kompromittere legitimationsoplysninger, forårsage denials of service eller have en række operationelle virkninger,” siger analytikere fra sikkerhedsfirmaet Forescout i deres nye rapport.

De identificerede sikkerhedsproblemer, samlet kaldet OT:ICEFALL, stammer fra usikre tekniske protokoller, svage kryptografiske implementeringer eller ødelagte godkendelsesordninger, usikre firmwareopdateringsmekanismer og forkert beskyttet native funktionalitet, der kan misbruges til fjernudførelse af kode. 14% af de afslørede sårbarheder kan resultere i fjernudførelse af kode, og yderligere 21% kan føre til firmwaremanipulation.

Et andet interessant resultat af denne forskning var, at mange af de sårbare enheder var blevet certificeret i henhold til forskellige standarder, der gælder for OT-miljøer som IEC 62443, NERC CIP, NIST SP 800-82, IEC 51408 / CC, IEC 62351, DNP3 Security, CIP Security og Modbus Security.

“Mens disse standarddrevne hærdningsbestræbelser helt sikkert har bidraget til store forbedringer inden for udvikling af sikkerhedsprogram, risikostyring og design- og integrationsaktiviteter på arkitekturniveau, har disse bestræbelser været mindre vellykkede med at modne sikre udviklingslivscyklusser for individuelle systemer og komponenter,” Konkludere analytikerne.

En historie om usikkert design i OT

Forescout-analytikerne drager sammenligninger mellem deres resultater og resultaterne fra Project Basecamp, et forskningsprojekt fra 10 år siden, der fokuserede på at afsløre usikre designproblemer i fjernterminalenheder (RTU’er), programmerbare logiske controllere (PLC’er) og andre controllere, der udgør SCADA-systemerne (Supervisory Control and Data Acquisition), der anvendes i industrielle installationer.

Derefter, efter opdagelsen af sofistikerede trusler som Stuxnet udviklet af nationalstater til at målrette PLC’er, satte forskerne, der deltog i Project Basecamp, sig for at ændre, hvad de sagde havde været “et årti med passivitet” af ICS-producenter og aktivejere efter 9/11. Et årti senere viser OT:ICEFALL, at mange af de samme problemer, såsom obskure proprietære protokoller, der mangler korrekt godkendelse og kryptering, fortsat er en almindelig forekomst i de enheder, der kører vores kritiske infrastruktur.

“De produkter, der er berørt af OT:ICEFALL, er kendt for at være udbredt i industrier, der er rygraden i kritiske infrastrukturer som olie og gas, kemisk, nuklear, elproduktion og distribution, fremstilling, vandbehandling og distribution, minedrift og bygningsautomatisering,” siger Forescout-analytikerne i deres rapport. “Mange af disse produkter sælges som ‘secure by design’ eller er certificeret med OT-sikkerhedsstandarder.”

Mens denne tilstand af usikkerhed som standard er fortsat i OT-verdenen, er antallet af angreb kun steget og udviklet sig. Siden Stuxnet har vi set Industroyer-angrebet, der forårsagede strømafbrydelser i Ukraine i 2016, TRITON-malwaren, der blev brugt i forsøg på sabotage af petrokemiske anlæg i Saudi-Arabien i 2017, Industroyer2-malware, der blev brugt mod elektrisk transformerstation i Ukraine i år, og INCONTROLLER APT-værktøjssættet. ICS-sikkerhedsfirmaet Dragos sporer 19 trusselsgrupper, der er målrettet mod ICS-miljøer, herunder tre, der blev opdaget sidste år og viste evnen til at få adgang til ICS / OT-netværk.

OT: ICEFALL-fejlene påvirker enheder fra Bently Nevada, Emerson, Honeywell, JTEKT, Motorola, Omron, Phoenix Contact, Siemens og Yokogawa. De omfatter tilstandsmonitorer, distribuerede kontrolsystemer (DCS), tekniske arbejdsstationer, RTU’er, PLC’er, bygningscontrollere, sikkerhedsinstrumenterede systemer (SIS), SCADA-systemer, protokoller og endda en logisk runtime.

Den logiske runtime er den software, der fortolker og udfører stigelogikken – koden skrevet af ingeniører til at handle på enhedens input og output. ProConOS-runtime fra Phoenix Contact bruges for eksempel i flere PLC’er fra forskellige leverandører, hvilket gør de fejl, der er opdaget i den – mangel på kryptografisk godkendelse af den uploadede logik – en potentiel forsyningskæderisiko, der fører til vilkårlig kodeudførelse.

“På grund af manglen på softwareregninger af materialer (SBOMs) og kompleksiteten af produktforsyningskæder, er det ofte ikke umiddelbart klart, hvilken runtime en bestemt PLC bruger,”Forskerne sagde i deres rapport. “Runtimes har typisk forskellige versioner med tilsvarende protokolforskelle og er underlagt OEM-integrationsbeslutninger. En PLC-producent kan vælge at bruge runtime, men ikke protokollerne, og foretrækker at bruge sin egen, eller kan vælge at bruge protokollen på en ikke-standardport eller kan vælge at rebrande eller ændre runtime helt. Uden proaktiv, koordineret indsats fra leverandører, CVE-nummereringsmyndigheder og CERT’er for at udbrede viden om sårbarheder i forsyningskæden til alle berørte parter, er sikkerhedssamfundet tvunget til at genopdage dem med jævne mellemrum og tilfældigt, hvilket resulterer i CVE-duplikering og komplicerer årsagsanalyse.

For eksempel var to CVE’er, der tidligere blev tildelt problemer i ProConOS-runtime – CVE-2014-9195 og CVE-2019-9201 – kun knyttet til Phoenix Contact PLC’er, mens de også påvirkede andre leverandører. Et problem blev opdaget senere i Yokogawa STARDOM-controllere og blev tildelt CVE-2016-4860, men det er faktisk det samme problem som CVE-2014-9195, siger forskerne. Problemet forværres yderligere af det faktum, at mange usikre som standardproblemer som dem, der er inkluderet i OT: ICEFALL, tidligere slet ikke modtog CVE-id’er, da de ikke blev betragtet som traditionelle sårbarheder, hvilket gjorde det svært for kunderne at spore dem.

Afbødning af ot-enhedssårbarheder

Forescout-teamet har arbejdet sammen med US Cybersecurity and Infrastructure Security Agency (CISA) under afsløringsprocessen, og agenturet har offentliggjort sine egne rådgivninger for nogle af problemerne. Aktivejere bør installere programrettelser og firmwareopdateringer, når enhedsproducenter gør dem tilgængelige, men at løse nogle af de identificerede problemer kan indebære en betydelig teknisk indsats og ændringer, så leverandører muligvis ikke adresserer dem i lang tid. I mellemtiden anbefaler Forescout-teamet følgende afbødningstrin:

• Opdag og lagerfør sårbare enheder. Netværkssynlighedsløsninger muliggør opdagelse af sårbare enheder i netværket og anvender korrekte kontrol- og afbødningshandlinger.
• Håndhæv segmenteringskontroller og korrekt netværkshygiejne for at mindske risikoen fra sårbare enheder. Begræns eksterne kommunikationsveje, og isoler eller indebar sårbare enheder i zoner som en afbødende kontrol, hvis de ikke kan patches, eller indtil de kan patches. Gennemgå firewallregler, især hvidlistede OT-protokoller, i forhold til SMV’ers viden. Nogle leverandører tilbyder dedikerede firewalls og switche med protokolbevidste sikkerhedsfunktioner.
• Overvåg progressive programrettelser, der frigives af berørte enhedsleverandører, og udarbevis en afhjælpningsplan for din sårbare aktivbeholdning, der afbalancerer forretningsrisiko og forretningskontinuitetskrav.
• Overvåg al netværkstrafik for mistænkelig aktivitet, der forsøger at udnytte funktionaliteten, der er usikker efter design. Brug overvågningsløsninger med DPI-funktioner til at advare sikkerhedspersonale om disse aktiviteter, så der kan træffes passende foranstaltninger.
• Indkøb aktivt efter secure-by-design-produkter, og migrer til secure-by-design-varianter af produkter, hvor det er tilgængeligt, og når det er muligt. Evaluer enhedens sikkerhedsstilling ved at inkludere sikkerhedsevalueringer i indkøbskrav.
• Gør brug af indbyggede hærdningsfunktioner såsom fysiske tilstandsafbrydere på controllere, der kræver fysisk interaktion, før farlige tekniske operationer kan udføres. Nogle leverandører tilbyder plug-and-play-løsninger til at simulere disse funktioner på netværksniveau for flere controllere. Hvis det er muligt, skal du aktivere advarsler om driftstilstandsomskift til overvågningsløsninger.
• Arbejde hen imod konsekvensreduktion ved at følge Cyber-PHA- og CCE-metoder. Dette er vigtigt for ikke kun at imødegå sandsynligheden, men også konsekvenserne af hændelser.

Kilde: CSOonline

Foto: Pexels