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