跳到内容

日志记录备忘单

简介

本备忘单旨在为开发人员提供关于构建应用程序日志记录机制的集中指导，尤其是在安全日志记录方面。

许多系统都启用了网络设备、操作系统、Web服务器、邮件服务器和数据库服务器的日志记录，但自定义应用程序事件日志记录常常缺失、被禁用或配置不当。它比单独的基础设施日志记录提供了更深入的洞察力。Web应用程序（例如网站或Web服务）的日志记录远不止启用Web服务器日志（例如使用扩展日志文件格式）。

应用程序日志记录应在应用程序内部保持一致，在组织的应用组合中保持一致，并在相关情况下使用行业标准，以便日志事件数据能够被各种系统消费、关联、分析和管理。

目的

应用程序日志记录应始终包含安全事件。应用程序日志对于安全和操作用例都是宝贵的数据。

操作用例

  • 通用调试
  • 建立基线
  • 业务流程监控，例如销售流程放弃、交易、连接
  • 提供问题和异常情况的信息
  • 性能监控，例如数据加载时间、页面超时
  • 其他特定业务需求

安全用例

应用程序日志记录也可能用于记录其他类型的事件，例如：

  • 反自动化监控
  • 识别安全事件
  • 监控策略违规
  • 辅助防抵赖控制（请注意，日志的防抵赖特性很难实现，因为其可信度通常仅基于对日志记录方的适当审计，而数字签名等机制在此处难以利用）
  • 审计跟踪，例如数据添加、修改和删除、数据导出
  • 合规性监控
  • 用于后续信息请求的数据，例如数据主体访问、信息自由、诉讼、警方及其他监管调查
  • 法律授权的数据拦截，例如应用层窃听
  • 为事件调查提供其他日志源中缺乏的额外应用程序特定数据
  • 通过攻击检测协助防御漏洞识别和利用

过程监控、审计和事务日志/跟踪等通常是出于与安全事件日志记录不同的目的而收集的，这通常意味着它们应保持分离。

收集的事件类型和详细信息往往不同。

例如，PCIDSS审计日志将包含活动的按时间顺序记录，以提供一个独立可验证的跟踪，从而允许重建、审查和检查以确定可归因事务的原始序列。重要的是，日志记录既不能过多，也不能过少。

利用对预期目的的了解来指导记录什么、何时以及记录多少。本备忘单的其余部分主要讨论安全事件日志记录。

设计、实施与测试

事件数据源

应用程序本身可以访问各种信息事件，这些事件应被用于生成日志条目。因此，主要的事件数据源是应用程序代码本身。

应用程序拥有关于用户（例如身份、角色、权限）和事件上下文（目标、操作、结果）的最全面信息，而这些数据通常无法提供给基础设施设备，甚至与此密切相关的应用程序。

可以考虑的其他关于应用程序使用情况的信息来源包括：

  • 客户端软件，例如桌面软件和移动设备在本地日志中的操作或使用消息传递技术，通过AJAX的JavaScript异常处理程序，以及使用内容安全策略（CSP）报告机制的Web浏览器
  • 嵌入式仪表代码
  • 网络防火墙
  • 网络和主机入侵检测系统（NIDS和HIDS）
  • 密切相关的应用程序，例如内置于Web服务器软件中的过滤器、Web服务器URL重定向/重写到脚本化自定义错误页面和处理程序
  • 应用程序防火墙，例如过滤器、防护、XML网关、数据库防火墙、Web应用程序防火墙（WAF）
  • 数据库应用程序，例如自动审计跟踪、基于触发器的操作
  • 声誉监控服务，例如正常运行时间或恶意软件监控
  • 其他应用程序，例如欺诈监控、客户关系管理（CRM）
  • 操作系统，例如移动平台

在包含来自不同信任区域系统中的事件数据时，必须考虑事件信息的置信度。数据可能缺失、被修改、伪造、重放，并可能是恶意的——它必须始终被视为不可信数据。

考虑如何验证来源，以及如何强制实施完整性和防抵赖性。

事件数据记录位置

应用程序通常将事件日志数据写入文件系统或数据库（SQL或NoSQL）。安装在桌面和移动设备上的应用程序可以使用本地存储和本地数据库，也可以将数据发送到远程存储。

您选择的框架可能会限制可用选项。所有类型的应用程序都可以将事件数据发送到远程系统（除了或替代本地存储）。

这可能是一个集中式日志收集和管理系统（例如SIEM或SEM）或在其他地方的另一个应用程序。考虑应用程序是否可以直接将其事件流，不带缓冲地，发送到标准输出（stdout），由执行环境进行管理。

  • 当使用文件系统时，最好使用一个独立于操作系统、其他应用程序文件和用户生成内容的分区。
    • 对于基于文件的日志，应严格限制哪些用户可以访问目录以及目录中文件的权限。
    • 在Web应用程序中，日志不应暴露在Web可访问的位置；如果必须如此，则应限制访问并将其配置为纯文本MIME类型（而非HTML）。
  • 当使用数据库时，最好使用一个单独的数据库账户，该账户仅用于写入日志数据，并且具有非常严格的数据库、表、函数和命令权限。
  • 使用基于安全协议的标准格式记录并将事件数据或日志文件发送到其他系统，例如通过syslog发送通用日志文件系统（CLFS）或通用事件格式（CEF）；标准格式有助于与集中式日志服务集成。

考虑为扩展事件信息（例如错误堆栈跟踪或HTTP请求和响应头和体记录）使用单独的文件/表。

哪些事件需要记录

安全监控、警报和报告的级别和内容需要在项目的需求和设计阶段确定，并且应与信息安全风险成比例。这可以用于定义需要记录的内容。

没有一劳永逸的解决方案，盲目遵循清单的方法可能导致不必要的“警报雾霾”，从而使真正的问题未被发现。

在可能的情况下，始终记录：

  • 输入验证失败，例如协议违规、不可接受的编码、无效的参数名称和值
  • 输出验证失败，例如数据库记录集不匹配、无效数据编码
  • 认证成功和失败
  • 授权（访问控制）失败
  • 会话管理失败，例如Cookie会话标识值修改或可疑的JWT验证失败
  • 应用程序错误和系统事件，例如语法和运行时错误、连接问题、性能问题、第三方服务错误消息、文件系统错误、文件上传病毒检测、配置更改
  • 应用程序和相关系统的启动和关闭，以及日志记录初始化（启动、停止或暂停）
  • 高风险功能的使用，包括：
    • 用户管理操作，例如添加或删除用户、更改权限、将用户分配到令牌、添加或删除令牌
    • 系统管理权限的使用或应用程序管理员的访问，包括这些用户的所有操作
    • 默认账户或共享账户的使用，或“紧急访问”账户的使用。
    • 对敏感数据的访问，例如支付卡持有人数据，
    • 加密活动，例如加密密钥的使用或轮换
    • 系统级对象的创建和删除
    • 数据导入和导出，包括基于屏幕的报告
    • 用户生成内容的提交和处理——特别是文件上传
    • 反序列化失败
    • 网络连接及相关故障，例如后端TLS故障（包括证书验证失败），或带有非预期HTTP动词的请求
  • 法律及其他选择加入，例如移动电话功能权限、使用条款、条款和条件、个人数据使用同意、接收营销通信的许可
  • 可疑的业务逻辑活动，例如：
    • 尝试以无序方式执行一组操作/绕过流程控制
    • 在业务上下文中不合理的行为
    • 尝试超出特定操作的限制

可选地考虑是否可以记录以下事件以及其是否为所需信息：

  • 序列失败
  • 过度使用
  • 数据更改
  • 欺诈及其他犯罪活动
  • 可疑、不可接受或非预期的行为
  • 配置修改
  • 应用程序代码文件和/或内存更改

事件属性

每个日志条目都需要包含足够的信息，以便后续的监控和分析。它可能是完整的内容数据，但更可能是摘要或仅包含摘要属性。

应用程序日志必须记录每个事件的“何时、何地、何人、何事”。

这些属性会因架构、应用程序类别和主机系统/设备的不同而异，但通常包括以下内容：

  • 何时
    • 日志日期和时间（国际格式）
    • 事件日期和时间——事件时间戳可能与日志记录时间不同，例如客户端应用程序托管在远程设备上，该设备仅定期或间歇性在线时的服务器日志记录
    • 交互标识符 注意A
  • 何地
    • 应用程序标识符，例如名称和版本
    • 应用程序地址，例如集群/主机名或服务器IPv4或IPv6地址和端口号、工作站身份、本地设备标识符
    • 服务，例如名称和协议
    • 地理位置
    • 窗口/表单/页面，例如Web应用程序的入口点URL和HTTP方法、对话框名称
    • 代码位置，例如脚本名称、模块名称
  • 何人（人类或机器用户）
    • 源地址，例如用户设备/机器标识符、用户IP地址、蜂窝/射频塔ID、移动电话号码
    • 用户身份（如果已认证或已知），例如用户数据库表主键值、用户名、许可证号
  • 何事
    • 事件类型 注意B
    • 事件严重性 注意B，例如 {0=紧急, 1=警报, ..., 7=调试}, {致命, 错误, 警告, 信息, 调试, 跟踪}
    • 安全相关事件标志（如果日志也包含非安全事件数据）
    • 描述

此外，考虑记录：

  • 辅助时间源（例如GPS）事件日期和时间
  • 操作 - 请求的原始目的，例如登录、刷新会话ID、注销、更新个人资料
  • 对象，例如受影响的组件或其他对象（用户账户、数据资源、文件），例如URL、会话ID、用户账户、文件
  • 结果状态 - 针对对象的ACTION是否成功，例如成功、失败、延迟
  • 原因 - 为什么发生上述状态，例如用户在数据库检查中未通过认证...、凭据不正确
  • HTTP状态码（仅限Web应用程序） - 返回给用户的状态码（通常是200或301）
  • 请求HTTP头或HTTP用户代理（仅限Web应用程序）
  • 用户类型分类，例如公共用户、认证用户、CMS用户、搜索引擎、授权渗透测试员、正常运行时间监控器（参见下文“需要排除的数据”）
  • 事件检测的分析置信度 注意B，例如低、中、高或数值
  • 用户看到的响应和/或应用程序采取的措施，例如状态码、自定义文本消息、会话终止、管理员警报
  • 扩展详情，例如堆栈跟踪、系统错误消息、调试信息、HTTP请求体、HTTP响应头和体
  • 内部分类，例如职责、合规性参考
  • 外部分类，例如NIST安全内容自动化协议（SCAP）、Mitre通用攻击模式枚举和分类（CAPEC）

有关这些内容的更多信息，请参阅末尾列出的“其他”相关文章，特别是Anton Chuvakin和Gunnar Peterson撰写的综合文章。

注意A：“交互标识符”是一种将单个用户交互（例如桌面应用程序表单提交、网页请求、移动应用按钮点击、Web服务调用）的所有（相关）事件链接起来的方法。应用程序知道所有这些事件都与同一交互相关，应记录此信息，而不是丢失信息并强制后续关联技术重新构建单独的事件。例如，单个SOAP请求可能存在多个输入验证失败，并且它们可能发生在短时间范围内。另一个例子是，长时间运行的由应用程序提交到数据库服务器的“saga请求”的输出验证失败可能发生在输入提交很久之后。

注意B：每个组织都应确保在事件分类（类型、置信度、严重性）、描述语法以及字段长度和数据类型（包括日期/时间格式）方面，采取一致且有文档记录的方法。

需要排除的数据

除非获得法律许可，否则切勿记录数据。例如，拦截某些通信、监控员工以及未经同意收集某些数据都可能违法。

切勿排除来自“已知”用户的任何事件，例如其他内部系统、“受信任”的第三方、搜索引擎机器人、正常运行时间/流程及其他远程监控系统、渗透测试人员、审计员。但是，您可能希望在记录的数据中为每个这些用户包含一个分类标志。

以下数据通常不应直接记录在日志中，而应被移除、屏蔽、清洗、哈希或加密：

  • 应用程序源代码
  • 会话标识值（如果需要跟踪会话特定事件，考虑替换为哈希值）
  • 访问令牌
  • 敏感个人数据和某些形式的个人身份信息（PII），例如健康信息、政府标识符、弱势群体信息
  • 认证密码
  • 数据库连接字符串
  • 加密密钥及其他主要秘密
  • 银行账户或支付卡持有人数据
  • 安全分类高于日志系统允许存储级别的数据
  • 商业敏感信息
  • 在相关司法管辖区非法收集的信息
  • 用户已选择退出收集或未同意收集的信息，例如使用“请勿跟踪”功能，或收集同意已过期的情况

有时也可能存在以下数据，虽然对后续调查有用，但在记录事件之前可能需要以特殊方式处理：

  • 文件路径
  • 数据库连接字符串
  • 内部网络名称和地址
  • 非敏感个人数据（例如个人姓名、电话号码、电子邮件地址）

在不需要个人身份或风险过高的情况下，考虑使用个人数据去标识化技术，例如删除、混淆或假名化直接和间接标识符。

在某些系统中，清洗可以在日志收集后和日志显示前进行。

可定制的日志记录

可能需要能够更改日志记录级别（基于严重性或威胁级别的事件类型、记录的详细程度）。如果实施此功能，请确保：

  • 默认级别必须为业务需求提供足够的详细信息
  • 不应完全禁用应用程序日志记录或合规性要求所需的事件日志记录
  • 日志记录级别/范围的更改必须是应用程序固有的（例如由应用程序根据批准的算法自动执行）或遵循变更管理流程（例如配置数据更改、源代码修改）
  • 日志记录级别必须定期验证

事件收集

如果您的开发框架支持合适的日志记录机制，请使用或基于其构建。否则，请实现一个可从其他模块/组件调用的应用程序范围的日志处理程序。

文档化接口，并参考组织特定的事件分类和描述语法要求。

如果可能，将此日志处理程序创建为一个标准模块，该模块可以经过彻底测试，部署在多个应用程序中，并添加到批准和推荐模块的列表中。

  • 对来自其他信任区域的事件数据执行输入验证，以确保其格式正确（如果存在输入验证失败，则考虑警报而非记录日志）
  • 对所有事件数据执行清洗，以防止日志注入攻击，例如回车（CR）、换行（LF）和分隔符（并可选地移除敏感数据）
  • 为输出（已记录）格式正确编码数据
  • 如果写入数据库，请阅读、理解并应用SQL注入备忘单
  • 确保日志记录过程/系统的失败不会阻止应用程序正常运行或导致信息泄露
  • 同步所有服务器和设备的时间 注意C

注意C：当应用程序运行在由其他方控制的设备上时（例如，在个人手机上，或在另一个公司网络上的远程客户工作站上），这并非总是可行。在这些情况下，请尝试测量时间偏移，或记录事件时间戳的置信度。

在可能的情况下，以标准格式记录数据，或者至少确保它可以使用行业标准格式导出/广播。

在某些情况下，事件可能会在中转点进行中继或集中收集。在后一种情况下，一些数据可能会在转发到中央存储库和分析系统之前进行聚合或汇总。

验证

日志记录功能和系统必须纳入代码审查、应用程序测试和安全验证流程中

  • 确保日志记录正常工作并符合规范
  • 检查事件是否一致分类，以及字段名称、类型和长度是否根据约定标准正确定义
  • 确保在应用程序安全、模糊、渗透和性能测试期间实施并启用日志记录
  • 测试这些机制不易受到注入攻击
  • 确保日志记录发生时没有不必要的副作用
  • 检查外部网络连接丢失时（如果通常需要）对日志记录机制的影响
  • 确保日志记录不能用于耗尽系统资源，例如通过填满磁盘空间或超出数据库事务日志空间，从而导致拒绝服务
  • 测试日志记录失败对应用程序的影响，例如模拟数据库连接丢失、文件系统空间不足、文件系统缺少写入权限以及日志记录模块本身的运行时错误
  • 验证事件日志数据上的访问控制
  • 如果日志数据用于对用户采取任何行动（例如阻止访问、账户锁定），请确保这不能用于导致其他用户的拒绝服务（DoS）

网络架构

例如，下图展示了一个为客户提供业务功能的服务。我们建议创建一个集中式系统来收集日志。可能存在许多此类服务，但所有这些服务都必须将日志安全地收集到集中式系统中。

此业务服务的应用程序位于以下网络段中：

  • 前端 1，即DMZ (UI)
  • 中间件 1（业务应用程序 - 服务核心）
  • 后端 1（服务数据库）

负责收集IT事件（包括安全事件）的服务位于以下段中：

  • 后端 2（日志存储）
  • 中间件 3 - 2个应用程序
    • 日志加载应用程序，从存储中下载日志，预处理，并传输到UI
    • 日志收集器，接收来自业务应用程序、其他基础设施、云应用程序的日志并保存到日志存储中
  • 前端 2（用于查看业务服务事件日志的UI）
  • 前端 3（从云应用程序接收日志并传输到日志收集器的应用程序）
    • 允许将两个应用程序的功能合并为一个

例如，所有来自用户的外部请求都通过API管理服务，请参见中间件2段中的应用程序。

MIDDLEWARE

如上图所示，在网络层面，日志的保存和下载过程需要开放不同的网络访问（端口），箭头以不同颜色突出显示。此外，保存和下载由不同的应用程序执行。

sergiomarotco 提供的完整网络分段备忘单：sergiomarotco：链接

部署与操作

发布

  • 通过在发布文档中添加日志记录机制的详细信息来提供安全配置信息
  • 向应用程序/流程所有者简要介绍应用程序日志记录机制
  • 确保监控的输出（见下文）与事件响应流程集成

操作

启用流程以检测日志记录是否停止，并识别篡改或未经授权的访问和删除（参见下面的保护部分）。

保护

日志记录机制和收集的事件数据必须受到保护，以防滥用，例如传输中的篡改，以及存储后的未经授权访问、修改和删除。日志可能包含个人和其他敏感信息，或数据可能包含有关应用程序代码和逻辑的信息。

此外，日志中收集的信息本身可能具有商业价值（对竞争对手、八卦者、记者和活动家而言），例如允许估算收入，或提供员工绩效信息。

这些数据可能存储在终端设备、中间点、集中存储库以及档案和备份中。

考虑在检查或提取过程中是否需要排除、屏蔽、清洗、哈希或加密部分数据。

静态存储时

  • 内置篡改检测功能，以便了解记录是否已被修改或删除
  • 尽快将日志数据存储或复制到只读媒体
  • 所有对日志的访问都必须记录和监控（可能需要事先批准）
  • 读取日志数据的权限应受到限制并定期审查

传输中

  • 如果日志数据通过不信任的网络发送（例如用于收集、转发到其他地方、分析、报告），请使用安全传输协议
  • 考虑是否需要验证事件数据的来源
  • 在将事件数据发送给第三方之前，执行尽职调查（法规和安全）检查

更多指导请参阅NIST SP 800-92计算机安全日志管理指南。

事件监控

记录的事件数据需要可供审查，并且已建立适当的监控、警报和报告流程

  • 将应用程序日志记录整合到任何现有日志管理系统/基础设施中，例如集中式日志记录和分析系统
  • 确保事件信息可供相关团队使用
  • 启用警报功能，并立即向负责团队发出更严重事件的信号
  • 与其他检测系统、相关组织和集中式情报收集/共享系统共享相关事件信息

日志处置

日志数据、临时调试日志以及备份/副本/提取物，在所需数据保留期结束前不得销毁，且不得在此时间之后保留。

法律、监管和合同义务可能会影响这些期限。

日志攻击

由于日志作为防御手段的有用性，它可能成为攻击的目标。另请参阅OWASP的日志注入和CWE-117。

机密性

谁应该能够读取什么？机密性攻击允许未经授权方访问日志中存储的敏感信息。

  • 日志包含用户的PII（个人身份信息）。攻击者收集PII，然后将其发布或用作对这些用户进行进一步攻击的垫脚石。
  • 日志包含密码等技术秘密。攻击者利用它作为进行更深层攻击的垫脚石。

完整性

哪些信息应该由谁来修改？

  • 拥有日志读取权限的攻击者利用日志窃取秘密。
  • 攻击利用日志连接到日志平台的漏洞方面，例如通过syslog发送有效载荷以导致越界写入。

可用性

可接受的停机时间是多少？

  • 攻击者通过泛滥日志文件来耗尽系统非日志功能所需的磁盘空间。例如，用于日志文件的磁盘也可能用于SQL存储应用程序数据。
  • 攻击者通过泛滥日志文件来耗尽可用于进一步日志记录的磁盘空间。
  • 攻击者利用一个日志条目破坏其他日志条目。
  • 攻击者利用日志代码的低劣性能来降低应用程序性能

可追溯性

谁应该对损害负责？

  • 攻击者阻止写入以掩盖其踪迹。
  • 攻击者破坏日志以掩盖其踪迹。
  • 攻击者导致记录错误的身份，以掩盖责任方。