初期三件事
- 事前的安全基线
- 事中的监控能力
- 事后的应急响应
其实做攻防和研发安全产品完全是两码事,存在巨大的鸿沟,如果拿做攻防的团队直接去做安全工具开发,恐怕挫折会比较多,即便有些研究员擅长做底层的东西,但对于高并发生产环境的服务器工具而言,还是有很大的门槛。另一方面做攻防和做研发的思路也截然不同,此时其实是在交付产品而不是在树立安全机制,所以往往要分拆团队,另外招人
如何推动安全策略
公司层面
推动安全策略必须是在组织中自上而下的,先跟高层达成一致,形成共同语言,对安全建设要付出的成本和收益形成基本认知,这个成本不只是安全团队的人力成本和所用的IDC资源,还包括安全建设的管理成本,流程可能会变长,发布链条会比过去更长,有些产品可能会停顿整改安全,安全特性的开发可能会占用正常的功能迭代周期。程序员可能会站起来说安全是束缚,这些都是需要跟各产品线老大达成一致的,他们要认同做安全这件事的价值,你也要尽可能的提供轻便的方法不影响业务的速度
战术层面
很多时候我认为甲方安全团队思路受限的地方在于:总是把安全放在研发和运维的对立面上,认为天生就是有冲突的。
其实有些问题处理的好,真正让人感到你提的建议很专业,研发和运维人员不仅会接受,而且会认为自己掌握了更好的编码技能或者安全配置技能而产生正向的驱动力
程序员鼓励师是一种实施层面的权宜之计,同时反映出安全行业比较缺少既懂技术且情商又高的人
安全需要向业务妥协吗?
安全建设