甲方安全系列之SeMF平台笔记:风险管理篇

admin 2023年5月20日01:39:06评论24 views字数 2989阅读9分57秒阅读模式

甲方安全系列之SeMF平台笔记:风险管理篇


前言


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


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


风险定义


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


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


安全技术风险:  以防范不法用户恶意攻击为目的 , 也就是我们常说的 安全漏洞

安全管理风险:  以满足企业自身安全需求为目的 , 比如内部员工防泄密等等

安全合规风险:  以满足监管要求或免责为目的, 原则上最要命的风险,但~~~~~


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


风险周期


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


风险识别的阶段:是很重要也是很基础的阶段,这一阶段可以大致明确安全团队的侧重及核心方向, 但是大多数企业在安全团队创建之初, 会直接跳过这一阶段, 依赖安全人员的经验,开启后续的阶段, 虽然最终的结果大概率一致, 但是更多情况下,会出现风险治理不完整,或者任务返工的问题。

风险评估和风险应对:拆分为两个阶段, 但是在常规的风险治理过程中, 大概率会合并在一起并行, 而且这两个是最能提现安全价值 也是 最能考验安全从业者基本功的阶段。对于很多安全人员来讲, 这就是工作的全部

持续监控与优化:这一阶段对于很多甲方而言,其实是比较遥远的, 目前了解到。只有一些财力雄厚或者安全团队较大的 公司才能落地。虽然也有不少公司在考虑监控之类的, 但是最终落地的时候, 仍然围绕评估和应对。并不属于严格意义上的持续监控与优化。


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


风险治理


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


  • 单个风险场景的全量治理覆盖

  • 单个资产主体的全量风险治理覆盖

  • 全量风险场景的全量资产治理覆盖 (太过理想化,暂不考虑, 有实现的大佬或者公司, 请带带我)


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


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


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


基础需求


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


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


  • 属性支持:  平台能够支撑不同类型、不同级别、不同状态的风险的自定义

  • 流程支持:  平台能够支撑不同发展阶段,对不同场景下风险处置流程的自定义

  • 闭环支持:  平台能够在最小成本的完成业务与安全的交互


平台实现


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


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


甲方安全系列之SeMF平台笔记:风险管理篇


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


甲方安全系列之SeMF平台笔记:风险管理篇


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


甲方安全系列之SeMF平台笔记:风险管理篇


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


甲方安全系列之SeMF平台笔记:风险管理篇


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


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


甲方安全系列之SeMF平台笔记:风险管理篇


甲方安全系列之SeMF平台笔记:风险管理篇


甲方安全系列之SeMF平台笔记:风险管理篇

甲方安全系列之SeMF平台笔记:风险管理篇

甲方安全系列之SeMF平台笔记:风险管理篇

甲方安全系列之SeMF平台笔记:风险管理篇

原文始发于微信公众号(FreeBuf):甲方安全系列之SeMF平台笔记:风险管理篇

  • 我的微信
  • 微信扫一扫
  • weinxin
  • 我的微信公众号
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2023年5月20日01:39:06
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   甲方安全系列之SeMF平台笔记:风险管理篇http://cn-sec.com/archives/1748198.html

发表评论

匿名网友 填写信息