2016 májusában a Microsoft bejelentette, hogy változtatni fog az eddig patch-elési eljárásán: a Windows 7 és Windows 8.1 operációs rendszerek esetén minden korábbi, nem biztonsági frissítés egyben fog települni a még nem javított operációs rendszer példányokra. Később a Microsoft újabb bejelentésben hozta nyilvánosságra, hogy ezt a megközelítést azokra a patch-ekre is kiterjeszti, amelyek "biztonsági és megbízhatósági" hibákat orvosolnak. Ez utóbbi bejelentés szerint ezzel együtt megjelennek az ún. "Security-only Update"-ek, amelyek az adott hónap összes biztonsági frissítését egyben fogják tartalmazni. Ezeket a frissítéseket csak akkor lehet telepíteni, ha minden korábbi biztonsági patch telepítve van már a rendszerre. Ezzel párhuzamosan 2016. októbertől (vagyis alig több, mint egy hét múlva) megszűnik az egyedi patch-ek elérhetősége, ahogy azt Nathan Mercer, a Microsoft TechNet munkatársa egy kérdésre válaszolva elmondta.

Ez az intézkedés jól illeszkedik a Microsoft-tól az elmúlt években tapasztalt kezdeményezéshez, amivel megpróbálja elérni, hogy az operációs rendszereiben minimálisra csökkenjen az ismert hibák száma és ez a legtöbb esetben örvendetes is. Azonban ugyanez az intézkedés nagyon komoly nehézségeket fog okozni azoknak a szervezeteknek és felhasználóknak, akik olyan alkalmazásokat használnak, amiknek a hibamentes működését egy-egy újabb Windows patch telepítése akadályozza.

A Windows operációs rendszer-család tagjait a kritikus infrastruktúrákat üzemeltető szervezetek is egyre több esetben használják és a vállalati/ügyviteli/irodai hálózatok az évek alatt lassan, de egyre nagyobb részt kaptak többek között az ipari alkalmazások kiszolgálásában is.

Figyelembe véve, hogy az elmúlt évek eseményei után egyre kevésbé látszik tarthatónak az a gyakorlat, hogy a különböző ipari rendszerek patch-elését csak ritkán, esetenként 2-3 évente egyszer, kötegelve végezzék el, fel kell készülni arra, hogy egy ilyen változást hogyan lehet összeegyeztetni a kritikus infrastruktúrák megbízható és nagy rendelkezésre állásának biztosításával.

Lévén Európában még nincs olyan, a NERC-höz hasonló, kötelező előírás a kritikus informatikai infrastruktúrák védelmével kapcsolatos jogszabály, mint az USA-ban, így számunkra nem fog olyan rövid távú problémákat okozni, mint az amerikai kollégáknak. Ted Gutierrez, a SANS oktatója ezekről a problémákról ír a SANS ICS Security blogon megjelent posztjában.

A ZDI még szeptember 21-én tette közzé, hogy a Fatek Automation nevű, tajvani székhelyű ipari eszközöket gyártó cég PM Designer nevű HMI szoftverében távoli programkód végrehajtást lehetővé tevő memóriakorrupciós hibát fedezett fel Ariele Caltabiano. A hiba a szoftver pm3 típusú fájlok feldolgozási funkciójában található, így bizonyos hibás fájlok feldolgozása memóriakorrupciós hibát idéz elő és ennek következtében a bejelentkezett felhasználó jogosultságaival lehet távolról programkód végrehajtást kezdeményezni.

A ZDI bejelentése nem egyértelmű azzal kapcsolatban, hogy a PM Designer mely verzióit érinti a sérülékenység.

A sérülékenységgel kapcsolatban a gyártó mind a mai napig nem publikált javítást, ezért az egyetlen javasolt kockázatcsökkentő intézkedés az, hogy a sérülékeny szoftververziókba csak megbízható forrásból származó fájlokat dolgozzunk fel.

További részleteket a ZDI publikációja tartalmaz: http://www.zerodayinitiative.com/advisories/ZDI-16-525/

A Siemens ProductCERT publikációja alapján a SCALANCE M-800/S615 típusú ipari routerekben illetve tűzfalakban egy olyan, sérülékenységet fedeztek fel (Alexander Van Maele és Tijl Deneut, a Howest munkatársai), aminek kihasználásával egy támadó hozzáférhet a webes kapcsolat során használt cookie-khoz. A hiba a V4.02-nél korábbi összes firmware-verziót érinti. A hiba tulajdonképpen nem más, mint a "klasszikus", secure flag nélküli cookie-kezelés az érintett eszközökbe épített webszervereken.

A Siemens a hibát a V4.02-es firmware-ben javította. A hiba javítását már tartalmazó firmware-re történő frissítés mellett a Siemens azt javasolja ügyfeleinek, hogy a különböző ipari eszközök menedzsment portjaihoz történő hozzáférést tegyék biztonságosabbá.

További részleteket a sérülékenységgel kapcsolatban a Siemens ProductCERT bejelentése tartalmaz: http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-342135.pdf

Szerk: Az ICS-CERT is publikálta a hibát: https://ics-cert.us-cert.gov/advisories/ICSA-16-271-01

Az East-West Institute és az ICS-ISAC CCIP néven útjára indított közös kezdeményezése a tavaly decemberi, ukrán villamosenergia-szolgáltatók elleni kibertámadás tanulságait levonva próbál meg új lendületet adni az információmegosztáson alapuló biztonsági intézkedéseknek.

Részleteket az ICS-ISAC által készített regisztrációs oldal tartalmaz. Azoknak, akik részt akarnak venni a kezdeményezésben, először a fenti oldalon regisztrálniuk kell magukat, majd egy 5-7 napos elbírálási időszak után válhatnak a közösség tagjaivá.

A kezdeményezés jó és örvendetes, azonban már most hallok olyan megjegyzéseket a szakmában, hogy célszerű lesz óvatosnak lenni az információk megosztása terén, hiszen senki nem tudhatja, hogy az általa megosztott információk pontosan kikhez is juthatnak el. Ez az a fajta óvatosság, ami minden eddig kezdeményezés hatékonyságát olyan szintre csökkentette, hogy végül az egész értelmét vesztette.

Személyes tapasztalataim alapján az ilyen kezdeményezéseket célszerű lehet kisebb körben elindítani (pl. iparágon vagy országon/régión belül) és minden esetben a személyes kapcsolatokon alapuló bizalomra kell, hogy épüljenek, különben a fent említett bizalmatlanság gyorsan alá fogja ásni az információmegosztás hatékonyságát.

Az ICS-CERT által publikált cikk szerint Zhou Yu független biztonsági kutató hibát fedezett fel a Moxa Active OPC Server alkalmazásában. A sérülékenység az Active OPC Server 2.4.19-nél régebbi verzióit érinti.

Az érintett szoftver HMI és SCADA rendszerek OPC drivereként használható. A hibát kihasználva egy, a rendszeren sikeresen authentikált felhasználó a fájlrendszerhez hozzáférve képes lehet jogosultságszint-emelést végrehajtani.

A gyártó a hibával kapcsolatban azt javasolja ügyfeleinek, hogy az Active OPC Server-ről váltsanak az újabb szoftverére, az MX-AOPC UA szerverre vagy telepítsék az Active OPC Server 2.4.19-es verzióját, amiben már javították ezt a hibát.

Az ICS-CERT a hibával kapcsolatban a szokásos biztonsági intézkedések alkalmazását javasolja:

- Minimálisra kell csökkenteni az ipari/egészségügyi rendszerek/hálózatok kapcsolatát az Internettel;
- Az ipari/egészségügyi rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari/egészségügyi rendszerek/hálózatok távoli eléréséhez biztonságos módszereket (pl. VPN) kell használni, de szem előtt kell tartani azt is, hogy az egyes VPN-megoldásoknak is lehetnek sérülékenységeik és ezeket is folyamatosan frissíteni kell a legújabb elérhető verzióra. Nem szabad elfelejteni továbbá azt sem, hogy a VPN csak annyira biztonságos megoldás, mint az eszköz, amit a VPN-en keresztül a védett hálózathoz csatlakoztatnak!

A sérülékenységgel kapcsolatban további információkat az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-264-01

A szeptember 12. és 15. közötti néhány nap megint igen gazdag termést hozott a különböző ICS rendszerek sérülékenységeiből.

Cross-site request forgery a Schneider Electric ION okosmérőiben

Karn Ganeshen független biztonsági kutató neve valószínűleg nem ismeretlen azoknak, akik követik a (jellemzően) ICS-CERT által publikált ICS sérülékenységek híreit, számos hibát talált már a múltban is különböző ipari rendszerekben. Ezúttal a Schneider Electric ION okosmérőiben fedezett fel CSRF hibát, amit kihasználva egy támadó jogosultság nélküli konfiguráció-módosításra lehet képes. A hibával kapcsolat Karn a proof-of-concept exploit-ot is eljuttatta a gyártóhoz és az ICS-CERT-hez.

A hiba az ION 73xx, ION 75xx, ION 76xx, ION 8650, ION 8800 és PM5xxx sorozatú eszközöket érinti. A Schneider Electric már összeállította a sérülékenység hatásait csökkentő intézkedések listáját és eljuttatja az érintett eszközöket használó ügyfeleinek. A gyártó a következő intézkedéseket javasolja elvégezni:

- Az okosmérők "Webserver Config Access" paraméterét javasolt "Disabled"-re állítani (alapértelmezetten ez a paraméter engedélyezett állásban van) és a mérők konfigurációját lementeni.
- Az okosmérők konfigurációjában van egy "Enable Webserver" paraméter is, ami a mérők webszerver funkciójának teljes engedélyezéséért vagy tiltásáért felelős. A paraméternek "YES" és "NO" értéke lehet, alapértelmezetten engedélyezve van a működése.

További információkat az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/alerts/ICS-ALERT-16-256-02

FENIKS PRO Elnet mérőórák sérülékenységeiből

Szintén Karn Ganeshen fedezett fel távoli kódvégrehajtást lehetővé tevő hibát a FENIKS PRO Elnet mérőóráiban és ehhez a sérülékenységhez is mellékelt PoC kódot. Ebben az esetben az ICS-CERT-nek nem sikerült egyeztetnie a gyártóval a sérülékenység javításáról vagy a sérülékenység okozta kockázatok csökkentéséről, így csak annyi tanáccsal tud szolgálni, hogy az érintett eszközök felhasználói a telepítés után mielőbb módosítsák az eszközök alapértelmezett jelszavait.

Az ICS-CERT sérülékenységgel kapcsolatos bejelentése itt található: https://ics-cert.us-cert.gov/alerts/ICS-ALERT-16-256-01

Rockwell Automation RSLogix sérülékenység

Ariele Caltabiano, a TrendMicro ZDI munkatársa egy puffer túlcsordulásból eredő sérülékenységet talált a Rockwell Automation RSLogix termékcsaládjának alábbi tagjaiban:

- RSLogix Micro Starter Lite, minden verzió,
- RSLogix Micro Developer, minden verzió,
- RSLogix 500 Starter Edition, minden verzió,
- RSLogix 500 Standard Edition, minden verzió és
- RSLogix 500 Professional Edition, minden verzió.

A hibát sikeresen kihasználó támadó egy már bejelentkezett felhasználó jogosultsági szintjével lehet képes kódvégrehajtást elérni.

A gyártó a sérülékeny eszközöket használó ügyfeleinek a legújabb, 8.40.00-ás firmware telepítését javasolja, amiben már javították a hibát, valamint további biztonsági intézkedések végrehajtását is javasolja:

- Az érintett RSLogix 500 és RSLogix Micro eszközökön ne nyissanak meg nem megbízható forrásból származó RSS fájlokat!
- Minden szoftvert a minimálisan szükséges jogosultsági szintű felhasználóval futtassák, ne pedig adminisztrátori jogosultsággal!
- Csak megbízható szoftvereket, szoftverjavításokat és antivirus/antimalware megoldásokat használjanak, valamint csak megbízható weboldalakat és csatolmányokat nyissanak meg!
- A felhasználók biztonságtudatosságát folyamatosan javítsák megfelelő képzésekkel!
- Alkalmazzanak alkalmazás fehérlistákat megvalósító programokat (pl. Microsoft AppLocker, amivel kapcsolatban a Rockwell Automation további részleteket is közöl az ügyfeleivel ezen a linken: https://rockwellautomation.custhelp.com/app/answers/detail/a_id/546989)

További információkat az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-224-02

Trane Tracer SC sérülékenység

A Trane, amerikai folyamatirányító rendszereket gyártó cég Tracer SC rendszerében Maxim Rupp talált sérülékenységet, amit kihasználva egy támadó bizalmas információkhoz férhet hozzá. A hiba a Tracer SC Versions 4.2.1134 és korábbi verzióit érinti.

A gyártó már elérhetővé tette a hibát javító frissítést és ügyfelei számára on-line támogatást is biztosít: http://www.trane.com/commercial/north-america/us/en.html

A hibával kapcsolatban további információk az ICS-CERT bejelentésében találhatóak: https://ics-cert.us-cert.gov/advisories/ICSA-16-259-03

ABB DataManagerPro sérülékenység

Az ABB DataManagerPro termékében a ZDI munkatársai találtak sérülékenységet. A hiba a DataManagerPro 1.0.0-tól 1.7.0-ig minden verzióját érinti. A hiba kihasználásával egy támadónak lehetősége van egy DLL fájlokat kicserélni olyan állományokra, amik segítségével adminisztrátori jogosultságokat szerezhet.

A gyártó az 1.7.1-es verzióban javította a hibát és azt javasolja az ügyfeleinek, hogy minél előbb frissítsék a hiba által érintett rendszereiket.

További információkat a hibáról az ABB és az ICS-CERT tájékoztatóiban lehet találni.

Yokogawa STARDOM sérülékenység

A gyártó és a japán CERT (JPCERT) közösen tájékoztatták az ICS-CERT-et egy, a Yokogawa STARDOM FCN/FCJ controller R1.01-től R4.01-ig terjedő verzióiban felfedezett sérülékenységről. A hiba kihasználásával a Logic Designer alkalmazás authentikáció nélkül tud csatlakozni a STARDOM rendszerhez. Ezzel egy támadó képes lehet parancsvégrehajtásra, alkalmazás leállítására és módosítására a rendszerben.

A gyártó az R.4.02-es verzióban javította a hibát és további információkat tett elérhetővé a weboldalán a hibával kapcsolatban: http://www.yokogawa.com/technical-library/resources/white-papers/yokogawa-security-advisory-report-list/

A Yokogawa a sérülékenység kapcsán, de attól függetlenül is azt javasolja minden ügyfelének, hogy hajtsák végre a szükséges biztonsági hardeninget a rendszereiken.

Az ICS-CERT bejelentése a sérülékenységről itt található: https://ics-cert.us-cert.gov/advisories/ICSA-16-259-01

Az ICS-CERT a fenti sérülékenységekkel kapcoslatban is a szokásos kockázatcsökkentő intézkedéseket javasolja:

- Minimálisra kell csökkenteni az ipari/egészségügyi rendszerek/hálózatok kapcsolatát az Internettel;
- Az ipari/egészségügyi rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari/egészségügyi rendszerek/hálózatok távoli eléréséhez biztonságos módszereket (pl. VPN) kell használni, de szem előtt kell tartani azt is, hogy az egyes VPN-megoldásoknak is lehetnek sérülékenységeik és ezeket is folyamatosan frissíteni kell a legújabb elérhető verzióra. Nem szabad elfelejteni továbbá azt sem, hogy a VPN csak annyira biztonságos megoldás, mint az eszköz, amit a VPN-en keresztül a védett hálózathoz csatlakoztatnak!

Augusztus elején a FireEye egy 12 oldalas PDF-et publikált, amiben összefoglalták az általuk 2000 óta összegyűjtött, publikusan elérhető, ICS rendszereket érintő sérülékenységekkel kapcsolatos elemzéseiket.

A publikált adatokból tisztán látszik, hogy 2008 előtt elenyésző számú ICS sérülékenység vált publikussá, de igazán a Stuxnet 2010-es felfedézése után nőtt meg ugrásszerűen az ilyen sérülékenységek száma (egészen pontosan 2011-ben négyszer annyi sérülékenységet publikáltak ICS rendszerekkel kapcsolatban, mint 2010-ben) és ez a növekedés (2014-et kivéve, amikor kismértékű csökkenés volt tapasztalható az előző évben napvilágra került sérülékenységek számához képest) folyamatosan növekszik. 2015-ben már több, mint 400 különböző ICS rendszereket érintő sérülékenység jelent meg. A FireEye kutatóinak várakozása szerint a következő években átlagos évi 5%-kal fog nőni az ICS rendszerekkel kapcsolatos sérülékenységek száma.

Az elemzésben egy szűkebb, közel 3 éves időszakot vizsgálva arra a megállapításra jutottak, hogy a sérülékenységek 58%-a a Purdue ICS architektúrában leírt második szinten működő elemeket érinti (a Purdue nagyvállalati referencia architektúra ICS rendszerekre alkalmazott változatáról itt írtam), ezen a szinten kerül meghatározásra, hogy az egyes ipari céleszközök hogyan és milyen interfészeken keresztül kommunikálnak számítógépekkel. A FireEye kutatói szerint ennek az lehet az oka, hogy a második szinten található eszközökhöz könnyebb hozzáférni és a sérülékenységeket kereső szakemberek számára sokkal ismertebbek, mint az első szinten működő ipari céleszközök.

Ami a publikált statisztikák közül szerintem a leginkább aggasztó az az, hogy az  ICS sérülékenységek átlag 33%-a gyakorlatilag publikus nulladik napi sérülékenységként lát napvilágot és többet ezek közül később sem javít a gyártó, többnyire azért, mert már nem ad támogatást az adott rendszerhez vagy eszközhöz, de volt olyan eset is (én is írtam róla), amikor az eszköz egyszerűen nem tette lehetővé a javítás telepítését, mert a codespace-ben ehhez már nincsen elég hely!

A sorozat mai részében egy Jalal Bouhdada és Erwin Paternotte előadásáról készült videót ajánlok, amiben bemutatják, hogy a vezeték nélküli szenzorok hálózati protokolljának gyenge pontjait kihasználva hogyan lehet támadást intézni egy ipari vezérlőrendszer ellen.

A WirelessHART egy vezetéknélküli szenzor hálózati protokoll, ami a HART (Highway Addressable Remote Transducer) protokollból lett kifejlesztve. A WirelessHART egy több gyártó által támogatott vezetéknélküli szabvány, amit kifejezetten az ipari hálózatok terepi/gyári eszközeihez fejlesztettek.

A kutatók legfontosabb megállapításai a következők:

- A legfontosabb titkosító kulcs, a Join Key általában a gyári alapértelmezett beállításokkal van használva a legtöbb WirelessHART-tal működő rendszeren. Ezek az alapértelmezett Join Key-ek többnyire publikusan elérhetőek a gyártói kézikönyvekben, ha pedig mégsem, akkor viszonylag egyszerűen lehet megtalálni őket az Interneten;

- Az 5 vizsgált WirelessHART gyártó összes firmware-jét ki lehetett tömöríteni JTAG használatával és így meg lehetett találni bennük a Join Key-eket, amik ugyan titkosítottak voltak, de ez nem akadályozta meg, hogy le lehessen másolni őket majd ezeket a Join Key-eket használva csatlakoztatni lehessen egy saját WirelessHART készüléket a hálózathoz.

A videó megtekinthető itt: https://youtu.be/AlEpgutwZvc

A Siemens ProductCERT bejelentése szerint Kiril Nesterov és Anatoly Katushin, a Kaspersky Lab munkatársainak segítségével több hibát is azonosítottak a SIPROTEC 4 és SIPROTEC Compact eszközökben. A hibák a SIPROTEC 4 és SIPROTEC Compact eszközöknél opcionális EN100 Ethernet modul összes, V4.29-nél korábbi verziójú firmware-ben megtalálható.

Az első hiba (CVE-2016-7112) lehetővé teszi, hogy az eszközök webes interfészén keresztül támadók megkerüljék a beépített authentikációs folyamatot és hozzáférést szerezzenek bizonyos (a bejelentésben nem részletezett) adminisztrátori funkciókhoz.

A második hiba (CVE-2016-7113) lehtővé teszi, hogy speciálisan kialakított TCP csomagokkal a sérülékeny eszközöket hibás állapotba juttassák.

A harmadik hiba (CVE-2016-7114) kihasználásával egy támadó az eszközök webes interfészén keresztül megkerülje a beépített authentikációs folyamatot és hozzáférést szerezzen bizonyos (a bejelentésben nem részletezett) adminisztrátori funkciókhoz. Ennek a hibának a kihasználásához szükséges, hogy egy legitim felhasználó be legyen jelentkezve a sérülékeny SIPROTEC eszközön.

Mindhárom hiba kihasználásához szükséges, hogy a támadó hálózaton keresztül elérje a sérülékeny eszközöket.

A Siemens a hiba által érintett SIPROTEC berendezéseket használó ügyfeleinek a mielőbb firmware-frissítést javasolja, az elérhető legfrissebb, V4.29-es verziójú firmware-ben javították a hibákat.

További részleteket a Siemens ProductCERT bejelentése tartalmaz: http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-630413.pdf

Szerk: 2016.09.06-án az ICS-CERT is publikálta ezeket a hibákat: https://ics-cert.us-cert.gov/advisories/ICSA-16-250-01

A biztonságos ICS architektúrát leíró tanulmány 2015-ben készült és a SANS Reading Room ICS whitepaper publikációi között érhető el. Alapját az 1990-ben a Purdue egyetemen kidolgozott nagyvállalati referencia architektúra ISA-99 bizottsága által készített vezérlési hierarchia-modellje adja. A vezérlési hierarchia Purdue modellje 4 zónát és 5 szintet különböztet meg (egy gyártóvállalat példáján keresztül):

Vállalati zóna
  5. szint: Vállalat
  Ebben a zónában helyezkednek el a vállalati IT infrastruktúra elemei, a különböző IT rendszerek és alkalmazások. Ebben a zónában mindennaposnak számítanak a VPN-en keresztüli távoli elérések és az Internet használata (pl. egyes alkalmazásszerverek licenc-ellenőrzése folyamatos Internet-kapcsolatot igényel). Az ebben a zónában elhelyezkedő rendszerek számára nem ajánlott közvetlen kommunikációs lehetőséget biztosítani az ICS rendszerekkel, ehelyett célszerű egy belső DMZ-n keresztül lehetővé tenni a hozzáférést az ICS rendszerek hálózatához.
 
  4. szint: Helyszíni üzleti tervezés és logisztika
  A 4. szint nagyon gyakran az 5. szintből kerül kialakításra, itt üzemelnek azok az üzleti rendszerek, amelyek fontos belső folyamatokat támogatnak (ilyenek lehetnek többek között kapacitás-tervezésben, készlet-nyilvántartásban, stb. érintett rendszerek).
 
Gyártási zóna
  3. szint: Helyszíni gyártási műveletek és vezérlés
  Ezen a szinten üzemelnek azok a rendszerek, amik a gyártási folyamatok üzemirányításának támogatását biztosítják (pl. hálózati fájlszerverek, általános IT szolgáltatások, mint a DNS, DHCP, NTP, stb., a mérnöki munkahelyek, történeti adatokat tároló rendszerek, jelentések előállítását és ütemezéseket végző rendszerek, stb.). Az ezen a szinten üzemelő rendszerek egy DMZ-n keresztül kommunikálnak a Vállalati zóna szintjein működő rendszerekkel - a DMZ-t megkerülő direkt eléréseket célszerű kerülni.
  Továbbá a 3. szinten található rendszerek kommunikálhatnak az 1. és 0. szinten található rendszerekkel is (pl. hálózati időszinkronizálás vagy DNS névfeloldás miatt erre szükség lehet).
 
Ipari zóna
  2. szint: Ipari felügyelet és vezérlés
  A 2. szinten működő rendszerek közé olyanok tartoznak, amelyek jellemzően az 1. szinten található rendszerekkel kell kommunikálniuk (ilyenek pl. a vezérlőtermi munkaállomások), illetve amik interfészként szolgálnak az 1. szintű eszközök és a gyártási vagy vállalati zónákban található rendszerek között (pl. monitoring és riasztó rendszerek vagy HMI-k).
 
  1. szint: Alapvető vezérlés
  Ezen a szinten olyan eszközök találhatóak, amelyek feladata a folyamatvezérlés biztosítása. Ezek az eszközök fogadják és dolgozzák fel a különböző szenzoroktól érkező adatokat. Ezek az eszközök (többnyire DCS-ek, PLC-k, RTU-k) felelősek a folyamatos, szekvenciális, kötegelt és diszkrét vezérlésekért. Ezek az eszközök jellemzően gyártó-specifikus operációs rendszereket/firmware-eket futtatnak és a mérnöki munkaállomásokról lehet őket programozni és konfigurálni.
 
  0. szint: Folyamatok
  A 0. szinten üzemelnek azok a szenzorok és műszerek, amelyek az ipari folyamatok közvetlen ellenőrzését végzik. Ezeket az eszközök az 1. szinten működő rendszerek vezérlik.
 
Biztonsági (safety) zóna
  Ebben a zónában olyan rendszerek működnek, amelyek az ipari folyamatok biztonsági ellenőrzését végzik és az előre bekonfigurált határértékek elérése vagy átlépése esetén az operátor értesítése mellett beavatkozik a biztonságos állapot helyreállítása érdekében. Ezeket a rendszerek az esetek többségében teljesen izolálják minden más rendszertől.
 
A tanulmány a referencia architektúra-modellen túl részletes javaslatokat is tartalmaz, amik minden ICS rendszerek kiberbiztonságáért, üzemeltetéséért és fejlesztéséért felelős szakembernek hasznosak lehetnek. Az eredeti, angol nyelvű tanulmány a SANS Reading Roomban érhető el: https://www.sans.org/reading-room/whitepapers/ICS/secure-architecture-industrial-control-systems-36327