A Q & A on etting technical criteria for monitoring outbound content.
Yet another term describing products that monitor the transmission of data out of your network is "Exfiltration Detection System" (EDS). This term is predominantly used in the military, but it is the most explanatory in use today for this class of products.
EDS wares are supposed to detect violations of regulatory, legal or corporate data-transmission rules. If they work properly, people will get reprimanded at best and prosecuted at worst. Therefore, they must stand up under microscopic scrutiny to influence the jury if the situation warrants it.
Because the consequences of EDS monitoring can be grave, the technology must be carefully examined before deployment to make sure the information it provides is completely accurate. Before you buy, be sure you drill the vendors hard on how the following issues would impact the validity of a claimed policy violation. If you don't, the witness chair could well become your own hot seat.
1.) What is the scope of detection?
Find out what kinds of data the EDS detects. Ask for documentation on the types of protocols, data formats and data format combinations the EDS supports. You need to have this as separate documentation, not just an online help screen, so you can show an auditor or external authority in hard copy. If you don't have this information in hand, you can't make a verifiable claim as to what sort of information is monitored over time.
2.) What is the measurable efficacy?
How effective is the EDS at detecting violations? Is the level of efficacy consistent with your requirements? If the product claims to detect U.S. vehicle driver's license numbers, does it cover all 50 states? If it claims to detect Social Security numbers, does it report a false positive when 000-00-0000 is transmitted? Make sure you have a clear description of what it will detect, and make sure it can be tested during maintenance or an audit.
Be careful of tunable parameters. If an EDS can detect leakage of credit card numbers, make sure you know when it will report the leakage. If it waits for 200 or more credit cards to leak and you thought it would report every individual violation, you are not really protecting the information as you claimed.
Check the efficacy before you look at performance or blocking capabilities, because if a product can't detect things, it doesn't matter how well it is at blocking. And if it can't detect properly at low speeds, then there is no point in attempting to deploy it in a high performance environment.
3.) How is the EDS managed?
An EDS, like any other critical infrastructure device, must be manageable in a sound and secure manner. Perhaps, because of the possible implications of the EDS output, it is even of higher importance here. The management interface should be secured, using SSL or Secure Shell or some sort of encryption mechanism that cannot be compromised by an impostor. Self-signed digital certificates are not sufficient, because a man-in-the-middle attack can be used to compromise the administrator account and allow an attacker to modify the EDS configuration to allow illegitimate traffic to get through, and you cannot assure that administrator access to the EDS is controlled properly.
Managing the device in any way (especially to configure policies) should automatically generate an audit trail so you can prove you have records on when and what changes are made to the detected policies. If you cannot prove who administers the box and when, you cannot prove you have firm control over the detection process and that would make all reported violations suspect.
In addition, because EDSs are often used by staff from different groups (network administration, compliance administration, policy-enforcement administration), there should be some sort of role-based administration mechanism. And if you use an EDS to comply with business requirements from major corporations, you probably need to have access to some sort of two-factor authentication mechanism for administrator access.
Like all other network devices, the EDS should be delivered with genuine management documentation, separate from the device, so that a sound operations process can be set up to train user/operators and provide for ongoing EDS administration. Fragmentary online help text that must be printed page by page from a Web browser is not product-grade documentation.
4.) What are the environmental requirements?
Ask what assumptions are made about the network environment in which the EDS operates. For example, if the vendor does not detect DNS traffic because there is an assumption that User Datagram Protocol () traffic never leaves the monitored network, this should be explained in the documentation, so you can deploy the product properly and show that the vendor-recommended network environment is in place. If the EDS assumes an administrator can access the public Internet while using the management interface, this should be documented so that adequate precautions are taken in case the administrator is running on a management subnet that generally is assumed to not be attached to the public Internet. If the EDS product is designed for use by a "compliance officer" and the vendor expects that person to be nontechnical, make sure there is a safe environment so that the administrator does not become a target of viruses or other attacks via the EDS.
5.) What are the infrastructure requirements?
An EDS is deployed on a network at a point where some significant amount of the network's traffic can be monitored, similar to the placement of an . This typically means it has a tap at the outside edge of the network. When combined with a management network interface for administrator access, the EDS is certainly sited at a sensitive point in the network. Ask the vendor what kind of infrastructure access the EDS needs where it is sitting on the network. If it uses a back-end database make sure there is the capability to adequately secure the connection. If it uses an administrator-class account to monitor data on production file servers, this means that administrator credentials are being used from near the edge of the network. This may well be a violation of the security policy for the production systems, because a compromise of the EDS would imply a compromise of the production systems. Additionally, you need to ask how adding an EDS to your network changes the attack surface. It should not make it less secure by increasing the risk from attack of an individual component.
6.) What is the event workflow?
You need to understand what happens when a policy violation is detected. Remember that whatever information is generated may be used in environments where its validity could be questioned. The event information should be secured to maintain chain of control in case it is considered evidence. External logging with appropriate security measures should be available or else the information generated by the EDS could be declared invalid. All the steps in the workflow of a detected event should be examined to ensure the information is handled properly and the EDS was provably operated in the intended manner.
Deployment of an EDS is similar to deploying other critical infrastructure components. There are risks as well as benefits. It is critical that the solution you choose provide reliable and accurate information, not only because it's part of your network, but because if the EDS finds something, it might mean someone gets fired, or goes to jail, possibly even upper management. The stakes are too high to treat deployment casually.