Dit is een nieuwe pagina.

Home > Artikelen > IoT beveiligen

Securing IoT

Inhoud

Beschrijving Hoofdstuk

  1. Een korte geschiedenis van OT-beveiliging
  2. Veelvoorkomende uitdagingen bij OT-beveiliging
  3. Hoe IT- en OT-beveiligingspraktijken en -systemen verschillen
  4. Formele risicoanalysestructuren: OCTAVE en FAIR
  5. De gefaseerde toepassing van beveiliging in een operationele omgeving
  6. Overzicht

In dit voorbeeld hoofdstuk van IoT Fundamentals: Netwerk Technologieën, Protocollen, en Use Cases for the Internet of Things, zullen lezers een korte geschiedenis bekijken van de beveiliging van operationele technologie (OT), hoe deze is geëvolueerd en enkele van de veelvoorkomende uitdagingen waarmee deze wordt geconfronteerd.

De tekst op deze webpagina is vertaald vanuit het Engels naar het Nederlands door Priscilla F. Harmanus. De originele tekst van het artikel vind je hier.

Veelvoorkomende uitdagingen bij OT-beveiliging

De beveiligingsuitdagingen waarmee IoT wordt geconfronteerd, zijn zeker niet nieuw en zijn niet beperkt tot specifieke industriële omgevingen. In de volgende secties worden enkele van de veelvoorkomende uitdagingen besproken waarmee IoT wordt geconfronteerd.

Erosie van netwerkarchitectuur

Twee van de grootste uitdagingen bij het beveiligen van industriële omgevingen waren het initiële ontwerp en het voortdurende onderhoud. De eerste ontwerpuitdagingen kwamen voort uit het concept dat netwerken veilig waren vanwege fysieke scheiding van de onderneming met minimale of geen connectiviteit met de buitenwereld, en de veronderstelling dat aanvallers onvoldoende kennis hadden om beveiligingsaanvallen uit te voeren. In veel gevallen is het oorspronkelijke netwerkontwerp solide en volgt het zelfs goed gedefinieerde industriële best practices en standaarden, zoals het Purdue Model for Control Hierarchy dat werd geïntroduceerd in Hoofdstuk 2, "IoT Network Architecture and Design". De uitdaging, en de grootste bedreiging voor netwerkbeveiliging, zijn normen en beste praktijken die verkeerd worden begrepen of het netwerk slecht wordt onderhouden. Vanuit het oogpunt van beveiligingsontwerp, het is beter om te weten dat communicatiepaden onveilig zijn dan de feitelijke communicatiepaden niet te kennen. Het komt vaker voor dat wat in de loop van de tijd misschien een solide ontwerp was, wordt uitgehold door ad-hocupdates en individuele wijzigingen in hardware en machines zonder rekening te houden met de bredere netwerkimpact. Dit soort organische groei heeft geleid tot verkeerde berekeningen van uitbreidende netwerken en de introductie van draadloze communicatie op een zelfstandige manier, zonder rekening te houden met de impact op het oorspronkelijke beveiligingsontwerp. Deze ongecontroleerde of slecht gecontroleerde OT-netwerkevoluties hebben in veel gevallen in de loop van de tijd geleid tot een zwakke of ontoereikende netwerk- en systeembeveiliging.wat in het begin een solide ontwerp was, wordt uitgehold door ad-hocupdates en individuele wijzigingen aan hardware en machines zonder rekening te houden met de bredere netwerkimpact. Dit soort organische groei heeft geleid tot verkeerde berekeningen van uitbreidende netwerken en de introductie van draadloze communicatie op een zelfstandige manier, zonder rekening te houden met de impact op het oorspronkelijke beveiligingsontwerp. Deze ongecontroleerde of slecht gecontroleerde OT-netwerkevoluties hebben in veel gevallen in de loop van de tijd geleid tot een zwakke of ontoereikende netwerk- en systeembeveiliging.wat in het begin een solide ontwerp was, wordt uitgehold door ad-hocupdates en individuele wijzigingen aan hardware en machines zonder rekening te houden met de bredere netwerkimpact. Dit soort organische groei heeft geleid tot verkeerde berekeningen van uitbreidende netwerken en de introductie van draadloze communicatie op een zelfstandige manier, zonder rekening te houden met de impact op het oorspronkelijke beveiligingsontwerp. Deze ongecontroleerde of slecht gecontroleerde OT-netwerkevoluties hebben in veel gevallen in de loop van de tijd geleid tot een zwakke of ontoereikende netwerk- en systeembeveiliging.zonder rekening te houden met de impact op het oorspronkelijke beveiligingsontwerp. Deze ongecontroleerde of slecht gecontroleerde OT-netwerkevoluties hebben in veel gevallen in de loop van de tijd geleid tot een zwakke of ontoereikende netwerk- en systeembeveiliging.zonder rekening te houden met de impact op het oorspronkelijke beveiligingsontwerp. Deze ongecontroleerde of slecht gecontroleerde OT-netwerkevoluties hebben in veel gevallen in de loop van de tijd geleid tot een zwakke of ontoereikende netwerk- en systeembeveiliging.

Er is een grote verscheidenheid aan beveiligde netwerkontwerpen binnen en tussen verschillende industrieën. Energiebedrijven hebben bijvoorbeeld een sterke geschiedenis in het gebruik van moderne technologieën voor operationele activiteiten, en in Noord-Amerika zijn er regelgevende vereisten van regelgevende instanties, zoals de Critical Infrastructure Protection (CIP) van North American Electric Reliability Corporation (NIP), besproken in meer details in Hoofdstuk 11, "Hulpprogramma's"), om veilige netwerkconnectiviteit en controle te implementeren met redelijk prescriptieve acties. In andere industrieën zijn er daarentegen vaak geen wettelijke vereisten of nalevingsbeleid, wat heeft geleid tot wijdverbreide verschillen in beveiligingsmogelijkheden.

In veel industrieën bestaan ​​de besturingssystemen uit pakketten, skids of componenten die op zichzelf staan ​​en kunnen worden geïntegreerd als semi-autonome delen van het netwerk. Deze pakketten zijn mogelijk niet zo volledig of nauw geïntegreerd in het algehele controlesysteem, netwerkbeheertools of beveiligingstoepassingen, wat een potentieel risico met zich meebrengt.

Alomtegenwoordige oudere systemen

Vanwege de statische aard en lange levenscycli van apparatuur in industriële omgevingen, kunnen veel operationele systemen als legacy-systemen worden beschouwd. In een energiebedrijfsomgeving is het bijvoorbeeld niet ongebruikelijk dat rekken met oude mechanische apparatuur nog steeds naast moderne intelligente elektronische apparaten (IED's) werken. In veel gevallen zijn verouderde componenten niet beperkt tot geïsoleerde netwerksegmenten, maar zijn ze nu geconsolideerd in de operationele IT-omgeving. Vanuit veiligheidsoogpunt is dit potentieel gevaarlijk omdat veel apparaten mogelijk historische kwetsbaarheden of zwakke punten hebben die niet zijn gepatcht en bijgewerkt, of het kan zijn dat patches niet eens beschikbaar zijn vanwege de leeftijd van de apparatuur.

Naast de eindpunten zijn de communicatie-infrastructuur en gedeelde gecentraliseerde computerbronnen vaak niet gebouwd om te voldoen aan moderne normen. In feite kunnen hun communicatiemethoden en protocollen generaties oud zijn en moeten ze interoperabel zijn met de oudste operationele entiteit in het communicatiepad. Dit omvat switches, routers, firewalls, draadloze toegangspunten, servers, systemen voor externe toegang, patchbeheer en tools voor netwerkbeheer. Deze kunnen allemaal kwetsbare punten bevatten en moeten worden beschermd.

Onveilige operationele protocollen

Veel industriële besturingsprotocollen, met name seriële protocollen, zijn ontworpen zonder inherente strenge beveiligingseisen. Bovendien was hun werking vaak binnen een verondersteld beveiligd netwerk. Naast eventuele inherente zwakke punten of kwetsbaarheden, is hun operationele omgeving mogelijk niet ontworpen met het oog op beveiligde toegangscontrole.

Industriële protocollen, zoals toezichtcontrole en data-acquisitie (SCADA) (zie hoofdstuk 6, "Application Protocols for IoT"), met name de oudere varianten, lijden aan veelvoorkomende beveiligingsproblemen. Drie voorbeelden hiervan zijn een veelvuldig gebrek aan authenticatie tussen communicatie-eindpunten, geen manier om gegevens in rust of in beweging te beveiligen en te beschermen, en onvoldoende controle om ontvangers correct te specificeren of standaard uitzendbenaderingen te vermijden. Deze zijn misschien niet zo kritisch in zelfstandige systemen, maar tussen zones of op langere netwerksegmenten, zoals een WAN (met name een openbare WAN), kunnen ze belangrijke overwegingen zijn.

De structuur en werking van de meeste van deze protocollen is vaak openbaar. Hoewel ze afkomstig zijn van een particulier bedrijf, worden ze omwille van de interoperabiliteit doorgaans gepubliceerd zodat anderen ze kunnen implementeren. Het wordt dus een relatief eenvoudige zaak om de protocollen zelf te compromitteren en kwaadwillende actoren te introduceren die ze kunnen gebruiken om controlesystemen te compromitteren voor verkennings- of aanvalsdoeleinden die kunnen leiden tot ongewenste effecten bij normaal systeemgebruik.

In de volgende secties worden enkele veelvoorkomende industriële protocollen en hun respectieve beveiligingsproblemen besproken. Merk op dat velen seriële, IP- of Ethernet-versies hebben en dat de beveiligingsuitdagingen en kwetsbaarheden verschillen voor de verschillende varianten.

Modbus

Modbus wordt vaak aangetroffen in veel industrieën, zoals nutsbedrijven en productieomgevingen, en heeft meerdere varianten (bijvoorbeeld serieel, TCP / IP). Het is gemaakt door de eerste programmable logic controller (PLC) -verkoper, Modicon, en is sinds de jaren zeventig in gebruik. Het is een van de meest gebruikte protocollen bij industriële implementaties en de ontwikkeling ervan wordt beheerd door de Modbus-organisatie. Raadpleeg hoofdstuk 6 voor meer informatie over Modbus.

De beveiligingsuitdagingen die bij Modbus hebben bestaan, zijn niet ongebruikelijk. Verificatie van communicerende eindpunten was geen standaardbewerking omdat het een ongepaste bron zou toestaan ​​om onjuiste opdrachten naar de ontvanger te sturen. Om bijvoorbeeld een bericht zijn bestemming te laten bereiken, is niets meer nodig dan het juiste Modbus-adres en functieaanroep (code).

Sommige oudere en seriële versies van Modbus communiceren via uitzending. De mogelijkheid om de uitzendfunctie te beteugelen bestaat in sommige versies niet. Er is een mogelijkheid voor een ontvanger om te reageren op een commando dat er niet specifiek op was gericht. Bovendien kan een aanval mogelijk onbedoelde ontvangende apparaten beïnvloeden, waardoor de noodzaak om de details van de netwerktopologie te begrijpen wordt verminderd.

Validatie van de inhoud van het Modbus-bericht wordt ook niet uitgevoerd door de initiërende applicatie. In plaats daarvan is Modbus afhankelijk van de netwerkstack om deze functie uit te voeren. Dit zou de mogelijkheid van misbruik van protocollen in het systeem kunnen openen.

DNP3 (Distributed Network Protocol)

DNP3 is te vinden in meerdere implementatiescenario's en industrieën. Het komt veel voor in hulpprogramma's en wordt ook aangetroffen in discrete en continue processystemen. Net als veel andere ICS / SCADA-protocollen was het bedoeld voor seriële communicatie tussen controllers en eenvoudige IED's. (Voor meer gedetailleerde informatie over DNP3, zie Hoofdstuk 6.)

Er is een expliciete "veilige" versie van DNP3, maar er blijven ook veel onveilige implementaties van DNP3. DNP3 heeft grote nadruk gelegd op de betrouwbare bezorging van berichten. Die nadruk, hoewel normaal gesproken zeer wenselijk, heeft vanuit veiligheidsoogpunt een specifieke zwakte. In het geval van DNP3 staan ​​deelnemers ongevraagde reacties toe, die een ongewenste reactie kunnen veroorzaken. Het ontbrekende beveiligingselement hier is het vermogen om vertrouwen te wekken in de staat van het systeem en dus het vermogen om de waarheidsgetrouwheid van de gepresenteerde informatie te vertrouwen. Dit komt overeen met de beveiligingsfouten van Gratuitous ARP-berichten in Ethernet-netwerken, die zijn aangepakt door Dynamic ARP Inspection (DAI) in moderne Ethernet-switches.

ICCP (Inter-Control Center Communications Protocol)

ICCP is een algemeen controleprotocol in hulpprogramma's in Noord-Amerika dat vaak wordt gebruikt om tussen hulpprogramma's te communiceren. Aangezien het de grenzen tussen verschillende netwerken moet overschrijden, heeft het een extra niveau van blootstelling en risico dat een hulpprogramma zou kunnen blootstellen aan een cyberaanval.

In tegenstelling tot andere besturingsprotocollen, is ICCP vanaf het begin ontworpen om via een WAN te werken. Ondanks deze rol vertoonden de eerste versies van ICCP verschillende belangrijke hiaten op het gebied van beveiliging. Een belangrijke kwetsbaarheid is dat het systeem geen authenticatie vereist voor communicatie. Ten tweede was versleuteling over het protocol niet standaard ingeschakeld, waardoor verbindingen werden blootgesteld aan man-in-the-middle (MITM) en herhalingsaanvallen.

OPC (OLE voor Process Control)

OPC is gebaseerd op de Microsoft-interoperabiliteitsmethode Object Linking and Embedding (OLE). Dit is een voorbeeld waarbij een IT-standaard die wordt gebruikt binnen het IT-domein en pc's is gebruikt voor gebruik als besturingsprotocol in een industrieel netwerk.

In industriële controlenetwerken is OPC beperkt tot werking op de hogere niveaus van de controleruimte, met een afhankelijkheid van op Windows gebaseerde platforms. Zorgen rond OPC beginnen met het besturingssysteem waarop het werkt. Veel van de Windows-apparaten in de operationele ruimte zijn oud, niet volledig gepatcht en lopen gevaar vanwege een overvloed aan bekende kwetsbaarheden. De afhankelijkheid van OPC kan die afhankelijkheid versterken. Hoewel nieuwere versies van OPC verbeterde beveiligingsmogelijkheden hebben, hebben ze ook nieuwe communicatiemodi geopend, die zowel een positief als een negatief beveiligingspotentieel hebben.

Bijzonder zorgwekkend bij OPC is de afhankelijkheid van het Remote Procedure Call (RPC) -protocol, dat twee blootstellingsklassen creëert. De eerste vereist dat u de vele kwetsbaarheden die aan RPC zijn verbonden duidelijk begrijpt, en de tweede vereist dat u het risiconiveau identificeert dat deze kwetsbaarheden voor een specifiek netwerk met zich meebrengen.

International Electrotechnical Commission (IEC) Protocollen

De IEC 61850-standaard is gemaakt om leveranciersonafhankelijke engineering van energiesystemen mogelijk te maken, wat op zijn beurt interoperabiliteit tussen leveranciers en gestandaardiseerde communicatieprotocollen mogelijk zou maken. Aanvankelijk werden drie berichttypen gedefinieerd: MMS (Manufacturing Message Specification), GOOSE (Generic Object Oriented Substation Event) en SV (Sampled Values). Webservices was een vierde protocol dat later werd toegevoegd. Hier geven we een korte samenvatting van elk, maar voor meer informatie over IEC-protocollen, zie hoofdstuk 11:

  • MMS (61850-8.1): MMS is een client / server-protocol dat gebruik maakt van TCP / IP en werkt op Layer 3. Het biedt dezelfde functionaliteit als andere SCADA-protocollen, zoals IEC 60870 en Modbus.

  • GOOSE (61850-8.1): GOOSE is een Layer 2-protocol dat werkt via multicast via Ethernet. Hiermee kunnen IED's gegevens 'horizontaal' uitwisselen tussen bays en tussen onderstations, met name voor vergrendelings-, meet- en uitschakelsignalen.

  • SV (61850-9-2): SV is een Layer 2-protocol dat werkt via multicast via Ethernet. Het draagt ​​spanning- en stroommonsters, meestal op de procesbus, maar kan ook over de stationsbus stromen.

Zowel GOOSE als SV werken via een publisher / abonneemodel, zonder betrouwbaarheidsmechanisme om ervoor te zorgen dat gegevens zijn ontvangen.

IEC 61850 heeft verschillende bekende beveiligingstekorten die kunnen worden benut door bekwame aanvallers om een ​​controlesysteem in gevaar te brengen. Verificatie is ingebed in MMS, maar is gebaseerd op wachtwoorden met duidelijke tekst en verificatie is niet beschikbaar in GOOSE of SV. Firmware is doorgaans niet ondertekend, wat betekent dat er geen manier is om de authenticiteit of integriteit ervan te verifiëren. GOOSE en SV hebben een beperkte berichtintegriteit, waardoor het relatief eenvoudig is om zich voor te doen als een uitgever.

Toen de standaard voor het eerst werd uitgebracht, was er een minimale beveiligingsmogelijkheid in deze protocollen, maar dit wordt aangepakt door IEC 62351 met de introductie van bekende IT-gebaseerde beveiligingsmaatregelen, zoals certificaatuitwisseling.

IEC 60870 wordt veel gebruikt voor SCADA-telecontrole in Europa, met name in de energiesector en voor geografisch verspreide besturingssystemen. Deel 5 van de standaard schetst de communicatieprofielen die tussen eindpunten worden gebruikt om telecontroleberichten uit te wisselen. 60870-5-101 is het seriële implementatieprofiel, 60870-5-104 is het IP-implementatieprofiel en 60870-5-103 wordt gebruikt voor beschermingsapparatuur. Nogmaals, in de vroege iteraties van IEC 60870-5 ontbrak de beveiliging. Dit wordt nu aangepakt door IEC 62351, waarbij de 60870-5-7-beveiligingsuitbreidingen werken, van toepassing op 60870-101 en 60870-104.

Andere protocollen

Soms zijn discussies over de beveiliging van industriële systemen beslist gericht op industriële controleprotocollen alsof ze het totaal zijn van wat zou worden waargenomen of overwogen. Deze aanname is bekrompen en problematisch op vele niveaus. In feite wordt het ten zeerste aanbevolen dat een beveiligingsmedewerker passief alle aspecten van het verkeer dat het netwerk doorkruist, identificeert alvorens enige vorm van controle of beveiligingsmaatregelen daarin te implementeren. Van bijzonder belang zijn een goede boekhouding, behandeling en begrip van de meest elementaire protocollen, transportmechanismen en fundamentele elementen van elk netwerk, inclusief ARP, UDP, TCP, IP en SNMP.

Sommige gespecialiseerde omgevingen hebben mogelijk ook andere protocollen voor achtergrondcontrole. Veel IoT-netwerken reiken bijvoorbeeld helemaal tot aan de individuele sensoren, dus protocollen zoals Constrained Application Protocol (CoAP) (zie hoofdstuk 6) en Datagram Transport Layer Security (DTLS) worden gebruikt en moeten afzonderlijk van een beveiliging worden beschouwd perspectief.

Apparaatonzekerheid

Naast de communicatieprotocollen die worden gebruikt en de installatiebasis van oudere systemen, hebben besturings- en communicatie-elementen zelf een geschiedenis van kwetsbaarheden. Zoals eerder in dit hoofdstuk vermeld (zie figuur 8.1 ), besteedde de beveiligingsgemeenschap vóór 2010 weinig aandacht aan industriële computers, en daardoor hebben OT-systemen niet dezelfde "proef door brand" doorlopen als IT-systemen. Figuur 8-2 laat dit grafisch zien door simpelweg het aantal industriële beveiligingsonderwerpen dat op de Black Hat-beveiligingsconferentie wordt gepresenteerd, te overlappen met het aantal gerapporteerde kwetsbaarheden voor industriële controlesystemen. Het verband tussen presentaties over OT-beveiliging bij Black Hat en het aantal ontdekte kwetsbaarheden is duidelijk, inclusief de daarmee gepaard gaande vertraging van ontdekkingen.










Afbeelding 8-2 Correlatie van industriële Black Hat-presentaties met ontdekte industriële kwetsbaarheden (US Industrial Control Systems Cyber ​​Emergency Response Team (ICS-CERT) https://ics-cert.us-cert.gov ).


Om de aard van de apparaatonzekerheid te begrijpen, is het belangrijk om de geschiedenis te bekijken van welke kwetsbaarheden zijn ontdekt en welke soorten apparaten zijn aangetast. Uit een evaluatie van de periode 2000-2010 blijkt dat het merendeel van de ontdekkingen zich op de hogere niveaus van het operationele netwerk bevonden, waaronder controlesystemen die worden vertrouwd om fabrieken, transmissiesystemen, oliepijpleidingen of welke kritieke functie dan ook te bedienen.

Het is niet moeilijk te begrijpen waarom dergelijke systemen vaak kwetsbaar worden bevonden. Ten eerste maken veel van de systemen gebruik van softwarepakketten die gemakkelijk kunnen worden gedownload en waar tegen kan worden gewerkt. Ten tweede werken ze op veelgebruikte hardware en standaardbesturingssystemen, zoals Microsoft Windows. Ten derde zijn Windows en de componenten die in die applicaties worden gebruikt, bekend bij traditioneel IT-gerichte beveiligingsonderzoekers. Het is weinig nodig om nieuwe tools of technieken te ontwikkelen wanneer de tools die al lang bestaan ​​voldoende zijn om de verdediging van het doelwit te doorbreken. Zo was Stuxnet, de beroemdste van de op industriële computers gebaseerde aanvallen, aanvankelijk succesvol omdat het in staat was een voorheen onbekende kwetsbaarheid in Windows te misbruiken.

De ICS-leveranciersgemeenschap loopt ook achter op IT-tegenhangers met betrekking tot beveiligingsmogelijkheden en -praktijken, evenals samenwerking met externe beveiligingsonderzoekers. Dat gezegd hebbende, begint deze situatie veel aandacht te krijgen voor de sector en wordt deze verbeterd door een aantal recente initiatieven die zijn ontworpen om de kwetsbaarheid voor beveiliging en systeemtesten in de industriële omgeving formeel aan te pakken. Hoewel er enkele formele normen zijn, zoals ISO / IEC 15408 (Common Criteria), ISO / IEC 19790 en een paar andere, blijven er weinig formele beveiligingstestentiteiten bestaan. Afgezien van formele tests, is er weinig wettelijke handhaving van algemene criteria die betrekking hebben op beveiligingstests van apparaten.

Het is nog niet zo lang geleden dat de veiligheidsonderzoeksgemeenschap werd gezien als een bedreiging in plaats van als een gewaardeerde en vaak gratis dienst om potentiële gevaren bloot te leggen. Hoewel de situatie is verbeterd, lopen de operationele inspanningen nog steeds aanzienlijk achter op IT-gebaseerde initiatieven, zoals beloningsprogramma's voor bugbounty's en geavanceerde programma's ter voorbereiding op kwetsbaarheden, in de trant van zoiets als het Microsoft Active Protections Program (MAPP). Om nog een stap verder te gaan, in de industriële wereld, zijn er zelfs geen parallellen met de wetten die de privégegevens van individuen beschermen. Hoewel veel staten en landen een melding vereisen als persoonlijke en financiële gegevens van een persoon mogelijk worden onthuld, vereisen zeer weinig wetten, buiten de elektriciteitssector, de melding van incidenten die levens in gevaar kunnen brengen.

Afhankelijkheid van externe leveranciers

Hoewel moderne IT-omgevingen bedrijfsactiviteiten kunnen uitbesteden of bepaalde verwerkings- of opslagfuncties naar de cloud kunnen degraderen, is het minder gebruikelijk dat de fabrikanten van originele apparatuur van de IT-hardwareactiva de apparatuur moeten bedienen. Dat niveau van leveranciersafhankelijkheid is echter niet ongebruikelijk in sommige industriële ruimtes.

Directe en on-demand toegang tot kritieke systemen op de fabrieksvloer of in het veld worden soms rechtstreeks in contracten geschreven of zijn vereist voor geldige productgaranties. Dit heeft duidelijke voordelen in veel bedrijfstakken, aangezien leveranciers hierdoor apparatuur op afstand kunnen beheren en bewaken en de klant proactief kunnen waarschuwen als er problemen beginnen binnen te sluipen. Er kunnen contracten worden geschreven om de bewaking en het beheer van apparatuur te beschrijven met expliciete verklaringen van welk type toegang is vereist en onder welke voorwaarden behandelen zij in het algemeen geen vragen over gedeelde aansprakelijkheid voor inbreuken op de beveiliging of processen om de communicatiebeveiliging te waarborgen.

Dergelijke afhankelijkheid en controle van leveranciers is niet beperkt tot toegang op afstand. Onsite beheer van niet-werknemers die computer- en netwerktoegang moeten krijgen, is ook vereist, maar nogmaals, controlevoorwaarden en verklaringen met gedeelde verantwoordelijkheid moeten nog worden nageleefd.

Beveiligingskennis

In de industriële operatieruimte ligt de technische investering voornamelijk in connectiviteit en rekenkracht. Het heeft veel minder investeringen in beveiliging gezien in vergelijking met zijn IT-tegenhanger. Volgens het onderzoeksbureau Infonetics was de markt voor industriële firewall in 2015 slechts ongeveer 4% van de totale firewallmarkt.

Een andere relevante uitdaging op het gebied van OT-beveiligingsexpertise is de relatief hogere leeftijd van de industriële beroepsbevolking. Volgens een studie van het Amerikaanse Bureau of Labor is in Noord-Amerika het gemiddelde leeftijdsverschil tussen fabrieksarbeiders en andere niet-agrarische werknemers tussen 2000 en 2012 verdubbeld, en de trend vertoont geen tekenen van omkering. Tegelijkertijd worden nieuwe connectiviteitstechnologieën geïntroduceerd in industriële OT-omgevingen die up-to-date vaardigheden vereisen, zoals TCP / IP, Ethernet en draadloos, die snel op seriële gebaseerde legacy-technologieën vervangen. De snelle uitbreiding van uitgebreide communicatienetwerken en de behoefte aan een industrieel controlebewust personeelsbestand creëert een even ernstige kloof in het beveiligingsbewustzijn.

Deze leemte in OT-beveiligingskennis wordt actief aangepakt. Het onderwijs voor industriële beveiligingsomgevingen is gestaag gegroeid, met name in de elektriciteitssector, waar voorschriften zoals NERC CIP (CIP 004) en IEC 62351 (01) voortdurende training vereisen.

Vanwege het belang van veiligheid in de industriële ruimte worden alle waarschijnlijke aanvalsoppervlakken als onveilig behandeld. Helaas blijft er, gezien de mogelijke enorme publieke impact van het schenden van deze systemen, een gezonde paranoia over de verbinding van IT-centrische technologieën en externe verbindingen, ondanks de enorme hoeveelheid investeringen in beveiliging op deze gebieden. Het naar een hoger niveau brengen van industriële netwerken is een langzaam proces als gevolg van diepe historische culturele en filosofische verschillen tussen OT- en IT-omgevingen.



Vorige sectie

3. Hoe IT- en OT-beveiligingspraktijken en -systemen verschillen | 

Volgende sectie

Home > Artikelen > IoT beveiligen