Eric Moriak - CISSP, CISM, CGEIT, CISA, CIA Program Manager - IT Audit Children s Medical Center Dallas. Dallas, Texas

Transcription

1 Eric Moriak - CISSP, CISM, CGEIT, CISA, CIA Program Manager - IT Audit Children s Medical Center Dallas Dallas, Texas

2 Objectives The purpose of this presentation is to develop a general awareness of DLP/SIEM functionality and how it has been used in a healthcare environment. Analyze actual scenarios of incidents that were detected and investigated through the use of these tools. 2

3 Outline The following topics will be covered: What are DLP & SIEM and how has Children s deployed them General Considerations What process considerations are needed during a deployment Process Documentation IRT Policy Management Incident Investigation What parties should be involved Data retention What do they capture and how do you manage it SIEM and DLP False Positives Where do you start? What is the impact on the security environment and the organization as a whole Case Studies DLP as a preventative control Inappropriate Images PHI Detection 3

4 What is DLP? A Data Loss/Leak Prevention solution is a system that is designed to detect potential data breach / data ex-filtration transmissions and prevent them by monitoring, detecting and/or blocking sensitive data while in-use (endpoint actions), in-motion (network traffic), and atrest (static data storage). In data leakage incidents, sensitive data is disclosed to unauthorized personnel either by malicious intent or inadvertent mistake. Such sensitive data can come in the form of private or company information, intellectual property (IP), financial or patient information, credit-card data, and other information depending on the business and the industry. Wikipedia 4

5 What is DLP? Continued DLP software can often be thought of as a large text string search engine. Policies are defined to the tool that identify what should be searched for and how it should be responded to. This could include involve simply reporting an incident, blocking an incident, or taking additional action such as re-routing for encryption purposes. Placement of the Enforce server should depend on where you believe data can potentially be lost. Proper design of the supporting infrastructure help establish what the solution can monitor or scan. At Children s, we monitor data in-use, in-motion and at-rest. 5

6 What is DLP? Continued 6

7 What is SIEM? Security Information and Event Management (SIEM) is a technology that provides real-time analysis of security alerts generated by network hardware and applications. SIEM is sold as software, appliances or managed services, and are also used to log security data and generate reports for compliance purposes. Wikipedia SIEM provides for centralized log management and analysis. The information available within the SIEM is dependent on the events that are captured on the servers from which logs are centralized. Without adequate event management, consistency of events across participating servers and sufficient log retention policies, the benefit of a SIEM solution can be severely hindered. 7

8 What is SIEM? Continued At Children s, SIEM provides for centralized log management and analysis. The information is correlated and used for both metrics and monitoring purposes. SIEM can only collect events that are captured on the local servers and before log files are centralized. Without adequate event management, consistency of events across participating servers and sufficient log retention policies, the benefit of a SIEM solution can be severely hindered. 8

9 What is SIEM? Continued Why mention SIEM in a DLP presentation? Once DLP has detected an event and a decision has been made to launch an investigation, log evidence can often be used to further substantiate the case that is under review. Consider a person who has been found ing inappropriate images. A review of the websites they have visited can often reveal additional information upon which an ultimate HR decision can be based. 9

10 What is SIEM? Continued 10

11 General Considerations Does your organization inform staff that they should have no expectation of privacy and that all activity on the network and related systems are monitored? Do you have policies in place that speak to sanctions and the escalation of response if policies are violated? Can an incident result in termination? How are these expectations communicated? What education does your organization provide in regards to these topics? Is your HR and Legal staff in agreement with the DLP policies you are using? 11

12 Process Considerations Without proper planning, a DLP/SIEM solution will not be successful. These are not technologies that you simply install and turn on. They require a significant amount of resource to support and monitor. Let s consider: Who will be responsible for the infrastructure, configuration, patching and release management of the environment? Who is the business owner of the solution? Who is going to be responsible for policy development, testing and implementation? What change management processes will be followed? Who is going to be responsible for initial incident response review? (IRT Incident Response Team) How are false positives going to be responded to? Initial volumes on new policies can be overwhelming. Are you going to review 100%, filters, or are you going to sample results until the policy is ultimately tuned or behavior is modified? 12

13 Process Considerations Continued Who is going to do incident investigation in the case an issue requires additional review? What type of process do you have to conduct investigations and document the work that is performed? Is there oversight in regards to the incidents being reviewed? At what point are HR, Legal, and/or Executive Leadership drawn into a substantiated incident? Are your processes documented? What are your internal SLA s? 13

14 Process Considerations Continued Let s take a look at the IRT (Incident Response Team s) responsibilities: First Line of Defense for incoming DLP incidents Assess all new incident types on a daily basis Develop sampling criteria where excessive volumes exist Eliminate false positives Escalate incidents which require additional review Develop management reports on metrics and trends (i.e. endpoint, , instant messaging, and network volumes) Propose new policies and/or revisions to existing policies 14

15 Process Considerations Policy Management Effectively, there are two types of policies that need to be considered: DLP Policies for detection purposes Retention of DLP policies (current and historical) Change Management Policies for server maintenance, application upgrades, and DLP policy administration Who authorizes the use of new/modified policies? Are test platforms used? When a new policy is implemented, how does the organization want to deal with the increased volumes of data? Who is the Business Owner for the applications (DLP & SIEM)? Policies and Procedures for administrating the program Sanction Policies? Code of Conduct - notification regarding user expectation s of privacy and organizational monitoring of network traffic Process documentation and flows CODE of ETHICAL CONDUCT 15

16 Process Considerations Continued So you have a detected incident what next? Here are some thoughts you should consider: Are the processes within your IRT consistent and documented? Have you removed any perceptions of bias from your escalation protocol? Who is actually charged with the responsibility of performing the investigation? Are their processes documented? Are they trained in performing an investigation? Would their evidence stand up in court? Are processes consistently followed between investigators? Do investigators document consistently? Does a standard exist in regards to what evidence needs to be collected? How do you preserve the chain of evidence? Is there a review or approval of a recommended course of action before it is implemented? By investigators and the affected leaders? Does your organizational leadership support the processes you follow? If HR, Privacy or Legal assistance is required, have they been involved in the development of the process and are they also in agreement with approved action before it is taken? Is the investigation process audited and reviewed? Does your process give you sufficient time to meet established SLA s (HIPAA - Breach Notification Requirements?) 16

17 Process Considerations Continued Depending on the incident, you may have to involve different groups. Besides the previous references to HR and Legal, what might some other groups be that may need to be involved? Always include the leadership of the area where an investigation is being performed. Do not inform them afterwards. (However, an exception could exist if the individual in question is also a leader.) Do you include the individual about whom the investigation is focused? It depends, you may want to gather/collect all evidence before you involve/confront the individual in question. You may need to coordinate with either your physical security personnel and/or facilities personnel if you need access after hours. Do you need to include media/public relations in case there is a potential that the issue gets out to the general public? Do you need to inform executive leadership in regards to issues of a sensitive nature or where a zero tolerance expectation has been breached? Do you need to reach out to external authorities; police, Homeland Security, FBI, etc. 17

18 Process Considerations Continued How long do you need to retain your DLP and SIEM information? HIPAA typically requires Data Retention of evidence for seven years. But as DLP, and especially SIEM, can generate huge volumes of data you need to consider the following: SIEM First, are local server logs retained long enough and is their sufficient storage locally to ensure all log data can be collected by your SIEM? How long do you store log data on disk before moving it to recoverable media? Who has access? Do you ever purge data? Do you have a policy? DLP Do you distinguish between captured incidents and escalated incidents and their retention requirements? Do you differentiate between escalated incidents that are found to be with merit and those that are found to be without? What is the impact on DLP case numbers? Could you restore data? 18

19 What Do the Tools Capture? These tools only capture what you ask them to so, do not think that this is technology that you install and walk away from. SIEM As SIEM only consolidates and correlates log data from member servers, it is up to you to ensure that all servers are; defined, are consistently capturing the events your organization is interested in and that there is sufficient storage for logs on the local server. If the logs are set to over-write before SIEM consolidates them, then that data will not be available for correlation. DLP You must understand what you want to get out of your DLP system before you purchase one. Whether you are targeting Personal Health Information, Payment Card Information, or some other form of critical/sensitive data it is up to you to know: What do I want to search for Why do I want to search for it When do I have to have the tools running (Planned implementation vs. Immediate) Where do I want to search for data How do I want to search for it 19

20 Getting Started Best advice, Walk Before You Run. Do not try to Big Bang these tools. Modified ISACA Presentation: 2013 ISACA Webinar Program 20

21 Dealing With False Positives Typically, new DLP policies can generate an exponential increase in the number of incidents that need to be reviewed. This is especially true if you are trying to change the culture of the organization via DLP. Consider this If you are dealing with new DLP policies, look at approaches that would help you categorize the incidents by type, department/unit, geographical location, etc. Then consider whether any of these groupings represent valid business purposes. If not, start working with the remaining groups from largest to smallest. You can impact culture more quickly by working with those groups that generate the highest volumes of incidents first. Also consider working with the leaders to address the unit as a whole not with just the individuals who were detected. 21

22 Dealing With False Positives Continued If you are dealing with existing DLP policies, consider developing a White List of groups that just simply develop noise. Note recognize that you can either exclude these groups within your DLP policy, but if the list is extensive external filters may be more appropriate. This can reduce the number of false positives you would otherwise have to consider. 22

23 Impact on the Security Organization What are some of the responsibilities that the Security Organization is going to have to face? DLP DLP Policy Testing and Change Management (Approvals and Validation) IRT Resource considerations (Are there backup resources?) Process Documentation (Does it exist?) Escalation protocols who gets notified in a breach scenario, HR incident, etc. SIEM Introduction and retirement of servers and the impact on SIEM log consolidation Resource considerations Consistency of log configurations on member servers (events captured and log size) Both Configuration Management Server and Application Release and Patch Management Access management to both tools 23

24 Organizational Impact The following are some of the considerations you ll deal with when considering organizational impact. First response is, OMG!! THEY ARE WATCHING US! No matter how much you communicate, there will be people who will think that 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. It s elementary 24

25 Organizational Impact Continued The organization will not measure the success of a DLP deployment by its technical topology, the volume of incidents detected or even the stability of the platform. You will be measured on how you deal with the events and the overall organizational change you cause as a result of your process. The technology only enables the process. Not acting upon an incident is unacceptable. So why do it? Always remember, any incident could potentially be a breach scenario. Compliance with regulations (PCI, HIPAA, etc.) Properly configured, the tool can act as a safety net for network traffic Consider the demographics of where your incidents are coming from. If areas of exposure consistently come from the same area, you ve just identified an areas for targeted educational opportunities 25

26 Example of Organizational Impact The following graph shows the growth in outbound encrypted s since implementing an aggressive outreach and educational campaign based on detected DLP incidents. 26

27 Case Study #1 Detecting PHI In Children s monitor s all outbound SMTP traffic for PHI. There are multiple policies for PHI (including specific PHI values from our EMR system), images, SSN values and even certain literal values. 27

28 Case Study #1 Detecting PHI Using DLP as a preventative control So, at Children s DLP is also setup as a preventative control. We ve deployed the technology in such a way that it evaluates all outbound for the presence of PHI from our EMR system. The Subject Line, Message Body and attachments are included in the scan. If the policy detects PHI, the is automatically re-routed through our encryption software before the SMTP traffic leaves our Exchange environment. It is as if the user had selected to send the securely. 28

29 Case Study - #1 Detecting PHI 29

30 Case Study - #1 Detecting PHI 30

31 Case Study - #2 Inappropriate Images At Children s there is a zero tolerance policy for accessing, storing or transmitting inappropriate images on our network. As a result, a DLP policy has been established that detects All images. Note - The technology cannot differentiate between appropriate and inappropriate images. As a result, all images are pulled. Once that population has been identified, filters are used to limit the number of incidents that need to be manually reviewed. Filters exclude incidents that are associated with White Listed applications or sites. So, let s consider the follow picture as an inappropriate image that was detected on a file upload. 31

32 Case Study - #2 Inappropriate Images Please meet Dippin Dots Let s consider how an upload of her image would be detected. 32

33 Case Study - #2 Inappropriate Images 33

34 Case Study - #3 DLP vs. IM At Children s, we also monitor our Instant Messaging (IM) environment for other activity. Policies that focus on potential harassment situations, inappropriate language, threats, and other forms of inappropriate staff communication are also monitored. This required some consideration in regards to the deployment of the IM environment as well. Session logs are only stored on the server. Local chat logs are not allowed. As IM sessions can also be discoverable in a legal suit, chat logs are only retained for 30 days and until a monthly assessment of activity has taken place. Log reviews are performed monthly, and evidence of the reviews are retained for seven years. This process helps ensure that the organization is doing their due diligence in regards to detecting and potentially preventing employee harassment. Chat logs would only be retained if the possibility of a law suit was elevated. 34

35 Case Study - #3 DLP vs. IM 35

36 Summary DLP and SIEM are extremely powerful tools. In a Healthcare environment, they are an essential control for ensuring that ephi is not inadvertently leaving your organization. Without a proactive approach towards monitoring I guarantee that you are leaking ephi. you just don t know where. 36

37 Questions?