responding to data breaches · 5/4/2010 · responding to data breaches can be a complex and...

Office of Information Technologies

NERCOMP SIG Amherst, MA

4 May 2010

Responding to Data Breaches

2 Office of Information Technologies

Session Description

  Data security and privacy are focal points in many institutions' information security programs. There is a complex set of legal and regulatory frameworks for protecting data that we are entrusted with. Responding to data breaches can be a complex and challenging process for even well seasoned information security professionals. During this session we will discuss the current legal and regulatory environment, instituting controls to reduce the likelihood of data breaches, and incident response planning for if (or when) data breaches do occur.


Agenda

  8:00am - 9:15am Registration and Coffee   9:15am – 10:30am Overview of Data Breach

Legal and Regulatory concerns   10:30am – 10:45am Break   10:45am – 12:00pm What Happens Next:

Approaches to Responding to a Breach   12:00pm – 1:00pm Lunch (included)   1:00pm – 2:15pm Open Discussion   2:15pm – 3:00pm Q&A   3:00pm Evaluations and End


Data Breach Legal and Regulatory concerns

  I am (thankfully) not a lawyer, and this is not legal advice…however…

  Laws and regulations govern an exceptional amount of our current day-to-day tasks in information security

  Once upon a time I actually logged in to routers and servers…

  Now I spend as much time in legal counsel’s office as I used to spend on the router…


Data Breach Law 101

•  Federal Legislation •  FERPA, GLB, FACTA, HIPAA, HITECH

•  State Legislation •  46 different state security breach laws •  In Massachusetts, MGL Ch. 93H

•  University Policies •  Data Classification, Handling, etc

•  Industry Regulations •  PCI-DSS

•  Research Restrictions •  FISMA, ITAR, EAR, etc.


Sensitive Data: Federal Law

  Each statue imposes specific requirements •  This is not intended as a comprehensive review of

federal legislation

  FERPA (Education records) •  students’ academic, personal, and financial information

as described in the relevant campus Academic Regulations or equivalent

  HIPAA (Health information) •  individually identifiable information related to a person’s

physical or mental health. This applies to any past, present, or future condition, treatment, or payment of health care service Protected Health Information (PHI)

•  Do you know if you are a covered entity?


Sensitive Data: Federal Law, Cont’d

  GLB (Financial records) •  students’ and parents’ records including names,

addresses, phone numbers, bank and credit card account numbers, credit histories, or social security numbers as they related to student financial aid information

  FACTA (“Identity theft red flags”) •  program requires financial institutions and “creditors” to

develop programs to identify, detect, and respond to “red flags” in “covered accounts” suggesting identity theft •  “creditors” •  “covered accounts” •  “identifying information”


HIPAA


HITECH act

  Health Information Technology for Economic and Clinical Health (HITECH) Act •  Guidance Specifying the Technologies and Methodologies That

Render Protected Health Information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals for Purposes of the Breach Notification Requirements Under Section 13402 of Title XIII (Health Information Technology for Economic and Clinical Health Act) of the American Recovery and Reinvestment Act of 2009;

  Interim final rules implementing HITECH Act provisions in two areas have already been issued and are currently in effect: enforcement and breach notification.


HITECH continued

  Civil penalty amounts apply to HIPAA Privacy and Security Rule violations occurring after February 17, 2009.

  Covered entities and business associates must comply now with breach notification obligations for breaches that are discovered on or after September 23, 2009. •  Do you know if you have any business associate

agreements with covered entities?

http://www.hhs.gov/ocr/privacy/hipaa/understanding/coveredentities/hitechblurb.html


Key HITECH points of note

  Timeliness of Notification •  Except when law enforcement requests a delay,

Covered Entity to send required notification •  without unreasonable delay AND •  in no case later than 60 calendar days after the date

the breach was discovered.

  Business Associates •  Business Associates must provide notification of breach

of unsecured PHI to Covered Entity “without unreasonable delay and in no case later than 60 days following discovery of breach.”


PCI-DSS Notification

  While PCI-DSS does not prescribe incident response procedures, Visa’s CISP does:

  Immediately contain and limit the exposure.   Alert all necessary parties immediately   Provide all compromised Visa, Interlink, and

Plus accounts to your merchant bank within 10 business days. •  Within 3 business days of the reported compromise,

provide an Incident Report document to your merchant bank

http://usa.visa.com/merchants/risk_management/cisp_if_compromised.html


Massachusetts Data Breach Law

  “An Act Relative to Security Freezes and Notification of Data Breaches” •  Creates several new chapters of M.G.L.

  The law: •  Defines “personal information” •  Defines “breach of security” •  Requires immediate notification to those

individuals whose “personal information” has been compromised as a result of a “security breach.”


Chapter 93H: Who and What is Protected?

  “Resident of the Commonwealth” (M.G.L. c. 93H, §§ 1, 3)

  “Personal Information” •  an individual’s name in combination with any

of the following: •  Social Security Number •  Driver’s License Number •  State Identification Card Number •  Financial account number, credit or debit card

number (M.G.L. c. 93H, § 1)


Chapter 93H: What Are We Protecting Against?

  “Breach of Security” •  unauthorized acquisition or unauthorized use

of unencrypted data or, encrypted electronic data and the confidential process or key that is capable of compromising the security, confidentiality or identity of personal information, maintained by a person or agency that creates a substantial risk of identity theft or fraud against a resident of the commonwealth. (M.G.L. c. 93H, § 1)


MGL 93H: What Happens When A Breach Occurs?

  Provide “Notice” •  Notice obligation triggered when agency

knows or should have known of •  “breach of security” -or- •  that the sensitive data “was acquired or

used by an unauthorized person or for an unauthorized purpose” (M.G.L. c. 93H, § 3(b))

  “Breach of security” versus data “used”


MGL 93H: What Happens When A Breach Occurs?

  Notice must be provided “as soon as practicable and without unreasonable delay” (M.G.L. c. 93H, § 3)

  Notice requirements differ by how agency handles data (M.G.L. c. 93H, § 3)

•  “Maintain” or “store” •  “Own” or “license”

  If “own” or “license” data, notice to AG, director of consumer affairs and business regulation, and MA resident (M.G.L. c. 93H, § 3)

  Content of notice depends on how agency handles data (M.G.L. c. 93H, § 3)

  Enforcement ??


Approaches to Responding to a Breach

  So, you have had a data breach, now what? •  What do you do to investigate if a breach occurred?

•  Is a virus infection a data breach? •  How do you effectively engage the community?

•  Training •  Delegated Authority

•  Notification •  Internal direction •  Public notice


How we got here

  Due to the number of information security reports originating from computers located on campus it became necessary to:

•  Document incident response procedures to work in conjunction with home grown software system

•  Expedite identification, investigation, remediation •  and if necessary, Develop notification procedures to

insure compliance with University policy as well state laws that pertain to sensitive data.


History..

  Prior to deployment of many data breach statutes, we develop informal workflow to notify academic staff of virus infected computers •  Identified via ePO, REN-ISAC, etc

  Procedure involved first shutting off switch port   System owner lookup procedures using Remedy

jack tracking and ticketing systems   Generally a telephone call from me…


After passage of MGL 93h

  Focus turned to identify a combination of:

•  compromised system + sensitive data

  A compromised system alone, while needing care and attention, did not run afoul of statute…

  However, far too many of our systems contained sensitive data. •  I will cover our sensitive data handling procedures later

(time-permitting)


University policies

  While many of our procedures pre-date formal University policies, having the policies has assisted with the enforcement of the procedures

  Most impacted staff have been fully helpful, and many have become strong allies in mitigating information security risk campus-wide

  Our data breach procedures were a logical maturation of previous information security policy


Incident Response Procedures

  Contain/Quarantine suspected compromised system

  Preserve an image of the local disks   Identify any sensitive data that may have been

exposed •  If sensitive data may be at risk:

  Identify and assess malware   Complete technical report outlining the findings

above   Work with legal counsel, internal audit, etc to

assess risk and take appropriate actions



  One important condition to make the process both efficient and effective is determining who has responsibility and/or authority over the suspected compromised system

  We currently use a two-class system that drives our incident response procedures

  While this may not fit all campuses, it works for our purposes



  In the course of formally documenting incident response procedures, we identified several distinct classes of networks: •  Academic Managed •  Academic Default •  Residential Default

  These are internal terms that define whether the computer is owned by the University or if it may contain University owned data

  While compromises or undergraduate student/residents computers are a serious issue, they are generally out scope for our breach procedures



  We developed a DNS and/or Subnet based cross-walk table identifying who to contact in the case of an incident

  Due to the highly fractionalized IT support infrastructures on campus, understanding who is responsible for what is one of the most challenging tasks •  Especially on a large, research campus

  This required us to focus on consistent handling procedures, regardless of which group supports the departments IT needs


Incident Response Definitions

  Academic Managed domains are those academic or staff departments that are managed via their own support infrastructure. For identification of an academic managed network see internal contacts list.

  Academic Default domains are all academic networks that are not listed as Academic Managed. If the source IP address is in an academic domain, but it is not listed in Incident Response Contacts as an Academic Managed then the network is classified as Academic Default.


Academic Default

  For departments without previously known IT support staff, we process these incidents through our help desk

  These procedures remain a work in progress, but we have an existing workflow

  Built from our historical workflows for handling DMCA complaints and compromised student computers •  These procedures were born out of the bad old days of

Code Red, Nimda, etc.


Academic Default Containment

  In general, we shut the switch port off first for academic default cases •  As a risk reduction step

  Notification is provided to the help desk via Remedy functionality (homegrown workflow)

  Help desk uses additional meta-data to identify some responsible party •  Often located by seeing who is paying the bills for that

jack

  Results is in a call from the Help Desk


Academic Default

  When the suspected compromised system arrives at the help desk:

  Ticket is sent to our Software Support group (tier2 help desk)

  Suspected system is handled by full time staff, not students

  Normalized data gathering procedures to identify sensitive data

  Reports sent back to campus Information Security Office


Academic Managed

  In departments with known IT support staff, we generally notify the department before shutting off any switch ports

  This has proven to be a more effective means of both trust building and risk reduction

  The same generalized procedures above are followed, but some responsibilities are delegated to the departmental IT staff

  While a work in progress, we have had excellent engagement from the campus and positive feedback


Example Contact Information

  We use a combination of IP address, DNS suffix, ADS domain, and physical building location to identify hosts

  This is a bit more art than science, but thankfully is no longer just in my head

•  Which was part of our previous processes


Documenting procedures

  All of our current incident response procedures are posted on the OIT website

  These are the public-facing parts of the process that we use for consistency, as well as for awareness and training

  This material represents the work of many individuals across campus

http://www.oit.umass.edu/security/incident/index.html


Documented Incident Response Procedures

  Respond to Data Security Incidents   IT Administrators need to notify OIT if any of the

following occur in their department. Note: Faculty and staff should contact their departmental IT Administrator. If your department does not have an IT Administrator, contact the OIT Help Desk immediately.



  Computing Devices Compromised by Malware (Most Common)

  These include departmental or personal devices that may contain sensitive data. If a server is compromised, contact [email protected] for instructions.

  Conduct a preliminary analysis using the Malware Incident Response Checklist - or - contact OIT as soon as possible.

  Submit an Incident Report to [email protected].



  Computing Devices Accessed without Authorization (Non-Malware)

  These include University devices accessed without permission - stolen or compromised credentials, credentials lost to phishing scams, and other attempts to access a device without authorization (e.g., former employees, etc.).

  Submit an Incident Report to [email protected].



  Lost or Stolen Computing Devices   These include departmental laptops, USB drives,

cell phones, or other devices that may contain sensitive data, or personal computing devices with sensitive University data.

  Contact the UMass Amherst Police.   Submit an Incident Report to

[email protected].



  General Incident Response Procedures   IT Administrators who suspect a data security

incident in their department or who were notified of a potential incident need to complete the following steps: Note: This is a general overview of the incident response process. Depending on the complexity of the incident, additional steps may be required.

  (Optional) Preliminary Analysis: If this is a malware infection, perform a preliminary analysis using the Malware Incident Response Checklist.



  Incident History: Gather the incident details, including symptoms and how you first responded.

  Incident Report: Contact [email protected] if OIT first notified you of the incident, sensitive data was stored on the compromised device, or you cannot rule out the presence of sensitive data on this device. A report is required even when encryption is available on the affected device.



  If the incident is confirmed:   Forensic Analysis: OIT will perform an in-depth

forensic analysis of the compromised device (if the device is available).

  Legal Counsel Review: The University Legal Counsel will review the incident to determine the University's legal obligations.

  User Notification: The University is required to notify the individuals whose personal information may have been compromised as a result of this incident. Not all incidents will result in a notice obligation.


Malware Incident Response Checklist

  Use this checklist for your preliminary analysis. Through the entire process, it is critical to: •  Keep detailed notes. Depending on the severity of the

incident, you may have to provide details about the incident, including how you first responded, to other staff, management, University Legal Counsel, or Internal Audit.

•  Minimize system changes. Keep the system intact as changes can destroy valuable data related to the incident. Do not power off, run anti-virus software, or attempt to back up data.

  Contact [email protected] if you need assistance with any of the steps below.



  1. Gather volatile information while the system is running (if possible)

  Document any open network connections, running processes, logged-in users, and connected drives. Capture an image of the computer’s memory.

  2. Shut the system down & preserve hard drive data

  You need to shut the system down before completing the next steps.



  Option A: Get a forensically-sound copy of the hard drive

  Get a forensically-sound 'bit-by-bit' copy of the affected hard drive(s) and keep this information until the incident is resolved. You should also preserve an MD5 hash of the original drive(s) and image(s). Note: You will need a hard drive write blocker to complete this step (see details below).



  Option B: Connect the hard drive to a write blocker

  Alternatively, you can connect the hard drive to a hard drive write blocker before performing the next steps. Write blockers enable you to acquire information from a drive without damaging its contents. We recommend Tableau products, available from multiple online retailers.



  3. Run IdentityFinder & a malware detection scan

  With the write blocker in place or after you obtained a forensically-sound copy of the affected hard drive(s):

  Run Identity Finder to determine whether personally identifiable information is stored on this device and where it is located.

  Complete a virus/malware detection scan using your preferred anti-virus/malware application.

  Gather any other information relevant to this incident.



  4. Provide OIT with an Incident Report   You must contact OIT if Identity Finder finds any

personally identifiable information, if OIT first contacted you about this incident, or if you cannot rule out the presence of sensitive data on this device. Email [email protected] the following information:

  Incident history (date, time, symptoms, how you first responded)



  4. Provide OIT with an Incident Report   Identity Finder and malware scan results (if

available)   Host name   IP Address   MAC Address   Building and room number   Your email address and campus telephone

number



  Preliminary Analysis: Findings & Next Steps   If you have completed a preliminary analysis,

these are some general recommendations based on the most common findings. For additional information, contact [email protected].

  Malware and personally identifiable information found Submit an Incident Report (see Step 6 above). OIT will need the compromised device (or the forensically-sound copy) for an in-depth analysis.



  Personally identifiable information found, but no malware Contact OIT for a secondary analysis (additional detection tools may be required). Remove the data if no longer necessary or save it in a safe location (e.g., server). Review the business processes that require sensitive data to be placed in this location.



  Malware found, but no personally identifiable information Review the scope of the incident to ensure other devices are not affected. Change all passwords and complete the appropriate recovery steps for this device. Submit an Incident Report if OIT originally notified you of this incident. Alternatively, email your malware scan results to [email protected] (we'll share them with other IT Administrators).



  No malware, no personally identifiable information You may need to re-diagnose the problem: check the incident symptoms and contact OIT for assistance.



  OIT can help! We can provide assistance with any of the steps below. We can also provide additional information related to an incident, such as network logs or centralized system/application logs (epo, ISS, AD, DNS).

  This is a critical piece of our approach, we engage with and support the departments in complying with our obligations

  Issues of responsibility, discipline, etc are not in scope of this analysis


Motivation…

  Consequences of Mishandling Data Security Incidents

  Responding to data security incidents promptly and efficiently helps protect the University's assets (e.g., data, computers, networks) and ensures compliance with state and federal law, and University policy.

  Under Chapter 93H of the Massachusetts General Law, the University is required to notify those individuals whose personal information may have been compromised as a result of a security breach.


Motivation…

  Consequences of Mishandling Data Security Incidents

  Failure to respond to a data security incident appropriately can lead to:

  Regulatory fines   Legal action   Loss of funding   Loss of reputation

  Most people on campus want to do the right thing


Challenges

  We are delegating substantial authority to these departments to appropriately handle these procedures

  However, they are already in a position of trust as they are often either the owners, stewards, or custodians of the data in question

  We provide oversight to the procedures   Building trust with the campus IT community is

the most critical element to keeping these procedures effective


Data Breach Notification Procedures

  Having a consistent protocol of communication between the impacted entities is important

  As a matter of University policy, we engage:

•  President’s office CIO •  Campus CIO(s) •  Legal Counsel •  Law Enforcement (if necessary)

  As lessons learned, we engage Internal Audit earlier in the process than prescribed by policy


Data Breach Notification Procedures

  Engagement with University Relations/News Office has helped •  Given the media awareness of data breaches, this is a

key relationship to have built before the incident occurs

  Data Breach Notices are legal documents, having departments craft their own may lead to more problems than benefits

  There are deep political and ownership issues that arise when discussing data breaches, you need to learn the context of an organization


Data Breach Procedures

  If a data breach did occur, in many cases filing a police report is an important step •  Under MGL 93h, impacted residents have a right to

obtain this report •  As always, check with your lawyer(s) first


Lessons Learned

  Our network registration procedures in academic networks are currently not effective enough

  Developing an Information Security community of practice for IT administrators on campus has been invaluable •  And inexpensive…

  Our procedures continue to evolve.


Network Registration

  Due to inefficiencies in some of the above processes we are pushing network registration in to all academic buildings

  We have had Netreg deployed for many years in residence halls and classrooms to address these same issues

  Using the same network registration procedures, except that we facilitate bulk or group registrations for academic departments

  Hopefully lowering the staff time commitment to find relevant contacts person(s).


Community of Practice

  Problem: How to engage already overburdened departmental IT staff to help secure campus data

  Solution: Buy them lunch…   Quick lessons learned

•  Buying lunch the first time helped drive attendance, money well-spent…Can probably get away with cookies.

•  Most IT administrators want to do the right thing, they just need some assistance in what that is…

•  Engaging IT staff in the development of the security program increased support and buy in…

•  Having many eyes and ears across campus provides far better detection of business process failure than lots of expensive technology…


Community of Practice

  Compliance obligations frequently change, thus are responses also change. •  e.g. 60-day notice obligation to HIPAA under ARRA

  Regular communications with the campus community helps align practice with obligation

  Given recent funding issues, most of these departmental administrators have little to no travel budget, local training events are often readily welcomed


Training, Awareness, and Prevention

  Using our CoP as a communications vehicle, we have extended much of our training and awareness materials

  Prevent Data Security Incidents   To reduce the likelihood of data security

incidents and prepare to respond if an incident occurs, OIT recommends that IT Administrators:

  Keep an updated inventory of sensitive data in your department. Periodically review your department's business requirements and purge the information that is no longer needed.


Training, Awareness, and Prevention

  Use the protection tools available from OIT. OIT offers departments several enterprise solutions to help manage sensitive data and mitigate potential incidents.

  Develop an incident response plan for the most common incidents. Designate staff members who can act as 'first responders' and keep their contact information readily available.


Protection tools available to campus

  OIT currently offers departments several tools that can help protect departmental computers and data, and mitigate potential data security incidents.

•  Identity Finder to Locate Sensitive Data •  Secunia CSI to Manage Third-Party Applications •  McAfee ePO for Centralized Security Scans •  IBM ISS Firewall to Manage Network Traffic •  Vulnerability Scanning to Prevent Network Attacks


IdentityFinder to Locate Sensitive Data

  IdentityFinder is an application that locates sensitive data (a.k.a. personally identifiable information - e.g., Social Security Numbers, credit card numbers, etc.) on desktops, laptops, servers, and other media. •  Ideal for: •  Keeping an accurate inventory of sensitive data stored

on departmental computers. •  Locating personally identifiable information in case of

data security incidents. •  Removing sensitive data when no longer needed.


Secunia CSI to Manage Third-Party Applications

  Secunia Corporate Software Inspector (CSI) is an application that checks for vulnerable programs and provides direct links to relevant patches and updates. •  Ideal for: •  Identifying vulnerable or outdated third-party

applications. •  Patching and updating third-party applications.


McAfee ePO for Centralized Security Scans

  McAfee ePolicy Orchestrator (ePO) is a centralized system for managing McAfee scans for multiple computers or networks.

  Ideal for:   Identifying viruses, malware, or other malicious

software on departmental computing devices.   Receiving email alerts when malware or other

threats are detected.


Vulnerability Scanning to Prevent Network Attacks

  OIT offers departments two types of vulnerability scanning:

  On-demand scans for departmental networks.   Scans for individual departmental devices (high-

value assets only). These scans are available through a third-party scanning company and cannot be requested on a recurring basis.


Additional Controls

  We are also actively pursuing broader scale Firewall rollouts to key areas that contain sensitive data

  Deployed botnet-focused IDS tools at the campus network border (FireEye)

  Network-based flows are critical to understanding what happened from a data breach.


Detection: Netflow


Detection: Netflow data   srcIP dstIP prot srcPort dstPort octets packets   80.116.163.85 xxx.yyy.131.204 17 3111 1434 404 1   81.3.162.10 xxx.yyy.131.182 17 1514 1434 404 1   200.74.27.228 xxx.yyy.131.246 6 447 8080 40 1   200.74.27.228 xxx.yyy.131.246 6 64068 80 40 1   200.74.27.228 xxx.yyy.131.246 6 50265 3128 40 1   142.179.169.213 xxx.yyy.131.178 17 1126 1434 404 1   213.60.21.96 xxx.yyy.131.171 17 1923 1434 404 1   212.180.2.68 xxx.yyy.131.114 6 63559 41544 40 1   200.29.164.162 xxx.yyy.131.233 17 1051 1434 404 1   202.103.13.62 xxx.yyy.131.35 6 9001 30185 40 1   213.119.233.63 xxx.yyy.131.7 17 1246 1434 404 1   216.51.150.219 xxx.yyy.131.7 17 1157 1434 404 1   24.112.24.160 xxx.yyy.131.122 17 1129 1434 404 1


Additional Lessons Learned

  It has been a long time since my staff has been wanting for work.

  The concern of staff overload is currently a major issue, incident response takes a lot of staff time and can be a stressful environment

  Engagement with legal and audit has been key to successful procedures

  Notification procedures are complicated, political, and nuanced, tread with caution…


Sensitive Data: Compliance

  To comply with state law and allow the University to take appropriate action in case of a security breach, the Office of Information Technologies (OIT) requests that each department takes four steps:

1.   Know what constitutes sensitive data 2.   Keep what’s necessary, purge what’s not. 3.   Identify the workstations/servers that contain

sensitive data in your department. 4.   Designate a ‘data security’ contact in your

department.


Confidential Data Handling Blueprint 1.  Create a security risk-aware culture that includes an information

security risk management program 2.  Define institutional data types 3.  Clarify responsibilities and accountability for safeguarding

confidential/sensitive data 4.  Reduce access to confidential/sensitive data not absolutely

essential to institutional processes 5.  Establish and implement stricter controls for safeguarding

confidential/sensitive data 6.  Provide awareness and training 7.  Verify compliance routinely with your policies and procedures From: https://wiki.internet2.edu/confluence/display/secguide


Questions?


Help Desk User Alerts


Help Desk Academic Alerts


Panel Discussion

William Connolly Managing Director of Stroz Friedberg, Boston office Bill Connolly heads the Boston office of Stroz

Friedberg, a consulting and technical services firm specializing in digital forensics, data breach and computer crime response. Bill supervises a team of digital forensic experts and is a trusted advisor to top executives, in-house lawyers and outside counsel. Prior to joining Stroz Friedberg, Bill served for seven years as an Assistant U.S. Attorney in the U.S. Attorney's Office in Boston.

responding to data breaches · 5/4/2010 · responding to data breaches can be a complex and...

Documents