=Start=
缘由：
好久没有写文章了，也不是不想写，好像也不是太忙，可能就是变懒了吧。。。结合现状，简单记录一篇，希望自己还能不断坚持学习、记录。
正文：
整理一套通用的审计日志格式，用于指导/督促业务方在设计/实现时进行参考。
基本要求：
【什么人】在【什么时间】从【什么途径】通过【什么设备】使用【什么方式】访问了【什么内容】，【访问结果】如何。
|
什么人
|
在什么时间点
|
从什么地方来
|
进入什么系统
|
以什么身份
|
对谁
|
进行什么操作
|
操作结果
|
……
|
|---|---|---|---|---|---|---|---|---|
| who | when | from | where | admin/operator/guest | target | what | success/fail | …… |
可选增强内容：
什么人（who）：它的账号类型是什么，属于哪个组，是否是超级管理员等等。
用什么设备（device）：设备的类型、操作系统版本、设备ID、设备属主是什么。
从什么地方来（from）：比如连接IP属于内网直连还是通过VPN接入；还有就是网络类型属于WiFi还是4G，网络信息是什么（SSID/BSSID）。
对谁（target）：对哪个页面（它的页面title是什么，创建者owner是谁，内容密级security_level是多少）。
操作类型（op_type）：增/删/改/查。
操作结果（op_return）：是否成功，原因如何等等。
=END=
《 “审计日志通用格式” 》 有 7 条评论
日志格式规范
https://blog.csdn.net/lk142500/article/details/80424945
`
1 简介
1.1 日志的作用
一般程序日志出自下面几个方面的需求：
1、 记录用户操作的审计日志，甚至有的时候就是监管部门的要求；
2、 快速定位问题的根源；
3、 追踪程序执行的过程；
4、 追踪数据的变化；
5、 数据统计和性能分析；
6、 采集运行环境数据；
1.2 撰写日志的要求
1.2.1 日志的可读性
1.2.2 日志的性能
1.2.3 占用磁盘空间
1.2.4 日志的时效性
1.2.5 日志级别(FATAL,ERROR,EARN,INFO,DEBUG,TRACE)
1.2.6 日志内容
1.2.7 日志格式(常见的日志格式中对于每一条日志应含有的信息包括日期、时间、日志级别、代码位置、日志内容、错误码等信息。)
2 日志级别和含义
2.1 Log4j的组成
Log4j由三个重要的组成构成：日志记录器(Loggers)，输出端(Appenders)和日志格式化器(Layout)。
2.1.1 Logger
控制要启用或禁用哪些日志记录语句，并对日志信息进行级别限制
2.1.2 Appenders
指定了日志将打印到控制台还是文件中.
2.1.3 Layout
控制日志信息的显示格式。
2.2 日志级别
2.2.1 TRACE
2.2.2 DEBUG
2.2.3 INFO
2.2.4 WARN
2.2.5 ERROR
2.2.6 FATAL
2.3 日志级别大小关系(DEBUG<INFO<WARN<ERROR)
3 日志规范示例
模仿，抄写是比较好的学习方式，借鉴前人撰写日志的良好风格以形成自己的风格是不错的方式。下面是一些不错的日志记录。
3.1 TRACE日志记录示例
3.2 INFO日志记录示例
3.3 DEBUG日志记录示例
3.4 WARN日志记录示例
3.5 ERROR日志记录示例
怎么样写出好的日志来?
**其实写好日志并不难，只要我们能在写代码的时候能体会到后面的维护工作的压力和艰辛，多点关注和理解就一定能做好这件事。**
`
日志导致线程Block的这些坑，你不得不防
https://tech.meituan.com/2022/07/29/tips-for-avoiding-log-blocking-threads.html
`
1. 前言
日志对程序的重要性不言而喻。它很“大”，我们在项目中经常通过日志来记录信息和排查问题，相关代码随处可见。它也很“小”，作为辅助工具，日志使用简单、上手快，我们通常不会花费过多精力耗在日志上。但看似不起眼的日志也隐藏着各种各样的“坑”，如果使用不当，它不仅不能帮助我们，反而还可能降低服务性能，甚至拖垮我们的服务。
日志导致线程Block的问题，相信你或许已经遇到过，对此应该深有体会；或许你还没遇到过，但不代表没有问题，只是可能还没有触发而已。本文主要介绍美团统一API网关服务Shepherd（参见《百亿规模API网关服务Shepherd的设计与实现》一文）在实践中所踩过的关于日志导致线程Block的那些“坑”，然后再分享一些避“坑”经验。
2. 背景
API网关服务Shepherd基于Java语言开发，使用业界大名鼎鼎的Apache Log4j2作为主要日志框架，同时使用美团内部的XMD-Log SDK和Scribe-Log SDK对日志内容进行处理，日志处理整体流程如下图1所示。业务打印日志时，日志框架基于Logger配置来决定把日志交给XMDFile处理还是Scribe处理。其中，XMDFile是XMD-Log内部提供的日志Appender名称，负责输出日志到本地磁盘，Scribe是Scribe-Log内部提供的日志Appender名称，负责上报日志到远程日志中心。
随着业务的快速增长，日志导致的线程Block问题愈发频繁。比如调用后端RPC服务超时，导致调用方大量线程Block；再比如，业务内部输出异常日志导致服务大量线程Block等，这些问题严重影响着服务的稳定性。因此，我们结合项目在过去一段时间暴露出来的各种由于日志导致的线程Block问题，对日志框架存在的稳定性风险因素进行了彻底的排查和修复，并在线下、线上环境进行全方位验证。在此过程中，我们总结了一些日志使用相关的实践经验，希望分享给大家。
3. 踩过的坑
本章节主要记录项目过去一段时间，我们所遇到的一系列日志导致的线程Block问题，并逐个深入分析问题根因。
3.1 日志队列满导致线程Block
日志量过大导致AsyncAppender日志队列被打满，新的日志事件无法入队，进而由ErrorHandler处理日志，同时由于ErrorHandler存在线程安全问题，导致大量日志输出到了Console，而Console在输出日志到PrintStream输出流时，存在synchronized同步代码块，所以在高并发场景下导致线程Block。
3.2 AsyncAppender导致线程Block
Log4j2打印异常日志时，AsyncAppender会先创建日志事件快照，并进一步触发解析、加载异常堆栈类。JVM通过生成字节码的方式优化反射调用性能，但该动态生成的类无法被WebAppClassLoader类加载器加载，因此当大量包含反射调用的异常堆栈被输出到日志时，会频繁地触发类加载，由于类加载过程是synchronized同步加锁的，且每次加载都需要读取文件，速度较慢，从而导致线程Block。
3.3 Lambda表达式导致线程Block
Log4j2打印异常日志时，AsyncAppender会先创建日志事件快照，并进一步触发解析、加载异常堆栈类。JDK 8低版本中使用Lambda表达式所生成的异常堆栈类无法被WebAppClassLoader类加载器加载，因此，当大量包含Lambda表达式调用的异常堆栈被输出到日志时，会频繁地触发类加载，由于类加载过程是synchronized同步加锁的，且每次加载都需要读取文件，速度较慢，从而导致了线程Block。
3.4 AsyncLoggerConfig导致线程Block
Log4j2打印异常日志时，AsyncLoggerConfig会初始化Disruptor RingBuffer日志元素字段，并进一步触发解析、加载异常堆栈类。JVM通过生成字节码的方式优化反射调用性能，但该动态生成的类无法被WebAppClassLoader类加载器加载，因此当大量包含反射调用的异常堆栈被输出到日志时，会频繁地触发类加载，由于类加载过程是synchronized同步加锁的，且每次加载都需要读取文件，速度较慢，从而导致线程Block。
4. 避坑指南
本章节主要对上述案例中导致线程Block的原因进行汇总分析，并给出相应的解决方案。
4.1 问题总结
日志异步处理流程整体步骤如下：
业务线程组装日志事件对象，如创建日志快照或者初始化日志字段等。
日志事件对象入队，如BlockingQueue队列或Disruptor RingBuffer队列等。
日志异步线程从队列获取日志事件对象，并输出至目的地，如本地磁盘文件或远程日志中心等。
对应地，Log4j2导致线程Block的主要潜在风险点如下：
如上图标号①所示，日志事件对象在入队前，组装日志事件时触发了异常堆栈类解析、加载，从而引发线程Block。
如上图标号②所示，日志事件对象在入队时，由于队列满，无法入队，从而引发线程Block。
如上图标号③所示，日志事件对象在出队后，对日志内容进行格式化处理时触发了异常堆栈类解析、加载，从而引发线程 Block。
从上述分析不难看出：
标号①和②处如果发生线程Block，那么会直接影响业务线程池内的所有线程。
标号③出如果发生线程Block，那么会影响日志异步线程，该线程通常为单线程。
标号①和②处发生线程Block的影响范围远比标号③更大，因此核心是要避免日志事件在入队操作完成前触发线程Block。其实日志异步线程通常是单线程，因此对于单个Appender来说，不会出现Block现象，至多会导致异步线程处理速度变慢而已，但如果存在多个异步Appender，那么多个日志异步线程仍然会出现彼此Block的现象。
4.2 对症下药
搞清楚了日志导致线程Block的原因后，问题也就不难解决，解决方案主要从日志事件“入队前”、“入队时”和“出队后”三方面展开。
4.2.1 入队前避免线程Block
1. 日志事件入队前避免触发异常堆栈类解析、加载操作。
2. 禁用JVM反射调用优化。
3. 升级JDK版本修复Lambda类Bug。
先说方案结论：
1. 自定义Appender实现，创建日志事件快照时避免触发异常堆栈类解析、加载，美团内部Scribe-Log提供的AsyncScribeAppender即是如此。
2. 日志配置文件中不使用标签，可以使用标签来代替。
4.2.2 入队时避免线程Block
结合上文分析的“日志队列满导致线程Block”案例，日志事件入队时避免线程Block的解决方案可从如下几方面考虑：
1. 日志队列满时，Appender忽略该日志。
2. Appender使用自定义的ErrorHandler实现处理日志。
3. 关闭StatusConfigListener日志输出。
先说方案结论：自定义Appender实现，日志事件入队失败时忽略错误日志，美团内部Scribe-Log提供的AsyncScribeAppender即是如此。
4.2.3 出队后避免线程Block
日志事件出队后会按照用户配置的输出样式，对日志内容进行格式化转换，此时仍然可能触发解析、加载异常堆栈类。因此，日志出队后避免线程Block的根本解决方法是在异常格式化转换时避免解析、加载异常堆栈类。
先说方案结论：显式配置日志输出样式%ex来代替默认的%xEx，避免对日志内容格式化时解析、加载异常堆栈类。
5. 最佳实践
本章节主要结合项目在日志使用方面的一系列踩坑经历和实践经验，总结了一份关于日志配置的最佳实践，供大家参考。
建议日志配置文件中对所有Appender的PatternLayout都增加%ex配置，因为如果没有显式配置%ex，则异常格式化输出的默认配置是%xEx，此时会打印异常的扩展信息（JAR名称和版本），可能导致业务线程Block。
不建议日志配置文件中使用AsyncAppender，建议自定义Appender实现，因为AsyncAppender是日志框架默认提供的，目前最新版本中仍然存在日志事件入队前就触发加载异常堆栈类的问题，可能导致业务线程Block。
不建议生产环境使用ConsoleAppender，因为输出日志到Console时有synchronized同步操作，高并发场景下非常容易导致业务线程Block。
不建议在配置文件中使用标签，因为日志事件元素在入队前就会触发加载异常堆栈类，可能导致业务线程Block。如果希望使用Log4j2提供的异步日志AsyncLogger，建议配置Log4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector参数，开启异步日志。
`
[…] 审计日志通用格式https://ixyzero.com/blog/archives/3683.html […]
《事件日志管理成熟度模型.pdf》
下载链接: https://pan.baidu.com/s/1zPjhSwbPq9D3W385cwArVQ
提取码: o512
`
背景:在遭受 SolarWinds 等事件后，美国总统拜登发布第 14028 号行政令，要求改善国家网络安全。根据行政令第 8 节的要求，白宫管理与预算办公室(OMB)于 2021 年 8 月 27 日颁布了 M-21-31 备忘录，要求做好事件日志管理和共享，提升网络安全事件响应能力，以更有效地保护联邦信息和行政分支部门与机构。
这份备忘录名称为“提高联邦政府网络安全事件的调查和补救能力”，主要是确保组织的安全运营中心(SOC)能保持最高级别的集中访问和可见性，提升事件调查和补救能力。为此，备忘录提出了事件日志管理成熟度模型，明确要求了日志记录、留存、管理等具体指标。
`
Implementing the OMB 21-31 Memorandum
https://logrhythm.com/blog/implementing-the-omb-21-31-memorandum/
Log Management Key to Meeting OMB-21-31 Requirements
https://www.devo.com/blog/log-management-key-to-meeting-omb-21-31-requirements/
Section I: Maturity Model for Event Log Management
https://www.whitehouse.gov/wp-content/uploads/2021/08/M-21-31-Improving-the-Federal-Governments-Investigative-and-Remediation-Capabilities-Related-to-Cybersecurity-Incidents.pdf
加强监控以检测针对Outlook Online的APT活动
Enhanced Monitoring to Detect APT Activity Targeting Outlook Online
https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-193a
根据 CISA 的 Microsoft Exchange Online Microsoft 365 最低可行安全配置基准，FCEB 机构应启用审计日志
https://www.cisa.gov/sites/default/files/publications/Microsoft%20Exchange%20Online%20M365%20Minimum%20Viable%20SCB%20Draft%20v0.1.pdf
Secure Cloud Business Applications (SCuBA) Project
https://www.cisa.gov/resources-tools/services/secure-cloud-business-applications-scuba-project
最猖獗的威胁、最严重的行业······深入《2023数据泄露调查报告》
https://mp.weixin.qq.com/s/v_m2w7sS6pda5b0j82arWQ
`
最近，美国通信运营商Verizon再次发布第16份年度数据泄露调查报告——《2023数据泄露调查报告》（以下简称：2023DBIR），本次报告依然基于大量现实事件进行分析，共计16,312起安全事件和5,199起数据泄露事件。本文将对报告中的重要发现及观点进行提炼分享。
数据泄露 四个关键发现
1. 最猖獗的威胁：勒索软件攻击
2. “人”仍是数据安全的重要因素
3. 不容忽视的商业电子邮件泄露 (BEC)
4. Log4j漏洞大流行
# 数据泄露 年度结果分析
VERIS框架是DBIR报告进行数据分析的基石，目前，基于该框架，报告共分析了953894起安全违规事件，确认254968起数据泄露事件。
VERIS框架将描述事件的核心分为四类（简称4A）：Actor（威胁行为体）、Action（威胁行为）、Asset（资产）和Attribute（属性）。
——即：谁（Actor），采取什么行动(Action)，影响了什么资产(Asset)以及（Attribute）资产受到怎么的影响。
2023DBIR报告提到：
## Actor（威胁行为体）
分为：外部威胁、内部威胁、合作伙伴
– 过去一年数据安全泄露事件中，外部攻击者占比高达83%，内部攻击者则占19%。
– 内部行为者不仅要为蓄意攻击负责，而且要为自身的错误行为负责。
– 无论外部威胁、内部威胁、还是合作伙伴，背后的动机95%出于经济利益的目的，与去年相比继续保持增长。
– 内部的各种违规行为更加频繁，大多涉及误用或错误操作，表明组织应该在日常安全管理方面给予更多关注。
– 由于俄乌持续冲突，国家支持的间谍攻击活动将会增加。相关事件证明，因地缘政治而引发意识形态或黑客行动相关攻击有所增加，但从更大的统计角度来看，这并未对普通企业和用户造成极大影响。
## Action（威胁行为）
威胁行为，包括：黑客攻击、恶意软件、误操作、社会工程学攻击、滥用、物理威胁、自然灾害。
– 特权账号或凭据的窃取和非法使用是数据泄露最为关键攻击手段。
– 勒索软件攻击依然令人担忧，虽然实际增长并不明显，但依然占所有数据泄露事件的24%。
– 在有组织犯罪分子实施的攻击事件中，超过62%的事件涉及勒索软件，59%的事件涉及经济动机。值得注意的是，与去年的“软件供应链末日”相比，今年没有供应商和软件供应链作为事件的行动向量。
– 全球都在Log4j漏洞下瑟瑟发抖。在这一次事件中，组织应迅速采取行动，加快打补丁和更新系统，避免了更大的灾难。
– 在黑客攻击中，最主要的攻击向量是WEB应用。
– 在社工攻击中，最主要的威胁行为样式是钓鱼。
## Asset（资产）
资产分为：Server（服务器）、Person（人员）、User（用户设备如：PC、手机等）、Network（广泛覆盖网络、路由、网络安全设备等）、Media（媒介）等。
– 人也是组织核心资产之一，是组织的最后一道防线，且在未来几年内会继续保持在第二的位置，而服务器一直排在第一位。
– Web应用程序和邮件服务器是影响最大的两类资产，而随着社会工程学的陆续发展，个人财务资产从去年开始呈现上升趋势。
– 和IT行业相比，OT领域虽然占比较少但同样受到影响。随着计算机技术大规模应用至传统工控组织、关基组织，OT遭受攻击的可能性在上升，其中制造业、采矿业、采石业、油气开采和公用事业等行业具有代表性。
– 报告数据显示，只有3.4% OT资产公开承认受到影响，考虑到系统的保密性和国家安全，真正能够公开数据和案例属于少数，真实的情况可能远远大于整个数值。
## Attribute（属性）
安全有三大属性，分别是机密性、完整性和可用性。通过描述资产的哪些属性可能受到影响，这是一种经过验证的理解事件潜在影响的方法。因此，安全人员在评估安全事件时，应首要考虑“资产或数据的副本是否泄露”(机密性)，“已知和可信的状态是否改变”(完整性)，“组织能否继续访问”(可用性)。
数据机密性，是DBIR报告一直以来关注的重点。2023DBIR提到，对过去一年数据泄露事件分析，个人信息、凭证信息、内部信息是泄露最为严重的种类。
此外有一个数据品种引起了DBIR团队的注意：虚拟货币。今年涉及加密货币的入侵数量比去年增加了四倍，与2020年相比更是相去甚远。涉及虚拟货币的网络攻击主要是漏洞利用、凭证窃取、网络钓鱼等。
# 数据泄露 事件模式分类
在2014年，DBIR报告首次引入了事件模式分类，而随着攻击类型和威胁态势的变化，每年的报告中模式分类也会发生合并与改变。
2023 DBIR报告中，将安全事件分为：基本Web应用程序攻击、拒绝服务、资产丢失和窃取、其他错误、特权滥用、社会工程、系统入侵以及其他，共八种模式。
`
question:
一条审计日志中应该包含哪些字段信息才可以认为是完整有效的？各个字段又分别起到什么作用？
answer:
一条完整有效的审计日志通常应该包含以下字段信息，每个字段的作用如下：
1. **时间戳（Timestamp）**：记录事件发生的确切时间，有助于确定事件发生的时间顺序和时序性。
2. **事件类型（Event Type）**：描述事件的类型，如登录、登出、文件访问、权限变更等，有助于识别事件的性质。
3. **用户/主体（User/Subject）**：记录执行操作的用户或主体的标识，有助于确定事件的发起者。
4. **目标对象（Target Object）**：描述操作的目标对象或资源，如文件、数据库、应用程序等，有助于确定事件的影响范围。
5. **操作（Action）**：描述执行的具体操作，如读取、写入、删除等，有助于了解事件的具体内容。
6. **结果（Result）**：记录操作的结果，如成功、失败、拒绝等，有助于评估操作的执行情况。
7. **IP地址（IP Address）**：记录执行操作的主机的IP地址，有助于确定操作的来源。
8. **设备/应用程序（Device/Application）**：描述执行操作的设备或应用程序，有助于确定事件发生的环境。
9. **审计日志来源（Log Source）**：标识审计日志的来源，如操作系统、数据库、防火墙等，有助于追踪事件的来源。
10. **详细描述（Description）**：提供关于事件的详细描述，包括额外的上下文信息或备注，有助于全面理解事件。
11. **审计记录ID（Log ID）**：唯一标识每条审计记录的ID，有助于快速检索和识别特定事件。
12. **相关链接（Related Links）**：提供与事件相关的其他信息或链接，如相关文档、报告等，有助于深入了解事件。
以上字段信息的完整性和准确性对于审计和监控系统的有效性至关重要，能够帮助组织监测和追踪系统活动，发现潜在的安全问题和异常行为。
==
question:
一条安全告警中应该包含哪些字段信息才可以认为是完整有效的？
answer:
一条完整有效的安全告警通常应该包含以下字段信息：
1. **告警时间**：记录告警事件发生的确切时间，有助于确定事件发生的时间范围。
2. **告警等级**：指示告警的严重程度，如低、中、高或紧急等级，有助于快速识别和处理重要事件。
3. **告警类型**：描述告警事件的类型，如异常登录、恶意软件检测、数据泄露等，有助于确定事件的性质。
4. **告警描述**：提供关于告警事件的详细描述，包括事件的背景信息、受影响的系统或数据等，有助于了解事件的全貌。
5. **受影响资源**：指明受到影响的资源或系统，如受感染的主机、泄露的数据等，有助于确定事件的范围。
6. **触发条件**：描述触发告警的具体条件或规则，有助于理解为何该事件被认为是异常或危险的。
7. **告警来源**：标识告警信息的来源，可能是安全设备、监控系统、日志记录等，有助于追踪事件的溯源。
8. **处理建议**：提供针对该告警事件的处理建议或应对措施，有助于快速响应和处理事件。
9. **责任人**：指定负责处理该告警事件的责任人或团队，有助于确保事件得到及时处理。
10. **处理状态**：记录告警事件的处理状态，如已处理、待处理、误报等，有助于跟踪事件的处理进展。
11. **附加信息**：额外的信息或上下文，如相关日志、网络流量数据、异常行为分析等，有助于深入分析事件。
以上字段信息的完整性和准确性对于有效管理和响应安全事件至关重要，能够帮助组织及时发现、调查和应对潜在的安全威胁。