{"id":28791,"date":"2023-03-21T09:00:24","date_gmt":"2023-03-21T07:00:24","guid":{"rendered":"https:\/\/www.kaspersky.nl\/blog\/?p=28791"},"modified":"2023-03-21T00:26:51","modified_gmt":"2023-03-20T22:26:51","slug":"updating-ot-infrastructure","status":"publish","type":"post","link":"https:\/\/www.kaspersky.nl\/blog\/updating-ot-infrastructure\/28791\/","title":{"rendered":"Het middel tegen operationeel technologisch conservatisme"},"content":{"rendered":"

Ik zeg het vaak, en al jaren: antivirus is dood<\/a>.<\/p>\n

Zo\u2019n uitspraak kan op het eerste gezicht vreemd lijken, en al helemaal van iemand die zich al sinds de begindagen<\/a> bezighoudt met alles wat met virussen en antivirussen te maken heeft in de late jaren tachtig<\/a> en vroege jaren negentig<\/a>. Als u zich echter wat verder verdiept in het onderwerp AV (RIP) en enkele gezaghebbende bronnen in het (voormalige) veld raadpleegt, wordt de verklaring al snel vrij logisch: ten eerste is \u201cantivirus\u201d veranderd in beschermende oplossingen \u201ctegen alles\u201d, en ten tweede zijn virussen, in de zin van bepaald soort kwaadaardig programma, uitgestorven. Bijna dan toch.<\/em> En het is dat schijnbaar onschuldige, verwaarloosbare woordje bijna<\/em> dat ik daarnet schreef dat tot op de dag van vandaag problemen veroorzaakt voor cybersecurity. En dat aan het eind van het jaar 2022! En die bijna<\/em> de basis van deze blogpost van vandaag\u2026<\/p>\n

Goed. Virussen. Die laatste overgeblevenen op de Rode Lijst<\/a>. Waar zijn ze tegenwoordig en wat doen ze zoal?<\/p>\n

Het blijkt dat die zich bevinden in\u2026 een van de meest conservatieve deelgebieden van de industri\u00eble automatisering: dat van de operationele technologie<\/a> (dat is dus OT<\/em>, niet te verwarren met IT). OT is \u201chardware en software die een verandering detecteert of veroorzaakt door directe monitoring en\/of controle van industri\u00eble apparatuur, activa, processen en gebeurtenissen\u201d (\u2013 Wikipedia). In wezen heeft OT betrekking op een omgeving met industri\u00eble controlesystemen (ICS<\/a>), soms ook wel \u201cniet-beklede gebieden\u201d genoemd. OT = gespecialiseerde controlesystemen in fabrieken, elektriciteitscentrales, transportsystemen, de nutssector, en de winning-, verwerkings- en andere zware industrie\u00ebn. We hebben het dan dus over infrastructuur. Kritieke<\/em> infrastructuur. En het is in deze industri\u00eble\/kritische infrastructuur waar \u201cdode\u201d computervirussen tegenwoordig springlevend zijn: ongeveer 3% van de cyberincidenten<\/a> waarbij OT-computers betrokken zijn, wordt tegenwoordig veroorzaakt door dit soort malware.<\/p>\n

Hoe kan dat?<\/p>\n

Ik heb het antwoord daarop hierboven eigenlijk al gegeven: OT \u2013 beter gezegd, de toepassing ervan in de industrie \u2013 is zeer conservatief. Als er ooit een sector is geweest die sterk gelooft in het oude axioma \u201cif it ain\u2019t broke, don\u2019t fix it!<\/em>\u201c, dan is het wel de OT-sector. Het belangrijkste bij OT is stabiliteit, en dus niet de nieuwste toeters en bellen. Nieuwe versies, upgrades\u2026 zelfs gewoon updates (bijvoorbeeld van software) worden allemaal met scepsis, minachting of zelfs angst bekeken. De operationele technologie in industri\u00eble controlesystemen wordt namelijk vaak gekenmerkt door krakende oude computers met\u2026 Windows 2000 (!) plus allerlei andere antieke software vol kwetsbaarheden (er is ook sprake van gigantische gaten in het beveiligingsbeleid en een nog tal van andere vreselijke nachtmerries voor de IT-beveiliger). Maar om even terug te komen op die zogenaamde \u201cniet-beklede gebieden\u201d: de IT-kit in de beklede gebieden (bijvoorbeeld op kantoor, en dus niet de productievloer of de ondersteunende\/technische faciliteiten) is allang tegen alle virussen beschermd, aangezien deze tijdig wordt bijgewerkt, ge\u00fcpgraded en gereviseerd, en volledig wordt beschermd door moderne cybersecurity-oplossingen. Maar in de niet-beklede gebieden (OT) is alles precies omgekeerd; vandaar dat daar virussen overleven \u00e9n gedijen.<\/p>\n

Bekijk de top-10 van meest verspreide \u201cold-school\u201d schadelijke programma\u2019s die in 2022 in ICS-computers worden aangetroffen:<\/p>\n

\"\"<\/a><\/p>\n

Sality<\/a>! Virut<\/a>! Nimnul<\/a>!<\/p>\n

Wat vertelt deze grafiek ons?<\/p>\n

Laat ik u eerst<\/strong> vertellen dat de hierboven vermelde percentages betrekking hebben op een \u201cslapende\u201d fase voor deze \u201cold-school\u201d virussen. Maar van tijd tot tijd kunnen dergelijke virussen de grenzen van een enkel besmet systeem overschrijden en zich over het hele netwerk verspreiden. En dat leidt dan weer tot een ernstige lokale epidemie. En in plaats van een complete, afdoende behandeling worden meestal gewoon de goede oude back-ups gebruikt, en die zijn niet altijd \u201cschoon\u201d. Bovendien kan de infectie niet alleen ICS-computers treffen, maar ook PLC\u2019s (Programmable Logic Controllers<\/a>). Zo was de Sality loader al lang voor het verschijnen van Blaster<\/a> (een proof-of-concept worm die de firmware van PLC\u2019s kan infecteren) aanwezig. Nou ja, bijna dan toch: niet in de firmware, maar in de vorm van een script in HTML-bestanden van de webinterface.<\/p>\n

Dus ja, Sality kan een echte puinhoop maken van geautomatiseerde productieprocessen, maar dat is nog niet alles. Het kan het geheugen aantasten via een schadelijke driver, en ook de bestanden en het geheugen van toepassingen infecteren. Dit kan vervolgens weer binnen enkele dagen leiden tot een volledige uitval van een industrieel besturingssysteem. En in geval van een actieve infectie kan het hele netwerk worden platgelegd, aangezien Sality sinds 2008 peer-to-peer communicatie gebruikt om de lijst van actieve controlecentra bij te werken. De fabrikanten van ICS zouden de code waarschijnlijk niet hebben geschreven met zo\u2019n agressieve werkomgeving in gedachten.<\/p>\n

Ten tweede:<\/strong> 0,14% in een maand klinkt niet als veel, maar\u2026 het vertegenwoordigt duizenden gevallen van kritieke infrastructuur over de hele wereld. Erg jammer als u bedenkt hoe een dergelijk risico volledig, eenvoudig en met de meest fundamentele methoden zou kunnen worden uitgesloten.<\/p>\n

En ten derde<\/strong>, aangezien de cybersecurity van fabrieken zo vol gaten zit, is het geen wonder dat we vaak nieuws horen over succesvolle aanvallen op die fabrieken met andere soorten malware \u2013 met name ransomware (voorbeeld: Snake vs Honda<\/a>).<\/p>\n

Het is duidelijk waarom OT-mensen conservatief zijn: het belangrijkste voor hen is dat de industri\u00eble processen waarop zij toezien ononderbroken blijven, en de invoering van nieuwe technologie\/updating\/upgrades kan nou eenmaal onderbrekingen veroorzaken. Maar hoe zit het met de onderbrekingen door ouderwetse virusaanvallen die juist mogelijk zijn omdat er achter de feiten wordt aangelopen? Precies, en dat is het dilemma waarmee OT-mensen worden geconfronteerd \u2013 en meestal nemen ze er genoegen mee achter de feiten aan te lopen, en zo komen we dus aan die cijfers in de grafiek.<\/p>\n

Maar raad eens? Dat dilemma kan tot het verleden behoren met onze speciale \u201cpil\u201d\u2026<\/p>\n

Idealiter moet er een mogelijkheid zijn om te innoveren, te updaten en te upgraden zonder risico voor de continu\u00efteit van de industri\u00eble processen. En vorig jaar hebben we een systeem gepatenteerd dat precies daarvoor zorgt\u2026<\/p>\n

In het kort gaat het zo: alvorens iets nieuws te introduceren in de processen die MOETEN blijven draaien, test u het op een nagebouwd model van het echte werk dat de kritieke industri\u00eble functies nabootst.<\/p>\n

Dit model bestaat uit een configuratie van het gegeven OT-netwerk, die dezelfde soorten apparaten inschakelt die in het industri\u00eble proces worden gebruikt (computers, PLC\u2019s, sensoren, communicatieapparatuur, diverse IoT-kits) en ze met elkaar laat interageren om het productie- of andere industri\u00eble proces na te bootsen. In de invoerterminal van dit model bevindt zich een monster van de geteste software, dat wordt geobserveerd door een sandbox<\/a>, die alle acties registreert, de reacties van de netwerkknooppunten, de veranderingen in hun prestaties, de toegankelijkheid van de verbindingen en vele andere atomaire kenmerken waarneemt. Met de zo verkregen data kan er vervolgens een model worden opgesteld dat de risico\u2019s van nieuwe software beschrijft, zodat met kennis van zaken beslissingen kunnen worden genomen over de vraag of deze nieuwe software al dan niet moet worden ingevoerd en wat er aan de OT moet worden gedaan om de aan het licht gekomen kwetsbaarheden te verhelpen.<\/p>\n

Maar wacht, want het wordt nog interessanter\u2026<\/p>\n

U kunt letterlijk alles in de invoerterminal testen \u2013 niet alleen nieuwe software en uit te rollen updates. U kunt bijvoorbeeld testen op bestendigheid tegen schadelijke programma\u2019s die externe beschermingsmiddelen omzeilen en een beschermd industrieel netwerk binnendringen.<\/p>\n

Dergelijke technologie heeft veel potentieel op het gebied van verzekeringen. Verzekeringsmaatschappijen zullen cyberrisico\u2019s beter kunnen inschatten voor nauwkeurigere berekeningen van verzekeringspremies, terwijl de verzekerden niet zonder reden te veel zullen betalen. Ook zullen fabrikanten van industri\u00eble apparatuur testmodellen kunnen gebruiken voor de certificering van software en hardware van externe ontwikkelaars. Als we dit concept verder ontwikkelen, zou een dergelijke regeling ook geschikt zijn voor sectorspecifieke accreditatiecentra. En dan is er nog het onderzoekspotentieel in onderwijsinstellingen!<\/p>\n

Maar laten we nu nog eens terugkeren naar ons fabrieksmodel\u2026<\/p>\n

Het spreekt vanzelf dat geen enkele emulatie de volledige verscheidenheid van processen in OT-netwerken met 100% nauwkeurigheid kan reproduceren. Op basis van het model dat wij op basis van onze ruime ervaring hebben opgebouwd, weten we echter al waar de \u201cverrassingen\u201d te verwachten zijn na de invoering van nieuwe software. Bovendien kunnen wij de situatie op betrouwbare wijze controleren met andere methoden \u2013 bijvoorbeeld met ons waarschuwingssysteem voor anomalie\u00ebn, MLAD<\/a> (waarover ik hier<\/a> al in detail heb geschreven), dat op basis van directe of zelfs indirecte correlaties problemen in bepaalde delen van een industrieel bedrijf kan opsporen. Zo kunnen er miljoenen, zo niet miljarden dollars aan verliezen door incidenten worden voorkomen.<\/p>\n

Dus wat houdt OT-mensen tegen om dit model van ons over te nemen?<\/p>\n

Tja, misschien zoeken ze vooralsnog \u2013 omdat ze zo conservatief zijn \u2013 niet actief naar een oplossing als de onze, omdat ze die misschien niet nodig vinden (!). Wij zullen natuurlijk ons best doen om onze technologie te promoten om de industrie miljoenen te besparen, maar in de tussentijd wil ik dit nog kwijt: ons model, hoewel complex, betaalt zichzelf zeer snel terug als het wordt overgenomen door een grote industri\u00eble\/infrastructurele organisatie. En het is geen abonnementsmodel of zoiets: het wordt \u00e9\u00e9n keer gekocht en blijft dan jarenlang zonder extra investeringen de boel redden (met een minimum aan regelgevings-, reputatie- en operationele risico\u2019s). O, en het is ook goed voor het volgende: de zenuwen van OT-mensen\u2026 of hun verstand.<\/p>\n","protected":false},"excerpt":{"rendered":"

De specifieke aspecten van de bescherming en het updaten van de OT-infrastructuur.<\/p>\n","protected":false},"author":13,"featured_media":28792,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[108,252],"tags":[138,1235,1233,1234,233],"class_list":{"0":"post-28791","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"tag-ics","10":"tag-mlad","11":"tag-operationele-technologieen","12":"tag-ot","13":"tag-virussen"},"hreflang":[{"hreflang":"nl","url":"https:\/\/www.kaspersky.nl\/blog\/updating-ot-infrastructure\/28791\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/updating-ot-infrastructure\/24942\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/updating-ot-infrastructure\/20439\/"},{"hreflang":"ar","url":"https:\/\/me.kaspersky.com\/blog\/updating-ot-infrastructure\/10478\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/updating-ot-infrastructure\/27499\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/updating-ot-infrastructure\/25272\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/updating-ot-infrastructure\/25602\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/updating-ot-infrastructure\/28159\/"},{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/updating-ot-infrastructure\/27424\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/updating-ot-infrastructure\/34311\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/updating-ot-infrastructure\/46467\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/updating-ot-infrastructure\/19830\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/updating-ot-infrastructure\/20453\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/updating-ot-infrastructure\/29576\/"},{"hreflang":"ja","url":"https:\/\/blog.kaspersky.co.jp\/updating-ot-infrastructure\/33951\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/updating-ot-infrastructure\/25628\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/updating-ot-infrastructure\/31318\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/updating-ot-infrastructure\/31027\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.nl\/blog\/tag\/ics\/","name":"ICS"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.nl\/blog\/wp-json\/wp\/v2\/posts\/28791","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.nl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.nl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.nl\/blog\/wp-json\/wp\/v2\/users\/13"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.nl\/blog\/wp-json\/wp\/v2\/comments?post=28791"}],"version-history":[{"count":2,"href":"https:\/\/www.kaspersky.nl\/blog\/wp-json\/wp\/v2\/posts\/28791\/revisions"}],"predecessor-version":[{"id":28795,"href":"https:\/\/www.kaspersky.nl\/blog\/wp-json\/wp\/v2\/posts\/28791\/revisions\/28795"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.nl\/blog\/wp-json\/wp\/v2\/media\/28792"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.nl\/blog\/wp-json\/wp\/v2\/media?parent=28791"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.nl\/blog\/wp-json\/wp\/v2\/categories?post=28791"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.nl\/blog\/wp-json\/wp\/v2\/tags?post=28791"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}