作者：Mils
前言
企业的安全应急人员好比救火队，一旦有业务着火被入侵，应急人员会第一时间扑过去灭火止损。
灭的火多了，慢慢就会发现哪里容易着火，如何才能抑制火苗，及时防患于未然。安全应急固然很重要，但是只有让风险前置，及早感知威胁，才能让我们的安全防御力量化被动为主动，形成安全闭环。
本人旨在结合MITRE ATT&CK 威胁矩阵，谈一谈自己对提升企业入侵检测能力的一点理解和思考，若有不足之处还请多多交流，也希望通过此次分享能够给读者带来一些启发。
（声明：本文内容仅代表我个人的理解，不代表任何公司或团队。）
安全应急响应简记
前言
世上有两种人，一种是已经知道自己被入侵了，另外一种是不知道自己已经被入侵的了。
无疑，前者是幸福的，能够通过事后的入侵排查和安全应急响应做到及时止损。通常，安全应急响应最开始会面临时间紧，信息少的情况，安全应急人员必须每分每秒都与时间赛跑，全程保持清醒的头脑，有条不紊的排查蛛丝马迹，最终定位问题来源。应急响应过程通常围绕检测，抑制，根除，恢复，跟踪等主要阶段，同时还需明确响应顺序和过程，还原完整入侵轨迹以便及时总结与复盘。
根据安全防护措施或防护设备的不同，攻击检测主要可以分为两种：一种是通过安全防护设备发现的攻击行为，能够触发安全告警且安全设备内通常会记录下明显的攻击载荷（若没有被加密的话）；另外一种也能被安全设备检测到，但是由于检测到的威胁来源不同，若缺乏人工分析，那么这些告警，通常容易被淹没在海量的告警里，并且，谁都不希望在内网里面看到此类入侵流量。但是往往又事与愿违，比如我的朋友Lego，就遇到了这么糟糕的经历。
Lego是一名信息安全工程师，于1个月前入职韩国某一手游公司，公司刚成立不到半年，正处于大力发展业务的时期，无暇顾及信息安全建设，公司基础边界防护还处于刚起步阶段，并且由于缺乏合理的IT基础平台支持，服务器日志数据也没有一个统一管理的地方。
争分夺秒，拨云见日
某日，Lego发现一服务器上存在多个JSP文件被成功上传的记录：上传来源IP为一公网地址：153.42.87.17*，目标IP：151.101.194.2*，上传的真实路径为：http://151.101.194.2*/groups/game/api/1312/upload，通过抓包分析，捕获到以下异常代码：
该文件利用”delta”变量获取参数，获取参数后以”O”为separator分割字符串，并对分割后的字符串进行16进制解码，最后将解码的内容输出到一随机生成的5位数作为文件名的文件内，并在页面中显示输出该文件名称，基本确认为小马的功能。
经过排查发现，151.101.194.2*对应的内网服务器IP为一虚拟地址，该虚拟地址实质背后映射了多台服务器，且该虚拟IP地址之前还有一层反向代理，大致拓扑如图（1）所示，并且由于缺乏良好的日志管理，无法通过对日志的集中分析来迅速定位问题，例如排查上传的恶意文件所在的真实服务器地址，导致排查工作必须一台一台进行。最终定位到了上传文件之后，这些文件所在的真实服务器。
图（1）
Lego登录这台服务器进行排查，发现上传后的文件被服务器进行了重命名，且由于特定功能约束，系统会对上传的文件添加文件头，导致文件无法解析，这也直接致使攻击者无法对上传后的文件进行利用。通过对所有已上传的文件分析后，发现含有恶意代码的文件主要集中在为三个，分别为UIOSX10932.jsp UIOSX12945.txt UIOSX11976.jsp。查看这台服务器上的访问日志，检索上述过程中发现的3个含有恶意代码的文件，发现UIOSX10932.jsp只有一条500的访问记录，且提交参数内容截图部分如下图所示：
根据上述分析的代码功能，对参数去除O字符后得到部分16进制编码的字符串：
再将其进行16进制解码后得到部分代码：
解码后的代码实现的也是木马功能，从而确定UIOSX10932.jsp小马被利用来写入其他木马，但是文件目录中并没有生成文件名为随机5位数的jsp文件，且服务器返回的状态码为500，初步可确认该后门文件并未执行成功。随后Lego立即联系业务，修复漏洞并进行复盘总结。
入侵排查，好似大海捞针
经过复盘，真相逐渐浮现出水面。Lego最开始看到的后门文件只是其中的一台服务器上的现象，通过排查服务器日志（细心的读者一定还记得在前文提到的，该手游公司由于缺少日志数据等的集中管理，面对服务器日志的排查，Lego不得不采用最原始的方式一台台登陆主机来进行），Lego一点一点的梳理着入侵行为所留下的轨迹，谨慎仔细的Lego是不会放过任何蛛丝马迹的，一颗紧绷的心也始终悬着，时间一点一滴的流逝着，并且在没有确认最终受影响范围之前，任何人都不敢掉以轻心。通过排查，发现其余还有几台主机内也存在相同的后门文件，且恶意入侵者存在恶意爆破及横向移动的行为，但由于区域间有网络隔离，受影响主机均仅限制在一个/27掩码的测试网段内，Lego通过几十台主机一台一台登陆和排查后，最终确认了此次事件的发起源头，并且也基本确定了此次入侵的受影响程度，且由于基本都是测试环境的主机，基本并没有敏感数据的泄露。
调整优先级，加大安全建设进度
虽然入职才短短一个月时间，Lego的计划内已经有非常多的安全防护建设项目要去推进，但是通过此次应急事件的经历，让Lego更加觉得时间的宝贵，并且由于行业背景的因素，手游公司面临的安全形势更为严峻，为了与入侵者赛跑，必须节约安全人员宝贵的运营时间，使用安全自动化编排技术辅助日常安全运营的工作，已经刻不容缓。安全智能编排技术能够加速威胁响应，简单来说就是将“人工智能与安全编排结合，实现人机协同，助力安全运营”。该理念获得了Lego老板的大力支持，在接下来的时间里，通过安全智能编排的接入，安全运营工作节约了大量的人力成本，也取得了实质性的进展，帮助公司阻断多起入侵行为，及时止损。
安全编排模型参考
安全智能编排剧本（图片来自于：雾帜智能）
不要为了应急而应急
上述应急事件的经历描述较为简略，因为这里重点希望突出的是事前预防的重要性，安全旨在防患于未然，尽管安全人员经常被调侃“信息安全和运维差不多，出事了，老板觉得要你何用，没出事，老板觉得要你何用。但是我们也还是要把安全进行到底，不是么？
从被动应急到主动防御
安全应急是被动的，如何在有限的资源基础上尽可能的做到提前防御，规避风险，我觉得首先需要做到以下几点：
1、对资源的自动化管理
这里的资源包括但不仅限于主机、网以及应用资源，并且重点在于自动化。
一台主机从创建、部署到发布等都应有唯一的渠道走完完整的流程，多方管理导致的结果往往会带来管理的盲区；并且必须自动化，想象一下，若一家公司有上百上千台主机，其中的资产信息都是通过手工的方式录入，并且其发布流程也都是通过邮件等方式进行传递，单纯靠管理的手段口口相传，时间一久，不仅增加额外沟通成本，资产库也逐步趋于混乱，以至于信息严重不及时，资产库形同虚设。
2、对区域的严隔离
这里的区域不难理解就是我们常说的访问区域，严隔离是为了避免例外的存在，过多的例外会导致区域边界的模糊，逐渐失去访问控制的意义，埋下巨大安全隐患。
3、自动化安全编排技术
编排可将多个安全应用按照一定的逻辑配合，实现多种安全业务功能，自动化编排进而提高安全运营效率，减少企业各项成本。
加速检测主动防御
ATT&CK旨在对攻击流程进行统一定义及归纳，从而帮助我们更好的理解攻击行为所带来的安全隐患。这里谈一谈我对MITRE ATT&CK的一点理解。MITRE提出的ATT&CK框架，是将入侵期间可能发生的情况，做出更细的画分，区隔出11个策略阶段。包括：入侵初期、执行、权限提升、防御逃避、凭证访问、发现、横向移动、收集、渗透、指挥与控制。
重点在于，若想要对攻击链路中的行为进行验证，首先需要确保自身检测能力的覆盖面，在资源有限的情况下，首先应该明确对下列几点的覆盖：
1、日志：从收集的日志中识别攻击行为，前提是确保日志收集的完整性；
2、范围：从安全设计体系分析暴露在外部容易遭受攻击的范围，做到对暴露资产的实时防御；
3、技术：检查自身的检测能力能否对关键攻击技术进行覆盖，从基础技术抓起；
4、数据：利用已有数据进行搜索，不断进行测试和迭代，通过对攻击行为的模拟，减少误报；
关于入侵防御能力的提升：基础安全始终是前提，技术覆盖是重点，逐层防御是关键，安全闭环是目标。需要通过不断地攻防演练，提升入侵检测能力，通过扩大技术覆盖范围，缩小与攻击者的差距，最终实现主动防御，防患于未然。
《参考资料》
MITRE ATT&CK https://attack.mitre.org/
如何将ATT&CK矩阵应用到安全运营中？https://www.secrss.com/articles/9469
浅谈大型互联网的企业入侵检测及防护策略 https://mp.weixin.qq.com/s/1Iry620hCkJ8sHA626T3Dg
ICD（集成网络防御）概念参考模型 https://www.secrss.com/articles/12023
IACD 集成的自适应网络防御框架 https://www.secrss.com/articles/5504
关于作者
Mils，信息安全从业人员 CISSP、CCSK、CCIE Security、RHCE 专业小熊猫饲养员，业余手绘爱好者
声明：本文来自唯品会安全应急响应中心，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
