安全需求评审:业务研发团队该如何提交信息

  • A+
所属分类:安全闲碎

数据安全的概念在近年来,越来越受企业重视,更多的是因为合规性的驱动,尤其是GDPR的巨额罚款,让企业开始愿意去投入更多的成本来满足数据保护合规性要求。数据安全的合规,最终不可避免的涉及到信息安全体系的建设、IT架构的设计以及应用系统的开发。作为一名信息安全从业人员,在此不去深究法律层面的术语概念,专业的事情就给专业的法律人员,而是从信息安全人员的角度去做相关的设计建设。

而在数据安全合规建设中,尤其是对GDPR的合规中,大型企业一般不会完全重新设计新的流程,而是尽可能的与过往的iso27001、SDL流程等现有体系流程相结合。同时对于研发来说,为了发布一套系统四处填写类似信息,亦会造成研发的反感。

本人有幸参与了东家SDL和devsecops建设、iso27701和iso29151认证、数据加解密项目、GDPR合规项目等工作,遂在此分享一下相关工作的思考,同时希望得到各位大佬的指正,共同学习进步。

那如何在安全需求评审中融合数据合规呢?我们今天先来看看需要业务研发团队提交的信息。

0x01安全需求评审的内容

在《信息安全技术 个人信息安全规范》中,规定了在某些场景下,需进行个人信息安全影响评估,包括信息所用于的目的、根据评估应当采取的安全措施等等。在GDPR中,第35条提出了企业要进行DPIA的要求,DPIA的步骤一般分为3步,即项目负责人填写初步清单、是否进行DPIA评估、实施DPIA。这其中包括是否收集个人信息、使用目的、处理方式、数据主体权利的履行措施、保护措施等等。iso27701中,7.2.5条说明需进行隐私影响评估,其中7.2.8中说明应当涉及将被处理的个人信息类型、处理目的、相关信息描述、接收者类别、技术及组织安全措施等等。

可以看出DPIA的进行其实和安全需求评审的实施阶段类似,都是在项目立项或者需求阶段进行介入;其次,安全需求评审往往也需要了解业务涉及的敏感级别、业务的目的、处理方式、安全措施等情况,在内容上和DPIA需要研发所提供的信息有重合的地方,因此两者可以合并在一起进行。

关于在安全需求评审阶段进行DPIA,应当如何设计各个模块,可以参考各个主要法律法规和标准。在《个人信息安全规范》中,分别从个人信息的收集、存储、使用、共享等个人信息全生命周期各个环节进行要求。在《数据安全能力成熟度模型》中,也主要通过数据的全生命周期各个阶段进行指导。而GDPR中,更多使用的是“处理”这一概念,涵盖所有围绕个人信息的操作,更侧重于数据主体的权利,这些权利不是针对数据全生命周期的某一特定环节。

由此可以看出,我们可以从个人信息全生命周期各个阶段和数据主体权利来设计各个模块。

除了相关法律法规、国家标准以外,对于某些细化类别,我们也可以参考相关配套标准或者实践指南进行设计。《app收集使用个人信息自评估指南》可以看做是对《个人信息安全规范》中的个人信息收集和信息主体权利部分的一种细化,实践的具体要求。《个人信息告知同意指南》也具体指出了很多细化场景。GDPR因为刻意避免提出相关技术措施,因此对于实施细节,说明较少,往往是通过第29条工作组或者监管机构如英国ICO的解释进行指导,如cookies的合规、同意的解释等等。

最后,在明确了相关内容后,根据之前在SDL建设和devsecops建设中的经验,设计问答形式的表格,让研发填写长篇大论,往往会造成更多的沟通成本,这往往是安全需求评审阻碍devsecops建设的一大瓶颈。因此,应当更多的让研发做选择题,并通过选择题,让部分需求评审能够自动化(不要指望完全自动化)。

0x02需要业务研发团队提供的信息

在《个人信息安全规范》和GDPR中,都提到了收集个人信息的两种方式,即直接收集个人信息和间接收集个人信息。其中,《个人信息安全规范》中提到,如果产品或服务的提供者提供工具供个人信息主体使用,提供者不对个人信息进行访问的,则不属于个人信息收集。规范同时举了个例子,即采集的信息不回传给软件提供者,则不算个人信息收集。这里要注意一下,在GDPR中,并没有发现类似规定,在GDPR中,这类也算是信息处理的一种方式。

数据采集或者个人信息的采集,一般需要了解三个部分:采集了什么数据,采集的目的是什么,如何采集的。但是根据整个安全需求评审的逻辑来看,应该是先看当前版本主要开发了什么新的业务模块,为了实现这个业务模块需要哪些数据(是否包含个人信息),这些数据是如何获取的。

(1)当前涉及的业务模块

2020年版《app收集使用个人信息自评估指南》评估点二“是否明示收集使用个人信息的目的、方式和范围”中,要求完整列举,不允许使用“等”“例如”等方式。对于“目的”列出了相关举例,如下所示:

地图导航,网络约车,即时通讯,网络支付,新闻资讯,网上购物,短视频,快递物流,餐饮外卖,交通票务,婚恋相亲,房屋租售,求职招聘,网络借贷等。

根据《信息安全技术 移动互联网应用程序收集个人信息基本规范》,其中列出了一系列业务功能,如下所示:

业务功能 描述
地图导航 为用户提供互联网地图和导航功能
网络约车 为用户提供网络预约汽车(不包含汽车租赁)服务
即时通信 为用户提供在线文字、语音、视频等形式的通讯服务,或基于即时通讯的交友互动等服务
网络社区 为用户提供博客、论坛、社区等服务,包括话题讨论、信息分享和关注互动等功能
网路支付 为用户提供在收付款人之间转移货币资金的服务(如非银支付、网银支付),包括支付、提现、转账、账单等功能
新闻资讯 为用户提供图文、音视频等新闻资讯信息服务,包括新闻资讯的浏览、搜索和发布功能
网上购物 为用户提供网上购买商品或服务的服务类型,包括商品展示、搜索、下单、交付、客服售后等功能
短视频 为用户提供短视频服务,包括浏览、搜索、制作、发布短视频和社交互动等功能
快递配送 为用户提供信件、包裹、印刷品等物品的寄递服务,包括寄件、查件、收件等功能
餐饮外卖 为用户提供餐饮等外卖信息和外卖服务,包括餐饮配送、到店自取等功能
交通票务 为用户提供交通相关的票务服务,包括票务查询、购买、改签、退票等功能
婚恋相亲 为用户提供征婚服务,包括异性推荐、相亲牵线等功能
求职招聘 为用户提供网上招聘和求职服务,包括职位发布、职位展示、职位搜索、投递简历等功能
金融借贷 为用户提供从金融机构进行个人消费贷款服务,包括授信、借款、还款与交易记录等功能,这里的金融机构是指有放贷资质的银行、消费金融公司、小贷公司等在网络上提供借贷服务的机构
房屋租售 为用户提供房源信息、房屋出租服务,包括房源展示、房源搜索、房屋出租等功能
二手车交易 二手车交易为用户提供汽车资讯、二手车交易服务,包括车源信息搜索和展示、车辆审核和二手车买卖等功能
运动健身 为用户提供运动记录和健康建议服务,包括健身运动管理、健康建议等功能
问诊挂号 为用户提供在线问诊、在线挂号的医疗服务
网页浏览器 为用户提供通过输入网址或站点导航浏览网上信*息资源功能的服务,包括网页浏览、文件下载、资源收藏等功能
输入法 为用户提供通过键盘、手写、语音等方式输入字符功能的服务
安全管理 为用户提供查杀木马病毒、清理恶意插件、修复漏洞、清理优化、骚扰拦截、权限管理等功能
旅游服务 为用户提供景点信息、旅游路线规划服务,包括景点展示、景点搜索、旅行路线设计等功能
酒店服务 为用户提供酒店信息、酒店预订服务,包括酒店展示、酒店搜索、酒店预订等功能
网络游戏 通过互联网、移动通信网等信息网络,为用户提供游戏产品和服务
在线影音 为用户提供在线音视频服务,包括浏览、展示、搜索、播放、下载音视频等功能
儿童教育 为用户提供儿童早教、儿童在线教育服务,包括儿歌教育、童话教育、早教练习等功能
电子图书 为用户提供读书、听书、漫画等电子图书阅读功能
拍摄美化 为用户提供拍摄照片、摄影、美颜、滤镜、表情包、个性化贴纸等服务
应用商店 为用户提供移动互联网应用程序下载、管理等服务
网络直播 为用户提供以视频、音频、图文等形式持续发布实时信息的服务

以上业务,需根据各公司实际情况进行微调或者合并(比如将涉及较少的业务功能统一先归并到“其他”里面)。

在GDPR当中,并非如上通过业务功能进行要求,而是从对数据主体所享有的基本权利产生影响的角度出发,提出一系列处理方式类型。具体如下:

类型 举例
是否对数据主体进行评估和评分 如应聘者测试评估,员工绩效评估
是否涉及具有法律或类似重大影响的自动决策,尤其是拒绝服务 如信贷自动审批,基于异常行为的自适应风险阻断
是否向第三方披露 将个人数据转移到新的供应商或位于英国/欧洲经济区以外的地方,或新的地点
是否会使用创新技术(特别是可能被认为侵犯隐私的新技术)?或以新的方式使用现有技术? 例如,使用生物识别技术(如指纹识别)登录应用程序,使用面部识别系统以验证身份和接受送货。

同时,要考虑到不同法律法规和标准的适用范围,因此还需要了解该功能模块面向服务对象的范围。

可使用该服务模块的用户所在国家范围

可使用该服务模块的用户的年龄范围

提供该服务的控制者主体所在国家范围

(2)该功能模块需要的数据

在法律法规或者标准中,对于个人信息的定义较广,尤其是GDPR,其第4条规定,“个人数据”是指已识别到的或可被识别的自然人的所有信息。所以,完全让研发团队说明自己采集了哪些个人信息,势必会漏掉很多在常见语境下,不被认为是“个人信息”。因此,需要给研发团队列明相关个人信息和个人敏感信息。

《个人信息安全规范》划分了个人信息和个人敏感信息两大信息。

表1个人信息举例

个人基本资料 个人姓名、生日、性别、民族、国籍、家庭关系、住址、个人电话号码、电子邮件地址等
个人身份信息 身份证、军官证、护照、驾驶证、工作*证、出入证、社保卡、居住证等
个人生物识别信息 个人基因、指纹、声纹、掌纹、耳廓、虹膜、面部识别特征等
网络身份标识信息 个人信息主体账号、IP地址、个人数字证书等
个人健康生理信息 个人因生病医治等产生的相关记录,如病症、住院志、医嘱单、检验报告、手术及麻醉记录、护理记录、用药记录、药物食物过敏信息、生育信息、以往病史、诊治情况、家族病史、现病史、传染病史等,以及与个人身体健康状况相关的信息,如体重、身高、肺活量等
个人教育工作信息 个人职业、职位、工作单位、学历、学位、教育经历、工作经历、培训记录、成绩单等
个人财产信息 银行账户、鉴别信息(口令)、存款信息(包括资金数量、支付收款记录等)、房产信息、信贷记录、征信信息、交易和消费记录、流水记录等,以及虚拟货币、虚拟交易、游戏类兑换码等虚拟财产信息
个人通信信息 通信记录和内容、短信、彩信、电子邮件,以及描述个人通信的数据(通常称为元数据)等
联系人信息 通讯录、好友列表、群列表、电子邮件地址列表等
个人上网记录 指通过日志储存的个人信息主体操作记录,包括网站浏览记录、软件使用记录、点击记录、收藏列表等
个人常用设备信息 指包括硬件序列号、设备MAC地址、软件列表、唯一设备识别码(如IMEI/Android ID/IDFA/OpenUDID/GUID/SIM卡IMSI信息等)等在内的描述个人常用设备基本情况的信息
个人位置信息 包括行踪轨迹、精准定位信息、住宿信息、经纬度等
其他信息 婚史、宗教信仰、性取向、未公开的违法犯罪记录等

表2个人敏感信息举例

个人财产信息 银行账户、鉴别信息(口令)、存款信息(包括资金数量、支付收款记录等)、房产信息、信贷记录、征信信息、交易和消费记录、流水记录等,以及虚拟货币、虚拟交易、游戏类兑换码等虚拟财产信息
个人健康生理信息 个人因生病医治等产生的相关记录,如病症、住院志、医嘱单、检验报告、手术及麻醉记录、护理记录、用药记录、药物食物过敏信息、生育信息、以往病史、诊治情况、家族病史、现病史、传染病史等
个人生物识别信息 个人基因、指纹、声纹、掌纹、耳廓、虹膜、面部识别特征等
个人身份信息 身份证、军官证、护照、驾驶证、工作*证、社保卡、居住证等
其他信息 性取向、婚史、宗教信仰、未公开的违法犯罪记录、通信记录和内容、通讯录、好友列表、群组列表、行踪轨迹、网页浏览记录、住宿信息、精准定位信息等

GDPR中,第9条规定了在GDPR管辖下的敏感个人数据,包括8类:

种族或民族出身

政治观点

宗教或哲学信仰

工会会员资格

基因数据

生物学数据

健康有关的数据

性生活或性取向数

同时,在《个人信息安全规范》和GDPR中,都规定了收集或者处理个人信息的合法理由或者说是征得数据主体同意的例外情况,因此,在进行该业务模块实现时,可以让研发项目团队提供需要该数据的原因。

这里要说明的是,从《个人信息安全规范》和《个人信息告知同意指南》可以看出,在采集个人信息时,应当征求数据主体的同意,然后再规定了可以不征求同意的情况。但是从GDPR可以看出,以及相应判例来看,“同意”并不是万能的,不能所有的采集都使用“同意”机制,因为“同意”是有“撤回同意”操作的合法理由必须适用适当。

根据《个人信息安全规范》,需要说明的原因包括:

与个人信息控制者履行法律法规规定的义务相关
与国家安全、国防安全直接相关
与公共安全、公共卫生、重大公共利益直接相关
与刑事侦查、起诉、审判和判决执行等直接相关
出于维护个人信息主体或其他个人的生命、财产等重大合法权益但又很难得到本人授权同意的
根据个人信息主体要求签订和履行合同所必需的
维护所提供产品或服务的安全稳定运行所必需的
新闻单位开展合法新闻报道所必需的
学术研究机构,出于公共利益开展统计或学术研究所必要,且其对外提供学术研究或描述的结果时,对结果中所包含的个人信息进行去标识化处理的

具体示例,可以参考《个人信息告知同意指南》规定的相关不需取得同意的例外情形。

根据GDPR第6条规定,需要说明的原因包括:

数据处理是为了履行控制者所负担的法律义务所必需(这里的法律义务是欧盟法或者欧盟成员国法,比如中国法并不属于这里的法律义务,因此应当区别对待)
执行公共利益领域的任务或者公务职权
数据处理是为保护数据主体或另一自然人的重大利益所必需
履行数据主体作为一方的合同所必需
数据处理是为实现控制者或者第三方所追求的合法利益所必需的

同时,为了满足PECR中的cookies政策,在数据采集中,应当再增加一部分,即cookies收集部分。需研发项目组提交的信息包括:

cookie名称

cookie所有者(比如是公司自己还是第三方统计分析的,如百度、谷歌)

cookie类别(绝对必要、优化类、分析类、隐私偏好)

cookie目的

(3)采集的方式

根据《个人信息告知同意指南》第5.1条,可以将个人信息采集方式细化如下:

个人信息主体主动填写、选择、上传等主动提供个人信息的
网络运营者通过智能终端、API、SDK、IoT设备、浏览器、传感器等自动采集个人信息的
网络运营者通过与用户交互记录个人信息主体行为的
网络运营者从第三方间接接受、查询等方式间接获取的
网络运营者从非完全公开渠道搜集个人信息的
网络运营者从个人信息主体关联身份或账号收集个人信息的
网络运营者使用大数据、AI等技术分析、关联和生成个人信息的

这里再次涉及到《个人信息安全规范》和《个人信息告知同意指南》中,指出的例外情况。

所涉及的个人信息是个人信息主体自行向社会公众公开的
从合法公开披露的信息中收集个人信息的,如合法的新闻报道、政府信息公开等渠道

后续,会根据以上收集的信息,对如何提出安全评审的要求进行分享。

安全需求评审:业务研发团队该如何提交信息

精彩推荐





安全需求评审:业务研发团队该如何提交信息
安全需求评审:业务研发团队该如何提交信息安全需求评审:业务研发团队该如何提交信息

安全需求评审:业务研发团队该如何提交信息安全需求评审:业务研发团队该如何提交信息安全需求评审:业务研发团队该如何提交信息

安全需求评审:业务研发团队该如何提交信息

本文始发于微信公众号(FreeBuf):安全需求评审:业务研发团队该如何提交信息

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: