诸子云·分享汇 | 第二周直播实录
10月19日，“诸子云·分享汇”线上直播第二季正式拉开帷幕。
作为社群活动计划的重要环节，本季线上直播邀请百家智库首批专家作为分享嘉宾，围绕涵盖等保合规、数据安全、个信保护等共计20个主题，计划开展10场分享活动，共同探讨企业网络安全实践之热点、焦点、痛点、难点和要点。
本文即对第二周直播实况的回顾。本周共开展两场分享活动，德资企业法务合规部经理张殿勇、中通快递高级安全专家陈圣、某金融机构安全专家刘顺、某电商公司安全管理杨文斌四位专家分别进行了议题分享。
★ 第一场 ★
10.26
个人信息保护三问
张殿勇 德资企业法务合规部经理
1、个人信息是什么？
一般认为“个人信息”是基于“识别说”、“关联说”的主张去认知，单独或者综合后直接或者间接可以识别到具体自然人的信息均可认为是个人信息，当然里面有一个例外情况，即：匿名化处理后的信息在可以作为非个人信息处理。这里的匿名化需结合脱敏技术来审慎对待。
在实际的业务场景中，我们还需要多维度去理解。
以个保法正式立法流程之前上海地区的侵犯公民个人信息类犯罪案件数据为例，我们可以发现自2009年刑法修正案（七）新增个人信息保护条款，为公民个人信息保护提供了重要依据以来，案件量逐年提升；直至2014年当年的案件数量超过前几年的总数，从数量上，可以反应出法律对于个人信息保护的力度不断加强，在随后的2015年刑法修正案（九）对于犯罪主体的范围扩大、侵犯个人信息行为的范围扩充及量刑加重的规定都可以得到印证。
通过分析上海市侵犯公民个人信息类犯罪案件，包括通过网络爬虫技术或者采用破解验证码非法获取个人信息，或者非法提供信用卡信息，又或者在数据交易灰产行业的非法出售行为，以及侵犯消费者、金融用户等合法权益的情况，其实可以发现，法律之所以予以规定个人信息的保护，其本质是个人信息具有法律保护的价值，换言之，具有法律保护的价值是个人信息的另一个维度定义标准。
2、个保安全是什么？
个人信息保护的目的，是保护个人信息的安全。从个人信息保护的行为模式来看，包括被动安全和主动安全。两种不同的安全模式在不同的业务场景下，理解虽有不一样，但是实质是相同的，结合前面提到的个人信息的价值维度理解，即：实现个人信息的价值安全。
个人信息的价值之于企业，首先是企业因为法律义务要求首先需承担相应的责任而存在，可以理解为某种程度上的被动安全。比如大到国家安全需要，小到企业经营资质保证，这是企业得以存续，业务得以开展的前提和必备能力所需。只有具备了这些，才能保证个人信息的安全价值稳定，如信息数据的储存安全能保证企业的数据存量支持，就像蓄水池的蓄水能力稳定，我们可以称之为“保值”。
其次，信息数据作为生产要素要产生生产力，同样需要流通，需要交易，才能实现价值变现，比如通过信息收集、信息解读、信息裂变等可以实现信息的创新创造而产生经济价值效应，这个过程就是“增值”。与此同时的，个人信息价值在变现的过程中风险是伴生的，如信息处理过程中会有流量被拦截、数据修改甚至信息的伪造，一旦发生这样的风险，基本上就出现了个人信息安全事故，甚至系统性的数据泄露风险。这一类的事故，显然会给公司带来经济损失甚至法律风险，也就是“贬值”。
最后，个人信息有关的任何创新都是基于业务发展的需要，所以个人信息保护安全工作的触角要对一线工作风险保持足够敏感的反应。通过对业务流中的各个负责部门的价值取舍作合情合理的了解，才能取得平衡，从而更好的协调好个人信息创新工作的安全管理。
3、个保路径是什么？
随着《个人信息保护法》的生效，我国网络数据信息安全的三大专门法律全部实施，信息安全相关的法律体系趋于完善，个人信息保护工作也更有抓手，那么个人信息保护工作的基本路径也随之清晰起来，归纳起来就是：循规问道做自己。
循规就是遵守法律与法规的规定，区分民事、刑事及行政监管的不同救济类型和要求，并且落实到企业业务实际中去做好内部风险分类及响应机制制度，及内部个人信息安全制度规范。
问道就是分清县官与现管，积极地与相关监管部门保持良好沟通，及时了解监管执法的口径，必要时候需要引进外部机构对内部相关的工作职能指导制度，以提高本企业业务中的个人信息保护工作能力。
做自己就是梳理所在企业所在行业的业务流程，熟悉个人信息相关的业务场景，通过事前、事中与事后的全流程管控。“流程管事，制度管人”，个人信息保护工作不是单机模式，还涉及到业务线的其他专业支持，如人员管理、培训宣导、法务支持等，如何在原有企业的制度基础上再构建一套行之有效的适用于个人信息保护的制度是一个系统工程，需要做好统筹规划。
企业个人信息保护合规
落地实践
陈圣 中通快递高级安全专家
判定某项信息是否属于个人信息，主要应考虑“识别”和“关联”这两条路径；对于个人敏感信息，需要满足特殊标记、增强告知、强加密、单独存储、独立规则的重点保护要求。
个人信息的判定标准，主要如下图所示。
那么对于常见的个人信息处理落地场景，我进行了详细的总结。
在购物App场景中，合规最低要求为对收集的个人信息至少在隐私政策中说明。如果收集面部识别、生理健康、银行金融、行踪轨迹信息等敏感信息，最好有单独弹窗提示并让用户点击同意；如果无法由用户单独点击同意，至少有浮窗或者备注进行说明。
在个人信息的获取场景中，如果利用爬虫技术等编写程序或者脚本以自动化方式抓取网页信息，必须要符合法律规定；不能从来源不明的渠道、黑市购买通讯录、邮箱地址、信用卡信息、征信信息等个人信息。
对于个人信息收集的目的，需要具体、明确地向用户告知，不能将功能描述和使用目的描述同义反复。个人信息的收集方式需要详细说明，包括自动化的收集方式；如果个人信息收集的范围随业务有所变更，需要同时修改个人信息保护政策并予以说明。
统一账号体系下的存储与注销。如果为同一个账号体系下，不同产品数据应分开存储，查询访问、删除时需较为方便。统一账号体系，对于注销账户来讲，注销某个产品即注销整个集团产品的账号，需要向用户告知清楚注销账号的后果；与此同时，为用户提供仅注销或删除某一单独产品个人信息的方法。
匿名化。常见的方法包括屏蔽、随机、泛化和加密，具体如下图所示。
信息共享或服务功能转跳。因账号登录、第三方支付、物流快递发货、广告等需要向第三方共享或者转让数据，需要在隐私政策中进行说明；如果实现服务功能需要跳转到第三方链接或者信息由第三方收集，还可以在实际触发该功能时以弹窗或者浮窗简单对信息种类和目的进行说明。
摄像头与物业。若视频监控设备被安装在单元小区，要判断数据使用方到底是小区物业还是监控设备开发者，从而定义数据处理者，并承担相应的责任义务。如果摄像头仅在家庭内使用，则监控设备开发者为数据处理者，需要承担全部责任义务，并告知用户取得同意。
第三方支付。公司需要审查第三方支付机构的资质，在隐私政策中对用户进行提示并详细说明个人信息收集的情况；如支付链接跳转至第三方支付机构页面，不留存第三方支付机构收集的与公司业务无关的个人信息，不向第三方支付机构提供与实现支付功能无关的信息；不提供第三方支付机构从其他渠道可以获得的按照反洗钱法要求必需提供的信息。
对SDK使用情况进行自查评估。要对SDK种类、所属系统、SDK名称、公司名称、SDK的个人信息保护政策链接、收集使用目的、类型/范围、方式、App从第三方SDK获取的个人信息以及是否控制所收集的信息、留存信息或者所收集信息是否被用于为公司提供服务以外的目的这10点放进隐私政策中详细说明。
除了常见的个人信息处理场景，这里还有一些特殊场景下的落地。
采集个人敏感信息的摄像头如何告知。需要在摄像头产品中提供张贴的纸质提示，包括收集信息种类，使用目的，同时给到用户获取更多信息的方式，如扫码获取更多信息，或提供隐私政策链接。
App安全评测。这里需要遵循《App 违法违规收集使用个人信息行为认定方法》《App 违法违规收集使用个人信息自评估指南》《常见类型移动互联网应用程序必要个人信息范围规定》等方法和指南的要求。
★ 第二场 ★
10.28
安全开发生命周期
从0到1建设实践
刘顺 某金融机构安全专家
SDL建设的前期准备，我们首先需要明确SDL的目标是什么：提升应用安全质量、满足监管合规要求、保障企业经营发展。
如何获得Boss和研发领导的支持，需要我们证明SDL是有效的，这个过程我们可以用微软的业界最佳实践作为佐证，并用SDL在其他企业取得的成功来予以证明。同时，我们可以围绕成本与收益、风险和合规几个维度来证明SDL的价值。
参考微软SDL的流程，我们企业目前在项目实施过程中明确了建设框架，包括目标导向、建设举措（体系建设、人员能力建设、工具能力建设）和效果体现（监管合规、逐步推广）。
为了支撑这些节点的有效落地，我们建设了SDL安全平台。首先是安全基线库，因为威胁建模本质上就是选择基线的过程，所以我们做了基于场景轻量化的威胁建模。对标签进行归纳，建立关联关系，并在开发阶段通过安全组件、知识库、安全测试用例、安全测试以及漏洞与事件管理形成闭环。
在流程建设环节，我认为最重要的是想办法尽可能确保不影响现有的研发流程，并且做到流程全覆盖，同时对重要节点严格把控。
制度建设环节我们专门制定了包括体系管理类、安全设计类、安全编码类、平台安全类和安全测试类的各项管理规章；同时我们还设置了安全制度规范库，针对不同的人群开设不同的安全培训和课程考试。
安全需求分析我们目前使用了基于业务场景的轻量化威胁建模。安全基线等于安全需求，基线库来源则包括了法律法规标准、各行业的应用系统安全设计规范、应用漏洞和安全风险。
但由于威胁建模对专业能力的要求非常高，一般需要专门的安全人员来负责。但如果安全人员不够，我们则可以通过标签和业务场景将安全语言转换成业务语言，然后交给产品经理来负责。
对于内生合规，我们的整体思路是将外规对内规，内规对基线，基线对功能，功能对验证。比如我们需要对相关的法律法规进行解读，转变为内部规范，通过基线来将制度更好地落地，从而转变成相应的功能，最后再通过验证测试来评估实现效果。
在开发环节，我们提供了统一的开发框架，提供了包括集中身份认证、统一会话、统一权限管控、统一过滤、会话token、强制预编译、统一文件上传、日志脱敏等安全功能，解决开发过程中面临的安全风险。
如果一些老的应用没有通过统一框架来开发，我们也提供了相应的安全组件，只需要调用相应的组件就可以实现同类型的功能，从而避免安全漏洞。
在安全测试阶段，我们为每个推广SDL应用配备固定的安全测试人员，针对每单新增需求开展人工渗透测试、安全基线测试用例、源码安全扫描、应用安全扫描、隐私合规、灰盒安全扫描等在内的安全测试。
如果在进行了安全测试之后依然发现漏洞，我们需要执行严格的安全复盘，主要分为三个步骤：
首先是统一思想，认可价值；然后通过我们总结的“灵魂五问”，找到具体的漏洞引入原因和引入人，连续问他五个为什么，找到问题的根本原因；最终帮助我们找措施，定计划，保闭环。
我们最终要取得的目标是：面向研发团队，我们要做到让同一类漏洞在同一个应用上不再出现；面向安全团队，把SDLC执行得更好。
而在最后的度量阶段，我们可以通过应用、人员、工具、漏洞等几个维度进行数字化统计分析，并面向研发团队和个人施行绩效考核。
开源安全治理实践
从0到1
杨文斌 某电商公司安全管理
全球新兴技术领域，开源成为主要技术路径，好处在于开源生产模式成为新一代软件开发模式，能够节约成本，缩短时间，提高效率；但与此同时，开源风险问题凸显，开源软件知识产权问题蔓延，成为开源应用屏障。好在目前全球开源治理理念兴起，国内开源治理模式初步形成，配套政策正在完善。
那么如何做好开源安全治理，首先要做好过程管控，这当中包括很多的节点，我这里只重点针对编码引入、私库拉取、发布前和运行中这四个环节进行阐述。
编码引入：在编码引入阶段，代码中的POM，间接依赖引入不安全版本，编码习惯管控；
私库拉取：私库中存在不安全版本，净化私库；
发布前：我们可以在编译打包时对不安全版本作检测，war包检测。
运行中：上线运行的系统中包含的不安全版本，服务中lib库jar包检测。
要注意的是，控机制越向左移，整改成本越低，所以过场管控要尽量在发布前做好。当然，这些思路并不一定适用所有企业的部署场景，企业需要根据自己的实际情况来进行建设。
目前我们针对生产环境打造了一个检测平台，它的实现逻辑相对简单，一面是漏洞库，另一面是资产，将资产和漏洞绑定之后就产生了漏洞资产的关联性，从而通过关联性精准定位存在的问题，并根据漏洞解决建议来解决问题。
针对资产管理，我们进行了资产备案，主要包括开源资产、组织资产、信息资产、漏洞资产等；在做好资产备案后，我们通过资产联动分析、精准定位、实时预警等手段进行分析预警。
在整改阶段，我们主要做了两个点，一个是闭环监测，在漏洞预警的时候分发责任人，实现常态化监测，对整改结果实时监控；一个是持续运营，包括漏洞库及时更新，定期漏洞通告机制，监控策略持续优化。
漏洞管理是通过漏洞视角来思考如何进行开源安全治理，主要有两种角度。
一是从风险整改处置的角度出发，我们遵循公司、项目、开源资产、开源漏洞的步骤，先从公司层面推导项目，找到存在问题的资产，再发现具体的漏洞。
二是从影响范围出发，遵循开源漏洞、公司+项目、开源资产、开源漏洞的顺序。当发现漏洞以后，先以漏洞为核心来寻找存在该漏洞的项目，精确漏洞的影响范围，再推导存在问题的资产，发现具体的漏洞。
在流程管控环节，我们实施了安全任务线上化全流程管控，主要包括：
1、安全任务流转建立线上化全流程管控机制；
2、线上任务分发、领取、反馈机制实现安全任务的统一整合、备案、统计；
3、建立任务反馈积分量化考核机制，反馈及时率和完成率等相关指标。
在制度约束环节，我们建立了开源安全管理制度，具体包括：
1、明确全生命周期相干部门职责分工；
2、明确开源软件使用规范和要求；
3、明确开源安全问题处置响应流程；
4、明确问题责任处罚标准。
总的来说，甲方在安全建设中最主要的目的是解决痛点，一般只要把一个问题解决好其实就够了。建立一套好的流程，虽然可以提升效率，帮助我们解决安全问题，但如果做的不好，也可能会导致更多问题的产生。所以对于开源安全治理，我建议大家结合自身的实际情况来进行建设。
专家演讲资料已上传知识星球，扫码获取完整内容
推荐阅读