Affichage des articles dont le libellé est Exchange 2013. Afficher tous les articles

In this third and last part of the article, we will explore Policy Tips, test these policies and look at all the information that DLP logs.

So far in this article series we have seen what the purpose of the new Data Loss Prevention feature of Exchange 2013 Preview is, how it works and how to create DLP Policies using both the Exchange Administration Center and the Exchange Management Shell Exchange. ....

Policy Tips

In the first part of this article, we saw that we can notify a sender if he/she is about the send information that violates a DLP Policy. But how is the sender notified? By including a Policy Tip notification message!

These Policy Tips are similar to the MailTips introduced in Exchange 2010 as they display a notification message to Outlook users when they are composing an e-mail. Obviously they only show up if Exchange detects something in the e-mail that violates a DLP Policy currently in place and if this policy has a rule to notify the sender.

A great thing about Data Loss Prevention [DLP] and Policy Tips is that Exchange will automatically look into a message’s subject, body and even attachments when evaluating conditions within policies. This means that if a user is writing an e-mail with a perfectly normal body text but attaches an Excel document with credit card details, then a Policy Tip notification that you create will be shown to the sender in Outlook reminding him/her of the policy against such action.

The benefit of Policy Tips is that if a user writing an e-mail is made aware in real-time that he/she might be violating a corporate policy, then he/she is less likely to violate it.

Now let’s test a few DLP Policies and look how these Policy Tips look like.

Testing DLP Policies

Let’s send a couple of e-mails to test these policies - remember that at this time both policies are set to Enforcementmode as we recreated the first policy (which was in Audit mode) in PowerShell and set it to this Enforce.

Let’s start by writing an e-mail with a credit card number attached:

Figure 3.1: Writing E-mail with Confidential Data

Note that while I am writing the e-mail a Policy Tip came up stating that the e-mail contains sensitive content! Even though the body of the e-mail doesn’t contain anything confidential, the attached file contains a credit card number which Outlook highlights straight away!

The interesting part is that these rules are smart enough to detect “valid” credit card numbers. If you simply type a random 16 digit number it will not flag it as being a credit card number! Also, no matter if you put spaces or not in-between each 4-digit set of numbers, Exchange will still detect it.

Because this e-mail only contains 1 credit card number, the existing policy will allow the e-mail to go through. Instead of including more credit card numbers in the e-mail (more than 9 as we saw in the first part of the article) I simply updated the High Count rule of this policy to match 1 or more credit card numbers and send the e-mail again. As expected, it gets blocked:

Figure 3.2: Blocked E-mail - Message Tracking Logs

Note the FAIL EventID, a report being sent to the DLP mailbox and the RecipientStatus saying why the message was rejected.

As I mentioned in the first part of this article, DLP information also gets written into the Message Tracking Logs (more than what I showed in Figure 3.2 above). These logs contain data from the Agents involved in processing mail flow content. For DLP, the Transport Rule Agent [TRA] is used to scan message content and apply the policies defined as part of the Exchange Transport Rules [ETRs]. The existing AgentInfo Event is used to add DLP related entries in the Message Tracking Log. If we look deeper into the logs of Figure 3.2, we can see this data:

Figure 3.3: Incident Data Logging

In the above screenshot, by the number of ruleId fields in EventData we can see the agent processed the e-mail against 2 rules. These fields are as follows:

The TRA (Transport Rule Agent) is ETRP (Exchange Transport Rule Performance)
The ruleId is 26eb1f73-da84-4cef-8d35-cc75805f2876 – you can check what rule this is by running the cmdletGet-TransportRules | ? {$_.GUID –eq “26eb1f73-da84-4cef-8d35-cc75805f2876” which in this case is theBlock Passport Numbers rule we created and which didn’t match anything
The execW (Execute Wall Clock) is 252ms
The exec (Execute CPU Clock) is 0ms
The TRA (Transport Rule Agent) is ETRP (Exchange Transport Rule Performance)
The ruleId is 2bdbddc1-7000-49b8-b941-b6fcca58699d – in this case is the Financial Data (U.S.): Monitor Data Sent To Outside High Count rule as we expected
The execW (Execute Wall Clock) is 199ms
The exec (Execute CPU Clock) is 15ms
The TRA (Transport Rule Agent) is DC (Data Classification)
The dcid (ID of the Data Classification) is 50842eb7-edc8-4019-85dd-5a5c1f2bb085
The count (Count of the Data Classification) is 1 as only one credit card number was found
The conf (Confidence level of the Data Classification) is 85%

Looking into the DLP Incident mailbox, we can see the report for this e-mail, including the text of the attached file! This report also includes similar information as the one seen in AgentInfo previously:

Figure 3.4: Incident Report

Note that the severity was set to High; it wasn’t an override; a Credit Card Number was detected with a count of 1 and a confidence level of 85%; the triggered rule was Financial Data (U.S.): Monitor Data Sent To Outside High Count; theReport ID Match shows the credit card number found and in Context we have the entire content of the text file.

Also, me as the sender received the following Non-Delivery Report [NDR] message:

Figure 3.5: Non-Delivery Report Message sent to Sender

However, nor the Policy Tip nor this NDR say how to override the policy as they should... It seems that this part is not 100% finished yet or perhaps I missed something...

Finally, let’s test an override. This time, let’s send the same e-mail message but with the word “override” in the subject (as this is the default override method, which obviously can be changed). As expected, the e-mail is allowed to go through but a report is still sent to the DLP Incident mailbox as configured in the Allow Override rule:

Figure 3.6: Allowed E-mail - Message Tracking Logs

Looking at the header of the received e-mail, we can see that the X-Ms-Exchange-Organization-Dlp-SenderOverrideJustification field was set to TransportRule override even though the same Financial Data (U.S.): Monitor Data Sent To Outside High Count rule was triggered:

Figure 3.7: Message Headers

Exchange 2013 Data Loss Prevention (Part 3)

by Nuno Mota

In the first part of this article series, we had a quick look at anti-spam in Exchange 2013 and how it is practically unchanged from Exchange 2007 and 2010. In this article we will explore the new features surrounding anti-malware protection in Exchange 2013.

Anti-Malware in Exchange 2013

Exchange 2013 comes out of the box with basic built-in anti-malware protection designed to help organizations combat viruses and spyware in their e-mail messaging environment. As a quick recap, viruses infect other programs and data, and spread throughout computers looking for programs to infect. Spyware, on the other hand, gathers personal information, such as login details or personal data, and sends it back to its author.
This basic anti-malware protection can be turned off, replaced, or paired with a cloud-based service (such as Microsoft Exchange Online Protection (EOP)) in order to provide a layered and more in-depth defense.

Forefront Protection for Exchange (FPE) vs. Exchange 2013

As we all know, in September 2012 Microsoft announced it was discontinuing further releases of all of the Forefront suite products, with FPE support expiring December 31, 2015. With this, Microsoft changed their security offerings in favor of a lightweight built-in, anti-malware filter in Exchange 2013. But how exactly does FPE compare to the built-in anti-spam and anti-malware capabilities of Exchange 2013?
The first difference from FPE is that the built-in anti-malware feature in Exchange 2013 uses only a single scanning engine, not multiple. This might not be a show stopper for some organizations, but it is definitely something to keep in mind.
Another limitation is the fact that Exchange 2013 only performs transport-level scanning, i.e., e-mails are scanned as they pass through the transport pipeline. Although transport-level scanning is very important, this means that it does not scan a mailbox store, meaning that imported items never get scanned unless they are sent to someone, for example. Also, imagine that an e-mail containing a virus that Exchange does not yet detect, gets delivered. When Exchange is updated with a signature for the virus, the e-mail will never be scanned and the user is free to open the infected e-mail as opening an e-mail that has already been delivered to the user's mailbox does not require the e-mail to pass through the transport pipeline.
The following table should provide some clarity around what is offered and what is not with Exchange 2013:

Feature	FPE	Exchange 2013
Scanning e-mails in real-time (transport scan)	Yes	Yes
Scanning mail store (mailbox scan)	Yes	No
Scanning e-mails when accessed (mailbox scan)	Yes	No
Quarantine	Yes	No
Reports	Yes	No
Attachment filter	Yes	No

Table 1

Enabling, Disabling and Bypassing Malware Filtering

If the default installation options of Exchange 2013 are selected, anti-malware filtering is enabled by default. If, for any reason, you chose to disable it during installation and now wish to enable it, you use the Enable-AntimalwareScanning.ps1 script. This script enables the malware agent and configures regular updates.
Start by navigating to the Exchange Scripts folder and then run the script mentioned above:
CD $ExScripts
.\Enable-AntiMalwareScanning.ps1
Restart-Service MSExchangeTransport

Figure 2.1: Enabling Anti-Malware Scanning

It is also possible to disable or bypass malware filtering of all e-mails in transit. For example, administrators may want to disable Exchange 2013 malware filtering if they are using another product for malware filtering. When malware filtering is disabled, the Exchange malware agent is unhooked and not running, and engine updates are not kept up-to-date.
Bypassing malware filtering should only be done when troubleshooting a problem. When malware filtering is bypassed, the Exchange malware agent remains hooked, and engine updates are kept up-to-date. However, malware filtering is skipped while administrators attempt to resolve whatever problems they are facing. After finishing troubleshooting, malware filtering should be restored.

Disabling Malware Filtering

To disable malware filtering, run the Disable-Antimalwarescanning.ps1 script and restart the Exchange Transport Service:
CD $ExScripts
.\Disable-AntiMalwareScanning.ps1
Restart-Service MSExchangeTransport

Figure 2.2: Disabling Anti-Malware Scanning

To verify that malware filtering is disabled, run the following cmdlet and confirm that it returns a value of False:
Get-TransportAgent “Malware Agent”

Figure 2.3: Checking Anti-Malware Scanning Status

Bypassing Malware Filtering

To temporarily bypass malware filtering, run the following cmdlet:
Set-MalwareFilteringServer <Server_Name> -BypassFiltering $True

Figure 2.4: Bypassing Anti-Malware Scanning Status

To verify that malware filtering is being bypassed, run the following cmdlet and confirm that it returns a value of True:
Get-MalwareFilteringServer | Select BypassFiltering

Figure 2.5: Checking Anti-Malware Bypassing Status

To restore malware filtering, simply set the -BypassFiltering parameter back to $False:
Set-MalwareFilteringServer -BypassFiltering $False

Engine and Definition Updates

When malware protection is enabled, Exchange automatically checks for engine and definition updates every 30 minutes. You can check when and what version of the engine and definitions is in use by running the Get-EngineUpdateInformation cmdlet:

Figure 2.6: Engine Update Information

If you want to manually force an update check, run the Update-MalwareFilteringServer.ps1 script (basically a wrap around the Start-EngineUpdate cmdlet):
CD $ExScripts
.\Update-MalwareFilteringServer.ps1 <Server_Name>

Figure 2.7: Starting Engine Update

To verify that updates were successfully downloaded, check the event log:

Open Event Viewer;
In Event Viewer, expand the Windows Logs folder, and then click Application;
In the Actions menu, click Filter Current Log;
In the Filter Current Log dialog box, from the Event sources drop-down list, select the FIPFS check box, and then click OK.

If engine updates were downloaded successfully, you will see an Event ID 6033 similar to the following:
MS Filtering Engine Update process performed a successful scan engine update.
Scan Engine: Microsoft
Update Path: http://forefrontdl.microsoft.com/server/scanengineupdate
Last Update time: ‎2013‎-10‎-28T14:18:23.000Z
Engine Version: 1.1.8601.0
Signature Version: 1.131.2169.0
You can configure the update settings using the Set-MalwareFilteringServercmdlet with the –UpdateFrequencyparameter. This parameter specifies the frequency interval in minutes to check for malware scanning engine updates. A valid value is an integer between 1 and 38880 (27 days), with the default being 30.
You can also use the -UpdateTimeout parameter to specify the timeout interval in seconds to use when checking for malware scanning engine updates. A valid value for this parameter is an integer between 60 and 300, with the default being 150 seconds (2.5 minutes).
Using the Get/Set-EngineUpdateCommonSettings cmdlet you can also change these and other settings on a global scale:

Figure 2.8: Engine Update Global Information

Rescan E-mails Already Scanned by EOP

Exchange 2013 can be configured to rescan e-mails that have already been scanned by a hosted e-mail filtering service such as EOP. As EOP only scans inbound and outbound e-mails, enabling this feature provides another layer of defense against malware as the on-premises Exchange will scan for internal e-mails. By default, e-mails scanned in the cloud are not resubmitted for malware scanning on-premises.
To rescan e-mails already malware scanned by the hosted filtering service, run the following cmdlet:
Set-MalwareFilteringServer <Server_Name> -ForceRescan $True

Figure 2.9: Forcing E-mail Rescan

To return to the default setting of not rescanning e-mails, simply reset the above parameter to $False:
Set-MalwareFilteringServer <Server_Name> -ForceRescan $False
Exchange on-premises uses the following Xheaders for AVStamp to check if an e-mail has already been scanned by EOP or not:

Exchange 2013 on-premise: X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0
Exchange 2013 in the cloud (Exchange Online/EOP): X-MS-Exchange-Organization-AVStamp-Service: 1.0

Conclusion

In this article we started exploring the new features surrounding anti-malware protection in Exchange 2013. In the next and final article, we will have a look at anti-malware policies and finish with some common questions and answers.

Anti-Spam and Anti-Malware Protection in Exchange 2013 (Part 2)

by Nuno Mota

Introduction

Spam and viruses have been a concern for any messaging administrator since almost the first public messaging environment. Every year, the volume of e-mail spam and viruses keeps increasing as so does their sophistication. Microsoft understands these threats and, as such, Exchange has been providing anti-spam protection out of the box for many versions now.
Exchange 2003 had built-in Open Relay Filter or DNS Blacklist and Realtime Blackhole List capabilities which were later complemented by Microsoft Exchange Intelligent Message Filter (IMF) that used Microsoft SmartScreentechnology to provide better anti-spam protection. IMF, first released in May 2004 became an integral part of Exchange 2003 in SP2.
With Exchange 2007 and 2010, Microsoft further improved Exchange’s anti-spam capabilities by providing connection filtering, content filtering, attachment filtering, sender ID, sender/recipient filtering, sender reputation and IP allow/block lists out of the box on an Edge server. All these features could also be enabled on a Hub Transport server, with the exceptions of connection and attachment filtering. This meant that small organizations that did not have the means, capabilities or enough e-mail volume to justify the cost of installing and maintaining a full perimeter network together with an Edge Transport server, could still take advantage of almost all its anti-spam capabilities.
However, although this provided a good level of protection, there was never in-built anti-malware protection for some reason. As such, all these features were typically complemented either by using anti-pam/anti-malware third-party software or appliance, or Microsoft’s own software. As to the latter, first there was Microsoft Antigen for Exchange 2003, then Microsoft Forefront Security for Exchange Server (FSE) for Exchange 2007 and finally Microsoft Forefront Protection 2010 for Exchange Server (FPE) for both Exchange 2007 SP1 and 2010.
As we all know, in September 2012 Microsoft announced it was discontinuing further releases of all of the Forefront suite products, with FPE support expiring December 31, 2015. Microsoft’s recommendation was now for organizations to use Forefront Online Protection for Exchange (FOPE), now named Exchange Online Protection (EOP) in its latest release.
Unfortunately, cloud solutions such as EOP are not suitable for every organization. So what should organizations with an on-premise Exchange 2013 deployment do for anti-spam and anti-malware protection? To answer this question, let us have a look at what Exchange 2013 provides in this subject. We will start by reviewing the anti-spam features of 2013, which are virtually identical to Exchange 2010 and then explore the new capabilities introduced around anti-malware protection.
For the first time, an Exchange release provides both anti-spam and anti-malware protection out of the box.
Note:
Although Data Loss Prevention (DLP) can be used to help protect sensitive data, this article will only focus on protecting against spam and viruses. For more information on DLP, please check the Exchange 2013 Data Loss Prevention article.

Anti-Spam in Exchange 2013

As with previous versions of Exchange, 2013 provides a layered approach to help reducing spam. It uses transport agents to provide anti-spam filtering with built-in anti-spam agents available remaining relatively unchanged from Exchange 2010.
With the server role consolidation in Exchange 2013, one might expect the anti-spam agents to now be installed on the Client Access servers (CAS), which run the Front End Transport service, since this service is the first point of contact for any inbound e-mail to the organization. However, remember that CAS servers now act as a stateless proxyfor all inbound and outbound external SMTP traffic, it does not inspect message content and does not queue any messages locally. On the other hand, the Transport service, which runs on all Mailbox servers, is almost identical to the Hub Transport server role in previous versions of Exchange. It handles SMTP mail flow for the organization, performs message categorization, content inspection and does queue messages locally.
For these reasons, anti-spam agents in Exchange 2013 run on Mailbox servers.

Anti-Spam Mailbox Agents

Anti-spam agents are usually enabled on mailbox servers when an organization does not have an Edge Transport server or some sort of third-party anti-spam filtering appliance.
Similarly to transport agents, anti-spam agents are assigned a priority value. A lower value indicates a higher priority, so typically, an anti-spam agent with priority 1 will act on a message before an anti-spam agent with priority 9. Based on the default priority value of the anti-spam agent, the following list briefly describes the agents and the default order in which they are applied to messages on a Mailbox server:

Sender Filter agent: compares the sender on the MAIL FROM: SMTP command to an administrator-defined list of senders or sender domains who are prohibited from sending messages to the organization to determine what action, if any, to take on an inbound message;
Recipient Filter agent: compares the message recipients on the RCPT TO: SMTP command to an administrator-defined Recipient Block list. If a match is found, the message is not permitted to enter the organization. The recipient filter also compares recipients on inbound messages to the local recipient directory to determine whether the message is addressed to valid recipients. When a message is not addressed to valid recipients, it is rejected;
Sender ID agent: relies on the IP address of the sending server and the Purported Responsible Address (PRA) of the sender to determine whether the sender is spoofed or not;
Content Filter agent: assesses the contents of a message and also acts on the safelist aggregation feature, which collects data from the anti-spam safe lists that Outlook and Outlook Web App users configure and makes this data available to the Content Filter agent;
Protocol Analysis agent: is the underlying agent that implements the sender reputation functionality. Sender reputation relies on persisted data about the IP address of the sending server to determine what action, if any, to take on an inbound message. A Sender Reputation Level (SRL) is calculated from several sender characteristics that are derived from message analysis and external tests.

Anti-Spam Legacy Edge Transport Agents

As Exchange 2013 does not provide, at this stage, an Edge server, many organization already using Exchange 2013 choose to use an Exchange 2010 Edge Transport server. One reason for this is that, besides having installed and enabled by default all of the anti-spam agents described above, an Edge server provides two more agents not available on a Mailbox server:

Connection Filtering agent: inspects the IP address of the remote server that is trying to send messages to determine what action, if any, to take on an inbound message. Connection filtering uses a variety of IP Block/Allow lists as well as IP Block/Allow List provider services to determine whether the connection from the specific IP should be blocked or allowed in the organization;
Attachment Filter agent: filters messages based on attachment file name, extension or MIME content type. Attachment filtering can be configured to block a message and its attachment, to strip the attachment and allow the message to pass through, or to silently delete the message and its attachment.

Based on the default priority value of the anti-spam agents, this is the default order in which they are applied on an Edge Transport server:

Connection Filtering agent
Sender Filter agent
Recipient Filter agent
Sender ID agent
Content Filter agent
Protocol Analysis agent for sender reputation
Attachment Filter agent

Enabling Anti-Spam Agents

As already mentioned, In Exchange 2013 the following anti-spam agents are available in the Transport service on Mailbox servers, but they are not installed by default:

Content Filter agent
Sender ID agent
Sender Filter agent
Recipient Filter agent
Protocol Analysis agent for sender reputation

Remember that organizations typically install the anti-spam agents in the Transport service on a Mailbox server only when it accepts all incoming mail without any prior anti-spam filtering. In case these agents are installed on a Mailbox server but there is also other Exchange anti-spam agents operating on the messages before they reach the Mailbox server (like an Exchange 2010 Edge Transport server in the perimeter network), the anti-spam agents on the Mailbox server recognize the anti-spam X-header values that are added to messages by other Exchange anti-spam agents. Messages that contain these X-headers pass through without being scanned again. The only exceptions are recipient look-ups performed by the Recipient Filter agent which will occur again on the Mailbox server.

Figure 1.1: Anti-Spam X-Headers

In order to install and use these agents, we have to use the same Install-AntispamAgents.ps1 script we used with Exchange 2007 and 2010. Start by navigating to the Exchange’s Script folder and then run the script:

Figure 1.2: Running the Install-AntispamAgents.ps1 Script

Next, restart the Microsoft Exchange Transport service either using the Services MMC or the Shell:

Figure 1.3: Restarting the Microsoft Exchange Transport Service

The final step is to specify the IP addresses of any internal SMTP servers that should be ignored by the Sender ID agent. At least one IP address needs to be set. If the Mailbox server we just installed the anti-spam agents on is the only SMTP server in the organization, then we specify its IP address.

Figure 1.4: Specifying Internal SMTP Servers

If you want to add IP addresses without affecting any existing values, use the following cmdlet instead:
Set-TransportConfig -InternalSMTPServers @{Add="<IP 1>","<IP 2>"...}
Note:Even though the script will run without any errors on a CAS server, remember that you cannot enable the anti-spam agents on an Exchange 2013 Client Access server.
Managing all the anti-spam agents in Exchange 2013 is virtually unchanged from Exchange 2007 and 2010. The only difference is that the anti-spam settings are no longer configurable through an user interface – only the Shell can be used to configure and manage these agents.
As there are already a number of articles on MSExchange.org on how to do that, this article will focus on the new anti-malware features of Exchange 2013. For more information, please visit the Security & Message Hygiene section onMSExchange.org’s website.

Exchange 2013 vs Exchange Online Protection Anti-Spam

Although Exchange itself provides very good anti-spam capabilities, for more anti-spam features and easier management, organizations can purchase EOP from Microsoft, a cloud-based e-mail filtering service that helps organizations protecting against both spam and malware. EOP is typically used in three primary ways:

In a standalone scenario with EOP providing protection for the on-premises Exchange 2013 environment, legacy Exchange versions or for any other on-premises SMTP e-mail solution;
As part of Microsoft Exchange Online with EOP protecting Exchange Online cloud-hosted mailboxes;
In a hybrid deployment with EOP protecting the messaging environment and controlling mail routing when there is a mix of on-premises and cloud mailboxes.

The following are benefits of using EOP versus Exchange 2013:

Easier configuration: administrators can use the Exchange Administration Center console to customize spam filtering settings. There is no anti-spam user interface in Exchange 2013;
Stronger connection filtering: in Exchange 2013, connection filtering IP Block/Allow lists are available only through an Exchange 2007/2010 Edge Transport server. EOP uses Microsoft’s own block/allow lists aggregated from vendors to provide greater IP-level filtering;
Stronger content filtering: with EOP, administrators can easily configure content filter policies to:

Filter messages written in specific languages;
Filter messages sent from specific countries or regions;
Mark bulk e-mail messages as spam;
Search for attributes in a message and act upon the message if it matches a specific advanced spam option attribute. Some of these options offer a combination of Sender ID and Sender Policy Framework (SPF) technologies to authenticate and verify that messages are not spoofed.

Quicker updates: spam updates are propagated more quickly across the network. In Exchange 2013 updates occur two times per month, whereas the service is updated multiple times per hour;
Outbound filtering: outbound spam filtering is always enabled when using EOP for sending outbound e-mail to protect organizations using the service and their intended recipients.

Conclusion

In the first part of this article series, we had a quick look at anti-spam in Exchange 2013 and how it is practically unchanged from Exchange 2007 and 2010. In the next article we will explore the new features surrounding anti-malware protection in Exchange 2013.

Anti-Spam and Anti-Malware Protection in Exchange 2013 (Part1)

Inscription à : Articles ( Atom )

In this third and last part of the article, we will explore Policy Tips, test these policies and look at all the information that DLP logs.

Policy Tips

Testing DLP Policies

Exchange 2013 Data Loss Prevention (Part 3)

Forefront Protection for Exchange (FPE) vs. Exchange 2013

Enabling, Disabling and Bypassing Malware Filtering

Disabling Malware Filtering

Bypassing Malware Filtering

Engine and Definition Updates

Rescan E-mails Already Scanned by EOP

Conclusion

Anti-Spam and Anti-Malware Protection in Exchange 2013 (Part 2)

Introduction

Anti-Spam in Exchange 2013

Anti-Spam Mailbox Agents

Anti-Spam Legacy Edge Transport Agents

Enabling Anti-Spam Agents

Exchange 2013 vs Exchange Online Protection Anti-Spam

Conclusion

Anti-Spam and Anti-Malware Protection in Exchange 2013 (Part1)

Labels

Popular Posts