前言
两年时间在企业安全上能做什么，笔者尝试挑战了一下这个问题。截至写这篇文章时，还有一些子领域做得不太好，不过既然时间差不多2年了，就拿出来分享一下吧。
对于企业安全建设，能说出来的人很多，但能落地庞大安全体系的人极少，大多需要5-10年。
范围对象
笔者任职公司是一个拥有数亿用户、各种各样的业务、几十个APP、几十万Server OS实例、数万雇员的公司，并且有多家投资公司，上下游有大量产业链合作伙伴，还有跨境业务。
在这种体量的公司规模下，先简单解读一下面临的挑战及安全需求：
1. IDC规模决定不可能用“买买买”搞定这摊子事，也不可能依赖开源软件，只能开启大规模自研之路。
2. IT雇员规模虽然不是互联网行业最大，但也是非常庞大（数万），并且呈现高度的地域离散化和移动化，除了BeyondCorp之类的搞不定。
3. 不只是做自己的企业边界内安全就可以，还要兼顾投后赋能、第三方、（数据）供应链安全；边做自己同时还要兼顾生态安全。
4. 建团队不能只靠HR、猎头，用常规手段多半是2年也建不起来能消化这些总需求的团队。
目标设定
对于一个体量虽然不是最大，但跟最大的互联网公司业务形态非常类似，技术栈广度又比较接近的情况而言，在结果上必须达到一线互联网公司将近全部的安全能力，才可以认为满足当下的需求。
设定这个目标并不是表面做做，或者为了PR的需求，而是真实的需求。稍微展开一下有几个很关键的因素：
实事求是地讲，一线互联网公司安全水平70%-80%左右的能力，并不是一个行业很高的标准，对于大多数公司来说这只是一个真正意义上及格的水平。原因在于70%-80%能力大约也就实现了相对系统化的安全体系，安全能力覆盖率接近100%，在重点技术栈部分有纵深防御能力。纵深防御在很多场景下是及格的入门标准，熟悉攻击的人都知道，单层防御没有兜底方案被突破的概率很大，结果往往等同于安全能力不及格。
那有人也许会问，照你这么说市面上那么多公司都不具备所谓的纵深防御能力，他们全都不及格么？真相总是残酷的，笔者也无力回答这个问题。
另一方面，仅仅“满足当下的需求”并不一定能适配未来的发展，有可能跟不上未来互联网/IT技术本身的发展，或者表现出安全阻碍业务的效率（不是说安全绝对不阻碍业务，而是说相对行业水平来说拖后腿）。
挑 战 1.
没有人
没有人可能是最大的困扰了，如此庞大的安全体系One man army是不可能的，说的再好，安全负责人的知识结构再完整也无济于事。且要实现这种目标必须让团队具备全栈的能力，不仅仅是web，也不是加二进制就够了，而是开发、算法、隐私保护、运营各样各样的全都需要，最终安全团队的技能需要覆盖互联网全技术栈和所有的安全领域（工控这种小众一点的除外）。上哪儿去搬来这样的团队是个大考验，而且我们还是有倒计时目标的。
很多时候我们看一家公司的安全能力，不妨先从侧面看看他的安全团队的知识结构和技能，这样往往可以印证是不是跟他PR的一样，也可以作为一种侧面窥探安全能力的参考。譬如，一个安全团队规模不大，假如只有30人以下，那么他基本不太可能具备大规模自研的能力，也不可能去实践纵深防御体系。如果一个安全团队的技能主要以web安全为主，主业也是一个webservice为主的简单业务，是不是能说安全可以cover了呢？答案是否，因为资产技术栈和防御技术栈不对等，资产技术栈比攻击面选择性稍微大一点，但通常远大于web的防御技术栈，所以一旦攻击涉及到二进制层面就可能不能从容应对，从现实来说小安全团队的组成选择主营业务对口虽然无可厚非，但苛求结果的角度来说不会特别理想。
反之，如果团队的知识结构没有问题，而效率、ROI不理想，那么最大的瓶颈可能在安全负责人。尤其当主营业务相当挣钱，对安全不是那么计较投产比的时候，往往很容易掩盖这个问题。
挑 战 2.
工程能力
对于很多市值100亿美元以上公司的安全团队来说，他们的真实瓶颈往往不是安全技术能力，而是工程化能力。这种所谓的工程化能力体现在能把自研的安全产品、安全系统落地于海量分布式环境，落地于规模庞大的组织的IT系统上，且不降低性能，不影响可用性，不出故障和运营事故。做一个安全产品demo是相对简单的，但也只是第一步，很多人以为随便凑几个RD便可以开发出安全产品部署到数以万计的系统上，但结果往往会半途而废。预估不足就在于安全方案设计，规则运营，数据分析都不是最难的，难的往往是性能和可用性。
这也是国内互联网公司安全能力跟全球头部公司比安全能力受制约最大的地方。
笔者就职时这家公司的其他技术领域已经有较大的发展和积累，对运维事故、可用性都有严格的定义和管理，大多数系统都有比较苛刻的逐年提升的可用性指标，对安全建设来说最大的坏处是你已经享受不到不用背负事故指标可以随意发布的红利，而是既要……又要……还要……在这种情况下，两年内研发出十几个安全基础组件覆盖所有的APP、服务器、员工终端、网络流量、敏感数据是极大的挑战。
强调工程能力和全栈技术视野的另一重影响是：这个因素直接决定安全团队和其他团队（SRE、IaaS和PaaS研发、业务研发）的沟通宽度。当两者之间的沟通管道越窄时，安全团队越容易落入自嗨，越宽则有利于作出接地气的项目。
挑 战 3.
向上管理能力
经常听到一些声音，诸如：§
l “老板不重视安全”；§
l “不给投入资源”；§
l “领导是个外行”；§
l “安全就是个背锅的”；§
l “业务方完全不懂安全”；§
……§
如果你不是问我建设性的建议而仅仅是针对这些现象的看法的话，那么我认为“以上全错”，只有一个真实的原因，那就是安全负责人的基本功不到位，甚至有些观点很危险。
做一个大安全体系需要的能力，已经远远超越纯技术层面，不能跟高层建立正确的沟通语言，肯定是做不出来的，因为这里面有太多的事情是需要上下同欲、横向对齐。即使送你100张安全体系的图背得滚瓜烂熟，给你一支现成的100人的全技术栈安全团队，缺了这个能力，你还是会发现安全体系很难落地。
就像笔者写《互联网企业安全高级指南》充其量只是写了些事情该怎么做，但实际一点没说CISO该怎么做，所以很多读者会发现即使看了那本书想在自己的企业里落地，但总感觉哪里还有点问题。现在我来解这个困惑：最大的Gap还是在实践者的管理基本功和全栈技术视野。
挑 战 4.
推动能力
在海量基础设施和复杂系统中落地考验的是工程能力以及自动化运维水平（后者通常不是大问题），但这只是面向机器的部分，而安全能力不可避免有面向人的那一部分，且比面向机器的部分多的多，譬如几个月内让几万雇员全部安装杀毒软件这无异于进行一场整风运动，连乙方的安全厂商都没听说过有甲方能这么干的，且这种手段如果屡试不爽是一定会有大的副作用的，而我们设定的时间要求，必须多次、强制、强势、无反弹的发生类似整风运动这样的事情，这个极其考验文案、沟通和推动能力，如果你的团队是一群纯“蓝军”组成的，连个正儿八经能沟通的人都没有，那么恭喜你，mission impossible！
笔者也曾听说过直接让安全工程师改写不合规的员工电脑桌面，不知道为什么，第一反应是安全工程师跟安全负责人有仇，想让安全负责人尽快下岗。守正出奇应该是一个主旋律，奇的方法偶尔用一两次还行，如果高频率的反复用，安全团队可能很危险。
挑 战 5.
专业技能 ？
如果有第5点的话，我想可能是安全负责人本身不能是一个外行和纯管理者，因为2年时间没有算进一个外行管理者自己学习、消化和错误决策的成本，而是只有紧凑的执行时间，也即是对怎么做不需要思考，而是要在落地效率上快马加鞭。执行速度加快意味着自己需要知道怎么做，而不是反复选型、验证、推倒重来。也不允许对人和项目上有太多的试水和推倒重来。简单来说，自己既要知道怎么做，又要知道招的人能不能做，还要知道人做的好不好。（这句话写起来很简单，实际要做到极难）
分解安全体系
图示的安全体系是一个较通用的技术沙盘，适用市值百亿到千亿美元公司较通用领域的安全建设。当然这只是个一级技术沙盘，没有展现更多的细节和实现，也没有业务相关性，主要给《互联网企业安全高级指南》做一个面向实操的update。因为书没有空写第二版，所以就零零碎碎把一些需要及时update的东西写出来。
另外这张图只是展示了传统意义的安全能力，没有展现对内的监管、审计和内控。只做隐私保护与网络安全是不够的，这只是狭义的安全；广义上的信息安全仍然有大量对内的工作要做，当然除了安全外，还需要做一些赋能业务的事，你可能觉得光光是这些安全需求已经很多了，难以消化，如果加上对内监管和业务赋能，那事情又比这张技术沙盘多出一倍。也不知道看官们是怎么定义安全工作的，笔者认为安全做的再好，价值也是有限的。所以笔者所在的安全团队从来不会只做纯安全。
对于技术沙盘中涉及的具体内容，笔者会在另一篇文章《下一代互联网企业安全架构》中展开。
实现和应对
那说到底这些事情该如何做呢？我们来谈谈从安全负责人视角（而不是安全工程师视角）展开最重要的事情。这些事情比研发HIDS，态势感知这些具体的项目重要的多。
安全治理框架
首先团队的技术能力是一种硬能力，这个几乎没办法去讲有什么捷径。但是对于安全体系而言，首先要做的是建立安全治理模型，明曰模型，实际不是模型，而是一套公司内的安全权责框架，能代表安全团队本身去推动项目落地，尽量由人为推动变成“轻推动+自我驱动”。安全团队可能挂靠于各种技术、平台、职能团队下，跟CEO之间往往也不是一级汇报关系，本身的组织层级和影响力都是有限的，如果全都靠安全团队自己去推那就比较累了，所以一定要借虎皮，而且是名正言顺的。
建立公司层面的风险统筹视角，并建立相关的虚拟组织对公司/事业群/业务单元风险周期性的评估和控制，对于安全团队而言相当于有了一个更高级的推手，当然不是说所有的事情都需要通过借虎皮这种方式，其实大部分事情，如果安全团队本身的沟通表达能力比较专业的话应该寻求内部消化，借助更高层级通常仅限于重后果、高频率、大范围、反复性的事情。对于这个问题其实也不是说一定要这种形式，任何可以借势的方法都可以认为是常规手段。
安全管理怎么做最好其实是没有标准答案的，所以笔者在这里也不过多的列出自己的解，避免限制大家的想象力。
对于安全负责人来说不能一上来就陷进技术视角，而是要为团队打开道路，否则安全团队产能高，但落不了地，结果还是不好。
业界对标
以笔者长期的观察，在甲方企业安全这个领域国内没有公司真正进入“无人区”，都还是有学习和模仿的对象的。积累不足的创新很多时候其实是自嗨，本质上是由于知识量或视野不足，不知道在世界上已经有一个更好的方法而已。在小一点的公司可能周遭人的知识不足以挑战你，在大公司这种形式上的“创新”则表现为人力和资源的浪费，想到哪里做到哪里往往是安全体系建设效率低下的原因。
对于国内的二三线互联网公司大多在整体技术积累上不表现为太领先和前瞻性，追求安全上的创新笔者认为无此必要，因为从安全团队的普遍职级、知识结构来看，能完成真正有意义的创新的概率极其低。那是不是完全不需要创新，也不是，跟业态相关的还是有的，譬如全球只有你所在的公司有这种业务形态，那还是有机会去思考对应的独特解决方案。
对于绝大多数公司而言，业界对标有助于快速识别自己的短板并且相对系统化的进行建设。安全本质上属于风险管理大类的工作，这类工作最忌讳：有10个风险，今年做3个，明年再做2个，看上去每年的指标还提高了，是不是绩效很好了？外行领导可能会陷入这种业绩不错的假象里。如果不对全局结果负责，还缺了50%的风险都没有得到控制，属于工作做得非常差。做安全的同学，尤其是作为Leader，负责某个领域或者几个领域，可能经常会被上级问及一个问题，就是安全做得好不好，我也看到过公司高管问下面同学这个问题，立马回答好或不好的，其实这样子的回答完全没有意义，因为好或者不好要看跟谁比，要视资源投入和时间效率来衡量产出。
假设以一家一线公司的安全高投入的结果去跟一个二线公司比，即使小幅领先也是差，但是如果同体量级别公司中，如果能力和效率大幅领先，甚至赶超上一个级别的公司，这种结果才有比较的意义。
以笔者所在的团队为例，我们会根据公司规模、竞争环境、技术整体成熟度，结合团队的落地实现能力去阶段性的选择不同的对标和参考对象（具体来说我们现阶段会对标全球互联网行业的头部公司；部分产品设计领域对标科技行业的某些头部公司；在地域、国情、业态相关的子领域会参考国内的一线公司，当然为了给团队设置高标准的底线，末了还会加一句其他公司暂时不参考）。
高标准对于任何一个有追求的团队来说都是不应放弃的底线。“要做什么事继而选择什么人”跟“有什么人继而选择做力所能及的事”，这代表了国内安全团队的分水岭。考虑团队落地能力主要是防止揠苗助长的行为，譬如对于一个10人安全团队，非要去模仿Google那种全栈自研的安全体系确实属于目标设定失误。
对于安全负责人来说，如果你所做的事情整体格局低于公司所处的市场地位，那么你可能危险了。因为在老板眼里，你是所有职能模块里拖后腿的那个人。很多同学不明白公司大了为什么总要去给自己空降一个更高级别的安全负责人，大抵就是这方面的原因，格局的修炼没办法在短时间内靠勤奋速成。
是不是这些东西太虚了，其实也不是，一方面是管理基本功，另一方面是专业技能和技术视野。除了对于安全理解还包括对于安全以外的互联网通用技术的理解。如果你了解一种攻击缓解机制，这种机制能否大范围的用在办公网络的PC，还是大规模运用于生产环境的IaaS，实现方式上能满足自动化运维，能支持熔断降级、尽可能不影响性能和用户体验，攻防角度对抗性价比最高的拦截检测点，综合衡量后的实现方案。强于单点对抗弱于工程技术，或者倒过来都可能造成误判。所以广大的安全从业者可以用一个尖锐的视角去评估现有团队的瓶颈，那就是看安全负责人本人的知识结构和平衡性。
如果你不是CISO，而是纯高P，最忌讳的就是你给不出在这个子领域的业界最佳实践的解，凡事都喜欢自己造轮子，又不能证明生产力，就容易让团队陷入尴尬的境地。
在实操上，进行对业界对标时，我们会评估对象在子领域的成熟度，但凡只有Demo，没有覆盖率，没有实际的数据化迭代运营，我们都评估为目标公司在该子领域不具备实际能力。举例来说做一个anti kernel rootkit的demo很容易，但只要没有大规模应用，我们就认为不具备能力。Demo可能有PR的价值，但是工程落地上直接对标可能会产生误导效果。
安全研究
安全研究严格意义上来说算不上是一个安全的子领域，因为安全研究存在于每一个安全子领域，单独拉出来说是因为大多数安全团队的组织结构反映了这是一个中长期投入的事情，可泛泛的理解为KPI导向相对模糊，有些甚至是纯PR。安全研究没有做的好和不好之说，只有相对接地气和不接地气。“未来长什么样是没人知道的”，这句话有两面性，一种代表不设限，消极地看则是无视成本和投入。
为什么要在这里提安全研究，因为对于安全团队到达一定规模以上，哪怕是两年的“闪电战”也必定会涉及，只针对当下做100%的安全运营是不可能满足业务增长需求的，甚至当其他公司的团队也在小步快跑时，你只选择对标当前状态就会永远被人甩在身后。弯道超车并非不可能，关键在于要对标别人的未来状态，这句话是不是逻辑有问题，其实对标大部分公司的未来状态都是有可能的，因为相对于他们自身的业界标杆而言，他们自己也是在学习和模仿的路上，所以这件事的门槛在于你是否能看到业界的发展路径，如果团队能力差不多，那么直接奔下一个点去就会事半功倍，所以整件事情达成效率的关键还在于你能否开启上帝视角，其次就是你在具体的项目上能否判断是选择新建，照搬，改进还是因为环境问题选择性略过对应的安全特性，这些决定了效率。
具体到实操上，安全研究这件事可以分为短期、中期和长期。短期定义为领导厂商已经成功落地的成熟技术，其余厂商不具备，但我方整体技术环境ready，可以选择研究（实际上等价于分析）然后复制。中期是目前行业的必然技术趋势，2-3年可见，进行预研和转化。长期（定义为3-5年）则是真正意义上为进入“无人区”做准备的，通常只有处于领导市场地位的公司（或挑战者象限的公司）才有此类需求，这类研究需要管理预期，大多可能会失败，没有结论或没有应用场景，需要容忍投入损失，目测国内有此类实际需求的公司不超过5家。
PR、顶会论文、应用场景、落地产品和服务，这些永远是在安全研究投入上需要平衡的话题。笔者根据自己所处的业务环境，选择以能实际落地的短期研究为主，辅之以有应用场景的中期预研，次之可以选择PR，在没有进入无人区的预示前不会选择进行长期研究。这个选择完全是应时应地制宜，只是一个trade off，结论也不是长期稳定的，会随环境的变化而变，且预计两年内会有调整。
限于篇幅和码字太累，此文先收笔到这里，关于达成两年闪电战的关键因素其实还有一些，譬如如何评价和改进安全建设这些打算单独成文。
小结
最后总结一下提升效率的几个关键因素：
1. 视野平衡性
2. 管理基本功
3. 他山之石可以攻玉
4. 全局推进方法论
5. ……
