不要学习业界最佳实践
安全方案保持超前,不接地气
表面省钱,什么都坚持自研
安全研发不懂安全,研发安全不懂研发
喜欢简单重复,避免自动化
以安全自High为中心,避免“客户至上”
安全建设的上限是蓝军的下限
全体躺平,让有责任感的成员占少数
坚持做“自下而上”的安全
做临时方案,避免做长期正确的事情
如果你想让一个信息安全团队做得一年比一年差,我这里有一些忠告建议,可以帮助你搭建一个失败的安全建设团队,请一定要按照以下十条建议去做,否则你的安全将建设得越来越好。
要让安全团队倒闭首要建议是看到各种安全会议眼花缭乱的PPT就抄在自己团队的规划里,牢记零信任、切面安全、内生安全、DevSecOps等一个都不能少。要成功让一个安全团队倒闭,就要坚持不研究业界更高体量公司的最佳实践,只局限于参与同等水平或者更小体量公司的视野。要照抄其他公司安全方案,少去思考为什么做这么做,背景是什么,有没有更好的路线,尽可能从自己的失败中学习教训,而不是参考别人的经验:)
一方面要不对标,一方面要确保你的安全方案是安全自以为是的,就强制覆盖到全公司,保持自己的安全方案照搬到另外一家公司也可以,不要考虑所在公司的实际情况,只考虑当前安全技术对自己岗位能力的匹配度。哪怕是超前的安全方案,只要是“面向简历有利”的安全方案都可以推行。
保持“谋杀”团队成员职业生涯的法宝是让他去自研一个夕阳产品,而实际自己就几个人,几条枪,不是专业研发,也没啥专利,坚持让当前宝贵的人力去做所谓的自研,千万不要用手头的预算购买成熟的商业产品,别把人投入到更有价值的岗位上去,因为这样会少安全会议谈论的资本。
要让做安全产品开发的小伙伴一点儿不懂安全,保持合作的高昂成本。做防御产品的技术人员要一点也不懂实际的安全价值,只管按照开发文档去实现功能,别去考虑实际的安全场景。
做产品安全的小伙伴要是攻击队出身,最好没有认证鉴权加密的安全基本功,和业务对接安全时要照搬安全编码规范和测试指南,不要去考虑开发细节,给出僵硬的修复指导,让一线研发自己去查资料。
重复机械的活动让团队成员心理更有稳定感,建立喜欢重复5遍以上的手工劳动的文化,排斥做自动化的开发,保持安全是个经验活动,而不是软件工程科学。
安全团队没有客户,只考虑自己安全圈里的技术对抗,千万不要将各个业务团队视为自己的客户,业务不配合安全是业务的价值观有问题。安全和业务要做到零和博弈,有你没我,有我没你,不要做安全工程师考虑客户服务,不要做赋能业务,要沉迷于领域内的安全攻防技术。
拿着安全的锤子看啥都是钉子,做出来个安全产品就套用到各个业务模型,哪怕自己已经不适合serverless、大数据、微服务的产品,依然要套用起来,花大力气让业务进行改造适配,而不是思考自己的产品是不是能给业务带来收益。
要妥协于蓝军,安全团队要保持被蓝军牵着鼻子走的节奏,坚持眉毛胡子一把抓去修复蓝军发现的问题,case by case的去解决,而不是区分优先级去耐心建设。以一年一度的护网为最高目标,没被打穿就是我们建设的好,被打穿就解释说是视野范围内的问题。
团队中虽然要有勤恳的老黄牛式员工,明星员工,但要保持新员工能力低于团队50%水平,持续让有责任感的员工跑路。让团队里做攻击的小伙伴占大多数,将工时作为绩效指标。保持“向上管理”的能力,建立安全是个风险管理,安全哪怕做的更好、更差都没啥用的价值观导向。
千万不要“自上而下”给予顶层设计和资源支持,让安全工程师自发地做出视野范围内的事情。哪怕是方向错了,只要大家努力了,人人有事干,事事有人管,就达到了安全团队存在的要求。另一个要领是领导说啥就干啥,忘记了是国家和人民托付给我们做安全,大老板是中央网络安全和信息化领导小组组长。
濒临倒闭的信息安全团队牢记自己是“临时工”,自扫门前雪,哪管事后洪水滔天,假装努力解决眼前的问题,掩耳盗铃地选择性地做简单容易拿绩效的事情,满足于做临时解决方案,千万不要复盘,反对举一反三,避免做长期而正确的事情。
如果读者有更好的办法可以让安全团队垮掉,欢迎关注微信公众号,私信作者一起交流。