统一审计
1. 修订履历
| 版本号 | 日期 | 姓名 | 修订内容 |
|---|---|---|---|
| 0.1 | 2020/1/4 | 王勇 | 新落成 |
| 0.2 | 2020/2/2 | 王勇 | 修订系统、功能、技术架构图 |
| 0.3 | 2020/2/20 | 王勇 | 添加需求部分 |
2. 题外话
最近部门领导突然找我，对我这种已经深处冷宫多年的资深咸鱼来说，很是惊恐，立马意识到肯定有大事情要发生，先听完再说，领导想筹备一个新产品，关于统一审计，主要面对的市场对信息安全审计有迫切需要的客户。听到这，我缓过神来，一想这产品，可够大的耶，由于是技术出身，对技术实现的底层很敏感，我如今底下也没这样的人，怎么做，但是当着面儿我到嘴边的话又咽下去，等需要真正落实去做，再去提资源这茬儿。当下最重要的我要梳理出来产品的抽象业务的边界，最好产品定位，以及需要描绘客户的可能会遇到的实际需求，整理汇总，形成一份产品可研报告。
3. 需求背景
随着近来我国在电商、教育、金融、通信类的业务是高速发展，随之而来的是各种应用型软件在面对各种的访问、操作信息资源的情况下，都未能及时建设企业内控审计，因而造成的安全问题时有发生，特别是在应用系统操作层面发生多起安全事件，造成影响非常恶劣。面对如此场景复杂和数据量过大的情况下，传统方案那种依赖各各业务支撑系统自身的日志功能进行审计的做法已经无法满足当前和未来业务发展的要求，更无法应对国家提倡的关于加强信息化安全管理的要求，急需建立统一的审计管理系统。
4. 系统模块定位
该系统独立运行，系统内部利用大数据等软件技术，供企业审计人员使用，可以对日常数据进行审计和回放，满足在线审计和离线审计的业务场景，解决在审计、运维过程中的“操作不可控，操作内容不可知”的问题。
5. 建设目标
统一审计系统通过“事前控制、事中监督、事后审计”的管理思路，从降低操作风险的角度出发，以操作行为管理为核心，集中管理的方式，对身份、认证、授权、审计等方面进行有效管理，从而使审计、运维管理更简单、更安全、更有效。
5.1. 技术目标
通过本项目的建设，将达到以下目标：
- 实现对审计主体信息的采集存储
- 实现对敏感核心业务进行关联的分析、审计
- 提升网络与业务系统安全等级
- 审计结果自动触发响应流程
5.2. 业务目标
- 对在业务系统中访问敏感数据、执行关键操作及其结果进行真实、全面的记录，并将业务操作行为、系统操作行为以及运营状态进行融合实现基础审计与专题审计信息，提供可用于责任追踪的相关证据及审计管理支撑手段
- 实现分级审计管理能力，支持审计任务权限分级管理、生成、分派、执行、反馈等闭环管理功能，为审计管理员完成审计工作提供必要的支撑手段，使得审计工作流程化、常态化
- 实现高效的精细化审计分析能力，规范“金字塔审计模型”中的审计信息采集、标准化、筛选、分析等处理过程，明确各环节策略配置，提供关键字、统计、关联等分析功能，并实现对异常行为的深度分析
- 将采集的应用数据集中视图展示和分条件检索，对应用日志的集中存储和集中审计，可根据线索将关联性数据进行聚合，提供基础画像的能力
5.3. 建设内容
构建应用审计模型，明确应用审计主体、客体以及审计的关联动作
新建对应用审计相关数据的采集:
- 记录采集关键敏感数据的操作行为、用户操作行为，如用户产品的套餐的变更、停开机等
- 构建基础数据采集的能力，具备文件、数据库以及消息数据的采集，并提供容错和高并发的采集能力
对需要审计的信息进行数据标准化处理
- 参考原始审计信息采集内容中的操作类型、操作子类、操作细项、审计级别制订本地化的审计信息类型编码标准
- 根据审计信息类型编码标准以及操作关键字匹配后进行补全，按照统一的格式存储
新建对应用信息的筛选:
- 按照审计信息筛选策略对标准化信息中的关键行为、关键资源进行匹配或对关键字进行识别，提取出需要进行审计分析的信息。在数据抽取的过程中，可以对需要归并的数据进行归并处理
- 针对抽取后的审计信息中的操作类型、操作子类、操作细项、组织机构等进行匹配，按照专题进行归类存储。
新增对应用审计信息的分析、预警，根据5W1H分析模型，整合事件的属性（WHEN-时间、WHERE-地点、WHO-人物、WHAT-对象、HOW-动作、WHY-凭据）进行分析、提炼、归纳出违规和异常行为特征，再根据响应的策略，触发相关的预警流程
6. 系统功能
6.1. 系统总体架构
系统架构
6.2. 功能架构
功能架构图
6.3. 技术框架
审计平台技术架构应分为审计分析应用、数据应用、数据存储、数据采集与处理，总体技术架构如下图所示：
技术架构图
- 审计分析应用：主要采用查询技术、报表技术、搜索引擎技术；
- 数据应用：支撑应用必备的任务处理、消息以及web容器技术：
- 数据存储：对数据进行存储，按照类型可分为关系型存储和非关系型存储；
- 数据采集与处理：主要包括基于分布式的大数据计算技术，包括离线模式和实施模式；
7. 数据采集
按照数据来源来区分有两种：
- 内部数据
各系统中的网络设备、主机操作系统、数据库及应用软件自身安全功能产生的日志。优点是能够充分利用现有系统的能力、记录较为全面（从功能上来说，无论通过网络还是在本地本机的访问，全部能够记录），缺点是开启日志记录功能尤其是数据库系统的审计功能需要占用系统资源，部分系统需要改造；
- 外部数据
获取外部数据存在三种实现方式，一、是通过镜像方式，分析、记录访问各类设备、应用、网络资源的操作行为。优点是不占用被审计系统的资源、不需要改造已有系统，部署灵活；缺点是无法记录本地访问，无法对加密数据流（如SSH、HTTPS等）进行分析和审计，很难针对每一类图形界面方式的应用进行审计；二、是采用堡垒主机方式，通过在网络中串行接入堡垒主机，对通过的流量进行拦截和记录，这种方式可以较好的解决加密数据流以及图形操作记录等审计的问题，其典型的实现就是综合接入维护平台；三、采用爬虫技术，在WEB端模拟浏览器信息，获取后端传送前端的数据内容，再分析和审计。
具体应用时应灵活利用三种方式，进行有效组合，以适应不同的系统、组网等情况的数据收集，避免功能重叠、资源浪费。例如，通过内部数据获取SSH、HTTPS以及非标准应用的用户操作信息，为避免影响数据库处理效率，通过外部数据获取数据库访问操作的信息。
数据特点
7.1. 采集机制和策略
7.1.1. 采集机制
对本地数据，应包括但不仅限以下方式：
- Syslog方式；
- SNMP方式；
- ODBC方式，数据库自身日志功能开启情况下，可通过ODBC方式收集数据库日志；
- Flatfile：该日志收集机制与Syslog逐条发送机制相对应，是系统日志文件整体传送和解析的机制；在条均允许的情况下，大量非实时日志数据、windows或xwindows的视频回放数据，可采用这种方式；
- OPSEC：Checkpoint防火墙通过OPSEC协议发送日志，需要支持OPSEC方式接收日志；
- 审计代理：对windows类操作系统，需要在主机上安装审计代理软件，收集系统日志；审计代理不应占用大量的系统资源或降低系统原有安全性。
对外部数据，应包括但不仅限以下方式：
- 利用爬虫技术对目标网站的内容进行抓取形成外部数据；
- 通过对网络设备进行镜像等方式获取审计对象的网络报文流量，形成外部数据；
- 通过堡垒主机串接方式，实现对审计对象用户操作的数据采集，形成外部数据；
7.1.2. 采集策略
内部数据采集方式支持通过安装审计代理程序或修改系统配置来进行日志的采集，通过数据收集策略定制来开启与关闭各系统的数据采集功能及确定应采集的数据的种类。
外部数据采集方式支持通过网络镜像、堡垒主机等方式获取审计对象的网络报文流量，进行协议解析和会话还原。按照访问控制的策略支持对特定用户和特定服务的操作行为的记录。
7.1.3. 数据传输安全
传输过程支持加密认证机制。数据传输异常中断，系统能够提示异常、重新传输。
7.2. 采集对象及关键操作
-
WEB服务器
-
BS架构应用
-
CS架构应用
-
主机系统
-
数据库
-
网络设备
8. 数据标准化
主要实现应包括但不仅限以下：
-
由于数据采集模块收集到多种类型的数据，而这些数据定义的格式和内容不尽相同，数据标准化模块将不同的数据格式转换成标准的数据格式并存储，为上层应用提供数据支持。
-
由于不同的设备，对事件的严重程度定义及侧重点不尽相同，不利于根据统一的安全策略进行处理。日志标准化模块将按照日志来源类型、事件类别、事件级别等可能的条件及条件的组合对事件严重级别进行重定义，便于日志分析模块的分析处理。
三类数据信息标准化要求：
-
用4A系统的帐号口令从而获取的用户访问相关信息，标准化字段包括主帐号信息、从帐号信息、用户身份信息（如用户姓名、用户职务）、所属机构、MSS系统<人资、薪酬、岗位关联信息、技能>信息、用户的登录信息（如登录ip等）、访问策略。
-
事件信息的标准化字段包括事件编号信息（此字段信息应全局唯一，作为标识事件的主键）、事件名称、事件原始时间、事件采集时间、事件内容、事件类型、事件源地址、事件目的地址、事件源端口、事件目的端口、事件原始级别、事件标准化后的级别、事件采集来源、事件涉及协议、会话信息。
-
资产信息的标准化字段包括资产名称、资产IP、资产所属域、资产管理人员、资产重要程度。
应明确的是，标准化并不是对原始日志的简单压缩或消减，在标准化的过程中，很多信息字段是无法从原始日志信息中获得的，需要日志集中管理与审计系统综合其它系统的相关数据分析生成，因此以上字段并不表示对原始日志提供信息的要求，而是指经过标准化后的日志信息应包括以上字段，各省可根据实际情况有所增减。
举一例如下：
| 版本 | 字段名 | 描述 |
|---|---|---|
| 1 | 事件编号 | 该事件全局的唯一编号 |
| 2 | 事件名称 | 事件名 |
| 3 | 事件内容 | 事件内容主体，如操作命令 |
| 4 | 事件类型 | 事件类别 |
| 5 | 设备地址 | 产生该事件的设备地址 |
| 6 | 设备名称 | 设备名称 |
| 7 | 设备类型 | 该设备的设备类型 |
| 8 | 严重级别 | 事件在重新定义后的严重级别 |
| 9 | 原始级别 | 事件的原始严重级别 |
| 10 | 事件时间 | 事件进入安全管理系统的时间 |
| 11 | 原始时间 | 事件产生时的时间 |
| 12 | 协议 | 事件相关的协议名 |
| 13 | 源地址 | 事件的源地址 |
| 14 | 源子网掩码 | 事件源地址的子网掩码 |
| 15 | 目的地址 | 事件的目的地址 |
| 16 | 目的子网掩码 | 事件目的地址的子网掩码 |
| 17 | 源主机名 | 事件源主机名称 |
| 18 | 目的主机名 | 事件目的主机名称 |
| 19 | 源端口 | 事件的源端口 |
| 20 | 目的端口 | 事件的目的端口 |
| 21 | 源进程 | 事件源相关的进程名 |
| 22 | 目的进程 | 事件目的相关的进程名 |
| 23 | 主帐号 | 事件相关的主帐号名 |
| 24 | 从帐号 | 事件相关的从帐号名 |
| 25 | 访问策略 | 客户访问应用系统策略 |
| 26 | 会话标识 | 会话ID信息 |
| 27 | Agent名称 | 系统收集该事件的Agent名称 |
| 28 | 客户信息 | 待补充定义 |
| 29 | 账户信息 | 待补充定义 |
| 30 | 产品信息 | 待补充定义 |
| 31 | 套餐信息 | 待补充定义 |
| 32 | 区域信息 | 待补充定义 |
| 33 | 包区信息 | 待补充定义 |
