IPAR 4.0
Telekommunikációs és informatikai berkekben, az IPAR 4.0 eszközöket valahogy úgy definiáljuk, hogy ipari cuccok amik IP hálózaton is kommunikálnak... Természetesen ez egy durva egyszerűsítés, de ebből a szögből nézve a gyártásban betöltött szerepe nem annyira fontos, mint a hálózatban elfoglalt helye. Ezek olyan tipikusan beágyazott-rendszer alapú megoldások, melyek saját operációs rendszerrel rendelkezhetnek, és IP kommunikációra, egy már korábban lefejlesztett általában valamilyen linux alapú kernel modult használnak.
Az ilyen eszközök mondhatni semmilyen tűzfal vagy végpontvédelmi megoldással nem rendelkeznek, kommunikációjuk az adatgyűjtő berendezésekkel általában nem titkosított, így potenciális veszélyforrást jelentenek a hálózatunkban.
Ebből a minimális erőforrásból gazdálkodó szoftverfejlesztőknek, már nem feltétlenül szkóp, hogy megoldásuk IT biztonság szempontjából is megfeleljen. Tehát az IPAR 4.0 eszközei számára a hálózati oldalról kell megvalósítanunk a biztonságos csatlakozás lehetőségét, továbbá azokat az IT biztonsági feltételeket, amiket egyébként is elvárnánk a hagyományos informatikai rendszereinkben.
Hülyeség lenne ha...
A IoT vagy SMART cuccunknak közvetlen internet hozzáférést adnánk. Ne adjunk felületet a külső támadók számára, akik ezt távolról közvetlen elérnék. Ugyan már, mi baj történhet?
Nézzünk erre egy példát:
forrás
A fenti videóban azt láthattuk, ahogy a támadó a PLC IP címén egy nmap és egy script futtatása után, megszerezte az adminisztrátori felhasználóhoz tartozó jelszót clear text-ben, így már könnyű szerrel léphet be a eszközre és bármit módosíthat.
Viszont ilyen design-t megvalósítani sem célszerű, mert feleslegesen elszállhat az IT budget.
Ebben az esetben előfordulhat bizony, hogy egy permit ip any any szabállyal érjük el azt hogy egyáltalán működjön végre a berendezés elérése, ami gyakorlatilag az első ábrán látható működést eredményezné.
Az optimum nem meglepő módon valahol a kettő között van. Minimum alkalmazzunk az ipari hozzáférési pontokon access controlt, ha alkalmas a rá az IOT akkor dot1x-el autentikálja magát a hálózaton, ha nem, akkor MAB-al azonosítsuk be... Az ipari végpontokat kiszolgáló switch-en csak az aktív használatban lévő switch port-ok kerüljenek engedélyezésre, ez legyen a minimum.
Amennyire lehet, szeparáljuk el az ipari produktív és management forgalmakat, a felhasználói intranettől, és a kettő közti átjárás legyen szabályozott.
A hálózati minden rétegében alkalmazzunk hardening megoldásokat, amelyek biztosítanak egyfajta alapfokú védelmet az illetéktelen behatolókkal szemben.
Az IOT vagy smart cuccnak (szenzor, vezérlő stb..) az elérhetősége legyen szabályozott, és itt a legfontosabb, hogy ki, mikor, és hogyan férhet hozzá. (Zero Trust)
Jó lenne...
Az általam elképzelt desing az valahogy így nézne ki az IPAR 4.0-ra tervezett hálózatoknál:
Telephelyen belül:
Ezt design tipikusan egy telephelyes működés esetén javaslom. Elég elvetemültnek tűnhet ez az elrendezés és a 4 tűzfal (redundancia miatt akár 8 is lehet), viszont, ha az ábrán nem is látszik elsőre, ezek lehetnek logikai tűzfalak is, amelyet mondjuk csak 2 fizikai tűzfalon valósítunk meg (redundancia miatt 4). Ilyen technológia régóta rendelkezésre áll gondoljunk csak az ASA context-jeire, vagy az a Fortigate VDOM-okra.
Alkalmazhatunk virtualizációt is és lehetnek VNF-ek az egyes tűzfal elemek.
Több-telephelyes működés esetén viszont már kicsit más helyzet optimalizálni kell a design-t úgy, hogy ne a 2-es ábrába fussunk bele:.
Ilyen esetben, a minimum az, hogy különböző logikai szegmenseket alakítunk ki az ipar és az iroda részre, melyek között tűzfalon szabályozott az átjárás...
Könnyű beleszaladni itt is abba a hibába, hogy a telephelyi OFFICE intranet tranzitként szolgál az IPARI rendszerek számára...
Mint a egyel fentebbi ábránál is említettem, ezeket az elemeket nem feltétlen fizikai megvalósítás szintjén kell elképzelni. Az OFFICE WAN és IPARI WAN hálózatot is lehet ugyanazon router-en terminálni, különböző VPN megoldásokkal:
DMVPN ivrf, MPLS L3VPN, SD-WAN.
Ennél a pontnál is álljunk meg pillanatra, és gondoljuk végig az egyes architektúrákat, biztonság, kezelhetőség és átvitel szempontjából.
MPLS L3VPN - Nagyvállalatok számára a legegyszerűbb megoldás abból szempontból, hogy a telephelyek közti WAN tranzit kapcsolatok kialakításával nem kell foglalkozni, ugyanis ezt a szolgáltató biztosítja számukra. Viszont ahány logikai összeköttetést szeretnénk létrehozni, annyi L3VPN szolgáltatást kell igénybe venni az adott szolgáltatótól. Továbbá a vállaltok ki vannak téve a szolgáltatói lefedettségnek... Összeköttetéseink teljes mértékben a szolgáltatótól függenek.
Biztonsági szempontból, sem túl szerencsés választás, ha azt vesszük alapul, hogy alapesetben a szolgáltató az L3VPN kapcsolaton nem biztosít az átvitel során titkosítást, csak logikai szeparációt. Természetesen készséggel szolgáltatnak extra díj ellenében titkosított L3VPN kapcsolatokat, de még mindig ki vagyunk téve a szolgáltató által üzemeltetett rendszer nyújtotta biztonsági paramétereknek, amit ráadásul nem ismerünk.
DMVPN - Sok ipari vállalat, abból fakadóan, hogy nem bízik a szolgáltató által biztosított biztonsági paraméterekben, az L3VPN mellé - vagy helyett - DMVPN hálózatot alakít ki a telephelyei között. A DMVPN-ben adottak azok a a beállítások amelyek extra titkosítási layer-t adnak a rendszernek, és a kellő mértékű logikai szeparációval biztonságosságosabbá alakíthatjuk az IPARI és IRODAI rendszereink közti átjárást, de üzemeltethetőség és bővíthetőség szempontjából már elég nehéz dolgunk van. Egy ilyen rendszer üzemeltetéséhez, magas szintű hálózati ismeret kellhet, mely sajnos nem akad minden bokorban, főleg nem egy olyan országban, ahol csak informatikusból 20000 hiányzik.
SD-WAN - Fontos megjegyezni, hogy SD-WAN alatt itt most csak az elfogadható definíció áll meg, amiben a redundáns WAN kapcsolatok kezelése mellett, megoldott a telephelyek közötti VPN-ek létrehozása (pl: Cisco SD-WAN) SD-WAN managment és orchestration egyszerűbb (a már kialakított hálózaton), és jobb biztonsági paramétereket is el tudunk érni mint a felső kettő esetben (pl: Ubmrella integrácóval). Ez köszönhető annak, hogy a központi kontroll rétegen keresztül, nemcsak a üzemeltethetőség, hanem a különböző integrációk is egyszerűsödnek.
TCO kalkulációk alapján is SD-WAN technológia számít nyertesnek.
A fentiek csupán a telephelyek közti transzport kérdés tisztázására szolgálnak. Fontos, hogy megfelelő határ- és végpontpontvédelmet alkalmazzunk az egyre kifinomultabb és egyre nagyobb kárt okozó - bizonyos körökben egyre nagyobb üzletet jelentő - támadásokkal szemben. Nem elég a vírusirtó és stateful packet filter önmagában , hogy megfelelően védett legyen a hálózat.
Megoldást komplex végpontvédelem, és az NGFW néven aposztrofált tűzfalmegoldások jelenthetik, amelyek mellett érdemes még a hálózat monitorozás, és a hálózat megfigyelésén alapuló védelmi megoldásokat is bevetni, hogy a lehető legtöbb 9-ben meg tudjuk védeni az infrastruktúrát. (például: Trend Micro Deep Discovery, cisco Stealthwatch, Flowmon...)
Ilyen rendszerekkel, nemcsak az infrastruktúra védelmen tudunk javítani, hanem az esetleges hibák, rossz konfigurációk feltárása is könnyebb lehet.
Ezek azok eszközök, amelyek a hálózat viselkedése alapján segíthetnek a zeroday típusú támadások felderítésében is.
Száz szónak is egy a vége
Mindent összegezve fontos, hogy alapos megfontolások mentén építsük az IPAR 4.0 trendben megjelenő automatizált ipari rendszereket. Nem szabad megfeledkezni a hálózatbiztonságról, és nem biztos, hogy a PLC-t szállító cég a legalkalmasabb arra, hogy ebben a témában tanácsot adjon nekünk.
Olyan partnert kell választani, akinek nem csak működtetés, hanem biztonság terén is kellő tapasztalata van ahhoz, hogy az üzleti igényeinkkel harmonizáltan alakítson ki, ipari hálózati és biztossági stratégiát. Ne feledkezzünk meg arról sem, hogy a megépített rendszer üzemeltethetősége ma már kevésbé egyértelmű kérdés, mint régen volt, hiszen egyre nehezebb olyan IT staff-ot felépíteni aminek megfelelő kompetenciája van egy ilyen komplex rendszer fenntartásához, tehát ahol lehet egyszerűsítsünk a menedzselhetőségen, és tartsuk azt is szemmel, hogy hálózat már nem csak móka és kacagás, a szórakozás forrása, hanem üzletileg is kritikus üzembiztonsági feladat.
Igyekszem visszatérni még a témára! Addig is irány a gyár!
