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.
3 Office of Information Technologies
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
4 Office of Information Technologies
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…
5 Office of Information Technologies
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.
6 Office of Information Technologies
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?
7 Office of Information Technologies
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”
8 Office of Information Technologies
HIPAA
9 Office of Information Technologies
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.
10 Office of Information Technologies
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
11 Office of Information Technologies
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.”
12 Office of Information Technologies
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
13 Office of Information Technologies
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.”
14 Office of Information Technologies
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)
15 Office of Information Technologies
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)
16 Office of Information Technologies
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”
17 Office of Information Technologies
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 ??
18 Office of Information Technologies
19 Office of Information Technologies
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
20 Office of Information Technologies
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.
21 Office of Information Technologies
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…
22 Office of Information Technologies
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)
23 Office of Information Technologies
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
24 Office of Information Technologies
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
25 Office of Information Technologies
Incident Response Procedures
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
26 Office of Information Technologies
Incident Response Procedures
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
27 Office of Information Technologies
Incident Response 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
28 Office of Information Technologies
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.
29 Office of Information Technologies
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.
30 Office of Information Technologies
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
31 Office of Information Technologies
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
32 Office of Information Technologies
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
33 Office of Information Technologies
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
34 Office of Information Technologies
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
35 Office of Information Technologies
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.
36 Office of Information Technologies
Documented Incident Response Procedures
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].
37 Office of Information Technologies
Documented Incident Response Procedures
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].
38 Office of Information Technologies
Documented Incident Response Procedures
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
39 Office of Information Technologies
Incident Response Procedures
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.
40 Office of Information Technologies
Incident Response Procedures
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.
41 Office of Information Technologies
Incident Response Procedures
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.
42 Office of Information Technologies
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.
43 Office of Information Technologies
Malware Incident Response Checklist
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.
44 Office of Information Technologies
Malware Incident Response Checklist
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).
45 Office of Information Technologies
Malware Incident Response Checklist
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.
46 Office of Information Technologies
Malware Incident Response Checklist
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.
47 Office of Information Technologies
Malware Incident Response Checklist
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)
48 Office of Information Technologies
Malware Incident Response Checklist
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
49 Office of Information Technologies
Malware Incident Response Checklist
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.
50 Office of Information Technologies
Malware Incident Response Checklist
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.
51 Office of Information Technologies
Malware Incident Response Checklist
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).
52 Office of Information Technologies
Malware Incident Response Checklist
No malware, no personally identifiable information You may need to re-diagnose the problem: check the incident symptoms and contact OIT for assistance.
53 Office of Information Technologies
Malware Incident Response Checklist
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
54 Office of Information Technologies
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.
55 Office of Information Technologies
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
56 Office of Information Technologies
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
57 Office of Information Technologies
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
58 Office of Information Technologies
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
59 Office of Information Technologies
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
60 Office of Information Technologies
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.
61 Office of Information Technologies
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).
62 Office of Information Technologies
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…
63 Office of Information Technologies
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
64 Office of Information Technologies
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.
65 Office of Information Technologies
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.
66 Office of Information Technologies
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
67 Office of Information Technologies
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.
68 Office of Information Technologies
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.
69 Office of Information Technologies
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.
70 Office of Information Technologies
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.
71 Office of Information Technologies
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.
72 Office of Information Technologies
Detection: Netflow
73 Office of Information Technologies
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
74 Office of Information Technologies
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…
75 Office of Information Technologies
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.
76 Office of Information Technologies
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
77 Office of Information Technologies
Questions?
78 Office of Information Technologies
Help Desk User Alerts
79 Office of Information Technologies
Help Desk User Alerts
80 Office of Information Technologies
Help Desk Academic Alerts
81 Office of Information Technologies
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.