前情提要

甲方安全之企业安全自动化工具SeMF分享

甲方安全系列之SeMF平台笔记(一)：改版说明

甲方安全系列之SeMF平台笔记(二):  基础数据管理篇

前言

上次说持续更新,但是鸽了很久, 这里郑重声明,不是我懒,只是看了看阅读量和评论, 没啥动力. 听说最近FB出了新活动, 赶紧把留存的草稿整理整理, 毕竟奖励看起来还是很香的.

天下熙熙皆为利来，天下攘攘皆为利往。       ——《六韬引谚》

风险定义

风险其实是一个很大的概念,但是找不到其他合适的词, 我们暂且用这个吧.

作为一个一直混迹于甲方的安全从业者, 待过不同的企业, 接触不同的安全团队, 先后体验了 四五个人的安全小组,一个人的安全部, 以及上百人的安全团队. 上经历了各种安全意义上的从0-1 ,以及从1-∞的安全演进历程,  当然无论在哪家公司, 安全部永远是风险导向的。目前遇到的风险归并下来, 主要分为三类:

• 安全技术风险:  以防范不法用户恶意攻击为目的 , 也就是我们常说的 安全漏洞
• 安全管理风险:  以满足企业自身安全需求为目的 , 比如内部员工防泄密等等
• 安全合规风险:  以满足监管要求或免责为目的, 原则上最要命的风险,但~~~~~

其实无论是哪类风险，作为安全人员，我们的核心任务，其实是通过各种方式来闭环他们

风险周期

考过安全类证书或者体系的同行或多或少都了解风险的生命周期， 从风险识别，到风险评估，再到风险应对以及最后的持续监控与优化，就普遍意义而言，四个阶段各有侧重，也相互关联，这里做个简单的科普， 更多的信息，请自行查询

• 风险识别的阶段： 是很重要也是很基础的阶段，这一阶段可以大致明确安全团队的侧重及核心方向， 但是大多数企业在安全团队创建之初， 会直接跳过这一阶段， 依赖安全人员的经验，开启后续的阶段， 虽然最终的结果大概率一致， 但是更多情况下，会出现风险治理不完整，或者任务返工的问题。
• 风险评估 和 风险应对 拆分为两个阶段， 但是在常规的风险治理过程中， 大概率会合并在一起并行， 而且这两个是最能提现安全价值 也是 最能考验安全从业者基本功的阶段。 对于很多安全人员来讲， 这就是工作的全部
• 持续监控与优化：这一阶段对于很多甲方而言，其实是比较遥远的， 目前了解到。只有一些财力雄厚或者安全团队较大的 公司才能落地。 虽然也有不少公司在考虑监控之类的， 但是最终落地的时候， 仍然围绕评估和应对。 并不属于严格意义上的持续监控与优化。

生命周期的划分， 并不意味这我们在落地时也需要完整照搬，各企业的情况不同，需求也不一样， 我们需要根据其生命周期， 建设有企业特色的安全风险生命周期管理。

风险治理

风险的治理说简单也简单，说复杂也复杂，可以划分为三类，但是主流的落地方式只有两种

• 单个风险场景的全量治理覆盖
• 单个资产主体的全量风险治理覆盖
• 全量风险场景的全量资产治理覆盖 （太过理想化，暂不考虑， 有实现的大佬或者公司， 请带带我）

在我任职的所有公司中，主要聚焦于 单个风险场景的全量覆盖， 由此延伸出对应的各种能力或者服务， 比如说sdl、渗透测试、合规评估 以及 常见的各种专项（治理专项，漏洞修复专项）等等。  当然，也有人说，自己的能力可不是发现一个风险就终止的， 应该不能这么分类的，这里请区分， 风险场景的和风险。

单个资产主体的全量风险覆盖； 也就是针对既定目标， 整合各个风险场景的方案，明确出要治理的内容，治理的途径、以及最后持续或周期的跟进。 这里就会有人说了， 既然能实现到这一步，为什么不是直接到下一阶段呢。 在较大安全团队待过的应该能理解，虽然公司内部各个风险场景都有闭环， 且能力都达标 ，但是在具体执行或者服务时， 单一的系统治理支持， 会演变成多个安全子团队之间协同处置，  组建一个大型的项目进行处理。   巨大的成本，完成全量覆盖根本不太现实。

安全团队小的时候，只能覆盖固定风险场景，指定达不到； 安全团队大的时候， 各安全能力可覆盖全量场景，但是各安全团队各自为战， 最终也会导致安全和业务形成 N:N的管理关系， 且不说安全侧作为职能部门 能不能付出这么大的成本， 一个业务经过N次整改，安全团队居然还说不达标， 业务侧反弹根本控制不住。当然， 想要达到理想状态下的风险治理模式， 也不是完全没有落地方案， 比如我们可以通过创建业务与安全中继来完成，类似有些公司，使用安全BP模式， 也有些公司，建立安全运营中心来解决， 最终使安全和业务侧形成一种 N:1:N的模式，插件安全建设及业务安全服务支持。

基础需求

说了那么多，似乎扯远了，正如我开头说的， 风险是一个很大的概念，风险治理也是，在具体落地过程中，企业是需要大量的安全从业者来实施。  在最开设计SeMF的时候， 我其实是想通过一个平台，来完成全量风险治理的落地，让风险治理脱离对安全人员的依赖， 但是随着不断的踩坑，最终不得不承认， 再好的工具，也只能提供辅助， 无法完全脱离安全从业者而存在。

SeMF平台的设计思路也有所转变， 从一开始的大而全的愿景，到现在具象化的功能模块， 通过抽象共性需求，提供一套完整的风险治理基础框架， 可以辅助安全从业者，最小成本搭建适用于自己企业的安全运营平台。 需求拆解后，可以归并以下几点：

• 属性支持：  平台能够支撑不同类型、不同级别、不同状态的风险的自定义
• 流程支持：  平台能够支撑不同发展阶段，对不同场景下风险处置流程的自定义
• 闭环支持：  平台能够在最小成本的完成业务与安全的交互

平台实现

SeMF平台在设计之初，其实主要是面向中小型公司或安全团队提供基础运营支撑的，所以其功能的落地点，也是围绕在 提供风险治理的基础支撑下。

上面说的风险三大类， 其实包含了很多子风险，在实际运营过程中，安全侧其实是有诉求进行集中归并和整理记录的， 为了保证我们的风险可以很好的区分， 提供了配置化管理的模块， 可以针对风险的分类，分级、来源、状态等信息进行配置化管理，确保能够针对各种风险进行有效的扩展。

针对风险的处置， 我们其实是需要一整套的完整的跟进机制的， 其实无论是 excel，jira或者一些其他的工具，都可以落地， 但是当风险的量级超过一定的程度， 就需要一套完整的机制，来确保每个风险都能完成闭环。这时我们就需要一套相对固定的流程来辅助。  可是在不同企业，或者在同一企业的不同发展阶段，针对风险的闭环流程不完全一致， 甚至在同一阶段针对不同风险的闭环也有不同的需求， 那么我们就需要一个相对灵活的工具来辅助实现， 比如，一个可配置化的风险闭环流程。

风险细化了， 处置流程也满足需求了， 那么接下来是风险的分发， 除了excel外，大多数的风险管理工具， 平台本身针对风险进行了有效的管理， 包括一些变更记录，大部分的漏洞管理平台或者工具基本上都能实现。

有权限的可以在平台上处置，那么没权限的呢， 正常的业务场景下， 其实是需要多个业务同学协作处理，频繁的权限变更，附带的管理成本，小型的运营团队是无法完成支持的。  这个时候一个可随时关闭的共享链接其实是一个很好的方案， 不用考虑授权的问题， 业务没账号也可以按照流程完成交互。当然，这里需要注意的是， 用户允许的操作，是流程所允许的。 所有的临时授权，都可以及时回收。

到这里似乎结束了，但是又没结束，这篇文章草稿写完的时候， 其实是想删了重写的，前半部分和后半部分完全不是一个层次的东西，但是想了很久，最终保留下来， 工具或者平台只是提供一种途径，来辅助完成任务。你知道的 和 你能完成的并不冲突，

这篇文章可以当两篇看， 第一篇：我眼中的风险，  第二篇：我对风险治理平台的需求，或者我怎么实现，当然各位大佬有建议，欢迎私聊或评论。