审计及问责

1. 访问、认证和授权.

   记录哪些身份在何时访问了哪些系统的日志. 这些资源包括但不限于:

   1. Web应用程序访问
   2. Azure AD和AD基础架构
   3. System access
   4. O365 file access
   5. MFA infrastructure
   6. Network access

      需要记录的风险级别:低* /中/高

      *不需要在低风险系统上进行本地认证的中央日志记录.

2. Network logs. 从网络活动生成的日志. 这些资源包括但不限于:
   1. Firewalls
   2. NetfLow基础设施
   3. VPN infrastructure
   4. 无线和有线基础设施
   5. DHCP的基础设施
   6. ARP tables

      需要记录的风险级别:低* /中/高

      *不需要在低风险系统上进行本地认证的中央日志记录.

3. Email logs. 从电子邮件活动生成的日志. 这些资源包括但不限于:
   1. 电子邮件路由设备
      1. 使用集中管理的邮件中继的工具和应用程序除外.
   2. 电子邮件安全设备

      需要记录的风险级别:低/中/高

4. Security events. 由OIT管理的安全工具生成的日志. 这些资源包括但不限于:
   1. AV/EDR
   2. IPS/IDS
   3. 网络安全监控(仅限中/高)
   4. pDNS (Passive DNS)日志(仅限中高)

      需要记录的风险级别:低/中/高

5. 特权、身份和凭证管理. 通过更改身份和凭证生成的日志. 这些资源包括但不限于:
   1. Active directory
   2. Duo administration
   3. 证书的签发和撤销

      需要记录的风险级别:低* /中/高

      *不需要在低风险系统上进行本地认证的中央日志记录.

6. Application logs. 应用程序作为其功能的一部分生成的日志. 这些例子包括但不限于:
   1. Change logs
   2. Execution logs. (High-risk only)
   3. 调试日志(不需要中央日志记录)

      需要日志记录的风险级别:中等/高

   4. 操作系统日志. 操作系统作为其功能的一部分而产生的日志. 只需要服务器操作系统的日志.

      需要日志记录的风险级别:中等/高

7. 操作系统日志. 操作系统作为其功能的一部分而产生的日志. 只需要服务器操作系统的日志.

   需要日志记录的风险级别:中等/高

8. OIT安全指定的其他日志类型

1. 为了确保托管技术设备维护正确的日志记录时间，它们必须使用时间.uidaho.或者一个被认可的来源作为他们的时间来源.
   1. Time.uidaho.Edu是一对时间服务器.
   2. Time.uidaho.Edu利用以下工具作为权威时间服务器.
      1. clock.xmission.com
      2. sue.cc.uregina.ca
      3. india.colorado.edu
      4. clock.sjc.he.net

         适用于:低/中/高

   3. 批准时间源，包括授权时间源时间.uidaho.以及直接或间接地:
      1. time.windows.com
      2. time.nist.gov
      3. Pool.ntp.org
      4. time.apple.com
      5. 与大学签约的云服务可以使用其内部时间服务器.
2. 如果可能的话，时间格式应该是ISO 8601 (YYYY-MM-DDThh:mm:ss).mmm+>)

确保OIT安全部门可以通过以下标准处理适当的日志:

1. 必须将所需的日志发送到经批准的中央日志服务器以进行关联, 评审和报告生成.
2. 必须为以下场景建立警报，以确保日志记录成功:

   适用于:低/中/高

   1. 在预期的时间段内没有日志卷或日志量很低.
   2. Log parsing errors
   3. 日志存储容量已达到限制.
3. 日志功能错误产生的警报必须发送给系统所有者和/或中央日志服务器管理员，以定位和解决问题.
4. 日志源所有者应定期检查日志记录系统，以确保日志记录符合规定的标准.

   适用于:低/中/高(至少每年一次)

5. 所有日志应包含:
   1. 根据日志源时间调整过的utc时间戳.
   2. 中央日志服务器处理日志的时间戳，经过utc调整.
   3. 日志源的IP地址/名称.
   4. 生成源的应用程序/服务名称(如果可用).
   5. 由应用程序提供或从上下文收集的任何相关标识信息.
      1. 示例包括但不限于:用户名, IP addresses, device names, certificates, user-agents, x-forwarded for, 转换后的IP地址, SPF results, Geo-location data.
      2. 高风险数据和特权功能的使用必须能够与代表用户的单个用户或进程相关联.
   6. Action performed.
      1. 示例包括但不限于:修改密码, 身份验证的尝试, HTTP POST, email received.
   7. 行动结果及原因(如有)
      1. 例子包括但不限于:成功, 密码错误导致失败, 由于权限问题导致的失败, HTTP 404.
   8. 安全信息(如果有)
      1. 示例包括但不限于:检测到的签名、安全动作、扫描结果.
   9. 上下文信息
      1. 例如:端口号、电子邮件主题、角色分配、会话状态.
   10. 根据系统所有者或OIT的要求，可能对调查有帮助的任何其他项目.

所需的日志应在适当的中央日志服务器上保留1年，除非法律另有规定, regulations, 合同义务或OIT Security规定的其他义务.

以下标准可确保日志数据的机密性和完整性.

1. 根据需要授予中央日志服务器访问权限.
2. 每年审查一次中央日志服务器访问权限.
3. 当删除中央日志服务器中的数据时，将出现警报.
4. 必须根据日志中数据的风险级别对中央日志服务器应用数据分类标准.

保护学生和客人的隐私, 学生和访客网络免于网络安全监控和pDNS日志记录.