Security Incident Response

Viewing 5 reply threads
  • Author
    Posts
    • #354
      recooper
      Participant

      Security Incident Response

    • #372
      ccovey01
      Participant

      2.1.2
      – bullet 1 – could we adjust the ‘area’ language and narrow it to department’s business systems? Most departments could have the public or students using either the wireless or an Ethernet drop and an incident could occur, but those departments don’t have any control over that type of user base and their activities.

      • #389
        base
        Participant

        Hi, I think this is a fair point to consider, and will recommend it be reviewed; however, this is internal procedure and Policy language for UNM.

        Please see UNM’s Safety and Risk services Policy policy.unm.edu/university-policies/6000/6110.html section 2, last sentence. Internal Audit, HR, and other investigative bodies have cited this and other internal procedures with respect to this issue.

    • #373
      ccovey01
      Participant

      3.1
      – most of us are inclined to support some sort of chargeback for negligence – but what would happen if the incident resulted from a state actor or advanced persistent threat? To encourage reporting of all real or potential incidents – which is ultimately what we all want – maybe investigations and remediation could be considered core-services?

      What we want to avoid are internal punitive repercussions that will limit reporting – things that customers fear like massive investigation costs and removal or takeover of their resources. On the other hand, perhaps this SLA can show in detail the external factors that customers should perceive as risks – regulatory and accreditation bodies, credit reporting coverage for breached accounts, etc.? Basically, make it clear to data users that internally, UNM IT will help them, that the investigation is about discovery, not punishment. But that there are serious consequences external to UNM – in those cases, they cannot dodge responsibility for negligence.

      This SLA could reassure customers that UNM IT will shepherd them through a process that may not have been their fault; otherwise, their fear of internal repercussions and costs may prevent them from reporting suspected issues. Which could allow an APT to thrive on the network. There is a time and place for cost recovery, but I fear implementing it within the Security Incidents SLA will undermine the larger goal, identifying and removing bad actors from the UNM network.

      • This reply was modified 8 years, 2 months ago by ccovey01.
      • #390
        base
        Participant

        Hi, I think the point you raised is certainly worth further discussion, and my recommendation is that this point be addressed by the leadership teams performing the final SLA review. I agree that moving the billing and payment discussions to a different area would enhance the incentive for units to bring issues forward based on standard criteria, without the risk of financial impact beign a potential consideration. I also appreciate the points you have made regarding ATPs; although, it is worth noting that UNM’s unpatched vulnerabilities are the primary cause of incidents, which are significantly easier to leverage than ATPs.

    • #376
      ccovey01
      Participant

      3.2
      – could the wider UNM data owner and data steward community be given notification about this SLA and its discussion process? It’s important for this non-IT community to be able to comment on an SLA that directly impacts their processes, and also to see the seriousness of incidents and the clean up process.

      • #391
        base
        Participant

        Hi, I believe some of the members of the Data Governance committee are members of the committee reviewing the SLAs.

        • #393
          kevings
          Participant

          Chad, that’s a great recommendation – I’ll forward this to the Data Owners to encourage participation of the relevant stewards.

    • #444
      jwong
      Participant

      Does the University have an overarching incident response plan?

      2.1.2 Bullet #1:  Can you clarify the language when the breach occurs outside of the Business Unit’s control?

      6.0:  What type of incidents are covered in this SLA, i.e does it include Desktop virus infection, server infections, stolen laptops etc.

    • #448
      base
      Participant

      Hi, UNM has an incident response plan that was developed as a standard response for all information security incidents related to ERP and ERP components. In addition, there are specialized incident response plans that have been developed for units with requirements to do so, for example, the Payment Card Industry (PCI) incident response plan. For 2.1.2 Bullet 1, an example of an incident where the department would be responsible for costs associated with responding to an incident is: if a staff member in a department made an unauthorized copy of Personally Identifiable/ Sensitive and Protected (PII/ SPI) information, the department where that employee works would bear the responsibility of paying investigatory costs that the investigative body requires (such as when Internal Audit requires forensics analysis be conducted on that employee’s computer(s)). In addition, if there were a disclosure/ breach of that PII/ SPI where the UNM investigative body determined that Identity Theft Protection services are required as part of UNM’s response, the department would be responsible for those costs, as well. Section 6 reads: This section intentionally left blank. This is related to an incident against the service, not an information security incident. We do distinguish between minor and major incidents. An example of a minor incident is: a virus infection on a workstation where there were Antivirus definitions available that would have prevented an infection if the definitions had been updated, where that workstation has no PII/ SPI, and the workstation was not used as part of an attack on third parties or internal services. An example of a major incident is: a device on the UNM network that was not patched, was taken over by an unauthorized third party, was used to attack other third parties, was used to attack other UNM internal resources, and/ or was used to access and/ or exfiltrate PII/ SPI for which UNM is responsible. Stolen and lost UNM-owned devices, or devices storing PII/ SPI for which UNM is responsible, must be reported to Safety and Risk Services (and stolen devices reported to UNMPD). If PII/ SPI was stored on that device, Safety and Risk Services notifies the ISPO so that we can assist the appropriate UNM entities in responding to any potential or actual breach, as required for the type of PII/ SPI involved.

      • This reply was modified 8 years, 2 months ago by base. Reason: Last of the formatting edits
Viewing 5 reply threads
  • The topic ‘Security Incident Response’ is closed to new replies.