给TSRC等甲方平台建设的一些建议

安全
甲方评价平台的价值不应该是收集了多少漏洞,吸引了多少白帽子,发了多少奖品等,而是应该看这个平台给甲方的安全体系建设带来了多少价值。包括:提升自己员工(安全、开发、运维、管理等)的技术技能及安全意识、发现和弥补自身安全流程(如sdl等)的缺陷、改进自身测试工具及流程(如黑、白盒审计工具等)等等。

从7月份加入TSRC平台来,我一直都给TSRC(Tencent Security Response Center)的朋友提了很多的建议,不过我用的方式都比较“极端”,所以给很多人的印象是我是TSRC平台最难缠的!直到最近博客及微博一系列的讨论,我也直接沦落为邪恶的“闹事者”!这个其中可能与甲方强大的“封建残余理论”有直接的关系,不过可能是我们对甲方对安全“进化”要求过高。于是只有采用以前常用的“曝光引发公共关注”的手段来促进发展了!?

我一直认为TSRC这样的平台是有积极意义的,所以把之前的一些建议提一下,希望给后来者得到一些启发。【这些建议可能比较凌乱没有体系!】

首先明确2点:

一、如何评价甲方漏洞平台的价值。

甲方评价平台的价值不应该是收集了多少漏洞,吸引了多少白帽子,发了多少奖品等,而是应该看这个平台给甲方的安全体系建设带来了多少价值。包括:提升自己员工(安全、开发、运维、管理等)的技术技能及安全意识、发现和弥补自身安全流程(如sdl等)的缺陷、改进自身测试工具及流程(如黑、白盒审计工具等)等等。通过平台吸收外界能量,提升本身的能力才是价值的体现。

另外我觉得甲方提升安全的最终目的是为了保证用户的利益安全。也就是最终对象是用户的利益。而对于用户应该不抛弃不放弃,更不应该bs小白用户。恰好我认为保护更多的小白用户的利益才是技术发展的动力。

而这些主题思想关系到整个平台的建设具体的措施的实施。

二、抛弃“封建残余”,真正重视和尊重安全人员。

目前来看,很多的甲方并没有从“敌对”的“封建思想”里走出来,还有很多的残余,漏洞平台是一个甲方和各大外来安全人员的一个互动平台,也就是说参与到这个平台的人就应该受到必须的尊重,然而很多甲方思想还是:“我给你奖金我给你奖品你能不能消停点?”的层次,所以我就在微博说了“GS3我已经砸了!” 虽然这只是个谎话 :)。

尊重是一个持续的过程,可体现在平台与白帽子互动交流的各个细节。当然有改变甲方这样的“根深蒂固”的思想,可能是一个很漫长的过程 ...

一些具体的建议:

1、完善自己的对漏洞的响应、审查、补丁等流程。在TSRC的实践看来,个人感觉TSRC更像是一个“传达室”,每天的工作就是确认下漏洞然后分发给不同的部门开发,进行修补。完全没有体现SDL的精髓,SDL是要求每个流程都需要有安全人员的参与,包括漏洞的确认,危害评估,漏洞影响的范围(如其他的产品线可能有类似的漏洞),给出具体的补丁修补方案及防御措施等等。

2、提高员工自身的能力。包括技术、安全的理解及和白帽子沟通能力等。个人认为身为安全人员都基础不过关,那他指导的安全流程实施本身就是不靠谱的。

3、重视漏洞修补。前面提到的平台价值就涉及到这个问题。很多的白帽子及甲方安全人员迷失在茫茫的“漏洞”里,而不重视甚至不在乎漏洞有没有得到很好的解决。在我报告给tsrc的漏洞里的dom-xss类型的漏洞,除了直接删除漏洞页面代码的修复方案外,其余重补率几乎达100%!有的漏洞甚至补丁次数达到了4-5次!而TSRC的标准本身是不重视漏洞修补复查情况(以前的标准是补丁复查出现的漏洞+1分),当我提出要按新漏洞计算时困难重重,因为他们某些安全人员认为这个不重要!并且说这个平台上就我有那么多问题!那么难缠!这是因为我知道在这样的机制下白帽子认真复查漏洞的基本没有!于是结果就是“漏洞还是那个漏洞!”。 为了证实我的看法,我还去某些平台上公布的腾讯的漏洞,复查一下,补丁随便就bypass了!

4、尊重标准。标准制订了就不能随时修改,即使原标准有缺陷,也要在以白帽子利益优先的基础上承认,并发布新的标准并告示。

5、标准的制订:

当时我给腾讯的建议是采用修正模式。也就是不用单一死板的漏洞类型来评估。对于甲方来说评估一个漏洞应该从多个方面来考虑:

i、 实施攻击的成本。包括漏洞有成熟的利用方式不需要什么门槛就可以实现攻击、漏洞触发的条件等。甚至包括发动攻击的法律风险等。

ii、 一但攻击成功的后果。比如攻击者利用这个漏洞可以取得的权限等等

iii、 这个漏洞的影响范围。比如某些通用的函数里的漏洞,可能覆盖到很多的产品线,很可能导致漏补等情况。

iiii、对技术的尊重及认可。这个主要是体现在有的漏洞通过某些技术完美利用了很难利用的漏洞等

...

应该把以上的一些因素的权重来实现一个修正的评分模式。而甲方不应该只看到漏洞的利用效果来评价。甲方的目的是修补漏洞,变得更加安全,可以更大程度的保护好用户的利益。而不是去变相鼓励渗透入侵。

6、奖励机制

TSRC从7月开始采用月排名的机制进行奖励。可能是考虑到奖品的成本问题,而采用这个方式。但是这个方式存在很大的问题,也就是越到后面排名,越不公平。我想很多白帽子意识到这个问题。所以为了弥补这些缺陷,腾讯采用了一些其他的奖励措施。比如直接给高危漏洞单独发放ipad等,但这个方式是才完全从漏洞利用来评价的!可能导致的后果就是,任何一个有可能得到shell的漏洞类型,白帽子都可能去尝试一下,这也是上面提到的“变相鼓励渗透入侵”的理由。还有一个措施就是把客服端、在线安全及移动客服端安全分开。而对于客服端领域因为参与的人少,直接不用费力就可以得大奖。这样导致的成本也就不断的提高,可能换个更公平的方案的成本可能差不多。

个人建议可以取消排名机制,白帽子根据提交的漏洞累计积分。然后根据积分发放对应的奖品。至于这个方案的成本和上面方案的成本比较,要看甲方自己去调查分析了。

7、加强和白帽子的交流合作。这个上面也有提到。在tsrc里看到的白帽子就提交漏洞就ok了。应该让白帽子参与到漏洞原理分析,触发提交,并可以提出修补的建议,补丁的确认等流程里。这个也是提醒尊重白帽子的主要途径。

8、加强平台建设

这个比较具体的漏洞平台的设计的一些细节。比如给白帽子提供更多的关于漏洞的细节,如触发的环境条件的描叙(操作系统、浏览器及版本、触发的错误信息等)这样可以尽可能的减少漏洞重现分析、甚至补丁等的成本。 还如完善交流的机制,减少和白帽子沟通成本等等。

最后,希望以上的一些建议,对于甲方的平台建设起点作用!更加希望各大甲方重视自己的安全,希望不是“皇帝不急、太监急!”(虽然我不是东方不败)!

update:

其实还忘记一点就是刷分问题,对于本身基础底子不够的甲方,刷分是不可避免的!恰好相反刷分可以加强巩固技术安全,弥补一些基础不足。也就是文章里“如何评价甲方漏洞平台的价值” 的方式来评价的!!

责任编辑:蓝雨泪 来源: 百度空间
相关推荐

2017-11-29 18:52:13

Python新手编码建议

2023-11-10 08:48:09

Lombok库Java8

2016-11-11 20:33:53

Hadoop大数据云计算

2018-06-21 15:23:36

2009-12-30 15:18:32

2019-11-19 09:06:32

网络安全网络攻击安全威胁

2020-09-21 06:58:56

TS 代码建议

2012-11-09 10:46:24

Canonical

2018-11-20 14:24:46

数据分析数据库统计

2011-11-30 15:57:18

2015-08-26 09:31:26

程序员建议

2011-04-27 09:21:09

程序员

2015-08-26 08:31:35

核心程序员成长

2015-11-24 10:13:49

应聘大数据校园

2013-12-03 10:30:28

iOS开发程序员自我提升

2009-06-30 20:44:44

2021-09-27 10:04:03

Go程序处理

2009-03-13 09:31:03

.NET整合分布式应用

2010-03-01 10:25:51

J2EE

2021-09-27 15:33:48

Go 开发技术
点赞
收藏

51CTO技术栈公众号