论文部分内容阅读
摘 要：在研究方法中，设计了基于业务的安全风险评估架构模型，该模型主要包含四部分内容：业务风险分析方法模型、业务系统梳理、安全需求析取及安全评估。研究方法阐述了业务安全风险分析借鉴的主要模型;安全需求分析，从合规性要求、业务自身安全要求和风险控制要求三方面定义了安全需求，主要用来分析业务的脆弱性，同时通过CIA属性（保密性、完整性、可用性）制定每个场景特定的安全指标;最后通过STRIDE威胁建模分析，并借鉴OCTAVE风险分析模型（从组织角度出发），从资产（把业务作为资产）、脆弱性、威胁三方面并考虑已有安全措施进行综合的定性风险分析。
关键词：业务安全;EA;IDEF0
中图分类号：U416.26 文献标识码：A
一、引言。
国外尤其是欧美在信息安全风险评估领域起步较旱，到目前为约有30年的发展历史，各发达国各自形成一套较为完整的标准体系、技术体系、组织架构和业务体系，同时都拥有自己的评估认证体系。风险评估模型往往与被评估领域紧密结合，逐步开发出了适用于不同领域企业或组织的风险评估的模型和风险评估方法，通过定性分析和定量分析，风险评估的过程逐渐转向自动化和标准化，已开发出了各种风险评估工具，这些工具不仅有效提高了评估效率，同时还极大消除了评估的主观性，使风险评估更加能体现真实情况。国内对风险评估的研究刚走过起步阶段进入发展阶段，也已有了自己的标准体系和技术体系，已形成一套较完整的成熟的风险评估体系，但总体上在实际的风险评估中，主观性和随意性较大的问题还有待改进。当前信息安全风险评估方法主要有如下几种：1）基于威胁分析的传统风险评估方法。提出了两种不同量化万式：绝对量化和相对量化。由于信息系统中威脅的多样性，因此基于威胁的风险评估非常依赖于评估者对系统威胁的认识和了解，评估者的经验显得尤其重要。绝对量化方式可操作性差，相对量化方式过于依赖评估者的经验，这种评估方法不适告大型的信息系统，评估可操作性不强。2）层次化威胁量化评估方法。从上到下卦为网络、系统、主机、应用4个层次，采取"自下而上、先局部后整体"的评估策略。这样的分析方法是基于网络入侵检测传感器报警日志和网络带宽占用率，但这些信息还不能全面反映黑客的攻击行为，诸如获取系统权限后执行的命令操作。3）故障树分析方法 （Fau lt An al ysis Tree-FAT）。主要是对各个风险要素的逻辅关系定性分析，同时依据该逻辑关系建立故障树。定量的部分主要是对故障树中各层要的风险产生概率加以计算。
总体上，目前风险评估的几种模型各有优缺点，有时需要结合使用，但相应的成本会增加。
二、基于业务的安全风险评估框架。
业务安全评估的意义：在信息技术高速发展的今天，信息系统在各行各业逐步深入和普及。伴随着政府部门、金融机构、企事业单位、商业组织等对信息系统依赖程度的日益增强，信息安全问题受到普遍关注。运用风险评估去识别安全风险，解决信息安全问题得到了广泛的认识和应用。
目前风险评估的主要方式是对信息系统进行全面的、系统的评估，评估对象包括信息系统所有组成部分：硬件系统（计算机硬件系统和网络硬件系统）、系统软件（计算机系统软件和网络系统软件）和应用软件（包括由其处理、存储的信息）。但根据Gartner 的数据显示，75% 的黑客攻击发生在应用层，而来自 NIST 的数据更为惊人，有 92% 被发现的漏洞属于应用层，也就是操作系统和应用（Applications），这里的应用可理解为业务系统及其提供的服务。参见图1可以看到，操作系统的攻击（紫色部分）只有15%，那么剩下77%都是对业务的攻击，业务成为了受攻击的重灾区。
另外，随着越来越多的对国家社会、经济有着重要影响的行业将传统的业务由线下搬到线上，出于对业务安全保障的迫切需求，它们对于信息系统安全评估需求有以系统安全需求为导向向以业务风险为导向转移的趋势。正因于此，一种更具针对性的、以业务为中心的、面向业务及其承载系统的一种评估方法正在逐步发展起来，本文称其为基于业务的安全评估方法。
业务风险评估框架模型：
基于业务安全风险评估，目前在业界没有相关的成熟标准可依。本项目结合广东电网业务系统的现状，在业务安全评估方面首次采用了一些比较创新的方法论及模型具体如下图所示：基于业务流的信息系统联动的风险评估模型，不同于传统的以资产为单元的风险评估模型，而是将各业务系统直接对应评估对象。
上图显示了业务流程、业务节点、信息资产、脆弱性、威胁等之间的关系：
一个业务流程可以由若干个独立的业务节点组成;
一个业务节点可能（同时或不同时）处理若干个重要的信息资产;
一个业务节点可能存在着若干个脆弱性;
威胁可能利用一个或多个脆弱性突破业务节点的安全;
一旦威胁突破了业务节点，所有通过该业务节点的信息资产将会受到危害。
由业务节点的脆弱性所形成的风险，也会使信息资产处于相同的威胁之中。基于业务流的信息系统联动的风险评估方法，将资产（业务节点）的风险提升为基于业务流程的安全风险。通过业务流程的关联，将资产造成的影响组合起来，揭示出影响信息系统整体安全的更深层次的原因。
业务风险评估架构主要包含四部分内容：业务风险分析方法模型、业务系统梳理、安全需求析取及安全评估。
方法模型阐述了业务安全风险分析借鉴的主要模型，它并不能取代传统风险评估，而是从具体的业务出发，专注于应用层、数据层的安全风险。在业务系统梳理方法方面借鉴了EA及IDFE0等国外先进模型;安全需求分析，从合规性要求、业务自身安全要求和风险控制要求三方面定义了安全需求，主要用来分析业务的脆弱性;最后通过STRIDE威胁建模分析，并借鉴OCTAVE风险分析模型（从组织角度出发），从资产（把业务作为资产）、脆弱性、威胁三方面并考虑已有安全措施进行综合的定性风险分析。 业务系统梳理方面主要以业务过程为出发点梳理出相应的人员参与哪些业务活动，在业务活动过程中会产生哪些类型的数据。整个活动会落到哪些应用组件上，并需要哪些基础设施来支撑。
安全需求分析方面包含了合规性安全需求析取、业务自身安全需求析取及风险控制安全需求析取。合规性安全需求主要从国家层面、行业层面及公司层面进行归纳汇总;业务自身安全需求主要从业务逻辑、业务权限、日常安全时间运维记录及数据安全等方面进行归纳汇总;风险控制安全需求主要从业务系统面临的威胁来源进行归纳汇总。
业务梳理方法
任何能够确实保障应用系统信息安全的体系必须要满足应用系统业务的安全要求，因此完整、透彻地了解业务的安全要求是建立有效的信息安全保障体系的基础。这样就需要通过系统化和工程化的手段来析取、分析和归纳应用系统业务中的信息安全需求。为此，在本项目中采用了业界的一些有效方法来保证业务安全需求分析的质量，这些方法概要介绍如下：
EA模型（Enterprise Architecture Model）是从企业整体业务出发来规划、建立和管理企业信息技术体系的方法论。EA模型是一个层次结构模型，每个层次涉及到了资产、过程、人员、时间、位置等要素。由于本项目主要目的是通过业务驱动产生业务安全要求，并将这些要求映射到技术层面，故仅仅采用了EA模型的基本思路，而不去构造一个完整的EA。在本项目中采用的EA模型框架如下图所示：
其中“业务层”为业务的描述，业务的描述包括对整体范围的定义和对业务过程的刻画;“信息层”包括了业务过程中的关键性输入、输出和控制数据，这些数据是支撑业务的信息资产;“应用层”包括支持业务的软件应用系统，这些应用系统通过对业务数据的创建、加工、管理来支持业务过程、维护业务信息资产;“基础设施层”包括了支持软件应用系统通信的设施和信息处理的硬件与软件平台。
IDEF0，根据前面的介绍，有效的信息安全保障体系建设要从业务入手，但要做到业务驱动的信息安全保障需要更进一步刻画具体的业务过程（即业务过程建模）。在本项目中采用简易并广泛使用的功能描述图形工具IDEF0来建立业务过程模型。IDEF0采用下图所示的模型来进行业务功能定义：
上图中各个元素含义和在本项目的应用说明如下：“活动”是过程中将输入加工成输出的功能，加工过程通过“机制”（如人员、应用系统）来完成但受到“控制”约束。一个业务过程会包含多个活动，每个“活动”还可进一步分解为子活动，子活动的表示方法与活动相同。“输入”、“输出”是人员在“活动”过程中产生的一些产出物，如“数据信息”等。同样，传统的IDEF0模型用于业务过程定义或重组。而在本项目中，IDEF0的目的是用于析取业务过程的信息安全需求（通过EA模型的映射），因此在很多情况下无需像传统模型那样分解到详细的底层活动。
EA架构映射
为了有效地梳理业务和资产并进一步地进行风险评估，需要系统化、按层次的建立起资产与业务过程的关联。业务过程分析参考如下模型，对有关的业务、数据、应用和资产进行关联，为每个业务构建业务过程手册，为进一步进行风险控制需求分析打下基础。
在本项目中IDEF0活动与EA四层架构四层关系如下，“输入”、“输出”和“控制”将映射到EA模型的信息层。“机制”包含了三类，即实施活动的人员、完成活动的应用软件系统和支持应用软件系统运行的基础设施，其中人员部分属于业务层，应用软件系统部分映射到应用层，基础设施部分映射到基础设施层。
业务安全需求分析：针对业务层的每个活动，了解利益相关者的安全期望，明确组织的业务安全要求。这些安全要求分为四个方面，機密性（Confidentiality）、完整性（Integrality）、可用性（Availability）、抗抵赖（Non-Rupudiation）和可回溯（Dating-back）。根据各业务特点，识别其综合安全要求;之后，确定业务层影响该要求的业务活动;最后，根据业务EA架构图中，各资产的对应关系，将该安全要求落实到以确定业务活动所对应的信息资产、应用资产和基础设施资产上。需注意的是，不是每个要求都能严格的落实在每层中，也有些要求可能在个别层没有对应的要求需要落实。
业务流细化分析流程
分析业务系统数据流是整个业务数据流分析过程中最重要的环节，通过业务流程分析最终输出系统数据流程图。
分析业务数据流的步骤如下：
第一步：获取业务系统网络拓扑结构，并进行核实，从而获得系统的应用场景;
第二步：通过人员访谈、系统文档调研的方法采集业务数据流的关键数据，包括业务之间的互访关系可能存在的威胁以及数据流走向;
第三步：数据包分析，通过对特定系统的数据包抓取获得真实的数据网络访问路径，发现通过人工访谈和文档分析不能全面了解的访问路径（注：该项工作的数据采集量可能较大，需要分析大量数据，不能了解系统服务器的真实端口开放情况）;
第四步：主机网络状态审计，通过系统服务开放情况获取主机网络连接状态;
第五步：分解业务系统，将业务系统按照功能模块分解成更小的业务单位，了解各业务单元之间的相互访问关系，以便从单个功能的角度去识别脆弱性和威胁。
第六步：脆弱性分析，针对每一个需要保护的资产，识别可能被威胁利用的弱点，并对脆弱性的严重程度进行评估。脆弱性的识别的数据主要来自资产的所有者、使用者以及相关业务领域的专家和软硬件方面的专业人士。在此基础上，进行威胁路径分析，分析业务系统体系结构中潜在的安全漏洞结合攻击者的目标，通过业务数据流示意图来识别所有可能影响目标的威胁路径。 第七步：风险综合分析，结合系统的脆弱性和威胁路径进行综合的风险分析，对威胁发生的可能性进行评估，将威胁带来的风险与攻击者的成本进行比较，进而采取相应的措施。
第八步：给出安全建议，对于分析得出的风险，给出整改建议并输出相应的评估报告。
安全需求（脆弱性）分析方法说明
安全控制体系构建途径：系统安全控制体系构建经过三个步骤：1、信息安全需求定义;2、信息安全控制目标确立;3、信息安全管控体系设计和实现。通过系统化管控过程，对安全管控体系构建和运行过程进行管理和控制。下面对上述三个步骤的主要工作内容进行概要描述：
信息安全需求定义：系统信息安全需求来源于三个方面：法规依从性要求、业务安全需要和风险管控要求。综合三方面安全需求，对系统安全需求进行定义，作为信息安全目标确立以及安全管控体系设计的依据;
信息安全控制目标确立：基于系统安全需求定义，确定安全控制目标。考虑系统现有安全措施，组织风险接受程度、安全项目建设规划等因素，对需求定义中确定的安全需求进行归类合并，分解成多个可实现的安全控制目标。这些控制目标将成为系统安全策略和安全控制制定和构建依据与基础。
信息安全控制体系设计和实现：第一步是明确安全政策，信息安全政策是约束主体对信息客体行为的准则，是为了达到一定的信息安全管控目标而制定的，安全政策是安全建设的基础要素。第二步具体制定系统安全管理制度、落实系统安全责任体系、落地系统技术控制措施、建立系统安全过程。
安全管控是动态的持续性过程，体系运行过程中，随时面临安全风险，通过持续性监控确保安全管控体系持续运行，实现信息安全的闭环管理。
系统安全需求定义方法
根据系统信息安全管控体系建设过程，信息安全的需求来源于三个方面，即合规性要求、业务要求和风险控制要求。
一是法规依从安全要求，组织具有社会性，参与各种社会活动，负有社会责任，行为受到各种社会规则的约束，这些约束来自国家、行业、商业活动以及企业内部要求四方面。
国家层面：作为重要国企之一，信息化建设必须符合国家法律、法规、政策、标准，不能对国家、社会、其他组织和个人造成不良影响和伤害。
行业层面：作为国家重点监管的企业，其各种行为包括信息化、信息安全建设必须符合行业主管（即国务院国有资产监督管理委员会，简称国资委）制定的政策、规范和标准。
商业协议约束：作为企业，参与各种商业活动，需遵守商业活动涉及的标准、协议要求。系统作为商业活动经常使用的信息传输工具，必须符合相关约定。
企业内部：是一体积庞大的国有企业，为保证内部信息化以及信息安全建设的规范化、持续化发展，制定的有关管理办法、规范和标准，适用于所有的分项信息化建设。因此，系统安全建设必须符合相关文件的要求。
上述四方面的要求大部分以文件发布的方式明确各自的要求。系统安全建设之初，需对此类文件进行收集，对相关条款进行解读，确定适用条款。其中，法律、法规、行业规范以及商业合同约束等为强制性合规条款;建设标准、指南属于参考性条款。
二是业务安全要求，业务自身安全需求在安全开发体系中侧重EA架构中的业务层和信息层，主要来源于业务系统梳理后所涉及的业务逻辑安全、业务权限、数据生命周期安全及针对业务系统日常运维安全事件记录等进行汇总。业务自身安全需求需根据业务系统业务功能的变化及日常发生的业务安全运维事件记录不断更新。
三是风险控制安全需求，通过信息化手段实现业务，就不可避免的面临信息有关的安全风险。电子业务面临的风险分为两类：系统风险和系统应用风险。
系统自身风险：是由于系统自身的控制措施不足导致系统自身重要信息资产和基础设施面临被攻击或破坏的的风险。面临风险的主体是系统本身，其安全需求集中在如何保证系统自身的安全。可采用行业内信息系统风险评估方法，发现系统的技术风险和管理风险。
系统应用风险：系统是员工进行内部、外部沟通的主要信息传输工具，是最大的暴露面之一。恶意份子借助系统，可能渗透到企业内XX用户，并以此做为跳板攻击企业网内部，或窃取内部敏感信息;内部员工，可能通过系统发送违法信息或窃取内部敏感信息;系统本身也可能被利用，例如被攻击成为垃圾XX的制造和发送者。这些风险不会影响业务的正常使用，但是會对其他系统或信息造成安全隐患。
本方法强调在进行安全需求分析时，要全面考虑这三个来源。上述三个方面的安全要求，没有明确的界限，会出现交叉现象。三者关系如下图所示：
四是法规依从性安全需求，法规依从性安全需求主要按照广东电网公司信息安全管理办法要求进行整理归类，该管理办法主要是参照国家等保标准并结合电力行业特点和广东电网自身实际情况制定，融合了技术管理两方面，具有很强的针对性，我们将尽量选取跟业务有较强的直接或间接关联的要求提取相应的风险控制点（指标），详细控制点参见方法论报告附件。
五是业务自身安全需求，业务自身安全需求是通过业务梳理分析而得到，具体来说是识别业务活动、识别业务数据、识别跟安全相关的业务规则，然后用经典的CIA（保密性、完整性、可信性）针对EA架构中的业务层、信息层、应用层、基础设施层（侧重业务层和信息层）分别进行分析，从而得到响应的控制点（重点是业务逻辑安全、业务权限、数据生命周期安全）。详细控制点参见方法论报告附件中的实例。
六是风险控制安全需求，针对业务场景采用微软STRIDE威胁模型，STRIDE威胁分类法是从攻击者的角度考虑威胁，围绕外部实体、处理、数据存储、数据流四个方面从如下六个角度分别进行分析：伪冒（Spoofing），伪冒威胁是指恶意方伪装成某人或某对象，如钓鱼站点伪冒真实的网银服务器，对用户发起钓鱼攻击。篡改（Tampering），篡改威胁包含对于数据以及代码的各种恶意修改。如恶意攻击者在链路层上修改用户转账的转账对象账号，窃取用户资金。抵赖（Repudiation），抵赖威胁是指用户或入侵者拒绝承认一个已执行的无法证实的行为，如用户否认进行交易。信息泄露（Information Disclosure），信息泄露是指将敏感信息泄露给那些未经授权获得访问的个体，如本地临时信息未及时清理造成的敏感信息泄露。拒绝服务（Denial of Service），拒绝服务（DoS）攻击通过使得服务暂时不可用或瘫痪，从而破坏系统的可用性。如针对网银服务器的拒绝服务攻击。权限提升（Elevation of Privilege），权限提升（EoP）通常发生在用户获得更高的能力场景之下，比如匿名用户利用系统的某个漏洞获得认证用户才能具有的权限。 在业务安全评估过程中，基于业务场景进行风险控制安全需求分析借助stride威胁模型能帮助理解系统中的潜在的安全威胁，明确风险并建立相应消减机制。对于业务系统安全测评来说，在测评准备阶段，通过威胁建模理解系统可能面临的安全威胁，掌握威胁可能利用的脆弱点位置，使得测评人员在现场测试阶段能有目的的按照预定的脆弱点位置查找漏洞和隐患，并帮助渗透测试人员快速有效寻找攻击路径，使测试工作更能贴合信息系统的安全风险场景。
不同信息系统由于其各自业务使命的不同，其威胁模型不同。随着信息系统运行环境的变化（例如最新的攻击技术，内外网应用转换等），其威胁模型也会变化。不同人员其对系统安全风险的理解不同，所建立的威胁模型也有差别。
这里需说明两点：1、风险控制安全需求实际上是业务安全需求导出的辅助（得到某业务场景潜在的安全威胁），本省并不能导出控制点。2、能达成检查对象的落地。从外部实体、处理、数据存储、数据流四个方面着手，通过EA架构映射到具体的基础实施，得到某个业务流程应该检查的实际对象。
业务影响分析
业务影响分析（Business Impact Analysis），也称业务影响评估（Business Impact Assessment），分析了干扰性风险对组织运营的影响方式，同时识别并量化了必要的风险管理能力。具体来说，BIA就以下问题达成了一致的认识：
关键经营过程的识别和临界状态、职能和相关资源以及组织已有的关键互相依存关系;
干扰性事项对实现重要经营目标的能力会产生怎样的影响;
管理干扰的影响以及使组织恢复到约定运行水平所需的能力。
业务影响分析（BIA）和风险评估通常是两个独立的流程，但它们必须同时或并行执行。其原因是，对没有进行风险评估的业务进行的评估影响不能提供全面的信息。我们可以认为影响是不会改变的。如果一个关键系统的中断对业务具有较高的影响（财务的或其他的），那么无论我们做什么，实际中断所造成的影响仍然很高。我们无法改变影响，我们只能尽量避免运行中断。
BIA的主要作用是：
对关键过程的认识，使组织有能力继续实现其既定目标;
对资源的认识;
有机会重新界定组织的运行过程，以增強组织的灵活性。
结合业务风险评估的具体的业务影响分析框架图如下：
三、结语。
国内外大量文献对基于业务的安全评估方法进行了研究，提出了很多有用的方案和算法。但是对业务安全的专项研究比较少，由于业务安全是一种新兴的技术，目前的应用还主要在实验阶段，研究存在一定的局限性，未来可以尝试通过模拟仿真等方法对该机制进行更进一步的论证，并尝试推广到其他应用场景。
参考文献：
[1]《国家信息化领导小组关于加强信息安全保障工作的意见》（中办发[2003]27号）.
[2]《中华人民共和国计算机信息系统安全保护条例》（国务院147号令）.
[3]《信息安全等级保护管理办法》（公通字[2007]43号）.
[4]《GB/T 18336-2008信息技术 安全技术 信息技术安全性评估准则》.
[5]《GB/T 22239-2019 信息系统安全等级保护基本要求》.
[6]《GB/T 20984-2007 信息安全技术信息安全风险评估规范》.
关键词：业务安全;EA;IDEF0
中图分类号：U416.26 文献标识码：A
一、引言。
国外尤其是欧美在信息安全风险评估领域起步较旱，到目前为约有30年的发展历史，各发达国各自形成一套较为完整的标准体系、技术体系、组织架构和业务体系，同时都拥有自己的评估认证体系。风险评估模型往往与被评估领域紧密结合，逐步开发出了适用于不同领域企业或组织的风险评估的模型和风险评估方法，通过定性分析和定量分析，风险评估的过程逐渐转向自动化和标准化，已开发出了各种风险评估工具，这些工具不仅有效提高了评估效率，同时还极大消除了评估的主观性，使风险评估更加能体现真实情况。国内对风险评估的研究刚走过起步阶段进入发展阶段，也已有了自己的标准体系和技术体系，已形成一套较完整的成熟的风险评估体系，但总体上在实际的风险评估中，主观性和随意性较大的问题还有待改进。当前信息安全风险评估方法主要有如下几种：1）基于威胁分析的传统风险评估方法。提出了两种不同量化万式：绝对量化和相对量化。由于信息系统中威脅的多样性，因此基于威胁的风险评估非常依赖于评估者对系统威胁的认识和了解，评估者的经验显得尤其重要。绝对量化方式可操作性差，相对量化方式过于依赖评估者的经验，这种评估方法不适告大型的信息系统，评估可操作性不强。2）层次化威胁量化评估方法。从上到下卦为网络、系统、主机、应用4个层次，采取"自下而上、先局部后整体"的评估策略。这样的分析方法是基于网络入侵检测传感器报警日志和网络带宽占用率，但这些信息还不能全面反映黑客的攻击行为，诸如获取系统权限后执行的命令操作。3）故障树分析方法 （Fau lt An al ysis Tree-FAT）。主要是对各个风险要素的逻辅关系定性分析，同时依据该逻辑关系建立故障树。定量的部分主要是对故障树中各层要的风险产生概率加以计算。
总体上，目前风险评估的几种模型各有优缺点，有时需要结合使用，但相应的成本会增加。
二、基于业务的安全风险评估框架。
业务安全评估的意义：在信息技术高速发展的今天，信息系统在各行各业逐步深入和普及。伴随着政府部门、金融机构、企事业单位、商业组织等对信息系统依赖程度的日益增强，信息安全问题受到普遍关注。运用风险评估去识别安全风险，解决信息安全问题得到了广泛的认识和应用。
目前风险评估的主要方式是对信息系统进行全面的、系统的评估，评估对象包括信息系统所有组成部分：硬件系统（计算机硬件系统和网络硬件系统）、系统软件（计算机系统软件和网络系统软件）和应用软件（包括由其处理、存储的信息）。但根据Gartner 的数据显示，75% 的黑客攻击发生在应用层，而来自 NIST 的数据更为惊人，有 92% 被发现的漏洞属于应用层，也就是操作系统和应用（Applications），这里的应用可理解为业务系统及其提供的服务。参见图1可以看到，操作系统的攻击（紫色部分）只有15%，那么剩下77%都是对业务的攻击，业务成为了受攻击的重灾区。
另外，随着越来越多的对国家社会、经济有着重要影响的行业将传统的业务由线下搬到线上，出于对业务安全保障的迫切需求，它们对于信息系统安全评估需求有以系统安全需求为导向向以业务风险为导向转移的趋势。正因于此，一种更具针对性的、以业务为中心的、面向业务及其承载系统的一种评估方法正在逐步发展起来，本文称其为基于业务的安全评估方法。
业务风险评估框架模型：
基于业务安全风险评估，目前在业界没有相关的成熟标准可依。本项目结合广东电网业务系统的现状，在业务安全评估方面首次采用了一些比较创新的方法论及模型具体如下图所示：基于业务流的信息系统联动的风险评估模型，不同于传统的以资产为单元的风险评估模型，而是将各业务系统直接对应评估对象。
上图显示了业务流程、业务节点、信息资产、脆弱性、威胁等之间的关系：
一个业务流程可以由若干个独立的业务节点组成;
一个业务节点可能（同时或不同时）处理若干个重要的信息资产;
一个业务节点可能存在着若干个脆弱性;
威胁可能利用一个或多个脆弱性突破业务节点的安全;
一旦威胁突破了业务节点，所有通过该业务节点的信息资产将会受到危害。
由业务节点的脆弱性所形成的风险，也会使信息资产处于相同的威胁之中。基于业务流的信息系统联动的风险评估方法，将资产（业务节点）的风险提升为基于业务流程的安全风险。通过业务流程的关联，将资产造成的影响组合起来，揭示出影响信息系统整体安全的更深层次的原因。
业务风险评估架构主要包含四部分内容：业务风险分析方法模型、业务系统梳理、安全需求析取及安全评估。
方法模型阐述了业务安全风险分析借鉴的主要模型，它并不能取代传统风险评估，而是从具体的业务出发，专注于应用层、数据层的安全风险。在业务系统梳理方法方面借鉴了EA及IDFE0等国外先进模型;安全需求分析，从合规性要求、业务自身安全要求和风险控制要求三方面定义了安全需求，主要用来分析业务的脆弱性;最后通过STRIDE威胁建模分析，并借鉴OCTAVE风险分析模型（从组织角度出发），从资产（把业务作为资产）、脆弱性、威胁三方面并考虑已有安全措施进行综合的定性风险分析。 业务系统梳理方面主要以业务过程为出发点梳理出相应的人员参与哪些业务活动，在业务活动过程中会产生哪些类型的数据。整个活动会落到哪些应用组件上，并需要哪些基础设施来支撑。
安全需求分析方面包含了合规性安全需求析取、业务自身安全需求析取及风险控制安全需求析取。合规性安全需求主要从国家层面、行业层面及公司层面进行归纳汇总;业务自身安全需求主要从业务逻辑、业务权限、日常安全时间运维记录及数据安全等方面进行归纳汇总;风险控制安全需求主要从业务系统面临的威胁来源进行归纳汇总。
业务梳理方法
任何能够确实保障应用系统信息安全的体系必须要满足应用系统业务的安全要求，因此完整、透彻地了解业务的安全要求是建立有效的信息安全保障体系的基础。这样就需要通过系统化和工程化的手段来析取、分析和归纳应用系统业务中的信息安全需求。为此，在本项目中采用了业界的一些有效方法来保证业务安全需求分析的质量，这些方法概要介绍如下：
EA模型（Enterprise Architecture Model）是从企业整体业务出发来规划、建立和管理企业信息技术体系的方法论。EA模型是一个层次结构模型，每个层次涉及到了资产、过程、人员、时间、位置等要素。由于本项目主要目的是通过业务驱动产生业务安全要求，并将这些要求映射到技术层面，故仅仅采用了EA模型的基本思路，而不去构造一个完整的EA。在本项目中采用的EA模型框架如下图所示：
其中“业务层”为业务的描述，业务的描述包括对整体范围的定义和对业务过程的刻画;“信息层”包括了业务过程中的关键性输入、输出和控制数据，这些数据是支撑业务的信息资产;“应用层”包括支持业务的软件应用系统，这些应用系统通过对业务数据的创建、加工、管理来支持业务过程、维护业务信息资产;“基础设施层”包括了支持软件应用系统通信的设施和信息处理的硬件与软件平台。
IDEF0，根据前面的介绍，有效的信息安全保障体系建设要从业务入手，但要做到业务驱动的信息安全保障需要更进一步刻画具体的业务过程（即业务过程建模）。在本项目中采用简易并广泛使用的功能描述图形工具IDEF0来建立业务过程模型。IDEF0采用下图所示的模型来进行业务功能定义：
上图中各个元素含义和在本项目的应用说明如下：“活动”是过程中将输入加工成输出的功能，加工过程通过“机制”（如人员、应用系统）来完成但受到“控制”约束。一个业务过程会包含多个活动，每个“活动”还可进一步分解为子活动，子活动的表示方法与活动相同。“输入”、“输出”是人员在“活动”过程中产生的一些产出物，如“数据信息”等。同样，传统的IDEF0模型用于业务过程定义或重组。而在本项目中，IDEF0的目的是用于析取业务过程的信息安全需求（通过EA模型的映射），因此在很多情况下无需像传统模型那样分解到详细的底层活动。
EA架构映射
为了有效地梳理业务和资产并进一步地进行风险评估，需要系统化、按层次的建立起资产与业务过程的关联。业务过程分析参考如下模型，对有关的业务、数据、应用和资产进行关联，为每个业务构建业务过程手册，为进一步进行风险控制需求分析打下基础。
在本项目中IDEF0活动与EA四层架构四层关系如下，“输入”、“输出”和“控制”将映射到EA模型的信息层。“机制”包含了三类，即实施活动的人员、完成活动的应用软件系统和支持应用软件系统运行的基础设施，其中人员部分属于业务层，应用软件系统部分映射到应用层，基础设施部分映射到基础设施层。
业务安全需求分析：针对业务层的每个活动，了解利益相关者的安全期望，明确组织的业务安全要求。这些安全要求分为四个方面，機密性（Confidentiality）、完整性（Integrality）、可用性（Availability）、抗抵赖（Non-Rupudiation）和可回溯（Dating-back）。根据各业务特点，识别其综合安全要求;之后，确定业务层影响该要求的业务活动;最后，根据业务EA架构图中，各资产的对应关系，将该安全要求落实到以确定业务活动所对应的信息资产、应用资产和基础设施资产上。需注意的是，不是每个要求都能严格的落实在每层中，也有些要求可能在个别层没有对应的要求需要落实。
业务流细化分析流程
分析业务系统数据流是整个业务数据流分析过程中最重要的环节，通过业务流程分析最终输出系统数据流程图。
分析业务数据流的步骤如下：
第一步：获取业务系统网络拓扑结构，并进行核实，从而获得系统的应用场景;
第二步：通过人员访谈、系统文档调研的方法采集业务数据流的关键数据，包括业务之间的互访关系可能存在的威胁以及数据流走向;
第三步：数据包分析，通过对特定系统的数据包抓取获得真实的数据网络访问路径，发现通过人工访谈和文档分析不能全面了解的访问路径（注：该项工作的数据采集量可能较大，需要分析大量数据，不能了解系统服务器的真实端口开放情况）;
第四步：主机网络状态审计，通过系统服务开放情况获取主机网络连接状态;
第五步：分解业务系统，将业务系统按照功能模块分解成更小的业务单位，了解各业务单元之间的相互访问关系，以便从单个功能的角度去识别脆弱性和威胁。
第六步：脆弱性分析，针对每一个需要保护的资产，识别可能被威胁利用的弱点，并对脆弱性的严重程度进行评估。脆弱性的识别的数据主要来自资产的所有者、使用者以及相关业务领域的专家和软硬件方面的专业人士。在此基础上，进行威胁路径分析，分析业务系统体系结构中潜在的安全漏洞结合攻击者的目标，通过业务数据流示意图来识别所有可能影响目标的威胁路径。 第七步：风险综合分析，结合系统的脆弱性和威胁路径进行综合的风险分析，对威胁发生的可能性进行评估，将威胁带来的风险与攻击者的成本进行比较，进而采取相应的措施。
第八步：给出安全建议，对于分析得出的风险，给出整改建议并输出相应的评估报告。
安全需求（脆弱性）分析方法说明
安全控制体系构建途径：系统安全控制体系构建经过三个步骤：1、信息安全需求定义;2、信息安全控制目标确立;3、信息安全管控体系设计和实现。通过系统化管控过程，对安全管控体系构建和运行过程进行管理和控制。下面对上述三个步骤的主要工作内容进行概要描述：
信息安全需求定义：系统信息安全需求来源于三个方面：法规依从性要求、业务安全需要和风险管控要求。综合三方面安全需求，对系统安全需求进行定义，作为信息安全目标确立以及安全管控体系设计的依据;
信息安全控制目标确立：基于系统安全需求定义，确定安全控制目标。考虑系统现有安全措施，组织风险接受程度、安全项目建设规划等因素，对需求定义中确定的安全需求进行归类合并，分解成多个可实现的安全控制目标。这些控制目标将成为系统安全策略和安全控制制定和构建依据与基础。
信息安全控制体系设计和实现：第一步是明确安全政策，信息安全政策是约束主体对信息客体行为的准则，是为了达到一定的信息安全管控目标而制定的，安全政策是安全建设的基础要素。第二步具体制定系统安全管理制度、落实系统安全责任体系、落地系统技术控制措施、建立系统安全过程。
安全管控是动态的持续性过程，体系运行过程中，随时面临安全风险，通过持续性监控确保安全管控体系持续运行，实现信息安全的闭环管理。
系统安全需求定义方法
根据系统信息安全管控体系建设过程，信息安全的需求来源于三个方面，即合规性要求、业务要求和风险控制要求。
一是法规依从安全要求，组织具有社会性，参与各种社会活动，负有社会责任，行为受到各种社会规则的约束，这些约束来自国家、行业、商业活动以及企业内部要求四方面。
国家层面：作为重要国企之一，信息化建设必须符合国家法律、法规、政策、标准，不能对国家、社会、其他组织和个人造成不良影响和伤害。
行业层面：作为国家重点监管的企业，其各种行为包括信息化、信息安全建设必须符合行业主管（即国务院国有资产监督管理委员会，简称国资委）制定的政策、规范和标准。
商业协议约束：作为企业，参与各种商业活动，需遵守商业活动涉及的标准、协议要求。系统作为商业活动经常使用的信息传输工具，必须符合相关约定。
企业内部：是一体积庞大的国有企业，为保证内部信息化以及信息安全建设的规范化、持续化发展，制定的有关管理办法、规范和标准，适用于所有的分项信息化建设。因此，系统安全建设必须符合相关文件的要求。
上述四方面的要求大部分以文件发布的方式明确各自的要求。系统安全建设之初，需对此类文件进行收集，对相关条款进行解读，确定适用条款。其中，法律、法规、行业规范以及商业合同约束等为强制性合规条款;建设标准、指南属于参考性条款。
二是业务安全要求，业务自身安全需求在安全开发体系中侧重EA架构中的业务层和信息层，主要来源于业务系统梳理后所涉及的业务逻辑安全、业务权限、数据生命周期安全及针对业务系统日常运维安全事件记录等进行汇总。业务自身安全需求需根据业务系统业务功能的变化及日常发生的业务安全运维事件记录不断更新。
三是风险控制安全需求，通过信息化手段实现业务，就不可避免的面临信息有关的安全风险。电子业务面临的风险分为两类：系统风险和系统应用风险。
系统自身风险：是由于系统自身的控制措施不足导致系统自身重要信息资产和基础设施面临被攻击或破坏的的风险。面临风险的主体是系统本身，其安全需求集中在如何保证系统自身的安全。可采用行业内信息系统风险评估方法，发现系统的技术风险和管理风险。
系统应用风险：系统是员工进行内部、外部沟通的主要信息传输工具，是最大的暴露面之一。恶意份子借助系统，可能渗透到企业内XX用户，并以此做为跳板攻击企业网内部，或窃取内部敏感信息;内部员工，可能通过系统发送违法信息或窃取内部敏感信息;系统本身也可能被利用，例如被攻击成为垃圾XX的制造和发送者。这些风险不会影响业务的正常使用，但是會对其他系统或信息造成安全隐患。
本方法强调在进行安全需求分析时，要全面考虑这三个来源。上述三个方面的安全要求，没有明确的界限，会出现交叉现象。三者关系如下图所示：
四是法规依从性安全需求，法规依从性安全需求主要按照广东电网公司信息安全管理办法要求进行整理归类，该管理办法主要是参照国家等保标准并结合电力行业特点和广东电网自身实际情况制定，融合了技术管理两方面，具有很强的针对性，我们将尽量选取跟业务有较强的直接或间接关联的要求提取相应的风险控制点（指标），详细控制点参见方法论报告附件。
五是业务自身安全需求，业务自身安全需求是通过业务梳理分析而得到，具体来说是识别业务活动、识别业务数据、识别跟安全相关的业务规则，然后用经典的CIA（保密性、完整性、可信性）针对EA架构中的业务层、信息层、应用层、基础设施层（侧重业务层和信息层）分别进行分析，从而得到响应的控制点（重点是业务逻辑安全、业务权限、数据生命周期安全）。详细控制点参见方法论报告附件中的实例。
六是风险控制安全需求，针对业务场景采用微软STRIDE威胁模型，STRIDE威胁分类法是从攻击者的角度考虑威胁，围绕外部实体、处理、数据存储、数据流四个方面从如下六个角度分别进行分析：伪冒（Spoofing），伪冒威胁是指恶意方伪装成某人或某对象，如钓鱼站点伪冒真实的网银服务器，对用户发起钓鱼攻击。篡改（Tampering），篡改威胁包含对于数据以及代码的各种恶意修改。如恶意攻击者在链路层上修改用户转账的转账对象账号，窃取用户资金。抵赖（Repudiation），抵赖威胁是指用户或入侵者拒绝承认一个已执行的无法证实的行为，如用户否认进行交易。信息泄露（Information Disclosure），信息泄露是指将敏感信息泄露给那些未经授权获得访问的个体，如本地临时信息未及时清理造成的敏感信息泄露。拒绝服务（Denial of Service），拒绝服务（DoS）攻击通过使得服务暂时不可用或瘫痪，从而破坏系统的可用性。如针对网银服务器的拒绝服务攻击。权限提升（Elevation of Privilege），权限提升（EoP）通常发生在用户获得更高的能力场景之下，比如匿名用户利用系统的某个漏洞获得认证用户才能具有的权限。 在业务安全评估过程中，基于业务场景进行风险控制安全需求分析借助stride威胁模型能帮助理解系统中的潜在的安全威胁，明确风险并建立相应消减机制。对于业务系统安全测评来说，在测评准备阶段，通过威胁建模理解系统可能面临的安全威胁，掌握威胁可能利用的脆弱点位置，使得测评人员在现场测试阶段能有目的的按照预定的脆弱点位置查找漏洞和隐患，并帮助渗透测试人员快速有效寻找攻击路径，使测试工作更能贴合信息系统的安全风险场景。
不同信息系统由于其各自业务使命的不同，其威胁模型不同。随着信息系统运行环境的变化（例如最新的攻击技术，内外网应用转换等），其威胁模型也会变化。不同人员其对系统安全风险的理解不同，所建立的威胁模型也有差别。
这里需说明两点：1、风险控制安全需求实际上是业务安全需求导出的辅助（得到某业务场景潜在的安全威胁），本省并不能导出控制点。2、能达成检查对象的落地。从外部实体、处理、数据存储、数据流四个方面着手，通过EA架构映射到具体的基础实施，得到某个业务流程应该检查的实际对象。
业务影响分析
业务影响分析（Business Impact Analysis），也称业务影响评估（Business Impact Assessment），分析了干扰性风险对组织运营的影响方式，同时识别并量化了必要的风险管理能力。具体来说，BIA就以下问题达成了一致的认识：
关键经营过程的识别和临界状态、职能和相关资源以及组织已有的关键互相依存关系;
干扰性事项对实现重要经营目标的能力会产生怎样的影响;
管理干扰的影响以及使组织恢复到约定运行水平所需的能力。
业务影响分析（BIA）和风险评估通常是两个独立的流程，但它们必须同时或并行执行。其原因是，对没有进行风险评估的业务进行的评估影响不能提供全面的信息。我们可以认为影响是不会改变的。如果一个关键系统的中断对业务具有较高的影响（财务的或其他的），那么无论我们做什么，实际中断所造成的影响仍然很高。我们无法改变影响，我们只能尽量避免运行中断。
BIA的主要作用是：
对关键过程的认识，使组织有能力继续实现其既定目标;
对资源的认识;
有机会重新界定组织的运行过程，以增強组织的灵活性。
结合业务风险评估的具体的业务影响分析框架图如下：
三、结语。
国内外大量文献对基于业务的安全评估方法进行了研究，提出了很多有用的方案和算法。但是对业务安全的专项研究比较少，由于业务安全是一种新兴的技术，目前的应用还主要在实验阶段，研究存在一定的局限性，未来可以尝试通过模拟仿真等方法对该机制进行更进一步的论证，并尝试推广到其他应用场景。
参考文献：
[1]《国家信息化领导小组关于加强信息安全保障工作的意见》（中办发[2003]27号）.
[2]《中华人民共和国计算机信息系统安全保护条例》（国务院147号令）.
[3]《信息安全等级保护管理办法》（公通字[2007]43号）.
[4]《GB/T 18336-2008信息技术 安全技术 信息技术安全性评估准则》.
[5]《GB/T 22239-2019 信息系统安全等级保护基本要求》.
[6]《GB/T 20984-2007 信息安全技术信息安全风险评估规范》.