Drie tekenen dat uw leverancier van cyberbeveiliging het systeem mogelijk belazert
Voor degenen onder u die aanwezig waren bij de RSA-conferentie Ik weet zeker dat het bombardement van e-mails, telefoontjes en LinkedIn-vergaderverzoeken in april aan de gang is. Hoewel ik durf te wedden dat veel van de leveranciers die smeken om vergaderingen producten of diensten aanbieden die niet op je radar staan voor 2023-2024, zijn er waarschijnlijk een handvol die je op de proef zou willen stellen om te zien of ze betere resultaten kunnen opleveren dan wat u momenteel gebruikt. Voor die leveranciers krijgt u na het verplichte kennismakingsgesprek, een technisch gesprek of zelfs een klantreferentiegesprek een Proof of Concept aangeboden (ook wel Proof of Value genoemd). Deze aloude traditie stelt u in staat om "test het product zelf."
Tijdens de PoC probeert de leverancier u te laten zien hoe hun product meer aanvallen stopt, meer phishing-e-mails detecteert, meer kwaadaardige websites opmerkt en dergelijke om hun marketingclaims te valideren. De bedoeling achter het aanbieden van een PoC is volkomen logisch en zou kopers moeten helpen voorkomen dat ze producten kopen met oververkochte mogelijkheden. Maar helaas leveren producten die goed leken te presteren tijdens een PoC maar al te vaak geen vergelijkbare resultaten als ze eenmaal volledig in de omgeving van de koper zijn ingezet.
Hoe kan dit? Gedurende mijn bijna 20 jaar van bouwen, verkopen en marketing internetveiligheid producten, heb ik zowat elke manier gezien waarop leveranciers deze PoC's proberen te spelen. Hier zijn drie tekenen dat uw PoC mogelijk minder is dan boven verwachting.
“Wij leveren alle data in onze omgeving, dus jij hebt er geen omkijken naar.”
Feit is dat grondig testen internetveiligheid producten die afhankelijk zijn van een soort externe dreiging of een enorme hoeveelheid interne gegevens voor het trainen van machine learning-modellen, kunnen omslachtig zijn. Aangezien geen enkele beveiliger zou of zou moeten instemmen met het testen van een onbekend product in zijn productieomgeving, hebben ze een redelijk robuuste testomgeving nodig om dit nieuwe product op de proef te stellen. Gezien deze vereiste zal het verleidelijk zijn om het aanbod van een leverancier te accepteren om de test uit te voeren met behulp van hun gegevens in de omgeving van de leverancier. Als je er even over nadenkt, is dit alsof je studenten vraagt om de vragen voor hun eindexamen op te schrijven. Denk je niet dat testen in de omgeving van de leverancier met hun gegevens de resultaten in hun voordeel kan beïnvloeden? Natuurlijk. Hoewel niemand wil dat hun PoC's langer duren dan een NHL-hockeyseizoen, moet u gegevens verstrekken om een product goed te kunnen doorlichten. Sommige leveranciers bieden mogelijk tools aan die aanvallen simuleren, wat redelijk is, zolang u, als potentiële klant, de keuze hebt om ze al dan niet te gebruiken. De beste manier om de lengte van de PoC te beperken, is door maximaal twee of drie use-cases te selecteren waarop u zich richt, en de benodigde gegevens alleen voor die use-cases te verstrekken. Idealiter maken de producten die u test het integreren van de producten die de gegevens genereren in uw omgeving eenvoudig.
“Welke versie testen we? Het is zo'n beetje ons GA-product. Je ziet het verschil niet.”
Toen ik de cyberbeveiligingsindustrie betrad en me voorbereidde op een PoC, vroegen we potentiële klanten om een server neer te zetten die aan onze minimumvereisten voldeed. Vervolgens installeerde ik het product handmatig op de machine, zodat de PoC-deelnemers konden zien welke versie van het product we gingen gebruiken voor het testen.
In de wereld van vandaag, waar SaaS de standaard is, kan het kennen van de versie van het product dat u aan het testen bent, aanvoelen als een reis door een wormgat. Helaas heb ik horrorverhalen gehoord van beoefenaars die in een PoC zaten met een leverancier, en de resultaten waren uitstekend, dus gingen ze een contract aan om het product te kopen. Een maand of twee snel vooruit, en de beoefenaars en het management zijn meer dan gefrustreerd. Het product dat in hun omgeving is geïnstalleerd, lijkt in niets op wat ze hebben getest. Functies ontbreken, integraties die ze gebruikten zijn nergens te vinden en het verhaal van de leverancier is: "Die versie zou binnenkort uit moeten komen." In sommige gevallen zie ik geen probleem met het gebruik van een nog niet uitgebrachte productversie voor een PoC, zolang de leverancier transparant is tegenover de potentiële klant. Wanneer een klant het gevoel heeft dat een leverancier iets voor hem probeert te verbergen, kan een klant/leverancier-relatie die zou moeten samenwerken, helaas onmiddellijk strijdlustig worden.
“We hebben nog nooit een dreiging gemist tijdens een PoC.”
In 1941 werd Ted Williams, ook wel bekend als De schitterende splinter, had een magisch seizoen op de plaat en sloot zijn seizoen bij de Boston Red Sox af met maar liefst .406 slaggemiddelde en een on-base percentage van .553. Veel honkbalhistorici beweren dat Ted Williams de puurste slagman ooit was die het spel speelde. Tot op heden heeft geen enkele slagman in de AL of NL het gemiddelde van .400 voor het jaar overschaduwd. Wat heeft Ted Williams te maken met een blog over PoC's op het gebied van cyberbeveiliging? Het punt is dat niets, of het nu een cyberbeveiligingsproduct is of de beste slagman ooit om het spel te spelen, altijd perfect is. Kun je een product testen op een specifieke set dreigingsvectoren en het product identificeert ze allemaal? Absoluut. Zou het het achtereenvolgens kunnen doen met nieuwe bedreigingen gedurende twee dagen, 5, 10 of zelfs 100 dagen? Maar zo zeker als ik weet dat Ted Williams in dat seizoen van 1941 27 keer uitviel, zal er een dag komen dat je glimmende nieuwe internetveiligheid product mist een dreiging waarvan u dacht dat het die zou detecteren.
Als tijdens een PoC de onbewerkte resultaten van de producttest niet onmiddellijk beschikbaar zijn of als u merkt dat mensen van de leverancier aan het project werken die u nog nooit hebt ontmoet, wees dan gewaarschuwd. U bent getuige van een verkoopteam dat de hulp inroept van ontwikkelaars, onderzoekers van bedreigingsinformatie of software-engineers die aan uw implementatie werken, om erachter te komen waarom ze bedreigingen missen of een functie niet werkt. Nogmaals, kunnen softwaredefecten aan het licht komen tijdens een PoC? Absoluut. Als ze dat doen, kun je dan ontwikkelaars en technici vinden die code live debuggen - zeker. De sleutel hier is transparantie. Ethische leveranciers zullen openhartig met u zijn als en wanneer een defect aan het licht komt. Ze zullen ook uitleggen waarom een eventuele dreiging tijdens een PoC is gemist. Onthoud dat wanneer u een product-PoC uitvoert, u de resultaten moet vergelijken met wat u momenteel gebruikt en met andere producten die u aan het testen bent, niet met een mythisch systeem dat continu 100% van de bedreigingen detecteert. U bent op zoek naar aanzienlijk betere resultaten, niet naar perfectie.
PoC voor de mensen
Met zoveel producten op de markt die vergelijkbare mogelijkheden, voordelen en resultaten claimen, is het bijna onmogelijk om te bepalen wat voor u het beste werkt zonder een PoC uit te voeren. Daarom ben ik een fan van de PoC, omdat het, wanneer het eerlijk wordt uitgevoerd, concurrerende producten de kans geeft om het tegen elkaar op te nemen in de echte wereld.
Laat het beste product winnen.
