According to the DLP market overview by Gartner [EQM07], the Websense Data Security Suite was one of the leading DLP solutions already in 2007. Nevertheless, it just provided network monitoring and discovery functionalities. Since an end- point agent was added in 2008, it is a suitable completion to the DLP newcomer McAfee. Central management both of policies and client administration is realized by standalone or web applications.
Like the McAfee Host Data Loss Prevention, the Data Security Suite monitors all removable storage media so that the same set of testcases can be applied.
4.3.1 Environment And Specifications
Regarding only the functionality relevant to endpoint protection, the Websense Data Security Suite includes the following components:
• DSS Server • Endpoint Agent
Figure 14: Architecture of the Websense Data Security Suite
The DSS Server is the central management and analysis component. Additionally it provides log files, statistics and stored incidents. To ensure the availability of this core system, it is possible to operate multiple instances of it – in this case, one of them must be the master DSS Server. Figure 14 shows the basic interaction between the single components. In contrast to the McAfee Host Data Leakage Prevention, the Websense solution installs its own database server per default. It is possible to define an existing database server, but since there is no need for a dedicated installation it is not listed in Figure 14. The DSS Server itself is divided into three tools:
• DSS Manager
• Management Console • Policy Wizard
The DSS Manager provides a frontend to access both analysis data and global configuration settings. There is detailed data on each incidents, statistics and time lines. Additionally it is possible to configure endpoint and server agents at this single point. The policies which define valuable data and adequate reaction rules can be created using the Management Console as well as users and roles can be administered. There are also a lot of predefined policies which protect classes of data which are very valuable in a country specific meaning. For example there is
Figure 15: The file containing the filtered string is blocked.
a policy which protects social security numbers which are used in the USA. These policies can be accessed via the Policy Manager.
4.3.2 Testcases
To make a statement about the security of the two DLP solutions, it is necessary to have a direct comparison. Since the two solutions can address the same leakage vector and use similar protection methods, the same testcases as for the McAfee solution were applied (Table 2). This comparison allows a more substantiated conclusion on the overall security and maturity of DLP solutions.
4.3.3 Results
The performed tests resulted in different findings which are listed in the remainder of this section. Again, the same challenge as for the McAfee Host Data Loss Pre- vention was used: A policy that should avoid the copying of files which contained the string SECRET to USB media was deployed to an endpoint agent. To ensure the correct functionality, a PDF document containing the defined string was copied to an USB stick. As Figure 15 shows and the policy dictates, the file is blocked. The mentioned tests were performed using this test environment. The results are listed below and are divided in the categories identify, monitor, react and system security.
Figure 16: A PDF document without its first line is not recognized.
Identify
To ensure the correct processing of different file types and file operations, a PDF document containing the string SECRET was copied to an USB stick and the detection worked correctly: The file was blocked. Again, the next test was the copying of the same file after its first line was removed. This small change was enough to circumvent the DLP solution and the file was copied successfully to the USB stick as Figure 16 shows. This test controls the inspection of files for their mime type. Since also the McAfee DLP solution did not recognize this file without the mime type information, the same PNG file containing the EXIF comment SECRET was copied to the USB stick. This time, the Websense Data Security Suite did not block the copying as Figure 17 shows.
Monitor
The system monitors all tested channels correctly. For example both NTFS al- ternate data streams and the Linux ext3 filesystem were monitored and every information breach was detected. But a test of the stability of the application failed: During the copying of a 5 GB file filled with random data – which con- tained also the string SECRET – to an USB hard disk, the complete operating system freezed in all three test runs. Without the endpoint agent running, this process completed without any problems. In the worst case, this system freeze could be a hint that any kind of an overrun in the agent software exists. Depend- ing on the kind of overrun, this could mean that this vulnerability is exploitable by an attacker. Otherwise this only affects the availability of the system.
Figure 17: EXIF comments in images are not recognized.
React
Per default, the communication between the endpoint agents and the DSS server is handled using HTTPS which implicitly means that every communication is en- crypted. This encryption can be turned off so that it was possible to analyze the communication protocol. The following listing shows the plain text communica- tion – without its HTTP header information to improve readability – that happens when the endpoint agent registers at the server after each start:
Request (client to server):
CPS_CLIENT4626415283943780173|xp-template|N/A|N/A| .K|....
Response (server to client):
CPS_CLIENT4626415283943780173|78|.XaO.... ...M.e.s.s.a.g.e. .w.a.s. .h.a.n.d.l.e.d. .s.u.c.c.e.s.s.f.u.l.l.y...
This protocol is vulnerable to at least one attack. An attacker is able to inter- cept the traffic from the client to the server and vice versa (Appendix C.5). If this happens, the attacker can drop the requests from the client to the server and reply arbitrary answers to the client. The complete response of the Server is predictable: CPS CLIENT4626415283943780173: Can be extracted from the Client re-
quest
78: Answer code which stands for Message was handled successfully. There are also other message codes like Incident was handled successfully
Message body: Derives from the answer code.
Thus an attacker can intercept the reporting of an incident, drop the request and send the answer Incident was handled successfully to the client. The reporting of incidents would never reach the server and thus would never been reported.
It could also be possible that an attacker is able to inject faked messages into the incident reporting system. It was not possible to replay an initial registration request of the client. But since there is no additional client verification using, for example, certificates, the session id (in the example above: CPS CLIENT4626- 415283943780173 ) is generated only on client side. This means that the server has no possibility to prove the identity of the client. If an attacker gets access to the data on the client system, he has access to all data the endpoint agent can use to generate the session id following a certain algorithm. It could be possible that an attacker explores this algorithm – since every data and program code for this algorithm is resided on client side – and is then able to generate valid session ids.
System Security
As mentioned in Section 4.3.3, the communication between the endpoint agent and the DSS server is encrypted due to the use of HTTPS. HTTPS is based on SSL which in turn uses certificates for the authentication of the two stations. Since the Websense Data Security Suite uses a certificate only on server side, the client is not authenticated. Additionally, the client does not verify whether the server’s certificate is valid. Thus an attacker is able to perform an SSL man in the middle attack which is described in Appendix C.5. This results in the decryption of the protocol and this in turn in the disclosure of sensible data. Since only data that is judged to match the policy – which is the valuable data – is sent, this actually adds an additional vector for data leakage.
4.4
Summary
The findings from Sections 4.2.3 and 4.3.3 show that the DLP solutions are not yet matured, even considering the fact that the Websense Data Security Suite is one of the leading solutions in this field.
There were far too many possibilities for even accidental leakage (e.g. the copying of data to one of the unmonitored partitions of an USB hard drive) in the McAfee Host Data Leakage Prevention that it would be dangerous to rely on the system as a part of the security concept. And even if the scan engine of the Websense solution may be able to avoid accidental leakage, it introduces an additional leakage vector to the network due to the lack of mutual authentication. These findings are summarized in Table 3 to provide a fast overview on the capabilities of the solutions. If the solution passed a test, a check mark (“X”) is used, otherwise a “X” takes place.
Test McAfee Websense Text file containing SECRET X X
Text file named SECRET X X
PDF document containing SECRET X X Word file with embedded Excel table X X Zipped Word file with embedded Excel table X X PDF document without mime type information X X
EXIF comment X X
NTFS alternate data streams X X Third party filesystem (ext3) X X Multiple partitions on USB hard drive X X
Blocking of valuable data / Secure deletion X X
Proper encryption of management communication X X
Proper Encryption of reported incidents X X
Fuzzing X X Handling of big files X X
Table 3: Performed testcases for McAfee Host Data Leakage Prevention and Websense Data Security Suite
5
Abstraction To General Problems And Con-
clusions
The results of the evaluation allow the drawing of several conclusions. In a first step, it is possible to abstract the problems found in the DLP solutions to general problems of the DLP approach which are summarized in Section 5.1. The next step is the discussion of alternate solutions which can also prevent data breaches, in Section 5.2. These solutions point out advantages and disadvantages of other approaches. It also discusses typical security tools like patch management and data classification which are not yet deployed in most environments.
5.1
General Problems
The different discovered vulnerabilities show that also software which should im- prove security needs lot of administration and development to be regarded as se- cure. So it is obvious that the costs to operate lot of security solutions – especially in a secure way – can easily exceed the available manpower. At the same time this manpower is missed at other tasks which are necessary to operate networks and systems in a secure way – what includes lot more assignments than administering security software. These circumstances can also lead to a loss of availability if the newly deployed DLP solution is misunderstood due to a lack of time. During the test phase of the McAfee DLP solution, a check was misplaced due to similarly sounding configuration options. This lead to the complete block of USB devices on all clients instead of blocking only the data which matched the policy. If this had happened in an operative environment, it would mean a huge loss of availability on either information or the access on USB storage. So it is essential to realize that the protection of one security goal probably affects the security level of another requirement. In many cases this can be avoided by acting carefully or using other controls, but often a few implications arise like the blocking of false positives in the DLP context.
These implications result from the high level of complexity of DLP solutions. To achieve the claim to block all confidential data in every possible state and medium, a lot of new software needs to be deployed – endpoint agents, event collector services, plugins in every network node and so on. This mass of necessary changes affects the overall complexity of the network in a risky way. Since complexity is the biggest enemy of realistic and long-run security [Sch00], the deployment of such an extensive solution must be planned and tested extremely carefully. To use any technology in a safe way it is necessary to understand the solution. Again, the high level of complexity may avoid deeper understanding of the different controls and concepts.
Any operative problem can be reduced if the product can be understood, but the big codebase for achieving the claimed features is still a problem. Every line of
code raises the probability of the existence of software bugs [Ber07] – bugs in general and security flaws in particular – which can both affect the safety and security of the system. This is true just as well for software which is to ensure security and so should be built with security in mind. Appendix B provides lots of examples of security tools which contain just as many bugs as all other software, so the initial statement keeps its validity. There is a high chance that further investigation will reveal lots of vulnerabilities which can even lead to system compromises in most of the DLP solutions [MM07]. And even if no security holes are discovered, the reporting of incidents can lead to a kind of denial of service attacks. If an attacker starts to generate notifications by accessing certain files, it is possible to trick the administrators into re-adjusting the notification policy. This can lead to decreasing attention concerning the DLP reports. If there are lot of notifications that remind the user that he is accessing valuable data, the user might get frustrated and also disregard the notification. The resulting nonacceptance might also allow scenarios like printing mistakes. If a user prints a sensible document by mistake and throws it to the paper basket, the information is not covered anymore by any DLP solution due to nonacceptance or habit. Even if a DLP solution could help by showing up a warning message, it is questionable whether awareness courses would not have been more efficient.
Similar scenarios arise from insider threats. The Data Breach Investigations Report [BHV08] shows that 50% of all information leakage caused by insider threats are conducted by administrators. These people have access to almost every data since they have to administer it. Additionally, they know how a deployed DLP solution works and are able to disable or bypass it.
By disregarding the reports – due to a lack of time, too much reports or careless- ness – the DLP solution loses lots of its benefit. Thus the overall system security can be decreased by implementing an arbitrary DLP solution just for feeling more secure. This is actually kind of a reactive approach: Regarding popular examples of data breaches, there are still many incidents which occur due to classical software vulnerabilities, inappropriate configuration or weak passwords. So the deployment of a DLP solution should be thoroughly reviewed if the reason for the deployment is a particular data breach. As always the reasons and circumstances of the leakage must be regarded to define a reasonable learned lesson. Based on this procedure, the further steps for closing the gap can be determined without blindly applying arbitrary security controls without understanding them.