数据安全合规实践(二) 安全需求评审:信息采集部分评审 – 作者:guoqi_znuel

前言

上一篇文章讲到在安全需求评审阶段,为满足数据安全合规,应当让业务研发团队提交哪些信息。今天这篇文章,我想和大家一起探讨一下,收集了这些信息后,怎么去做评审。

首先,在SDL和devsecops概念普及及热炒的当下,基本上没有人不会承认安全需求评审在应用安全中的重要性。但在做安全需求评审的时候,尤其是大型企业,其实是很头疼的事情,它往往会有以下痛点问题:

(1)安全人员少,但系统多,没法覆盖(我所在公司,安全人员在100-200左右,应用安全组基本维持在10人左右,但需要面对集团活跃系统300-500套,每月发版次数在900次以上);

(2)研发自提交的信息太简单,难以评审,每次都通过会议访谈又太耗时间;

(3)devsecops中对自动化要求较高,安全需求评审如何做到自动化;

自然,在安全需求评审中,融入数据合规内容,必然会增加工作量,也不会绕过上面三个问题。在本篇文章中呢,不会去专门讲我们在实践中如何做devsecops或者如何做安全需求评审,这些问题呢,我计划后面会做devsecops专题,来分享我们在实践中遇到的问题和解决的方案(如果按照b站的视频做法,这时候应该说如果点赞过万,我就xxxxxx)。

其实关于痛点2,在上一篇文章中,我们使用的方法有解决,即通过标准化的选项,减少业务研发人员自组织语言,便于安全评审人员快速理解;同时,通过举例,让业务研发人员理解安全合规的意图,减少对问题理解的误差。这样从双向减少了沟通成本。当然这里要注意一点,有些问题还是必然要进行访谈的,这个我们就不在这里展开了。

痛点1和痛点3其实是相关的,因为人力不足,效率低,所以要寄希望于自动化。那么上一篇文章中,标准化的选项,就为自动化提供了前提。当然在安全需求评审的自动化中,除了标准化的选项,我们还尝试了语义分析技术,但目前还在摸索过程中,各位大佬如果有好的想法也可以一起探讨。

所以接下来,我们就来看看如何在收集到标准化信息后,进行自动化的数据合规安全需求评审。同时,在此附上上一篇文章的链接

在自动化的安全需求评审中,我们将需求分为以下几类:(1)需求合理性评估,如对是否应当采集该数据进行评估;(2)安全附加性要求,如对某个需求,附加需要注意的安全措施或者安全要求。

0x01 何时需要触发

根据GDPR的要求,出于相同或类似的目的处理相同类型的个人数据,并且已经为这些活动完成了DPIA,那么则无需进行额外的DPIA。因此,在此处,如果在业务研发团队提交了相同的业务功能模块、相同的采集数据集、相同的采集方式、相同的处理方式时,则不需要进行进一步评估。当然,有人说不能信任研发团队提交的数据,这个时候,其实就是要靠后续审计、安全测试等来追责了。

0x02 数据采集必要性

根据《个人信息安全规范》中规定个人信息安全基本原则中,包含“最小必要”。GDPR中,第5条中规定,“充分、相关并且应限制于为实现该个人数据处理目的所需的最小限度内”。DPIA中,最核心的部分就包括“必要性”评估。

来源:freebuf.com 2020-10-16 18:21:48 by: guoqi_znuel

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论