前言
上篇博客我说，最近可能是突破瓶颈期了，然后应该会陷入新的瓶颈。然后突然发现其实不然，似乎上次才刚刚发芽，如今反倒开了花。
本篇博客将浅显得讨论一下反入侵体系的建设。
原则
所谓的道术器，即治理的方向，方法，依赖工具。打个比方： 骑x向x走。 骑就是治理方法，治理方向就是向哪走，骑的那个东西就是依赖的工具。反入侵的治理过程的道术器一言以蔽之就是：通过安全产品分别从数据安全和产品安全角度进行识别、防御、检测、响应、恢复。其中识别、防御属于阻止Preventive，响应、恢复属于校正Corrective，还有一部分就是Detective。一个完整的治理就应该是从预防到检测最后到校正的阶段。同时在每一个阶段中继续采用这种方向方法依赖的模型去进行思考。
治理之道
识别
我们从识别谈起，一类是资产识别，一类是风险识别。识别资产和风险都是是为了防御，但无论是网络层的防御还是主机层的防御，以及是应急响应还是事后灾难恢复。不知道资产的分布无异于小马过河，不知深浅。 在不了解资产分布的情况下，先不谈防御无法构建。当出现问题的时候，甚至无法评估受损的范围，更不用提什么应急响应以及恢复了。根本不知道资产在哪里，怎么去定位？又怎么去防御？因此，资产识别可以说是企业反入侵建设的第一步，建立起资产收集系统也是重中之中。当然这个也是相对而言，假设一个公司就10台服务器，那建立资产收集系统，显然是个ROI较低的事情。而且完全没有必要，因为所有的资产一目了然，全在心里。讲完了资产识别之外要将风险识别。风险识别就是所谓的威胁建模。只不过在这里你不仅仅是针对单个的系统去做STRIDE建模，而是针对整个企业去进行。各个系统的分布，网络环境，物理部署、主机系统、访问权限等等。在对企业的资产识别之后，针对架构进行统一的威胁建模从而能够提出治理决策。所以识别是第一步，但是建立资产系统却不一定是第一步（视公司规模大小而定）
防御
随着识别的结束，就可以开始适当的建设防御了。为什么说适当的建设防御呢？因为有的同学，习惯一上来就是入侵检测，还没明白输入输出，就开始说着要检测。威胁的防御正确的姿势（流程）应该是层层缓解，而不是仅仅依赖其中一环。那谈到防御，也有两点要关注的地方。一是产品，一是数据， 在数据安全被重视起来之前，谈起防御，大多是以SDL为主。我们现在先从产品角度谈一下。一个产品的诞生基本要经历一下过程，
所以我们要从架构、研发、运行、部署、运营的角度去考虑整个安全开发周期。当在架构的阶段就进行安全评审，分别从系统架构，网络架构，依赖和支撑等方面去评估安全，以及可行性。再到研发流程，就要开始推安全研发了，培训研发人员具有安全开发意识，甚至提供安全开发规约以及安全包，所谓安全包就是Security by default的SDK。这个时候已经从架构和研发的层面去尽可能的确保产品的安全性。随即当原型研发完毕，进入运行阶段，渗透测试的同学又要进行一波攻击，无论是从web，pc还是app，进行漏洞挖掘，还是黑白盒扫描，代码审计等方式去评估产品目前的安全现状。当在“浅水区”暂时确保了产品的安全性，就要部署，并对外发布版本了。为什么说只是暂时确保了”浅水区的安全“，相信安全行业的从业者都知道，要永远对对手包含敬畏之心，你永远不知道什么时候会暴露一个新的0day.而且受限于自己做评估的环境，不能覆盖到真实用户的每一个环境。那回到部署，部署的话C/S, B/S架构都离不开S，此时需要针对网络安全，主机安全进行防御。当然随着目前云计算的发展，大部分企业会选择上云，是不是上云就能解决大部分的问题，依托云服务厂商就能完成安全防御？ 不一定的，错误的RBAC授权，以及VPC配置同样会导致新的安全问题。只能说新的技术解决了一部分的安全问题，但同时也带来了新的安全问题。当然，上云是一种趋势。但谈完从架构到部署的安全防御，并没有结束。持续化的运营才能保持整个产品的周期流程中的安全。无论是接收外界的反馈，情报，SRC白帽的漏洞。还是内部发现新的告警去处理，主机的补丁需要打等等。整个流程中都需要进行运营。
现在从SDL的角度谈完了安全防护，那从数据的角度谈谈数据安全的防护。数据同样是核心的资产，产品带来了数据，数据使产品更有价值。从数据安全来看，如何从采集、传输、存储、处理、交互到销毁进行防护，显然是一种不同的思路。不过其中有些领域其实是和sdl有交集的。而且从数据安全治理的思路里，我学到了一个思想：即管理，组织，技术。数据安全强调从管理层制定策略，由组织确保技术能够执行。在DSMM的数据安全规范里有30个过程域，每个有5个层级。我不会针对每个过程域和层级中的观点再进行具体介绍。首先采集中一部分会面临合规，以及一些端上对抗，唯一性标识，防逆向等技术。传输会面临网络安全，应用安全等，数据从客户端到服务端经历的链路上，收集到的数据是否被篡改了？如何检测被篡改了？是否对应用产生威胁，是一个威胁请求等等，到存储，似乎提到存储，大家一般会应该是感到最像数据安全的部分了。但需要注意，其实不止的。存储对于数据安全也只是其中的一个过程域，在存储的过程中需要保证逻辑存储安全，介质存储安全，以及数据备份和恢复。至于销毁一般是不对外的，无论你对是物理擦除还是硬件销毁外人都是不得而知的，但是唯一需要注意的点是确保彻底销毁，无法复原。所以我们来看看剩下的两个过程，处理和交互。这两个部分一般即面向内部的也要面向外部。面向内部的需要注意处理环境的安全，确保你的处理平台的权限分离，导入导出时的最小化，并且用于正当使用，什么叫正当使用，除了通用的之外，各个企业需要根据自己的业务场景去制定。同时面向外部需要注意数据脱敏，敏感数据一定要经过脱敏处理才能进行流传，无论是替换，随机，偏移，取整。要确保脱敏化的数据防匿名化恢复。到现在基本上除了通用过程与之外都介绍了。谈到通用过程域，这一部分是和产品维度防护相交叉的最多的部分。比如说安全事件应急，资产管理，监控和审计等等，基本都在其中。
检测
谈到检测，检测的关键在于明确输入和输出。只要知道了输入和输出，你就知道你想要什么了。见过上来就是我要用模型，我要机器学习的。听起来很高端，其实并不然。脱离了场景，数据产生的模型并没有什么大的价值。所以场景化的数据模型才是正确的选择。何况模型并不是唯一的选择（广义上来说，规则应该也算模型的一种，但这里单独拆分出来）。我们不鄙视规则和名单（ioc/威胁情报），也不盲目自信机器学习和深度学习的能力。任何一项的引发的线上事故对于企业来说都是个损失。当然现在NLP/CV一些领域的迁移应用效果还是很好的。恶意文件检测，机器流量识别，入侵检测等等。比如说cnn和webshell分类，birch聚类和url的pattern提取等等，以及半自动的渗透测试等等（不仅仅在入侵检测领域）。
在检测的环节中，收集足够的数据是基础。如果数据能有能唯一的标识则更好。比如设备指纹，浏览器指纹等等。当然一切从客户端来的数据，都面临被篡改的风险。当收集到数据之后即可进行检测，本质就是计算以及计算校正的过程。那么你要知道计算的实体是在文件中？还是在内存中？不同实体决定了部署的方式不同，比如内存中的检测就不能通过上传文件到远端进行检测。需要在流量经过的链路服务器上挑选一个或几个链路节点进行部署（端上部署的话，还需要考虑模型自身的安全防护：防逆向），但如果是文件的，你就既可以选择在服务器上进行检测，也可以不。一般来说，大家喜欢上传文件到远端检测，这样就不必要顾虑文件所在端的服务器性能消耗。那么知道了计算的实体，即所谓的输入。还要知道计算引擎的构成，即所谓的名单库，规则库，模型等等，都是计算的过程。通过对输入的数据进行计算得到结果，这个记录是不是一个威胁的请求。一般场景下，还会存在另一个问题就是实时还是离线。拥有了计算能力，怎么能够将其应用起来，是选择实时监测还是离线监测？这就意味着选择。在名单，规则，模型之间选择（or组合）。一个好的做法是在实时、近线、和离线上都拥有检测能力。即进行名单的过滤和规则的匹配，用t-1天的数据得到的模型做近线计算，将生成的数据补充到名单之中。同时再去拿t天的数据进行离线分析。那么在线上的过程中，模型的近线名单计算和规则的计算过滤之间又出现了新的选择，选是不选，开启还是关闭，自动化的降级？能不能自动化的调控，能不能智能化的自动调控呢？
响应与恢复
无论是防御住了，还是没有防住，或是在检测部分检测出来了威胁，那么就需要进行止血了。从时间线上来看，就是事前、事中、与事后的处置。
事前一般主要预防，在防御上面。当然事后的复盘分析也可以作为事前预防的经验。事中主要关注与内外部的威胁止血，在发现恶意行为的第一时间能够及时止损。把威胁产生的损失降到最小化。在这个过程中需要评估受损的范围，或者说可能面临威胁的范围并进行修复。同时止血的过程中，如果威胁的产生是有目的性的，还需要进行保存现场，调查取证。顺便在说一下，资产识别很重要。如果不知道资产在哪，就没办法快速的识别，也就没办法响应和进行恢复。当然事后恢复的很大一部分功劳在于事前的预防。比如说之前没有做灾备，你后面数据坏掉了，怎么去恢复呢？
治理之术
上面说了治理的方向，需要做些什么。现在我们看下怎么去做？怎么去做的话，落实下来其实是个人，怎么落实就是个人与企业之间的权衡了。
个人
至于个人而言，看你在反入侵体系里的位置了。不过抛却位置之后，作为一个合格的安全工程师，至少需要在三个方面要有研究。一是安全本身的知识，二是研发的能力，三就是算法的能力。安全本身的能力让你有能够在这个行业吃饭的资本，研发的能力包含了开发和架构，能够让你将自己的新想法快速落地实现，也有助于理解架构方面的知识。算法的能力一般来说对大部分人员来说是欠缺的，但是算法能够改进现有的轮子，使其从方的轮子变成圆的。掌握了算法的人基本上能够从本质上看清一个产品背后的核心逻辑。
但是当你拥有这三种能力的时候，需要如何体现呢？个人的能力在企业内需要通过一定的项目进行体现。这个时候你就需要拥有另外一些能力：方向掌握、项目管理。在推项目的过程中，这是很重要的两点。因为在这个过程中有时候你不必事实亲为，但是一定能够知道走向和预期。（不必事事亲为，不意味着对技术实施啥都不懂，必须要知道其中细节,而且需要能有自己完成原型验证的能力）。
因此在一个项目的完成过程中，除了硬技能之外还需要沟通的软技能。协调能力，沟通能力是一样不可以少的。毕竟目前的项目大多不再是单人式的了，需要团队成员的合作。如何有效的沟通和协作才是快速推进项目的关键。
企业
无论谈到什么建设，没有企业本身的支持是不行的。因此就算谈到反入侵的建设，也是需要企业支持才行。
因此需要从管理层确定治理策略，然后通过组织架构确保其能够执行，最后通过相应技术得以实施。谈到技术的话，之前提到的技术都属于反入侵建设里面的，同时需要注意识别场景，然后根据对应场景下的数据实施相应的治理策略。同时在建设的过程中，要建设起平台化的支撑。
能够使得整个过程趋向于自动化。在这个建设的过程中，一般来说平台化的产品是面向内部的，很少有开源的，当然也是有的。这个时候就从团队规模，变成了企业规模。也就形成了生态。比如说现在的ASRC的联盟，就是生态化的。可以使得从BU间的治理能力转换成不同企业之间的治理能力。从而是BU间的生态转变成企业间的生态。最后推广成全行业的标准，举例来说，目前提交的DSMM标准。本身是阿里的最佳数据安全实践，即将可能成为标准。从企业的反入侵治理到制定安全领域的安全标准。注定是一个漫长的道路，而且需要有平台有机会才能够有可能做到。
治理之器
上面讲述了治理的方式，治理的方向。那么要依托什么才能实现这些治理方式？就像是你知道了想去某地自驾游，可是车还没到手一样。怎么搞到这个车呢？在反入侵治理过程注定需要依赖大量的外部工具，毕竟不是所有工具都能够通过自研完成。那么如何进行选择呢？
自研？没时间没精力？买？没钱？开源的？用着不放心？或者干脆直接买服务？把安全建设托管给三方？当然这个显然不是一个好的选择。至于如何选择，看企业本身的情况？是否需要招聘安全团队，购买对应的安全产品，亦或是通过依托开源产品进行改进，或者自研的方式。总之，适合自己的才是最好的。
其他
啰里啰嗦了这么多，改改写写了两天。就算你做了上面的这些事情，知道怎么去做。你还是会遇到很多的坑，这些坑，不踩过是不可能知道的。团队沟通，技术落地，都是不可不考虑的成本。基础安全建设，持续化运营。都是反入侵中的重要环节。
上周末的时候参加了四叶草的校园安全行。作为合作方出了个学生版的浅谈反入侵。当然不是这个文章里所讲的。另一个版本讲的是为了绘制出企业安全的概况，以及相应的职业选择。但是好像效果不是很好。后来在郑州大学还着重给研一的学生讲了下入侵检测和机器学习深度学习结合的一些东西，效果也不是很好。看来企业安全和反入侵相关的知识还是和企业讲比较靠谱。