Infrastructure Data Release Policy

Definition

Infrastructure Data (InD) refers to data generated by IT infrastructure and related support services; this includes but is not limited to logs and records generated by any components of an institution’s Information Technology infrastructure, such as server logs, application logs, security devices records, door access logs, network device logs, network monitoring data and traffic metadata, NAC logs, DHCP transaction logs, and similar.

All Infrastructure Data should be considered classified, and requires special handling. Most will be considered Level Two, but some may be considered Level Three.

Infrastructure data is owned by the department (usually, the department head) that employs the system or service’s primary or senior administrator. The data owner is responsible for identifying and classifying Infrastructure data, and for its oversight, proper handling, and dissemination.

In general, the primary purposes for generating and retaining InD is for service performance or system problem diagnostics and troubleshooting. It is also kept for Incident Response needs, incident impact analysis, and incident forensic investigations, for both disruptive and non-disruptive types of incidents.

Use of InD, and in particular InD that may be linked to an individual client or user, for purposes other than those just described is the subject of this management policy.

Cases where release of InD is permitted

when contacted by a public safety official or senior staff where there is a clear health/safety issue that needs immediate attention. Relevant data can be released to the requestor ("Petitioner") immediately as the situation warrants.
when there is a suspected or alleged violation of law or institutional policy; relevant data should be released to the authoritative department responsible for adjudicating the infringement (HR for a staff/faculty violation, student affairs office for a student violation, and Campus Safety and Wellbeing for a stolen device or other similar situation).
completely anonymized data for internal research purposes, at the discretion of the department owning the data.
IT may, in certain cases, at the request of a user, release data pertaining to that user, at our discretion, after careful consideration. Thoughts about the gravity of the situation, whether the data is useful or important, what the role of the data will be, and workplace ethics are encouraged.

Cases where release of InD is not permitted

when there is no specific incident or no specific individual being investigated; InD may not be used to “fish” or sweep for potential misconduct, except where this is done as part of a standard security controls practice, such as malware scanners, SIEM tools, IDS systems, etc.
when the incident does not rise to the level of a policy violation.
a professor asking for logs to prove whether a student was cheating or being otherwise deceptive or not.
any case not otherwise covered by this policy.

If and when InD is released, it should be released along with a very specific description of exactly what the data means. For instance: "Our logs show that a device with this MAC address sent an association request to the access point that we show as being installed on the wall in Enfield 56D at the time when the access point’s internal clock said it was 10:01:06 a.m. on Sunday, October 24, 2256, and our logging server received the message when its internal clock said it was 23:56:45, Monday, December 4, 2016," and including some mitigating information such as “This does not prove that any specific person was at any specific location at any specific time. It doesn’t mean anything other than what was stated above.”

It's important to stress, when discussing InD, that it rarely proves anything. It is intended for diagnostic purposes, is not foolproof, and requires a lot of expert interpretation, which is also subject to error.