freeBuf
主站

分类

漏洞 工具 极客 Web安全 系统安全 网络安全 无线安全 设备/客户端安全 数据安全 安全管理 企业安全 工控安全

特色

头条 人物志 活动 视频 观点 招聘 报告 资讯 区块链安全 标准与合规 容器安全 公开课

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

甲方安全建设——SDL团队管理章程与SDL从业者自我修养
2023-05-07 23:12:31
所属地 浙江省

0x01 前言

这篇文章既是写给甲方SDL团队管理者,也是写给所有甲方SDL从业者。

打铁还需自身硬,想要在企业中将安全建设好,首先要从安全团队内部出发。一个有战斗力的安全团队,是一切的基础。

笔者刚刚负责SDL团队的时候,经历过很多管理上的问题。刚开始带团队时,会感到对比单兵作战时压力大了很多倍。很多事情会让人感觉,失去了对以往工作内容和技术本身的掌控感。假设你有比较强烈的责任感,就会发现很多人并不会按照你的意愿行事,你希望所有人都能够跟你一样有责任心、做事认真,但现实与我们的期望往往大相径庭。

追根溯源,这里有工作认知和观念的问题,也有工作方法的问题。尤其对于刚刚从乙方进入甲方工作的白帽子们,开始时很难适应和转变工作思路,容易按照过去在乙方工作形成的惯性向前走。而甲方的安全工作重点和乙方实际上有非常大的差别。

为了理清和改善团队里的具体问题,帮助大家提升对甲方安全工作的理解,我们在内部制定了一个SDL团队章程,帮助团队成员更好的成长,并且帮助团队更好的运作和管理。

本次分享出来,希望帮助初入甲方的SDL从业人员,更好的认识自己的工作,同时希望能够帮助更多的甲方SDL团队,提升团队战斗力。如果你的SDL团队刚刚建立,或者你觉得在团队管理上存在一大堆问题,那么你可以考虑参考这篇文章制定一个团队的章程。

我会尽量在每一项的注解中解释问题和背景,可以对照看看你或者你的团队是否也存在一些类似的问题,也许你能够在里面找到些共鸣。如果一个都没有,那么恭喜你,你可能处在一个非常优秀的SDL团队中。


0x02 SDL团队管理章程

一、目的(我们为什么存在?)

使命:支撑保障业务、亿万IoT设备、用户的安全!
提升安全建设水位,寻找并利用各种方法手段,最大程度为业务降低安全风险,保障业务健康发展。

注解:
对于一个团队来讲,应该要有一个共同的使命,明确团队目标和使命,驱动大家向一个目标前进,也是我们所有工作的意义所在。
使命要结合公司的业务,你的公司为谁服务,有哪些产品,公司做安全的意义是什么?

二、行为守则

没有条条框框,但有原则。以下行为原则及产出结果是评判绩效的重要参考依据。

注解:
行为守则是为了帮助大家判断工作中的原则,什么样的行为习惯是团队里鼓励的,什么样的行为习惯是团队里不鼓励的。主要在于工作观念,方式方法的引导。里面其实涉及了一点价值观层面的东西。现在感觉有个不大好的风气,谈“价值观”色变,企业不好意思讲,员工觉得“你是不是在pua我”,普遍觉得虚,我一直认为价值观不论是对于个人成长,和团队战斗力来讲,都有关键性的作用(个人观点)。当然好的工作和管理方法,也可以引导团队健康良性发展。好的价值观是先天条件,好的管理方法是后天努力。

通常有一定规模的甲方才会建立自己的安全团队,而这类甲方企业通常都会有KPI、OKR之类的绩效管理手段,而一旦有绩效管理,那么必然会出现公司划给团队的蛋糕有限,应该怎么分的问题。

由于每个人的经历不同,性格不同,对于专业能力成长所处的阶段也不同,所以对自我的评价不可避免会出现认知偏差。人们往往会高估自己的能力,认为自己是高于平均水平的,能力越差的人,越容易对自己产生过高的评价,产生“达克效应”。当然也有人会低估自己。


当我们在对团队成员做绩效评价时,是综合考虑所有人的工作表现和产出进行对比的,所以很可能出现一种情况,你给出的绩效评价结果低于对方的预期,原本对方在自己的认知里自我评价是非常高的,可能高于团队里的大部分人,但是他实际上可能并不清楚怎样的工作表现和结果是更好的,也不完全清楚其他人做了什么,平时的工作表现如何,完成质量如何,难以客观评价自己也无法客观评价他人。这是由于信息不对称造成的正常现象。所以我们要尽量有一个共同认可的标准原则,能够帮助大家对比复盘改进,提供指导,并且基于这个标准对自己的工作和他人的工作产生更加清晰的认知。明白为什么有的人能够拿更好的绩效,有的人拿比较差的绩效,自己如何改进提升能够做到更好。

(这里只是基于公司既定的KPI或OKR管理规则进行讨论,每个公司落地实行KPI、OKR的情况好坏不同。以上仅供参考,不代表笔者认可所有的绩效管理制度。)


哪些行为是我们鼓励的?

1、有责任感,自驱主动,关键时刻,能主动承担责任,为公司解决问题,为团队分担压力。

注解:做为安全从业人员,责任感是一切的前提。安全团队是公司安全的最后一道防线,如果没有责任感,谈何保护好企业和用户信息安全?

2、对发现的安全问题,深究本质,深入沟通,深入了解业务环节中各依赖方之间的处理逻辑,能够最大范围解决同类安全问题。解决方式有时有很多,可以在技术架构层面给出方案并推动,也可以在管理层面,给出可落地的方案,推动实施。

注解:在做白帽子(漏洞挖掘机)或者在乙方工作的时候,很少会涉及完整的安全方案,通常都是发现一个漏洞解决一个漏洞,绝大多数情况在漏洞的修复建议里写的都是“一句话建议”,好一点的可能从通用安全方案模板中粘贴上一大段安全实现Demo代码。初入甲方的同学,在推动业务解决安全漏洞时很容易按照过去的惯性行事。比如有的人,漏洞直接丢给开发,让开发自己去理解漏洞,自己想办法修,修完我再来验证你有没有修好;好一点的,会给个一句话的修复建议,但是这个建议既没有具体的方法,也没有考虑实际的业务情况,最后没办法落地。开发即使参考了这个一句话的建议,也是基于自己对安全有限的理解,搜索到一些质量参差不齐的参考资料,去修漏洞,修完之后复测再被绕过,如此反复,浪费大量的时间资源;更好一点的,修复建议稍微详细了一点,甚至还有参考文章的连接,修复代码Demo,但是由于没有耐心,进一步跟开发沟通去理解清楚整个业务逻辑、实际实现和应用之间的调用链路,可能依然不好落地,最终开发只能凭借你给的资料,结合自己的理解修复漏洞。这是在安全方案层面。 
在具体的漏洞修复推动层面,大部分同学可能发现一个漏洞,推动解决一个漏洞,到这里就结束了。不是说这样不好,能够完完整整的把一个漏洞从发现到修复的闭环跟进完成,已经算很好的了。
但在甲方,你其实可以做得更好。比如发现一个漏洞,你能不能深入业务,深究本质,从根源上给出完整方案,由点及面最大范围解决同类风险?有的漏洞业务方自己修只解决了这个单点风险。但是应用依赖的上下游链路里,是不是有更好的节点可以通过改造去修复漏洞,从根源上给出完整方案把问题解决,很有可能一口气就解决了几十几百个潜在的同类漏洞和风险。
有些常见的风险无法通过纯技术手段解决,是不是可以思考和设计一下如何优化现有的流程,在整体研发流程的某个环节中,解决这类风险?如果你能主导并且推动落地,就更完美了。

3、对漏洞,能够指导开发修复,针对业务具体情况,深入理解业务,给予完整详尽的安全方案。

注解:做到第2条其实不太容易,除了工作方法,对待问题的思路上养成好的习惯,对SDL人员的技术能力也是一个挑战,尤其对没做过或者没有系统学习过开发的白帽子来讲是比较难的。所以日常工作中,可以从第3条开始,每一个漏洞每一项风险,都问问自己,是不是认真对待,做到了这种程度。经过一段时间积累,以及对业务研发的了解,你会发现做好第2条并没有那么难。能够讲清楚问题的原理、危害、方案,不仅可以帮助业务同学提升安全知识和意识,同时也会传递你的专业性,赢得更多信任,在后续的工作中,对方也会对你或者你团队的工作更加支持和尊重。

4、事情能否做好,很大程度取决于对细节的掌握,抱着“较真”的态度把事情认真搞清楚,之后再下结论或评判。

注解:SDL工作跟业务会有大量的对接沟通,由于双方背景知识不同,掌握的信息不同,沟通上很容易出现不顺畅的情况。有时候,可能双方连事实都没去搞清楚,因为某一方对某个细节不掌握或者理解不一致,就吵起来了。心里面互相给对方贴了标签,安全觉得业务不听话,让你修个漏洞怎么这么麻烦,业务觉得安全啥也不懂还为难我。 其实大多数情况,只是沟通的耐心不够,对细节掌握的程度不够,才导致了无法理解对方。真正耐心地去了解清楚需要掌握的所有细节,很难有聊不通的问题、做不好的事情。真的遇到了比较极端的情况,无法解决,可以向上反馈,上升到上一级Leader,此时也有理有据。 如果自己还没有尽力去搞清楚问题,就乱下结论,跟人吵架,是非常不专业的行为。
安全工作,能“较真”非常重要。

5、发现问题,主动去解决或者主动推动解决(而不是总期待别人解决问题),落地解决方案。需要帮助时,可向团队发起主题会议,在周会时讨论方案,如有必要,可专门开会讨论。

注解:职场中有的人很善于发现问题,但是永远的在不断进行毫无建设意义的抱怨,而且总是希望别人来解决问题,从未考虑过自己有没有可能去解决掉问题。遇到自己能力范围内无法解决的问题时,可以在正式的场合反馈交流,私下的抱怨永远无法解决问题。凡是问题,皆是机会。发现问题,能主动解决问题,也是一个人能力和价值的体现。这条可以对照下面不鼓励的行为第4条来看。

6、鼓励技术研究,更鼓励选择与公司业务或技术栈安全有相关性的技术方向,深入研究,为我们的安全建设创造价值。

注解:我们搞安全的平时一定要保持技术进步,越是往后学,你会发现要学的东西越多,就没有学完的时候。但是偶尔会有同学学着学着方向就偏了,整天研究的东西跟实际工作没有半毛钱关系。举个不一定恰当的例子,假设你的公司技术栈完全是Java,没有一个业务用到PHP,你在Java安全还没有吃透的情况下,整天研究PHP安全(即使它是最好的编程语言),但也不值得鼓励,除非你目标明确,想要下一份工作跳槽到一个PHP技术栈的公司。人生苦短,精力有限,你的研究方向能够为自己的安全建设本身带来价值吗?假设你的出发点是积累跳槽资本,大多数情况下,你当前的工作需要的能力,其实也是市场上需要的能力,因此不必舍本逐末。当你有多个方向想要研究的时候,尽量选择对个人对本职工作都有意义的那一个,一举多得。

7、鼓励分享,分享是加深自己技术理解程度的机会,也是增强自己表达能力的机会,同时会给团队其他人带来不同程度的帮助和提升。优秀的团队一定是共同成长,互相成就的。

注解:这条不用解释。

8、保证质量,有始有终。

注解:有时候一个人跟一件事情,跟着跟着就没后续了,过了很久之后由于某个事件复盘,发现之前有做过,但没做完,甚至一些相关的人都离职了。包括我自己,事情多时间久了,偶尔也会遗忘。所以一些周期长的事情可以写到待办里记录下来,有始也要有终。 保证质量也很重要,不能说目标里定的是完成,不管啥样搞完就行了,最后发现一大堆问题,还得重做。

9、换位思考,如果你是研发,你要怎么修复这个问题。站在对方的角度,考虑你要怎么沟通,对方才能更容易接受。

注解:换位思考是一项很重要的工作能力,不论是在沟通上,还是自我提升上。

10、养成总结的习惯,经常沉淀。鼓励把提效工具、方法带给团队,输出给业务团队。

注解:好的工作方法、工具能够经常总结沉淀,分享给团队,往往可以帮助到其他人,带来整体效率的提升。如果能够进一步输出给业务团队,更能体现价值。一个人也许可以走的更快,但一群人可以走的更远。

最后一条,职业生涯发展(升职加薪)利器:主动性!主动性!主动性!


哪些行为是不鼓励的?

1、职责划分过于清晰,固守边界,自扫门前雪。

注解:工作中经常会遇到一些处于模糊地带的事情,参与也行,不参与也说的过去。如果每个人都严格按照职能界定固守边界,自扫门前雪,那么很多事情就无法产生协作,问题永远不能解决。向前走一步,“山不过来我过去”。

2、对漏洞的产生原因,修复方案模糊不清的,不进行研究,直接给“一句话”方案,拒绝沟通,不考虑场景,强制研发按照“一句话”方案修复。

注解:这是个常见的问题。在鼓励的行为2、3条里说过了。

3、安全遇到紧急事情是常态,不要做旁观者,要做参与者。

注解:一个通用漏洞爆发,一次安全事件,都可能是比较紧急的。你的每一次主动参与或者提供帮助,别人都能够看到。

4、毫无建设意义的抱怨。凡是问题,皆是机会。发现问题,能主动解决问题,是一个人能力和价值的体现。
不同人遇到问题,理解是不同的:
有的人没有明显感知,觉得问题是正常;
有的人觉得问题都是别人的问题,与我无关;
有的人产生强烈的负面情绪,回避问题;
有的人寻找解决办法,主动推动/解决问题。
问题是一面镜子,对问题的态度,一定程度上会折射出一个人的认知水平。
你希望自己成为哪一类人呢?

注解:这个问题前面鼓励的行为第5条里说过了。

5、少做少犯错?
No!!!不要怕犯错,犯错会带来成长。避免“固定型心态”,拥抱“成长型心态”(如果不了解这两个概念,可以自助了解下)。

注解:有的人在职场待久了,会“精通”所谓的职场“潜规则”,比如做的多错的多。也许在某些地方适用。但我相信拉长时间来看,这种心态对自己来讲一定是弊大于利的。

6、人不是机器,工作时间偶尔开小差可以理解,但在正常工作时间内不能花太多精力在与工作本身无关的事,比如:刷剧、看电影、打游戏、挖SRC、做众测等。

注解:工作时间内花太多时间搞娱乐本身就是一件非常离谱的事情,虽然比较少见,但确实会有。有些搞安全的同学可能喜欢占用工作时间挖SRC、做众测、私活,而本职工作却没有花时间做好。为什么会有这种现象,这是一个很大的话题,不在这里深入聊了。SDL团队里最好能避免这种风气。

三、会议规范

  • 时间
    每月至少一次团队复盘会。其他事项可按需发起会议。具体会议时间跟进实际情况决定。
  • 方式
    每位团队成员,均可以在有需求时,发起团队会议。
  • 内容
    任何与工作相关的内容,包括但不限于:
    技术分享
    漏洞复盘
    工作问题同步
  • 参会人员
    每次会议,发起者需要指定团队参会人员类型,分为必须参加、建议参加、自行决定。
  • 会议过程要求
    讨论重要内容时,所有参会成员需合上电脑,放下手上其他工作,认真投入参与,倾听、思考、讨论。

注解:开会的时候如果没有要求,可能会有一些同学忙于手中其他的事情,而不能很好的参与进来,会议的效果大打折扣,浪费彼此的时间。

四、关于此章程

此章程由团队全体成员商议制定,每年回顾调整一次。

注解:要确保团队所有成员参与,充分讨论,达成一致。随着时间和团队发展阶段的变化,章程的内容也应该定期回顾调整。

0x03 后记

其实最早的版本,写的比这个多一些,后来尽量做了精简。以上内容仅供参考,希望能对各位读者所在企业的安全建设有所帮助,可能很多问题我还没有遇到过,如果你遇到了一些团队建设的难题,或者好的建议,欢迎和我交流。

因水平有限,文中内容如有偏颇也欢迎批评指正。

个人微信:w4ter0

作者:唐银@涂鸦智能

# 企业安全 # SDLC # 甲方安全 # SDL
本文为 独立观点,未经允许不得转载,授权请联系FreeBuf客服小蜜蜂,微信:freebee2022
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
相关推荐
  • 0 文章数
  • 0 关注者
文章目录