![专栏特辑 | 开发安全铁三角纵横谈（三）]( "专栏特辑 | 开发安全铁三角纵横谈（三）")
为了能更好地理解今天所讲，请大家先回顾一下之前“开发安全铁三角纵横谈”内容：
安全设计的分工是最能体现开发团队和安全团队关系的。曾经有客户找我，希望我们协助他们的开发安全高手去做安全设计。我当时很诧异，反复询问，安全设计是由安全团队做吗？他说是的。我说你们安全设计怎么做呀？他回答主要基于等保三级。类似的情况其实我还碰到过，有不少的机构是让安全团队做安全设计的。
通常，如果一个机构将安全设计交给安全团队，这个机构的开发安全工作一定很难真正落地，因为安全团队是不可能做好安全设计的。
为什么明明设计不适合安全团队，还会出现由安全团队来负责安全设计呢？在这里可能出现了一个假的“安全设计”——这个”安全设计”其实是一个安全需求，比如参照等保三级的“安全设计”，就是提满足等保三级的一些安全需求。
通过对比，大家能理解真正的安全设计是什么？它是设计在安全方面的体现，是针对一个设计的安全说明。所以，安全团队是不适合负责安全设计的，最多可以协助安全设计。
也有人会问，那么我们做一个“安全设计”不行吗？这个“安全设计”顶着安全设计的帽子，真实的安全设计就会缺失，安全设计的管控就更不可能了。
好了，我们下一个结论：安全设计应该是开发团队负责，安全团队协助。
再往下就是安全需求，安全需求是到目前为止，在分工中最有弹性的，由开发团队负责和由安全团队负责都是可行的。
在讨论开发团队合适还是安全团队合适之前，先有一个问题要解答：需求不是业务部门提的吗？为啥不让业务部门提？
真正的业务需求是分两个阶段来做的。首先是业务部门提需求，这个叫业务需求，比较粗，直接给程序员的话，因为不够细，一般认为开发不能直接用，所以，业务需求后续会由开发团队做一个需求细化，这个需求细化的英语文档叫“requirements specification”，又有人把需求细化这个动作称为“需求规格”。这个需求规格一般由开发团队完成，业务部门确认，把业务部门的需求真正变成程序的流程和要求，让普通程序员一看就知道怎么编程实现。
所以，业务需求虽然是业务部门提出，但由于技术原因，实际是由开发部门提出细化的需求，业务部门确认。因此，安全需求，如果是宏观的，那很简单，早期满足CIA，即机密性（Confidentiality）、完整性（Integrity）、可用性（Availability），后期还增加一些不可抵赖、可追溯等特性；或者满足等保三级要求等，无论如何，很简单，项目之间差异小。但对于细化的安全需求，对程序员编程有实际影响意义的需求，业务部门是没能力出的，只能开发团队或者安全团队出。
开发团队负责、安全团队协助与确认这种模式的好处在于，实际开发中，需求会有调整（当然有的机构管得严点，流程复杂点，调整少，但不可能杜绝），开发肯定是知道“调整”的，安全需求要不要配套调整由开发决定，整个关系很顺。坏处在于开发团队会觉得自己不太懂，不愿意接受。
反之如果安全团队负责，开发团队确认，好处是容易达成一致意见，坏处是当需求发生调整，安全多半是不知道的，就很难相应地调整。即便增加流程务必让安全团队参与，但很多调整比较琐碎，安全团队很难跟得住。
总结一下：如果能形成开发团队负责、安全团队协助与确认这种模式最好；实在不行，就安全团队负责，开发团队确认，也是能操作的。
最后看安全响应。安全响应在SDL中是一个安全响应计划，然后大家按安全响应计划执行。
现在很多机构也有安全响应计划，多半是运维团队牵头制定的，在开发安全这一块肯定是比较粗的。从实践来说，一般是安全团队来定位问题，然后各个部门配合响应。
好了，今天就分享到这里。下次，咱们开始研究安全需求分析。
原文始发于微信公众号（国舜股份）：专栏特辑 | 开发安全铁三角纵横谈（三）
评论