“第八期清流派企业安全沙龙”于8月10日举行。
本期沙龙的两个议题是：“等级保护2.0”与“安全团队趟坑系列之安全开发”。
1、等级保护2.0
本次沙龙讨论了等保2.0的一些改动与实质性的内容，讨论内容从几个层面切入：测评对象、测评流程、测评差异项、等保高风险项以及一些实时性问题。
一、测评对象：
测评对象上更加贴近了当前互联网发展，新增了、也区分了很多平台与系统的测评要求，比如：除了通用要求以外还有云计算（Iaas Paas Saas）、移动互联、物联网、工控系统，由于笔者行业经验有限，物联网、工控可能并不了解，但云计算方面大致研读了一下，在责任划分上比较清晰，比如使用了Iaas服务，那么物理层以上的归自己测评，Pass服务则应用级以上自己测评，如果采购了Saas服务则账户体系等由自己测评，总归一句话：自己那摊子事自己测评。
二、测评流程
测评流程分为：确定定级对象——初步确定等级——专家评审签字——主管部门签字——公安备案审查——最终确定定级
定级对象：其中定级对象根据系统面向对象（如面向内部还是面向社会群众）、系统内存储与传输数据的敏感程度（如是否有真实的用户手机号、身份证等信息）以及存储的量级等，在定性过程中其实可以考虑更同行业、同类型系统去对比
专家评审：近期卡的稍微严格了一些，建议聘请三位外部专家（具备评测资格资质的）共同评级并签字，备案期间会检查；
公安备案审查：近期临近十月一，由于之前发文说十月一之后公安部将不再接收等保1.0的报告，所以最近定级备案、等保测评的比较多，目前北京地区貌似海淀非常火爆，其他分局还好
三、测评项差异
总体来讲更加务实一些，之前演讲时做了几条总结：
删除过时攻防姿势，新增应对新型攻击要求
删除审计结果报表，重视审计过程记录
网络边界的访问控制细粒度强化
个人信息保护要求强化，强化账户系统
可信计算技术建立系统到应用的信任链
降低内部人员专人专项，加强外部人员安全管控
加强外部与自研服务系统安全检测，加强漏洞风险管理
管理制度方面其实大部分企业都是对内一套对外一套，对内务实对外务虚
四、高风险项
等保高风险项很快随之而出，大概分为两块：1、网络设备、安全设备、主机设备；2、应用系统。整体来讲在细则上可以做一些总结提炼：
1、弱口令、默认口令、
2、远程管理防护
3、双因素认证
4、恶意代码防范
5、审计措施
6、不必要服务处置
7、已知重大漏洞修复、测试发现漏洞修复
8、用户权限管控
9、访问策略管控
10、数据完整性、保密性（传输、存储）、备份恢复
11、数据采集、存储、使用、访问以及敏感信息处理
五、其他实时性问题
沙龙期间交流一些近期各公司在等保相关工作中遇到的实质性问题，比如关于云备份的情况；数据中心、办公地、测评地点的关系；不同测评机构更换带来的问题；近期等保相关的材料等，由于属于闭门会议不在公众号做过多分享~~~
2、安全团队趟坑系列之安全开发
安全开发团队的建设并不是每个企业的必选项，但针对安全需求的定制开发确是越来越多企业的需求。从行业整体情况看，安全需求趋于复杂化、差异化。标准的，大而全的产品未来很难满足企业安全需求。先看脑图：
从开发方式上看，有如下选择：
1、自己招人，自建团队。自己组建开发团队是很多安全团队的梦想，有了自己的团队，不仅可以全面掌控需求的实现，也可以让团队的逼格全面提升。招人的时候你会发现会有三类人供你选择①懂开发的不懂安全；②懂安全的不懂开发；③都懂的招不起。土豪公司当然可以直接选择都懂的高手加盟，但是对于大部分企业来说一定要有个抉择。我们建议选择①，原因很简单安全团队不缺懂安全的人。
2、人员外包。通过人员外包的方式可以快速组建团队，但除了前期团队组建时期对人员把关之外，还涉及到三个问题。①团队管理难，毕竟生杀大权不在安全团队leader手里；②团队稳定性差，根据经验，外包开发团队的人员稳定性相对较差；③难以保障知识产权，代码都是别人写的，想保护知识产权的代价是非常大的。
3、定制开发项目。通过项目的方式进行定制开发，避免了招人和团队管理的复杂性。但选择定制开发前，需要安全团队对需求非常明确，否则项目很难验收。另外，后续迭代大概率还需要用之前的合作方，在流程上存在一定风险。所以定制开发项目适合需求明确，后期迭代需求不大的项目。
开发方式确定后，进入到具体开发工作，也不是一件容易的事。
首先，我们要确定自主开发范围。任何一个团队都不是全能的，所以我们建议通过自主研发实现的工作至少应该满足下面有三个特点之一。①市场上没有（或很少有）能解决此类问题的产品；②企业对某方面的需求是市场常规产品无法满足的；③安全团队可以明确的设计产品运行逻辑，一些具体的技术难点可以单独攻关，但总体逻辑都说不清楚，很可能会使项目流产。
其次，要选择一个合理的迭代方式。一般说来我们借鉴互联网公司“小步快走”的模式。这样的好处是一方面可以频繁试错，避免犯大错。另一方面可以给用户一个持续的刺激。
第三，产品设计。从笔者经验来看，系统的复杂程度和系统推广的难度成正比的关系，所以强烈建议在系统设计的时候要充分考虑易用性。尤其是非安全部门内部使用的系统（比如工单系统）的开发，一定要考虑好用的问题。
最后，代码安全。一个每天发现别人系统漏洞的团队开发的系统，如果出现漏洞是一件非常丢人的事。就像一个资深安全工程师设弱密码一样丢人。所以安全团队输出代码的安全性最好不要出现安全问题，这是颜面问题。
最后我们探讨一下 自主开发的优势和劣势。
先说优势：
自主可控：对于一些重要的产品，代码和策略上的自主可控还是很重要的。可以有效避免安全策略被轻易突破。
贴近需求：文章开头就提到过，越来越多的企业对针对自己在某个垂类的特殊需求，通用的产业产品很难完全符合这类需求。这就需要开发能力的介入。
方便迭代：在攻防技术不断迭代的今天，很难有一个能力能一劳永逸的解决某一类的问题。企业安全团队作为防御者，如果有开发能力，就能掌握产品能力迭代的主动性，在对抗中取得一定的优势。
再说说劣势：
成本不可控：除非开发需求完全明确，而且期间没有任何技术攻关工作。否则投入的开发成本就没法做到完全可控。、
产品价值生效较慢（对比商业产品采购）：自主开发产品对比采购商业产品来说最直接的劣势就是速度了。
管理成本高：增加团队的规模，会在一定程度上增加管理成本，这很好理解。另一方面，如何平衡安全开发团队和安全需求团队之间的关系也很重要。
团队稳定性影响产品迭代速度：一般来说，企业安全开发团队不会很大。这种情况下，每个人员的流失对团队的影响就比较大，如何保证小型团队的稳定性，并对流动性进行充分预估是管理者需要思考的问题。
由于多方面因素，对于一些比较敏感的话题无法全面展开，欢迎有猛料的兄弟来报！非常感谢所有参加沙龙的同学（排名不分先后）：航天云网杨、贝壳陈、快手李、蘑菇韩、58到家刘、爱卡刘、国网电商张、瑞安魏&符、航天霍、正保晨、央视网黄。
声明：本文来自清流派安全，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
