Meratalyst / Catraki Part II – The next generation
Meraki og Catalyst Nyhed: Vores egen Tech Lead, Thomas Obbekær Thomsen, guider dig i, hvordan du gør din Catalyst-switch Meraki-monitored. Læs guiden her.
Skal Mads fra HR kunne lægge dit procesanlæg ned?
Nej, selvfølgelig skal Mads ikke det, men erfaringsmæssigt ser man, at selvom det lyder som en no-brainer at holde procesanlæg adskilt fra resten af sin infrastruktur, så er det ikke altid sådan virkeligheden ser ud.
Langt de fleste procesanlæg i dag benytter Ethernet som kommunikationsmedie i større eller mindre grad til at forbinde de forskellige PLC’er, frekvensomformere, I/O-moduler, sensorer m.v. i anlægget, samt til kommunikation til SCADA og HMI systemer. Disse netværk går ofte under navne som “SRO”, “driftnet”, “teknisk net”, “OT” m.fl., men uanset hvad man kalder det, er formålet med disse netværk det samme, nemlig at være en kommunikationskanal mellem de komponenter, servere og systemer der driver procesanlægget – det vel at mærke på en stabil og sikkerhedsmæssig forsvarlig måde, så anlæggene har rettidige og valide data hele tiden. Procesanlæg kan opbygges på mange måder, og derfor er der oftest heller ikke en entydig facitliste til, hvordan krav til oppetid, firewalling m.v. skal implementeres for SRO-netværk.
Er det procesanlæg man driver eks. samfundskritisk infrastruktur, såsom elforsyning, drikkevandsforsyning, spildevandshåndtering, eller er det vigtigt for virksomheden, at procesanlægget altid kører, er det min holdning, at SRO-miljøet, herunder netværk, SCADA-servere/systemer og perifere komponenter bør betragtes som et af de mest kritiske assets, man har, og det netværks- og sikkerhedsmæssige design bør afspejle dette. Erfaringsmæssigt ser man dog, at SRO-netværk ikke altid er forankret i en decideret IT-afdeling med netværksteknikere og sikkerhedsfolk, men i stedet lander denne opgave hos den tekniker, der er dygtig til at programmere PLC’er og SCADA-systemerne, ofte i samarbejde med leverandøren af selve procesanlægget.
I nogle af de installationer, jeg har arbejdet med i de forskellige sektorer inden for forsyningsvirksomhed, har denne fordeling vist sig at være uhensigtsmæssig i forhold til at opretholde et driftsstabilt netværk med et højt sikkerhedsniveau. Det sammenholdt med at procesanlæg typisk kører i mange år uden redesign eller lignende gør, at der er mange ældre installationer rundt omkring, som kører lige så godt som den dag, de blev sat op, nemlig uden problemer – problemet er blot at trusselsbilledet på IT-området har ændret sig markant de seneste 5-10 år.
I den forbindelse kan man stille sig selv nogle spørgsmål som f.eks.: Hvad sker der, hvis Mads fra HR eller Mette fra Økonomi ved et uheld får udløst et ransomware-angreb, og man har et såkaldt “fladt” netværk, hvor både administration og SRO er Lag 3- eller sågar Lag 2-mæssigt forbundet? Tanken om et ransomware-angreb i et netværk er aldrig rar, men kobl det sammen med, at du ikke længere kan styre elnettet, fordi de servere og systemer, der var dedikeret til dette, også er lagt ned. Og nu vi er ved ting, der ikke er rare at tænke på, så findes der jo også mere målrettet malware, der specifikt går efter PLC’er og de her komponenter, hvor endpoint protection oftest hverken er mulig eller har stort fokus. Og i de fleste virksomheder har hverken Mads eller Mette et behov for at kunne kommunikere direkte med en SCADA-server eller en PLC.
En måde at løse en række af de her udfordringer er at logisk segmentere SRO væk fra det øvrige netværk med traditionelle værktøjer såsom VLAN, VRF m.v. eller sågar helt galvanisk adskilt. Men det er sjældent, man bare kan gemme sit SRO netværk helt væk i en lukket boble, så hvad gør man så?
Ved at implementere såkaldte ”industrial DMZ” zoner og bruge jump-hosts adskilt af Next-Gen Firewalls med relevante IPS-signaturer, kan man designe et SRO-miljø, som har en meget høj grad af sikkerhed, hvor udgangspunktet er, at ingen trafik må flyde, hverken ind eller ud eller mellem SRO og det almindelige administrative netværk. Al kommunikation sker via jump-hosts, reverse proxies eller lignende, så man har mulighed for granuleret kontrol af hvem, hvad, hvornår og hvordan, der må kommunikeres, og der er mulighed for logning og dokumentation af, hvad der foregår på netværket.
I Wingmen designer vi industrielle netværk med udgangspunkt i Cisco Validated Design for Industrial Ethernet, som bl.a. omfatter forsyningsvirksomheder men naturligvis også mange andre typer industrianlæg.
-Bo Urskov
Meraki og Catalyst Nyhed: Vores egen Tech Lead, Thomas Obbekær Thomsen, guider dig i, hvordan du gør din Catalyst-switch Meraki-monitored. Læs guiden her.
Netværksautomatisering kan virke kompleks og teknisk, men den tekniske side er ofte den enkleste del. Den virkelige udfordring ligger i det organisatoriske og planlægningsmæssige arbejde før, under og efter kodning. Her er de første 6 trin til at opnå succes med netværksautomatisering.
Netværksautomatisering kan virke kompleks og teknisk, men den tekniske side er ofte den enkleste del. Den virkelige udfordring ligger i det organisatoriske og planlægningsmæssige arbejde før, under og efter kodning. Her er de første 6 trin til at opnå succes med netværksautomatisering.
Har Tech Tanken gjort dig nysgerrig på at vide mere? Så kan du følge med på hjemmesiden her eller du kan kontakte mig, hvis du har spørgsmål til denne tanke.
Mail: bur@wingmen.dk
Kbh.: Tobaksvejen 23B, 2. sal, 2860 Søborg
Aarhus: Lyshøjen 2, 1. sal tv., 8520 Lystrup
Odense: Stenhuggervej 21, 5230 Odense M
Telefon: 70202110
Mail: info@wingmen.dk
CVR: 36440228