《绿盟 - RSA2017浅谈下一代应用及IT基础设施的安全管理模式——DEVSECOPS》
DevSecOps是2017年美国RSA大会新出现的一个概念，大会甚至专门为这个概念和方向设置的议题和讨论会。DecSecOps是一种全新的安全理念与模式，从DecOps的概念延伸和演变而来，其核心理念安全是整个IT团队（包括开发、运维及安全团队）每个人的责任，需要贯穿从开发和运营整个业务生命周期每一个环节才能提供有效保障。来自Garnter研究公司的分析师David认为，当今的 CIO 应该修改 DevOps 的定义，使之包括安全理念变成为 DevSecOps。DevSecOps是糅合了开发、安全及运营理念以创建解决方案的全新方法”。
安全厂商的研发能力总体不如软件公司，而且很多产品还有实习生参与，现阶段不能奢望安全设备自身的安全性有多强，和互联网公司比又没有留人的竞争力 一些老产品甚至都没人在维护了。
其实所有的问题都围绕着一个主题，增加攻击成本。如果增加攻击成本的系统本身出了问题。那么他就处于这个网络攻击链环之中了。
安全厂商爆漏洞是不可避免的，毕竟很多安全厂商的研发人员也不是做安全的，做出来的安全产品也一定会有安全问题，内部也不全是安全SDL流程。怕就怕供应商反应慢，厂商不承认，通知不到位。
0day 目前建议有足够数量的安全人员的企业做。先把基础安全做好并优化以后，干的事情。【毕竟需要人力和财力支持】，一般企业重点还是把基础安全做好，策略规则优化监控告警为主。并不建议投入太多人力自研安全产品或者系统。
【☆】我们对自研安全有一定的需求，但是没能力，所以短期不会上，合作研发，外包研发可能会有，之前提到某单位和某单位合作研发单兵作战工具就是例子，我们也期待这样的合作。短期我们解决0day的方式，是增加APT设备，对攻击行为进行识别，毕竟0day不具备可预见性，但是攻击行为是有一定模式的，目前部分厂商搞得攻击模型，机器学习等产品，我们都很感兴趣。
现在稍微有点钱的企业已经开始重金挖人，自研安全设备只是对内安全建设的任务之一，哪怕是重复造轮子，出了事好歹能自己修复，不然只能等厂家更新，甚至厂家会甩锅。
个人观点：（我从个人角度，非常认同这位大佬说的，从安全研究人员角度来说很现实）
（1）对于企业来说是否要自研安全产品，更重要的应该是安全团队是否有能力做这个事情，因为你至少要专门招几个专职做这些事情的人，在HC这方面或许就实现不了。
（2）产品自研成功后，便需要专人进行维护，假设之前产品的研发者离职了，于是需要重新招人，然后重新熟悉代码，再进行专职维护更新。
（3）假设是从0到1开始的，我觉得还是先买商业化产品，然后等安全团队稳定了，上面两个条件都满足了，再考虑是否自研。
（4）如果安全团队完全有能力，那么肯定还是要自研。
3、在红蓝军对抗过程中，美人计、声东击西等“计谋”层出不穷，你经历过哪些攻防演练“三十六计”，欢迎分享避雷。
1、你说的这几种倒是没遇到过，不过红队用的比较多的是用大量扫描器制造海量日志，增加分析难度，然后在里面夹杂针对性的攻击。
2、还有从段子里面听过，红队创建虚假的“蓝队交流群”，然后在里面收集信息，发布和污染蓝队的信息。
3、演练前一个月花钱找人去应聘面试的一大把。
4、总结一些蓝队溯源反制小技巧：
-最好的蓝队溯源——微信群：xxx你们谁认识？
-我们是直接找对应的接口销售，登录他们的内部通信软件，比如钉钉，直接搜姓名，然后去匹配简历啥的，命中率极高——这种也算社会工程学溯源。
-再讲一个溯源点，我们反制了攻击队后，通过系统读了序列号出来，然后找联想接口查谁买的——硬件序列号=订单号=采购厂家。
2、文化的挑战
安全通常是作为独立组织存在，且与研发和运营分开。此外，在IT人员的概念中，安全往往会增加IT人员额外的工作量，拖累项目的进度甚至延期，因而IT人员与安全往往站在对立面。同时研发人员和运营人员大都不懂安全。由此造成的文化与意识壁垒，一时间很难打破。
3、安全知识和技能薄弱
DevSecOps需要研发、运维及安全人员协作，共同承担安全职责，可站在对方的视角看待问题。但是对于研发和运维人员来说，往往缺少安全意识及技能，在系统设计开发及部署运维等环节，无法高效协同保障安全性。
3、构建DevSecOps工具链
DevSecOps主要分为10个阶段，分别是计划（Plan）、创建（Create）、验证（Verify）、预发布（Preprod）、发布（Release）、预防（Prevent）、检测（Detect）、响应（Respond）、预测（Predict）、适应（Adapt），其中预防（Prevent）在之前的版本里也有叫做配置（Configure）。
