After completing the development of the data classification model and supporting processes including policies and standards a tool may need to be implemented to enforce data protection based upon the model. Data Loss Prevention (DLP) is an example of a tool that can enforce protection of data that has been classified by the enterprise. In the previous Data locations section several examples of data locations were presented to emphasize the complexity of data management and protection in the enterprise. DLP can help find data in these various locations, and in some cases enforce encryption, block insecure transmission, and block unauthorized copying and storing of data based upon data classification. There is significant benefit to having a solution with this capability, allowing automated protection within the enterprise, integration with existing solutions, and actionable reporting.
The primary purpose of DLP is to protect against the unauthorized exfiltration of enterprise data from the enterprise egress connections. Because this can be accomplished by several methods it is important to consider the capabilities of the DLP solution and how it can be integrated into the environment to provide the expected protection. The following sections will cover the implementation of DLP for the common data locations in the enterprise.
Data can be stored multiple ways in an enterprise network, commonly in network shares, databases, document repositories, online storage, and portable storage devices. Data may reside in these locations as part of a business process or simply for convenience of access by employees. When evaluating the storage locations in the environment, identifying the business case for the method should be the first step in deciding if this method will be approved in accordance to policies, standards, and the finalized data classification model. I will use the portable local storage method as an example exercise for evaluating the use of storage technologies and the risk introduced by their use. Based on the Acceptable use policies and Data handling policies sections in Chapter 3, Security As a Process, a series of questions needs to be answered to determine how to properly assess the use of the technology in question.
For example, consider a local portable storage device used by employees:
- Is the use of this storage type permitted?
- If no, then how can this be enforced?
- If yes, does the use of the type of technology affect the security posture of enterprise data?
- Can enterprise data reside on this storage type?
- If so, how does this affect the security posture of enterprise data?
- What type of data may reside on the technology?
- Who will control the technology?
- What protection mechanisms must be implemented to protect data?
- How will the protection mechanism be implemented and managed?
More or fewer questions can be asked, to reach a decision on the use of portable storage technologies. Some technologies will require more input than others, as well as a complete understanding of the interacting business processes. It may be decided that only certain storage technologies are permitted for storing enterprise data of certain types with low risk to the enterprise in the event of data loss.
A DLP strategy can be developed to ensure all data locations are accounted for including employer-owned systems such as employee laptops. Most DLP solutions have the ability to scan data stores and also provide an agent that can be deployed on end systems to monitor and prevent unauthorized actions for classified enterprise data. The locations where data will reside as part of a standard process can be scanned for the specific data types that have been identified in the enterprise data discovery phase. If a discovery scan was initiated to identify data in locations, it can be used in an ongoing scheduled scan to continuously monitor the data stores for data that should or should not reside in the data location.
In order to provide protection for the discovered data, either an automated function within the DLP solution can be used to move the data to a secure location, or implement other methods to restrict access as the data is discovered. Another method that can be employed is to simply report on the discovery findings, and investigate the business reason for the data residing in the location. In order to employ automated protection methods for data in storage it is imperative that the effects of such actions are completely understood to minimize impact to critical business processes. A majority of enterprise cases will be a manual process of investigating the reason for the data residing in the location and working toward moving the process and data to a secured method. This method is least impactful and is recommended for enterprises with new DLP implementations.
In cases where the data location is an employee laptop, it may be acceptable to take more aggressive steps to protect the data resident on the system—including deletion. As more portable storage devices are becoming commonplace on the enterprise network without authorization, deploying an agent to employer-owned assets may be the best method to enforce data loss prevention at the end point, in essence never allowing the system to store the data on any local drive including portable attached storage. This solution does not solve the employee-owned assets problem, which introduces several complexities including privacy, management, supported platforms, and risk. Refer to the BYOD initiatives section in Chapter 2, Security Architectures for more information on approaching this trending topic.
A method to reduce DLP complexities is to identify systems that may be multipurpose data stores, such as file servers, and may have more lax permissions versus a tightly controlled and specialized database server. There is value in scanning database servers such as identifying a misconfigured database storing unencrypted data.
Data in use is data that is actively processed within an application, process, memory or other location temporarily for the duration of a function or transaction. Examples of data in use are point-of-sale systems, call center systems, web applications, employer end systems, and servers. These are systems and applications that are in some way interacting with enterprise data, but not storing long term, only long enough to perform a function or transaction.
Data in use is the unique facet of DLP that is a little more complex than dealing with data in storage or data in transit. In use implies that there is an application or function involved to read, add, remove, and modify data. Even though using data is a business function, if required, there may be reason to ensure that the data is not handled in an unauthorized manner that could lead to loss. Data in use can be monitored by an agent installed on the end system to permit only certain uses of the data and deny actions such as storing the data locally or sending the data via e-mail or other communication method.
Typically, the DLP agent that resides on the end system will be inserted low in the TCP/IP stack to ensure it can detect data before any encryption can be applied such as SSL (HTTPS) that would allow circumvention of network-based security mechanisms. Due to this behavior, implementation on employee-owned devices introduces privacy issues because any personal transactions such as online banking, medical record lookup, and so on may be detected and details of the transaction stored in the DLP database for review.
This scenario must be carefully evaluated when considering a BYOD deployment for employees with access to classified data. This is not an issue for employer-owned assets covered by well written security policies informing employees there is little expectation of privacy when using enterprise assets for personal use. Most policies indicate no personal use of enterprise assets is permitted, but in reality it is not generally enforced, with some probability of private data being detected and stored within the DLP solution. There should be a process for removing this data, if not needed for an investigation, to ensure some level of privacy for employees.
Several benefits can be derived from using an Endpoint DLP solution for preventing data exfiltration including limiting where data can be stored, how it can be transmitted, and what applications can be used to interact with the data. Preventing the saving of classified data to attached storage devices or removable media such as CD/DVD can prevent large amounts of data loss for otherwise undetectable methods of exfiltration.
No network monitoring device will detect if thousands of medical records are saved to a local machine and moved to a USB storage device, but Endpoint DLP can detect and prevent this action. Another benefit of the solution is preventing USB-attached storage at all, not just when coupled with a classified data type. Many other security threats are introduced to environments through these small portable devices with high capacities for storage. Implementing an Endpoint DLP solution will add an additional layer to the overall DLP strategy where data is directly interacted with in the most vulnerable state.
Data in transit is data that is being moved from one system to another, either locally or remotely, such as file transfer systems, e-mail, and web applications. The focus of DLP for data in transit is specifically data leaving the enterprise through egress connections. It is expected that insecure transmission of sensitive data occurs within the network boundary due to the perception of the secure internal network and many industry standards allowing for unencrypted, clear text transmission of data. However, it is recommended that all data including credentials be transmitted only using secure methods. A simple reason for this practice is to ensure protection regardless of network architecture and design changes.
It is common to have many communication methods available in the enterprise for day-to-day business including e-mail, file transfer, web portals, instant messaging, and conferencing services that include voice, video, and instant messaging. With these business conveniences come additional methods to transmit data out of the enterprise, many times encrypted and therefore invisible to network-based security technologies. Various DLP solutions have accounted for this fact and provide solutions capable of intercepting and decrypting communications to look for classified data. There are commonly solutions for HTTP/HTTPS, FTP, SMTP, IM interception, and inspection.
The following diagram depicts an example Network DLP solution implemented for e-mail, web, and general network traffic interception, inspection, and mitigation:
The DLP solution for data in transit is typically deployed at the network egress connections and is configured to look for specific protocols and inspect data based on configured policies. For specialized implementations there are solutions that provide e-mail and web gateway technologies that can act as complete web proxy and mail forwarder implementations in addition to DLP.
In these scenarios the traffic leaving the network via one of these communication methods is sent to the DLP appliance, decrypted if configured, and inspected. Once inspection is complete actions will be taken as per the policy configuration. Typical DLP actions may include block, permit, and encrypt detected data. Generally, this is configurable per data type, source/destination pairs, senders, recipients, and so on. The level of customization depends on the DLP solution. Flexibility of the DLP solution should be evaluated prior to purchase and implementation.
There can be several business processes identified that transmit classified data via insecure methods and can be managed using the DLP solution to report current state, transitional states, and provide accountability for future instances. It is advisable to communicate intentions of the DLP solution prior to sending a report to a business unit asking them why they are doing something that violates policy or the classification standard. Of the three DLP implementation areas, in transit tends to get the most attention because it provides confirmed instances of data leaving the enterprise network. Because there is typically less trust associated with external entities and networks than internal violations, priority will probably be focused here and some level of risk analysis performed to determine the best course of action for long-term remediation. In fact, most proof of concept implementations start with a network implementation of DLP to identify data in transit leaving the network.
Network-based DLP is one of the easiest methods to determine what data types are leaving the network and in what manner, secure or insecure. It also has the least amount of effort associated with the implementation, because no agent software is needed for the basic network monitoring solutions. There is more work with the e-mail and web-specific solutions, but these should be carefully considered for implementation and be understood as to how they would integrate with existing technologies. The e-mail and web solutions can typically perform URL filtering, and SPAM protection, which may already be implemented in another solution. This can complicate the overall implementation; collaboration with other teams is essential when considering these two technologies.
A decision may need to be made in regards to what function each security appliance will perform. For instance, if the next generation firewall (NGFW) can support URL filtering with user mapping, the decision needs to be made as to whether the NGFW feature will be used or if all web filtering and DLP functions specific to web traffic will be a feature that DLP will provide.
Because this technology has far reaching capabilities into most teams' areas of responsibility in an enterprise, it must be well communicated especially to network related teams if separated from information security. A little collaboration up front will go a long way to finding the right fit for DLP in the organization and alleviate unnecessary tension where internal lines are drawn but DLP blurs the lines of roles and responsibilities.
Having implemented Network DLP, E-mail DLP, Web DLP, and Endpoint DLP most data loss scenarios will be detected and can be prevented with a high rate of success. As with any security technology, the enterprise adoption and maturation of processes will determine the overall success and value-add. A phased approach and consistent communication with the involved teams will ease the transition into the use of another security technology that will take time to manage and remediate findings. If this can be presented as a service of IT Security there may be additional gains of internal trust and cooperation because there is immediate partnership in the resolution to secure enterprise data.
In the previous sections, the common methods of discovering data and protecting data from exfiltration were covered. The challenge with this toolset is deciding what methods to employ, in what phases, and how to digest the output from the tool. Implementation itself may not be much of a challenge but operationalizing the solution and delivering value on the investment may pose more of a challenge.
The best method to implementing any solution in the enterprise is to first understand the problem to be solved, and then determine the course of action. This is probably truer with a solution like DLP than most. Because DLP will span multiple teams within the enterprise and have several technologies involved, collaboratively coming to an agreement on how to proceed with a DLP implementation is critical to the success of the program. The following sections will cover the DLP solutions presented, approaches to successfully implementing them, overcoming challenges, and getting value from a DLP implementation.
DLP Network is the simplest solution to implement in an enterprise environment because fewer IT teams need to be involved for implementation. It is also the quickest method to determine what data is leaving the network in an insecure manner, therefore identifying bad business practices or malicious behavior can be done with little effort and some cross-functional coordination. Because the network component of DLP must be able to see all traffic at the network edge, the network team will need to be involved. A challenge here may be the use of SPAN ports, if there is no other aggregation technology in use. SPAN ports can be a challenge on switches because many times there is a limit to how many can be configured and it can be taxing on the switch backplane where all data must traverse for the switch to move data.
The size of the network egress connections will also have an effect on the size of the network implementation. Some DLP solutions are appliance based, whereas others run on standalone server hardware, but both must be sized properly for the amount of data that will be inspected. If too much data is sent to the system and the network interfaces are overrun, some data will be lost.
Having a good understanding of protocols in use at the network edge is valuable information that can be used to limit the types of data the DLP solution has to inspect. This can increase performance and reduce unnecessary inspection of protocols that are unable to be inspected, such as SSL, without a decryption capability and other protocols not in use.
If the plan is to provide actionable data to other teams within the enterprise, knowing what teams own enterprise processes will be important in order to provide feedback and options for remediation, where there is a security issue introducing risk to the enterprise. It is good practice to communicate intentions of any introduced technology, if others will be held responsible for data it provides. Simply providing a team with a report from a tool they have never seen and demanding they fix what is detected does not foster the collaborative environment needed for DLP to be successful. This is a fact for all facets of the overall DLP solution.
In the enterprise the two most used technologies are probably e-mail and the Internet. Introducing a new method to access either technology may be met with more apprehension than the basic network portion of DLP. In order for the e-mail or web solution to be effective they must be inline, or otherwise configured to receive e-mail or web communication, inspect, and be able to take action. This is not a passive implementation and can affect traffic leaving the network via these two methods. Planning the implementation and working with the teams responsible for the surrounding technologies, like existing Internet proxy servers and e-mail forwarders, will ensure proper placement of DLP and an agreed upon implementation. Consider the use cases for implementing DLP E-mail and Web carefully before designing the solution and developing policies.
Overall, there are few options for the designs of both technologies because they must be able to take action on the traffic; so understanding the design requirements along with the existing implementation of like technologies will highlight the areas of most significant change in the way the current solutions are working. As mentioned in the Data in transit section previously, the issue of overlapping technologies was presented as one challenge that may be difficult to overcome, especially if there is significant investment in an existing and overlapping technology, or a highly sought after feature purchased to only be scrapped in lieu of the DLP solution. Generally, this type of challenge will be contained within IT and can be resolved without engaging the business, as these are transport type technologies that will remain unnoticed until there is a policy violation or service impacting failure.
The primary purpose of the DLP E-mail and Web solutions is to take the necessary actions to protect enterprise data from insecure transport and exfiltration through e-mail and web over these communication methods. Taking action in this scenario will involve either direct or indirect user interaction and therefore must be communicated to the users explaining how the DLP implementation changes the use of e-mail and web within the enterprise. DLP E-mail solutions will also affect those business partners that receive encrypted e-mails with instructions on how to retrieve the protected e-mail. A thorough review of business processes that will be affected is recommended to ensure nothing is impeded from functioning and impactful to the business. A phased approach can be leveraged, either using DLP Network or using the e-mail and web solutions in a permit, but alert mode, allowing identification of insecure business practices that can be remediated in collaboration with the business process owner, without impactful mitigation actions.
The most significant relationship that requires buy-in and collaboration will be the messaging and network teams because both DLP technologies will change how they operate these services for the organization. Early communication and involvement of these two teams will ensure a design that meets the security requirements and integrates well with the existing infrastructure. Also, having the expertise of these teams available for implementation, troubleshooting, and long-term operational support is invaluable.
Another DLP solution that requires significant forethought and interaction with other enterprise teams is the DLP Discover solution. DLP Discover is the tool that can scan network shares, document repositories, databases, and other data at rest. In order to access this data, an account with permissions will need to be configured, to allow the scans to open the data stores and inspect for policy matches. Having an understanding of the use cases involving data at rest and knowing where the data resides should be a significant portion of the planning for a Discover implementation. Before making a decision on what product is purchased to meet the requirement to scan data at rest, ensure the primary data locations are supported by the solution to realize the intended value-add.
Some products perform specific functions of DLP discovery better than others. It is recommended to test each product in the real environment to gauge the effectiveness of each solution in the environment where they will be used. Once Discover has been run in the environment, carefully review the results to identify strengths and weaknesses of the product. Look to see if the product detected the known data types that should be detected; if it did not, look for possible misconfiguration and test other products on the same data set to look for differing results.
Because the DLP Discover solution is looking for data at rest and scanning hosts to enumerate policy matches, it may be advisable to run scans during off hours as the solution may increase the I/O on the system being scanned and impact performance.
There can be permission errors that will impede the success of the scan; testing by initiating a limited scan can help identify simple issues that will otherwise derail the scan. If there are file auditing controls in place, the DLP solution may trigger alerts based on file access operations, therefore, teams that perform monitoring functions need to be aware of the Discover host and scans so time is not wasted trying to hunt down an issue that does not exist.
As mentioned before, this tool can also be used to find data when it is unknown what data is at rest in the various data locations. In this scenario, communication and collaboration with system administrators is very important in order to get accounts set up and information on the data locations such as share names, URLs for web-based document repositories, and so on. It can be a great exercise to evangelize the DLP product in the environment that can provide useful feedback and knowledge about the environment that would otherwise take a significant amount of time to discover. A strategy can then be developed to protect the discovered data by running scans on a regular basis to ensure data stores do not become adulterated with classified data, putting the enterprise at risk.
Once DLP discovery has been configured and set up in the environment, it is a good validator of a properly implemented data protection program. Discovery of classified enterprise data can hone in on educational issues, bad business practices, and erroneous storage of data that would normally go undetected.
The last presented component of DLP to consider is the closest to the end user where the human interaction is the highest and, in theory, where the greatest risk is introduced to enterprise data – DLP Endpoint. DLP Endpoint is an agent-based technology that must be installed on every end point. Unlike the other technologies that are more process and design focused, Endpoint is a numbers game. In a typical enterprise, there will be more end point systems than any other hardware combined. This requires a significant implementation of agents that have to be installed, managed, and the output operationalized for meaningful and actionable reporting.
Installing the agents in a common enterprise setting is not too difficult as most enterprises have software management tools to install applications remotely on end point systems. The agent will still need to be packaged and tested on the various supported operating systems. Once installed the agent will check in with the policy server and this must be carefully monitored to make sure there are no communication issues and that the intended coverage is in place for DLP Endpoint. Agent status will change depending on the state of the system (on, off, or disconnected from the network), but the total number of hosts should match the number of agents deployed.
Because the number of hosts will be more than with other types of DLP solutions, incidents may be exponentially more, and careful planning of enabled policies will help with deciding the best approach to the end point solution. For the end point solution a specific goal can be the most affective, such as configuring blocking actions for classified data and attached local portable storage versus alerting on the presence of the data on the end point. As mentioned previously, the agent will install itself low in the TCP/IP stack, therefore any access to HTTPS websites like online banking, online shopping, and other personal sites will trigger the DLP solution and create and incident. If the goal is to make sure employer data is not transmitted from the host, then pre-classifying data or setting a threshold on the number of records may be the best option for detecting a possible exfiltration issue versus an employee making an online purchase.
There will be a lot of output even when the most basic of policies is set. It will be very important for the DLP operations team to quickly address false positives, tune the policies, and focus on what will make the most impact in protecting enterprise data from compromise and loss. If there are patterns in the output, then creating customized reporting to capture the pattern will be important to capture trends and focus on real issues.
The last and most important statement on DLP solutions is that it will take some time to find the norm in the environment, even if it is bad. The intelligence that can be gathered from this powerful tool can highlight security awareness issues, bad business practices, and illegal or malicious activity. At times it will all look the same, but the trained eye will know how the business functions and will be able to decipher good from bad. It is recommended to implement DLP in the monitor mode first, while these patterns are learned, to reduce the potential impact to the enterprise.