Mark Fetches, CTO van Spinnaker Support – Interviewreeks

Mark Fetches is Chief Technology Officer voor EMEA bij Spinnaker Support, waar hij enterprise-organisaties adviseert over technologie-strategie, beveiliging, cloud, AI en grootschalige transformatie-initiatieven. Met meer dan 30 jaar ervaring in consultancy en leiderschap bij Accenture, Deloitte en PwC, heeft Mark nauw samengewerkt met C-suite-executives en raden van bestuur om complexe enterprise-omgevingen te moderniseren en technologiebeslissingen af te stemmen op langetermijndoelstellingen van het bedrijf. Gevestigd in het VK, specialiseert hij zich in het helpen van organisaties bij het navigeren van legacy-technologie-uitdagingen, operationeel risico en digitale transformatie met praktische, bedrijfsgerichte richtlijnen.

Spinnaker Support is een toonaangevende wereldwijde aanbieder van derdepartij-ondersteuning voor software, beheerde services en beveiligingsadvies voor ondernemingen die Oracle (ORCL ), SAP, JD Edwards en andere kritieke platforms gebruiken.

U heeft meer dan 20 jaar ervaring in het adviseren van ondernemingen bij Accenture, Deloitte en PwC voordat u CTO werd bij Spinnaker Support. Kijkend terug op die reis, wat zijn de grootste misvattingen die executives consistent hebben gehad over technologie-risico’s, en hoe heeft de opkomst van AI die gesprekken veranderd?

Ik denk dat de grootste misvatting altijd is geweest dat technologie-risico’s ergens aan de zijlijn van het bedrijf zitten en beheerd kunnen worden als een specialistische kwestie. Ik heb dat nooit echt zo gezien.

De meeste ernstige risico’s die ik heb gezien, komen voort uit leiderschapskeuzes. Hoeveel complexiteit u tolereert. Hoe afhankelijk u wordt van oude platforms of sleutelleveranciers. Hoe hard u dringt op snelheid. Of u de data waarop het bedrijf draait, echt vertrouwt. Technologie is waar die keuzes zichtbaar worden, maar het is meestal niet waar ze beginnen.

Ik heb in de loop der jaren veel executives zien focussen op de voor de hand liggende dingen, zoals cyberbeveiliging, compliance en kostenreductie. Dat zijn echte problemen, natuurlijk. Maar de risico’s die bedrijven meestal te pakken nemen, zijn vaak stiller dan dat. Het is het platform dat iedereen weet dat het broos is, maar waarvan de vervanging constant wordt uitgesteld. Het is het dataprobleem waar niemand echt verantwoordelijk voor is. Het is de uitbestede afhankelijkheid die efficiënt lijkt totdat het een bottleneck wordt. Dat zijn de dingen die op de achtergrond kunnen zitten voor jaren en dan plotseling zeer zichtbaar worden als er iets misgaat.

Ik denk ook dat er een langdurige gewoonte is om compliance te verwarren met veerkracht. Ze zijn niet hetzelfde. U kunt een audit doorstaan en nog steeds veel kwetsbaarder zijn dan u denkt. Een controlelijst vertelt u niet hoe het bedrijf zal reageren onder druk, hoe snel het kan herstellen of of leiders het probleem echt duidelijk genoeg zien om te handelen.

Wat AI heeft veranderd, is het niveau van aandacht. Deze gesprekken zaten eerder dieper in de organisatie. Nu zitten ze midden in de discussies in de bestuurskamer over groei, vertrouwen, productiviteit en merk. Dat is een zeer goede zaak. Maar het heeft ook een nieuwe vereenvoudiging geïntroduceerd, namelijk het idee dat het AI-model dat wordt gebruikt het risico is. Meestal is het groter dan dat. De moeilijkere vragen gaan over de data en het bestuur eromheen, de beslissingen die het beïnvloedt en het punt waarop menselijke oordeel nog steeds moet tellen.

Als ik het zou moeten samenvatten, zou ik zeggen dat technologie-risico nooit echt over de technologie alleen is gegaan. Het is altijd een weerspiegeling van leiderschapsoordeel geweest. AI heeft het alleen maar moeilijker gemaakt om dat te negeren.

Beveiligingsteams hebben nu toegang tot meer kwetsbaarheidsinformatie dan ooit tevoren, maar ondernemingen blijven worstelen met prioritering. Waarom denkt u dat de industrie een signaal-ruisprobleem heeft in plaats van een detectieprobleem?

Ik zou het heel eenvoudig stellen: de industrie heeft geen gebrek aan kwetsbaarheidsgegevens. Het heeft een gebrek aan duidelijkheid.

De meeste beveiligingsteams hebben al meer dan genoeg invoer, scanneruitvoer, dreigingsinformatie, ernstscores, patchadviezen, exploitrapportage. Het probleem is niet of ze zwakheden kunnen vinden. Het is of ze de paar kunnen scheiden die het bedrijf echt kunnen schaden van de veelheid die technisch interessant maar minder consequentieel zijn.

Daarom zie ik het als een signaal-ruisprobleem. Detectie is enorm verbeterd. Wat niet in hetzelfde tempo is verbeterd, is de mogelijkheid om context toe te passen. Een kwetsbaarheid wordt pas een echte prioriteit als u weet waar het zit, hoe blootgesteld het is, hoe kritisch dat activum is, wat compenserende controles er zijn en wat de bedrijfsimpact zou zijn als het zou worden uitgebuit.

In de praktijk vallen veel ondernemingen nog terug op de metrics die het makkelijkst te produceren zijn, zoals ernstscores, patchtellingen en verouderingsrapporten. Die zijn nuttig, maar ze zijn niet hetzelfde als menselijke oordeel. Een hoog scorend probleem in een lage-waarde intern systeem kan minder belangrijk zijn dan een lager gewaardeerde zwakte die op iets klantgericht of operationeel kritiek zit.

Ik denk niet dat dit fundamenteel een zichtbaarheidsprobleem is. Het is een bedrijfsprioriteringsprobleem dat door de beveiligingsteams moet worden geleerd. We zijn erg goed geworden in het genereren van bevindingen. We zijn nog minder consistent in het vertalen van die bevindingen in een korte lijst van acties die leiderschap met vertrouwen kan ondersteunen.

En vanuit mijn perspectief is dat de echte verschuiving die de industrie nog moet maken, een verschuiving weg van meten hoeveel we kunnen detecteren naar beslissen wat echt belangrijk is in termen van bedrijfsimpact.

Op bestuursniveau is dit echt een kwestie van risicoverplaatsing, kan de onderneming technische blootstelling omzetten in een klein aantal duidelijke, uitvoerbare bedrijfsprioriteiten? Degene die dat goed kunnen doen, zijn degene die van ruis naar signaal gaan.

Veel cybersecurity-leveranciers beweren dat AI automatisch kwetsbaarheden kan prioriteren en bedreigingen kan voorspellen. Waar ligt de kloof tussen de marketingnarratief en wat AI realistisch kan leveren in enterprise-omgevingen vandaag?

Ik denk dat de makkelijkste manier om het te zeggen is dat de marketing eroverheen tends naar een niveau van zekerheid dat echte enterprise-omgevingen eenvoudigweg niet toelaten.

Leveranciers beschrijven AI alsof het boven de ruis kan uitstijgen, alles kan opnemen en betrouwbaar kan vertellen wat het meest belangrijk is en wat waarschijnlijk zal gebeuren. Het is een overtuigend verhaal omdat elk beveiligingsleider minder rommel en meer vertrouwen wil. Maar zodra je binnen een grote onderneming komt, zijn dingen zelden zo schoon als dat eenvoudige verhaal.

AI kan absoluut helpen. Het kan patronen samenbrengen, sommige van het handmatige sorteren reduceren, afwijkende patronen benadrukken en teams helpen om door volumes van informatie te werken die anders moeilijk te beheren zouden zijn, en dat heeft echte waarde. Maar er is een verschil tussen een team helpen om sneller te werken en weten, met enige dependable precisie, wat het meest belangrijk is in die specifieke omgeving.

Daar ligt de kloof. De meeste ondernemingen zijn vol van ongelijkmatige context. Activum-inventarissen zijn onvolledig. Eigendom is niet altijd duidelijk. Bedrijfskritiek verschuift. Controles variëren van de ene naar de andere delen van het bezit. Gegevenskwaliteit is gemengd. Als de onderliggende afbeelding patchy is, dan zal de output van de AI ook patchy zijn, hoe gepolijst de interface er ook uitziet.

Ik denk dat dit vooral waar is als leveranciers het hebben over voorspelling. Er is een significante verschil tussen zeggen: “dit patroon ziet er riskant uit” en zeggen: “dit is wat er volgende zal gebeuren.” Het eerste kan nuttig zijn. Het tweede is waar de taal vaak voorbij de realiteit gaat.

Als ik het zo zou moeten zeggen, AI is het best begrepen als een versterker, niet als een autoriteit. Het kan teams helpen om te sorteren, correleren en focussen. Wat het niet consistent kan doen, is de behoefte aan menselijke oordeel, lokale kennis en een duidelijke begrip van wat het bedrijf echt om geeft.

Daar ligt de verdeeldheid. De narratief suggereert zekerheid. De realiteit is bescheidener en nuttiger dan de hype als je eerlijk bent over het.

AI kan de kwaliteit en snelheid van de analyse verbeteren, maar het kan de noodzaak van menselijke oordeel niet verwijderen. De noodzaak om de rommeligheid van enterprise-beveiligingsbeslissingen te begrijpen.

Spinnaker Support werkt uitgebreid met Oracle, SAP en JD Edwards-implementaties. Wat maakt zeer aangepaste ERP-omgevingen bijzonder moeilijk voor AI-gedreven beveiligingshulpmiddelen om te begrijpen en nauwkeurig te beoordelen?

Wat deze omgevingen moeilijk maakt, is dat ze, na genoeg jaren, ophouden met gedragen als standaardsoftware waarop de AI is getraind en beginnen met gedragen als een record van hoe het bedrijf echt werkt.

Ik heb dit vooral gezien in zwaar aangepaste Oracle-, SAP- en JD Edwards-bezittingen. Op papier kunt u nog steeds naar een bekend platform kijken. In werkelijkheid kijkt u vaak naar jaren van lokale aanpassingen, aangepaste code, geërfde integraties, toestemmingstructuren, rapportage-logica en workarounds die zijn gebouwd voor zeer specifieke operationele redenen. Voor een AI-gedreven beveiligingshulpmiddel kan dit moeilijk te lezen zijn met enige werkelijke zekerheid.

Veel van deze hulpmiddelen werken het beste wanneer de omgeving relatief consistent is en de patronen gemakkelijker zijn om te vergelijken. Zwaar aangepaste ERP-omgevingen zijn zelden zo. De logica is meer verward. De documentatie is vaak onvolledig. Eigendom kan over teams worden verdeeld. Wat ongebruikelijk lijkt, kan perfect intentioneel zijn en wat routineus lijkt, kan blijken te ondersteunen iets echt kritiek in financiën, supply chain of operaties.

Dit is waar de moeilijkheid ligt. Het hulpmiddel wordt niet alleen gevraagd om een kwetsbaarheid of een misconfiguratie te vinden. Het wordt gevraagd om te begrijpen wat dat probleem betekent in de context van een bedrijfsproces, een aangepaste afhankelijkheid of een controlestructuur die mogelijk nergens anders bestaat.

En dat is een veel moeilijker probleem dan de marketing meestal impliceert. AI kan helpen om patronen naar boven te brengen, sommige van het handmatige analyse te reduceren en teams te helpen om door volumes van informatie te werken die anders moeilijk te beheren zouden zijn, en dat heeft echte waarde. Maar als het bezit slechts gedeeltelijk is gedocumenteerd, gevormd door jaren van uitzonderingen en diep verbonden met de manier waarop het bedrijf werkt, is er een limiet aan hoe nauwkeurig een geautomatiseerd systeem het op zichzelf kan interpreteren.

Daarom denk ik dat het echte probleem niet is of AI iets kan zien. Het is of het genoeg van de omliggende context kan begrijpen om het goed te beoordelen. In zwaar aangepaste ERP-omgevingen is dat nog steeds waar menselijke expertise het verschil maakt.

Een van uw belangrijkste argumenten is dat menselijke expertise geen bottleneck is om te elimineren, maar een essentieel onderdeel van het beveiligingsproces. Kunt u voorbeelden delen waar menselijke oordeel risico’s identificeerde die een AI-gedreven prioriteringsmotor waarschijnlijk zou hebben gemist?

Ja, absoluut. En voor mij is dit waar de beperkingen van geautomatiseerde prioritering heel duidelijk worden.

Sommige risico’s hebben alleen zin als u de omgeving goed genoeg kent om te begrijpen wat erachter zit. Een systeem kan van buitenaf niet erg belangrijk lijken. De kwetsbaarheidsscore kan onopvallend zijn. Maar iemand die het bezit kent, weet dat het loonadministratie ondersteunt, kwartaal-eindrapportage, een fragiele integratie of een bedrijfsproces waar het bedrijf gewoon niet zonder kan. Het signaal in de gegevens kan gewoon lijken. De werkelijke gevolgen zijn dat niet.

Ik heb ook gevallen gezien waar het controlebeeld er in theorie beter uitziet dan in de praktijk. Een AI-motor zou kunnen aannemen dat een risico is verlaagd omdat segmentatie aanwezig is, of omdat toegang is beperkt of omdat een controle bestaat. Maar iemand dicht bij de omgeving weet dat één controle ongelijkmatig wordt toegepast, een andere wordt omzeild wanneer operaties onder druk staan en een derde stilzwijgend is gestopt met betrouwbaar te zijn. Die soort gap komt niet altijd schoon in het systeem van record.

Hetzelfde gebeurt in aangepaste omgevingen. Een script, een workflow of een toestemmingmodel kan routineus lijken als u patronen scant op grote schaal. Voor iemand die weet hoe dat systeem in de loop der jaren is aangepast, kan hetzelfde detail meteen opvallen als een echte bron van blootstelling.

Timing is ook belangrijk. Een kwetsbaarheid kan beheersbaar lijken in isolatie, dan veel ernstiger worden omdat het bedrijf midden in een migratie, een overname, een regelgevingsdeadline of een piekoperatieperiode zit. Die soort verschuiving is niet altijd gemakkelijk voor een geautomatiseerde motor om te interpreteren met de juiste gewicht.

Als ik het over menselijke expertise heb, heb ik het niet over instinct in enige vage zin. Ik bedoel lokale kennis. Geheugen. Oordeel. Het vermogen om te zien wanneer een klein technisch probleem is verbonden met iets veel consequentieelers.

Daarom zie ik menselijke expertise niet als een bottleneck om te verwijderen. Ik zie het als het deel dat valse vertrouwen voorkomt. AI kan helpen om gegevens te sorteren en te verkleinen. Maar de risico’s die het meest tellen, zijn vaak degene die alleen duidelijk worden als iemand begrijpt hoe het bedrijf echt werkt.

Terwijl ondernemingen haasten om AI overal in de beveiligingsoperaties te adopteren, wat zijn de grootste risico’s van het over-automatiseren van kwetsbaarheidsbeheer en blootstellingsevaluatie?

Het grootste risico dat ik zie, is dat u de schijn van controle creëert zonder de realiteit van werkelijk te begrijpen dat u onder controle bent.

Kwetsbaarheidsbeheer is een van die gebieden waar automatisering evident waardevol is. Op enterprise-schaal hebt u automatisering nodig om problemen te vinden, gegevens te correleren, prioriteit te geven in volume en het hele proces gaande te houden. Geen enkel serieus bedrijf kan dat handmatig beheren.

Maar het gevaar komt wanneer automatisering het programma begint te drijven zonder voldoende menselijke uitdaging eromheen.

Het eerste voor de hand liggende risico is valse prioritering. Als u te zwaar leunt op geautomatiseerde scoring, kunt u technische ernst gaan behandelen alsof het hetzelfde is als bedrijfsrisico. Het is het niet. Een kritieke kwetsbaarheid op een geïsoleerd of compenserend gecontroleerd activum kan in de praktijk minder belangrijk zijn dan een lager gewaardeerde kwestie die op een hoog blootgesteld systeem zit dat is verbonden met een kritiek bedrijfsproces.

Het tweede risico dat ik zie, is verlies van context. Geautomatiseerde programma’s zijn alleen zo goed als de activumgegevens, eigendomsgegevens, afhankelijkheidskaarten en uitzonderingsbehandeling erachter. Als die informatie onvolledig is, en in de meeste ondernemingen is een deel ervan meestal onvolledig, dan kan de automatisering zeer efficiënt worden in het doorvoeren van gebrekkige beslissingen door het systeem.

Het derde risico is gedragsmatig. Zodra mensen beginnen de workflow te vertrouwen, stoppen ze met het ondervragen van de uitvoer. Teams gaan ervan uit dat wat naar boven komt het meest belangrijk is en wat niet naar boven komt kan wachten. Dat is begrijpelijk, maar ik denk gevaarlijk. Omdat het de cultuur verschuift van geïnformeerd risicobeheer naar passieve aanvaarding van machine-gedreven ordening.

En dan is er een bredere strategisch risico, namelijk dat ondernemingen beginnen met het verwarren van doorvoer met beveiligingsverbetering. Het sluiten van een grote hoeveelheid kwetsbaarheden ziet er operationeel goed uit. Het creëert dashboards, metrics en een gevoel van momentum. Maar als u de blootstellingen die het meest voor het bedrijf tellen niet vermindert, bent u misschien alleen maar sneller aan het kijken naar drukte.

Daarom denk ik dat automatisering absoluut het zware werk moet doen. Maar het moet oordeel ondersteunen, niet vervangen. Anders hebt u een proces dat efficiënt, meetbaar en schaalbaar is, maar niet noodzakelijkerwijs veiliger.

U heeft uitgebreid gewerkt in IT-transformatie en enterprise-architectuur. Hoe moeten CISO’s het noodzaak om kwetsbaarheden snel te patchen in balans brengen met de operationele risico’s van het onderbreken van kritieke bedrijfssystemen?

Geweldige vraag, want dit is een van die gebieden waar het makkelijke antwoord meestal het verkeerde is.

Natuurlijk wilt u snel patchen. Geen CISO zal argumenteren voor het langer dan nodig zitten op bekende kwetsbaarheden. Maar in een echte onderneming, vooral een die kritieke systemen draait, is snelheid op zichzelf niet het doel. Als u patcht en iets neerhaalt waar het bedrijf van afhankelijk is, hebt u één probleem opgelost door een ander te creëren.

De balans ligt echt in het begrijpen welke risico’s live zijn, welke theoretisch zijn en welke systemen verandering kunnen tolereren zonder ergens anders problemen te veroorzaken.

Sommige kwetsbaarheden vereisen echt dringende actie. Als iets blootgesteld, uitbuitbaar en in een deel van het bezit zit dat ertoe doet, dan beweegt u. Maar de meeste keren is de beslissing minder absoluut dan mensen het laten klinken. U kunt andere controles rond het probleem hebben. Het getroffen systeem kan strak worden geïsoleerd. Het operationele risico van het maken van de verandering vandaag kan hoger zijn dan het een korte periode vasthouden en het op de juiste manier doen.

Daarom zijn de betere CISO’s degenen die een volwassen gesprek met het bedrijf kunnen voeren. Niet alleen: “Dit is kritiek, patch het nu”, maar: “Dit is de blootstelling, dit is wat er kan gebeuren, dit is wat er mis kan gaan als we het verkeerd aanpakken en dit is de veiligste manier erdoorheen.” Dat is een geloofwaardiger vorm van leiderschap dan elke kwetsbaarheid behandelen alsof het in isolatie bestaat.

Ik denk ook dat deze momenten iets diepers over het bezit zelf blootleggen. Als een onderneming constant bang is om core-systemen te patchen omdat elke verandering gevaarlijk lijkt, vertelt u meestal dat de omgeving broos is geworden. Te veel verborgen afhankelijkheden, niet genoeg testvertrouwen, te weinig veerkracht in de architectuur. In die situatie is het patchen-debat eigenlijk een symptoom van een veel ouder probleem.

Ja, patch snel waar het risico echt is en het pad duidelijk is. Maar waar de omgeving gevoelig is, is de taak om risico te verminderen zonder een grotere rommel te creëren. Dat is de balans.

En om eerlijk te zijn, de meeste ervaren CISO’s weten dit al. De uitdaging is om hun beslissing onder druk toe te passen, wanneer de klok tikt en niemand de gevolgen van het verkeerd krijgen wil bezitten.

Spinnaker’s aanpak combineert AI-gedreven analyse met expertvalidatie. Welke specifieke taken moeten AI afhandelen, en welke beslissingen moeten stevig in de handen van ervaren beveiligingsprofessionals blijven?

Ik denk dat de scheidslijn eigenlijk vrij eenvoudig is.

AI moet het werk doen dat profiteert van snelheid, schaal en consistentie. Door grote hoeveelheden gegevens gaan, signalen samenbrengen, patronen vinden, afwijkende patronen benadrukken, teams helpen om het veld te verkleinen, dit is precies het soort werk waar machines nuttig voor zijn. Het bespaart tijd, het vermindert handmatige inspanning en het geeft beveiligingsteams een beter startpunt.

Het is ook goed geschikt voor de repetitieve delen van de taak. De eerste laag van triage. Samenvatting van bevindingen. Verbinding van soortgelijke kwesties. Herhaalde uitzonderingen volgen. Aandacht vestigen op waar bepaalde soorten controlezwakte blijven verschijnen. Niets van dat vervangt expertise, maar het maakt beter gebruik van het.

Waar ik veel voorzichtiger zou zijn, is wanneer u van analyse naar besluitvorming gaat.

De belangrijke oproepen moeten nog steeds bij ervaren beveiligingsprofessionals liggen. Is dit echt een serieus risico in dit bedrijf of ziet het er alleen serieus uit in het abstracte? Is dit een echte controlefout of is het een rommelige maar begrepen uitzondering? Als we dit nu fixen, wat anders kunnen we verstoren? Als we wachten, wat accepteren we echt? Dat zijn oordeelsoproepen.

En dat is voordat u zelfs maar naar de meer menselijke kant gaat. Waarom gebeurt dit? Is de onderneming willens en wetens dit risico dragend of heeft ze het gewoon opgehouden met het opmerken? Is dit een geïsoleerd probleem of een teken van iets cultureels eronder? Dat soort interpretatie telt nog steeds veel.

Daarom zou ik AI laten doen: sorteren, clusteren, de eerste pas, het zware werk. Maar ik zou het niet laten beslissen wat het bedrijf het meest moet zorgen over of welke actie moet worden ondernomen zonder menselijke herziening.

Omdat zodra een beslissing gevolgen heeft, of operationeel, financieel of reputatiegebonden, u niet langer alleen informatie verwerkt. U neemt een oordeel.

En in beveiliging, denk ik, zou dat nog steeds een persoon met echte intelligentie moeten zijn.

Veel ondernemingen focussen nog steeds zwaar op kwetsbaarheidstellingen en ernstscores. Waarom denkt u dat echte blootstellingbeheer een bredere kijk vereist die compenserende controles, toegangsbeperkingen, systeemarchitectuur en bedrijfscontext omvat?

Het vereist een bredere kijk omdat een nummer op zichzelf niet veel vertelt over hoeveel problemen u echt in bent.

Ernstscores hebben hun plaats. Kwetsbaarheidstellingen hebben hun plaats. Ze helpen u om het probleem te meten. Ze helpen u om de backlog te organiseren. Maar ze zijn niet hetzelfde als het begrijpen van blootstelling, en dat is waar ik denk dat veel ondernemingen nog steeds dit verkeerd doen.

Een kwetsbaarheid kan ernstig lijken in theorie en nog steeds relatief goed worden geïsoleerd in de praktijk. Als toegang tot het systeem strak wordt beperkt, als er andere compenserende controles eromheen zitten, als het in een deel van de omgeving zit dat moeilijk te bereiken is door toegangsbeperkingen, dan kan de werkelijke waarschijnlijkheid dat het probleem schade veroorzaakt heel anders zijn dan wat de brute score suggereert.

En dan krijgt u het tegenovergestelde geval, dat vaak het meest interessante is. Iets lager op de lijst kan blijken veel meer te tellen omdat het zit waar het zit. Het raakt een kritieke dienst. Het is gemakkelijker te bereiken. Het zit in een deel van de systeemarchitectuur waar één compromis ruimte geeft om te bewegen. Dat is het soort ding dat een eenvoudige ernstscore niet goed kan verklaren.

Daarom denk ik dat als mensen over blootstellingbeheer praten, het voor mij moet betekenen meer dan alleen kwetsbaarheden sorteren op score en werken naar beneden.

U moet weten wat eromheen zit. Wat de controles zijn die er al zijn. Wie toegang heeft. Of het systeem geïsoleerd is of verbonden met iets belangrijkers. En als het wordt uitgebuit, wat er echt gebeurt. Anders beheert u het beeld van risico in plaats van het risico zelf.

De dashboard verbetert. De ticketnummers bewegen. De rapportage ziet er beter uit. Maar u bent niet noodzakelijkerwijs veiliger.

Ik denk dat een deel van de reden hiervoor is dat nummers troostend zijn. Ze zien er objectief uit. Ze geven mensen iets om schoon te presenteren. Ze creëren het gevoel dat het probleem is teruggebracht tot iets meetbaar en onder controle. Maar echte blootstelling is meestal veel rommeliger dan dat.

Het zit in de overlap tussen de zwakte, de controles eromheen, de architectuur waarin het leeft, en de bedrijfsconsequenties als er iets misgaat.

Ja, gebruik de scores. Gebruik de tellingen. Natuurlijk. Maar verwar ze niet met begrijpen.

Als u wilt weten waar de echte blootstelling is, denk ik dat u naar de hele omgeving moet kijken, niet alleen naar een nummer dat eraan is vastgemaakt.

Enterprise-software-omgevingen gaan een periode van significante verandering binnen als ondernemingen legacy-systemen moderniseren en tegelijkertijd AI-technologieën adopteren. Kijkend naar de toekomst over de komende drie tot vijf jaar, hoe ziet u de relatie tussen AI, cybersecurity en enterprise-platforms evolueren, en waar moeten technologie-leiders zich vandaag op voorbereiden?

Ik denk dat de komende drie tot vijf jaar vrij definiërend zullen zijn.

Voornamelijk omdat bedrijven proberen om oude enterprise-bezittingen te moderniseren en tegelijkertijd AI in de mix te brengen, en geen van beide dingen is gemakkelijk op zichzelf. Beide tegelijk doen, verhoogt de inzet.

Wat verandert het eerst, denk ik, is dat AI ophoudt met een zijexperiment te zijn en begint deel te worden van de manier waarop het bedrijf echt werkt. Het verschijnt in workflows, ondersteuning, ontwikkeling, beveiligingsoperaties en platformbeheer, niet als een noviteit, maar als onderdeel van de leiding.

En zodra dat gebeurt, wordt het cybersecurity-gesprek serieuzer. U vraagt niet alleen of het hulpmiddel nuttig is. U vraagt wat het kan bereiken, wat het kan beïnvloeden, welke gegevens het voedt en wat de consequenties zijn als het iets verkeerd doet.

Ik denk ook dat we zullen zien dat beveiliging en architectuur moeilijker te scheiden zullen worden. In veel oudere omgevingen is het ding dat eruitziet als een beveiligingsprobleem, vaak eigenlijk een architectuurprobleem dat een beveiligingsbadge draagt. Zwakke identiteitsontwerp, te veel afhankelijkheden, onduidelijk eigendom, broze integraties, slechte zichtbaarheid, dat zijn de dingen die meestal onder het zichtbare probleem zitten. AI zal dat niet gladstrijken. Als het al iets doet, zal het de rommel sneller blootleggen.

Daarom denk ik dat de ondernemingen die dit goed doen, degenen zullen zijn die ophouden met het behandelen van AI-adoptie, cybersecurity en platformmodernisering als drie afzonderlijke werkstromen. Ze zijn steeds meer hetzelfde gesprek.

Als ik technologie-leiders nu zou adviseren, zou ik beginnen met zichtbaarheid. U moet een veel duidelijker greep hebben op wat u heeft, hoe het verbindt, wie toegang heeft tot wat, waar gevoelige gegevens bewegen en waar uw echte controlepunten zijn. Zonder dat, het toevoegen van AI aan de top verhoogt alleen maar het aantal dingen die u niet volledig begrijpt.

Het volgende is governance, maar niet de performante soort. Echte beslissingen. Waar kan AI worden gebruikt? Waar moet menselijke herziening in stand blijven? Hoe worden uitvoer gecontroleerd? Welke gegevens zijn ontoegankelijk? Wie bezit de consequenties als het systeem de verkeerde actie aandrijft? Die vragen moeten nu worden beantwoord, niet later.

En eerlijk gezegd, vereenvoudiging telt meer dan veel mensen willen toegeven. Hoe meer verward het bezit is, hoe moeilijker het is om te beveiligen, hoe moeilijker het is om te moderniseren en hoe moeilijker het is om AI te gebruiken zonder nieuwe onzekerheid te creëren.

En dan is er de mensenkant. De betere ondernemingen zullen degenen zijn die weten hoe ze automatisering kunnen combineren met oordeel. Ze zullen niet alleen AI-uitvoer consumeren omdat het snel of gepolijst is. Ze zullen het uitdagen. Testen. Terugduwen wanneer nodig.

Daarom denk ik dat AI, cyber en enterprise-platforms de komende jaren veel nauwer met elkaar verweven zullen raken.

En ik denk dat de leiders die zich goed voorbereiden, degenen zullen zijn die begrijpen dat dit niet alleen een technologische verschuiving is. Het is een verandering in hoe beslissingen worden genomen, hoe controle wordt uitgeoefend en hoe veerkrachtig de organisatie echt is.