A CPA recounts exponential growth in Compliance. Mary Ellen McLaughlin

Transcription

1 Compliance TODAY September 2015 a publication of the health care compliance association A CPA recounts exponential growth in Compliance an interview with Patricia Bickel Compliance and Privacy Officer; Director, Professional Integrity Program USF Health at the University of South Florida See page A growing voice in the compliance chorus: The Department of Justice Criminal Division 33 Do you have an effective compliance program? 41 The anatomy of a DLP incident: Using automation to improve compliance 47 The changing nature of compliance under payment for quality and cost effectiveness Tony Maida Mary Ellen McLaughlin Eric J. Moriak Paul R. DeMuro This article, published in Compliance Today, appears here with permission from the Health Care Compliance Association. Call HCCA at with reprint requests.

2 by Eric J. Moriak, CISSP, CISM, CISA, CIA, CGEIT The anatomy of a DLP incident: Using automation to improve compliance Data Loss Prevention (DLP) and Security Information and Event Manager (SIEM) are tools a covered entity can use to protect its electronic protected health information (ephi). When considering a deployment, procedural considerations are as important as the technology itself. Creating the right policies for monitoring will either make or break your program. The cost of implementation does not stop with the technical deployment. Implementation is the first step in an iterative process. Eric J. Moriak ([email protected]) leads the IT Audit function for Children s Health System of Texas (CHST) in Dallas. He has more than 30 years of experience in IT Applications Development, Information Security, Systems Programming and IT Audit. Moriak Covered entities often face challenges regarding the control and monitoring of electronic protected health information (ephi) and personally identifiable information (PII) 1 throughout their organizations. This data is often created, received, maintained, or transmitted in a variety of applications, and it also has many opportunities to move either internally or externally via the organization s network. Depending on the type of data involved, there are a number of regulations that speak to how this data should be secured and monitored for appropriate use, including the HIPAA Privacy and Security Rules 2,3 and Payment Card Industry Data Security Standard (PCI DSS). 4 Inappropriate distribution of this information could trigger breach notification requirements and may have to be reported. These breaches could also result in either penalties or fines. Breaches are likely to remain undetected if not captured at the point when the incident occurred. If a breach were to occur and appropriate monitoring tools have not been deployed, then the provider could be potentially viewed as being negligent in regard to their monitoring activities. Fortunately, there are tools that can assist a covered entity with their monitoring responsibilities. Tools such as Data Loss Prevention (DLP) 5 and Security Information and Event Manager (SIEM) 6 can be critical resources to help ensure compliance. However, as with so many other tools or applications, the technology by itself is not a silver bullet. A successful monitoring program depends on several factors beyond just the technology itself. Some of the less obvious items include, but are not limited to: Supporting policies Training of employees A dedicated incident response team (IRT) Escalation procedures Trained investigators

3 DLP and SIEM defined So what are DLP and SIEM? DLP, simply put, is a tool that is designed to protect an organization from a potential data breach. It accomplishes this goal by monitoring data in the environment. Data monitoring is broken down into three categories. They include data that is either in use, at rest, or in motion. Data that is in use is data that is being acted upon. An example would be when you write data to a USB drive. As that data is being written, the data is considered in use. Data at rest can be thought of as an Excel spreadsheet that is stored on a network share. It exists in the environment, but is currently unused or static. Data that is in motion is that data that is currently traveling across the network. This traffic can have either an internal or external destination. The DLP solution should be deployed in a manner that helps the organization to monitor the environment for those incidents that management wants to detect. This implies that there is a strategy to the deployment. For example, in the instance of a healthcare provider, you would want to monitor for inappropriate disclosures of ephi. Placing the DLP engine at the network s egress points allows the provider the opportunity to detect both inbound and outbound traffic for ephi and to take a predefined action. However, the ability to identify ephi is also up to the provider to define. If the DLP policies have not been defined correctly, then the ability to properly identify incidents will be limited or the possibility of false positives can increase exponentially. SIEM can easily be thought of as centralized log management. It provides real-time analysis of log data for events that are written into your system s logs (e.g., security alerts). Depending on your organization s requirements, every computer produces one or more logs. These logs record the activity on the computer, and they are constantly updated as new events occur. The ability to search logs for an incident is severely limited when a SIEM solution is not in place. A SIEM gives you the ability to correlate log information in order to monitor and/or research incidents. Without a SIEM, every computer with a log would have to be researched individually. A SIEM simplifies this task and improves overall compliance by providing a single point of reference for all log data. As with DLP, SIEM also requires a strategy before it should be deployed. Ensuring that the organization has identified all of the log events it wants to capture is the first step, ensuring that log files have sufficient space requirements is yet another. Other considerations and additional steps include having a policy that requires systems to perform logging consistently, that all computers are defined to the SIEM, and that the SIEM sweeps logs on an appropriate frequency. In short, both of these tools require forethought prior to their implementation, or the results will likely fail to meet the organization s expectations for compliance. The reason that SIEM is referenced in an article regarding DLP is that these tools complement one another. If DLP detects an incident, the SIEM logs can often provide additional detail. General considerations The decision to implement either of these technologies is only the first step to consider when developing your compliance program. There are several procedural questions that should also be considered in advance: Do you have policies in place that speak to sanctions and escalation processes if management s expectations around data loss are violated? Do your HR and legal staff agree with the DLP policies you are planning to use?

4 Can an incident result in disciplinary action up to and including termination? Does your organization inform staff that they should have no expectation of privacy and that all of their activity on the network and related systems is being monitored? How are expectations of staff communicated and on what frequency? What type of education does your organization provide in regards to your monitoring activities? Besides these questions, the impact on manual processes should also be considered. Although your IS department will likely be responsible for the infrastructure (i.e., hardware, configuration, version control, patching, etc.), who is the business owner of these tools? The assignment of a business owner will help define who is responsible for making the decisions about what the organization should be monitoring for, who should monitor, and how incidents should be acted upon. IS should not be, and is typically not, the business owner. The business owner should be responsible for developing, testing, and promoting new or updated DLP policies and clearing these through management. The business owner should also follow established change management procedures whenever a change is made to a DLP policy. IS should manage the infrastructure, but as with the other applications they support, they should not be the business owner. The incident response team Another key consideration is the establishment of your incident response team (IRT). This is the organization s first line of defense for incoming DLP incidents. This group reviews incidents as they are identified by the tool and filters out false positives. Once an incident is assessed and has been found to warrant additional review, it is escalated to the organization s investigators. The IRT should be tasked with developing effective strategies to deal with false positives and with confirming that these approaches meet the business owner s expectations. Because initial volumes of incidents can be overwhelming, having effective filters will assist your program in identifying those incidents of greatest interest. Consider the demographics of where your incidents are coming from. If areas of exposure consistently come from the same area, you may have identified an area for targeted education. Other items you should consider include: Documenting your monitoring program; Training staff to perform effective investigations; Ensuring consistency between your investigators; Maintaining the evidence trail and understanding how the evidence is going to be handled; Formally identifying the business function responsible for performing the investigations; and Monitoring the team for success and identifying the metrics to be used. Finally, because the IRT is responsible for analyzing the volume of identified incidents, they are often a valuable resource in identifying new or revised DLP policies that the organization should consider. Policy management In an effective DLP environment, there are two types of policies that should be discussed. The first is your traditional policy that defines management s expectations. Depending on your organization, these can take different forms. Some common examples that would tie into the monitoring program may include your organization s code of conduct. This might be where staff is formally notified of

5 the organization s expectation surrounding privacy (or lack thereof) with computer usage and the organization s intent to monitor and network traffic. Other policies might include your sanctions policy, an escalation policy, data security, etc. The other type of policy is one that is defined to the DLP engine itself. These DLP policies effectively tell the application what data is being monitored for. It is also important to consider the manual controls over DLP policies. For example, change control needs to be in place whenever policies need to be updated. Controlling and communicating when a change to a policy is promoted into production is critical. Without this control, assumptions over how an incident was identified may occur. Consider a situation where a policy is updated multiple times in the same week; in this case, the investigator may not know what policy was in effect and he/she may be expecting different results. Furthermore, policies should have some form of version control. Being able to know what policy was running at the time of incident capture enables the organization to re-create the detection. If a legal challenge were to ensue, the ability to recreate the event detection will be important. Getting started Before you start with your monitoring activities, there are five basic questions you need to consider. These are: What do I want to search for? Why do I want to search for it? When does my program need to be operational? If a legal challenge were to ensue, the ability to recreate the event detection will be important. Where do I want to search for the data? How do I want to search for it? These questions are part of an iterative process. As with any lifecycle, you start with understanding your risk and regulatory requirements. You then develop your policies and procedures to detect potential incidents, assess results, perform remediation where required, conduct education and awareness, and then re-assess. No matter how much you communicate, there will be people who think they won t be detected and that their network activity is private. It is up to your organization s culture as to how (or if) you communicate the impact of your monitoring program. Either way, the word will get out. Reporting So you ve implemented your DLP solution, written your organizational and DLP policies, set up your IRT, deployed the technology, and now you are looking at your first incident. What do you do next? Consider who you are dealing with. Is it a staff member, a vendor/contractor, a physician, or even someone from executive leadership? Do you have a zero tolerance policy for certain incidents, a three strikes, you re out approach, or do you need to consider different approaches for different populations of people? Consistent application of the program is critical. Do not make these decisions in isolation. Make sure you have HR, Legal, and executive management support. You should also consider what type of incident you are dealing with. Differentiating

6 incidents, such as those with or without merit, will affect how you respond. Issues without merit may only require re-education, but issues with merit may require a higher degree of response. After reviewing the incident, you should also consider reviewing the SIEM logs if the investigation warrants additional research. The logs could contain additional evidence for your investigation. Your process should also address notification. Does the investigator approach the individual first, their manager, or a higher level? If the incident leads to disciplinary action or termination, when do you involve HR or Legal? If an incident results in a data breach, at what point in the process do you notify your privacy officer? Will you be able to comply with breach notification requirements? Finally, how do you respond if the incident were to point to some form of illegal activity or a violation of personal conduct? At what point do you notify your public relations officer or other external authorities? Operational considerations So what are some of the operational considerations of implementing these tools? For a SIEM, ensuring that each member server is consistently collecting the same events is critical. Also, ensuring that local log files are configured with sufficient space is another key concept. Another point that can easily be missed is ensuring that all servers participate in the solution. In today s environments (especially when that environment is highly virtualized), servers can be introduced and/or deleted on the fly. Making sure all servers participate in the SIEM can be an ongoing struggle. Establishing a log retention procedure and having it documented should also be considered. Establishing appropriate access to either DLP or SIEM is also important. Both capture large volumes of data; however, these tools only capture what you ask of them. For a DLP deployment, you ll need to consider how you manage that data once it has been collected. Do you distinguish between captured incidents versus escalated incidents? Do you save them both? Do you differentiate between escalated incidents that are found to be with or without merit? What happens to an incident when there is an open investigation and the incident itself has exceeded its retention requirements? What is the impact on DLP case numbers if you delete data? In some systems, incident numbers will reset. Before you delete data, have you tested your ability to restore it? Managing the volume of data on either system will need to be a point of consideration. Summary DLP and SIEM are essential tools for developing an effective monitoring program. They come with an expectation of a defined strategy and dedicated resources. Whether you are attempting to control ephi, PII, or some other form of data, without a proactive approach towards monitoring, I guarantee that you are leaking data. You just don t know where. 1. National Institute of Standards and Technology, U.S. Department of Commerce: Special Publication Guide to Protecting the Confidentiality of Personally Identifiable Information (PII). April Available at 2. U.S. Department of Health and Human Services, Office for Civil Rights: Summary of the HIPAA Privacy Rule. Available at 3. HIPAA Security Rule is located at 45 CFR Part 160 and Subparts A and C of Part PCI (Payment Card Industry) Security Standards Council: PCI SSC Data Security Standards Overview. Available at 5. SANS Institute InfoSec Reading Room: Data Loss Prevention. August Available at 6. SANS Institute InfoSec Reading Room: Successful SIEM and Log Management Strategies for Audit and Compliance. November Available at