SCADA i PLC Security: Opšte preporuke za bezbednost industrijskih kontrolnih sistema

SCADA i PLC sistemi zaslužuju fundamentalno drugačiji pristup bezbednosti od svega što je pokriveno u prethodnim serijama na ovom blogu — ne zato što su principi drugačiji, već zato što je cena greške drugačija. Kompromitovan fajl server znači izgubljene ili ukradene podatke. Kompromitovan PLC koji upravlja pumpom, pećom, ili proizvodnom linijom može značiti fizičku štetu, prekid proizvodnje koji se meri danima, ili u najgorem slučaju, opasnost po ljudske živote. Ovaj tekst pokriva opšte principe hardeninga OT (Operational Technology) i ICS (Industrial Control Systems) okruženja — nezavisno od konkretnog proizvođača opreme, sa fokusom na ono što čini ovu oblast suštinski drugačijom od standardnog IT hardeninga koji smo obrađivali kroz ostatak bloga.

Zašto se standardni IT pristup ne prenosi direktno

Ovo zaslužuje objašnjenje na samom početku, jer je izvor najvećeg broja grešaka kad IT tim prvi put pristupi OT okruženju. U IT svetu, poverljivost je tipično prioritet, dostupnost je važna ali se prekid može tolerisati (server se restartuje, servis se na kratko obnovi). U OT svetu, redosled prioriteta je obrnut — dostupnost i bezbednost fizičkog procesa dolaze prvo, jer proizvodna linija koja stane, ili sistem za tretman vode koji prestane da radi, ima direktnu, trenutnu posledicu van računarskog sistema.

Ovo se direktno prenosi na to koje alate je bezbedno koristiti. Standardni IT alat za aktivno skeniranje mreže (koji šalje pakete i očekuje odgovor da bi mapirao uređaje) može, kad se usmeri na PLC, izazvati pad ili nepredvidivo ponašanje kontrolera — mnogi PLC-ovi rade na jednostavnim, resursno ograničenim mikrokontrolerima čiji mrežni stek nikad nije dizajniran, testiran, niti otporan na neočekivan ili intenzivan saobraćaj. Isti princip važi za standardan proces zakrpa opisan kroz Windows i Linux Server hardening serije na ovom blogu — mnogi OT uređaji rade godinama, ponekad i decenijama, bez ijedne primenjene zakrpe, jer proizvođač opreme možda više i ne postoji, ili jer bilo kakva izmena zahteva potpuni, skup proces re-sertifikacije bezbednosnog sistema pre nego što se sme ponovo pustiti u rad.

Purdue model — segmentacija kao osnovni, nepregovarljiv princip

Isti princip segmentacije koji smo detaljno obradili kroz Firewall Hardening i Container Hardening serije na ovom blogu ima ovde svoju najstariju, najformalizovaniju primenu — Purdue Enterprise Reference Architecture, model koji deli industrijsko okruženje na hijerarhijske nivoe, svaki sa jasno definisanom funkcijom i strogim granicama prema susednim nivoima.

Model definiše pet osnovnih nivoa: Nivo 0 obuhvata sam fizički proces (senzori, aktuatori, motori — fizička oprema koja direktno dodiruje proizvodnju). Nivo 1 obuhvata kontrolere koji direktno upravljaju tim uređajima — PLC-ovi i RTU-ovi (Remote Terminal Unit) koji izvršavaju logiku u realnom vremenu. Nivo 2 je nadzorni sloj — HMI (Human-Machine Interface) radne stanice preko kojih operater posmatra i interveniše, SCADA serveri koji prikupljaju podatke sa PLC-ova, i inženjerske radne stanice preko kojih se PLC-ovi programiraju i konfigurišu. Nivo 3 obuhvata operativno upravljanje na nivou pogona (MES sistemi, istorijski podaci o proizvodnji). Nivoi 4 i 5 predstavljaju standardnu poslovnu IT infrastrukturu — ERP, email, standardnu kancelarijsku mrežu, sve ono što smo obrađivali kroz većinu prethodnih serija na ovom blogu.

Vredi konkretno ilustrovati zašto ova segmentacija stvarno menja ishod napada, ne samo teoretski. Ransomware koji uđe kroz kompromitovan email na Nivou 4 (standardna kancelarijska mreža) mora proći kroz DMZ firewall da bi dosegao Nivo 3 — bez pravilno postavljene segmentacije, taj korak je trivijalan, dok sa njom, ransomware jednostavno nema rutu dalje. Čak i ako bi neki servis u DMZ zoni (usled greške u konfiguraciji) bio kompromitovan, on i dalje nema mrežni put ka SCADA serverima na Nivou 2 ili PLC-ovima na Nivou 1 — fizički proces nastavlja da radi, netaknut, dok se incident ograničava i saniram na višim nivoima.

Šta treba uraditi

• Uspostaviti industrijsku DMZ zonu sa dva odvojena firewall-a — jedan na granici između poslovne IT mreže (Nivo 4/5) i DMZ-a, drugi na granici između DMZ-a i OT mreže (Nivo 3 i niže) — po istom principu dvostruke DMZ arhitekture opisanom u Firewall Hardening seriji na ovom blogu, ovde primenjenom sa još strožim, manje fleksibilnim pravilima s obzirom na posledice greške
• Nikad ne dozvoliti direktnu, rutabilnu vezu između poslovne IT mreže i PLC/SCADA opreme — svaki podatak koji mora da putuje u tom pravcu (npr. istorijski podaci o proizvodnji za ERP izveštaje) treba da prolazi kroz posrednički sistem u DMZ zoni, nikad direktno
• Segmentisati i unutar same OT mreže, ne samo na granici prema IT-ju — mikrosegmentacija (obrađena detaljnije u Firewall Hardening seriji) sprečava da kompromitacija jedne proizvodne linije ili jednog PLC-a automatski ugrozi ostatak pogona
• Tretirati granicu između Nivoa 1 (PLC-ovi) i svega iznad kao posebno strogu, gotovo nepregovarljivu — ovo je tačno površina koju su ciljali najozbiljniji, dokumentovani napadi na industrijsku infrastrukturu (Stuxnet, Industroyer), i zaslužuje najviši nivo pažnje u celoj arhitekturi

"Air-gap" je danas najčešće iluzija, ne stvarnost — planirati u skladu s tim

Vredi eksplicitno adresirati zabludu koja je nekad bila tačna, a danas retko jeste: pretpostavka da je OT mreža "air-gapped" (fizički potpuno odvojena od bilo koje spoljne mreže) i da zato ne zahteva istu pažnju kao IT infrastruktura. Savremena stvarnost — daljinski pristup za dobavljače opreme radi održavanja, integracija sa cloud analitikom, IIoT senzori koji šalju podatke ka spoljnim platformama — znači da prava, potpuna izolacija danas retko postoji, čak i u okruženjima koja je formalno "imaju" na papiru.

Šta treba uraditi

• Popisati svaku stvarnu vezu koja izlazi iz OT mreže — daljinski pristup dobavljača, USB uređaji koje inženjeri unose radi ažuriranja PLC logike, WiFi mostovi koje je neko postavio "privremeno" i zaboravio, mobilne hotspot uređaje — pre nego što se pretpostavi da je mreža zaista izolovana
• Za daljinski pristup dobavljača opreme, koristiti kontrolisan, vremenski ograničen VPN pristup sa MFA, po istom principu opisanom u VPN Hardening tekstu na ovom blogu, nikad stalno otvorenu, zaboravljenu vezu
• Kontrolisati fizičke portove (USB, dostupni Ethernet priključci) na kritičnoj opremi — neovlašćen USB uređaj unet radi "brzog ažuriranja" ostaje jedan od najčešćih, a najmanje sofisticiranih puteva unošenja malvera u navodno izolovanu OT mrežu, isti obrazac koji je korišćen u Stuxnet napadu
• Tretirati svaku novu IIoT ili cloud integraciju kao svesnu, dokumentovanu odluku koja zahteva bezbednosnu procenu pre povezivanja, ne kao rutinsku tehničku nadogradnju koja se sprovede bez šireg razmatranja posledica po segmentaciju

Zašto Modbus, DNP3 i slični protokoli zahtevaju poseban tretman

Ovo zaslužuje detaljno tehničko objašnjenje, jer direktno određuje zašto se standardne mere zaštite (autentifikacija, enkripcija) ne mogu jednostavno "uključiti" na industrijskim protokolima na isti način kao na modernim IT protokolima. Modbus, jedan od najrasprostranjenijih industrijskih protokola, nema ugrađenu autentifikaciju, enkripciju, niti stvarnu proveru integriteta van osnovnog checksum-a — specifikacija protokola jednostavno pretpostavlja da je svaki uređaj koji može da dopre do porta 502 legitiman, poverljiv učesnik. Bilo koji uređaj sa mrežnim pristupom tom portu može izdati bilo koju komandu (čitanje ili pisanje registara, promenu stanja releja) koju taj protokol podržava, bez ikakve provere da li stvarno ima pravo da to učini.

DNP3, noviji i nešto sofisticiraniji protokol čest u energetskom i vodovodnom sektoru, ide korak dalje sa strukturiranim objektima podataka i mogućnošću da uređaj sam, neupitan, pošalje događaj nadređenom sistemu — ali čak i DNP3, u svojoj osnovnoj, često primenjenoj konfiguraciji, nosi istu fundamentalnu slabost. Postoji formalno proširenje protokola (DNP3 Secure Authentication, poznato i kao SAv5) koje dodaje challenge-response autentifikaciju, ali je u praksi retko stvarno primenjeno na postojećoj, starijoj opremi.

Šta treba uraditi

• Prihvatiti da segmentacija opisana ranije u tekstu nije opciona dopuna, već jedina stvarna zaštita za protokole koji sami po sebi nemaju autentifikaciju — ako bilo ko sa mrežnim pristupom može izdati bilo koju komandu, jedini način da se to spreči je da se taj mrežni pristup nikad ne dozvoli u prvom mestu neovlašćenim uređajima
• Gde oprema i infrastruktura to podržavaju, uključiti DNP3 Secure Authentication (SAv5) ili ekvivalentne bezbednosne ekstenzije, umesto oslanjanja isključivo na osnovnu verziju protokola
• Razmotriti Modbus/TCP kroz TLS omotač (wrapping) ili namenske industrijske gateway/proxy uređaje koji dodaju enkripciju i autentifikaciju iznad protokola koji sam po sebi to ne poseduje, posebno za segmente gde je saobraćaj izložen širem delu mreže nego što je striktno neophodno
• Kontrolisati funkcijske kodove (function codes) na nivou firewall-a ili namenskog industrijskog gateway-a gde je to podržano — dozvoliti samo tačno one operacije koje su stvarno potrebne za taj konkretan segment (npr. dozvoliti čitanje registara sa HMI-ja ka PLC-u, ali blokirati pisanje sa bilo kog drugog izvora osim autorizovane inženjerske radne stanice)

Pasivno praćenje — vidljivost bez rizika ometanja proizvodnje

Ovo je princip koji direktno proizlazi iz ograničenja opisanih ranije u tekstu: pošto aktivno skeniranje nosi rizik destabilizacije osetljive, resursno ograničene opreme, OT bezbednosno praćenje se gradi na suštinski drugačijem pristupu od IT monitoringa opisanog kroz prethodne serije na ovom blogu — pasivnom prikupljanju saobraćaja (kroz SPAN port ili mrežni tap), bez ijednog paketa poslatog ka samim kontrolerima, i bez ikakvog agenta instaliranog na sam PLC (što tehnički često nije ni moguće, budući da mnogi PLC-ovi ne mogu da izvrše proizvoljan softver trećih strana).

Vredi istaći praktičnu prednost koju OT okruženje ima nad tipičnom IT mrežom kad je reč o anomaly detekciji: industrijski saobraćaj je izrazito deterministički i predvidiv u poređenju sa običnim korisničkim saobraćajem. HMI koji redovno, na fiksnom intervalu, čita tačno određene registre sa tačno određenog PLC-a stvara jasan, stabilan obrazac — bilo kakvo odstupanje od tog obrasca (nov izvor koji nikad pre nije komunicirao sa tim PLC-om, pokušaj pisanja sa uređaja koji bi trebalo samo da čita, komanda upućena van uobičajenog vremenskog prozora) mnogo je lakše uočiti nego ekvivalentnu anomaliju u haotičnijem, ljudski-generisanom IT saobraćaju.

Šta treba uraditi

• Uspostaviti pasivno prikupljanje saobraćaja (SPAN/tap baziran, nikad agent na samim kontrolerima) kao osnovu za vidljivost OT mreže, bez ikakvog uticaja na performanse ili dostupnost same kontrolne mreže
• Snimiti period normalnog, "steady-state" saobraćaja (obrađenog kao osnova/baseline) pre uvođenja bilo kakvog aktivnog alarmiranja — koji izvori komuniciraju sa kojim odredištima, kojim funkcijskim kodovima, i u kom vremenskom obrascu — isti princip audit-pre-enforce koji se provlači kroz svaku operativno osetljivu promenu opisanu kroz celu ovu seriju blogova, ovde sa još većim naglaskom s obzirom na posledice greške
• Alarmirati na svako odstupanje od uspostavljene osnove — nova kombinacija izvor-odredište-funkcijski kod koja se ranije nikad nije pojavila često predstavlja prvi, najraniji signal izviđanja ili pokušaja lateralnog kretanja, dana ili nedeljama pre nego što bi eventualna destruktivna faza napada uopšte počela
• Koristiti OT-svesne alate za praćenje, ne generičke IT mrežne alate — standardni IT monitoring alati ne razumeju Modbus, DNP3, ili slične industrijske protokole, i njihova primena na OT mrežu ostavlja veliku, nevidljivu rupu u pokrivenosti
• Logovati svaku konekciju i svaki funkcijski kod na nivou industrijskog gateway-a ili proxy uređaja gde takav uređaj postoji u arhitekturi — detaljan zapis olakšava i istragu incidenta i izgradnju preciznije osnove za buduću anomaly detekciju

Napomena o riziku: pasivno praćenje, iako bezbedno po sam proces, ima suštinsko ograničenje koje vredi razumeti — bez konteksta sa nivoa samog uređaja, teško je pouzdano razlikovati bezopasnu, legitimnu promenu obrasca (npr. planirano održavanje koje privremeno menja normalan saobraćaj) od stvarnog napada. Iznenadan skok u DNP3 saobraćaju može biti legitimna nadogradnja sistema ili pokušaj napada — bez dodatnog konteksta, pasivan alat sam po sebi ne može sa sigurnošću da razluči razliku. Kombinovati pasivno praćenje sa jasnom komunikacijom unutar organizacije o planiranim promenama i održavanju, kako bi tim koji prati alarme imao kontekst potreban za brzu, tačnu procenu svakog odstupanja od osnove.

Autentifikacija operatera i inženjerski pristup — least privilege primenjen na fizičku kontrolu

Isti princip individualne odgovornosti i najmanjih privilegija koji se provlači kroz svaku seriju na ovom blogu ima ovde direktnu, fizičku posledicu: operater ili inženjer sa pristupom HMI-ju ili inženjerskoj radnoj stanici ima mogućnost direktne izmene ponašanja fizičkog procesa, ne samo pristup podacima.

Šta treba uraditi

• Ukinuti deljene, generičke naloge na HMI i inženjerskim radnim stanicama (čest, istorijski obrazac u OT okruženjima "da bi smena mogla brzo da preuzme kontrolu") u korist individualnih, imenovanih naloga — isti princip individualne odgovornosti opisan kroz svaku seriju na ovom blogu, ovde sa direktnim značajem za istragu bilo kog incidenta koji uključi fizičku promenu procesa
• Uvesti MFA za pristup inženjerskim radnim stanicama i sistemima za programiranje PLC-ova, gde operativni kontekst (npr. hitna intervencija tokom incidenta) to dozvoljava bez ugrožavanja brzine reagovanja na stvarne operativne potrebe
• Ograničiti ko sme da menja PLC logiku (program koji kontroler izvršava) na uzak, jasno definisan krug inženjera, sa formalnim procesom odobravanja i dokumentovanja svake izmene — neovlašćena ili nedokumentovana izmena PLC logike je jedan od najozbiljnijih, a najteže otkrivih rizika u celom OT okruženju
• Čuvati bezbednosnu (backup) kopiju PLC logike i konfiguracije van same OT mreže, po istom principu backup discipline detaljno obrađenom kroz Backup Infrastructure seriju na ovom blogu — mogućnost brzog vraćanja na poznatu, ispravnu verziju logike je ključna za oporavak nakon bilo kog incidenta koji uključi neovlašćenu izmenu ili gubitak konfiguracije

SCADA i PLC bezbednost, više nego bilo koja druga tema pokrivena kroz ovaj blog, zahteva prilagođavanje standardnih IT principa specifičnostima fizičkog procesa koji se štiti — segmentacija ostaje temeljni, nepregovarljiv princip, ali metod primene (pasivno umesto aktivno, sporo i pažljivo umesto brzo) mora poštovati stvarnost da greška ovde nema samo digitalnu, već i fizičku posledicu. Isti obrazac koji povezuje ovu temu sa svakom prethodnom serijom na ovom blogu ostaje prisutan u osnovi — default-deny, least privilege, slojevita odbrana — samo primenjen sa dodatnom pažnjom koju fizička dimenzija ovog rizika zahteva.