危险！安全人员和开发运维人员之间的误解

安全团队和开发运维人员团队之间的误解可将企业置于业务风险之中

从物理、金融风险&＃xff0c;再到战略和运营风险&＃xff0c;今日企业被种种风险所包围。企业和员工必须就这些风险进行沟通&＃xff0c;这反而会促进企业团结一心。这种沟通需要IT人员、安全人员和开发运维人员(DevOps)的通力合作。这些团队应当清晰地认识到应用的安全性和业务风险波动之间的关联&＃xff0c;这会让他们进一步明了自身在解决安全风险时的职责。相对的&＃xff0c;失败的沟通也会让整个企业处于危险之中。

倾向于聘请开发运维人员的企业通常会追求高投入产出比、内部的持续创新&＃xff0c;以及高敏感度的客户响应能力。大多数领导团队最恐惧的就是对手的创新和进步&＃xff0c;以及疏远了本应抓住的客户而导致销售额损失。因此&＃xff0c;安全团队的话语权远远不如开发运维团队&＃xff0c;更不要说阻止后者了。即使在最理想的情况下&＃xff0c;安全团队也只能对他们产生一些影响。

安全团队要想和商户以及开发运维人员进行有效沟通&＃xff0c;就需要了解应用安全和企业面临的风险波动之间的关联。如果能实现这一目标&＃xff0c;安全团队将会在信息风险事宜上更有话语权。然而&＃xff0c;如果对这些风险置若罔闻&＃xff0c;企业将会遭受各种安全问题的困扰&＃xff0c;团队地位也会一落千丈。

避免沟通失败的第一步&＃xff0c;就是了解开发团队不需要的安全措施。某些最佳实践指南就不尊重技术现实&＃xff0c;比如“加密数据库中所有数据”&＃xff0c;这样的指南显然不具备实际意义。标准应该适合应用&＃xff0c;并且对于开发团队具有可行性。那些缺乏开发经验的安全团队常常误入这个陷阱。

除此以外&＃xff0c;执行安全测试时漏洞信息管理的欠缺是害处多多的。检测工具会误报&＃xff0c;虽然确定了这些漏洞&＃xff0c;但是这些“漏洞”不能反映系统或软件的真正弱点。工具还会错报所检测到漏洞的严重程度&＃xff0c;而导致的不合理优先级。在与开发运维团队沟通时&＃xff0c;漏洞误报既浪费时间&＃xff0c;也降低了安全团队的可信度。

最好的结果是&＃xff1a;对缺乏兼容性的漏洞加以沟通&＃xff0c;或形成未修复漏洞的日志。最坏的结果是&＃xff1a;开发团队把时间浪费在了没用的补丁上。应用的安全性常常难以捉摸&＃xff0c;所以许多开发团队仅凭自身是难以理解漏洞的。如果他们无法认识到这些内容&＃xff0c;他们就无法正确评估漏洞的风险&＃xff0c;也不会知道该如何解决它们。而兼容和支持恰恰是开发团队取得成功的关键。

开发运维团队需要和安全团队沟通哪些内容?

当安全团队与开发者沟通漏洞时&＃xff0c;漏洞必须确实存在且被精确测评&＃xff0c;安全团队对漏洞影响的说明会让开发运维团队更加心中有数。针对性的补救建议至关重要&＃xff0c;它需要尽可能和开发团队所使用的语言和框架相符。这使它能更容易解决问题&＃xff0c;漏洞可以更快也更有效地被修复&＃xff0c;修复漏洞的时间产出比也会得以改善。目标明确的漏洞修复也更容易一次性成功。

安全团队还可以为漏洞的处理以及合规提供有价值的指导。一旦因为漏洞而导致处罚或关停服务&＃xff0c;开发团队需要及时获得这些漏洞信息并第一时间进行修正。

除了漏洞&＃xff0c;安全团队还可以就系统架构建议进行进一步沟通&＃xff0c;来更好的设计应用以减少系统因为合规要求而受到的种种束缚。举例而言&＃xff0c;将信用卡相关事宜交给可信的第三方可以避免系统需要受不符合PCI-DSS的评估。另一个例子&＃xff0c;不进行非必要的个人身份信息存储&＃xff08;PII&＃xff09;以避免人工管理数据的风险。营销人员经常想要存储所有可访问的数据&＃xff0c;但是系统设计师需要理解储存过多的数据对隐私和安全的影响以及相伴的风险。

安全团队和开发运维团队之间的误解会让企业面临风险。在与业务风险相关的应用安全已经对业务造成了影响时&＃xff0c;安全团队应当出面进行沟通。如果安全团队可以从品牌、金融、战略等方面进行风险评估&＃xff0c;那么他们就会成为开发运维团队最可靠的谏言者&＃xff0c;并帮助开发运维团队建立和维护安全的系统。

本文转自d1net&＃xff08;转载&＃xff09;