=Start=

缘由：

最近在学习ITIL的时候意外发现知乎上的几篇文章之一，讲的非常系统（还贴心的将涉及到的一些标准、文档之类的放在网盘中方便进一步深入学习，太赞！），看完之后真的是「感觉就是自己菜到抠脚」了，经作者同意，将文章转载至此，方便自己经常查看、学习。

• 原文链接：信息安全体系的“术”：“术”的详解
  
• 作者：刘巍然-学酥（业斐）

PS：出于排版格式的考虑，有对部分「分隔符」之类的进行轻微删改，还望理解。

正文：

参考解答：

上期回顾与本期内容

在上一篇专栏文章《信息安全体系的“术”：标准主线与关联性》中，我们讲解了企业内部风险控制、IT风险控制、信息安全管理体系的相关标准。我们梳理了标准主线，以及标准相互之间的关联性。

本期，我们灵活讲解具体术的使用技巧，但不涉及具体的内容。

按照标准之间的关系，我们分别梳理如下体系中渗透出的“术”：

• 企业风险管控：COSO，SOX法案，SOX的404条款
• IT风险管控：COBIT
• 信息安全风险评估：ISO13335、ISO27005
• 信息安全技术评估
• 信息安全技术体系：IATF、等级保护
• 信息安全管理体系：ISO27000系列
• 信息安全流程体系：ITIL系列
• IT审计

实际上，信息安全本质上就是风险管理控制。而风险管理控制的核心就是守护价值。在进入企业参与信息安全相关的工作时，经常会存在一个误区，认为保障信息安全是天经地义的事情。其实，做任何事情都是有价值的。由于信息安全会涉及较大的开销，如果企业的IT无法产生足够的价值，那么保障信息安全反而会带来更大的负担。举个例子，如果我有1000根金条，总价值超过1亿，我才愿意花费100万元购买一个可靠的保险柜。反之，如果我只有1万元的资产，我肯定不会去购买100万元的保险柜。很多企业的信息安全风险管控不健全，可能的原因之一是其IT无法带来与安全相匹配的价值。因此，在考察企业信息安全风险管控和相关管理、技术等方面时，要注意这个问题。不能一刀切，认为所有的企业都需实现健全的信息安全风险管控。

守护价值：企业风险管控

企业具体关注什么风险？

COSO发布了企业风险管理综合框架，详细总结了企业需要关注的风险，主要由财务风险、法律风险、组织风险、运营风险等。下图展示的是2004版COSO企业风险管理综合框架*（图片来源：COSO企业风险管理综合框架）。

COSO企业风险管理综合框架主要关注8大层面的企业风险。

• 内部环境：治理结构、组织结构、授权与责任、风险偏好、人力资源政策、风险管理文化等。
• 目标设定：战略目标、经营目标、报告目标、合规目标。
• 事项识别：事件识别方法、事件分类、风险与机会。
• 风险评估（与信息安全高度相关）：固有风险与剩余风险评估。现在，COSO里面的风险评估方法为“风险=发生可能性*影响”。ISO27005也采用了相同的风险评估方法。这进一步体现了标准与标准之间的映射和借鉴关系。
• 风险应对：风险回避、风险降低、风险分担、风险承担。
• 控制活动（与信息安全高度相关）：企业层面控制、业务流程层面控制、IT一般控制与应用控制。其中，IT一般控制与应用控制具体实现在COBIT里面进行了详尽描述。这也体现了标准之间的映射和借鉴关系。
• 信息与沟通：收集与传递内部信息、外部信息。
• 监控：独立监控、持续监控、自我评价、缺陷改进。

COSO和IT风险有什么关系？

结合COSO框架和上一篇专栏所讲解的内容，我们可以看出框架中的部分内容实际和COBIT等框架是有契合点的。控制活动中业务流程层面控制、IT一般控制、应用控制和COBIT是契合的。实际上，COBIT中专门提到了IT一般控制和应用控制，与COSO框架中此部分的内容完全契合；COSO中的信息与沟通、监控等在COBIT中也有相应的承接。

SOX法案与COSO相比，增加了什么内容，和IT风险有什么关系？

在上一篇专栏中我们讲到，安然公司的破产等丑闻事件促使美国颁发了SOX法案。SOX法案所增加的核心内容之一是企业风险和刑事责任的结合。而另一个核心内容与IT风险有着紧密的关系，就是我们之前提到的404条款。404条款要求保证会计账务、财务报告、财务流程、财务应用和底层IT基础架构的完整性、可用性、准确性。虽然SOX法案无法具体落地，但SOX法案对IT风险控制产生了巨大的影响。

守护价值：IT风险管控

COBIT是什么？

首先，我们来看一看COBIT 4.1的框架图（图片来源：IT Governance Institute，中国建设银行翻译，COBIT 4.1，第43页）

COBIT中主要关注4个维度的内容：计划与组织、获取与实施、交付与支持、监控与评价。各个维度所关注的具体项目如下图所示。

业内对于COBIT的定义有不同的观点。有的人认为，COBIT是一个IT风险评估框架；有的人认为，COBIT是一个IT审计框架；有的人认为，COBIT是一个IT治理框架。我们认为这3种理解都是正确的。

• IT风险评估是指，根据自己的方法去评估IT中有哪些风险。可以使用COBIT作为IT风险评估的方法。COBIT列举了很多条目。当评估IT风险时，我们可以考察所缺失的项，并评估这些缺失的项会引发何种风险。此时，我们可以将COBIT理解为IT风险评估框架。
• IT审计框架相对比较好理解，我们可以按照COBIT框架，对IT的各项进行逐条审计。
• 业内一般将IT治理分为2类：控制论IT治理和决策论IT治理。决策论IT治理主要考虑决策什么，谁来决策，如何监督有效执行。控制论IT治理就是以COBIT为代表，其主旨是通过控制风险达到治理目标。即考察：IT架构与企业风险是否是战略匹配的；所拥有的资源是否可以恰巧解决高、中、低风险；项目管理是否是有效的；管理框架和要求是否可以落地执行等。因此，可以通过风险控制的方式实现IT治理。

IT风险比信息安全风险更关注什么？

信息安全风险是IT风险的一部分。信息安全风险主要关注系统如何不被入侵，如何实现数据保密等。而IT风险需要考察与涉及IT活动的各种风险。举个例子，企业想上线一套企业资源规划（Enterprise Resource Planning，ERP）系统实现IT业务线的资源流程管理。那么，企业是购买系统，还是独自开发系统？独自开发系统的话，如果在规定时间内没有完成开发，则如何处理？这类问题也是IT风险需要控制的内容。在某种程度上，IT风险和信息安全风险也是互相映射的。举个例子，企业遭到了黑客的攻击，那么企业要购买安全设备抵御攻击？还是独立研发技术和设备抵御攻击？总之，IT风险关注的问题比信息安全风险所关注的问题要大，但互相之间是相互映射的。

在此，我们举一个IT风险的实例，让朋友们更好地理解IT风险及其控制方法。互联网云服务提供商为客户提供云存储服务。客户所要求的服务等级协议（Service-Level Agreement，SLA）中要求提供7*24小时的服务。然而，云服务商的某个堡垒机是从某个外企厂商购买的，此外企厂商仅承诺提供5*8小时的服务。因此，一旦在5*8小时之外出现事故，那么云服务提供商就会面临相应的风险。如何降低这种风险呢？我们可以按照COBIT框架进行风险控制和管理。

1. 识别所有的供应服务商。
2. 对供应服务商按照设备功能、关键程度等进行分类。服务器相关、网络设备相关等关键程度最高；笔记本电脑相关、台式电脑相关的关键程度较低。
3. 要求供应服务商提供相应的支持证书。
4. 考察服务商的持续发展能力。对于小规模企业，要注意企业可能会破产、倒闭等。
5. 管理与供应服务商的关系，保持联系。
6. 在购买设备和服务时，要签订相应的SLA。
7. 确保供应商所提供的服务满足法律相关的业务标准，要签订相应的保密协议和责任协议。
8. 实施供应服务商的变更流程、惩罚与奖励措施。
9. 实施绩效管理。服务供应商应满足业务要求，能够履行合同协议。绩效与市场现状相比要有能力、价格等的竞争力。

上述就是COBIT框架。虽然这个框架看起来比较空，但真正落地的时候，我们会发现COBIT覆盖了几乎所有的IT风险。因此，COBIT堪称经典！

守护价值：信息安全风险评估

在讲信息安全风险评估前，我们首先看一看风险评估标准ISO13335中给出的风险管理中的关系（图片来源：ISO13335-1:1996，P16）。

按照上图，我们可以很清楚地整理出各个项与风险之间的关系：

• 信息资产拥有价值，增加风险；
• 威胁可以利用漏洞，增加风险；
• 漏洞会暴露相应的信息资产；
• 相应的防护措施可以抗击威胁，可以降低风险。

有了风险管理中的各个关系，我们就可以根据关系进行相应的风险评估了。在风险评估中，我们主要关注的就是资产、威胁、漏洞。业内一般有3种风险评估方式：定性风险评估、定量风险评估、半定量风险评估。

定性风险评估：ISO13335、ISO27005

定性风险评估就是ISO13335和ISO27005标准，业内对标准的使用和理解已经很成熟，在此不再过多讲解。但是注意，使用风险评估时一定要和业务紧密结合。

举个例子，飞机设计图纸是否具有极高的保密性要求？如果没有和业务人员进行充分交流，我们可能会想当然地认为任意国家的飞机设计图纸均为高度机密资料。但是，风险评估与业务紧密结合后发现，A国某型号的飞机设计图纸是从空客或波音公司的飞机原型中拆解描绘得来，仅描述了部件的规格和型号，此设计图纸在国际范围内不会引起其他国家的关注。同时，A国仅有唯一的企业有资格制造和生产飞机。因此，即使飞机设计图纸泄密，也不会对企业造成较大的业务风险。考虑上述业务背景后，A国的飞机设计图纸就不具有极高的保密性要求了。

定量风险评估

定量风险评估和财产挂钩，也就是用财产量化的方式描述风险。一般，业内不会实施定量风险评估，因为很难评估风险所涉及的财产价值。但是我们可以通过相同的定量风险评估方式核算出风险的控制收益的趋势。

定量风险评估的方法一般需要比较两个参数的大小：（1）采用安全控制措施后的收益、（2）安全控制措施的成本。显然，当（1）大于（2）时，意味着所采取的安全控制措施为企业带来了收益，应该采用；否则（1）小于（2），意味着安全控制措施的成本大于收益，不应采用此安全措施。而采用安全控制措施后的收益可以通过财产价值与下述参数计算得到：

• 暴露因子（EF）：标识的威胁造成的财产损失百分比
• 单次损失期望值（SLE）=财产价值*EF
• 年发生概率（ARO）：某个威胁一年中发生的估计概率
• 年损失期望值（ALE）=SLE*ARO
• 采用安全控制措施后的收益=ALE-采用安全控制措施后的ALE

现在，信息安全风险评估方法在逐渐与企业风险评估模型靠近。信息安全风险评估方法在信息安全领域已经使用的非常成熟了。

信息安全技术评估

我们看到了IT风险评估，信息安全风险评估。那么，有信息安全技术评估的相关标准吗？实际上，是没有信息安全技术评估标准的。但是，业内仍然存在这样的意识形态，如评估网络可靠性、渗透测试等安全技术。这是为什么呢？

实际上，风险评估是2004年开始发展的。但是在当时，并不是所有的企业都有能力实施风险评估。然而，一些安全企业发现，风险评估中的一些具体活动，如扫描、渗透测试等，是可以具体实施的。因此，这些安全企业就逐渐开展了类似的技术评估。而技术评估结果等更加直观的体现了技术薄弱点。对于客户来说，发现了100个漏洞并修复；发现了服务器入侵风险，进行相应的措施等，比空泛地定性风险评估更容易被用户所接受。

所以，信息安全技术评估虽然没有相关标准，但类似的活动还会长期存在下去。我们在这里起码要区分清楚，信息安全技术评估不再标准里面，是约定俗成的一种意识形态。在业内，要区分IT风险评估、信息安全风险评估、信息安全技术评估这些概念。

管理体系：ISO27000系列

我们终于讲到ISO27000系列了，这是信息安全业内最广为人知的系列标准。

ISO27000标准家族

首先要强调，ISO27000是一个标准族，包括概论及术语、要求、规范、实施指南、测量、信息安全风险管理、认证机构要求等。

我们还是用制造桌子的例子来描述ISO27000系列各个标准之间的关系。

• ISO27000，概论及术语，2009年出版：指出后面要用到一些名词，如桌子、边、直的等；
• ISO27001，要求，2009年出版，对桌子进行认证，说明作为桌子应该有什么要求；
• ISO/IEC27002，规范，2013年改版：如何满足桌子的要求？桌子应该有4条边，边应该是直的。
• ISO/IEC27003，实施指南，2010年出版：如何保证有4条边呢？如何做才能保证边是直的？
• ISO/IEC27004，测量，20009年出版：桌子是否满足要求，查看做出来的东西与桌子之间相差多少。
• ISO/IEC27005，风险管理，2008年出版：并没有有关桌子的合适实例。
• ISO/IEC27006，认证机构要求，2007年出版：桌子制作完，认证机构要进行认证。但是，如何认证认证机构本身？

认证委、认证公司、咨询公司的关系

• 上面我们提到，ISO/IEC27006用于对认证机构进行认证。认证委就是国家机关。国家机关对认证公司的能力、认证实施过程和方法论等进行认证，最终向认证公司颁发认证资质。
• 认证公司是获得国家机关认证的资质，来认证其他的机构是否符合ISO27001。
• ISO27001是一个比较复杂的标准，通过ISO27001相对来说也比较困难，因此就出现了咨询公司。咨询公司为企业提供咨询，帮助企业获得ISO27001认证。

ISO27001和ISO27002有什么不同？

前面说到，ISO27001是要求，ISO27002是规范，这两个到底有何不同呢？我们简单对比一下ISO27001和ISO27002的具体内容，就可以大概理解其不同之处。下图是ISO27001附录A的第1页，我们只关注“5 信息安全方针”一部分即可（图片来源：ISO/IEC27001：2013，小李飞刀翻译，P15）。

下图是ISO27002所对应的“5 信息安全方针”一部分（图片来源：GB/T 22081-2008/ISO/IEC27002：2005，P11）。

可以看出，虽然都是“5 信息安全方针”一部分，目标是一样的。但是ISO27001只是给出了具体目标，而ISO27002指出了具体的控制措施。

ISO27001只有管理要求吗？

不能简单地认为ISO27001只涉及管理，只涉及文档。比如，提出访问控制需求后，根据安全域的划分需求进行安全域划分，划分后还应有具体的技术方案实现访问控制需求。所以，ISO27001中不仅涉及了管理要求，还有各种支持性文档和指南文件作为技术方案落地的参考。下图是ISMS的方针目标、策略、和相关的指南文件结构图。

其中，蓝色框中的为总体目标和总体方针。粉色框中的为各目标和方针的指南文件、操作文件，作为技术方案落地的参考。最下方的表单相应的技术维护文档，用户记录评审信息和维护信息。

总之，ISO27001不仅涉及管理和文档，还有具体的实施指南、规定和办法，用户进行技术落地。但是，我们这里要强调的是，信息安全管理体系并没有进行具体技术体系的指导。但是，没有指导不代表不去参考。

ISO27001：2013版本有什么变化？

我们直接引用上海安言咨询给出的图来描述ISO27001：2013版本的变化。业内一般称“北谷安、南安言”，这两家公司是信息安全咨询非常知名的公司。

可以看到，与ISO27001：2005版本相比，ISO27001：2013版本针对近年来的安全需求，对部分内容进行了分化，也增加了部分内容。

流程体系：信息技术基础架构库（Information Technology Infrastructure Library，ITIL）

ITIL是一套有关IT服务管理的方法，从而为业务部门提供更好的服务。ITIL已经成为事实上的业界标准，并以其为中心在全球形成了完成的产业。ITIL分为两个重要的版本，ITIL version 2和ITIL version 3。这两个版本有很大的不同。现在，业内一般使用ITIL version 3了。下图很好地描述了ITIL的各个模块，并指出了ITIL version 2和ITIL version 3的区别（图片来源：ITIL V3 Foundation中文培训讲义，交大慧谷培训中心，P25）。

由于ITIL的模块较多，这里不能进行一一展开。在此，我们仅简单介绍几个重要的模块。

• 供应商管理：方案是背靠背。
• 信息安全管理：参考ISO27001。
• 业务连续性管理：参考ISO22301。
• 容量管理：应使用一定的技术手段去监测，当性能不足时应能够进行相应的快速扩容。举个例子，以前互联网的带宽是100M，现在变成1G，那么路由、网络设备、安全设备都需要升级。
• 服务级别管理：就是服务级别协议（Service Level Agreement，SLA）。所承诺的SLA代表了1年所出事故的时长要小于规定的范围。
• 发布与部署管理：当信息系统从测试环境编译，待正式发布时，应该有一定的控制措施。
• 资产与配置管理：就是运维配置管理数据库（Configuration Management Database，CMDB）。
• 变更管理：直观上看，发布与部署管理属于变更的一种。但是ITIL把发布与部署管理、变更管理进行了区分。这是因为发布一般来说是从测试环境到生产环境的变化。但只要生产环境有所变化，都应属于变更。所以，从定义上两者需要进行区分。变更管理的一个典型实例是，系统工程师为了测试方便，在防火墙的Untrust区到Trust区第1条规则中就设置了any to any permit，导致防火墙的规则防护形同虚设。如果采用了恰当的变更管理流程，此种规则变更在审批时将无法获得通过。
• 事件管理：我们认为翻译成事态管理更加合适。事态是指暂时没有没有影响到生产环境，但持续下去预计会影响业务执行的事件。比如，CPU使用率前天为50%，昨天是60%，今天是70%。这类事件就属于事态管理的范畴。
• 问题管理：问题是指已经影响到生产环境的事件。比如，防火墙使用了NAT状态功能，当防火墙瘫痪时，就需要对生产环境进行变更，进行相应的处置。
• 故障管理：如果某个问题事件频发，问题就升级成为了故障。比如，思科路由器存在SSH拒绝服务漏洞，此漏洞被蠕虫病毒所利用，导致思科路由器的CPU使用率飙升。虽然重启路由器会暂时解决此问题，但问题会周期性地重复出现。此时就需要进行问题回溯，追溯问题发生的原因。此类事件称为故障。

技术体系：IATF

信息保障技术框架（information Assurance Technical Framework，IATF）总体架构如下图（图片来源：IATF Release 3.1，Appendix C，P42）。

IATF是国际上第一个提出技术、运行、人员（PPT）三位一体的纵深防御理念。其指出，人员，借助技术的支持，实施一系列的运行过程，最终实现信息保障目标的方法。根据纵深防御理念，IATF提出4部分架构：本地的计算环境、区域边界、网络和基础设施、支持性的基础设施。技术环境就是服务器等；区域边界指外联区、广域网、加盟机构等相互之间的边界；网络和基础设施就是企业的基本网络设施；支持性的基础设施指的是证书机构（Certification Authority，CA）、电子邮件（Email）等设施。其具体关键点总结如下：

IATF指出，要按照纵深防御的理念，人员、操作、技术的方式，在本地的计算环境、区域边界、网络和基础设施、支持性的基础设施中，重复地采用纵深防御进行防护。我们之所以将IATF列为技术体系，并不是因为其指出了人员、操作、技术的纵深防御理念，而是因为IATF给出了本地的计算环境、区域边界、网络和基础设施、支持性的基础设施这四个区域中所需要技术防御方法和架构。举个例子，在区域边界中（IATF Release 3.1——September 2002，第六章），IATF详细给出了如下内容：

• 防火墙的功能要求、潜在攻击、潜在攻击策略、技术评估方法
• 远程访问的功能要求、潜在攻击、潜在对策、技术评估方法
• 边界访问的要求、潜在攻击、潜在对策、技术评估方法、产品选择准则
• ……

IATF虽然现在基本已不再使用，3.0版本后也不再更新，但是纵深防御的理念为未来的安全体系奠定了基础。

偏技术体系：等级保护

等级保护相对来说偏技术体系，这是因为在使用等级保护时，我们一般只参考技术部分。

大部分人所能接触到的都是等级保护的基本要求。等级保护分为技术层面和管理场面，分别有各种对应的要求。企业需要根据这些要求完成相应的文档、流程、表单等。下图可以很好地总结等级保护的要求。

不同级别所要求等级保护的点数也有所不同。标准根据不同的安全域，一共划分了五个等级。但是标准中没有规定第5级的要求，因此一般称有4级等级保护要求。标准中规定了各个层级的要求和综合管理要求，对信息安全的技术体系具有指导意义。

等级保护对技术要求的整理和归纳是很不错的，使用起来很方便，也不会出现歧义。有些企业会自己制定相应的技术体系，如从预警、检测、防护、恢复这4个维度构建技术体系。这是一种技术体系落地的一种可行方法。业内一般用信息安全管理体系代替等级保护的管理要求。这同样体现了标准与标准之间互相渗透的特性。

业内实现等级保护时一般只参考《等级保护基本要求》。实际上等级保护相关的标准和规定很多，共有8个政策性文件以及各种技术文件。8个政策性文件为：

• 《中华人民共和国计算机信息安全保护条例（国务院147号令）》
• 《关于信息安全等级保护工作的实施意见（公通字【2004】66号）》
• 《信息安全等级保护管理办法（公通字【2007】43号）》
• 《关于开展全国重要信息系统安全等级保护定级工作的通知（公信安【2007】861号）》
• 《信息安全等级保护备案实施细则（公信安【2007】1360号）》
• 《公安机关信息安全等级保护检查工作规范（公信安【2008】736号）》
• 《关于加强国家电子政务工程建设项目信息安全风险评估工作的通知（发改高技【2008】2071号）》
• 《关于开展信息安全等级保护安全建设整改工作的指导意见（公信安【2009】1429号）》

客观地说，等级保护在标准的整个生命周期框架里是非常完整的。无论是从国家立法、监督执行与指导、与风险评估的结合、相关部位的支撑都是非常体系化的，并不亚于ISO27001标准。等级保护详细描述了实施生命周期内的主要活动，如图所示。

我们对等级保护的评价是非常中肯的，我们很想为等级保护正名。在信息安全起步的初级阶段，等级保护可以起到很好的指导借鉴作用。

IT审计

IT审计是：独立的第三方IT审计师获取并评价证据，以判断IT环境是否能够保证资产的安全、数据的完整、有效率的利用组织资源、有效果地实现组织目标的过程。 IT审计有几个重要的关键点：独立的第三方、获取并评价证据、证据可被重复识别和评价、可得到一直结论。下图可以很好地描述IT审计的作用。

IT审计有很多方法获取证据，我们这里强调几个和安全相关的审计方法：文档审核、访谈、配置核查、实地查看、漏洞扫描、渗透测试。审计证据要支撑审计结论，一共有符合并超出预期、符合、轻微不符合、部分不符合、严重不符合、不适用这几个维度。

IT审计中，优势证据的选择是一个很重要的问题。IT审计要求证据可以不断重复再现并能够统一得出一致性的意见。我们以审计服务器是否打补丁为例子：

• 访谈：找负责人询问是否安装了补丁；
• 配置核查：查询补丁安装的档案；
• 漏洞扫描：通过漏洞扫描查看漏洞是否通过安装补丁的方法修复；
• 渗透测试：通过渗透测试检查漏洞是否存在，是否有可能被利用；

那么，上述情况中哪些可以作为优势证据呢？对于安装补丁方面，漏洞扫描和渗透测试结果可以作为优势证据。这是因为：访谈可能会出现不真实的回答，甚至伪造。配置核查的结果确实安装了补丁，但没有对服务器进行重启，导致补丁没有生效。漏洞扫描结果可能会出现漏报。因此，上述顺序不存在严格的递进关系，要通过具体情况选择合适的证据。

IT审计中有两个重要的概念：符合性测试与实质性测试。

• 符合性测试是指，所宣称的控制措施是否真的有效。比如，安全工程师宣称防火墙对某台服务器采用了最小化服务的配置规则，但实际查看时可能会发现服务器对外开放了不必要的数据库端口。
• 实质性测试是指在符合性测试的基础上，为取得直接证据而在业务数据流程中使用检查、查询及计算、分析性复核等方法。比如财务系统需要做实质性测试，需要检查财务数据处理流程中每个模块的输入、处理、输出的函数是否会造成数据异常，来验证财务数据是否是完整可靠的。

业内公认，符合性测试结果越好，说明信任度越高，实质性测试相对来说可以越少。另外，在测试时一定要注意独立第三方原则，避免内部勾结造假。

另外，IT审计分为内审和外审。内审是指内部人员来审计目前的规章制度和运行情况与标准之间的差距。外审就是第三方的人员进行审计。一般建议，内审半年或者一个季度一审查。外审一般是一年一审。IT审计也适用于安全审计。

知识和文档体系展示

在专栏文章的最后，我们用一个框架图来展示信息安全的知识，及相应的文档体系。

参考链接：

• 信息安全体系的“术”：“术”的详解

=END=