Explorer III

Solved

DLP testing for Outlook and Gmail (Fortigate 60E)

Forum|Forum|2 years ago
June 25, 2024
4 replies
3191 views

Hello everybody,

I'm working on a Fortigate 60E (FortiOS 7.2.8).

My pc is on an isolated network (i'm the only host) and there is only one simple rule: Screenshot 2024-06-20 alle 10.28.34.png

The dlp profile is simple and is configured to block a credit card number. I built it following the Fortinet tutorial for DLP. It's configured to work with every possibile protocol.

I tested this profile on dlptest.com and everything worked fine.

Now, I'm trying to understand if this profile could be able to block an email that contains a credit-card number inside the text (or an attached file that contains a credit-card number).

Here is Gmail:

During the upload of the attached file, Gmail correctly detects the data leak inside it and blocks the upload.

Screenshot 2024-06-25 alle 10.34.50.png

But if I write the same credit-card number as plain text, the mail is blocked in a strange way...the connection collpases ("an error occured") and I have to refresh the page.

Screenshot 2024-06-25 alle 10.44.20.png

I can't send the mail obviously, but this is not a good filtering. You are stucked and you have to refresh the page. Why is this happening?

For Outlook is the same, more or less.

Maybe that Fortigate is not the right tool to work with emails? Maybe I need FortiMail?

Thank you for your support!

Best answer by pminarik

DLP's goal is to prevent the transport, and that's it. The response to a client's message containing the offending data is to reply with a replacement block-page for DLP (if HTTP/S), or dropping the session in other cases (TCP RST maybe? Not sure off the top of my head).

How the client app responds to this is out of scope. Maybe it will react reasonably, like in your first screenshot, maybe it it will just "halt and catch fire", like in your second screenshot. Either way, it's not possible for Fortinet to generate DLP responses that will be understood by all features of all web-apps. There's no general approach that will be understood by every app all the time, unfortunately.

pminarikAnswer

Staff

DLP's goal is to prevent the transport, and that's it. The response to a client's message containing the offending data is to reply with a replacement block-page for DLP (if HTTP/S), or dropping the session in other cases (TCP RST maybe? Not sure off the top of my head).

How the client app responds to this is out of scope. Maybe it will react reasonably, like in your first screenshot, maybe it it will just "halt and catch fire", like in your second screenshot. Either way, it's not possible for Fortinet to generate DLP responses that will be understood by all features of all web-apps. There's no general approach that will be understood by every app all the time, unfortunately.

raffaeledpAuthor

Explorer III

Thank you, I understand what you say and agree with you. Do you think that FortiMail could handle this kinds of situations in a more appropriate way?

pminarik

Staff

Assuming the goal is filtering webmail of Gmail, I would not expect FortiMail to behave any better here. I would expect that some direct integration with Gmail for this to have assurance of working "nicely" from an end-user's perspective, and I'm not sure if either FortiOS or FortiMail have such integrations. (to FortiMail experts reading this: Corrections welcome! :) )

Maybe if the filtering was done on the SMTP level (once the message is "sent" by the user and in transit)? Not sure if one can configure Gmail to send all mail through a FortiMail first.

Hypothentically, some (Forti?)CASB solution might be a good fit, but I do not know if there is any for Gmail.

edit: This document appears to describe a Gmail<->FortiMail integration via SMTP. I assume you would then be able to apply DLP on the FortiMail for the passing Gmail traffic.

Sign up

Login with SSO

Login to the community

Login with SSO