漏洞管理电子流

smarttang 2015-09-18 12:54:00

0x01 写在前面


这篇文章主要是为了分享和记录自己的一些成长,如有写得不好的地方,还望斧正。在最早期针对漏洞管理这个事情,个人觉得比较恶心。特别是各种邮件发来发去,到最后追溯到某个系统曾经出现的安全风险时,一顿猛翻,甚至连源邮件出处都找不到…然后就有了这篇文章。

0x02 原来的方式


原来的方式比较蛋疼的是,这里面有很多各种各样的问题,各种各样的拖延,例如:研发会质问,这个漏洞严重吗,为啥要马上修复?又比如:这个漏洞是正常逻辑,需要修改还要过产品那边,又或者这个漏洞看不懂啥的,又比如你提供的信息不够全面等等。因为这些问题导致修复一个漏洞需要2-3天,甚至更长的时间。

然而对于我们来说,这是0容忍的。所以我们需要推动,浪费很多口水跟这些人解释,如果title比较高的情况下,可能比较好操作,如果只是最基层,可能就….而且还有一个问题,不知道其他的小伙伴有没有遇到过,就是突然某天你所管辖的系统被人爆了,然后莫名其妙的可能存在很多未知的风险,再然后就是领导找你谈话,问你这个系统曾经出现过哪些风险,还有记录么?….然后,你就说,都有邮件…然后领导说:你搞下,把这些东西整理出来…然后:xx^&*($%^&

0x03 改善


在发现这个问题以后,我试图改变这个现状,从沟通需求开始、去咨询研发、还有我们需要服务的部门,到底怎样做才能做到最好。逐步,我开始设计一个自动化的方式来提高整体的效率,包括流程的问题。我初步认为,这个流程不需要太复杂,并且我认为这个跟快递管理的理念是一致的『使命必达』。说干就干,梳理下我认为比较达标的方式:

想到达到这个目标不是一般的难,起码中间扯皮是比较麻烦的事情,但是如果我们能把这个东西做出来,也是一种成就。

0x04 撸成代码


既然我们知道了目标就可以开始试图模拟这种场景来实现这个效果。当然,前题你需要得到上面的支持,非常荣幸,在坚持自己见解后,得到了最大力度的支持。

我的设计如下:

  1. 发现漏洞,上报漏洞(通过安全平台发起=>研发收到该漏洞信息邮件)他可以通过登录平台查看详细信息,或者通过邮件了解该漏洞的细节。在确认知悉后,点击『已知悉』会通过该方式对安全平台的API进行一次请求,并且更新当前该漏洞的处理状态。(安全提交=>平台发送=>研发收)

  2. 在点击『已知悉』后,研发再次收到平台发起的一个电子流,提示该漏洞执行中的流程,在修复完成后,研发再次进行下一步操作。(平台发=>研发收)

  3. 在确认漏洞已修复的时候,通过点击『已修复』进入漏洞的复检流程。(平台发=>研发收)

  4. 在确认漏洞已经修复完成后,安全人员针对漏洞进行复查,灰度测试环境上线。(平台发=>安全收)在这里,安全人员有两个选择,一个是『确认修复』、一个是『漏洞打回』由于有的时候漏洞有可能修复不全面,导致可以二次利用。所以有可能漏洞会被打回。(平台发=>安全收)

  5. 在漏洞测试完成后后,研发或运维会根据实际情况,对代码进行完整的同步。在全部完成后,点击『已同步环境』则漏洞修复流程结束。(平台发=>研发/运维收)

整个过程通过电子流的方式实现,同样使用了邮件的方式,但是可以明显看出来整个漏洞的处理过程非常清晰、直观。同时,妈妈再也不担心漏洞的历史无法追溯了。有了数据,随时可查。可视化管理~

展示下平台的漏洞管理是啥样的。

0x05 需要注意


  1. token的时效问题:首先,你是通过邮件的方式发出、发入,势必会有时效的问题产出,你需要将token设置在合理的范围时间,这个根据你的实际情况来定,我预设的是在1天内token有效。
  2. 风险描述问题:以上的描述和实际使用的版本有些不同,毕竟有保密的需求,这个东西需要你跟研发、运维、还有你们自己的大哥沟通清楚,了解清楚怎么做才是最合理的。
  3. 在风险处理时间上,在系统上最好做个关联,例如该类风险超过一定时间没有修复,提前多久给研发发提醒,毕竟有的时候可能会忘记,最好就是有一定的提醒功能,这样会更加友好。(我还是挺关注用户体验的)

0x06 送个漫画

评论

W

wefgod 2015-09-18 12:57:41

运营商需要有具体的工单的,而不是只靠邮件往来。

小饼仔 2015-09-18 15:05:26

突然想起了 '发单小王子' 这个词····

X

xsser 2015-09-18 15:25:29

很有实际意义啊

L

lietolee 2015-09-18 16:38:36

楼主关于研发效率的问题可以引入sla要求,并且对问题单进行闭环处理。
而且看你的描述 安全和产品对漏洞的处理比较分离。比如具体的修复方法是否有效等,缺乏安全方面的支撑,修复后重新验证的方式效率略低。 你还可以引入漏洞预警,对于一段时期或者特殊漏洞的问题进行预警。
还有建议你们的系统中增加关于漏洞问题的详细技术分析, 原因,影响,解决方法,处理时间等,以备后期查验和参考。
仅供参考。

S

smarttang 2015-09-19 13:50:56

@哮喘 嘿嘿~

S

smarttang 2015-09-19 13:55:05

@lietolee 具体的情况具体分析,按照目前的方式来看,我们推崇统一框架处理,在一定的情况下,我们要求统一输入输出,标准化。至于漏洞预警这块,这个系统本身就集成这个功能,只是目前还不完善,所以暂时没启用。我主要分三中漏洞方向:内部漏洞、外部漏洞、通用型漏洞。基本上你说的我都涵盖了。我们在解决方法、处理时间、还有技术分析、截图这块,基本上全部都是有的。只是截图没有截全。。。。我们自己培养的实习生,定期都会对漏洞进行完整的review、学习。

S

smarttang 2015-09-19 13:55:40

@xsser 谢谢哈~ 我一直在折腾这些玩意。哈哈~

S

smarttang 2015-09-19 13:57:41

@whoda 据说rapid7 有漏洞管理的东西,但是我目前看到的貌似都不太符合国情,要么就是跟企业不匹配。。后期我准备把大的东西做完以后再开源一起玩。。。目前就不放出来让别人打我脸了。。。毕竟是有点挫。。。

S

smarttang 2015-09-19 13:59:11

@test 您说的是CMDB把。。相对来说我们跟运维系统应该是独立存在的,正如运维和安全职责分离一样。当然,我们会提供非常完善的API供给CMDB进行资产关联,这点应该是妥妥的。

S

smarttang 2015-09-19 14:00:00

@wefgod 在写的时候只考虑到了甲方(互联网公司)。。。没有考虑那么深入。。。

S

smarttang 2015-09-19 15:00:55

@hellox 恩。但是大部分情况下,我们都是需要走流程化的思路的,不然每个问题都发个邮件啥的,连事后追踪都搞不定。常常因为这些个问题,最后连验收都没人验收。。

P

px1624 2015-09-20 20:39:47

要是企业用了这种系统,的确蛮好的,不过会不会被爆菊?

S

smarttang 2015-09-21 10:22:16

@px1624 应该不会吧。。。- - #

B

BMa 2015-09-22 15:26:53

@smarttang 其实这个把src 与 jira结合,可以很大程度上解决这个问题

S

smarttang 2015-09-23 15:17:00

@BMa 嗯嗯~但是更多是内部的回溯用,这个相对来说会比较全面一些。

S

smarttang

乌云两个帐号都是我的... t.qq.com/mojige123

twitter weibo github wechat

随机分类

神器分享 文章:71 篇
memcache安全 文章:1 篇
区块链 文章:2 篇
IoT安全 文章:29 篇
Ruby安全 文章:2 篇

扫码关注公众号

WeChat Offical Account QRCode

最新评论

Yukong

🐮皮

H

HHHeey

好的,谢谢师傅的解答

Article_kelp

a类中的变量secret_class_var = "secret"是在merge

H

HHHeey

secret_var = 1 def test(): pass

H

hgsmonkey

tql!!!

目录