Menu 

DLP – Part 2

If you have not yet read Part 1 of this two-part series, please read it first for a better understanding of Data Leak Prevention and how it may benefit your organization.

This particular blog post is going to center a bit more around a real-life application for a DLP scenario that we have recently put in place for a client looking to better automate International Traffic in Arms Regulations (ITAR) document control.  In lieu of actually going into all of the ins/outs of ITAR-compliance (which we are more than happy to discuss), I am going to say that the basic requirement that we are going to utilize DLP for is controlling the accidental transmission of documents outside of the network, in this case via SMTP (although HTTP(s), SMTP(s), POP3, etc. can also be easily enabled).  It also assumes there is a FortiGate that can do DLP and Exchange 2007/2010 with an installed and properly configured 3rd Party Certificate for SMTP.

Scope
First hurdle was defining the documents that needed to be controlled.  Since the documents that did not need to be ITAR-compliant are really no different than those that need to be ITAR-compliant, we needed a way to identify those that we need to ensure are protected.  Although we can put a DLP rule in place to block all outgoing attachments, it wouldn’t be good for business, so we decided that simply automating a process that all ITAR files come in from (a custom-built web application), that would automatically adjust the permissions of the file and prepend the name “ITAR” to the document.  This would allow us to identify it from all non-ITAR documents as well as provide a universal method for tagging these items compared to attempting something like meta-tagging where we would likely have to implement a third-party application or custom code in order to enforce that across multiple document types, formats and applications.  The main goal here is to prevent accidental data transmission and trying to at least slow down any malicious attempts.

Practice
As mentioned above, the first step was to define a method that we would identify the documents to be controlled, and put a naming and security scheme in place within the domain to enforce that.  We did this through the use of a simple, secure web application written so that ITAR documents can be uploaded to the client and renamed appropriately.  The next step with the documents named was to put a rule in place on the FortiGate firewall that would prevent this type of document to be sent out.  This was simple enough:

Create a File Filter:

              1. UTM -> AntiVirus -> File Filter -> Create New
              2. Name: ITAR Filter
              3. Create New
              4. Filter Type: File Name Pattern
              5. Pattern: *ITAR*
              6. Action: Block
              7. Enable: Checked

Apply The Filter:

1. UTM -> Data Leak Prevention -> Rule -> Create New
2. Name: ITAR Attachment
3. Protocol: Email
4. Rule select: Attachment type, is, ITAR Filter
5. File Options select: Scan archive contents
6. Click Ok

You can then go on to create a Compound Rule, and then a Sensor that utilize the rule created earlier, and add in any other rules or protocols that might be needed.  Once the Sensor is created, you need to apply it to a Firewall Policy Rule in order for it to actually be used.  This is as easy as creating a firewall rule for the protocol(s) you are utilizing, and then applying the UTM of the selected Protocol and DLP Sensor to the rule.  That is about it for configuring the firewall!

But what about…
Obviously stopping all email with the ITAR attachments may work for some, however for this client, they also work directly with other ITAR-compliant organizations that they will need to transfer ITAR documents to/from.  So how do we deal with this?  Simply we ensure that both organizations’ email servers can enforce TLS encryption for communications.  That way any documents sent (ITAR or not) are encrypted and thus compliant.  Additionally, since we have not setup the Fortigate to inspect the encrypted SMTP, it will allow for ITAR documents to be transmitted to a defined list of domains in our email server that we say are TLS encrypted.  In our case this is Exchange Server 2010.

Setup TLS Encryption for specific domains
Since we know a handful of domains that we will want to send ITAR encryption to, we will need to make several changes to our Exchange deployment so specifically send and receive TLS-encrypted email from those domains, and not accept email that has not been encrypted (from those domains only).  The key here is to create a Send (and maybe Receive as needed) connector in Exchange for those specific domain(s) and then ensure that TLS is enforced.  You can also utilize your default receive connector and enable Mutual Auth TLS in the Network tab.

For Example to send to Intrinium.com (assuming Intrinium.com can use TLS):
1. New Send Connector (Internet), named TLS Secured
2. Address Space: Intrinium.com
3. Network: Enable Domain Security (Mutual Auth TLS)

Add Domains to the Send (and/or Receive) Transport List (see Here) in Exchange Management Shell:

Send
Set-TransportConfig –TLSSendDomainSecureList Intrinium.com
 (this will set only a single domain and will clear any other, for multiples, use:)

$TransportConfig = Get-TransportConfig
$TransportConfig.TLSSendDomainSecureList += “intrinium.com”
Set-TransportConfig -TLSSendDomainSecureList $TransportConfig.TLSSendDomainSecureList

Receive
Set-TransportConfig -TLSReceiveDomainSecureList intrinium.com
 (this will set only a single domain and will clear any other, for multiples, use:)

$TransportConfig = Get-TransportConfig
$TransportConfig.TLSReceiveDomainSecureList += “intrinium.com”
Set-TransportConfig -TLSReceiveDomainSecureList $TransportConfig.TLSReceiveDomainSecureList

Finally
The last thing we need to do is turn off opportunistic TLS for the default connectors.  Since we are not inspecting encrypted (SMTP SSL inspection is supported by some FortiGate models, and could be an alternative option) emails we want to ensure that only those that are encrypted are allowed out and everything else should be considered to be “public” as far as email goes, we need to simply run the following commands for the default Send connector (not the one used by TLS) to not use TLS and to not send out to the secured domains specified earlier:

 Set-SendConnector “Default Send Connector” -IgnoreSTARTTLS: $true
 Set-SendConnector “Default Send Connector” -DomainSecureEnabled:$False

And the following on the Send connector that is using TLS:
 
 Set-SendConnector “TLS Secured” -DomainSecureEnabled:$True

What Happens Now
So now when an email is sent that contains an ITAR-controlled document it will either be encrypted by Exchange and ignored by the DLP filter, or (if it is not sent to an identified domain that is secured) it will be inspected and either allowed through or blocked if it contains an ITAR document.  We can even go as far as adjusting the message back to the sender, however we have left it as default here and the following NDR is sent back from the FortiGate:

<domain> rejected your message to the following e-mail addresses:
conrad@<domain> (conrad@<domain>)
<domain> gave this error:
This email has been blocked. The email message appeared to contain a data leak.

Your message wasn’t delivered due to a permission or security issue. It may have been rejected by a moderator, the address may only accept e-mail from certain senders, or another restriction may be preventing delivery.

Diagnostic information for administrators:
Generating server: <EXCHANGE>.<domain>
conrad@<domain>
<domain> #554 5.7.1 This email has been blocked. The email message appeared to contain a data leak. ##

Original message headers:
Received: from <EXCHANGE>.<domain> ([fe80::0000:0000:0000:0000]) by
<EXCHANGE>.<domain> ([fe80::0000:0000:0000:0000]) with mapi id
xx.xx.xx.xx; Tue, 7 Jun 2011 12:04:41 -0700
From: <sender>
To: “
conrad@<domain>” <conrad@<domain>>
Subject: ITAR Email
Thread-Topic: ITAR Email
Thread-Index: AcwlRbwtOu3Ugap2StWvM7QfuCikAw==
Date: Tue, 7 Jun 2011 19:04:39 +0000
Message-ID: <
.FA628430320F3B48857577D720612F33358038@<EXCHANGE>.<domain>>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [xxx.xxx.xxx.xxx]
Content-Type: multipart/mixed;
 boundary=”xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”
MIME-Version: 1.0

Wrap Up
So that is how we configured and used DLP and it was the most simple part of the entire project.   I found that it is a good idea to keep the exchange queues open and restart the Transport Service after ANY changes to make sure they take.  You’ll know right away if emails to/from the domains are working correctly, although I recommend having an email client open (or OWA) and have emails going to/from constantly to ensure things are working to TLS and non-TLS domains.

Submit a Comment

Pin It on Pinterest

Share This