CCS 2021 | 金融安全分论坛：安全应该量体裁衣 企业SDL建设要结合自身实际

随着业务迭代速度的加快，开发模式的不断革新，很多企业在应用安全实际需求和监管合规要求等因素共同作用下，开始将目光转向软件安全开发生命周期（SDL）的建设，但鉴于SDL建设是一个大型且复杂的系统化工程，大部分企业在落地步骤、建设规划、重点内容、风险控制等方面缺乏科学的方法论和实际经验作参考，意愿强烈却无从下手，已经成为了当前大多数企业正在经历的困境。

近日，在CCS 2021成都网络安全大会——金融安全分论坛上，来自于嘉实基金的安全负责人周明昊从“安全设计评审”的角度，分享了自身企业在安全开发体系建设方面的方法论和实践经验。

安全开发建设具有企业属性

企业应结合自身情况来整体设计

周明昊表示，在七八年前当大家谈到SDL的时候都是在借鉴国外的一些技术和方法论，想将这些先进的经验复制过来放在自身企业上，以推动安全开发体系建设。但安全开发的建设实际上具有强烈的企业属性，不同行业、不同企业的安全开发方案在思路和路径规划上都存在细微或巨大的差异。

“以嘉实基金自身的规模来看，直接套用一个成熟的SDL框架体系是存在相当大困难的。安全很多时候是量体裁衣的工作，要根据企业自身情况来设计，去一点一滴的改善安全的现状。如果安全部门冒然的去推动SDL建设，肯定会引起开发部门的抵触情绪。在他们看来，安全部门去插手开发管理，相当于是外行管内行，是很难推动的。”

以保障业务上线为出发点

建立安全设计评审体系

周明昊表示，在当前金融机构加速数字化转型的背景下，系统版本迭代非常迅速，往往开发一个新系统版本只留给开发团队了2周到1个月这样很短的限期，因此通常情况下留给测试团队的时间只有2天，而留给安全团队的时间甚至可能只有1天。

作为为安全把关的角色，在极为有限的时间内，如果安全团队提出需要优化的安全问题，就会导致开发团队错过业务上线的截至期限，这样开发人员和安全人员都很痛苦，甚至还会发展成为开发人员与安全人员之间的冲突。

在业务集中开发时期，最多时可能会有十余个独立的开发团队同时开发新系统，此时重复的安全问题，可能会在这些不同的业务单元中反复出现。因此周明昊便开始带领团队着手推进开发安全体系的建设，以期让开发人员提前了解常见的风险场景，让业务能够在如期上线的前提下，兼顾好安全风险控制，协调好业务上线窗口紧张与安全风险控制之间的矛盾。

从更轻量化、实用化的角度出发，嘉实基金选择了建立安全设计评审的机制。“我们推动安全设计标准化的初衷在于做好安全风险管控的同时，不过多的占用开发团队的时间，不增添额外的工作量，甚至还能帮大家节约时间让大家整体工作能够做得更轻松。”

周明昊介绍，在将安全设计加入项目评审前， 开发项目组通常会因为担心安全部门卡流程，往往会提前以电话、邮件等形式沟通安全部门人员了解可能存在的风险项，以加快项目整体的推进。但这种沟通方式是低效的，而且很容易出现疏漏。因此需要把这些安全风险控制项设计成标准文档，来帮助开发部门与安全部门之间更好的协作沟通。

为了进一步提高沟通效率，嘉实基金在项目开发评审的过程中引入了安全开发评审的机制，将安全作为项目评审的重要一环，让项目从开发到业务上线的过程更加标准化。

如何建立一个行之有效的安全设计评审体系？

周明昊认为，建立安全设计评审体系前应该做好三点准备，首先是贯彻上线前的安全检查，做好常见问题统计；第二是要细致的做漏洞修复后的复查工作；第三是要对开发管理发展现状保持关注。

01

贯彻上线前的安全检查，做好常见问题统计

 贯彻上线前的检查做好问题的统计很重要。一个好的设计，是基于日常中发现的问题，然后去提出如何避免这些问题的方法，或者如何修复这些问题的方法，把它给整合到安全设计中。另外去做好问题的统计，哪些问题比较容易出现。

需要注意的是，安全设计文档和需求调查表不应该覆盖所有的安全问题，如果覆盖的问题特别多，这个文档会特别长，导致开发人员失去耐心。安全部门应该根据自身企业的情况和差异，选择适合自己日常中经常会发现有问题的加到设计里面。

02

细致的做好漏洞修复后的复查工作

 有时候开发人员修复问题不一定会按照安全部门的建议来，如果安全部门的复查做的不细，比如在某个地方告诉他们需要用参数化查询，如果他只是加了一个过滤，结果看起来可能漏洞已经修复了，但事实上修复的并不完整。如果有一些转移或者有一些别的符号，它的过滤不一定能覆盖到。

如果你在复测中没有发现开发人员的这种错误做法，那么在后面的工作中，他们可能会默认这样的做法也是能够解决安全问题的，进而就会导致他的设计习惯方面越走越偏。所以安全部门的漏洞复查工作要做的尽可能细致，一方面可以帮助开发人员认识到正确的修复办法，另一方面也有助于树立安全部门的权威性。

03

对开发管理发展现状保持关注

 最后一点是要关注开发管理的现状，安全部门应该和项目开发团队保持较多的沟通，让开发团队了解安全部门的关注焦点，同时安全部门也要了解项目的大概情况，包括开发时间是否紧急、这个项目里面的开发人员是否有安全开发的经验、开发人员采用的接口是自己设计，还是有现有的接口可以调用等等。只有对相互之间有一个了解，才能促进大家更好的协作。

在分享最后，周明昊用了一个例子，形象的比喻了安全人员与开发人员的关系。

他表示，对于一家企业的安全团队而言，大家普遍存在一种安全责任意识。在这种责任意识的推动下，安全人员会把公司的网络、IT环境视为自己保卫的一座城堡，每时每刻都保持着高度的警惕，担心有人进来偷东西，有人来突然发起攻击。因此，在城堡内部，安全团队布置了监控，种种安全防护设施。

但此时，如果开发团队出现错误的操作，就会让这些堡垒的安全防护从内部瓦解。就如同在城堡里挖了一个地洞，或者是私自搭建了一个违章建筑一样，为这些原本安全的堡垒装上了了一个隐形的定时炸弹。

周明昊表示，安全部门必须就这些风险因素与开发人员进行有效的沟通，帮助开发团队清晰的认识到应用的安全性与业务风险之间的关联，明确开发人员在解决安全风险时的重要责任。同时，安全团队提出的安全设计标准也应该以业务为中心，尽量避免事后给开发团队提要求，协助开发团队建立一个更安全的系统，成为开发团队最可靠、最信任的谏言者。

THE END