Security Incident Response

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.

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.

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.

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.

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, 1 month ago by base. Reason: Last of the formatting edits