Voorkom verkeerd verzonden e-mails en vang op wat Preventie van gegevensverlies (DLP) mist

Voorkom verkeerd verzonden e-mails en vang op wat Preventie van gegevensverlies (DLP) mist

De meeste beveiligingsteams voeren een programma voor preventie van gegevensverlies uit, en de meeste van die programma’s werken zoals bedoeld. Toch bereikt gevoelige data nog steeds de verkeerde personen via e-mail, omdat patroonregels beoordelen wat een bericht bevat en niet wie het ontvangt. Preventie van verkeerd geadresseerde e-mail sluit dat gat.

Stel je een klantenlijst voor die met veertig namen zichtbaar in het Aan-veld wordt verzonden, een contract dat naar een persoonlijk Gmail-account wordt gekopieerd in de week voordat iemand ontslag neemt, of een domein dat met één teken verkeerd is getypt. De verzender is geautoriseerd, het bestand mag vertrekken en er wordt geen enkele regel geactiveerd. De data is in orde. De ontvanger is verkeerd.

Dit artikel legt uit waar patroon-gebaseerde DLP stopt, hoe Kiteworks Agent en Human Error Prevention (AHEP) de ontvanger controleert terwijl een bericht nog wordt geschreven, en hoe je het kunt testen aan de hand van je eigen incidentgeschiedenis voordat je een beslissing neemt.

Samenvatting voor het management

Patroon-gebaseerde DLP en ontvangercontrole beantwoorden verschillende vragen. DLP vraagt of een bericht data bevat die het niet zou mogen bevatten. AHEP, een functionaliteit van de Kiteworks Data Policy Engine, vraagt of deze ontvanger logisch is voor dit bericht, en doet dit terwijl de verzender het probleem nog kan oplossen. Voor beveiligingsleiders is de waarde een controle voor een risicocategorie die bestaande tools niet zien, geleverd op het platform dat al gevoelige data in beweging beheert. Alleen-rapportagemodus laat je de blootstelling meten voordat een enkele verzender een waarschuwing ziet.

Belangrijkste punten

  1. DLP controleert de data, niet de ontvanger. Geautoriseerde data die naar de verkeerde persoon wordt gestuurd, passeert elke patroonregel, dus fouten met ontvangers hebben hun eigen controle nodig. Het bijstellen van DLP-regels sluit dat gat niet.
  2. Verkeerd geadresseerde e-mail is een veelvoorkomend, goed gedocumenteerd incidenttype. Uit analyse van incidentrapporten door Osterman Research, ingediend bij een gegevensbeschermingsautoriteit, bleek dat dit type incident op de eerste plaats stond met 21 procent, en 96 procent van meer dan 300 ondervraagde leiders door Abnormal rapporteerde verlies hierdoor.
  3. Elke AHEP-policy wordt alleen geactiveerd onder specifieke voorwaarden. Ontvangerstype, externe hoeveelheid, identiteitsmatch en aanwezigheid van bijlagen voeden drie vooraf gebouwde policies, zodat waarschuwingen zeldzaam genoeg blijven om serieus genomen te worden door verzenders.
  4. Alleen-rapportagemodus meet risico voordat iemand een waarschuwing ziet. Elk bericht wordt geëvalueerd en stilletjes gelogd, wat je een basislijn van detecties per policy geeft om te vergelijken met je incidentlog en DLP-bevindingen.
  5. Elke waarschuwing en elke beslissing komt in de auditlog. Policy, richtlijn, ontvangers, reactie en tijdstip worden vastgelegd, wat auditgereedheid ondersteunt als iemand vraagt hoe je weet dat de controle heeft gewerkt.

Waarom patroon-gebaseerde DLP een verkeerde ontvanger niet kan zien

DLP doet belangrijk werk, en niemand zou het moeten uitschakelen. Het inspecteert berichten en bijlagen op data die niet mag vertrekken, zoals kaartnummers, identificatoren of gemarkeerde documenten. Het probleem ontstaat wanneer de data mag vertrekken, maar de persoon die het ontvangt de verkeerde is. Er is niets voor een regel om op te matchen, dus blijft het stil, en het incident komt pas aan het licht als de echte ontvanger reageert of een klant klaagt.

Wat patroonregels beoordelen

Patroonregels beoordelen het bericht zelf: de tekst, de bijlagen, de labels. Ze beantwoorden een duidelijke vraag goed. Bevat dit bericht data van een type dat wij beperken? Dat werkt voor exfiltratie en voor onbedoelde lekken van data die nooit via e-mail had mogen reizen. Het helpt niet wanneer een legitiem document bij een onbedoelde partij terechtkomt.

Wat ze niet kunnen beoordelen

Aangrenzende toolcategorieën dekken het gat ook niet af. DSPM vindt en classificeert gevoelige data in rust. IAM bepaalt wie mag inloggen. Zero trust bepaalt wie toegang krijgt tot wat. Alle drie zijn waardevol, maar geen van hen vraagt of de persoon in het Aan-veld de persoon is die de verzender bedoelde. Die vraag hoort bij het moment van opstellen, daarom moet een ontvangercontrole in het opstelvenster zitten.

Hoe Kiteworks AHEP de ontvanger controleert vóór verzending

AHEP maakt deel uit van de Kiteworks Data Policy Engine en vereist release 9.5. Het evalueert een bericht terwijl het wordt geschreven, en opnieuw telkens wanneer de verzender een ontvanger toevoegt of verwijdert of een bestand bijvoegt. E-mail reist nog steeds direct van de client naar de mailserver. De AHEP Validation Service evalueert alleen het bericht en verstuurt zelf geen e-mail.

Drie vooraf gebouwde policies voor veelvoorkomende ontvangerfouten

Drie policies zijn direct klaar voor gebruik. Eén raadt BCC aan wanneer het aantal externe ontvangers een drempel overschrijdt die je beheerder instelt. Eén voorkomt verzending naar persoonlijke e-mailadressen wanneer een bekend persoonlijk domein, een identiteitsmatch met de verzender en een niet-inline bijlage samen voorkomen. Eén detecteert fouten in e-maildomeinen, en markeert domeinen die één teken afwijken van een bekend consumentendomein en domeinen zonder geldig MX-record. Beheerders stellen de status van elke policy in op Uit, Aan of Alleen-rapportage, en kiezen een Suggestie- of Waarschuwingsrichtlijn. Er is geen maatwerkontwikkeling nodig.

Waarom waarschuwingen zeldzaam genoeg blijven om gelezen te worden

De policy voor persoonlijke adressen vereist dat alle drie de voorwaarden tegelijk gelden, dus een persoonlijk adres zonder bijlage activeert het niet. Die terughoudendheid is bewust. Mensen stoppen met het lezen van waarschuwingen die de hele dag verschijnen, en een waarschuwing die alleen verschijnt als aan de voorwaarden is voldaan, is er één waar ze op reageren. Als er wel een waarschuwing verschijnt, zit de oplossing in het opstelvenster: verplaats externe ontvangers naar BCC, corrigeer het domein of verwijder de gemarkeerde ontvanger. Bij Suggestie kan de verzender doorgaan. Bij Waarschuwing moet de verzender eerst de waarschuwing oplossen of negeren. Niets wordt stilletjes geblokkeerd.

AHEP testen met je eigen incidentdata

Je hoeft geen enkele leverancier op zijn woord te geloven. Zet elke policy een paar weken in Alleen-rapportagemodus. AHEP evalueert en logt elk bericht en toont niets aan gebruikers. Vergelijk daarna de detecties met je eigen incidentlog en met wat je DLP in dezelfde periode heeft gemarkeerd. Het verschil tussen de twee is jouw getal, en dat is het sterkste argument dat je kunt gebruiken richting een budgethouder.

Wat je moet controleren voordat je een pilot start

Plan voor de grenzen. Waarschuwingen werken in de Kiteworks Web App en Outlook Classic. AHEP vereist de Kiteworks containerized services layer (RKE2) en de Validation Service, die door de technische ondersteuning van Kiteworks wordt geactiveerd. Detectie is het nauwkeurigst wanneer gebruikersnamen een standaardformaat volgen en zakelijke adressen eruitzien als voornaam.achternaam@bedrijf, en niet elk persoonlijk adres wordt gedetecteerd, bijvoorbeeld bij een eigen domein. Stem deze punten eerst af met je messagingteam en de pilot zal je waardevolle inzichten geven.

Het ontvangersgat dichten op het Kiteworks Data Control Plane

Posturetools laten zien waar gevoelige data zich bevindt en wie er toegang toe heeft. DLP inspecteert wat vertrekt. De resterende stap is actieve bescherming van data in beweging, op het moment dat een persoon of een AI-agent een ontvanger kiest. Dat is waar het Kiteworks Data Control Plane opereert. AHEP is ingebouwd in de Data Policy Engine die al e-mail, bestandsoverdracht, SFTP, MFT en formulieren beheert, zodat ontvangercontroles naast de data-bewuste policies draaien die je op andere kanalen gebruikt. Validatie draait binnen je eigen omgeving, en elke waarschuwing, afwijzing en beslissing komt in een niet-manipuleerbare auditlog die je SIEM-tooling kan voeden.

Het vult je DLP-, DSPM- en IAM-investeringen aan in plaats van ze te vervangen. Wil je de drie policies zien werken in de Kiteworks Web App en Outlook Classic, plan een aangepaste demo met ons team en neem je eigen incidentvoorbeelden mee.

Veelgestelde vragen

Patroon-gebaseerde DLP inspecteert de inhoud van berichten en bijlagen op beperkte datatypes, maar beoordeelt niet of de ontvanger correct is, waardoor geautoriseerde gevoelige data bij onbedoelde partijen kan terechtkomen zonder dat regels worden geactiveerd.

AHEP, onderdeel van de Kiteworks Data Policy Engine, controleert de ontvanger in realtime terwijl een bericht wordt opgesteld, en evalueert voorwaarden zoals ontvangerstype, externe hoeveelheid, identiteitsmatch en bijlagen om mogelijke fouten te markeren vóór verzending.

De policies adviseren BCC bij te veel externe ontvangers, blokkeren verzending naar persoonlijke e-mailadressen in combinatie met identiteitsmatches en niet-inline bijlagen, en detecteren domeintypfouten of ongeldige MX-records.

Voer policies enkele weken uit in Alleen-rapportagemodus om detecties stilletjes te loggen, en vergelijk de resultaten vervolgens met bestaande incidentlogs en DLP-bevindingen om een basislijn te bepalen zonder waarschuwingen aan gebruikers te tonen.

Aan de slag.

Het is eenvoudig om te beginnen met het waarborgen van naleving van regelgeving en het effectief beheren van risico’s met Kiteworks. Sluit je aan bij de duizenden organisaties die vol vertrouwen privégegevens uitwisselen tussen mensen, machines en systemen. Begin vandaag nog.

Share
Tweet
Share
Explore Kiteworks