Improving DLP system security

(1)

Faculty of Computing

Blekinge Institute of Technology SE-371 79 Karlskrona Sweden

Improving DLP system security

Sara Ghorbanian and Glenn Fryklund

(2)

i i

partial fulfillment of the requirements for the degree of Master of Science in Engineering. The thesis is equivalent to 20 weeks of full time studies.

Contact Information:

Author(s):

Sara Ghorbanian

E-mail: sagh09@student.bth.se

Glenn Fryklund

Email: glfr09@student.bth.se

External advisor:

Peter Bayer DinGard AB

University advisor:

Stefan Axelsson

Dept. Computer Science & Engineering

Faculty of Computing

Blekinge Institute of Technology SE-371 79 Karlskrona, Sweden

Internet : www.bth.se Phone : +46 455 38 50 00 Fax : +46 455 38 50 57

(3)

Context. Data leakage prevention (DLP), a system designed to prevent leakage and loss of secret sensitive data and at the same time not affect employees workflow. The aim is to have a system covering every possible leakage point that exist. Even if these are covered, there are ways of hiding information such as obfuscating a zip archive within an image file, detecting this hidden information and preventing it from leaking is a difficult task. Companies pay a great deal for these solutions and yet, as we uncover, the information is not safe.

Objectives. In this thesis we evaluate four different existing types of DLP systems out on the market today, disclosing their weaknesses and found ways of improving their security.

Methods. The four DLP systems tested in this study cover agentless, agent based, hybrids and regular expression DLP tools. The test cases simulate potential leakage points via every day used file transfer applications and media such as USB, Skype, email, etc.

Results. We present a hypothetical solution in order to amend these weaknesses and to improve the efficiency of DLP systems today. In addition to these evaluations and experiments, a complementing proof of concept solution has been developed that can be integrated with other DLP solutions.

Conclusions. We conclude that the exisiting DLP systems are still in need of improvement, none of the tested DLP solutions fully covered the possible leakage points that could exist in the corporate world.

There is a need for continued evaluation of DLP systems, aspects and leakage points not covered in this thesis as well as a follow up on our suggested solution.

Keywords: Data leakage prevention (DLP), API hooking, agent based, agentless.

i

(4)

3.1 Applications for Windows in My Endpoint Protector . . . 19

3.2 Applications for Mac OS in My Endpoint Protector . . . 19

4.1 Test results from clean install . . . 27

4.2 Test results from disabled agent . . . 28

4.3 Test results from disconnected DLP server . . . 28

4.4 Conceptual illustration of the implemented solution . . . 32

5.1 Results of combining My Endpoint Protector and MyDLP . . . . 35

5.2 Results of combining My Endpoint Protector and MyDLP with disabled agent . . . 35

5.3 Results of combining My Endpoint Protector and MyDLP with disabled connection to DLP server . . . 36

A.1 Clean install results . . . 44

B.1 Disabled agent . . . 45

C.1 Disconnected server results . . . 46

ii

(5)

2.1 Test Cases . . . 17

4.1 Summary of results from Figure 4.1 . . . 27

5.1 Summary of the combined My Endpoint Protector and MyDLP solution . . . 36

5.2 Hypothetical combination: Difference in percentage. . . 37

iii

(6)

Abstract i

1 Introduction 1

1.1 Definitions . . . 2

1.2 Background . . . 4

1.3 How DLP systems work . . . 5

1.3.1 Agent based . . . 5

1.3.2 Agentless . . . 7

1.3.3 Hybrid . . . 9

1.4 Current Limitations . . . 10

1.5 Research question . . . 11

1.6 Related Work . . . 12

2 Method 14 2.1 Test Environment . . . 14

2.2 Tested DLP systems . . . 16

3 Evaluation of DLP products 18 3.1 The agent based solution - My Endpoint Protector . . . 18

3.1.1 Found problems and suggested improvements . . . 19

3.2 The agentless solution - Trustwave DLP . . . 21

3.3 The hybrid - MyDLP . . . 23

3.4 The file system scanning tool - OpenDLP . . . 25

4 Results 26 4.1 Test results . . . 26

4.2 Implemented solution . . . 30

4.2.1 API Hooking . . . 30

5 Analysis 34 5.1 Analysis of the hypothetical scenario . . . 34

5.2 Analysis of DLP solutions . . . 37

iv

(7)

6.2 Future work . . . 41

References 42

A Clean install 44

B Disabled Agent 45

C Disconnected server 46

v

(8)

Introduction

Credit card information and social security number of clients are examples of sensitive secret information that is very common in the corporate world, information that should be of limited use and should not be leaked or shared. An employee that is trying to email such information to a rival company is an example of leakage that can have devastating outcomes for a company such as losing clients, lead to legal cases, etc. To prevent this kind of leakage, systems dedicated to identify and protect sensitive data were introduced in 2006 [6] and became known as Data Leakage or Loss Prevention (DLP). Their purpose is to clog the existing leakage points and block unauthorized disclosure of confidential data.

Today there are many vendors with various DLP systems for different operating systems and mobile platforms. But limiting the access for employees to do their everyday work can cause irritation and frustration among some. This in turn can lead to employees trying to find ways to work around the system.

A recent real world example of the internal threats and how the DLP system still is in need of improvements is the data leakage of classified data regarding the NSA and its operations an employee at the US signals intelligence organisation NSA, Edward Snowden managed to perpetrate. Because he had a high level of privileges being an administrator, nothing prevented him from bending existing systems to allow him get ahold of data he should not without alerting anyone. An example that shows how the threat is current and the results can be devastating for the company targeted.

Scenario The purpose of this thesis is to gain an understanding in how the existing DLP systems on the market today work, their coverage, their weaknesses and what that can be done to improve these. This is done by testing four existing DLP systems and examining what leakage points they cover and if these systems can be tampered with.

Contribution Based on the results of our experiments in section 4.1, a proof of concept solution, using system call tracing, also called API hooking (see section 4.2.1), has been implemented and work as a complement to an existing DLP

1

(9)

system. This solution is based on the suggested improvements contributed to each of the tested DLP systems.

Outline We start by giving the relevant definitions, a background to DLP followed by what the needs are and a presentation of the different types of DLP systems that are on the market today. Thereafter we describe the research question of this thesis and summarize what has been done within the area of DLP.

In chapter 2 we present the research methods used in this thesis, followed by chapter 3, where an evaluation of the tested DLP system and the experiments is presented. In chapter 4 we give the results from the different experiments and our implemented solution. These results are then analysed in chapter 5 and compared to the existing solutions. The final chapter is Conclusion and future work, which is a summary of the conclusions made in this thesis and what can be done in the future within this area.

1.1 Definitions

As mentioned, DLP stands for Data Leakage or Loss Prevention, preventing sensitive data from being lost or leaked. A DLP system is designed mostly to defend against the company’s own staff, legitimate users that already have access to most of the internal systems and data. Users trusted to go through most of the system’s other protection and defence, which is needed in order for them to do their job efficiently [16]. Although the staff might not intentionally try to do anything harmful to the company, there are situations where that is not the case.

To put things into perspective, here are three examples of attackers that can be encountered within a company:

• Unintentional - The unknowingly employee that accidentally loses secret data outside of the company’s internal system – The ordinary user with no malicious intent.

• Misuse - The disgruntled employee who might try to leak secret information to a rival in order to get even with the company – The ordinary user with mischievous intent.

• Malicious - The agent from a rival that has infiltrated the company as one of the employees – A user who knows what information he or she is after and will do anything to get it.

If a malicious unauthorized user tries to hack his/her way in to the internal network, systems such as IDS, Intrusion Detection Systems, or IPS,Intrusion Prevention System are responsible for detecting and preventing this from hap- pening. Should the hacker manage to pass these systems the DLP system would

(10)

then treat this user as any other user within the internal network, block any data that is not allowed to leave. In other words, a DLP system is the opposite of both IPS and IDS, monitoring what is going out instead of coming in.

Any information stored on a hard drive or within a computer is considered data. DLP solutions often look at data in three different states [3]:

• Data In Motion (DIM) - Data that is currently being transferred from one location to another. This could be considered moving a file from one hard drive to another or even an email being sent across the Internet.

• Data In Use (DIU) - Data that is actively being used by any software.

Like a text document that has not necessarily been saved to the hard drive.

• Data At Rest (DAR) - Data that is stored on a hard drive and is not actively being used or transferred.

A DLP system is a set of rules, also referred to as policies and is a principle or protocol to guide decisions and achieve rational outcomes. [20]

These policies are set by the administrator and contain the rules for the network and the endpoints, what is allowed and what is not. These policies can be set on a specific application or a web page, anything that makes file transfer possible such as email, instant messaging or transfers to an external hard drive.

Different policies can also be set depending on what level of access the user has.

The more specific these policies are set, the less false positive and false negative alerts would be given from the DLP system, which would lead to a more accurate system.

DLP systems can be categorized into three types; agent based, agentless and hybrids:

• Agent based is software, an agent, installed on each endpoint, which is communicating with a DLP server that delegates the different policies [11].

• Agentless is one or more servers that monitors and analyses the network traffic and every endpoint is forced to have its traffic routed through this.

Nothing is installed on the endpoints.

• Hybrid is a combination of the above, an agent on each endpoint and monitoring servers.

Other definitions and explanations of terms used in this document:

There are different actions a DLP system can do, meaning what the DLP system should do to a particular file type or content. These actions can be to block, quarantine or do nothing and this depends on the policy set up by the administrator. The system can also log the events with information about who did it, when it happened, what it contained and what action that was taken.

(11)

A proxy is a server or a computer system that acts like a mediator between clients and other servers. It can also be used to monitor and filter the network traffic, both inbound and outbound [21].

File magic numbers are used to identify the format of a file by a number of bytes at the beginning of the file [18].

Signatures are a more complex way of identify the type or format of a file involves analysing the file for patterns other than file magic numbers that matches a certain type.

Another way of identifying a file type is by examining the MIME-type of the file. MIME stands for Multipurpose Internet Mail Extension and one example of a MIME-type is “application/zip”, which is for zip archive files [19].

HTTP/HTTPS, Hypertext Transfer Protocol (Secure) is a communication protocol used for surfing the web. HTTPS encrypts the network traffic and is mostly used on websites containing sensitive information such as usernames and passwords.

1.2 Background

The various DLP systems today offer mostly the same functionality within their system. Some of these functionalities can be to prohibit users from attaching a specific file type in an email, block and log whenever someone is trying to copy to clipboard or taking a print screen, or denying to print documents that contains a specific word, sentence, credit card number, etc. The system should allow an administrator to specify the policies with enough precision needed for their company while being easy to maintain.

Another important task both the administrator and the DLP system have is to inform the employees about what is allowed and what is not. Should an incident occur, accidentally or intentionally, the system should give a clear explanation of what happened and why that specific file was blocked. This could otherwise lead to frustration and repeated attempts of transferring the file.

One feature some existing DLP systems have is to detect where sensitive data is stored within the network with a file system scan. These scans iterate through all accessible files in the network and depending on the file performing an action according to active policies. These scans are very demanding on the system that is being scanned and is often schedulable so that they run while only a few are using the system.

Today there are many companies that provide DLP systems for all types of operating systems and mobile devices. Some are open source and other commercial where the company will either send a consultant to install and setup their product for you or sends the sources and software your company needs to install the system yourself. It is important to first identify what the assets are, what possible leakage points there are within the company and identify if there is any

(12)

existing system that could interfere with a DLP system before deciding which one suits best.

In reality, DLP solutions will have to be implemented and setup so that it can coexist and utilise already existing systems and data [15]. This means that a DLP system has to be tailored according to existing systems and not the other way around in order for it to be able to have a practical implementation.

1.3 How DLP systems work

Every DLP system today differ in some way how they approach the data leakage problem, but many essential parts remain similar. Most DLP systems have predefined content dictionaries that contain words such as “Confidential”, “Secret”,

"Credit Card Number/Information”, etc. They also come with dictionaries with credit card number patterns for the different manufactures such as Visa, Master Card, American express. The DLP system scans the files to be transferred and if there are numbers matching any of these patterns, it will mark this as a credit card number. As mentioned, depending on the policy set for this type of event, the DLP system will perform the defined action.

Some also has the ability to do a specific action to certain file types such as either by blocking the file extension or examining the MIME-type of the file. If the latter is performed, it would still be solid if the extension is changed. If a file is changed from Smile.png to Smile.txt, the system would still recognize this file as an image and not a textfile due to the MIME-type examination.

As mentioned earlier, there are three types of DLP systems today, agent based, agentless and hybrids. This section will give a more detailed description of how the different types work and their limitations.

1.3.1 Agent based

An agent based DLP system is where every endpoint has an agent installed which is managed from a central server where the administrators set up all policies based on how data is allowed to be managed. In order for this to be effective the solution must be able to manage the following issues:

(13)

Compatibility, the agent must not just be able to run on every potential endpoint but also be configured/adapted for every endpoint. Endpoints vary in how they can be used, different operating systems offers different features, which may or may not be potential causes for data leakage.

Correct configuration, administrators must set up precise and detailed policies and the central server must be offering the means to create these.

This means that policies must be able to cover:

• All possible context data could be in, ranging from being sent as an attachment in an email to being printed out on a local or a network printer.

• All possible types of data. Today the most common data can be categorized into different types of data. An example of such cat- egorization, data associated with the file “grammar.docx” could be categorized as a word document. Being able to cover data based of their type can make it easier when creating policies to define a larger amount of data that should be covered.

• Actual content contained within files. While it is possible to classify most of the data, it would not be enough precision when implement- ing policies. Relying only on data types will cause a lot of false positives and could prevent ordinary data from being sent or ending up with false negatives since there are ways to bend the rules of classification.

• An administrator should be able to add file size as an attribute. An example of why this is important is blocking known image file types could lead to a word file being blocked because of a thumbnail.

If administrators cannot create rules/policies to cover all of their scenar- ios, the system will fail to prevent sensitive/secret data from leaking or blocking non-sensitive ordinary data.

Connection to central server, the agent must be able to establish a secure connection to the central server and verify the identity of it. An encrypted connection to the central server is essential since it will be used to send logs and policies, which contain information regarding the data that is being protected. Also ensuring that the central server is whom it claims is vital in order to prevent a man-in-the-middle attack where someone would set up their own fake server in order to manipulate the policies or intercept logs.

(14)

Running in an unsecure environment, the agent will need to run on endpoints such as laptops where ordinary users might have high, if not, full level of privileges. This means the agent needs to be aware and able to protect itself from both intentional and unintentional manipulation.

This can be everything from tampering with binaries or configuration files critical for the agent to work, to attempts of uninstalling the agent or preventing it from accessing data, ports or even establishing connection with the central server. As administrator the user would be able to disable the agent from connecting to the server by setting up a firewall rule to prevent any connection to or from the central server. Another way of disabling the agent would be to stop the service from running through the task manager and only allowing it to start manually.

Report/log to both administrators and users The agent must be able to send logs to its server in case of an incident and also inform the user of the reason why it blocked the file. It is also important for the agent to log events even if the connection to the DLP server has been lost for some reason. The logs should be sent as soon as the connection has been re-established and the agent must be able to protect these logs from being tampered with locally on the endpoint.

1.3.2 Agentless

Agentless is another type of DLP solution where there is no need to install software on the endpoints. Instead this solution revolves around having one or more servers established in the network where all network traffic is routed through. This eliminates problems like coverage to some degree and it allows the critical parts of the solution to run in an environment easier to secure compared to an agent based solution. It makes the protection more transparent and integrates quite easy with existing technology. But there are still some important aspects:

(15)

Complete coverage

While the machine is within the network, all the network traffic routed through the DLP server can be monitored and managed. The technique here is the use of a proxy server, which is a server that mediates the traffic between a sender and a receiver, combined with a content filter that throws away any traffic containing data that is considered sensitive. There are ways to ensure that all traffic has been analysed by the DLP solution before leaving the network and the most effective way to accomplish this is to set rules at the node facing out of your network to only allow outgoing traffic from the DLP server(s). This prevents any traffic, not originating from a DLP server, to leave the network. However this solution does not have any means of preventing an endpoint from leaving the network or bypassing the DLP server by reconfiguring the proxy settings.

Beyond the issue of devices leaving the network there is also all the other types of media that data could potentially be leaked/transported through.

An agentless solution have no direct way of controlling what data is being transported onto portable USB devices, burned to a CD/DVD or even printed as an agent based solution has. This has to be considered before choosing an agentless DLP system.

SSL/HTTPS connections, any communication using a protocol that encrypts the data being sent is a big problem for the agentless DLP. These protocols are designed to have data encrypted from the moment it leaves the source until it is received at the intended destination, which makes it impossible for a DLP server to analyse the data being sent. However, there are techniques for a DLP server, despite the use of protocol such as SSL/HTTPS, being able to analyse the data. When a client first tries to establish a connection it sends some data to request the set up of an encrypted connection. By intercepting this request the DLP server can pretend to be the receiver towards the client, meanwhile it establishes its own connection towards the real receiver. Allowing the DLP server to act as a middle man that can inspect the traffic being sent between the client and the real server.

(16)

Correct configuration Just like agent based solutions you must have proper policies set up by administrators and the DLP server must offering the means to create these. The more detailed the policies are defined, the better protection.

Complete transparency/Play fair The way an agentless system works is basically the same concept as a man-in-the-middle attack on all the machines in the network. It is an attempt to break into or intercept connections in order to eavesdrop or in this case inspect the traffic [2].

The user might believe he or she is communicating directly with the web server but is really communicating with the DLP server, which is analysing the traffic and then passing it on to the web server. A user might send personal information that the user do not want to be monitored. Therefore a DLP system using these methods should be informing the user when this kind of monitoring is used.

Report/log to both administrators and users This is also an issue shared by both the agentless and agent based solutions. Informing users that their traffic within the internal network is being monitored should be mandatory since this type of inspection could be considered as severe intrusion on users privacy.

1.3.3 Hybrid

The hybrids combine the network analysis performed by proxies and the use of an agent on each endpoint. This makes it possible to monitor both the network traffic and file transfers to media such as USB, CD/DVD and printers. Although a hybrid solution has theoretically a greater potential protecting data it still has to face the same problems as both agent based and agentless solutions.

• Compatibility

• Correct configuration

• Connection to central server

• Running in an unsecure environment

• SSL/HTTPS connections

• Complete transparency/Play fair

• Report/log to both administrators and users

• Complete coverage - Although this is still an issue, with the combined use of a DLP server analysing the network traffic and a DLP agent monitoring each endpoint the potential coverage is much greater. It also offers

(17)

additional possibilities to enforce policies on a device that manages to bypass the network analysis. Since you have a DLP agent running on the device it could technically be programed to filter traffic not routed through a legitimate DLP server.

1.4 Current Limitations

The current state of DLP systems still suffers from limitations. It does not matter if it is agent based, agentless or the hybrid, they all face problems. Agentless have good coverage of outgoing data but faces performance issues. Thorough and efficient inspection of everything going out of a network is a huge problem and is much likely to increase latency on outgoing traffic. The compromise is often not to inspect all traffic, which will result in a less effective DLP system.

Agent based does not have this problem since the inspection is somewhat distributed to each individual machine or device in the network. In order for this to be an effective solution it requires implementations of the DLP agent software to work on all OSs being used. The DLP agent works as a “lookout” and reports to the DLP server whenever outgoing data does not abide by a policy. This will reduce the computation required from the DLP server and put some of it onto each machine in the network instead. However putting too much of the computation on to each machine would result in similar performance issues as with the agentless solution.

In order to account for the lack of DLP agent software for every possible OS that could exist in a network, the hybrid solution provides a combination of features from both agentless and agent based. It offers agent based protection on supported OSs in combination with remote scans in order to cover the network.

Alas, not even the hybrid solutions are able to fully cover and protect data once a machine or device leaves the internal network[17]. Both agent based and agentless solutions depend on a DLP server only accessible from the inside of the internal network. The reason for this is to protect the data exchanged with and stored on the DLP server, data such as policies and information regarding what sensitive secret data is. In the case of an agentless solution this means that once a machine containing sensitive secret data is taken outside of the internal network it has completely circumvented the DLP system, one example being a laptop that can easily be moved from one network to another.

The agent based solution however, keeps its last synchronized policies even if the connection to the server has been lost and protects the data on the endpoint from being leaked. Although, new policies sent from the server to the agents are not recieved by an offline agent.

This issue can be dealt with by setting up Virtual Private Network (VPN), which is a solution that allows users outside of a network to remotely establish a secure connection to an internal network using given credentials such as a user-

(18)

name and password. This makes it possible for the DLP server to still reach a remote machine. A VPN is yet not always a possible solution; it requires Internet connection in order to establish the connection with the internal network something, which is not always available.There is also the scenario of a malicious user with the intent to leak data, which would simply ignore to setup a VPN in order to circumvent the DLP system.

Another issue is companies that might want to protect their assets, but are not interested in a solution that would require redoing large parts of their existing system. They would have to make considerations regarding the impact on users ordinary workflow when establishing a DLP system. Policies and the method of enforcing them cannot be too lax in a way that the system fails to identify and prevent the leakage. At the same time the policies should not be too strict and the enforcement not too intrusive. It would most likely have a negative impact on users workflow, which could lead to users actively attempting to work around the system. Should it be possible to work around or manipulate, then the system would be rendered ineffective.

These systems will never be able to prevent every type of information leakage, and a simple example is taking a picture of the screen with their mobile phone, or writing down the sensitive information on a piece of paper. Another action is called shoulder surfing, when an unauthorized user takes a peek at sensitive information on other users screens and memorizes this. These are actions the DLP system cannot prevent and could never cover. But if it comes to this, the DLP system has fulfilled its purpose by blocking the existing leakage points it is supposed to cover.

1.5 Research question

The main research questions for this master thesis have been:

• In what ways can a DLP agent that has no connection to the main DLP server be vulnerable to tampering attacks?

• What can be done to improve protection against tampering attacks on a DLP agent when it has no connection to the main DLP server?

To be able to answer these, several experiments have been produced and conducted on four existing DLP systems; My Endpoint Protector, Trustwave, MyDLP and OpenDLP. These experiments have been performed in virtual environments with different operating systems to see the coverage of the DLP systems.

Tampering attacks have also been conducted on these DLP systems to discover potential weaknesses and ways to work around the installed agent.

(19)

1.6 Related Work

There has been some industrial research in the DLP area but not as much aca- demic research. Most of the research has been aimed on identifying how to choose the best DLP system depending on the needs. This has been done mostly through comparison between available systems, one example is by Gartner [14]

who compares Trustwave, McAfee, Symantec and 11 more different DLP vendors and pinpoints their strengths and what to look out for.

Blasco et al. [3] looked at ways of bypassing a DLP systems using trusted applications. A trusted application is described as a software that has been approved to be used by the users in a otherwise restricted environment. This means a user is not allowed to install or run any application that has not been approved. They prove in their paper that by encrypting secret data and using only trusted applications, in this case an ordinary spreadsheet, a user is able to leak information. The DLP system does not identify this data as sensitive and since the application is classified as trusted, the data is not detected.

Carvalho et al. [4] present their attempt in preventing email leakage by, either intentionally or unintentionally addressing emails with sensitive information to non-desired recipients. With the help of machine learning they also present a solution to this problem. They managed to detect leakage in 82% of their test cases with their solution.

Jinhyung et al. [7] suggests a design for a DLP architecture that take user privacy into consideration. Their research presents the trade-off relationship between information leakage prevention and privacy protection. They suggest a scoring module for calculation of level of privacy and security. Whenever rules are fired, the security and privacy scores are calculated. They use these scores to see how many times the private information has been reviewed by the DLP system. With this, the DLP system can recognize how many times the DLP process invades the privacy during the monitoring process.

Luft [8] raised the question “Can Data Leakage Prevention Prevent Data Leakage?”. After evaluating two DLP system the indications were that DLP system still had problems preventing data from leaking. He also discovered that the systems did not properly secure the communication between the DLP server and DLP agent. Making it possible to intercept and eavesdrop on the traffic being sent such as incident reports containing information regarding secret sensitive data being blocked. Although this evaluation was conducted in 2009, DLP systems are rapidly improving which means that continued evaluation is required.

Also as the author self mentions, there are more DLP systems in use that should be evaluated in a similar way.

Although Luft looked at the security of DLP system, still no research that looks into the aspects of how the DLP system itself can be manipulated has been found. This is something that is believed to be a critical aspect and has been the focus of this thesis.

(20)

In the work of Balinsky et al. [1] and Wüchner et al. [22] they look at implementation of an agent based DLP solution. Balinsky suggest a solution involving intercepting function calls to the Operating System in order to manage read and write access to data. Wüchner continued the work of Balinsky by applying an adapted policy model. In both Balinsky and Wüchner work they highlight some found vulnerabilities with their suggested DLP solutions. Men- tioned are the possibility to bypass their solutions since they do not intercept all possible function calls to the operating system that could be used to access data.

They also point out weaknesses in policy management and that it is possible to manipulate their solutions by attacks such as man-in-the-middle. Also in both solutions they require a user’s permissions and access to critical files required by the solution to be restricted.

(21)

Method

This chapter presents the method chosen to answer the reseach questions in this thesis along with the four tested DLP systems followed by a list of file transfer applications and media used when executing our test cases.

2.1 Test Environment

Because of limited access to resources and setup, the intended test environment consisted of a virtual environment with computers running on different operating systems:

• Windows 7 running service pack 1.

• Linux running Ubuntu 13.10

• Mac OS X Mavericks.

By using a virtual environment, the advantage is that it is fairly easy to create clones of whole virtual environments, which will reduce the time it takes to setup all environments. It also allows easily managing and jumping between environments when necessary.

The four DLP systems has been installed and thoroughly tested, one at a time on these computers. To be able to cover the leakage point with external hard drives and printers, a USB flash drive and a network printer has been used.

The experiments also consider when a user has different privileges on the local machine. The attempted experiments were to leak sensitive data using webmail clients (Gmail), local mail clients (Windows Live Mail), cloud syncing software (Google drive), social media (Facebook), instant messaging software (Skype), remote control software (Teamviewer), printers (network and local) and USB devices. The data attempted to leak was:

• A text file containing the words considered secret: “Hemlig”, “Stopp”, “Credit card information” and “confidential”. These have then been added in a custom content dictionary to see if the system can detect files containing these words. A credit card number: 4485630591171087, has also been added into the text file to test their built in CCN finder.

14

(22)

• The same text file but compressed into a zip-archive. Formats: .zip, .7z and .rar.

• Again the same text file but with the file being encrypted (it was stored within a Truecrypt file container).

• A 5370 kb large audio file, .mp3.

• A 15 kb large .png image

• Compressing the encrypted text file into a zip-archive

• A Microsoft Office Word file (docx), this because this file type is an archive that can be decompressed and files can be added without anyone knowing.

For every experiment, one file type at the time was set to be blocked and allowing the rest to see if there is any way to go around and fool the system. The experiments with the compressed files were done twice, first to block compressed file types, the second to allow them but not allowing its content, the text file.

Same was done with encrypted files. Tests with the Office file were also made twice, one time to block the file type .docx and the second to allow it but not allowing images. We then extracted the .docx file and added an image in the archive.

The tests were run through three different phases for each DLP solution. Dur- ing the first phase the attempt was to set up the DLP solution according to the recommendations and instructions available in order to prevent leakage of the data. Attempts to move/leak the data were made using the applications and software previously mentioned and then grade the test case with either Passed/- Passed with comments or Failed depending on if it managed to properly prevent the data from being leaked. The experiments that for any reason could not be conducted were graded C for comment and the tests where the system did not cover that functionality the grade was N/A. This phase also included of looking at how well the solution reported a prevention to both administrators and users.

The second phase consisted of attempts to disable or bypass the DLP solution in any way and then looking at how well it performs in a “crippled” state. The tests were run again and graded the solution in a similar manner based on how well it performed. In order to achieve attempts of attacking the DLP solution we tried:

• Booting the computer from another media like a CD and through that accessing the hard drive, also called a live CD attack.

• Corrupting or manipulating important binaries or configuration files used by the DLP solution.

• Stopping/killing the DLP solution preventing it from running.

(23)

The third and final phase was preventing communication between the central server in the DLP solution and the endpoint. To accomplish this, rules were set up within the local firewall on the endpoint to prevent communication between the central server and the endpoint. Then like in the two previous phases the tests were run again in order to see what effect this had on the DLP solution.

2.2 Tested DLP systems

In order to gain a good understanding of how current DLP system work, both open source and commercial products, an investigation of the four following DLP systems has been conducted:

• OpenDLP¹

• MyDLP²

• My Endpoint Protector³

• Trustwave⁴

OpenDLP and MyDLP were chosen as representatives of open source systems.

My Endpoint Protector was chosen because it is a DLP system deployed in the cloud, which uses Software as a Service, SaaS. A 10-day trial with full access to all the functionality has been run. The last system, Trustwave, was chosen as a representative for commercial DLP system. Access to their virtual test environment, setup by Trustwave through a third party, Hatsize ⁵ was granted for testing.

These experiments should be conducted on more DLP system in order to achieve better results and understanding, since some DLP systems offers different functionality. But due to time limits, these are the only ones tested. For the testing process, a test plan was produced, which has been run on My Endpoint protector, MyDLP and Trustwave. The reason to why it was not executed on OpenDLP is explained in section 3.4. The experiments executed are listed in table 2.1.

1https://code.google.com/p/opendlp/

2http://www.mydlp.com/

3http://www.endpointprotector.com/

4https://www.trustwave.com/

5http://hatsize.com/

(24)

Test Case Configuration

Transfer a text file Policy set to block text files Transfer a text file with sen-

sitive data Policy set to block text files has been removed.

Policy for sensitive data is active Transfer a compressed file Policies set to block compressed files Transfer a compressed file

with sensitive data Policy set to block compressed files has been removed. Policy for sensitive data is active Transfer an encrypted file Policies set to block encrypted files

Transfer an encrypted file

with sensitive data Policy set to block encrypted files has been removed. Policy for sensitive data is active Transfer a media file Policy set to block media files

Transfer an image Policy set to block images

Write sensitive data Type blocked words from content dictionary Transfer a compressed file

with encrypted file within. Compress an encrypted file with the policy set to block encrypted files. Policy set to block compressed files has been removed.

Transfer a Microsoft Office

files 1. Policy set to block .docx files.

2. Add blocked file types in decompressed .docx files. Policy set to block .docx filed has been removed

Table 2.1: Test Cases

The tests also consisted of how possible leakage points are handled, such as being blocked or logged. Also, additional investigation has been made regarding the problems of implementation of agent based software. An improvement has been suggested and a proof of concept has been implemented.

(25)

Evaluation of DLP products

This chapter presents the evaluation of the four DLP systems according to the approach stated in chapter 2 along with found problems and suggested imrpove- ments.

3.1 The agent based solution - My Endpoint Pro- tector

My Endpoint Protector is an agent based DLP solution with all administration deployed and running in the cloud. Everything is managed through their Web User Interface, everything from policy creation to download and deployment of the agent on to an endpoint. It is a 100 % cloud managed DLP solution and they have two editions of the solution, one free edition with limited functionality and restrictions on how many endpoints that may be used. The other is a non-free version that has no restrictions on the functionality and no limit on how many endpoints that may be used. My Endpoint Protector offers a trial where you, for a limited number of days, can try out the non-free version, which is the version used for our testing. They cover many different platforms, such as Windows 7 and 8, Mac OS X, Apple and Android tablets and phones. The tests have been conducted on both Windows 7 and Mac OS X Maverick just to see if they differed in their protection services. An account was created with the 10-day free trial where all features were enabled.

The policy settings for Windows covered the most common applications used for file sharing or transfers, and this covered the software that was planned to test.

The different file types to monitor are predefined and covers a variety of image- , text-, media- and compressed file types (see figure 3.1). It is a user-friendly administration tool where it is easy to add your own context dictionary and to block print screens and copy paste. Although, even if the print screen button was blocked, it did not block the software “Snipping tool” on Windows.

The applications covered for Mac OS was not as widely ranged and there is no way for the administrator to add more (see figure 3.2). There were many tests not performed on Mac OS because the applications were not supported for this

18

(26)

Figure 3.1: Applications for Windows in My Endpoint Protector

Figure 3.2: Applications for Mac OS in My Endpoint Protector

operating system, applications such as Gmail and Google Drive. File types and context dictionaries were the same but it was not possible to block print screens.

On the other hand, this is the first DLP system available for Mac, even if it is not complete.

3.1.1 Found problems and suggested improvements

The found problems and these improvements are aimed for the Windows version of this system.

Problems:

• An image was sent via Windows Live Mail, even if the action was to block, because it uploads the image to Microsoft SkyDrive, which is not included in the list of applications for Windows.

• The DLP agent disabled the Print screen button but was not able to disable the Snipping tool for taking screenshots, which is a pre-installed on Windows.

(27)

• The agent is not able to decompress files and analyse the content, even if it contains sensitive data.

• Printing with network printers was not detected by the agent. The file type .xml was the cause of blocking, not the printing itself.

• The agent could not detect if sensitive text was being written in a document or chat, only if the user was trying to copy the text.

• When connection is lost between agent and server and incidents occur, the logs are not sent to the server after reconnecting.

Improvements:

• Make it possible to add own application to monitor.

• Since the agent analyses the MIME-type of the files, the administrator should have the ability to add more file types if necessary.

• Save logs locally but encrypted and send to server as soon as connection has been reestablished.

• Be more aware of compressed files, decompress archived files and analyse its content.

(28)

3.2 The agentless solution - Trustwave DLP

Trustwave DLP is a commercial agentless DLP solution that does content filtering and monitoring on dedicated servers in the network. In order for this to work it is necessary to configure each endpoint to route its traffic through these servers. To enforce this, ensuring the traffic is not bypassing the servers it is recommended to prevent any outgoing SSL/HTTPS traffic (in other words encrypted traffic) from leaving the network with the exception of traffic coming from the DLP servers.

Ordinary non-encrypted traffic is covered by a monitoring server that receives a copy of the outgoing traffic and writes a log if it discovers any sensitive data leaving the network.

Access was given to their pre-installed and setup virtual environment, which they use when demonstrating their product to new clients. Their lab consisted of 6 servers and one Windows 7 desktop. Each server ran one of the system’s modules:

• DLP Console - This server is more or less the central link between all the components in the system. It is managed through a Web UI presenting all the logs from the components in the system.

• DLP Monitor - This server is placed between the machines in the network and the proxy. Its purpose is to monitor and log any outgoing data that matches one of the set policies (here called categories).

• DLP Web - Is responsible for filtering/blocking sensitive “web content”.

• DLP Email - A Mail Transfer Agent placed between the internal mail server and the external network (internet). Its purpose is to filter/block email traffic.

• Entrust - Their mail server. (Entrust’s Entelligence).

• Email & Proxy Server - Their purpose is to redirect outgoing traffic through the DLP Servers.

Each of the individual DLP modules has to be configured through their individual Web UI. Other modules also seen were:

• Secure Web Gateway (SWG) - This module was running on the “Email &

Proxy Server”.

• Discover - A collector that scans and classifies data in network file shares.

This environment is operated by a third party and has recently been updated and did not work completely, the settings of handling SSL/HTTPS traffic was not operational during the time access was given. Because of the lack of SSL/HTTPS

(29)

support in the environment, the tests could not be made like the other tests conducted. Because of this issue, proper test of Facebook and Google Drive could not be made since they do not have the option of HTTP. Another issue that came up was to force Skype and Teamviewer to go through the proxy. Even though the settings were correct, by analysing the network traffic it was noticed that the traffic did not go through the proxy. So the test result are based on what tests that could be performed and the documentation that was given and from there giving it a more hypothetical evaluation. In order to be able to test the system at all, a web server was configured with the possibility of uploading files over HTTP to see if these would be blocked by the DLP system.

Settings for external hard drives and printers was nowhere to be found and after consulting with Trustwave, the information was that their solution is not an endpoint solution which means they do not cover these items.

When trying to cut the connection between any DLP components on the endpoint and the server by starting and adding rules in Windows Firewall as done with the other DLP systems, the virtual environment just froze and happened every time this was attempted. This led to the phase three tests were not able to be conducted.

This is a very complex DLP system and even though their documentation was thoroughly read, it was not presented how file type blocking was to be set. This affected the following test cases:

• Transfer a text file

• Transfer a compressed file

• Transfer an encrypted file

• Transfer a media file

• Transfer an image

• Transfer a Microsoft Office files

We discussed this issue with a representative from Trustwave, he claimed that this could be made by their policy scripting language and by that time, it was too late to test this.

3.2.1 Found problems and suggested improvements

Since this was a pre-installed and setup environment, these problems and improvements are aimed for Windows.

Problems:

• Uploading .zip and .rar files were blocked but not the file type .7z.

(30)

• Encrypted files containing sensitive data was not discovered by the DLP system.

• When attaching a document with sensitive data in an email, the only noti- fication the user receives is “Something went wrong, could not attach document. Please try again.”

Improvements:

• Trustwave received the feedback on .7z and said they would fix this issue.

• Simplify adding file types from scripting language to adding MIME types.

• Present the user with more information about which file that was blocked and why.

3.3 The hybrid - MyDLP

MyDLP is a combination of the two previously described DLP solutions. Like Trustwave’s DLP solution, content filtering is done within the network using dedicated servers and in addition to that it also offers DLP agents to be installed on endpoints (these agents only run on Windows though). Each endpoint has to be configured to route its traffic through the DLP server.

It is a open source DLP system with two different licenses, Community Edition and Enterprise Edition where there is no commercial support for the Community Edition. They offer a 30-day trial with the Enterprise Edition to test their solution which has been used during these tests. They have provided several tutorial videos and manuals on their website ¹ of how to install and set up their system and defining the policies.

This DLP solution allows the user to manually add new file types with MIME, web pages to be blocked or logged and is user-friendlier than Trustwave. The different rule types in MyDLP are:

• Web rule - Used to monitor and control web traffic

• Mail rule - Monitor and control e-mails

• Removable storage (inbound and encryption) - Control data moved to removable storages, such as USB sticks

• Screen shot rule - Prevents print screen function while a sensitive application is running

• Printer rule - Control printer jobs

1www.mydlp.com

(31)

• API rule - Allows you to integrate custom applications with the DLP system Several attempts of adding a mail rule for blocking email clients was made without any success, but when adding a web rule it managed to block web mail clients such as Gmail and Outlook. It blocked all email attachments except the encrypted files containing sensitive information. A local mail client, Windows Live Mail, was also used with the right proxy settings but it did not block the attachments from that client.

This DLP solution extracts the compressed files before determining if it is sensitive or not, which is something My Endpoint Protector does not do. It is even able to extract .docx files to see if there is anything snuck in in the folder.

Same as with Trustwave, we were not able to force Skype and Teamviewer to go through the proxy.

Compared to My Endpoint Protector, when disabling the agent from connecting to the DLP server and send a file that is blocked and then reconnect, the logs are sent to the server as soon as the connection has been reestablished. MyDLP has the built in functionality of file system scans called Discovery but has a very high impact on performance.

One benefit with MyDLP is that even if the agent is disabled on the machine, the rules forced via the proxy are still operational, but USB and local printers are no longer prevented. And if the connection to the DLP server is blocked, the last operational policies are still enforced.

3.3.1 Found problems and suggested improvements

Problems:

• Blocking attachments in web mail clients but not in local mail clients. Proxy settings were set up but still not blocked.

• When sending a .docx file with an image added in the extracted folder, in email this was detected but not when sending it on Facebook.

• Only locally connected printers are possible to block. When printing with a wireless network printer it did not block the printing.

• No notifications are presented to the user when something has been blocked.

This could lead to frustration if the user is not aware of this information or file type being blocked.

• When applying a rule for blocking application/octet-stream, MIME-types for inter alia encrypted files, the DLP system blocked entire web pages which contained octet-streams which made it impossible to test encrypted files as attachments.

(32)

• The screenshot rule was able to block the software “Snipping tool” in Win- dows, but not the button for print screens. Other screenshot tools were not blocked.

Improvements:

• Extract .docx files for all types of file transfers.

• Present information about what caused the blocking to the user.

• Differentiate on file transfers and web browsing when it comes to octet- streams.

• Block any type of screenshot attempts.

3.4 The file system scanning tool - OpenDLP

OpenDLP is described as “... a free and open source, agent- and agentless-based, centrally-managed, massively distributable data loss prevention tool...” [13] on their web site, which is a good description of this system, a centrally-managed regular expression scanning tool. This DLP solution only analyses the data locally stored on the machines and does not monitor network traffic or prevents data from being leaked. This is a typical example of how the concept of what can be considered a proper DLP solution still is not perfectly defined.

If a file contains sensitive data by the time the scanner reaches to this file, then it could be quarantined or blocked, otherwise this file could be attached or printed undetected. This scanning tool does not affect performance as much as MyDLP, but since every scanning log is saved in a database, it could start being noticeable if the database is getting overwhelmed with log entries. On the other hand, this is not a scanning tool for a big company, since every targets IP-address must be manually added in the scanning list. It is not possible to add a network address for it to go through. For this thesis we have chosen to look at DLP systems that monitors Data in Motion and OpenDLP is only analysing Data at Rest and because of this system being a regular expression scanner, no tests were possible to be performed on this DLP system.

(33)

Results

In this chapter we give the results of our evaluations from chapter 3 and present the implemented solution along with its results. These results will be further analysed in chapter 5.

4.1 Test results

Figures 4.1-4.3 presents a summary of how the three different DLP systems, My Endpoint Protector (MEP), Trustwave (TW) and MyDLP (MD), passed the tests.

As mentioned in section 2.1, the different gradings were:

• P - Passed, the system successfully blocked the leakage attempt.

• PC - Passed with comments, partially succeeded to block or identify leakage attempt but did not qualify for a P. Comments are given.

• F - Failed, the system did not block the leakage attempt.

• C - Comment, a test case that for any reason could not be conducted.

• N/A - Not able to test due to function not covered by the DLP system.

Phase 1: Clean Install

The first phase of our experiments was to install the software on the endpoints, setting up policies according to documents and manuals and begin to transfer our test files. No tampering has been made to the software at this stage. Figure 4.1 shows our results of how these DLP systems coped with our tests.

26

(34)

Figure 4.1: Test results from clean install

Results:

My Endpoint Protector Trustwave MyDLP

Pass 37 2 14

Pass with comments 8 1 10

Failed 22 2 23

Comments 0 19 21

N/A 9 53 9

Total 77 77 77

Table 4.1: Summary of results from Figure 4.1

Comments:

• Trustwave - Due to issues with SSL/HTTPS, we were not able to test these.

Also, they do not cover endpoints, therefore N/A on printers and USB.

• MyDLP - Not able to force Skype and Teamviewer to go through the proxy.

Phase 2: Disabled Agent

In the second phase we tried to find ways to disable the DLP agent on the endpoints. This was done according to section 2.1. Figure 4.2 represents the results of this experiment:

(35)

Figure 4.2: Test results from disabled agent Results:

Pass 0 0 7

Failed 68 0 31

Comments 0 24 21

N/A 9 53 9

Total 77 77 77

Table 4.2: Summary of results from Figure 4.2 Comments:

• Trustwave - Trustwave is an agentless DLP system, therefore no agent to disable. Also, same comments as in phase 1.

• MyDLP - Same as in phase 1.

Phase 3: Disconnected Server

In the third and final phase we tried preventing the communication between the central server in the DLP solution and the endpoint. We refer to section 2.1 for a description of how this was done. For the results of this phase, see figure 4.3.

Figure 4.3: Test results from disconnected DLP server

(36)

Results:

Pass 34 0 7

Failed 26 0 39

Comments 0 24 21

N/A 9 53 9

Total 77 77 77

Table 4.3: Summary of results from Figure 4.3

Comments:

• Trustwave - The virtual environment halted when a firewall rule was added and activated. Also, same comments as in phase 1.

• MyDLP - Same as in phase 1.

(37)

4.2 Implemented solution

In addition to the evaluation of DLP solutions we have also considered means to implement an DLP agent of our own, mainly for Windows, in order to better understand the DLP agent’s weaknesses. We have yet to discover documentation describing the difficulties and problems of the actual implementation of an DLP agent. We mentioned in section 1.6 the work of Balinsky and Wüchner and while they put perspective on attacks and weaknesses against a running DLP application, their focus is more on performance. We have analysed the technique they used in an attempt to identify possible problems at implementation. The solution needs to cover file transfers via media such as [1]:

• USB, CD/DVD or other external media

• Printers

• Instant messaging

• Email attachments

• Other file transfer services

It also needs to be able to identify and categorize data according to a set of rules/policies and should be able to adapt and apply these rules according to different context. It must also both log the actions performed for the specific file and give the user an explanation to why this action was taken. Using a simple way of defining rules by black- and whitelisting directories, files and files containing a predefined signature or magic number will allow for possible integration with solutions like the ones we have evaluated in chapter 3. The idea is that existing solutions could provide information regarding what files should be considered sensitive. This along with a list of applications that will be used and should be monitored.

In order for applications to access data stored on a medium such as a hard drive, CD/DVD or USB drive, applications request the data through the operating system. This is also the case when storing or transferring data between mediums like sending files across the network or copying a file from a hard drive to a USB drive. By placing an inspection layer between the application and the operating system you can manage who and what get access to what data.

4.2.1 API Hooking

One way to accomplish this is a technique that intercepts function calls to the operating system in a program and redirects it to another function. This technique is known as Applications Programming Interface hooking, API hooking, also called System Call Tracing or System Call Intercepion. This is the same

(38)

technique that Balinsky [1] and Wüchner [22] were using in their work and it have also been used with malware detection looking at the pattern of called API and flag applications that vary from what is considered normal behaviour. [9].

API hooking is quite demanding and risky if not implemented correctly. Once an API is hooked it is your code that has to manage all function calls to that API and any mistakes could lead to applications crashing or even system fail- ure such as BSOD, Blue Screen Of Death. Microsoft Research has developed a framework for Windows in order to make API hooking easier and more secure.

This framework is known as Detours [10] and is available in two editions, express and professional, where there are limitations to what the first edition can do such as limited processor support and only works for the x86 architecture. We used an open source counterpart to Detours namely the framework EasyHook, which build on the Detours concept while continuing improving it like they mention on their website:

“Easyhook starts where Microsoft Detours ends. This project supports extending (hooking) unmanaged code (APIs) with pure managed ones, from within a fully managed environment like C# using Windows 2000 SP4 and later, including Windows XP x64, Windows Vista x64 and Windows Server 2008 x64. Also 32- and 64-bit kernel mode hooking is supported as well as an unmanaged user-mode API which allows you to hook targets without requiring a NET Framework on the customers PC. An experimental stealth injection hides hooking from most of the current AV software.” [5]

Results

By defining and hooking the Windows API related to file management [12] using the EasyHook framework, the following functions have been implemented:

• CopyFile

• CreateFile

• DeleteFile

• MoveFile

• ReadFile

• ReplaceFile

• WriteFile

We predefined a list of which files and directories that should blocked and which that should be allowed. We also defined a list of magic numbers and signatures

(39)

that should be blocked. We managed to successfully prevent hooked processes from accessing files that were either blocked, not whitelisted or contained either a blocked magic number or signature through any of the defined API.

Below is pseudo code describing the inspection process of a hooked API when called:

Algorithm 1 Inspection process

1: procedure FileInspection

2: f iletype ←type of requested file

3: f ilepath ←path to requested file

4: for all entries in blocked file types list do

5: if identitfied filetype = entry then

6: blockAP Icall

7: for all entries in blocked directories and file list do

8: if requested filepath begins with entry then

9: blockAP Icall

10: for all entries in allowed directories and file list do

11: if requested filepath = entry then

12: allowAP Icall

13: blockAP Icall

Figure 4.4: Conceptual illustration of the implemented solution

The limitations and problems

With EasyHook you may encounter some restrictions depending on how it is used such as the application requiring .NET 3.5 or 4.0 installed in order to be able to run. However it offers a simple and safe way of hooking single processes redirecting the API calls of your choice. It is possible to globally hook all processes, this would

(40)

however involve rewriting/replacing the real API. It would effectively allow you to manage all processes using the API but any problems caused by the rewritten API would then affect the entire system. By hooking each process individually any problem encountered in the redirected API will only affect the hooked process.

Below is a list of other issues we encountered during the implementation of our solution:

• The library of APIs available in Windows are many and though a lot of the APIs do not involve file access, failing to hook the ones involving file access would allow for bypassing the agent entirely.

• The agent itself is vulnerable to API hooking from any privileged users.

Measures to ensure that the agent has not been tampered with must be taken in order to assure its safety. This could be done by a hidden process that observes the status of the agent like a watchdog and take actions such as rebooting the system if the agent for some reason has been disabled.

• The solution does not offer any protection against live CD attacks.

• Since each process is hooked individually the solution must ensure to hook every process immediately when they are created. If not, there will be a time gap where the process have the ability to freely access data until it is hooked.

• Our solution is only intended to look at API hooking as a mean to DLP and does not focus as much on performance. It is worth mentioning that the amount of files and directories listed for white- and blacklisting will directly affect performance on hooked processes.

• During our tests, iexplore.exe and chrome.exe could still access all files when the user tried inter alia uploading a file to a web server. We assume this is due to the use of APIs other than the ones we have defined. In the work of Balinsky[1] they handled this using means other than API hooking. They used Browser Helper Object, which is a module in Internet Explorer that provide additional functionality similar to extensions and addons in other web browsers like Firefox and Chrome.

(41)

Analysis

The results in chapter 4.1 proves that an agent based solution, where the agent has been disabled, does not cover any of the leakage points, it forgets the policies and allows everything to pass. This is however somewhat handled by an agentless system since it does not depend on an agent to do all the work, instead sending the network traffic through the proxy to monitor. On the other hand, when the server is disconnected this becomes useless, where the agent based remain the last set policies. The agentless system does not cover any media physically connected to the endpoint, such as USB, CD/DVD or printers, no matter what state it is in. Since the experiments of Trustwave did not give a fair and complete result, we are left with My Endpoint Protector and MyDLP.

5.1 Analysis of the hypothetical scenario

Individually these systems do not perform as well as hoped, however a combination of these solutions could together, hypothetically, yield a much better cover.

Figures 5.1-5.3 and table 5.1 shows hypothetical assumptions and the results of how the combination of the agent from My Endpoint Protector and the proxy from MyDLP would perform in these experiments. By complementing each other in situations where the other fails would be the most effective DLP solution. Yet, far from perfect, not all leakage points are fully covered but there is an improvement in their coverage and the number of fails decreases. These hypothetical results have been developed from assumptions, if one of the DLP solutions pass and the other fails, the first one will be responsible of that leakage point. The results presented in this section does not take the grades N/A in consideration.

An analysis of the three phases has been done with their respective result and compared to the original results from our experiments.

Hypothetical phase 1: Clean install

Compared to phase 1, we now get a pass rate of 65% where we before got 54%

by only using My Endpoint Protector. The fail rate of My Endpoint protector in the original phase was 32% and for MyDLP 34%. With this combination we would get a fail rate of 15%. Figure 5.1 illustrates these results.

34

(42)

Figure 5.1: Results of combining My Endpoint Protector and MyDLP

Hypothetical phase 2: Disabled agent

Since in the original phase 2, MyDLP was proven to cover the most leakage points, this hypothetical experiment would give the same results, a pass rate of 10%. My Endpoint Protector failed 100% of the tests in the original phase 1, with this combination the fail rate would instead be 46%. Figure 5.2 demonstrates what these results would look like. This combination would be beneficial for the agent based solution.

Figure 5.2: Results of combining My Endpoint Protector and MyDLP with disabled agent

Hypothetical phase 3: Disconnected DLP-server

Same as in phase 1, My Endpoint Protector performed best in the third phase.

With this combination it would give a slightly better result from the original, a pass rate of 51% compared to 50%. The biggest difference here would be the fail