FAM is a relatively new technology, but we already see the emergence of consistent architectural models. The key components are a central management server, sensors, and connectors to the directory infrastructure.

Central Management Server

The core function of FAM is to monitor user activity on file repositories. While simple conceptually, this information is only sometimes available natively from the repository, and enterprises store their sensitive documents and files using a variety of different technologies.

This leads to three main deployment options – each of which starts with a central management server or appliance:

  • Single Server/Appliance: A single server or appliance serves as both the sensor/collection point and management console. This configuration is typically used for smaller deployments and when installing collection agents isn’t possible.
  • Two-tier Architecture: This is a central management server and remote collection points/sensors. The central server may or may not monitor directly; but either way it aggregates information from remote systems, manages policies, and generates alerts. The remote collectors may use any of the collection techniques we will discuss later, and always feed data back to the central server.
  • Hierarchical Architecture: Collection points/sensors aggregate to business-level or geographically distributed management servers, which in turn report to an enterprise management server. Hierarchical deployments are best suited for large enterprises which may have different business unit or geographic needs. They can also be configured to only pass certain kinds of data between tiers, in order to handle large volumes of information, to support privacy by unit or geography, and to support different policy requirements.

Whichever deployment architecture you choose, the central server aggregates all collected data (except deliberately excluded data), performs policy-based alerting, and manages reporting and workflow.

The server itself may be available in one of three flavors (or for hierarchical deployments, a combination of the three):

  1. Dedicated appliance
  2. Software/server
  3. Virtual appliance

Which flavors are available depends on the vendor, but most offer at least one native option (appliance/software) and a virtual appliance.

If the product supports blocking this usually handled by configuring it as a transparent bridge or in the server agent (which we will discuss about in a moment). We will discuss the central server functions in a later post.

Sensors

The next component is the sensors used to collect activity. Remember that this is a data-center oriented technology, so we focus on the file repositories, not the file access points (endpoints). There are three primary homes for files:

  1. Server-based file shares (Windows and UNIX/Linux)
  2. Network Attached Storage (NAS)
  3. Document Management Systems (including SharePoint)

SANs are generally accessed through servers attached to a controller/logical unit or document management systems, so FAM systems focus on the file server/DMS and ignore the storage backend.

FAM tools use one of three options to handle all these technologies:

  1. Network monitoring: Passive monitoring of the network outside the repository, which may be done in bridge mode or in parallel, by sniffing at a SPAN or mirror port on the local network segment. The FAM sensor or server/appliance only sniffs for relevant traffic (typically the CIFS protocol, and possibly others like WebDAV).
  2. Server agent: This is an operating system-specific agent that monitors file access on the server (usually Windows or UNIX/Linux). The agent does the monitoring directly, and does not rely on native OS audit logs.
  3. Application integration: Certain NAS products and document management systems support native auditing well beyond what’s normally provided by operating systems. In these cases, the FAM product may integrate via an agent, extension, or administrative API.

The role of the sensor is to collect activity information: who accessed the file, what they did with them (open, delete, etc.), and when. The sensor should also track important information such as permission changes.

Directory Integration

This is technically a function of the central management server, but may involve plugins or agents to communicate with directory servers.

Directory integration is one of the most important functions of a File Activity Monitor. Without it the collected activity isn’t nearly as valuable. As you’ll see when we talk about the different functions of the technology, one of the most useful is the ability to manage user entitlements and scan for things like excessive permissions.

You can assume Active Directory is supported, and likely LDAP, but if you have an unusual directory server, be sure to check with the vendor before buying any FAM products.

Roles and permissions change on a constant basis, so it’s important for this data flow to happen as close to real time as possible so the FAM tool knows, at all times, the actual group/role status of users.

Capturing Access Controls (File Permissions)

Although this isn’t a separate architecture component, all File Activity Monitors are able to capture and analyze existing file permissions (something else we will discuss later).

This is done by granting administrator or file owner permissions to the FAM server or sensor, which then captures file permissions and sends them back to the management server. Changes are then synchronized in real time through monitoring, and in some cases the FAM is used to manage future privilege changes.

That’s it for the base architecture; in our next post we’ll start talking about all the nifty features that run on these components.

Share: