第二篇 ：次集成时代及服务交付
--- Web 安全，应用安全，更多专注纵深领域的安全公司开始陆续出现
**【1】次集成时代所带来的格局变化
**
次集成时代，这个名字是我随便喊的，在我眼里那个时代大概是这样的：
除早期入局的几家厂商外，几乎不再有哪家可以坐拥全线产品；
因为产品不完整，所以方案上往往是“抱团取暖”
抱团取暖的过程中，对那些掌握话语权的总包持有者们来说，就有了其方案内产品的选择权
这种选择权就出现了另一种可能性，比如，某些合作关系较好的，慢慢合作可能就不仅限于项目，可能还有投资
当然，为了获取更强的方案完整性，也有主动向外扩展、寻找公司去投资的总包持有者们
这一系列的动作，也间接出现了一些派系，现在也会听到说，某某公司是XX系的
正因为这些背景，让很多纵深领域的安全公司出现，而且纵深的细分市场曾经一度会被拆分的很细致。
从早期出现专注应用安全领域的公司开始，那时候还是以“应用安全”一个较大的领域出现，到后来出现专注于“Web安全”，甚至更小的被细分到更小粒度的“专注移动安全”。
这种形势至今几乎依然在持续，这给一套方案的设计提供了更多的可能性，这种可能性带来的是方案的完整性，但也引发了另一个问题。
【2】运营问题初现：方案的整合之难
随之而来的另一个问题就是，一个方案之下包含了来自多个厂商的产品，在一个体系、甚至在一个具体的产品（如，某些安全管理平台/SIEM系统等）中将其整合，就成了一个难题，而且这个难题至今依然在延续着。
于是，在当时的业内出现一些不得已而为之的解决之道 —— 接入规范。
某些甲方的大集团，为了整合所有产品入局，就开始定制各类接入规范，这种接入规范可理解为，为了整合各种安全产品向其大平台进行数据整合而做的数据统一化接入 —— 欲入其局者，先从其规范而行之，不若则卒。
除此之外，我也参与过更具野心的一套方案，为了打通多个厂商产品与现有平台的整合，自己定义一个服务层，专门用于告警内容的转化，当时的核心在于以下几点：
告警字段的统一化及抽取
告警字段的说明字典定义
抽取之后的关联
还有一些细节，当时的文档实在翻不到了、也记不清了。反正简单理解就是，自己为所有产品的告警构建一个翻译层，翻译成统一的语言（不但标准到字段、甚至统一到CVE或其他自定义编号）之后录入到当前管理系统中，然后在当前的管理系统内做统一的关联告警。
那一年大概是2012年，现在回想起来，似乎是在等待世界末日的日子里无事可做而产生的疯狂想法。最终 …… 一厢情愿的执着果然没有好结果。
这类整合问题至今依然存在，而且仅仅是安全运营过程中所面临的最初级问题之一，实际上运营的坑更多，那些，留在后话再讲。
【3】监管红利与创业潮
【3.1】监管红利
等级保护的落地推广在2010年前就有了非常明显的势头。
随着势头越来越强烈，很多监测、扫描、检查类的产品借着这波浪潮出现了一次增长，在原有的 to B 市场中也开始细分出 to G 市场来迎合这一波趋势。
在这个时代中，整体的安全建设方案、尤其面向 to G 市场的方案开始出现了以下的趋势：
面向监管方的检查能力主要的要点在于：快速、大规模以及持续监测能力。而这些能力则以各类政府的Web门户为主、线上和内部系统为辅。
有攻就有防，有检查就有自查。一份能力，两个场景；一个产品，两个客户。从理论上来说，这应该是厂商喜闻乐见的一个场景。但实际上却并不尽如人意，而造成这一结果的主要原因在我看来是 to G 客户的特性所造成的 —— 这是商务话题而非技术话题了。
有了检查、也有了自查，就需要有配套的整改能力。配套的整改能力就以防护类产品为主要手段。
从中可以看出，这是一波既卖矛、又卖盾的过程。
于是，也出现了不少必须 “自相矛盾” 的方案 —— 你家的盾能抵住谁家的矛、甚至是你家的盾能不能拦截自家的矛。
当然，这个过程并非是真正的自相矛盾，而是围绕攻防场景不断展开并强化相关安全能力的一个过程。此时的检测类产品和防御类产品出现了一波良性增长，也不断开始有厂家开始回归安全最初的本质，也就是漏洞 —— 当然，其本质是否正确就不做讨论了 —— 不过有些细节很快就被玩坏了，比如，有的盾专门识别友商矛的特征，发现特征后该来源全杀、无论对错。
【3.2】大众创业与万众创新
随着大众创业、万众创新的提出，安全也进入了一个短暂且有力的爆发时代。
大量资金的涌入，让很多小团队开始焕发新生，也出现了很多新的团队。
一些国外先进的理念被快速引入并落地、很多沉寂已久的产品也开始重获新生，市场上一下多了很多选择。
方案开始具备完整性，而为了获得更强的完整性，开始出现两类趋势：
原来的云、管、端的三层拆分方式已经装不下体量巨大、概念超前的各种安全产品了，于是在这里，纵深防御的概念开始衍生和扩展，并在传统的三层上开始被拆的更为细致。
以线上环境为例，可以按照业务逻辑和技术逻辑来进行更细致、更多维度的拆分，例如：
Web（前端业务）
Nginx（代理或应用）
API（接入/接口层）
业务（后端业务逻辑）
存储
向下还有更多 …… 不再一一列举
向下的多层拆分给了更多安全能力、安全产品和安全概念的更多空间，也让整体方案的能力看起来更丰富了。
但这样的拆分和方案方式，并没有解决之前所提到整合问题，甚至会引入更多的整合问题。而且那些在传统简单且粗暴的三层拆分之下都难以实现的东西，在如此拆分之下只会越来越复杂。
但是，难得的创意总需要有一个容得下其产品的空间，所以，又何须抱怨。
毕竟，该来的总是会来，该走的也总是会走。
除了更加细化的拆分方式之外，另一种方式就是试图在每层之内加入更多的东西。上面算是在纵向分层的丰富度问题，而此处算是在特定层面的横向丰富度问题，道理差不多，不再细说了。
【3.3】新概念融合所带来的交付方式的改变
安全作为一个多学科边缘所组成的独立专业领域，在新技术和概念的融合方面一直是走在前列的。
随着创新和创业的火爆，云计算、大数据、人工智能和其他各种听过没听过的概念，都开始以不同的方式被整合到这个领域之内。
而这些繁杂且红极一时的概念中，我认为只有云计算的相关技术和概念与安全领域的最终契合度最高。
因为，只有云计算是对安全能力的生产、交付和运维模式有可能产生改变的一种技术，而其他技术的引入可能改变产品的技术或形态，但对生产、交付和维护等关键动作未形成重大影响，没有跨出原有的路径，除了锦上添花外、很难寻到新的突破机会 —— 而云计算与安全的结合，虽然至今也难以称得上完美，但至少跳出了原有的模式，这就意味着会比传统的方式有更多的机会。
（下图：2014年时写的两张关于云安全的胶片）
【4】甲方安全的崛起
不知道从什么时候开始，甲方安全团队开始走向了安全能力鄙视链的顶端。
而且有那么一段时间，能切身感受到的就是，一些大厂开始纷纷成了安全从业者们的一个新选择，而且是一个更优于厂商的选择。
而老牌安全厂商的一些特定团队的人也成了很多大厂定向狩猎的对象。
对于这一部分的安全建设工作，后面再慢慢来讲，此处就算简单的提前点题吧。
【5】日渐复杂的安全环境下的服务进化
从刚才的故事中把话题扯回来，再看看那些年的安全服务。
如果谈安全服务的全面性实在是过于庞大，大到ISMS的建设、小到一次渗透、一次应急，那几年前前后后参与的项目有近百个，但能够给我印象深刻甚至影响至今的，大概也就只有那么一两个。
【5.1】攻击路径
在07年的时候，随着Web安全开始兴起，攻击的模式开始变的复杂。
原来传统的exp 是要硬生生打到系统上，只要做好一定防护让系统不可达就可以相对容易的规避各类 N-day，但Web安全的出现则不同，你并不能要求一个Web服务器不对外提供Web ，而且随着Web 技术架构衍生的复杂度提升，穿过Web 边界进入到服务器内网横向的过程和手段也变得极其多样复杂，这就提升了对抗的难度和复杂度。
在这个背景之下，我在当时的老板、业内知名的“妈咪王” 的点拨下开始尝试一套新的分析模式 —— 攻击目标如果是且仅是单点（即，不移动），则其风险相对可控，在某些场景下这种风险甚至可接受（如，单点上无重要业务、无敏感数据）。所以应该关注的是那些会形成路径的攻击，即关注的应该是攻击过程。而这种分析模式的好处在于，这类路径是相对可穷举的。
依据这个思路，我做了一次攻击路径梳理 —— 第一版简单粗暴，只是单纯的从攻击动作层面做了枚举，例如这样：
【5.2】攻击路径升级：威胁路径
后来我才意识到，应该梳理的是威胁而不是具体的攻击动作，所以在第二年、08年的一次客户培训之前，以此为蓝本做了一个以威胁为导向的下拆版本。
翻出当时的版本，重新get了一下当时的思路，应该是这样的：
第一步：通过可识别的威胁手段的向下拆解到足够细的粒度；
第二步：按传统的网络、系统、应用等层面来识别系统弱点，并拆分到具体的问题上；
第三步：将威胁与弱点进行连线，形成一个可操作的评估工具，并辅以人工测试进行验证；
当时的第二版大概是这个样子的（没有连线的版本）：
【5.3】项目实战
当时的理论成型之后，大概一年后才有机会进行实战，而且在实战的过程中发现了一个新的问题 —— 原来仅关注了那些客观的，即，威胁和弱点。而对于那些主观且更具个性化的缺少关注，即，业务本身的特性。
所以，在项目过程中，换成了先以业务梳理为入手点。截取当时项目最终汇报的两页胶片供参考：
第一页：面向业务的威胁路径分析与梳理
第二页：威胁路径到攻击路径的转化与验证（PoC）
通过项目实战，清晰且明确的梳理出十几条攻击路径，并且超过半数通过了验证，而且其中还有一条是梳理到了代码逻辑层，验证出一个极其隐蔽的SQL注入点。
以上，牛逼吹完了，正经的说一下当时此类服务模式的优势与劣势。
优势有几点：
有深度，肯定比两眼一抹黑的黑盒渗透要有深度
验证及可视化效果好，全程都是贴着业务进行梳理和验证，用户的可视化感官强烈、也非常容易描述问题
改造方案成本低，因为是路径式的梳理，服务后续的改造方案也将以路径为目标进行改造而不是单点改造，举例说明，假如一次攻击发生的过程涉及了边界、内网及系统三个层面的话，原来的建设以单一层面为对象进行建设，就会出现三层建设，而以路径为修复目标的话，只要卡住路径上一点即可。如果梳理出多条路径的话，只要把所有结果放到一起找到性价比最高的那一个或几个点，即可起到最大化作用，这个问题在后面的运营中还会反复提到
当然，劣势也相当明显：
投入成本，当时同等规模的项目基本上是2-3人在3周以内完成，这个项目3个人做了接近5周
协调复杂度高，尤其是需要跨系统沟通的时候，获取这些精确的信息并不容易
验证成本高，有些梳理工作画在图上很容易，但想要动手构造就会无比复杂
可复制性差，整个梳理和验证过程对团队有技能和业务理解要求，并不容易复制
所以必须承认的是，从厂商视角上来看这并不是一个合理且能被人普遍接受的项目交付模式。但如果更换一下视角，把自己放在甲方的安全建设和运营视角来看，持续跟踪并维护这样一份业务梳理后的展开图，就可以为后续的持续建设和改造提供参考甚至是评价。
那么，既然谈到了甲方的建设与运营，接下来一篇，就从情报体系的建设与运营开始，谈一下我对安全运营的理解与看法。
（本篇完）
