中国移动日志集中管理和审计系统功能及技术规范综述.docx
《中国移动日志集中管理和审计系统功能及技术规范综述.docx》由会员分享，可在线阅读，更多相关《中国移动日志集中管理和审计系统功能及技术规范综述.docx（32页珍藏版）》请在冰豆网上搜索。
中国移动日志集中管理和审计系统功能及技术规范综述
中国移动通信企业标准
QB-╳╳-╳╳╳-╳╳╳╳
中国移动日志集中管理和审计系统
功能及技术规范
TheRequirementsandTechnicalSpecificationoftheCentralizedSystemforLogmanagementandAudit
版本号：
1.0.0
2008-╳╳-╳╳实施
2008-╳╳-╳╳发布
中国移动通信有限公司发布
目录
1.范围1
2.规范性引用文件1
3.术语、定义和缩略语1
4.综述2
4.1.建设需求2
4.2.建设目的3
4.3.系统总体框架4
5.日志采集5
5.1.采集对象及关键操作6
5.2.采集机制与策略8
6.日志标准化10
7.日志分析11
7.1.功能要求11
7.1.1.用户身份关联11
7.1.2.资产关联12
7.1.3.操作行为分析能力12
7.1.4.高危操作审计13
7.1.5.数据库操作指令还原13
7.1.6.会话重放13
7.1.7.事件生成效率14
7.1.8.审计查询14
7.1.9.审计分析报告14
7.2.审计策略15
7.2.1.事件分类15
7.2.2.事件分级15
7.2.3.缺省策略15
7.2.4.策略定制15
7.2.5.定义合法行为15
7.3.事件响应16
7.3.1.触发警报条件16
7.3.2.告警方式16
7.3.3.告警信息16
8.自身管理功能16
8.1.日志功能16
8.1.1.原始记录管理17
8.1.2.备份管理17
8.2.自身安全管理功能17
8.2.1.多级用户划分17
8.2.2.用户帐号管理17
8.2.3.日志分组管理17
8.2.4.用户认证管理18
8.2.5.认证失败处理18
8.2.6.自身审计数据生成18
8.2.7.自身安全审计记录18
8.2.8.组件管理18
9.时间同步要求19
10.系统部署方面的要求19
10.1.整体要求19
10.2.代理程序的安装和卸载19
10.3.产品卸载安全19
11.日志存储与备份20
11.1.日志存储20
11.1.1.存储安全性要求20
11.1.2.存储配置管理20
11.2.日志备份20
11.2.1.备份日志安全性要求20
11.2.2.备份数据存储压缩比21
11.2.3.备份恢复功能21
11.2.4.备份管理配置21
12.接口要求21
12.1.与被管理系统接口22
12.1.1.采集接口22
12.1.2.采集信息22
12.2.与帐号口令集中管理系统接口23
12.2.1.采集接口23
12.2.2.采集信息23
12.2.3.用户管理接口23
12.2.4.身份认证接口24
12.3.与综合维护接入平台接口24
12.3.1.采集接口24
12.3.2.采集信息24
12.4.与工单系统接口24
12.5.告警转发接口25
12.6.日志转发接口25
12.7.数据传输安全25
13.性能要求25
13.1.稳定性25
13.2.资源占用25
13.3.网络影响25
14.编制历史26
前言
随着中国移动通信网、业务网及各支撑系统的不断发展，各类设备产生的日志信息也越来越多。
为了更好的对系统日志进行管理，提高系统安全度，以满足SOX法案审计要求，需要建立一套统一的日志集中管理及审计系统。
中国移动日志集中管理及审计系统是各通信网、业务网和各支撑系统统一的日志汇总、存储、管理的节点。
系统主要完成对各被管理网络或系统的日志采集，日志标准化，日志分析，输出审计结果、告警、报表等功能。
系统通过分析各种操作日志，及时发现通信网、业务网和各支撑系统中的非法用户、非法访问、异常操作、异常状态等安全信息，及时通知相关人员进行处理，提高各被管理通信网、业务网和各支撑系统的安全管理水平。
具体实施中，在集中化总体原则下，可综合考虑维护管理职能划分、业务特点等因素，规划系统建设数量。
本标准规范了中国移动日志集中管理及审计系统的建设需求，建设目的，总体框架，系统功能，系统接口要求等。
本标准可作为选用日志集中管理与审计产品，进行产品开发与测试、应用开发与改造的技术依据，指导日志集中管理与审计系统的建设。
本标准由中移号文件印发。
本标准由中国移动通信有限公司网络部提出并归口。
本标准由标准归口部门负责解释。
本标准起草单位：
中国移动通信有限公司网络部、业务支撑系统部、管理信息系统部。
中国移动集团北京公司，中国移动集团湖南公司、亿阳信通股份有限公司、北京神州泰岳软件股份有限公司、华为技术有限公司、北京紫光顺风信息技术有限公司、北京汉铭信通科技有限公司、国际商业机器（IBM）中国有限公司、北京天融信网络安全技术有限公司。
本标准主要起草人：
魏丽红、杨永、周智、徐海东、曹一生、马翀、吴哲峰、陈敏时、刘楠、田峰、冯运波、陈江峰、文兵、王杰涛、张威、魏郧峰、郑汉刚、李钒、马宏伟、李攀、胡善坤。
范围
为指导中国移动通信集团及各省公司建设日志集中管理与审计系统，明确通信网、业务系统和支撑系统日志集中管理与审计系统的系统架构、主要功能、关键技术等，特制定本规范。
本规范完全适应集中或者分级、跨专业或者分专业等多种建设模式，实现主机、网络和应用三个层面的日志集中统一管理。
规范性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款。
凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。
凡是不注日期的引用文件，其最新版本适用于本标准。
表1-1
[1]
BS7799
信息安全管理体系标准
[2]
COBIT
[3]
Sarbanes-OxleyAct
《萨班斯法案》
[4]
《中国移动（香港）有限公司内部控制手册》
中国移动通信有限公司
[5]
《中国移动内部控制手册》
中国移动通信有限公司
[6]
《中国移动帐号口令集中管理技术要求》
中国移动通信有限公司
术语、定义和缩略语
下列术语、定义和缩略语适用于本标准：
加一列英文
表1-2
词语
英文
解释
本地型日志
各系统网络设备、主机操作系统、数据库及应用直接产生的日志。
网络型日志
在网络层面通过镜像等方式获取审计对象的网络报文流量分析，转换后的日志。
4A（AAAA）
Accounting,Authorization,Authentication,Audit
帐号管理，授权，认证，审计
SOX
Sarbanes-Oxley
萨班斯法案
MISC
MobileInformationServiceCenter
移动信息服务中心
WAP
WirelessApplicationProtocol
手机无线增值业务
BS7799
BritishStandards7799
信息安全管理标准
COBIT
ControlObjectivesforInformationandrelatedTechnology
IT管理与控制框架
OPSEC
OPERATIONSECURIITY
CheckPoint软件技术有限公司的开放式体系结构解决方案
综述
随着中国移动通信有限公司通信网、业务网、支撑系统的迅速发展，网络规模迅速扩大，主机、网络设备、应用软件数量不断增多，业务资源访问、操作量不断增加，由于内控措施不力造成的安全问题时有发生。
依赖各通信网、业务网和各支撑系统中设备自身的日志功能进行审计的做法已经无法满足中国移动目前和未来业务发展的要求，无法满足国家和资本市场的要求，急需建立统一的日志集中管理与审计系统。
该系统审计被管设备记录的用户操作行为日志。
被管设备根据用户操作行为或自身安全检测功能分析形成的安全事件日志，由规划中的安全运行管理系统直接处理。
1.2.建设需求
目前，全网日志集中管理与审计需求主要包括：
1．全面的日志采集需求：
根据中国移动通信网、业务网和各支撑系统中的主机、网络设备、应用系统类型和网络分布，采取基于各设备自身产生的日志文件的本地型日志采集方式和基于网络流量抓取的网络型日志采集方式，对全网设备、应用以及网络中的各类操作进行全面的日志采集。
2．审计记录的规范化需求：
由于全网设备种类繁多，各设备日志信息存储格式、字段含义、通信协议差异较大。
需要对采集到的各种设备日志进行归一化处理，提取审计记录完整信息，为后续审计分析提供依据。
3．基于策略的日志过滤、归并：
面对海量原始日志，需要按照相关策略进行过滤和归并，减轻日志数据传输压力和存储压力。
4．本地型日志审计与网络型日志审计相结合的审计体系。
本地型日志，主要采用设备自身能力，记录较为详细的本地操作，各设备提供商可以更好地理解、确定重要操作类型、重要操作指令和关键词等，然后通过多种采集机制汇总到日志集中管理与审计系统，但缺点是开启数据库审计等功能，会导致系统性能快速下降，尤其不适合于已建系统的审计；网络型日志则通过网络旁路抓包的方式获取网络操作，较适应于标准指令如telnet、SQL的审计，不会影响所审计的系统性能，但难以识别非标准应用软件层面的关键操作。
两者互补、结合，构成中国移动综合的审计体系。
5．多维关联分析需求：
对于来自各个资源的日志信息，提供多维的关联分析功能。
面向系统用户，将一个用户在多个设备上的操作进行横向关联分析，形成以用户为主题的操作行为审计；面向特定安全事件，对于发生在多个设备上的事件痕迹进行关联分析，形成一个完整的事件相关操作过程的审计；从设备角度，形成本设备全部访问情况的安全审计报告。
6．日志存储需求：
原始日志信息是来自网络的第一手数据，需要长期存储，并确保它们的完整性、保密性，不得随意访问、修改和删除。
同时，由于日志量较大，应提供压缩存储机制。
7．符合Sox法案内控报表需求：
根据Sox法案对企业内控的要求，应提供符合Sox法案要求的各种内控报表。
1.3.建设目的
通过实施日志集中管理和审计，可以达到对用户操作行为重点审计，及时发现异常操作，提高审计效率的目的。
1.实现自动的日志集中采集与存储。
将各专业系统的系统日志、应用日志、操作访问日志汇聚到一起，进行分类、压缩存储。
2.实现自动的日志集中分析。
通过定义规则，对日志进行横向和纵向关联，进行自动化分析，找出潜在安全问题。
3.实现自动的日志集中审计。
通过将操作、访问日志关联到用户，分析用户的操作行为，以便于责任认定。
4.实现审计结果自动触发响应流程的机制，更快、更早地发现问题，将损失降低到最低限度。
5.提升通信网、业务网和各支撑系统的安全等级。
通过集中化的日志集中管理与审计系统，实现对日志的自动采集、分析、审计和响应，提高日志审计的效率，做到问题早发现早处理，将风险控制在可以接受的程度。
1.4.系统总体框架
日志集中管理与审计框架结构如图4.1所示。
本文后续章节将对各模块进行说明。
图4.1日志集中管理与审计系统框架
图4.1是日志集中管理与审计系统的逻辑结构，整体功能分为四层：
第一层，数据采集适配层。
日志集中管理与审计系统通过Syslog、ODBC、SNMPTrap、Socket、File等多种接口，采集各设备、系统和应用的本地型日志；通过镜像等方式采集网络型日志，通过两种采集方式的合理配置，实现对被管网元中所有用户操作行为的信息采集。
第二层，日志标准化层。
将采集层采集到的不同类型、不同格式的日志数据，通过标准化处理，形成归一化的日志格式，以便后续分析和审计。
第三层，日志分析层。
通过对日志的横向和纵向的关联分析，发现异常操作，找出可能存在的安全问题；对用户的操作、数据库访问进行回放，分析用户权限是否合理，在发生问题时，可用作责任认定；将分析发现的问题生成告警信息送上层处理，以及时通知用户，也可以转发到第三方系统处理，如直接向电子运维系统派单。
第四层，展现层。
主要包括四个关键的功能模块。
审计策略功能主要完成用户对审计策略的定制，修改等功能，并通过此模块向下层派发，实现审计策略的更新；报表功能主要完成经报表呈现功能，支持用户灵活定制各种报表，输出符合规范要求的报表，展现日志集中管理与审计系统的各类审计结果；告警输出模块根据下层送来的分析结论，一方面生成声光电告警，以提示维护人员处理，另一方面，可以按照工单借口要求，生成自动工单，送往EOMS。
此模块也能实现用户对各种告警信息、告警格式的灵活定义；原始日志检索功能主要满足用户对各类原始日志的检索、查询、排序等数据处理需求。
日志集中管理与审计系统还应与本省内的其他系统如EOMS等实现接口互联，通过接口可以将日志或告警信息转发到其他系统进行进一步的分析处理。
日志采集
日志采集模块应覆盖所有的网络设备、主机操作系统、数据库以及各个应用，实现对所有用户访问操作、尤其是各类关键操作记录的收集。
系统采集的日志有两种来源：
1.本地型日志：
各系统中的网络设备、主机操作系统、数据库及应用软件自身安全功能产生的日志。
优点是能够充分利用现有系统的能力、记录较为全面（从功能上来说，无论通过网络还是在本地本机的访问，全部能够记录），缺点是开启日志记录功能尤其是数据库系统的审计功能需要占用系统资源，部分系统需要改造；
2.网络型日志：
存在两种实现方式，一是通过镜像方式，分析、记录访问各类设备、应用、网络资源的操作行为。
优点是不占用被审计系统的资源、不需要改造已有系统，部署灵活；缺点是无法记录本地访问，无法对加密数据流（如SSH、HTTPS等）进行分析和审计，很难针对每一类图形界面方式的应用进行审计；二是采用堡垒主机方式，通过在网络中串行接入堡垒主机，对通过的流量进行拦截和记录，这种方式可以较好的解决加密数据流以及图形操作记录等审计的问题，其典型的实现就是综合接入维护平台（参见《中国移动综合维护接入平台功能及技术规范v1.0.0》）。
具体应用时应灵活利用两种方式，进行有效组合，以适应不同的系统、组网等情况的日志收集，避免功能重叠、资源浪费。
例如，通过本地型日志获取SSH、HTTPs以及非标准应用的用户操作信息，为避免影响数据库处理效率，通过网络型日志获取数据库访问操作的信息。
1.5.采集对象及关键操作
5.1.1.主机系统
●Solaris
●AIX
●Windows
●Linux
●等等
操作记录包括：
系统文件和文件属性修改，口令输入、关键应用系统文件的改变、增加和改变用户属性、系统启动和关闭等。
所有系统特权命令的使用都被全面的记录。
日志内容至少包括：
用户操作时的用户识别符、登陆时间、注销时间、事件发生的日期和时间事件内容或操作结果等。
5.1.2.数据库
●Oracle
●DB2
●SQLServer
●Sybase
●Informix
●等等
操作记录包括：
用户登录、注销、数据查询、插入、数据修改、数据删除、修改配置等。
日志内容至少包括：
用户操作时的用户识别符、登陆时间、注销时间、事件发生的日期和时间事件内容或操作结果等。
5.1.3.网络设备
CISCO、Juniper、华为等主流厂商的交换机和路由器，其它厂商设备等。
操作记录包括：
用户登录、修改配置等。
5.1.4.各类安全设备
●IDS设备，如ISS等主流厂商或者现网在用的HIDS、NIDS产品。
●防火墙设备，如CheckPoint、CiscoPIX、Netscreen、华为等主流厂商或者现网在用的防火墙设备。
●帐号口令管理系统；
●防病毒系统等等。
操作记录包括：
用户登录、修改配置等。
操作记录包括：
用户登录、修改配置、收集到的入侵事件日志等。
5.1.5.Web服务器
●WebLogic
●Apache
●MicrosoftIIS
●WebSphere
●等等
操作记录包括：
用户登录、修改配置、应用层的操作等。
日志内容至少包括：
用户操作时的用户识别符、登陆时间、注销时间、事件发生的日期和时间事件内容或操作结果等。
5.1.6.邮件服务器
●Sendmail
●Exchange
●等等
操作记录包括：
用户登录、修改配置、应用层的操作等。
5.1.7.B/S结构的应用
●MISC业务的应用
●其他
操作记录包括：
用户登录、修改配置、应用层的操作等。
日志内容至少包括：
用户操作时的用户识别符、登陆时间、注销时间、事件发生的日期和时间事件内容或操作结果等。
5.1.8.C/S结构的应用
●智能网业务的应用
●短信业务的应用
●其他
操作记录包括：
用户登录、修改配置、应用层的操作等。
日志内容至少包括：
用户操作时的用户识别符、登陆时间、注销时间、事件发生的日期和时间、事件内容或操作结果等。
1.6.采集机制与策略
5.2.1.日志采集机制
对本地型日志，支持以下采集方式：
⏹Syslog方式；
⏹SNMP方式；
⏹ODBC方式，数据库自身日志功能开启情况下，可通过ODBC方式收集数据库日志；
⏹Flatfile：
该日志收集机制与Syslog逐条发送机制相对应，是系统日志文件整体传送和解析的机制；在条均允许的情况下，大量非实时日志数据、windows或xwindows的视频回放数据，可采用这种方式；
⏹OPSEC：
Checkpoint防火墙通过OPSEC协议发送日志，需要支持OPSEC方式接收日志；
⏹审计代理：
对windows类操作系统，需要在主机上安装审计代理软件，收集系统日志；审计代理不应占用大量的系统资源或降低系统原有安全性。
对网络型日志，支持以下采集方式：
⏹通过对网络设备进行镜像等方式获取审计对象的网络报文流量，形成网络型日志。
⏹通过堡垒主机串接方式，实现对审计对象用户操作的数据采集，形成网络型日志。
然后，日志集中管理与审计系统采用与本地型日志采集相同的方式采集网络型日志文件。
。
5.2.2日志采集策略
本地型日志采集方式支持通过安装审计代理程序或修改系统配置来进行日志的采集，通过日志收集策略定制来开启与关闭各系统的日志采集功能及确定应采集的日志的种类。
网络型日志采集方式支持通过网络镜像、堡垒主机等方式获取审计对象的网络报文流量，进行协议解析和会话还原。
按照访问控制的策略支持对特定用户和特定服务的操作行为的记录。
5.2.3数据传输安全
传输过程支持加密认证机制。
数据传输异常中断，系统能够提示异常、重新传输。
日志标准化
本模块主要实现以下功能：
1.由于日志采集模块收集到多种类型的日志，而这些日志定义的格式和内容不尽相同，日志标准化模块将不同的数据格式转换成标准的数据格式并存储，为上层应用提供数据支持。
2.由于不同的设备，对事件的严重程度定义及侧重点不尽相同，不利于根据统一的安全策略进行处理。
日志标准化模块将按照日志来源类型、事件类别、事件级别等可能的条件及条件的组合对事件严重级别进行重定义，便于日志分析模块的分析处理。
三类日志信息标准化要求：
1.从帐号口令管理系统获取的用户访问相关信息，标准化字段包括主帐号信息、从帐号信息、用户身份信息（如用户姓名、用户职务）、用户的登录信息（如登录ip等）、访问策略。
2.事件信息的标准化字段包括事件编号信息（此字段信息应全局唯一，作为标识事件的主键）、事件名称、事件原始时间、事件采集时间、事件内容、事件类型、事件源地址、事件目的地址、事件源端口、事件目的端口、事件原始级别、事件标准化后的级别、事件采集来源、事件涉及协议、会话信息。
3.资产信息的标准化字段包括资产名称、资产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名称
日志分析
1.7.功能要求
用户身份关联
由于网络及应用的复杂化，孤立的设备日志无法直接与用户关联在一起身份，不利于问题分析、处理。
通过有效的关联，准确地判断出用户的身份和属性，从而将操作行为和自然人进行对应。
审计系统需要支持将系统层的日志、数据库日志、应用层的日志及网络数据和实际用户关联起来，支持对不同用户之间的操作的日志进行关联审计，区分不同用户行为和聚合同一用户的行为。
用户的关联能力可以通过两种方式实现。
1.如果审计系统采集到的日志含有用户身份信息，或审计系统具备用户身份数据库，则由审计系统自身完成用户身份关联分析；
2.如果审计系统中不具备上述能力，可以和帐号口令管理系统进行结合，实现和用户身份的关联分析。
从数据统一性和维护方便的角度考虑，建议采用第二种方式。
资产关联
审计结果需要和资产进行关联，以实现事件和资产的对应，直观地为相关系统管理人员、安全人员提供具体系统的安全状况。
资产关联能力可以通过两种方式实现。
1、如果审计系统中具备资产管理的能力，审计出的事件和内置的资产管理模块进行关联分析；
2、如果审计系统中不具备资产管理能力，可以和如资源管理平台等其他资产管理系统进行结合，通过对其进行查询等操作，实现和审计事件的关联分析。
从数据统一性和维护方便的角度考虑，建议采用第二种方式。
操作行为分析能力
通过审计系统，要在海量的网络事件中审计出用户操作行为，支持将系统层的日志、数据库日志、应用层的日志及网络数据进行相互关联，尤
升级会员 