安全审计，其实应该是信息系统建设中不可分割的一部分，是信息系统安全建设中最关键的一个环节，是信息系统安全运行的“最终守护者”。
但是，在相当长一段时间内，运营商将更多的注意力放在了内外隔离、病毒防护、网络入侵防范等领域；在涉及信息安全建设时，似乎就是防火墙、入侵检测、病毒防护这“老三篇”。
现实情况是：当运营商的运营支撑系统变得越来越庞大，当运营商传统的手工作业越来越多地被计算机替代，当运营商越来越疏远钢笔、纸张、保险箱、会计账簿，运营商的担心越来越多。同时，也实际出现了越来越多的安全事故。
谁动了我的数据？谁窃取了我的财富！
这个问题一直困扰这运营商核心业务系统的建设者、管理者、使用者。
随着“萨班斯（SOX）法案”的实施，这个问题一下变得十分的清晰和严峻：内审和内控！原来那个一直让运营商惴惴不安的威胁来自于内部！
如果说通过实施防火墙、入侵检测、病毒防护技术使得信息系统具备了相当的抵御来自外部的威胁的能力，那么，当运营商进一步关注“内控”时，运营商应该采样什么样的技术呢？
答案是“内部管理”和“安全审计”，并应当将更多精力围绕核心业务系统来展开。
下面，首先考察一下主流安全审计技术的基本实现原理。
主流安全审计技术浅析
就目前主流安全审计产品的实现形态上来看，基本的技术有两类：日志收集型和网络探测型。
基于日志收集技术的审计
这是较早的、较为传统的审计方式，主要收集并分析各种日志。登入、登出、添加、删除、修改、更新等活动，应用日志、操作系统日志、数据库日志、网络设备的日志等。网络设备及防火墙日志操作系统/应用系统日志，Syslog类工具、安全事件收集类工具。
基于日志收集类产品的工作示意图如下:
采样这种技术的日志审计产品，有着以下几个关键技术：
1、日志信息的获取
某些系统具可基于某种通用的协议，如Syslog协议、SNMP协议等，向外传递日志信息；审计系统只要兼容这些协议，就可以提取到日志信息。
某些系统，尤其是大量的数据库系统、应用系统，没有支持通用的协议来向外传递日志信息，这就要求审计系统能通过某种定制的方式去获取日志信息。
在某些系统中，本身就没有完善的日志信息，比如：数据库系统在没有启动自审计功能的情况下，几乎就没有任何实质性的审计信息，这就要求审计系统能通过其它方式来形成日志信息，并传递到审计系统。
2、日志信息的格式化和归并：
各种系统提供的日志信息的格式可能是千奇百怪的，包含的内容也没有统一的标准，这就要求审计系统具备相当的兼容能力，能够对多种格式的日志信息进行综合的处理。
在对原始日志信息进行格式化处理的基础上，基于一些基本的审计准则，对这些原始的信息进行归并处理，集中存储到审计信息数据库中。
3、基于收集的日志信息，建立有效的分析模型：
日志信息浩如烟海，审计系统必须提供一个有效的机制对这些信息进行匹配和过滤，如抽丝拨茧般从中分析出核心的信息，让使用者能迅速、直观地获取到他所关心的信息。
实际上，上面谈及的三个关键技术，也是运营商在内控审计工作实施中，要对日志型审计系统进行重点考察的三个方面。
基于网络探测技术的审计
利用Sniffer技术获取通信数据并进行会话重组和协议分析，对网络和应用数据进行记录、回放和分析，从中发现潜在威胁和事件，对于违反安全策略和规则的行为，根据安全策略发送Reset包主动中断网络连接。
基于网络探测类产品的工作示意图如下：
采样这种技术的网络审计产品，有着以下几个关键技术：
1、通信数据的获取
网络审计产品必须通过某种方式获取原始的通信数据，可以有两种方式：
1)在目标系统中安装Sniffer软件，对通信数据进行侦听，并将侦听来的数据传递给网络审计产品进行进一步的分析和处理；
2)利用网络监听技术，直接获取网络交换机上的通信流量，进行分析和处理。
目前，绝大部分的网络审计产品均采样第二种方式。
2、对各种通信协议的解析
网络审计的基本原理就是通过对通信数据的重组和分析，恢复出应用系统的应用层数据，然后对这些应用数据进行记录、匹配和响应，因此，一个网络审计产品往往要对若干种通信协议进行解析，并且具备一定的协议解析的扩展能力，能够针对某些特定的通信协议，迅速地扩展支持能力。
例如，针对Unix系统的常用维护协议（Telnet、FTP、SSH等）进行解析，对数据库操作协议（SQL协议）进行解析，对B/S或C/S类型的业务系统进行解析。
3、提供灵活、高效的匹配模型和方法
网络审计系统需要面临的几乎是所有底层的通信数据，这这些信息量远远高于日志审计产品所面临的信息量，这就要求网络审计系统必须提供灵活、高效的匹配模型，在所解析恢复出来的海量的应用数据中，定位关键的信息，并对这些信息进行合理的组织和存储。
同样，上述三个关键技术，也成为运营商考察一个网络审计产品的三个主要方面。
两种审计技术的分析和比较
由于技术思路的不同，使得日志审计产品和网络审计产品在很多方面存在着区别，下表给出了这两类产品的比较和区别：
|
|
基于日志收集的审计 |
基于网络探测的审计 |
|
审计粒度 |
取决于原有的日志系统 |
可自行定义 |
|
关注点 |
网络行为的结果 |
网络行为的过程和结果 |
|
作用点 |
拓扑中的节点 |
拓扑中的关键路径 |
|
独立性 |
系统操作者可接触日志 |
只有审计者可以控制 |
|
资源占用 |
占用系统的资源 |
可能占用带外通信资源 |
|
阻断能力 |
在系统内实施风险大 |
对于session的阻断 |
|
兼容性 |
需要进行兼容性测试 |
主要基于协议分析 |
|
部署难度 |
在系统中部署风险较高 |
旁路部署，风险小 |
|
集中性 |
不全 |
不全，可以绕过 |
由于基于日志收集的审计系统原则上是基于目标系统的原始日志信息进行加工、整理，因此，这类审计产品并不会增加审计信息量，它更关注的是如何对原有的日志信息进行格式化和归并，基于某种审计分析模型，提炼出核心的审计信息。
从这个层面讲，基于日志收集的审计系统的功能难以保障系统的安全，而且也无法满足事后的侦察和取证应用。并且安全审计并非日志功能的简单改进，也并非等同主机入侵检测，不能够仅仅通过网络抓包、还原就能够达到审计效果。
基于网络探测的审计系统原则上可以获取所有的通信流量，可以审计记录所有用户关心的内容，因此，在审计信息量方面、审计粒度方面较基于日志收集的审计系统有很好的扩充。
但是，基于网络探测的审计系统却面临如何解析多种通信协议，尤其是业务系统通信协议的难题，甚至在某些情况下，这类审计系统显得有些力不从心，比如：基于Windows图形界面、X-Window图形界面的操作，对这类审计系统而言，就难以实现有效的操作审计。
正是因为这两种审计技术都存在各自的优缺点，因此，出现了综合采样两种技术的“综合型审计”的实际安全需求。以下将结合在运营商支撑系统领域的一些审计项目经验，重点介绍这方面的技术实现。
支撑系统安全审计需求
运营商业务支撑系统发展至今，应用系统、网络设备、主机设备、操作系统、数据库由诸多的供应商提供，涉及多层次、多厂家、多型号、多版本。数据方面涵盖客户资料、营业、计费、客服、管理诸多方面。在人员方面涉及各个系统供应商的技术支持人员、现场开发人员，内部系统管理人员，业务系统的使用人员。
结合现状，以日志形式检查操作行为已远远不能满足关键业务支撑系统的发展需求。对各个系统缺乏集中统一的访问审计，无法进行综合分析，不能及时发现非法、违规行为。需要通过安全审计避免计费系统中的计费信息不被非法修改；保障核心客户的信息是被拷贝、盗取；减少业务使用者、系统管理员、供应商越权访问等问题。
从实际运维来看，内部系统维护人员、集成商、软件开发商均需要登录主机、数据库进行系统维护和故障诊断。开发商需要通过远程登录、本地登录进行软件系统的开发、调试、故障诊断。可能带来如下问题：越权访问或越权修改系统信息、违规和误操作、违反操作流程和管理规范、内外勾结获取企业核心机密信息。
这些问题如果不能有效地解决，将给系统留下很大的安全隐患。面对如此复杂的支撑系统，运营商最需要解决的问题就是高效的监督和管理。需要采用可用技术保证管理规范、操作规范的执行力度，加强内部系统管理和供应商网络行为的监督；进一步规避BOSS、经分、网管中面临的来自设备层面、系统层面、应用层面、管理层面的安全风险。
《萨班斯法案》第404条款要求进行评价的内部控制包括针对与会计报表中所有重要科目和信息披露相关的所有会计认定所实施的内部控制，包括：
主要交易是如何启动、授权、记录、处理和报告在财务报告中；
用以防范或找出与重要账户、交易种类和披露相关的错误或舞弊的内部控制措施；
其它重要内控措施所依赖的内部控制，包括一般性控制，例如信息系统控制；
非经常性、非系统交易或财务估计的内控措施；
财务报表关账和汇总过程中的内控措施等等。
围绕《萨班斯法案》第404条款的基本要求，结合运营商的业务支撑系统运维特点，面向业务系统的安全审计系统一般应具备以下功能：
针对主机、数据库、安全设备、应用多个层次的操作，UNIX命令、数据库SQL、安全设备Syslog、应用日志的细粒度审计；其中BOSS所有重要操作，特别是对财务报表有关的操作留有系统日志。
重要数据库操作的审计主要包括数据库进程运转情况、绕过应用软件直接操作数据库的违规访问行为、对数据库配置的更改、数据备份操作和其他维护管理、对重要数据的访问和更改、数据完整性等。
重要应用系统的审计主要针对BOSS、经分、网管等。审计内容包括：业务系统正常运转情况、用户开设/中止等重要操作、授权更改操作、数据提交/处理/访问/发布操作、业务流程等内容。
提供审计记录、告警、实时阻断多种控制措施，对于特别关键的业务、操作，提供原始记录和审计凭证；
提供命令查询、会话查询、安全策略查询等综合查询和报表，并可以通过“回放”对记录的TCP会话进行事后重现；
多种审计/查询手段和审计报告，能够根据需要自行定义审计报表，以多种方式获取系统的相关审计信息。
运行维护规范化、制度化，关键系统的维护操作的运行状况、使用状况可视化。
确保原有系统的正常运转，尽量减少对原系统的扰动，尽可能使系统做最小修改，并对系统性能产生最小影响。
因此，针对运营支撑系统中的安全设备和网络设备、应用系统和运行状况进行全面的收集、分析、评估是保障网络安全的重要手段。安全审计应当包括多方面、多层次，不是靠一套简单产品就能够全面覆盖，需要建立实时、集中、可视化审计，有效/及时的审查系统究竟是不是违背安全策略，并及时定位安全隐患。
综合业务安全审计系统
结合目前主流安全审计系统的现状，可以提出“综合审计”概念，建立面向运营商核心业务系统，面向业务逻辑、数据库与操作命令的业务安全审计系统。采用的“IP数据捕获＋日志收集＋定制Agent”的混合审计机制。将审计系统的职能定位为业务安全审计，更多层面体现在服务于核心业务系统的定制化审计和报表功能。
IP包捕获：工作在核心交换机上，监听来自外部的远程操作系统、数据库系统，以及BS模式的应用层面的访问，能够记录、告警、统计和分析；
日志收集：主要用于安全设备、网络设备和主机设备、数据库，能够设备的日志，解决直接在服务器上面、不经过网络的访问记录和日志，形成综合报告。
定制Agent：针对需求定制专门采集引擎，如批处理程序，由应用层记录下来日志，通过采集Agent去定时抓去过来，进行统一展现。
综合业务安全审计系统采用多重监测技术复用来保障审计信息收集的完整性、分析数据源的全面性和结果的准确性，避免通过网络远程访问或直接在服务器后面接线访问的弊端，同时避免在服务器上加装更多处理引擎导致服务器压力增多、避免开启更多数据库记录日志对数据库的压力。
综合业务安全审计系统在运营支撑系统的部署示意图如下：
业务安全审计系统针对具体应用平台(DB/OS)、业务系统(BOSS/经分/网管)的操作命令、业务逻辑进行审计。针对应用需求，如FTP/Telnet系统维护、SQL数据库维护，制定应用级别的和审计策略，使得系统能针对具体的应用或业务系统实现命令级别、访问逻辑级别的审计。对应用系统层、操作系统层及数据库层的与财务报表相关的重要文件、目录的关键操作进行审计记录，这包括支持对应用系统、操作系统、数据库系统、中间件的日志的收集。
业务安全审计系统通过对IP报的分析实现应用级的审计，基础应用策略库提供了基于IP报的安全策略的制定功能。可以直接编辑安全策略，也可在俘获的IP报的基础上，学习提炼出符合需要的安全策略。并可以通过设置来完成对通用协议，如WWW、POP3、SMTP等通信的过程的审计。
根据不同的应用协议或应用系统可以开发具备应用特征、行业特征的应用策略库，如针对BOSS、BI策略模块是综合业务安全审计系统中最具特色、最具价值的模块。
业务安全审计系统的体系结构应当包括四个层次：审计信息产生层，审计信息存储层、审计信息分析层和审计信息展现层。
审计信息产生层
产生层包括所有日志产生源。每个产生源都通过执行日志产生程序或网络探测生成日志数据，日志集中存储到审计服务器中。包括计费、帐务、营业、ETL过程，ST过程，OLAP过程，Web访问、数据库访问、OS访问功能日志等。具体包括如下几类事件：
前端应用：进行业务办理、多维分析、数据挖掘、即席查询等操作时，记录操作的对象，如访问了哪个报表，同时要记录操作者的身份，帐号。
OLAP及关系数据库：结合数据库系统身份设置不同的操作审计策略。最细粒度为SQL协议集所定义的操作命令及其对象等。根据基本SQL命令和存储过程进行组合，形成一个有实际意义的访问过程。
Unix主机审计：对Telnet、FTP、RCP、rlogin远程登录协议进行操作审计。预先设定好需要审计记录或禁止的关键命令、敏感操作过程；审计的最细粒度为上述协议的操作命令及其对象。
用户登录事件：主要记录登录的用户帐户、登录日期时间、登录的地址（计算机或IP地址）和操作结果（成功或失败）。
用户注销事件：主要记录注销的用户帐户、注销日期时间和注销的方式（正常注销或其他）。对于管理员强制注销帐户的情形，还须记录执行操作的管理员帐户。
用户管理事件：对于用户名的创建，主要记录新增的用户名、事件发生的日期时间和执行操作的管理员帐户。对于用户名的删除，主要记录被删除的用户名、事件发生的日期时间和执行操作的管理员帐户。对于口令的更换，主要记录尝试修改口令的帐户、事件发生的日期时间和操作的结果（成功或失败）。对于口令的重置，主要记录被重置口令的帐户、事件发生的日期事件和执行重置操作的管理员帐户。
策略更改事件：涉及添加用户或更改用户属性的事件发生，主要记录添加（或更改）的时间和各个用户的（更改前后）属性。系统管理员对影响系统性能的参数进行调整时，记录相应参数。
审计信息存储层
日志存储层存储由日志产生层产生的日志数据。日志数据的传输可以是实时的或接近实时的，或者是基于时间段或数据量决定的批量传输。日志数据采用集中存储的方式存储在日志服务器中。日志数据集中存储在日志服务器中。在将数据存入审计日志服务器之前必须保证数据的真实性和完整性。
日志存储包括3个方面：
应用程序本地存储，例如批处理程序写本地日志文件，再如操作系统产生的日志。
日志接收服务器的本地存储，例如应用程序写本地日志的同时，给日志服务器发送过了的日志，该日志发送者不能更改。
日志数据库，存储格式化的日志，便于进行统计分析、审计。
审计信息分析层
分析层通过监测和查看日志数据，自动分析日志，检测到可能存在的攻击和威胁时报警，并且提供生成审计报告的功能。日志接收服务器接收日志后，传给日志分析服务器，进行检测分析。
授权用户可以修改规则集和可审计事件集。系统将收集到的数据与规则集中定义的规则进行比较，如果发现异常，则可识别出存在潜在的安全侵害。系统对定义的可审计事件的出现或累计出现进行检测，如果发现异常，则可识别出潜在的安全侵害。
用户可以通过制定符合业务特征的规则，然后将多个规则进行汇总、编辑和命名，形成具备某种业务特征的规则写入用户自定义的规则库。这样，用户在针对某个特定用户制定审计策略时，可以直观地使用自命名的规则进行设置，方便了各种策略的制定和查询。
审计信息展现层
业务安全审计系统可以提供多种级别审计记录，基于时间、用户、IP地址、服务、命令、策略的查询手段，能迅速地从审计记录中获取关键信息。例如：登录/登出信息、关键操作信息、原始数据等，并提供相应的查询手段从审计记录中获取相关的信息。针对系统身份、操作命令、关键操作等提供查询手段，管理员输入这些信息后，能查询到相关的内容，并可以进一步跟踪到更详细的审计记录。
利用Web展示技术，实现对审计日志的多维分析和其他分析，可以产生图形、报表等类型的分析结果。业务审计系统提供审计报表功能，系统管理员可以根据自己关心的内容设置审计报表的输出。由于综合业务安全审计系统针对网络操作提供了多种层次的协议解析，在生成审计报表时，可以定义不同层次的输出内容。
例如，针对Unix系统的登录/登出、关键命令的执行情况、流量、TCP会话数等自动生成审计报表。通过设置合理的审计报表，管理员可以迅速、直观地了解到系统地运行情况、使用情况；如果发现异常，可以利用综合业务安全审计系统的查询、分析、跟踪功能，定位出现问题的人员、时间、操作内容等。
基于综合审计理念，建立面向运营商核心业务系统的综合型业务安全审计系统，可以帮助运营商设置比较恰当的安全策略。随着业务安全审计系统的应用和应用策略库的及时更新，业务安全审计系统所提供的功能将越来越丰富、越来越接近运营商的实际使用需求，使得审计系统能尽快地发挥出最大的安全审计和内部管理作用。（耿文欣编辑）
