Operationele technologie in industriële IoT tolereert IT-stijl patching niet. "Bedreigingsanalyse" is een veilige en krachtige oplossing

Over het industriële internet der dingen gesproken - (IIoT). Operationele technologie in het industriële internet der dingen (IoT) tolereert geen patching in IT-stijl. Het gebruik van "Bedreigingsanalyse" is een veilige en krachtige oplossing. Binnen bedrijven en over de hele wereld is het IIoT-ecosysteem een ​​nauw verweven en onderhandelde fusie van IT en OT. OT-systemen zijn niet alleen bedrijfskritisch, ze kunnen ook landkritisch zijn, of kritiek op leven en dood.

Elke industriële internet of things (IIoT)-klant die ik spreek, wil de sterkst mogelijke beveiliging. Geen internet der dingen – industriële internet der dingen (IIoT).

Wie binnen de organisatie van de klant zal dit proces uitvoeren en beheren? Tijdens een ontmoeting na een ontmoeting met klanten die IIoT-mogelijkheden bouwen, kom ik een natuurlijke, maar soms gespannen onzekerheid tegen tussen IT- en OT/LOB-professionals als het gaat om IIoT-beveiliging.

Deze kapitaalonzekerheid is zelf een beveiligingskwetsbaarheid omdat het de implementatie van essentiële beveiliging vertraagt.

Uit een recent Forrester-onderzoek onder IT- en OT/LOB-leiders bleek dat IT- en OT-managers gelijk verdeeld waren over de vraag of IT of OT verantwoordelijk is voor beveiliging, volgens DARKReading van InformationWeek. Als een alarmerend resultaat van deze impasse, meldt Forrester, is een onaanvaardbaar groot aantal bedrijven - 59 procent - bereid om "middelmatige tot hoge risico's met betrekking tot IoT-beveiliging te tolereren".

Ik geloof dat dit onjuist en verkeerd is voor bedrijven om deze verwaarlozing te laten voortduren - en ook gevaarlijk voor hun hele operaties.

Overweeg de verschillen tussen enterprise-IT en OT:

• Beschikbaarheid :
  IT beschouwt 99 procent uptime als acceptabel, terwijl OT 99,999 procent uptime vereist - het verschil tussen 8,76 uur en 5,25 minuten jaarlijkse downtime.
  • Levensduur van het systeem :
  IT-systemen worden gemiddeld om de drie tot vijf jaar vernieuwd. OT-systemen gaan daarentegen 10 tot 15 jaar mee.
  • Patching :
  IT-patches/updates kunnen worden uitgevoerd wanneer er updates beschikbaar zijn, maar OT-patching/updates lopen het risico strategische, inkomstengenererende industriële activiteiten te onderbreken.

Er zijn ook veel andere IT/OT-verschillen, zoals verschillende benaderingen van de cloud.

Alle verschillen worden echter opgevangen door de universele behoefte aan de meest veerkrachtige IIoT-beveiliging die beschikbaar is.

Een benadering waar ik de voorkeur aan geef, is industriële bedrijven te helpen de zwaarbevochten, lang bevochten lessen van IT te gebruiken om over te stappen naar een geavanceerde staat van IIoT-beveiliging. IIoT is vakkundig ontworpen en ingezet om te voldoen aan de gedifferentieerde vereisten van OT. Sommigen geloven dat de OT-systemen een andere vorm van datacenter zijn, de zwaar beschermde kern van enterprise-IT.

Er zijn enkele veelbelovende ideeën die je kunt aanpassen op basis van tientallen jaren IT-ervaring. Deze ideeën gebruiken en er vervolgens aan toevoegen om nieuwe niveaus van IIoT-beveiliging te bieden, terwijl de specifieke behoeften van OT worden gerespecteerd. Enkele van deze aanpassingen zijn de scheiding van eindpuntnetwerken, microsegmentatie en analyse van gebruikersgedrag (UBA). Ik zal deze in toekomstige stukken bespreken.

Met patchen , IT en OT spreken verschillende talen. Voer 'bedreigingsanalyse' in.

We begrijpen dat het patchproces bedoeld is om een ​​softwareprogramma bij te werken, te repareren of te verbeteren. Meestal een snelle oplossing - en vaak ook een lukrake. Als het echter om patchen gaat, is een directe overdracht van de dagelijkse IT-praktijk naar OT niet altijd haalbaar.

Als het op patchen aankomt, spreken IT en OT verschillende talen.

Het is essentieel dat de IIoT-industrie, IT en OT, samenkomen in het belang van hun ondernemingen. Dit vereist dieper nadenken en meer verbeeldingskracht om robuuste cyberbeveiligingstechnieken te ontwikkelen. Deze operaties zullen noodzakelijkerwijs flexibeler en effectiever moeten zijn dan reflexieve patching.

Patches kunnen problemen veroorzaken voor OT. Zoals we zien met patches voor de Meltdown en Spectre CPU-kwetsbaarheden, kan een patch de zaken soms erger maken. Vroege patches voor Meltdown en Spectre hadden invloed op de prestaties van het hele systeem.

De harde waarheid is dat de zachte onderbuik van de moderne industriële economie grotendeels oude OT-machines zijn. Als iets in de IT-wereld is geïnfecteerd, is het eerste instinct om het snel af te sluiten en te patchen (of te vervangen). Maar in OT is vaak het tegenovergestelde waar:keep it up and running.

Sommige cruciale OT-systemen staan ​​al 15 tot 25 jaar of langer op fabrieksvloeren. Deze baby's kunnen niet gemakkelijk worden verwijderd en gepatcht. Zelfs als er een geschikte patch beschikbaar zou zijn - die systemen hebben over het algemeen niet genoeg geheugen of CPU-bandbreedte om patches te accepteren.

Ten slotte is er de kwestie van de relatieve complexiteit en kwetsbaarheid van OT-systemen in vergelijking met IT-systemen.

IT-systemen kunnen worden afgebroken, gepatcht en opnieuw opgestart om identieke service te leveren. IT kan racks met identieke servers gebruiken, en als er een uitvalt of uitvalt, neemt de volgende in de rij het zonder problemen over. Maar OT-systemen zijn vaak sterk georkestreerde combinaties van software en hardware met 'persoonlijkheden'.

Zelfs als bedrijven machines kunnen uitschakelen om te patchen – als ze weer in de lucht komen – kunnen de resultaten onvoorspelbaar zijn. Het is niet hetzelfde systeem omdat de patch wildcards heeft geïntroduceerd die zich kunnen vermenigvuldigen via andere elementen van het systeem.

In OT is onvoorspelbaarheid niet acceptabel.

Kortom: er moet een betere manier zijn om IIoT-systemen te beschermen dan reflexmatig patchen OF het negeren van een beveiligingsrisico omdat patchen gewoon niet haalbaar is - om alle redenen die ik zojuist heb uiteengezet.

DE BETERE MANIER:"BEDREIGINGSANALYSE"

De betere benadering in OT is om beveiligingsuitdagingen op een veel gedetailleerdere manier te onderzoeken dan nu het geval is. Ik stel voor dat we de eeuwenoude benadering van dreigingsanalyse gebruiken voor patchen.

Eerste stap in dreigingsanalyse:

Wacht met het nemen van onmiddellijke actie. Dat betekent wachten met patchen, niet met patchen, wat dan ook. Wacht even totdat we valideren of er daadwerkelijk een systeemkwetsbaarheid bestaat - en zo ja, hoe kan deze worden misbruikt?

Er zijn meerdere factoren waarmee u rekening moet houden.

Sommige systemen die diep in ondernemingen actief zijn, kunnen inderdaad kwetsbaarheden hebben. Omdat het systeem zo geïsoleerd is binnen de onderneming, is het daadwerkelijke veiligheidsrisico minder dan het risico van het afsluiten van systemen voor patching – ervan uitgaande dat er zelfs maar een patch bestaat.

De calculus verandert bij het evalueren van systemen die worden blootgesteld aan de cloud of internet - daar is het beveiligingsrisico duidelijk veel groter.

Bedreigingsanalyse:

Bedreigingsanalyse: zou dan snel kunnen identificeren welke systemen waarschijnlijk zonder patches kunnen blijven werken en welke systemen moeten worden gestopt voor patching.

Bedreigingsanalyse: zou ook een kwetsbaarheid valideren. Het is belangrijk om een ​​andere vraag te stellen:als deze kwetsbaarheid kan worden misbruikt door bepaalde bedreigingen, is er dan een manier om dit te stoppen afgezien van patching ?

Beveiligingsexperts kunnen bijvoorbeeld een set vooraf bepaalde scripts maken binnen het netwerk of op het eindpuntapparaat zelf. Dat zou helpen bij het identificeren van de juiste reactie op een aantal verschillende bedreigingen. Deze scripts zouden dienen als een 'als/dan'-sjabloon om reacties op bedreigingen te formaliseren, automatiseren en versnellen. Het punt is om met meer verfijning te denken dan een binaire patch/niet patch-beslissing.

Softwarebedrijven moeten de ontwikkeling van dreigingsanalyse ondersteunen door klanten meer te vertellen over de patches die ze uitbrengen. De belangrijkste informatie die we graag willen zien, is hoe kwetsbaarheden kunnen worden uitgebuit en mogelijke manieren om zich hiertegen te beschermen.

Deze extra transparantie zou klanten meer informatie geven om beslissingen te nemen over de juiste beveiligingsmaatregelen voor getroffen systemen. Beveiligingsexperts moeten erop kunnen vertrouwen dat een patch op zijn minst hetzelfde risiconiveau handhaaft dat bestond voordat een kwetsbaarheid werd ontdekt.

Bedreigingsanalyse: moet extreem gedetailleerd zijn. Als een onderneming 100 apparaten heeft draaien, heeft elk zijn eigen dreigingsanalyse nodig, waaronder een vergelijking van kwetsbaarheden versus patchvoordelen, evenals een resulterend "menu" met beveiligingsopties.

Het primaire doel is natuurlijk om de beveiliging te verbeteren en tegelijkertijd de OT-uptime te maximaliseren.

Bedreigingsanalyse: is genuanceerder en meerdimensionaal dan go/no-go patching-beslissingen.

Maar er is een uitdaging die de industrie moet oplossen om van waar we zijn naar waar we zouden moeten zijn:op dit moment kost het volgen van het hierboven beschreven proces tijd, geld, hoogopgeleide professionals - en zelfs dan is het niet gemakkelijk om te doen.

De leveranciersgemeenschap moet beginnen te handelen volgens een overeengekomen reeks standaarden. We hebben standaard en mogelijk wetgeving nodig over de manier waarop meldingen worden afgehandeld en kwetsbaarheden worden aangepakt. Betekenis - niet bedekt. Dit hele proces kan worden geautomatiseerd.

Wat zo goed werkte in IT, past gewoon niet bij OT.

Het is tijd voor branchebrede innovatie die verder gaat dan de keuze tussen patch, patch, patch - of ongepatchte systemen kwetsbaar laten worden.

Ons doel moet zijn om krachtige, effectieve processen te bouwen en vervolgens te automatiseren om deze nieuwe aanpak te introduceren. Dit alles kan binnen het bereik van industriële bedrijven en landen over de hele wereld liggen.

Alleen omdat we deze betere toekomst duidelijk kunnen zien, betekent niet dat deze dichtbij is.

Maar laten we nu beginnen om daar samen te komen.