Beyond the base FAM features, there are two additional functions to consider, depending on your requirements. We expect these to eventually join the base feature set, but for now they aren’t consistent across the available products.
Activity Blocking (Firewall)
As with many areas of security, once you start getting alerts and reports of incidents ranging from minor accidents to major breaches, you might find yourself wishing you could actually block the incident instead of merely seeing an alert.
That’s where activity blocking comes into place – some vendors call this a ‘firewall’ function. Using the same kinds of policies developed for activity analysis and alerts, you can choose to block based on various criteria. Blocking may take one of several different forms:
- Inline blocking, if the FAM server or appliance is between the user and the file. The tool normally runs in bridge mode, so it can selectively drop requests.
- Agent-based blocking, when the FAM is not inline – instead an agent terminates the connection.
- Permission-based blocking, where file permissions are changed to prevent the user’s access in real time. This might be used, for example, to block activity on systems lacking a local agent or inline protection.
Those three techniques are on the market today. The following methods are used in similar products and may show up in future updates to existing tools:
- TCP RESET is a technique of “killing” a network session by injecting a “bad” packet. We’ve seen this in some DLP products, and while it has many faults, it does allow real-time blocking without an inline device, and does not require a local agent or the ability to perform permission changes.
- Management system integration for document management systems. Some provide APIs for blocking, and others provide plugin mechanisms which can provide this functionality.
All blocking tools support both alert and block policies. You could, for example, send an alert when a user copies a certain number of files out of a sensitive directory in a time period, followed by blocking at a higher threshold.
DLP Integration
Data Loss Prevention plays a related role in data security by helping identify, monitor, and protect based on deep content analysis. There are cases where it makes sense to combine DLP and FAM, even though they both provide benefits on their own.
The most obvious option for integration is to use DLP to locate sensitive information and pass it to FAM; the FAM system can then confirm permissions are appropriate and dynamically create FAM policies based on the sensitivity of the content. A core function of DLP is its ability to identify files in repositories which match content-based polices – we call this content discovery, and it is not available in FAM products.
Here’s how it might work:
- FAM is installed with policies that don’t require knowledge of the content.
- DLP scans FAM-protected repositories to identify sensitive information, such as Social Security Numbers inside files.
- DLP passes the scan results to FAM, which now has a list of files containing SSNs.
- FAM checks permissions for the received files, compares them against its policies for files containing Social Security Numbers, and applies corrective actions to comply with policy (e.g., removing permissions for users not authorized to access SSNs).
- FAM applies an SSN alerting policy to the repository or directory/file.
This is all done via direct integration or within a single product (at least one DLP tool includes basic FAM).
Even if you don’t have integration today, you can handle this manually by establishing content-driven policies within your FAM tool, and manually applying them based on reports from your DLP product.
Comments