Transition File Blocking Profiles Safely to Best Practices
Apply File Blocking profiles to allow rules to protect
against risky file types used in malware campaigns without risking
application availability.
The following guidance helps determine whether to start with block or alert actions
as you define the initial File Blocking profiles and begin the transition to best
practice profiles. Alert instead of allowing file types to generate logs and gain
visibility into the traffic.
Best practices File Blocking profiles are often different for different types of applications and
might be different for inbound, outbound, and internal traffic. For example:
If
internal applications depend on file type transfers that the best
practice File Blocking profile recommends blocking, allow those
file types for those internal applications; .dll files are a good
example. Allow those file transfer types only for the necessary
internal applications, not for all applications.
For internet-based traffic, take a more restrictive approach
to prevent attackers from delivering malicious files and to reduce
the attack surface.
For data center traffic, take a more restrictive approach (except for internal applications that
depend on file transfer types that you would otherwise block) to reduce
the attack surface and protect your most valuable assets.
When you carve out exceptions, follow the principle of least
privilege and apply the exceptions only to the applications and
users and that need access to the file type for business purposes.
Business-critical applications
—Start with the alert action for all file types and move to
best practices File Blocking profiles as
soon as possible. If you already have blocking controls in place, replicate them
and continue to block traffic that you already know you want to block.
For applications that aren't business-critical, start the transition to a best practices File
Blocking profile:
Inbound
and outbound traffic
—Set the
Action
to
block
for
7z, bat, chm, class, cpl, dll, dlp, hta, jar, ocx, pif, scr, torrent,
vbe, and wsf files. Set the
Action
to
alert
for
all other files.
Internal traffic
—Block 7z, bat, chm, class, cpl, dlp,
hta, jar, ocx, pif, scr, torrent, vbe, and wsf files (this is the
same as the inbound/outbound profile except it alerts on .dll files
instead of blocking them). Alert on all other files.
Block all of the following file types you can for users who don’t need them for business
purposes: cab, exe, flash, msi, Multi-Level-Encoding, PE, rar, tar,
encrypted-rar, and encrypted-zip.
If necessary, create exceptions for IT groups and others
who need legitimate business access to any of these file types.
If you already block any other file types, continue to block them.
Transition
to a best practices File Blocking profile as quickly as you are
comfortable with doing so.
Fine-tune profile rules that alert and transition them to blocking as soon as you
comfortably can, especially for internet-facing and data center traffic. Monitor the
Data Filtering logs (
Monitor
Logs
Data Filtering
) to understand file type usage before configuring block actions for
specific file types. As you learn which file types your business-critical and internal
custom applications require, transition toward a best practice File Blocking
configuration, modified as necessary to support your business needs.