话题1: 如何有效杜绝员工 github 泄密？看起来要想根除，只能把代码圈起来，不让员工通过各种途径带走才行。求教各位大佬是用什么方式来规避这种风险的？完全杜绝估计要彻底牺牲效率，有什么能平衡的好的方案吗？
A1:技术上，DLP+github代码泄露监控；管理上，重罚+全员通告。但很难杜绝，DLP总有对抗手法，如果真想带走代码，一般都上传github私有账号和各类网盘。
Q:“DLP+github代码泄露监控”有在用，但是效果不好，有什么好的落地经验吗？DLP 对代码的效果不是很好，github 私有项目基本不可能发现，公用项目也很难做到全面发现，要依赖大量的规则和运营。
A2:断网+VDI云桌面方式。目前实际落地多的还是事前监控、DLP、事后处罚，其中终端DLP尽可能多覆盖各种客户端工具和浏览器，开发环境离线。不过DLP，离线等方案可能会影响正常工作，github监控+处罚好点。没办法杜绝，只能提高检测的手段和能力，然后加大处罚力度进行威慑。
A3：禁止github访问，或者能否做到上传和下载分开，禁止上传。不过我们公司限制是禁止不了，开发很多要用，尤其是开发过程中需要和大量第三方机构联调，没法断网。安全要平衡研发效能。
A4：github禁了怎么借鉴学习？不同行业的需求不一样，以互联网公司为例，应该没公司能禁止访问github。研发常需要下载github部分代码组件直接copy过来，或者查看gitbook的博客文档。
另外VDI云桌面方式怎么整iOS开发？做iOS开发的必须得用mac，mac上又没有合适的数据DLP工具。
A5:规章制度定好，宣贯好，技术手段能监控发现的就发现，事件驱动，发现了处罚。如果想着前期各种断，为了极小部分的泄露，影响了整个研发，我认为不应是安全的价值。
而说到mac电脑，简直就是定时炸弹,但是技术人员很多都有自己的代理,上传代码的流量本来就不多。还有些个人电脑，外包开发的代码等等。github现在随便私有仓库，扫描基本废了。
A6：现在的dlp对mac的管控也是很强的，终端dlp检测git push的动作。
Q：是不是可以尝试区分正常 clone pull 代码，上行的流量应该很小，有能实现这个功能的dlp吗？
A7:把push写进脚本,这种事件还要区分 github 还是内部 gitlab，我甚至可以用三方包来帮我做git push。要完全杜绝不可能，要绕过有好多方法，只能选个能解决掉90%的方案。
A8：想杜绝只能断网+VDI，不然只能持续对抗了。除非对代码防护要求特别高的公司，否则杜绝看来是不可能。因为还有gitlab、saas、gitee等一大堆代码托管平台。
A9:是的，github泄露监控大部分都是针对github，我之前运营SRC收到过码云、语雀泄露敏感信息。
A10:VDI解决不了用mac本开发的问题，目前好像没有 mac 的vdi 产品。技术手段管控总有绕过的方法，还是得靠管理手段，制定好处罚措施，而且要看内部员工上传github具体动机有哪些，有些技术特别喜欢把github当记事本和随手备忘录。
A11:我们正巧最近也是梳理了公司内部代码管控的现状，也制定了一些安全方案来降低代码风险。这块还是得平衡业务和安全，抓大放小，不能因为安全影响业务效率。大部分企业的代码泄露还是内部人员为主，这块还是需要管理+技术结合，首先需要通过建立公司级的数据安全管理体系和制度，把代码上升到公司核心数据的地步，让开发人员先树立起这个意识，然后针对代码仓库的认证、权限管控都是基本面保障手段。
咱们安全人员认知中的dlp+代码监控也只能一定程度防范，比如现在各种开源工具、各种公有云都能监控github代码泄露，国内很多gitgee类似的可能就成为视野盲区。代码防泄露目的还是防范大面积泄露，如果要实现风险最小化，那管控措施一定很严，会影响业务效率。像在互联网公司不让研发上网、不让访问github基本不太现实。
A12:其实大家都知道，监控，宣传，处罚，只不过付出多少成本，做到什么程度，得到什么收益而己。我们应该相信开发人员，防君子不防小人，多宣传，强处罚，大家意识强了，就收敛了。
A13:我们目前正在实践的一种治理思路，就是联合基础架构侧提供的Saas化的IDE，来确保代码不落本地，进而管控权限和减少代码泄露途径；比较类似你说的把代码圈养起来。
效果呢，还在小范围内灰度，对于我们安全侧需求比较容易达成，上面说的风险面基本可以收敛；主要对服务提供方的要求高，高可用性和体验做到接近原生IDE，另外某些场景也暂时支持不了，路还比较漫长，所以目前主要还是搭配着上面那些常规安全手段在做。
A14:云ide是好东西，类似研发场景下的VDI，研发效能有需求，安全团队搭车就好，看看安全能力怎么放进去，比如安全研发的需求。
话题2：领导问了个问题：应用漏洞数量的增降改变，是因为研发水平提高或下降了？还是安全部门挖漏洞的能力变强了，或者是应用的覆盖度上去了。如何通过一些指标和领导说明清楚这个问题呢？求各位大佬指点。
A1:是不是可以从被测系统数量和挖掘漏洞类型去粗略评估一下，或者从黑盒测试和白盒测试的不同层面说明下，或者下降可以根据某一类漏洞从时间维度上做个统计分析和对比，比如以前测出来的漏洞在新开发的系统中消失了，可以认定为研发能力提升吧。
1，网络安全监控发现了攻击，通知系统侧去排查服务器受影响情况。
2，网络攻击肯定是利用了某个层面的漏洞，然后领导问我，为什么你们网络安全运维做漏洞排查的时候没有发现呐？漏洞排查做到什么地方去了呐？
3，再然后系统侧来排查服务器受影响情况，也无法知道要修复哪个漏洞，让我根据监控清楚出漏洞情况说明报告。他们才知道去修复哪个漏洞。
A3:急于套模板都会陷入不实，领导已经在追根溯源了，这个时候第一步要做的就是深入分析，然后再抽象归类，减了为什么，首先要避免的就是安全挖漏洞马虎了，理想的是开发形成了方法规避，那么这个方法有没有被植入流程，还是就出过问题的团队在用，值不值得推广，增了为什么，安全团队增加了什么能力，之前覆盖多少，现在覆盖多少，大概要有个数；如果有机制了，那么为什么失效了；还有一种可能就是有漏洞库的更新，虽然也可以归入安全能力提高但最好分开。
这个东西不要避讳，你给我的是什么人，我只能挖市面上已公开的漏洞，未知的我就是覆盖不到，又没高手专家又没实验室，漏洞情报更新了，规则库更新了，谷歌微软都有漏洞，凭啥要求安全不遗漏漏洞呢，有开发就会有漏洞。但是，如果利用的是已知漏洞，那确实不该，立正挨罚，从机制上改正，这个批评得没毛病。
我感觉分管领导看到数字追问工作效果是常规操作，怎么用这些数字更好地反映安全工作水平，是安全运营课题。但我们的出发点不该是为了指标好看，确实该先具体情况具体分析，再设置各部门接受的、合适的数字指标，如覆盖率、分部门漏洞排名、千行代码缺陷数、安全检出率、外部检出率、复发率…这些都不是必须的，先找原因。
发现一个漏洞，也是可以做个非正式的5why回顾的，在哪个环节检出，为什么在这里检出，有哪些机制，前面为什么失效了。刨根问底的态度，值得养成工作习惯。其中最特殊的是安全检出率，这个无法从已经发现了多少应用漏洞去回答，得专门做另一件工作来检验安全检出率，试试分母有多大了，不非得做。
理解，领导问这个问题，说明他不希望安全漏洞是随机性的，发现了就发现了，没发现就没发现，要说明白个能力边界。这比上面问安全为啥没发现已经好多了，省去了艰难的转变领导思想这一步，把握领导的疑问把工作做实就好。
我觉得领导的指示很明确，甚至给出了回答模板，先去调查清楚再归类回答就可以了
回答之前要多想一步，这里有没有问题，能不能改进，有章法地归类回答。领导问的这个问题也有同类的案例：研发效能、单侧覆盖率为啥低了？缺陷为啥高了？人的问题还是CI/CD的问题？
归类回答和回答的区别是，归类是可枚举的，就那么几类问题，分类有条理，除此之外没了。CTO问这个很正常，确实得拉上研发一起研究清楚回答好，后手也要达成一致，因为措施往往意味着研发习惯的修正。
A1:得要先做好分级分类，不过这个基本上就拦掉大部分人的脚步了。
Q:人工分级？人工打标签？数据安全，是不是还有数据脱敏，数据维护、访问审计?
A2:国密改造,三级数据不要求脱敏了吗？数据好分级不好落实啊，尤其针对旧数据的处理。打标签可以是手工方式也可以是计算引擎自动打标。
A3:标签本身也是要不断迭代吧，是不是有标签树。个人感觉，先把数据安全搞起来再谈运营吧，数据运营和安全运营一样吧，你得先有基建，才能谈运营。现在数据安全基本的都有了。到了该从运维转向运营的阶段了。数据安全运营可以考虑上终端DLP和网络DLP，分级分类现在是合规驱动了。现在很多成熟的商业化分级分类产品。另外给数据打完标签以后是不是该脱敏了？
A4:对于结构化数据打标容易，但是企业内还有大量非结构化的文档 也会包含大量敏感信息，打标就没有那么容易。数据又是不断衍生和变化的。关键还在于源头管控和使用安全。
A5:数据安全这块各家场景各不相同，比应用安全还吃场景。还是先厘清自家目标，有哪些外部要求和自家管理诉求、技术方案都大同小异可互相借鉴、不涉及具体场景的数据安全大家也不好提意见，怕误导。
A6:数据分类分离太难了，要把单位里的所有文件都要查找出来，才好每个文件去分类分级。我们想做但推动不了，公司大了拉齐都挺难，不是安全部门力量就行的。数据分级分类，得懂业务也懂技术。
A7:个人觉得上DLP这个，还是初步建设阶段，运营需要将检测指标量化，并且指标能带来价值。例如:DLP的检测场景梳理出来，然后制定一定的指标关联风险场景，一旦超出指标，那么定义为风险等等，这才算运营。
A8:涉及全单位各部门推动。网络间要打通，有点复杂，还在理。不可能的，安全部门得量力而行，先从自己够的着的数据开始以及合规（或者违规处罚力度大的）开始，比如用户个人信息保护。金融的，按照数安法和个保法定了内部的标准，优先把等保系统的数据先处理了，根据这些系统的数据，定了数据脱敏规范。
A9:数据分类分级，这个靠制度，靠人。分完了呢？哪里有？哪儿用了？怎么用？最终还要有监测识别手段，然后每个公司的偏好也不同。
首先得聚焦，把第一阶段要治理的数据限定一个list,然后才是开始考虑从生命周期开始，梳理归口分类分级。一开始就想着数据治理做全，其实从各方面来说都不如先搞高级别的金融数据，如四级金融数据，三级金融数据。做了而不管的，流于形式。
A10:目前比较好落地的多是办公数据的DLP：网络上上一套防敏感数据外发外泄，终端上上一套防敏感数据明文存储，业务数据中敏感数据类型、场景需求各不相同，加密和脱敏技术通用策略不太通。
A11:偏向三级数据内也区分场景，做类似催收场景、征信场景的实验下看效果，大而全感觉还没落地就黄了。数据治理，从入门到死在分类分级定义上。当范围缩小到一定程度，自然就能往下走，否则你就是去的太广了。数据安全治理说白了是数据治理的一个分支而已，而且数据团队对业务团队有很多输出，业务团队要仰仗数据团队。所以数据团队牵头最能搞下去。可以先整理基础数据台账和行业及企业数据分级分类标准，再结合企业典型数据场景去做分析会好一些。
A12:不同阶段关注点不同，始终还是要围绕公司发展，业务发展自上而下的落实关注关键风险。安全是为业务服务，做数据分类分级是为了更好的做数据安全，数据的类别，级别应用在安全管控措施上，如数据加密，数据脱敏。
A13：我记得一位大哥说的很好：最好去做数据治理+安全而不是数据安全+治理，数据安全太强业务关联了，外挂式最多只能做校验。我们行就是数据团队在牵头做，安全团队只是支持，因为银行的数据治理靠安全团队是做不了的，业务数据的分级分类也是数据团队在做。
最后，不管是数据安全还是网络安全，信息安全，我们应分析他们的暴露面，风险点在哪里，然后再采取对应的手段或措施。
A13:从百度上查了几篇数据安全运营的文章，供参考：
-
关于数据运营安全：https://zhuanlan.zhihu.com/p/341970227
-
以运营思路开展数据安全管理工作：https://www.3wcoffee.com/qfnews/detail?id=5369
-
https://baijiahao.baidu.com/s?id=1686923518298179349
-
https://blog.csdn.net/rlnLo2pNEfx9c/article/details/111658981
-
推荐2本书：《穿越数据的迷宫：数据管理执行指南》、《DAMA数据管理知识体系指南（原书第2版》。
本周群里共有 113 位群友参与讨论，群发言率为25.33%，群发言消息数为 486 条，人均发言数为 4.30 条。
本周群里共有 145 位群友参与讨论，群发言率为42.78%，群发言消息数为 430 条，人均发言数为 2.97 条。
![如何有效杜绝员工github泄密？应用漏洞数量的增降改变 VS 安全与研发能力向上汇报？数据安全运营怎么做？| 总第140周]( "如何有效杜绝员工github泄密？应用漏洞数量的增降改变 VS 安全与研发能力向上汇报？数据安全运营怎么做？| 总第140周")
来源：《2020中国安全运营中心调研分析报告》---赛迪顾问
--------------------------------------------------------------------------------
【金融业企业安全建设实践群】和【企业安全建设实践群】每周讨论的精华话题会同步在本公众号推送（每周）。根据话题整理的群周报完整版——每个话题甲方朋友们的展开讨论内容——每周会上传知识星球，方便大家查阅。
如何进群？
原文始发于微信公众号（君哥的体历）：如何有效杜绝员工github泄密？应用漏洞数量的增降改变 VS 安全与研发能力向上汇报？数据安全运营怎么做？| 总第140周
评论