4 dingen waar MDR providers liever niet over praten

Vertaling script Jan Bavar – 4 dingen waar MDR providers liever niet over praten.

Een hele goede morgen. Ik ben Jan Bavar. Ik ben de groepsbeveiligingsarchitect bij Conscia Group, en we beginnen het webinar genaamd “4 Dingen Waar MDR-aanbieders Niet Graag Over Praten.”
Dus, eigenlijk, werkte ik als service-eigenaar voor MDR bij Conscia. En op basis van de ervaring met het aanbieden van MDR-diensten op de markt, wil ik enkele dingen met jullie bespreken of presenteren die we hebben gezien die het vandaag de dag moeilijk maken om MDR-diensten te vergelijken. Bepaalde dingen waar typische MDR-aanbieders misschien niet graag over praten omdat die diensten bijvoorbeeld in bepaalde gevallen suboptimaal kunnen zijn. Dit zal je in staat stellen om verschillende MDR-aanbieders te vergelijken en de MDR-dienst te kiezen die het beste bij jouw omgeving past. Dus eerst wat huishoudelijke mededelingen.

Verbind je zeker met audio om me te horen. Je zult gedempt zijn, maar er is een Q&A-sessie of chat die je kunt gebruiken om vragen te stellen. Ik zal vragen aan het einde behandelen, maar stel gerust vragen die je hebt met betrekking tot het onderwerp van MDR en MDR-diensten. We nemen dit webinar op en zullen deze opname ook achteraf delen.
Een paar dingen over mij. Ik ben een groepsbeveiligingsarchitect bij de Conscia Group. Ik ben al meer dan dertig jaar bezig met digitale beveiliging.
Ik begon met beveiliging in de vroege jaren negentig met wat ik Lego-firewalls noem. In die tijd was er geen firewallproduct, en we moesten eigenlijk zelf firewalls bouwen met behulp van bepaalde bouwstenen die leken op Lego-blokken. Vandaag de dag richt ik me echt op MDR-diensten. Waarom?
Omdat ik voel dat MDR vandaag de dag het sterkste hulpmiddel is dat we hebben om digitale criminaliteit te bestrijden. Ik denk dat we op een punt zijn aangekomen waar er zoveel grijze zone-activiteit is, die niet kan worden aangepakt door traditionele preventieve technologie, dat MDR eigenlijk de enige technologie- en servicecombinatie is die de moderne acties van digitale criminele actoren kan aanpakken. Ik werk voor Conscia Group. Conscia Group is een pan-Europese onderneming met lokale aanwezigheid in veel landen.
Ze zijn een zeer technisch georiënteerd bedrijf, en ons doel is in feite om de marktleider te zijn in cybersecurity en managed services in heel Europa. We willen technologie beveiligen en vereenvoudigen zoals die in de samenleving wordt gebruikt, maar wat we echt willen doen, is ook de omgevingen van klanten goed beschermen met een bepaalde set geavanceerde beveiligingsdiensten. Goed. Dat gezegd hebbende, laten we meteen naar de kern van de presentatie van vandaag gaan.

Dus, MDR-diensten worden gedefinieerd als in feite een nieuwe manier om beheerde remote SOC-diensten uit te voeren. Deze definitie komt van Gartner, en het idee is dat MDR-diensten detectie en respons beheren, klanten voorzien van op afstand geleverde beveiligingsoperatiecentrumdiensten, maar in een kant-en-klare ervaring, die behoorlijk verschilt van de eerdere ervaringen met het gebruik van SOC. Dus vandaag de dag vertrouwt moderne MDR typisch op de aanbieder om het juiste technologiepakket te kiezen, de juiste use cases te kiezen, en het detectiekader en het responskader te kiezen, waarmee ze zullen opereren, natuurlijk in overleg met de klant.
Maar het is niet langer de klant die typisch dicteert wat precies moet worden gedetecteerd en waarop moet worden gereageerd, omdat dit de expertise van de aanbieder is. Dus ik denk dat dit het grootste verschil is dat we hebben gezien. En er is ook een enorm verschil, zoals je zult zien, in de technologieplatforms die we gebruiken om aanvallen te detecteren en erop te reageren. Dus deze sessie gaat over het hebben van de kennis om verschillende MDR-aanbieders te vergelijken en hoe de typische zwaktes in MDR-aanbiedingen aan te pakken.
En ik zou graag vier verschillende onderwerpen willen bespreken, die ik denk dat de belangrijkste zijn op basis van wat we hebben gezien in de markt en ook bij onze klanten. Dus het eerste onderwerp waar we het vandaag over zullen hebben, is een soort van de olifant in de kamer, wat ik denk dat een van de belangrijkste problemen is waarmee MDR-producten vandaag de dag worden geconfronteerd, namelijk dreigingszichtbaarheid. Dus de vraag die je typisch zou stellen aan een MDR-aanbieder is welke criminele activiteit je zult kunnen detecteren en wanneer je dat zult kunnen detecteren? Dus dit is, denk ik, een zeer, zeer belangrijke vraag omdat het direct verband houdt met de hoeveelheid of het percentage, om zo te zeggen, van dekking die een aanbieder zal hebben over de potentiële criminele activiteit in jouw omgeving.

Ze zullen gebruik maken van wat we een kill chain noemen. Dus meestal vijf of tien stappen voordat ze bij de gouden sleutels komen of een soort impact bereiken. Het is belangrijk te begrijpen dat we slechts één stap in die reeks hoeven te detecteren om verdacht te worden of om de aanvaller te betrappen terwijl hij vordert. Dit zorgt ervoor dat de statistieken in ons voordeel werken.

Ik zeg altijd dat het heel gemakkelijk is voor de aanvaller om binnen te komen en we moeten accepteren via de ‘assume breach’ filosofie dat aanvallers binnen zullen komen. Maar het is extreem moeilijk voor de aanvaller om onopgemerkt te blijven gedurende de vijf of tien stappen naar impact, en dat brengt ons vandaag de dag heel dicht bij een detectiecapaciteit van bijna honderd procent. Het feit dat we veel dekking hebben, vroege dekking hebben, en dat we slechts één stap hoeven te detecteren om de aanvaller te detecteren.
En tot slot, als we vandaag XDR- en Centimeters-technologieën vergelijken, is het echt, denk ik, heel betekenisvol om te overwegen dat voor MITRA ingenuity, wat wordt beschouwd als de industriestandaardtest van detectietechnologieën, alle leveranciers XDR-technologie op tafel brengen, maar niemand meer Centimeters brengt.
Dus ik denk dat dit opnieuw een zeer duidelijke indicatie is dat de markt al heeft besloten dat XDR absoluut de primaire technologie is die we vandaag gebruiken om criminele activiteiten te detecteren, waarbij Centimeters als een soort zijspan kan dienen om de use cases te dekken die XDR niet kan dekken, wat meestal een zeer klein percentage van de totale dekking is. Dus in termen van dekking is het ook belangrijk te begrijpen welke gebieden van IT eerst moeten worden gedekt. Soms kunnen we ons niet veroorloven of kunnen we XDR en MDR niet overal in onze omgeving implementeren.

Vandaag de dag is het nog steeds waar dat eindpunten, zoals clients, gebruikerssystemen, mobiele apparaten en servers, het eerste slagveld zijn. Dus we moeten ze zeker eerst dekken omdat ze een kans van vijfenzeventig procent vertegenwoordigen om de aanvallers te vangen, omdat ze ongeveer vijfenzeventig procent van het MITRA ATT&CK-framework dekken. Eindpunten zijn dus cruciaal in onze strijd. Het tweede punt is uiteraard de cloud en identiteits- en samenwerkingssystemen.
Dus als je programma’s zoals Office 365 gebruikt, zijn eindpunten niet per se nodig voor iemand om je cloud aan te vallen. Identiteitsgebaseerde detecties en samenwerkingsgebaseerde detecties, vooral e-mail, zijn in feite de tweede en derde onderdelen van de heilige drie-eenheid, die ik de drie belangrijkste dingen noem die we vandaag moeten observeren. Dus eindpunten, identiteiten en samenwerkingsapplicaties. Netwerken zijn typisch een verre vierde omdat netwerken vandaag de dag, hoewel ze echt goede mechanismen bieden voor het verminderen van het aanvalsoppervlak en preventie, ons niet veel detectiemogelijkheden kunnen bieden.
Dus de meeste dingen die netwerken in het verleden konden vertellen, zijn vandaag beschikbaar via eindpuntmechanismen zoals EDR. Dus het netwerk wordt vandaag niet beschouwd als een primaire detectiebron. Het kan worden toegevoegd als een secundaire detectiebron, maar op de lange termijn zal het slechts een paar procentpunten toevoegen aan het totale plaatje vanwege de overlapping van netwerk- en eindpuntfunctionaliteit. Dit is alleen waar in IT-omgevingen.

In OT-omgevingen of in IOMT-medische omgevingen zijn de zaken heel anders omdat we natuurlijk geen agents op eindpunten kunnen installeren. Het is moeilijk om daadwerkelijk in identiteitsystemen te pluggen, enzovoort. Dus in OT- en IOMT-omgevingen is de beste praktijk nog steeds om netwerkobservatie te doen.
Dus we doen in feite passieve observatie met behulp van meestal op anomalieën gebaseerde systemen die normale profielen van verkeer correleren en opbouwen en vervolgens waarschuwen bij elke vorm van afwijkingen. Dit is momenteel nog steeds de beste aanpak. Maar je moet begrijpen dat zelfs met de beste aanpak, we ver verwijderd zijn van de capaciteit van een IT-omgeving om bedreigingen te detecteren. Dus het netwerk is waarschijnlijk de belangrijkste of bijna de enige manier waarop we OT- en IMT-omgevingen betrouwbaar kunnen monitoren, maar dat geeft ons meestal ongeveer vijfentwintig procent dekking van bestaande bedreigingen.
Dus we zijn ver verwijderd van de dekking van meer dan negentig procent die we in IT-omgevingen genieten. Een andere manier om hiernaar te kijken zou ook deze grafiek kunnen zijn, bijvoorbeeld. Dus in deze grafiek kunnen we bijvoorbeeld ook zien hoe de zichtbaarheid toeneemt op basis van de technologie die we gebruiken. Dus in de oude dagen, toen we Centimeters-systemen en logs gebruikten, hadden we meestal een zichtbaarheid tussen vijf en twintig procent van het MITRA-framework.
Dus vrij lage zichtbaarheid omdat we beperkte informatie zagen, beperkte telemetrie, wat er ook maar werd ingevoerd in het Centimeters-systeem. We konden niet echt veel contextuele informatie verwerken.

Telemetrie rond gebeurtenissen. En met de komst van EDR en verder onze XDR, in feite het concept van EDR toegepast op andere gebieden, is de zichtbaarheid gestegen naar vijfenzeventig, vijfentachtig procent, negentig procent dekking van het MITRA-framework. Dus vandaag de dag, met een eenvoudige implementatie van XDR-technologie op een paar belangrijke gebieden, kunnen we heel snel naar meer dan negentig procent MITRA-dekking springen, wat echt uitstekend is vergeleken met de oude Centimeters-gebaseerde ontwerpen.
En natuurlijk is het enige probleem hier dat alle detectietechnologie sterk afhankelijk is van mensen. Dus, uiteraard, hebben we een MDR-provider nodig bovenop of doen we dit intern om er daadwerkelijk enige zin of waarde uit te halen. En het is echt belangrijk dat je altijd MDR-providers vergelijkt en bespreekt met MDR-providers over de zichtbaarheid die ze in jouw omgeving zullen bieden. Dus afhankelijk van de technologie die ze zullen gebruiken en de gebieden die ze zullen observeren.
Dus, nogmaals, voor mij is de beste praktijk vandaag de dag het gebruik van XDR. Eerst de heilige drie-eenheid van eindpunten, identiteiten en samenwerking monitoren. En dan, indien nodig, aan het einde een paar procentpunten toevoegen met aanvullende technologieën, die Centimeters kunnen zijn. Maar, nogmaals, dit moet op een zeer kosteneffectieve manier worden gedaan.
Dus, verdergaand, wat zijn de typische probleemgebieden waarop MDR-providers zich vandaag de dag richten? Dus als je wilt samenwerken met een MDR-provider, wat is waarschijnlijk een soort lastige vraag voor de MDR-provider of iets lastigs voor jou om daadwerkelijk te implementeren? Dus, typisch, het eerste probleemgebied dat we zien, zijn aangepaste applicaties of SaaS-applicaties anders dan klassieke Office 365. MDR-providers zijn erg goed in het detecteren van criminele activiteiten in traditionele sorry, in algemene infrastructuren, platforms, dus dingen zoals eindpunten, cloud, enzovoort, die gemeenschappelijk zijn voor een hele klantenbasis.
Als je aangepaste applicaties hebt of als je zeer aangepaste cloudapplicaties hebt, is het typisch onwaarschijnlijk dat dit goed wordt afgehandeld door de MDR-provider. Ten eerste omdat aangepaste applicaties niet veel telemetrie bieden. Ten tweede omdat de MDR-provider zou moeten leren wat normaal is in jouw aangepaste applicaties. Dus dit is iets dat typisch erg duur zal worden als de MDR-provider bereid is om dat te doen.

De meeste MDR-providers zijn niet bereid om dit te doen om redenen die hun schaalbaarheid beïnvloeden. Dus dit is iets dat vandaag de dag niet echt hoog op de prioriteitenlijst staat. En als je eerlijk bent, denk ik dat het belangrijker is om je echt te concentreren op de drie gebieden die ik eerder heb genoemd voordat je aangepaste applicaties gaat monitoren. Als je webapplicaties hebt die naar het internet gericht zijn, is mijn advies altijd om eerder te investeren in preventie, in applicatieverharding, in veilig programmeren dan in het daadwerkelijk inschrijven van die applicatie zelf in een soort MDR- of SOC-scenario.
Er is ook een goed advies, denk ik, dat als je aangepaste applicaties of aangepaste SaaS-applicaties hebt, soms de authenticatielaag zelf een sterke detectielaag kan creëren. Bijvoorbeeld, als je single sign-on geïmplementeerd hebt over
Je SaaS gebruiken met enter ID, het observeren van enter ID zal een heleboel aanvallen tegen je SaaS-applicatie opvangen, zelfs als het een aangepaste applicatie is. Dus overweeg soms om authenticatie te gebruiken als de sterke detectielaag, die in feite fungeert als een soort initiële toegangdetector rond je aangepaste applicaties. En in dit geval kan elk MDR-product dat monitoren, en ze hoeven de specificaties van je aangepaste applicaties niet te kennen.
Ten tweede kunnen leveranciers soms bepaalde aspecten van de cloud niet monitoren, namelijk platform as a service. We weten over infrastructure as a service, wat typisch infrastructuur is die door de cloud wordt geleverd. We weten over SaaS, wat typisch dingen zijn zoals Office 365. En traditioneel hebben we echt goede MDR- en XDR-technologieaanbiedingen rond die gebieden, rond die scopes.
Vandaag de dag gebruiken veel klanten ook PaaS. Dus platform as a service. Zoals database as a service, objectopslag, app-services, enzovoort in Azure, GCP, AWS, enzovoort. En dit is traditioneel niet goed afgehandeld door veel XDR-tools, dus we hadden niet echt goede zichtbaarheid.
Vandaag de dag veranderen de zaken ten goede. Dus vandaag denk ik dat we op het punt zijn dat we voor elk groot cloudplatform kunnen beweren dat we een vrij sterke zichtbaarheid hebben. Maar ik raad altijd aan om de lokale versie van XDR van dat specifieke cloudplatform te gebruiken. Dus als je bijvoorbeeld Azure gebruikt, is de beste manier om Azure te monitoren Defender for Cloud.

Als je AWS gebruikt, is de beste manier om dat te monitoren AWS GuardDuty. Als je GCP gebruikt, is de beste manier om dat te monitoren SCC. Dit zorgt er in feite voor dat de beveiligingstechnologie die de cloud monitort, in sync is met de cloudfuncties, en je zult waarschijnlijk geen compatibiliteitsproblemen tegenkomen met externe monitoring-apps die niet alle functies van de cloud ondersteunen. En zoals we weten, is PaaS ontwikkelaarsgedreven.
Ontwikkelaars willen meestal niet beperkt worden in hun keuze van functies. Dus ik denk dat de beste praktijk vandaag de dag is om te gaan met het native mechanisme dat door de cloud wordt geleverd, en de MDR-provider zou in staat moeten zijn om de native cloudmechanismen te monitoren die detectiemogelijkheden bieden in een XDR-manier met behulp van bijvoorbeeld die drie diensten die ik noemde. Het derde ding dat echt belangrijk is, is dat als je MDR implementeert met een serviceprovider, je ervoor moet zorgen dat je echt consistente zichtbaarheid hebt. We hebben in het verleden nogal wat gevallen gezien waarin we dachten dat we goede zichtbaarheid hadden, maar de klanten verzuimen ons te vertellen over bepaalde delen van hun omgeving waar ze geen agents hebben geïnstalleerd, ze hebben niet de juiste API’s verbonden, enzovoort.
Dus dit is echt, echt belangrijk, en meestal gebeuren incidenten daar. Aanvallers hebben het ongewone vermogen om die blinde vlekken in je omgevingen te vinden. Dit kunnen acquisities zijn. Dit kunnen gebieden zijn waarvan je denkt dat ze niet riskant zijn, maar dat wel zijn, enzovoort.
Dus we noemen ze DFIR-doelen. Typische doelen voor grote incident response-activiteiten. Mijn aanbeveling hier is dat, als je met de MDR-provider praat, kijk of ze ook een soort red of purple teaming-service aanbieden, waarmee je je blinde vlekken kunt ontdekken. Misschien weet je er niet eens van, en de provider kan offensieve beveiliging gebruiken om je omgeving verder te ontdekken en te zien waar de blinde vlekken zijn, waar technologie moet worden ingezet.
En het laatste probleemgebied voor MDR is vroege verkenning. Ik heb klanten gezien die in feite zeggen: kun je ons op de hoogte stellen van elke enkele scan van onze website? Ons antwoord is meestal nee, omdat je dan vijfduizend alarmen per dag zult ontvangen. Ik denk dat we moeten opgeven om vroege verkenningsdetectie te doen, omdat er simpelweg te veel van is en er zeer beperkte use cases zijn waarin verkenningsdetectie echt nuttig is.

Dus meestal laten we die initiële zichtbaarheid vallen om ons te kunnen concentreren op latere stappen van de aanvaller met veel hogere kwaliteit. Dus verkenning, denk ik, is geen goed idee, tenzij het natuurlijk interne verkenning is. In die gevallen moeten interne scans, interne verkenning natuurlijk worden gewaarschuwd en moeten ze natuurlijk worden opgenomen in het detectiekader. Dus dat zijn de blinde vlekken of typische probleemgebieden die je misschien met de MDR-provider zult bespreken om te zien hoe ze het daadwerkelijk aanpakken.
Maar soms denk ik dat je ook een beetje moet toegeven, bijvoorbeeld om bepaalde dingen niet te doen. Vooral, nogmaals, raad ik je af om aangepaste applicaties te prioriteren, en ik raad je af om enige vorm van externe verkenning te prioriteren. Oké. Dus de belangrijkste conclusie over dit gedeelte, wat ik denk dat het belangrijkste is, is het gedeelte over zichtbaarheid en waarmee je MDR-providers kunt vergelijken, omdat de zichtbaarheid die de MDR-provider daadwerkelijk in je omgeving heeft, de kwaliteit van de service zal bepalen, ervan uitgaande dat het team natuurlijk goed is.
In feite kunnen we vandaag de dag min of meer alles observeren. En XDR-technologie stelt providers in staat om dit te doen zonder veel interne ontwikkeling. Dit is, denk ik, een grote verandering ten opzichte van de Centimeters-gebaseerde gesprekken van gisteren, toen de provider in feite veel use cases zelf moest creëren. Het tweede punt is dat je altijd eerst XDR moet gebruiken.

Dus XDR-technologie is vandaag de dag absoluut de marktleidende technologie in termen van hoe we dingen detecteren. Het komt met duizenden use cases. Het richt zich in feite op de dingen die criminelen waarschijnlijk zullen gebruiken, en het heeft die vroege focus. Dus het betekent dat het zich echt richt op het initiële toegangsdeel van de aanvalsketen.
Netwerken, hoewel ze erg goed zijn voor preventie, brengen niet veel waarde voor detectie in de IT-wereld omdat de meeste detectie op het eindpunt kan worden gedaan, wat eerder op het netwerk werd gedaan. Maar netwerken kunnen erg nuttig zijn in niet-IT-omgevingen, maar
Onthoud dat niet-IT-omgevingen nog steeds niet de algehele zichtbaarheid hebben die we in IT-omgevingen hebben. We zijn nog steeds veel zwakker in OT-omgevingen vergeleken met wat we kunnen doen in IT-omgevingen, waar we vandaag de dag min of meer alles kunnen doen. Zorg ervoor dat de zichtbaarheid consistent is.
Zorg ervoor dat we geen blinde vlekken hebben. We zijn die nieuwe acquisitie niet vergeten in termen van observatie. Ja. En onthoud dat CMs typisch een technologie is die langzaam overgaat naar logbeheer.

De meeste detectiemogelijkheden die Centimeters bood, zijn vandaag de dag beschikbaar in XDR. Er zijn waarschijnlijk nog een paar use cases die een Centimeters vereisen, maar Centimeters is, denk ik, te duur als detectiemotor vandaag de dag en overweeg in feite meer naar logbeheer te migreren voor een meer kosteneffectieve oplossing. Oké. Dus dat was een beetje het eerste gebied waarin je de MDR-provider zou moeten ondervragen en in feite de MDR-provider zou moeten uitdagen om te zien wat voor soort zichtbaarheid ze je zullen bieden met behulp van de technologie stack die ze ondersteunen.
Het tweede punt is uiterst belangrijk omdat het een verschuiving in klantattitudes signaleert naar een meer reactieve of responsieve benadering van de MDR-providers. Dus in het verleden vroeg je de providers meestal: wat zullen jullie kunnen detecteren? Dus dat is het zichtbaarheidsgedeelte. Maar vandaag de dag denk ik dat de primaire vraag zal zijn: wat zullen jullie kunnen verstoren?

Dus deze verstoringscapaciteit van de leverancier wordt steeds belangrijker, en niet alle MDR-leveranciers bieden dezelfde soort verstoringsmogelijkheden. Dus je zou moeten vragen wat er verstoord kan worden en wanneer, hoe snel. Dus verstoringscapaciteit is in feite het idee dat de leverancier zich kan richten op de ‘r’ in MDR, dus managed detection and response, om zo snel mogelijk te reageren om de keten van gebeurtenissen die tot impact leiden te doorbreken. Deze reactie is meestal in de vorm van containment.
Dus in feite kan de leverancier een snelle actie ondernemen die de aanval verstoort om deze in te dammen en niet verder te laten gaan naar impact. En dit is vandaag de dag het idee van veel klanten die in feite zeggen: beter veilig dan sorry. Probeer zoveel mogelijk te verstoren voordat je zelfs met ons praat. Dus ze zullen de MDR-provider meestal vooraf autoriseren, en de MDR-provider zou in staat moeten zijn om die diensten betrouwbaar te leveren.
Natuurlijk is het idee om de reactietijd te verkorten. Waarom is deze verkorting van de reactietijd belangrijk? Omdat aanvallers steeds meer dingen automatiseren. Typisch, de verstoringen die MDR-providers zouden moeten doen, zijn uiteraard eindpuntisolatie, wat natuurlijk al jaren bij ons is.
Dus het idee dat als er een compromis is van een bepaald systeem, de provider dat systeem onmiddellijk moet isoleren of in quarantaine moet plaatsen om verdere verspreiding te voorkomen. Dan met de komst van steeds meer cloudaanvallen, zien we een verschuiving van criminelen naar clouddiensten.

We doen in feite veel identiteitsgebaseerde verstoringen. Dus gebruikers afmelden, gebruikers uitschakelen, dat zijn dingen die identiteitsgebaseerd zijn en in het portfolio van elke provider moeten zitten. Maar ze moeten ook extreem, extreem snel worden gedaan, zoals we zullen zien. En het laatste, je zou ook netwerkblokkering kunnen eisen, zowel op de firewall als op het eindpunt. Eindpunten zijn misschien zelfs een betere manier om netwerktoegang tot specifieke sites te blokkeren. Een voorbeeld hiervan zou zijn als je een nieuwe phishing-site hebt gezien die bijvoorbeeld enkele van je gebruikers heeft gefisht, dan zou je de rest van je eindpuntpopulatie kunnen instrueren om niet meer met die site te communiceren.
Dus een vorm van dynamische URL-filtering. En als je dit op het eindpunt doet, is het natuurlijk beter omdat het niet afhankelijk is van de topologie, omdat de regels met het eindpunt meereizen, en al je mobiele gebruikers zullen van dezelfde soort bescherming genieten. Maar in termen van reactietijd is het echt belangrijk. Dus deze grafiek, denk ik, laat heel goed zien dat hoe meer we de reactie vertragen, hoe groter de kosten van onze incidentrespons worden.
Weet je? Dus tegenwoordig moeten we soms zelfs in seconden of minuten reageren, niet in uren of dagen. Toch? Omdat hoe meer we vertragen, hoe groter het vuur zal worden en hoe moeilijker het zal zijn om het te blussen.Dus, uiteraard, is het idee van MDR-providers dat ze zich richten op de minuten tot uren of zelfs seconden reactietijd, en dat is een beetje de waardepropositie van MDR. Dus MDR zegt in feite dat we alle incidenten heel klein zullen maken, en dat is het gemakkelijkst te bereiken door een zeer snelle vooraf geautoriseerde reactie. Dus dit is echt, echt belangrijk. En dat garandeert dat al je incidenten klein blijven, dat ze gemakkelijk te repareren zijn, dat je geen grote vaardigheden in je IT nodig hebt om ze aan te pakken.
Maar ook, nogmaals, zullen de kosten van het incident verwaarloosbaar blijven. Ja. Dus dit is bijvoorbeeld wat het resultaat hiervan is in je IT-omgeving. Toch?
Dus als we een bepaalde aanvaller kunnen blokkeren nadat hij of zij al in onze omgeving is gekomen in vijf of tien minuten, dan hoeft de klant misschien alleen maar het eindpunt schoon te maken, het eindpunt opnieuw te installeren, de inloggegevens opnieuw in te stellen, en zo iemand. Dus eenvoudige IT-acties die geen significante IR-vaardigheden vereisen. Dat is een beetje de belofte van MDR vandaag. Dus de belofte van MDR is dat je nooit een groot incident response-proces of -activiteit nodig zult hebben.
Je zou er nog steeds een moeten hebben voor noodgevallen, maar MDR zou al je incidenten extreem, extreem klein moeten houden. Dat gezegd hebbende, zelfs een reactie in dertig minuten is soms niet genoeg. Zelfs een reactie in tien minuten is soms niet genoeg. Aanvallers hebben geautomatiseerde manieren gevonden om vandaag de dag impact te bereiken, wat vereist dat we nog sneller moeten zijn.
Dus bij traditionele phishing, bijvoorbeeld, wanneer een gebruiker werd gefisht en het wachtwoord of MFA van die gebruiker werd vastgelegd, duurde het voor de aanvallers meestal een paar uur om daadwerkelijk gebruik te maken van de vastgelegde inloggegevens om bepaalde zakelijke e-mailcompromissen of interne spear phishing-aanvallen uit te voeren. Dus tegenwoordig wordt phishing meestal gebruikt om Office 365-inboxen aan te vallen. Iemand phisht je gebruikers met een phishingmail die eruitziet als een uitnodiging om iets op SharePoint te bewerken. De MFA-inloggegevens worden vastgelegd in een AITM-aanval, dus een aanvaller-in-de-midden-aanval.
En de aanvaller zal die inloggegevens vervolgens gebruiken om in te loggen op de inbox van de gebruiker, de doorstuurregels te wijzigen om hun aanwezigheid te verbergen en interne spear phishing of onderschepping van e-mails te starten. Het punt is dat aanvallers dit hebben geautomatiseerd. Dus de hele activiteit na de diefstal van inloggegevens kan één of twee minuten duren, enzovoort. Dus het is meestal buiten onze menselijke manier of menselijke capaciteit om te onderzoeken.
Bijvoorbeeld, bij Conscia MDR is onze mediane tijd om te onderzoeken vier en een halve minuut, wat echt, echt goed is, maar het is niet genoeg om geautomatiseerde aanvallen aan te pakken. Dus als de aanvaller in staat is om de gecompromitteerde inloggegevens binnen een minuut of zo te gebruiken, hebben we een snellere manier nodig. Om die reden hebben we bijvoorbeeld onze eigen automatiseringen ontwikkeld, die in feite sneller handelen dan mensen zouden doen. Dus wanneer we bijvoorbeeld een verdachte login zien, die alle indicaties heeft van een AITM-aanval, loggen we de gebruiker onmiddellijk uit.

We hebben aangepaste automatiseringen in plaats, die het SOC dichter bij realtime preventie brengen. Dus we detecteren, analyseren en reageren niet langer, maar we hebben bepaalde use cases die een volledig automatische reactie vereisen. En voor deze gevallen, die meestal AITM zijn, omdat ze zwaar geautomatiseerd zijn, moeten we een volledig automatisch systeem in plaats hebben, dat ook een beetje zacht is. Want als je de gebruiker uitlogt, log je meestal de aanvaller uit.
In de misschien één procent van de false positives, zal de gebruiker gewoon opnieuw moeten inloggen. Dus zelfs als er af en toe een false positive is, is dat geen probleem. Dus dat is een goed voorbeeld van hoe een SOC hun eigen automatiseringen kan ontwikkelen, wanneer bijvoorbeeld zelfs XDR niet snel genoeg kan handelen of waar mensen die XDR-waarschuwingen interpreteren niet snel genoeg kunnen handelen. Dus de belangrijkste punten hier zijn in feite dat MDR-providers zich vandaag de dag moeten richten op de ‘r’.
Dus als de provider zich richt op de ‘d’ en de ‘r’ aan jou overlaat, ben je misschien te laat met je reactie. Dus de aanbeveling is zeker om de MDR-provider zoveel mogelijk vooraf te autoriseren voor reactie. Zorg altijd voor uitzonderingen, want er zijn natuurlijk bepaalde dingen die niet onmiddellijk moeten worden beantwoord, zoals servers, bedrijfskritische systemen, enzovoort. Probeer een zeer gebruiksvriendelijk uitzonderingsbeheersysteem te hebben met een provider en een levenscyclusbeheersysteem.
Dus je doet dit niet maandelijks, maar je kunt die beleidsregels daadwerkelijk on-the-fly wijzigen, wat kan worden beantwoord. En onthoud dat menselijke reactie op
Vandaag de dag is soms te traag. Bijvoorbeeld, voor AITM moeten we beter presteren in termen van automatische respons, waardoor de MDR-provider heel dicht bij realtime respons komt. Dus de klassieke preventieve technologie, maar met de intelligentie die de MDR-provider kan bieden.
En als je dit niet doet, een kleine grap, toch, voor alles is er altijd incident response. Dus, nogmaals, als je te laat bent met je reacties, moet je de brandweer inschakelen en zullen de kosten zeer, zeer hoog oplopen. Je gebruikt in dat geval in feite niet de essentie van MDR. Goed.
Dus dat is het tweede punt dat echt belangrijk is: het hebben van het response-element, zeer sterk aanwezig in je MDR-service en vooral weer met de juiste snelheid. We hebben nog twee onderwerpen te gaan die iets lichter zijn. Het eerste heet vertrouwen op magie. Dus ten eerste moeten leveranciers niet blindelings vertrouwen op XDR-technologie.
Hoewel XDR-technologie geweldig is, is het niet almachtig. Het zal bijvoorbeeld hiaten hebben. Er kan een black swan-evenement zijn wanneer zelfs XDR-technologie het niet kan detecteren. Dus wat doe je als XDR faalt en wanneer doe je het?
Toch? Dus er zijn twee soorten black swan-evenementen. Ten eerste, het eerste black swan-evenement dat we hebben gezien in de vorige dia’s wanneer XDR niet snel genoeg is of wanneer mensen die XDR interpreteren niet snel genoeg zijn. AITM is een klassiek voorbeeld van een geavanceerde phishing-aanval die dat kan doen.
En om die reden doen we black swan-automatiseringen. We creëren in feite aangepaste automatiseringen, die de mens uit de lus halen en alleen jou en de klant achteraf informeren dat we automatisch actie hebben ondernomen. Het tweede punt is black swan false negatives zoals Log4j. Log4j is een oud verhaal, denk ik, nog steeds aanwezig in sommige omgevingen, maar het is zo populair geweest, toch, in onze gedachten dat ik denk dat het belangrijk is om het naar voren te brengen omdat toen Log4j uitkwam, geen enkele XDR-leverancier een bevredigende regel had om dat te detecteren.
Dus het was een blinde vlek. Het was een false negative voor iedereen. Niemand kon Log4j detecteren omdat het een ongebruikelijke manier was om software iets te laten doen. En wat gebeurde er op dat moment?
Dus, in feite, wat we als MDR-providers moesten doen, was in feite een noodgeval-use case creëren. Dus een detectie-use case om dat aan te pakken. Bijvoorbeeld, we hebben een beleid dat we dit binnen vierentwintig uur moeten creëren. Moeten we wachten op de leveranciers?
Mijn antwoord is nee. Typisch, leveranciers nemen minstens een week om detectieregels te creëren voor volledig nieuwe manieren van systeemhacking of nieuwe technieken. Dus minstens een week. Waarom?
Omdat ze de regels zo moeten ontwerpen dat ze geen miljoenen of miljarden false positives veroorzaken. Aangezien leveranciers veel klanten hebben, zullen ze altijd regels moeten creëren die zinvol zijn voor alle omgevingen. Je MDR-provider daarentegen heeft te maken met een
veel minder klanten en je MDR-provider heeft een veel betere kans om deze regel binnen vierentwintig uur uit te brengen en dit zou een kwaliteitsregel moeten zijn. Wanneer we het hebben over use cases, wanneer we het hebben over noodregels, heb ik het niet over IOCs, je weet wel, hash- of IP-adresgebaseerde regels.
Die regels zijn heel eenvoudig te omzeilen, niet betrouwbaar. We hebben het over gedrags- of anomaliegebaseerde regels. Regels die variaties van die aanvallen zullen opvangen. En daarom zijn die regels moeilijk te schrijven zonder veel false positives.
Dus leveranciers waarop je vertrouwt, technologieleveranciers, zullen wat tijd nodig hebben, maar de MDR-leverancier is veel beter gepositioneerd om een sterke gedragsregel in een beperkte tijd te creëren omdat ze zullen zien hoe de regel reageert op jouw omgeving, en ze kunnen deze veel gemakkelijker afstemmen dan de leverancier. Dus de leveranciers, dus je MDR-leverancier, zou in staat moeten zijn om op noodsituaties te reageren. Ze zouden een track record moeten hebben dat laat zien hoe ze hebben gereageerd op eerdere noodsituaties toen XDR een detectiekloof had. Dus dat is het eerste punt.
Dus het creëren van nood-use cases is het eerste dat je van de leverancier zou moeten eisen, dat kan een ongemakkelijk gesprek voor hen zijn. En het tweede punt voor de leverancier is dat we moeten begrijpen dat wanneer er een nieuw probleem opduikt, wanneer we iets leren zoals Log4j, dat probleem niet vanaf vandaag bestaat, maar al maanden of jaren in onze omgevingen aanwezig is. Toch? Wanneer we nieuwe kwetsbaarheden ontdekken, zijn die niet nieuw.
Toch? Ze zijn al jaren of maanden aanwezig in de code. Dus het is belangrijk voor de leverancier dat ze niet alleen vooruitkijken en de detectieregel voor toekomstige gebeurtenissen creëren, maar ook retroactief jagen voor jou. Dus je vraagt ze altijd, doen jullie ook retroactieve jacht?
Omdat dit garandeert dat ze in het verleden kunnen kijken om te zien of deze nieuwe kwetsbaarheid daadwerkelijk is uitgebuit in jouw omgeving terwijl het niet werd gedetecteerd. Een zeer belangrijk punt. Dus zowel de toekomst als het verleden moeten door de leveranciers worden aangepakt, wat zelden wordt gedaan door veel MDR-leveranciers. Dus vraag ze hier zeker naar.
Het tweede vertrouwen is niet op technologie, maar op dreigingsinformatie. Dus dreigingsinformatie is in feite de educatie die we vandaag de dag ontvangen over wat er in de wereld gebeurt met betrekking tot aanvallen, technieken, enzovoort. Marcus Ranum, die de vader van firewalls is, een echt gerenommeerde oude school expert, zei in de jaren negentig al: laten we geen slechtheid opsommen.

Het is veel beter om de goede dingen op te sommen en op alles anders te waarschuwen. Dus hij pleitte duidelijk voor het white listing-model van beveiliging, wat tegenwoordig zero trust wordt genoemd. Maar zelfs in de jaren negentig zei hij dat het opsommen van slechtheid een slecht idee is. Dus, je weet wel, antivirus, IPS-handtekeningen, enzovoort.
Soms is het onze enige kans. Toch? Maar over het algemeen zouden we sterkere methoden voor detectie en preventie moeten gebruiken. Dus dreigingsinformatie, als het wordt gegenereerd om in machines te worden ingevoerd, als het machine-consumeerbare dreigingsinformatie is, wat in feite IOCs zijn.
Dus slechte IP-adressen, slechte hashes, enzovoort, moeten we ons echt bewust zijn dat die dingen beperkt bruikbaar zijn. Ze pakken mutaties van aanvallen niet aan. Ze zijn misschien maar een paar uur geldig, enzovoort. Dus we moeten ons scherp bewust zijn van de beperkingen van IOCs, en IOCs zouden niet onze primaire manier van detectie moeten zijn.
IOCs zouden een soort laatste redmiddel moeten zijn om iets te detecteren of een aanvulling op andere dingen die veel sterker zijn. Dus een MDR-provider die sterk vertrouwt op IOCs en dreigingsinformatie, is meestal niet in staat om veel dingen te detecteren, vooral geen variaties, vooral geen dingen die op de lange termijn geldig zijn. Dus dit is echt belangrijk. Dus IOCs zijn opnieuw zeer beperkt in hun bruikbaarheid voor detectie.
Ze kunnen bijvoorbeeld worden gebruikt voor incident response. Ze kunnen worden gebruikt voor aanvalstoewijzing, enzovoort. Maar voor puur detectiedoeleinden zouden ze als een secundair middel voor detectie moeten worden beschouwd. De tweede vorm van dreigingsinformatie, die niet door machines kan worden geconsumeerd, maar door mensen kan worden geconsumeerd, is denk ik belangrijker.
Dus als MDR-partners leren we over nieuwe technieken, over nieuwe dingen in het wild, en dat stelt ons in staat om nieuwe use cases te creëren. Dus dat is goed. Toch? Vraag je MDR-provider hoe ze mens-consumeerbare dreigingsinformatie gebruiken.
Gebruiken ze het daadwerkelijk om nieuwe use cases te creëren? Gebruiken ze het om hun analisten op te leiden, enzovoort? Dus dat is de goede kant, de echt lichte kant van dreigingsinformatie, in feite leren over dingen en niet te veel vertrouwen op het machine-consumeerbare deel. Oké.
Dus dat is echt belangrijk. Bijvoorbeeld, bij Conscia MDR gebruiken we dit om onze eigen nood-use cases te creëren indien nodig, als XDR dat niet dekt, maar we gebruiken dit ook om klanten te informeren over wat er met hen gaat gebeuren of waar ze strategisch over moeten nadenken op basis van kennis van wat criminele groepen doen. En ten slotte, vertrouwen op AI. Toch?
Dus, er is geen SOC of MDR-provider die niet beweert dat AI echt een integraal onderdeel is van hun operaties. Ik geloof ze meestal niet. Waarom is AI belangrijk voor ons als MDR-providers? Omdat het een hint geeft naar wat we over een paar jaar willen doen, namelijk het automatisch afsluiten van cases op basis van AI-triage.
We zijn er nog niet. Nu vandaag is AI echt succesvol als generatieve AI. Dus het genereert dingen. En als het dingen genereert, is het vandaag de dag veel nuttiger voor aanvallers.
Het genereert phishingmails. Het genereert phishingwebsites. Het genereert malware, enzovoort. Maar als MDR-providers kunnen we AI vandaag de dag niet volledig benutten voor wat we het meest willen, namelijk betrouwbare triage van cases.
Toch? Snelle en betrouwbare triage. We kunnen het nog niet doen. Dus, typisch, gebruiken aanvallers het, en wij gebruiken automatisering om het te bestrijden.
Dus met automatisering kunnen we de extra schaalbaarheid vinden die aanvallers zullen hebben op basis van AI. Maar ik denk dat het gebruik van AI in het SOC meestal echt, echt overdreven is. We kunnen het misschien gebruiken als, je weet wel, copilots, assistenten, samenvatters, enzovoort om onze onderzoekstijden iets te verbeteren, maar het is nog lang niet in staat om het menselijke element van de MDR-service volledig over te nemen. Dus daag je providers uit over de details, hoe ze AI gebruiken, en waarschijnlijk zul je ontdekken dat ze zullen zeggen, nou, we gebruiken machine learning.
En machine learning bestaat al tien of vijftien jaar, en alle XDR-producten gebruiken machine learning al sinds altijd. Toch? Dus machine learning is een geweldig hulpmiddel voor ons om anomaliegebaseerde detectie te doen, maar wat we willen doen is eigenlijk triage daarna. Toch?
En dit is iets waar AI nog niet is. Oké. Dus hoe vertrouwen we op magie? Dus we zouden niet op magie moeten vertrouwen omdat we altijd XDR-platforms moeten nemen.
Hoe goed ze ook zijn, ze zijn ook feilbaar, ze kunnen hiaten hebben, en MDR-partners zouden in staat moeten zijn om die hiaten aan te pakken wanneer die hiaten zich voordoen. Ze gebeuren meestal, zoals, een of twee keer per jaar dat we een nieuwe klasse van aanvallen hebben die niet onmiddellijk door XDR kan worden aangepakt. Maar toch is XDR verreweg het meest effectieve detectieplatform. Het tweede punt is altijd begrijpen dat de machine-consumeerbare dreigingsinformatie.
Dus IOCs zouden niet een primaire detectiemechanisme moeten zijn, tenzij je geen andere keuze hebt. En ten slotte, machine-consumeerbare TI is echt goed als je besluitvorming op basis daarvan wilt doen of use cases wilt ontwikkelen, maar dat is in feite de taak van de MDR-provider. Ja. En begrijp dat AI, opnieuw, meestal machine learning betekent bij de meeste MDR-providers, wat niets te fancy is.
En ons laatste onderwerp zal werkdrukbeheer zijn. Dus dit is een typische angst van klanten. Weet je? Ik word onboarded naar een MDR-service.
Wat zal de werkdruk zijn die van ons, de klanten, wordt gevraagd wanneer we met de MDR-service werken? Dus wanneer wat zal de provider doen wanneer ze met ons moeten praten? Hoe vaak? Wanneer zal dit gebeuren?

Dus dit is een typische angst van de klant. En de vraag zal in feite zijn, hoeveel tijd moet ik besteden aan het werken met een externe MDR-service? En ik zal je een typisch consultantsantwoord geven. Het hangt ervan af.
Het punt is dat we in feite moeten zien wat de factoren zijn die in feite laten zien wat in feite de voor- en nadelen zijn in termen van hoge of lage werkdruk voor de klant. En het spectrum van opties is vrij breed. Dus in het beste geval wil je idealiter dat de MDR-provider je helemaal niet lastigvalt. In feite ontvangt de MDR-provider de waarschuwingen, de telemetrie, en ze doen alle onderzoeken volledig onafhankelijk, autonoom zonder jouw hulp.
Aan de andere kant van het spectrum doet de MDR-provider niet veel triage. Ze sturen simpelweg de waarschuwingen naar jou door en vragen je om ze uit te leggen, in feite dat jij hun werk uitvoert. Dus hoewel dit een beetje het spectrum van dingen is, ligt de waarheid ergens in het midden, en meestal ligt de waarheid ergens aan de linkerkant, hopelijk, als het een goede MDR-provider is. Dus elke MDR-provider zal gevallen tegenkomen waarin ze het onderzoek niet volledig kunnen afronden zonder enige bedrijfskennis van jouw kant, maar dat zou beperkt moeten zijn.
Dus, in feite, zouden ze een zeer laag aantal vragen moeten hebben, een laag aantal interacties met jou, wanneer ze eigenlijk iets niet weten. Ja? En vooral met XDR-technologie die ten grondslag ligt aan de belangrijkste MDR-diensten van vandaag, is dit meestal veel gemakkelijker te doen omdat XDR-technologie providers in staat stelt om veel autonomer te zijn omdat ze veel meer telemetrie beschikbaar hebben voor root cause-analyse. Dus de keuze van technologie zal zwaar beïnvloeden waar je je bevindt in het spectrum.
Dus gebruikers met XDR-technologie zullen veel meer aan de linkerkant zijn. Gebruikers met Centimeters-technologie zullen veel meer aan de rechterkant zijn, wat een beetje een extra nagel aan de doodskist is voor Centimeters-technologie. Nu de factoren die het beste scenario beïnvloeden. Dus, typisch, zul je zeer weinig interactie zien met je MDR-service operationeel op dagelijkse basis als je platforms vrij generiek zijn, wat betekent dat je geen te exotische dingen gebruikt.
Je gebruikt geen dingen die sterk afhankelijk zijn van bedrijfsspecifieke zaken, en dat is meestal de meeste IT-platforms. Dus de meeste IT-platforms die gebaseerd zijn op, je weet wel, Windows, Linux, macOS, klassieke cloud, SaaS Office, Azure, GCP, AWS. Dat wordt vandaag de dag als generiek beschouwd. Dus in die omgevingen hebben de providers de kennis en de telemetrie waar ze de meeste onderzoeken autonoom kunnen afronden.
Het tweede punt is, ja, ze moeten de juiste tools hebben. Als ze XDR hebben, zijn ze meestal veel gemakkelijker in staat om de root cause in het root cause-analyseproces te vinden. Als je ordelijk bent, helpt dat ook. Toch?
Dus als je ordelijk bent, wat betekent dat je gebruikers meestal niet alle vrijheden in de wereld hebben om software uit te voeren, software te downloaden, enzovoort. Dus hoe ordelijker je bent, hoe minder interactie je zult hebben met de MDR-provider. En ten slotte, als er een interactie is, zou de provider tools moeten hebben die deze interactie heel eenvoudig maken. Dus bijvoorbeeld, wat we doen met Conscia Talk is dat we een portal hebben.
Als we een vraag voor je hebben, stellen we je simpelweg een ja of nee vraag op het portaal over een specifiek scenario dat we hebben gezien. En we komen nu ook met een mobiele app, waarmee je die vragen kunt beantwoorden alsof je een telefoontje beantwoordt. Dus we beweren in feite dat bij onze typische klanten de totale tijd die je maandelijks met ons doorbrengt voor al je menselijke middelen ongeveer twee uur is. Dus heel, heel licht.
Aan de andere kant, in het slechtste geval, onderzoeken we een extreem bedrijfsspecifiek platform zoals een OT-omgeving of een aangepaste applicatie, je weet wel, dingen die niet gestandaardiseerd zijn. En om die reden zouden de analisten in de MDR en bij de MDR-provider in feite moeten weten hoe alles werkt, enzovoort. En dit is niet echt schaalbaar voor MDR-providers. Dus in veel van die gevallen zullen MDR-providers simpelweg de waarschuwingen naar jou doorsturen en zeggen dat dit gevaarlijk lijkt.
Wat denk je? Dus dit is echt belangrijk. Het tweede punt is dat als de MDR-provider sterk vertrouwt op Centimeters, CMs meestal veel minder gegevens hebben voor root cause-analyse. En meestal lopen providers sneller tegen het obstakel aan en sturen ze de vraag naar jou door met de vraag wat jij ervan denkt.
Toch? En dan doe jij het onderzoek in plaats van de MDR-provider. Als je omgeving chaotisch is, vooral voor uitvoering, of als je erg dynamisch bent in termen van reizen, zullen er veel vragen zijn over gebruikers die naar Nigeria of Vietnam reizen, enzovoort. Is het een zakenreis of is het vakantie?
Omdat veel van de cloudaanvallen zullen plaatsvinden op basis van ongebruikelijke logins, en dat moet in feite behoorlijk overlappen met reizen. En ten slotte, als de provider met jou samenwerkt, controleer altijd de tools die ze gebruiken. Als ze e-mail gebruiken om je vragen te stellen, is dat waarschijnlijk geen goed idee omdat dit gevoelige gegevens zijn, en e-mail is zeker niet het meest veilige platform om gevoelige gegevens op te bespreken. Dus belangrijke punten.
Zorg ervoor dat wanneer je voor een MDR-service gaat, je in feite een lage werkdruk hebt met de MDR-provider die echt goede tools, echt goede technologie heeft, en over het algemeen dingen onderzoekt die meestal standaard zijn. Je moet ook accepteren dat MDR-providers niet in staat zullen zijn om veel te leren over de specificaties van je OT-omgeving, niet in staat zullen zijn om te leren hoe je aangepaste applicatie werkt omdat het niet schaalbaar voor hen is. Als ze bereid zijn om dit te accepteren, zal het heel, heel duur zijn. Dus soms zeggen we zelfs tegen klanten, als je extreem domeinspecifieke dingen hebt, is het misschien het beste om dit zelf intern te doen en de rest door de MDR-provider te laten afhandelen omdat jij je bedrijf het beste kent.
En als je bedrijfsspecifieke detecties hebt, zijn ze meestal laat in de aanvalsketen, dus ze zijn niet zo tijdsdruk als de klassieke initiële toegang incidenten. Dus het heeft soms zin om het detectiekader te splitsen en in feite te zeggen dat alle criminele dingen die bijna tot impact leiden, door een externe MDR-provider worden geleid terwijl sommige bedrijfs
Specifieke zaken, zoals fraudeopsporing, enzovoort, zullen nog steeds intern worden afgehandeld omdat ze niet zo tijdkritisch zijn als de initiële toegang en escalatie-incidenten. En het goede nieuws is ook dat als je voelt dat je niet ordelijk bent, MDR je ordelijk kan maken omdat een goede MDR-provider, op basis van wat ze hebben gezien, aanbevelingen aan je zal doen en je in feite zal adviseren over hoe je ordelijker kunt worden op basis van hard bewijs.
Ik denk dat dit ook iets is dat MDR-providers zouden moeten bieden, en je zou dit moeten eisen als onderdeel van je MDR-service, zodat je in feite voortdurend aanbevelingen krijgt om je volwassenheid te verhogen. Dus dat brengt ons tot het einde. De vier gebieden waarin we vinden dat MDR-partners moeten worden uitgedaagd zijn: dreigingszichtbaarheid, het vermogen om snel en betrouwbaar te reageren, niet vertrouwen op magie, en zorgen voor een lage en consistente werkdruk van jouw kant. Nu zal ik kijken naar de vragen die je mogelijk hebt, en we kunnen dingen bespreken als de tijd het toelaat.
Oké. Laat me de vragen controleren. Plaats je vragen gewoon in de chat of Q&A, en ik zal ze onmiddellijk beantwoorden. Oké.
Ik wacht gewoon een paar seconden omdat we niet veel vragen hebben. Dit betekent eigenlijk dat ik waarschijnlijk over de meeste dingen heb gesproken. Ja. Bedankt, Sasha, voor de bemoedigende opmerkingen.
En zoals ik al zei, ik werk al meer dan dertig jaar in dit veld, en ik werk in MDR omdat ik voel dat dit de plek is waar we vandaag de dag het meeste verschil kunnen maken. Dus aangezien er geen specifieke vragen zijn, wil ik je heel erg bedanken voor het bijwonen van het webinar. Als je verdere vragen hebt, neem dan contact op met mij of je lokale vertegenwoordiger als je meer wilt weten over onze eigen MDR-diensten. Heel erg bedankt.