一、 方案概述某市电子政务监控预警平台建设方案东软

　　1.1 方案建设目标

　　某市电子政务网络由全市各个委办局单位网络接入组成，由于接入单位众多且各自单位信息安全建设水平参差不齐，经常造成内部网络病毒和异常安全事件发生。考虑到电子政务网络实际组成和规模情况，东软设计出全市电子政务监控预警平台（以下称“监控预警平台”）的主要目标是基于电子政务网络和信息系统在安全保障以及监管信息系统建设方面所面临的形式和问题，研发一套综合的风险预警平台，进一步加强电子政务网络和信息系统的监管力度，总体把握市政务网络和信息系统的安全运行状况，提高各政务单位在应对突发网络攻击事件的应急响应能力和风险预警能力，从而有力地支撑市政务网络和信息系统的稳定运行。

　　1.2 方案设计原则

　　考虑到本平台最终为全市的政务单位进行统一服务，在本方案设计中，我们遵循了以下的原则：

　　先进性原则

　　提出最新的安全监控预警平台的概念，将安全监控和安全技术有效衔接，并根据电子政务业务需求，与业务网络深入结合，从而保证系统的先进性，以适应未来数据发展的需要。

　　整体安全和全网统一的原则

　　该平台的系统设计从完整安全体系结构出发，综合考虑信息网络的各种实体和各个环节，综合使用不同层次的技术和理论，为信息网络运行和业务安全提供全方位的监控和服务。

　　标准化原则

　　参考国内外权威的安全技术与管理体系的相关标准进行方案的设计和技术的选择。整个系统安全地互联互通。

　　技术和管理相结合原则

　　整个平台结合了安全技术与监控管理机制、人员思想教育与技术培训、安全规章制度等内容。

　　可扩展性原则

　　为方便满足网络规模和安全功能的扩展，本设计方案考虑了网络新技术和业务发展的扩充要求，以及市电子政务网络自身的特点，本方案所设计的平台系统具有灵活的扩展能力，能够随着各个监控节点，随着平台的功能扩展进行灵活的扩展。并且平台具备定期升级，不中断业务应用服务的能力。

　　开放性原则

　　该平台的运行需要与多种设备协调，如：主机设备、网络设备、安全设备、应用系统等等，该平台提供了一定的开放性以适应与相关设备和系统的适应。

　　1.3 方案设计思路

　　电子政务网络监控预警平台，以分布式方式采集来自于电子政务网络的各个相关设备的日志信息和告警事件信息，经过智能的关联分析后，准确判断真实的安全事件，快速定位安全事件的来源，分析安全事件的根本原因，集中展示市电子政务网络的整体安全状况。一旦发现高风险安全事件，自动触发安全事件处理流程，督促相关责任人进行快速解决问题和故障。

　　1、监控对象定位：电子政务外网、政务用户互联网接入、重要信息系统、政务网站等等。

　　2、日志信息的来源：电子政务外网汇聚节点或者接入节点的安全设备、政务用户互联网接入节点的安全设备、重要信息系统边界部署的安全设备、重要信息系统自身、政务网站边界部署的安全设备等等。

　　3、由专用的数据采集引擎负责数据采集，数据采集引擎采用分布式部署。

　　4、展示平台具有多元化、分层次等展示形态。

　　二、 电子政务网络监控预警平台体系架构

　　为了充分满足电子政务网络的部署现状，本方案所设计的监控预警平台从体系架构上可分为：IT基础层、数据采集层、数据处理层、展示层四个层面，各个层面包括了多个功能模块或子系统。该平台的整体架构示意图如下：

  　1、IT基础层为监控预警平台的数据获取来源。

　　2、数据采集层：根据平台指定的运维策略，数据采集层负责从网络设备、安全设备、业务系统、服务器等采集各种安全信息、日志信息、流量信息，经过数据格式标准化、数据归并、数据压缩等处理后，提交给上层数据处理平台。

　　3、数据处理层：将采集到的原始数据按照业务系统数据、网络数据、安全数据进行分门别类，经过基于统计、基于资产、基于规则的关联分析后，科学合理的定义安全事件的性质和处理级别，作为展示平台的数据基础。

　　4、展示层：实现整个平台的灵活展示和配置管理。一方面通过丰富的图形化展示方式呈现电子政务网络、政务用户互联网接入、重要信息系统、网站等安全状况，提供有效的安全预警，减少安全破坏的发生，降低安全事件所造成的损失；另一方面对整个监控预警平台进行配置与维护。

　　三、 IT基础层

　　IT基础层为监控预警平台的数据获取来源，至少包括如下范围：

　　1、网络设备，包括：路由器、交换机等；

　　2、安全设备，包括：入侵检测系统、网络审计系统、病毒检测系统、漏洞扫描系统、防火墙、异常流量检测系统、网站诊断系统等；

　　3、应用系统，包括：主机操作系统、数据库系统、中间件系统等；

　　4、服务器，包括：日志服务器、网管服务器等。

　　四、 数据采集层

　　数据采集层主要通过数据采集引擎来实现原始数据的获取，为统一的信息库提供基础数据。

　　4.1 采集方式

　　因为该平台面临政务网络内不同单位众多类型厂商品牌设备构成的多种数据来源，每一种数据来源的信息都存在较大差异，为了保证平台能够获取全面的数据，数据采集引擎在获取原始数据时，需要支持如下几种数据采集方式：

　　1、 通过配置实现采集：通过配置采集源的Syslog、SNMP Trap、Socket、ODBC/JDBC、Flow等方式将事件日志、告警信息、性能参数以及其他相关数据发送到数据采集引擎。

　　2、 通过远程登录方式采集：通过Telnet/SSH等方式，由数据采集引擎模拟登录到系统上获取事件日志、告警信息、性能参数以及其他相关数据。

　　3、 安装代理实现采集：在服务器上安装采集引擎代理程序，执行后台采集服务以及采集脚本，将目标系统上的事件日志、告警信息、性能参数以及各类事件数据收集后发送给数据采集引擎。

　　4、定时轮询采集：数据采集引擎通过ICMP、SNMP、ARP来获取监管对象的数据。

　　4.2 采集策略

　　数据采集引擎，支持灵活定义采集策略，包括如下：

　　1、数据采集引擎采用分布式部署方式。因为市电子政务网络具有城域网特点，应用电子政务网络的各个政务单位分布较为分散，为了保证数据的获取不受地理分布的限制，数据采集引擎采用分布式部署方式。

　　2、支持动态采集策略，因为每个数据采集引擎所面临的监控对象不同，因此数据的来源也会有所区别，平台可以为每个数据采集引擎配置不同的采集策略，使得每个数据采集引擎都可以较为针对的采集相适合的数据。

　　4.3 基础数据处理

　　监控预警平台是一个具有多数据源集成体系特点的平台，平台需要数据访问的透明性以及实现数据源的及时可用性，因此平台需要设计一个合理方案，以对来自不同数据源的各种数据进行表示，从而便于进行统一处理；其次则应考虑异构数据转换问题，将来自不同数据源的各种数据转换成集成系统能进一步处理的统一格式；另外还必须定义基本运算，进行信息数据的归并，从而能够有效完成数据查询、存取等具体功能。因此数据采集引擎在通过一定的协议或者文件方式采集到大量的原始数据后，会对数据进行如下的处理：

　　1、数据格式统一标准化，因为数据来源来自多种不同类型的设备和系统，数据采集方式也存在着较大的差异化，导致获取到的原始数据格式是多种多样的，因此数据采集层首先将原始数据按照平台规定的数据格式，进行统一标准化处理。

　　2、数据归并，针对海量的原始数据，数据采集层会按照安全事件的类型、安全事件发生的时间、安全事件的次数等条件对原始数据进行必须的归并。

　　3、数据压缩，当大量的数据在网络中传输时，势必会造成网络拥挤，影响正常的业务应用。为了保证网络传输的畅通，数据采集层对原始数据一定的压缩处理，再提交到数据传输接口。

　　4、数据传输，此为数据采集层向数据处理层提交数据的传输接口。

　　五、 数据处理层

　　数据采集引擎将标准化和归并后的安全告警数据、性能数据、配置数据、故障数据等信息提交给平台的核心数据处理系统后，核心数据处理系统能够有效识别各类数据，并将不同的数据分发给不同的数据处理子系统进行处理，防止同一数据被不同的数据处理子系统分别处理。

　　我们将原始数据分为三类：业务系统数据、网络数据和安全数据，因此数据处理平台设计了如下三个数据处理子系统：

　　1、业务系统数据处理子系统；

　　2、网络数据处理子系统；

　　3、安全数据处理子系统。

　　5.1 业务系统数据处理子系统

　　业务系统数据的来源，主要是：业务系统、日志服务器等。数据采集平台通过程序接口访问业务系统获取主要监测数据，提交给数据处理平台后，数据处理平台进行初步判断，检测为业务系统数据，会自动提交给业务系统数据处理子系统。在业务系统数据处理子系统中，我们又将数据进行了一定的分门别类，具体类别如下：

　　1、操作系统数据；

　　2、数据库系统数据；

　　3、中间件系统数据。

　　业务系统数据处理子系统定期自动向安全数据处理子系统输出数据。业务系统数据处理子系统在进行数据处理时，一旦检测到各种异常，就会生成特定安全事件，并随时输出到安全数据处理子系统，作为安全数据处理子系统的数据来源之一。

5.1.1 操作系统数据处理

　　业务系统数据处理子系统在获取到操作系统数据后，会根据不同操作系统的特性，对数据进行一定的处理。

　　平台所支持的操作系统类型，至少包括：Windows2000/2003服务器系统、Linux服务器系统、IBM AIX服务器系统、SUN Solaris服务器系统、HP UNIX服务器系统、Tru64服务器系统等。

　　操作系统数据处理的内容，如下表所示：

　　5.1.2 数据库系统数据处理

　　业务系统数据处理子系统在获取到数据库系统数据后，会根据不同的数据库系统特性，对数据进行一定的处理。

　　平台所支持的数据库系统类型，至少包括： DB2、Oracle、SQL Server、MYSQL等。

　　数据库系统数据处理内容，如下表所示：

序号	类别	描述
1	基本信息整理	数据库名称、数据路径、基本目录、数据库版本、字符集、配置的临时表大小、临时表目录、更新时间
2	数据表信息	表的名称、行的格式、行数、索引长度、表的类型、当前大小、扩展大小、表创建时间、表更新时间、更新时间等信息
3	缓存信息	创建的临时文件数目、创建的临时表数目、在查询缓存中的空闲内存块数量、查询缓存中空闲内存数量、查询缓冲的请求命中率、添加到插叙缓存中的查询数量、由于低内存而从查询缓存中删除的查询数量、注册在查询缓存中的查询请求数量、在插叙缓存中块的总数目、使用内存大小、打开表的数量、打开过的表的数量、表缓存配置数、更新时间等信息
4	线程信息	缓存中的线程数、为处理远程连接请求创建的线程总数、当前打开的连接数、处于非睡眠状态的线程数、更新时间等信息
5	锁信息	表的直接锁定次数、锁等待的次数、更新时间等信息
6	页和行锁信息	数据的页数量、脏页数目、缓冲池中页刷新请求数目、空闲页的数量、页缓存池的大小、页的大小、当前被等待的行锁的数量、共计消耗在获取行锁上的时间、为获取行锁平均等待时间、更新时间等信息
7	性能事件	在业务系统数据处理子系统检测到某个数据库系统的表空间使用率、连接数使用率等性能指标超过特定阀值时，会自动生成性能事件，随后提交给安全数据处理子系统。
8	故障事件	在业务系统数据处理子系统检测到某个数据库系统的实例未启动、连接服务未启动、数据库关闭、数据库归档日志已满、数据库连接数已满等异常时，自动生成故障事件，随后提交给安全数据处理子系统。

5.1.3 应用系统数据处理

　　业务系统数据处理子系统在获取到应用系统数据后，会根据不同的应用系统特性，对数据进行一定的处理。

　　平台能够支持应用系统类型，至少包括：IBM Websphere、Apache Tomcat、Microsoft IIS等。

　　应用系统数据处理的内容，如下表所示：

序号	类别	描述
1	基本信息整理	应用系统类型、应用系统版本信息、应用系统健康度，即统计24小时内应用系统的启用状态
2	会话动态信息	会话类型、会话名称、创建的会话数、失效的会话数、平均会话生存期、请求当前访问的会话总数、当前存活的会话总数、无法处理的新会话请求次数、被强制逐出高速缓存的会话对象数、从持久性存储读会话数据花费的时间、从持久性存储读取的会话数据大小、从持久性存储写会话数据花费的时间、写到持久性存储的会话数据大小、中断的 HTTP 会话亲缘关系数、前一个和当前访问时间戳记的时间之差、超时失效的会话数、不再存在的会话的请求数、会话级会话对象的平均大小、记录时间
3	进程池动态信息	名称、类型、高范围、低范围、当前、高水位、低水位、并发活动或池中线程状态、记录时间
4	JDBC连接池动态信息	名称、类型、创建连接的总数、已关闭的连接的总数、分配的连接的总数、返回到池的连接的总数、连接池的大小、池中的空闲连接数、等待连接的平均并发线程数、池中的连接超时数、正在使用的池的平均百分率、使用连接的平均时间、在允许连接之前的平均等待时间、因为高速缓存已满而废弃的语句数、记录时间
5	事务数动态信息	在服务器上开始的全局事务数、在服务器上已开始的本地事务数、并发活动的全局事务数、已落实的全局事务的个数、回滚的全局事务数、超时的全局事务数、超时的本地事务数、记录时间
6	事务的平均持续时间	平均时间、最小时间、最大时间、总大小、数量、总和、全局或本地状态、记录时间
7	JVM动态信息	高水位、低水位、当前、低范围、高范围、Java 虚拟机运行时中的空闲内存、Java 虚拟机运行时中使用的内存容量、Java 虚拟机已经运行的时间数、Java 虚拟机的 CPU 使用情况、记录时间
8	EJB动态信息	创建bean的次数、除去 bean 的次数、处于就绪状态的bean实例的个数、并发存活的bean的平均数、调用 bean 远程方法的次数、远程方法的平均响应时间、将对象返回到池的调用次数、由于池已满而放弃正在返回的对象的次数、池中对象的平均数、传递到 bean 的 onMessage 方法的消息数、处于钝化状态的 bean 的个数、处于就绪状态的 bean 实例的个数、记录时间
9	性能事件	在业务系统数据处理子系统检测到某个应用系统的会话数、JDBC连接数、事务数、事务的平均持续时间等性能指标超过特定阀值时，会自动生成性能事件，随后提交给安全数据处理子系统
10	故障事件	在业务系统数据处理子系统检测到某个应用系统的服务异常停止、业务系统不可用等异常时，自动生成故障事件，随后提交给安全数据处理子系统

　　5.2 网络数据处理子系统

　　网络数据的主要来源是：网络设备。数据采集层将原始数据提交给数据处理层后，数据处理层进行初步判断，检测为网络相关数据，会自动提交给网络数据处理子系统。

　　网络数据处理子系统定期自动向安全数据处理子系统输出数据。网络数据处理子系统在进行数据处理时，一旦检测到各种异常，就会生成特定安全事件，并随时输出到安全数据处理子系统，作为安全数据处理子系统的数据来源之一。

　　5.2.1 网络拓扑自动发现

　　该子系统提供详细的拓扑图元数据结构，并开放拓扑数据，提交给统一信息库，供展现层使用。

　　网络拓扑能够最为直观地反映整个网络连接状况。自动发现是系统拓扑中非常重要的一个功能，它能够自动识别设备类型，包括各种服务器类型、路由器、交换机、等等，以及它们之间的关系，并且自动将它们存储到公用对象库中对应的类中。网络管理人员通过图形管理界面能够直观的查询网络拓扑关系。

　　网络拓扑自动发现，有三种实现协议：包括ICMP、SNMP、CDP、其中ICMP主要用于发现网络的主机节点，其耗时较长，而SNMP和CDP主要是用来搜索网络内的路由器、交换机等网络设备。本方案会综合使用上述三种协议来自动发现和生成电子政务网络拓扑、监控预警平台自身的网络拓扑。

　　5.2.2 网络设备监控

　　数据采集平台通过SNMP数据采集方式，采集网络设备的MIB数据，实时监控网络设备的运行情况。

　　网络数据处理子系统在获取到网络数据后，会根据不同的网络设备特性，对数据进行一定的处理。网络设备类型至少能够支持：CISCO、华为、Juniper、Foundry等。

　　网络数据处理内容包括：

　　1、基本信息整理：网络接口数量，每个接口的IP地址/MAC地址等；

　　2、接口信息：接口索引、接口类型、接口描述、接口速率、工作状态、管理状态、接口总流量、入口流量、出口流量；

　　在网络数据处理子系统检测到某个网络设备的CPU使用率、内存使用率、接口流量等性能指标超过特定阀值时，会自动生成性能事件，随后提交给安全数据处理子系统。

　　在网络数据处理子系统检测到某个网络设备的设备停机、接口不通等异常时，自动生成故障事件，随后提交给安全数据处理子系统。

5.2.3 网络拓扑管理和监控

　　无论是自动生成的网络拓扑结构，还是手工绘制的网络拓扑结果，均可以进行手工编辑。

　　1、在拓扑图上添加、删除设备，添加、删除连线，修改设备的属性，移动网元位置等；

　　2、可对调整好的拓扑图进行导入、导出等操作。

　　3、可将多个网元和子网合并为一个图云网，也可选定局部区域显示成一个图云网，供展示层灵活展示使用。

　　4、具备网络导航功能，可以快速地定位到某个图云网。

　　5、网络拓扑图管理自动和网元设备监控关联，供展示层灵活展示使用。

　　5.2.3.1 虚拟网络拓扑管理和监控

　　该监控预警平台与重要信息系统的物理链路无法进行互联互通，因此重要信息系统的网络拓扑不能通过网络拓扑发现来自动生成，该平台提供了一定虚拟网络拓扑管理功能。

　　管理人员可以根据重要信息系统的实际网络拓扑结果，在平台上进行手工绘制。通过添加重要信息系统设备及其相关连线，修改设备属性，修改设备之间的连线，移动网元位置等操作，来完成重要信息系统在该平台上以一种虚拟网络拓扑形式进行管理。

　　5.2.3.2 政务外网网络拓扑管理和监控

　　根据政务外网汇聚节点的IP地址划分，自动生成政务外网的网络拓扑结构，并对政务外网网络拓扑进行管理和监控。

　　5.2.3.3 监控预警平台网络网络拓扑管理和监控

　　根据监控预警平台的IP地址划分，自动生成监控预警平台的网络拓扑结构，并对监控预警平台的网络拓扑进行管理和监控。

　　5.3 安全数据处理子系统

　　5.3.1 异常流量分析

　　异常流量分析模块通过FLOW、SNMP等方式，对系统网络流量信息或系统信息的进行提取、收集、整理、归类、分析，实时监控、检测系统网络中DOS/DDOS攻击、蠕虫病毒、僵尸网络及其他网络滥用事件，提取异常特征，并启动报警和响应系统进行阻断和防御。异常流量分析模块面向管理员提供流量分布、流量异常特征、攻击响应、应用层服务等各类网络运行状况的统计分析数据，从而有效帮助管理员更好地监控和掌握系统网络的使用情况。

　　5.3.1.1 异常流量分析的数据基础

　　异常流量分析模块依赖于Flow技术，并且广泛支持所有可能被利用的基础数据。除了NetFlow V1/V5/V7/V9、SFlow V4/V5、Cflowd V5/V8、NetStream V5/V8/V9之外，还支持SNMP、BGP、SPAN、CLI、NAP等方式，对路由设备状态、路由表项、动态路由协议交互、IP/MAC影射、MAC/Port影射、原始报文内容等进行实时采集，把链路流量图式和网元节点状态同时纳入到系统分析基础数据库中并在二者之间进行高度关联分析，不仅大幅度提高流量分析结果的准确率(如通过流量分析得出的“流量异常”表象往往有可能是由于网元设备错误策略配置等内在因素所诱发的)，而且通过对网元设备的主动分析/调节还可较精确的定位异常流量来源并有效缓解其影响。

　　5.3.1.2 基于基线的精确检测

　　异常流量分析模块支持固定基线和动态基线两种类型，其中固定基线可由管理员根据以往历史流量数据或应用业务已明确的流量特点进行人工定义，而动态基线则赋予此模块有效检测未知异常流量特征的能力。异常流量分析模块实现了多种网络流量趋势预测算法，能够通过对未知特征的网络流量进行一定周期的采样分析后，自动完成对该部分流量的图式建模和基线描述，并持续跟踪实际流量的变化曲率而对基线进行动态调整，从而保证了此模块对于网络流量演变趋势的自学习能力，能够有效避免随机杂波的偶发干扰、显著提高系统检测命中率。

　　5.3.1.3 细粒度的异常溯源定位

　　借助复合技术所带来的丰富的数据资源，异常流量分析模块可在异常检测命中之后，提供细粒度的溯源定位功能，从而为管理员采取后续的处理措施提供准确的位置信息。

　　异常流量分析模块可在两个层面中提供异常溯源定位：

　　网络层：在其监控的网络范围之内，能够将异常流量来源直接回溯至最接近攻击源的路由设备接口；

　　链路层：在其监控的网络范围之内，能够将异常流量来源直接定位于最接近攻击源的交换设备端口。

　　5.3.2 安全事件关联分析

　　关联分析，是指利用算法去判断一系列告警信息是否源于同一个攻击行为并完成攻击场景的重构。这种攻击行为具有单一的攻击意图，可以包括单个简单的攻击行为和由一系列攻击步骤组成的复杂的攻击行为，也被命名为攻击场景。其中关联分析是整个平台处理的核心，利用关联分析技术处理安全设备所产生的告警事件现在是安全管理研究中的一个热点问题。在实际网络环境下，攻击者在实施攻击的过程中，其扫描行为、口令试探行为、访问文件行为、会话、流量往往会在不同的安全工具上留下相应的特征。关联分析正是要依靠下辖的IDS节点、防病毒网关、网络行为审计、防火墙等安全设备提供的这些安全特征信息来对网络安全全局状况作出判断。

　　目前关联分析的方法有很多，典型的包括基于统计的关联分析、基于规则的关联分析、基于监控对象的关联分析等。

　　5.3.2.1 基于规则的关联分析

　　基于规则的关联分析（Rule-based Correlation，RC），是将可疑的活动场景（暗示某潜在安全攻击行为的一系列安全事件序列）加以预先定义，系统能够根椐定义的关联性规则表达式，对收集到的事件进行检查，确定该事件是否和特定的规则匹配。

　　1、 针对典型的安全活动场景预先定义关联规则，如DDOS攻击、缓冲区溢出攻击、网络蠕虫、邮件病毒、垃圾邮件、电子欺骗、非授权访问、企图入侵行为、木马、非法扫描、可疑URL等。

　　2、 可根据事件发生的因果关系，进行逻辑上关联分析。

　　3、 根据安全事件发生前后，受攻击系统各个性能监控参数的变化幅度情况。

　　4、 可根据网络的动态情况自适应过滤相关度较低的事件。

　　5、 提供向导式创建关联性规则功能。

　　6、 关联性规则应具有良好的移植性，可以按照特定的文件格式如XML进行导入和导出。

　　5.3.2.2 基于统计的关联分析

　　参照国家相关标准，定义安全事件类别，对每个类别的事件设定一个合理的阀值，将出现的事件先归类，然后进行缓存和计数，当在某一段时间内，计数达到该阀值，可以产生一个级别更高的安全事件。

　　5.3.3 安全事件处理流程

　　安全事件处理模块是整个监控预警平台的应急响应模块。

　　5.3.3.1 定义事件处理流程

　　根据安全事件的不同性质和级别、各监控对象的不同特点，定义相应的事件处理流程。

　5.3.3.2 工单的来源

　　1、 安全数据处理子系统经过对安全数据的分析后，生成的安全事件；

　　2、 业务系统数据处理子系统生成的性能事件和故障事件；

　　3、 网络数据处理子系统生成的性能事件和故障事件；

　　5.3.3.3 与知识库系统关联

　　安全事件处理与知识库关联。

　　1、安全监控人员在准备处理工单之前，可以根据内容的关键字信息到知识库系统中查询符合该事件类型的相关内容，包括：事件原因分析、事件处理步骤、事件总结等，获得相应的处理经验。

　　2、安全监控人员在处理完毕工单后，可以将与此工单相关的详细内容，如：事件原因分析、事件处理步骤、事件总结等生成相关案例，保存到知识库中，为其他人处理类似事件提供经验共享。

　　5.3.3.4 工单执行和监控流程

　　当平台发现有真实安全事件时，根据预先制定的工单处理流程，平台会自动生成安全事件处理工单，此时不需要人工干预，系统自动调用服务程序通过声音、图形、短信、邮件、代理程序等方式及时通知负责处理此安全事件工单的监控人员。此时也启动安全事件进入其相应的处理流程。

　　工单的执行和监控流程具有下列特征：

　　1、工单具有一定的时限性，必须在规定的时限内处理完毕，如果在规定的时间内未被及时处理，系统会自动修改工单状态，并自动向相关人员发送超时通知；

　　2、当某个工单不能被此工单相关的监控人员正确处理时（因为技术人员水平或者时间的原因），可提前终止对工单的处理，并说明终止工单的原因。安全监督人员负责核实终止原因，同时将工单重新派发给其他监控人员，以充分保证工单能够被正常处理；

　　3、安全监督人员可随时监督工单生成进程和处理进程，如：系统目前有多少待处理的工单，有多少正在处理中，多少已经处理完毕。

　　4、系统自动记录每个工单从生成，到接受处理，到处理完毕，以及处理确认的全部过程，此记录过程成为考核监控人员的依据。

　　5.3.4 风险管理

　　5.3.4.1 风险计算

　　风险管理以监控对象为基础，通过获取统一信息库中监控对象的配置数据，对监控对象价值、安全威胁因素关联后计算监控对象的风险值，并对监控对象的风险实现动态的监控。

　　假设风险计算公式（可根椐实际情况进行调整）为：

　　风险值＝f（监控对象价值，威胁可能性）；

　　通过风险分析得到的风险状况为一个数字，不同的取值范围决定了不同的风险级别，风险级别划分为五个等级：

　　为确保安全风险管理符合监控预警平台的监控深度以及相关要求，可根据实际现状和监控对象提出详细的风险计算方式，并能够在后续的实施过程中进行重新设计和二次改造。

　　5.3.4.2 风险的动态监控

　　1、 当安全事件更新后，对应的监控对象的风险被更新。

　　2、 当故障事件更新后，对应的监控对象的风险被更新。

　　3、 当故障事件更新后，对应的监控对象的风险被更新。

　　4、 当监控对象发生某些可能对风险有影响的变化后，对应的监控对象的风险被更新。