ISO/IEC 27001 第八章 运行

----写在前面的话----

回来了，继续更新“运行”章节的内容。

安全团队的同事被毕业的越来越多，小木作为安全团队“硕果仅存”的安全管理者还在勉励支撑着信息安全架子不倒，每天和产品经理、项目经理、研发、运维有开不完的会、吵不完的架，聊不完的天。我其实一直在思考，究竟如何证明信息安全体系在正常运行，我每天忙到飞起，能证明体系在运行吗？答案是否定的，体系是否运行不取决于信息安全团队的人数，也不取决于996或者007,取决于是否有多少“过程”能够产出信息安全的内容。

ISO/IEC都是在“过程”或者“过程方法”的基础上讨论如何开展相关管理体系工作，只有过程运行后体系才能运行，有体系才有信息安全管理生存的土壤。

----8 运行 ----

标准原文：

组织应规划、实施和控制满足信息安全要求所需的过程，并实施6.1中确定的措施。组织还应实施这些规划来实现6.2所确定的信息安全目标。

组织应保持文件记录信息达到必要的程度：有信心证明过程是按计划进行的。

组织应控制计划了的变更、评审非预期变更的后果，必要时采取措施减缓负面影响。

组织应确保外包的过程已确定，并处于可控状态。

标准的第一段话写的很清楚，组织需要通过建立过程来实现信息安全目标，什么是过程？引用过程的定义“一组将输入转化为输出的相互关联或相互作用的活动”。不论是安全需求、要求还是原则，如果这些仅仅是某些人或者某些团队的单向输出，那必然不是体系化运行的表现。

例子一：产品团队合并代码到Master分支触发了SAST的CI，SAST的扫描结果同步至安全团队SAST后端服务，由信息安全团队指导对代码缺陷进行修复，修复之后重新触发CI。

例子二：产品的功能迭代并要上线一个重要的功能模块，并正常进行安全提测，安全团队在进行渗透测试时发现了越权漏洞，向产品团队进行正常反馈，产品团队进行漏洞修复后进行回归测试。

例子三：产品在进行需求评审时，安全团队对账户管理模块的功能进行了评审，提出了以RBAC为理念的鉴权思路，并对接口鉴权JWT框架提出了安全需求替代原有的session鉴权。

以上这三个场景是代表SDL流程的不同阶段，但这三个例子不是“过程”，是“过程”里的具体活动。当然，过程是由若干个活动组成，SDL也是由软件开发生命周期的不同安全活动组成。

但是，信息安全管理者一定不能局限在活动中，一定要跳出活动去看整体的过程，要用过程思维去俯瞰整体。这里，我想到了管理体系书籍中所提到的“过程方法”，什么是“过程方法”？ 将过程视为资源去进行管理，核心是“将组织相关的活动和资源作为相互关联的过程所组成的体系来进行系统的理解和管理，从而更高效地得到期望的结果”

例子一：是不是所有代码的合并都需要触发SAST的CI，有多少业务合并没有触发CI？产生的结果哪些已修复，哪些未修复，修复率是多少？

例子二：越权漏洞很难被SAST发现，如果检测出SQL注入，为什么SAST没检测出来，是不是SAST结果审核所遗漏或压根没发现？

例子三：JWT这套鉴权框架有什么安全隐患？在之后的评审中能否有更为有效的鉴权框架的推荐？

以上只是抛砖引玉，作为信息安全管理者，不应过度关注活动本身而是活动的输入与输出，能否依据输入与输出优化过程本身，从而提升企业风险管理的效率。比如，以上例子SDL流程，缺少了对线上业务变更的所带来的风险，这是一个管理过程活动的缺失。作为信息安全管理者，应当考虑如何补足这个活动的缺失，审视周围的人力、财务、技术资源，想办法提出方案进行过程补全。

如果信息安全不懂技术，以上所有都无从谈起。无论何时何地，信息安全的技术储备永远是核心竞争力。

----写在后面的话----

如果没有“过程”与“活动”的土壤，信息安全体系就只能停留在文件上，无论买多少设备、无论投入多少人力，信息安全体系就是一句空话。是不是很严重？是不是很可怕？

真相很扎心，对于国内绝大多数企业来说无所谓。所谓的监管驱动，养几个渗透测试人员（没有看轻渗透人员的意思），做几套大而美制度就够用了。

再说一个更扎心的，信息安全体系的过程是建立在软件质量体系过程、软件信息技术管理过程之上，不可能独立于其他体系存在。

信息安全体系运行的好坏，不取决于其本身，但信息安全体系又是监管的重灾区，所以才衍生出文档工程师、安全PPT工程师此类岗位（没有贬低的意思，存在即合理）。

当软件质量体系混乱、信息技术管理混乱、甚至基础设施运维混乱的情况下，信息安全体系目标只能沦为口号，信息安全管理者也就会沦为吉祥物，背锅侠，并且我看不到任何转变的希望。

写到这里，痛心疾首。

但，即便如此，我想借用长安的荔枝中李善德的一句话““就算失败，我也想知道，自己倒在距离终点多远的地方。”

”