姚志平，CISSP CDPSE CISM CISA CEH CHFI，曾在多家世界500强企业负责信息安全及风险管理工作，现在某外资银行负责信息安全风险审计工作。
----------------------------------------------------------
各位群友晚上好，非常感谢聂总，也非常荣幸有这次机会跟大家分享。
今天我分享的主题是“浅谈风险管理视角的信息安全工作”，这个话题本身涉及的面非常广，我会基于个人经验浅谈一下对这一个话题的理解，纯当抛砖引玉，大家多指正。
信息安全需要体现业务价值，这是一个老生常谈的话题。但是结合到具体实践中，你会发现很难为信息安全找到一席之地。例如在典型的公司治理架构中（Enterprise GovernanceStructure - Sample1，Enterprise Governance Structure - Sample2），我们是很难看到信息安全的字眼存在的。而与其相关度最强的，很多时候就是通过 risk forum 或者 risk committee去阐述业务价值。
Enterprise Governance Structure - Sample1
Enterprise Governance Structure - Sample2
而从风险管理的角度，一些业界常用的风险管理相关的标准，依然只是指引性的框架，没有真正看到信息安全相关的风险管理如何在实际工作中落地。例如偏企业风险治理的 COSO 的Enterprise Risk Management Framework, 还有偏 IT 治理的 COBIT。
COSO Enterprise Risk Management Framework
![姚志平：浅谈风险管理视角的信息安全工作]( "姚志平：浅谈风险管理视角的信息安全工作")
COBIT Core Objective and Reference Model
信息安全领域本身也推出了一系列信息安全风险管理的标准，例如 ISO 27000 系列中的 27005（ Information security risk management ）以及 NIST 系列中的 SP 800-37R2 (Risk Management Framework for Information Systems and Organizations)，这些标准则更像是信息安全风险管理的操作手册。
ISO/IEC 27005: information security risk management process
27005 主要覆盖风险识别，风险分析，风险评估，风险处置以及风险监控的整个风险生命周期管理。
NIST 800-37R2 Risk Management Framework for Information Systems and Organizations
NIST800-37 主要覆盖系统分类，控制选择，控制部署，控制评估，控制监控的整个控制相关的生命周期管理。
在这里要提一下 ISACA 的 RISK IT Framework，算是其中一个比较早的将 IT 和信息安全相关风险带入到整个风险范畴（如战略风险，市场风险，合规风险，法律风险等）的一个框架。
I&T-related risks in Risk IT framework
我们都知道，上世纪 80 年代债务危机背景下出台的 Basel I，把风险管理体系正式带入到金融系统。而随后的 Basel II 和 Basel III 中，增加了“操作风险”（Operational Risk）的内容和要求，IT 系统相关的风险事件也终于纳入到银行风险管理体系中来。
Basel Operational Risk Taxonomy
Basel 对推动行业全面风险管理的作用是巨大的。但是从另一方面，他又容易造成 IT 从业者思维定势，我所能影响的就是“操作风险”，或者只能是“操作风险”中的 system event 或者system security event。
在这里跟大家分享几个典型的把思维局限在 system event 的例子：
最近因为 log4j，大家对开源软件安全风险的关注度进一步提高了。之前我们对集团内部开源软件管理做了一次全面风险审查。审查中看到我们已经有明确的开源组件来源管控策略，统一的外部下载接口，统一的开源组件仓库，并且开源组件的安全管控也嵌入到了SDLC(Software Development Life Cycle)中，在软件开发和集成过程中都会进行卡点扫描，对开源仓库也会进行定期安全扫描，开源组件中的安全问题也会输入到安全漏洞工单系统进行闭环管理。但是在审查过程中我们发现了非常致命的一个缺陷，就是这些开源软件的许可证竟然无人过问。
软件开发流程的管理人员，往往会关注开源软件的安全漏洞和变更管理，但是忽略了更广泛风险光谱中的法律风险（legalrisk）。其实开源软件虽然名为“开源”，但他的许可也由松趋严，分不同的类型。
使用开源软件如果违反了相应的软件许可，对企业造成的影响，不比 log4j 小，如软件下架，业务停顿，甚至法律诉讼。关于开源软件许可的一些诉讼案例，可以参考维基上的 Opensource license litigation。
另一个例子是我们对集团的互联网安全接入控制做的风险审查。同样的，在传统安全控制上，或者说传统的外部网络攻击风险上，该上的控制都上了，诸如恶意 URL 阻断，CASB、DLP耦合，可疑文件沙箱隔离，高危流量审计，例外访问审批流程等。
同样在审查过程中，非法流量的阻断控制上，Hacking、Games、Pornography、Weapons这些显眼的该阻断都阻断了。但是有两种流量却被轻易放过了，他们是 Instant Messaging 和 OnlineMeeting。由于疫情影响，很多与客户的沟通工作，都更多地采用线上方式进行。但是对于金融行业，与客户的沟通往往是需要可记录及可稽查的。Web gateway 的管理人员，忽略了更广泛风险光谱中的员工操守风险（conduct risk）及合规风险（regulatory compliance risk）。至于使用非可记录稽查的方式与客户沟通的后果，下面案例是一个比较典型的例子。
JPMorgan fined $200M, failed to monitor employee communication
https://nypost.us.homelinux.com/2021/12/17/jpmorgan-fined-200m-failed-to-monitor-
其他的关于 IT 与信息安全相关的大风险范畴的示例，如撞库攻击，仿冒网站造成的外部欺诈风险，数据隐私保护所牵涉的法律与合规风险，人工智能与机器学习的 FATE 原则导致新的模型风险（model Risk）等。IT 与信息安全的能力圈，早已大大超出 Basel 中 businessdisruption and system failure 的范畴。
刚才提到在大风险范畴去识别信息安全相关的风险事件。在资产评估过程中，我们就可以对企业的关键风险事件进行识别。如何准确全面识别所有风险事件（如一般网络攻击，外部欺诈，内鬼，系统出错，特权账号管理），一直是安全从业人员的一个难题。而在这方面，刚才提到的 Basel 的操作风险目录可以作为一个参考。
巴塞尔协议在 1988 年的版本最早提出了操作风险的概念，并把操作风险归类为七个一级事件类型，分别是：Internal fraud, external fraud, employment practice and workplace safety,clients products & Business Practices, Damage to physical assets, business disruption and system failures, execution delivery & process management；而七个一级事件类型又细分为十三个二级事件类型。
Basel Level1 & Level2 Operational Risk Taxonomy
近年来，随着企业运作对 IT 的依赖越来越多，网络安全事件的不断发生和变化，行业也开始对操作风险事件的分类方法进行了更新和演进，如 O.R.X.推出的 Operational Risk Taxonomy，就增补了 Third Party, Technology, Information and Cyber Security 等。
ORX Operational Risk Taxonomy
实际工作中，企业和部门可以根据自己的风险特征进行适当的裁剪，但是在大部分金融企业，Internal Fraud, External Fraud，Technology, Information and Cyber Security 和 Regulatory Compliance 是大部分安全及 IT 风险管理者需要关注的，如下为参考示例：
具体的二类、三类风险事件，可以根据行业上的安全事件年报或安全报告进行细化和定期更新，如 Verizon Data Breach Investigation Report, X-Force Threat Intelligence Index,或者是一些行业联盟如 Operational Riskdata eXchange Association。如下图为参考示例：
也可以利用上面提到的安全行业报告定期对安全事件目录进行定期的更新，以确保安全目录的时效性。并且在后续对不同安全事件的风险分析时，安全行业报告中不同安全事件的发生次数是计算风险事件发生概率的重要输入。
识别出信息安全风险事件后，针对特定风险事件的分析一般会针对风险事件的影响与概率组成风险分析矩阵（Risk Assessment Matrix）,从而得到固有风险（Inherent Risk）,其中上面提到的 ISO27005, NIST 800-30 Guide for Conducting Risk Assessments 以及 The Open Group 的 Risk Taxonomy (O-RT)都有非常详细的分析方法。
我们经常提到 risk appetite（风险偏好），也即是决策主体对待可能出现的风险的态度。业务也往往用风险偏好和接收风险作为延迟修复控制的理由。
在这里 COSO 和 Risk IT 都提到了一个概念 Risk Capacity（风险容量）。其定义如下：Risk capacity is usually defined as the objective magnitude or amount of loss that an enterprise can tolerate without risking its continued existence.
也就是企业超过了这个风险损失，是不能持续运营下去的。有了这个基线，再去谈风险偏好，对实际工作中的风险评估，风险例外活动都非常有帮助。如下图左边的情况，就是一个相对稳定的风险管理模型，虽然实际风险围绕风险偏好上下波动，但是一直维持在组织的风险偏好以下。而下图右边的情况，就比较波动了，因为风险偏好定得有点高，实际风险发生时，组织往往无法承受实际产生的损失。
Risk Capacity, Risk Appetite and Actual Risk
我们在应对企业高管和内外部监管审计的要求时，总会设法做到所有控制都万无一失，事无巨细。
全球内部审计委员会在 2007 年发布的 IT 审计原则(Guide to the Assessment of IT (GAIT) Principles)中提出了两个非常重要的观点：
Principle 1: The failure of technology is only a risk that needs to be assessed, managed, and audited if it represents a risk to the business.
Principle 2: Key controls should be identified as the result of a top-down assessment of business risks, risk tolerance, and the controls—including automated controls—required to manage or mitigate business risk.
总结起来，就是只有影响到业务的风险才是真实的安全风险，而所有安全控制措施的唯一目的就是减缓业务风险。在实际情况中，我们没有见过一例“完美“的控制，但是有非常多将风险控制在极低程度的控制。所以当老板让你确保”不允许发生一起外部入侵事件“时，我们可以自信的说”我们的入侵拦截控制可以防止90%的入侵事件，即便发生入侵事件，我们的NTR，EDR，网络隔离，事件响应机制能够快速有效响应，使入侵本身不对组织造成实质风险“。当内外部审计提出”10 台电脑没有安装杀毒软件“的审计发现时，我们可以自信的回复”99%的安装率是我们的 KCI，10 台在我们的容忍度范围内，也不会影响组织的风险现状“。
https://www.coso.org/Documents/COSO-ICIF-11x17-Cube-Graphic.pdf
2. Risk Management Framework for Information Systems and Organizations
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r2.pdf
3. ISO/IEC 27005:2018 Information technology — Security techniques — Information security risk management
https://www.iso.org/standard/75281.html
4. ISACA Risk IT framework
https://store.isaca.org/s/store#/store/browse/detail/a2S4w000004Ko9VEAS
5. Open Source License Compliance
https://fossa.com/blog/tag/open-source-license-compliance/
6. Open source license litigation
https://en.wikipedia.org/wiki/Open_source_license_litigation
https://managingrisktogether.orx.org/operational-risk-taxonomy
8. Risk Taxonomy (O-RT), Version 2.0 - The Open Group
https://publications.opengroup.org/c13k
9. Verizon Data Breach Investigation Report
https://enterprise.verizon.com/resources/reports/2021-data-breach-investigations-report.pdf
10. X-Force Threat Intelligence Index
https://www.ibm.com/security/data-breach/threat-intelligence
11. NIST 800-30 Guide for Conducting Risk Assessments
https://csrc.nist.gov/publications/detail/sp/800-30/rev-1/final
----------------------------------------------------------------
Q1：集团下面各个分子公司很多，网络安全水平参差不齐。总部一级系统多，分子公司自建系统也多，投入水平也千差万别。请问有什么好方法让网络安全工作在集团内快速见效么？
A：从风险管理层面，子公司多，水平参差不齐，这是控制现状的问题。首先要梳理清楚，集团的风险偏好和子公司的风险偏好是否一致。如果一致，那么对集团也好，对子公司也好，所有控制要求都是一致的，可以根据风险偏好水平选定一些控制措施进行落实和评估（红蓝，渗透，审计均可），在集团和子公司内部进行定期的沟通与排名，这或许是一个比较快的促进工作的办法。如果集团和子公司风险偏好不一致，那么还是要落实到具体子公司进行沟通和风险识别，只从集团层面去推行一些控制，子公司不一定适用，也不一定有效。
Q2：一二三级指标有哪些？实际公司的信息安全管理是通过三级指标来反映风险水平，这一二三级指标分别怎么设计？
A：一二三级指标可以参考具体的risk taxonomy, 比如ORX这个是公开的，可以下载参考一下：https://managingrisktogether.orx.org/operational-risk-taxonomy。
我看见实际工作中是用KRI（key risk indicator）和KCI(key control indicator)来反映风险水平，至于安全的KRI和KCI， ISO有一个reference。当然我刚才分享也提到了，信息安全的KRI不要光集中在system event，这对我们从业者是挑战也是机遇。
Q3：log4j这个开源组件卡点扫描是使用了商用的开源组件扫描工具吗？还是普通的漏扫和代码扫描？
A：开源和商用都有，这个跟漏扫和代码扫描不一样，open source management蛮多工具可以做的，群里就不打广告了哈，可以私下交流。
Q4：安全部门在公司内部经常面临制度层面是信息科技风险管理一道防线职责，但实际做着二道防线职责，包括信息科技风险策略和模型、信息科技风险审查都需要，请问有没有好的能明确管理边界和绩效指标的建议？
A：传统金融企业的三道防线还是蛮清晰的，安全传统意义上就是第一道防线，当然最新版本的COSO也把安全定位成了二道防线的支撑部门。在实际工作中，二道防线作为risk steward评估一道防线的风险策略和风险水平，一道防线实际执行控制工作，但其实联系与合作非常紧密，分分合合都没有问题，都是风险的实际分析和控制。但是您提到信息科技风险审计，这个就一定要作为独立第三方部门了，个人建议要把这个权利交出去。第三道防线就好比监察机构，御史大夫，不能跟一二道混在一起，当然，如果三道防线缺乏技术能力，可以通过借调方式进行补充，个人不建议安全做纯三道防线的工作。
Q5：最后的总结很到位！请教一个问题：能否分享一些让领导重视安全的实践或者小技巧？
A：领导重视的是自己的业务，确实不是安全本身。让领导重视安全的技巧和实践，群里很多大佬之前都有非常好的经验分享。就我今天的分享来说，个人建议就是不要把眼界局限在系统风险或操作风险本身，切合业务，在更大的风险光谱去阐述信息安全工作，效果应该不会太差。当然，事件驱动，监管驱动，行业动态这些技巧，群内以前的分享就非常好用了。
Q6：在公司做风险评估，是侧重安全体系类的评估好一些，还是侧重围绕业务系统的风险评估好一些，安全体系类的评估总感觉比较偏上层对后续的安全规划输入不够，围绕业务系统的评估感觉也是解决了一些单点为题，有没有好一点的经验
A：感谢提问，这个问题非常好啊，我看到成功的案例，肯定还是要聚焦业务的，从业务角度进行风险评估，这个在ISO27005的附录里面有具体的说明，可以稍微参考一下。围绕业务的评估肯定是单点，这后续就需要CISO或者risk officer对评估结果进行整合梳理，这也是独特价值体现。因为业务只能看到一个点，科技只能看到科技的体系，cybersecurity head的价值会大大增加。
Q7：请教一下您在实践中如何更好的将安全触达业务，以保障企业战略一致？目前安全普遍汇报cio的情况比较多，这个过程中很有可能会牺牲安全，又将如何应对？
A：我看到的成功的CISO，不一定能够直达战略或者董事会，但是汇报的范畴一定超出传统操作风险或系统风险的范畴，这样往往看到的东西会比CIO还多还重要。在外企不止一次看到CISO通过炒作geopolitical的话题，越过CIO直接上board，当然这是极端例子。刚才分享的一些内容，就是给各位同仁一点借鉴，安全超过CIO的范畴，目前看是一个趋势。
Q8：如果控股公司、全资公司、并购公司从边界专线接入进来，那这个的访问控制流程怎么设计？比如访问控制的审核、审计、评估，这个有好的方式吗？我这几十条专线接入，访问控制上万条，人工审核的话太难。
A：抱歉，这个确实超出我的经验范畴了。不过相信群里有大佬能帮助解决的。
Q9：前文分享的第4点信息安全风险评估，即“识别出信息安全风险事件后，针对特定风险事件的分析一般会针对风险事件的影响与概率组成风险分析矩阵（Risk Assessment Matrix）,从而得到固有风险（Inherent Risk）其中上面提到的ISO27005, NIST 800-30 Guide for Conducting Risk Assessments 以及The Open Group的Risk Taxonomy (O-RT)都有非常详细的分析方法。”，这个可以展开讲一下吗？
A：这个评估还是比较普遍的，ISO27005和NIST800-30是专门的操作手册，结合刚才提到的Operation Risk Taxonomy 和Bow-Tie Method（这个可以google一下，5分钟秒懂的）。
Q10：请问一下关于开源仓库定期开展安全扫描能详细说一下吗？
第一个问题是下面举的具体风险例子，好像也没有实质对业务造成影响，比如许可证，客户沟通，防病毒，如果这些有业务价值的话，怎么衡量体现它？相应地“进不来、看不见、拿不走”保护似乎也有业务价值。
第二个问题是关于风险评估范围的，风险评估给组织做了个体检，领导很重视，改造了，评估现在很健康了，但还是出了事，可能是风险评估范围没覆盖到，可能是机制在执行落地时出了问题，评估良好的环节出了错，这个怎么解？
A：“进不来、看不见、拿不走”毫无疑问肯定是有业务价值的，而且安全在传统system event和operational risk中有举足轻重的作用。具体的风险环境不同，可能业务的感受也不同。许可证这个确实可大可小，软件下架，法律诉讼都是常见的，具体可以参考一下我提到的那个wiki词条哈。至于客户沟通这块，也得看行业，比如投行就对这块非常谨慎的，也举了jp morgan的具体例子了。
至于怎么输出“进不来、看不见、拿不走”等传统基础设施安全的业务价值？这个问题问得太好了。这方面其实群里很多大佬都有很精彩的分享，我确实不适合班门弄斧哈。个人看到传统安全上确实越来越不好“讲故事”了，system（business）unavailable和data breach讲得有点多，确实没有兴奋点了。如果是强监管，regulatory breach可以拿来讲。“进不来看不见拿不走”我们都知道重要，但是可能跟业务阐述的时候，得加点其他“调料”。确实看到很多CISO会拿data privacy，geopolitical这些话题来提高曝光度。
Q12：风险容量和风险偏好这2个概念之间的区别之前还真没有注意区分过，不过风险容量这个的值大部分公司取的应该也是合法合规，而不是更高一级的安全可控吧？
A：risk capacity其实这也只是概念问题，其本质也就是在具体做风险偏好评估，风险接受处理的时候，真正考虑风险事件本身企业是否能够承受。比如log4j，可能有些业务真的硬着头皮不下线不修复，那么其中的后果，业务是否能够接受，需要阐明清楚。
Q13：我想请教下，你们是怎么开展开源软件的安全风险评估的，对业务出现什么样的影响就必须处理，或者你们的处理标准大概是什么样的？
A：感谢彭总的提问，开源软件目前我们看到的主要还是cybersecurity和legal两块的risk，至于控制阈值，安全的粗略可以根据cvss来定，当然现在比较时髦的是有一个cyber quantification的概念，把cvss和业务影响，控制等因素结合起来做阈值。至于legal方面，最好跟法务部门一并评估。有一些开源软件是不能二次开发不能作为商业用途的。
A：https://managingrisktogether.orx.org/operational-risk-taxonomy是一个很好的starting point，但是一定要结合业务和行业做细分，金融行业本身风险部门就比较完善，可以跟风险部门多沟通，一般都能看到安全部门能配合风险部门做更多的事情。
Q15：风险偏好和风险容量这里是不是涉及一个度量标准问题？当风险管理建设统一的出口和分级分类管理时，那么如何处理多部门多业务间达成一致的标准？风险场景复杂化与落地标准简单易行的冲突如何平衡，想问下这里有什么建议吗？
A：大道至简，最好先从集团层面定下来几个普适性比较强的指标（业务收入，客户，监管等），复杂的风险问题，由具体的业务专家进行分析，在落到普适性标准下面去进行分级。这个问题确实比较大，有需要可以私下详细聊一下。
Q16：信息安全管理和科技风险管理工作差异在哪里，如何考虑合并或分开管理？
A：个人经验上，我看到在企业中，各部门更像是冲刷平原，而不是一个个房子。部门的工作职责更多是由能力圈决定的。信息安全风险在学术上可能更多归于科技风险或操作风险。但是我看到的趋势是，在很多企业，信息安全部掌握着最多的科技管理能力，只能说信息安全的能力圈是有做大的潜力的，但是是否合并或者分开管理，得看企业具体实践了。
Q17：科技风险事件的损失计量有成熟的模型和方法吗？
A：科技风险事件其实还应该在企业风险管理的大框架上去计量，这个我记得《银行业金融机构-信息科技风险监管研究》这本书有风险计量的方法，可以参考一下。至于在cyber领域，有cyber risk quantification这个概念。
Q18：在等保测评中，如果测评机构对90%的检测率不认可，怎么办？
A：这个如果监管或者评测机构的指标，就不是可以商量的风险指标了。
Q19：我们现在还是要求以告警的维度进行管理的，是否合理的？感觉有点浪费人力物力？
A：这个问题不太好回答啊，因为需要结合具体企业文化和企业风险环境去评估。您提到的是监管告警吗？这个维度其实也算常见呀。
-----------------------------------------------------------------
原文始发于微信公众号（君哥的体历）：姚志平：浅谈风险管理视角的信息安全工作
评论