Responding to Data Breaches by yaoyufang


									                  Responding to Data Breaches

                                     NERCOMP SIG
                                      Amherst, MA

                                      4 May 2010

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.

Office of Information Technologies                       2
    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

Office of Information Technologies              3
 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…

Office of Information Technologies                      4
 Data Breach Law 101
       •  Federal Legislation
       •  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.

Office of Information Technologies                       5
 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?

Office of Information Technologies                                      6
 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
    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
           •  “creditors”
           •  “covered accounts”
           •  “identifying information”
Office of Information Technologies                                     7

Office of Information Technologies   8
    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.

Office of Information Technologies                                        9
 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?

Office of Information Technologies                         10
 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.”

Office of Information Technologies                                    11
 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

Office of Information Technologies                               12
 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

Office of Information Technologies                      13
 Chapter 93H: Who and What is Protected?
    “Resident of the Commonwealth”                (M.G.L. c. 93H, §§ 1,
    “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
            (M.G.L. c. 93H, § 1)

Office of Information Technologies                                         14
 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)

Office of Information Technologies                           15
 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”

Office of Information Technologies                           16
 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 ??
Office of Information Technologies                          17
Office of Information Technologies   18
 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

Office of Information Technologies                              19
 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.

Office of Information Technologies                                 20
    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…

Office of Information Technologies                       21
 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

Office of Information Technologies                                    22
 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

Office of Information Technologies                      23
 Incident Response Procedures
    Contain/Quarantine suspected compromised
    Preserve an image of the local disks
    Identify any sensitive data that may have been
      •  If sensitive data may be at risk:
    Identify and assess malware
    Complete technical report outlining the findings
    Work with legal counsel, internal audit, etc to
     assess risk and take appropriate actions
Office of Information Technologies                      24
 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

Office of Information Technologies                       25
 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
Office of Information Technologies                       26
 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

Office of Information Technologies                       27
 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
Office of Information Technologies                       28
 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
       •  These procedures were born out of the bad old days of
          Code Red, Nimda, etc.

Office of Information Technologies                                29
 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
    Results is in a call from the Help Desk

Office of Information Technologies                                   30
 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

Office of Information Technologies                      31
 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

Office of Information Technologies                       32
 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

Office of Information Technologies                         33
 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

Office of Information Technologies                      34
 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.

Office of Information Technologies                        35
 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
     for instructions.
    Conduct a preliminary analysis using the
     Malware Incident Response Checklist - or -
     contact OIT as soon as possible.
    Submit an Incident Report to

Office of Information Technologies                     36
 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

Office of Information Technologies                      37
 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

Office of Information Technologies                     38
 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.

Office of Information Technologies                        39
 Incident Response Procedures
    Incident History: Gather the incident details,
     including symptoms and how you first
    Incident Report: Contact 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.

Office of Information Technologies                       40
 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
Office of Information Technologies                         41
 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 if you need
     assistance with any of the steps below.

Office of Information Technologies                                  42
 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.

Office of Information Technologies               43
 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

Office of Information Technologies                       44
 Malware Incident Response Checklist
    Option B: Connect the hard drive to a write
    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.

Office of Information Technologies                        45
 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
Office of Information Technologies                      46
 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 the
     following information:
    Incident history (date, time, symptoms, how you
     first responded)

Office of Information Technologies                       47
 Malware Incident Response Checklist
    4. Provide OIT with an Incident Report
    Identity Finder and malware scan results (if
    Host name
    IP Address
    MAC Address
    Building and room number
    Your email address and campus telephone

Office of Information Technologies                  48
 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
    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.

Office of Information Technologies                        49
 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.

Office of Information Technologies                      50
 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 (we'll share them with
     other IT Administrators).

Office of Information Technologies                       51
 Malware Incident Response Checklist
    No malware, no personally identifiable
     You may need to re-diagnose the problem: check
     the incident symptoms and contact OIT for

Office of Information Technologies                    52
 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

Office of Information Technologies                          53
    Consequences of Mishandling Data Security
    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
Office of Information Technologies                     54
    Consequences of Mishandling Data Security
    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
Office of Information Technologies                    55
    We are delegating substantial authority to these
     departments to appropriately handle these
    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

Office of Information Technologies                       56
 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

Office of Information Technologies                      57
 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

Office of Information Technologies                                    58
 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

Office of Information Technologies                            59
 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.

Office of Information Technologies                     60
 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).

Office of Information Technologies                      61
 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…
Office of Information Technologies                                    62
 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

Office of Information Technologies                            63
 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.

Office of Information Technologies                     64
 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.

Office of Information Technologies                      65
 Protection tools available to campus
    OIT currently offers departments several tools
     that can help protect departmental computers
     and data, and mitigate potential data security

       •    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

Office of Information Technologies                              66
 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.

Office of Information Technologies                                  67
 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
       •  Ideal for:
       •  Identifying vulnerable or outdated third-party
       •  Patching and updating third-party applications.

Office of Information Technologies                          68
 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.

Office of Information Technologies                      69
 Vulnerability Scanning to Prevent Network Attacks
    OIT offers departments two types of vulnerability
    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.

Office of Information Technologies                       70
 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

Office of Information Technologies                 71
 Detection: Netflow

Office of Information Technologies   72
 Detection: Netflow data
      srcIP       dstIP        prot srcPort dstPort   octets     packets
   xxx.yyy.131.204 17 3111            1434     404       1
      xxx.yyy.131.182 17 1514          1434     404       1
   xxx.yyy.131.246 6       447       8080     40       1
   xxx.yyy.131.246 6       64068      80      40       1
   xxx.yyy.131.246 6       50265      3128     40       1
   xxx.yyy.131.178 17 1126           1434     404       1
      xxx.yyy.131.171 17 1923         1434     404       1
      xxx.yyy.131.114 6     63559     41544     40       1
   xxx.yyy.131.233 17 1051           1434     404        1
   xxx.yyy.131.35 6        9001      30185    40        1
   xxx.yyy.131.7 17 1246            1434     404       1
   xxx.yyy.131.7 17 1157            1434     404       1
   xxx.yyy.131.122 17 1129            1434     404       1

Office of Information Technologies                                              73
 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…

Office of Information Technologies                         74
 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

Office of Information Technologies                          75
 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

Office of Information Technologies                                        76

Office of Information Technologies   77
 Help Desk User Alerts

Office of Information Technologies   78
 Help Desk User Alerts

Office of Information Technologies   79
 Help Desk Academic Alerts

Office of Information Technologies   80
 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.

Office of Information Technologies                         81

To top