0x0 安全运营的背景

        安全运营是以企业安全能力成熟度为基础，运用适当的安全技术和管理手段整合人、技术、流程，持续降低企业安全风险的综合能力。在最近几年安全运营这个岗位出现之前，大部分的企事业单位都是由IT运维部门的少数几个工程师承担一部分的应急响应与安全监控的职责，由于运维工程师们大部分的技术栈偏向于网络工程、系统运维层面，在未出现棘手的安全事件的背景下，热门的安全威胁集中在一些DDOS攻击、Office宏、基础的木马病毒(肉鸡)、文件夹病毒等，也未造成特别严重的业务破坏，工程师也能借助于一些杀毒软件、网络设备进行一定程度的缓解、遏制甚至于处理清理，应对日常的安全问题也游刃有余；伴随着攻击技术的升级与黑产团伙在利益驱使的背景下，当前越来越多的攻击逐步开始走进了大众视野，尤其以热门的网页挂马、批量植入各类虚拟货币的miner、入侵后的数据Ransome、数据窃取后的利益变现等新的场景，应对此类威胁则需要更加专业的安全人员和工具储备，在此背景下出现新的态势感知、威胁情报、数据监测、终端响应平台等新的技术与产品种类。由于安全业务的特殊性，除开乙方的安全岗位外、甲方的安全建设很难直接的产生直接的收益，经常面临着出事了安全岗位似乎没有什么用，没出事也感觉安全岗位似乎也没有什么用的尴尬局面，那日常的安全运营工作应该如何体现自己的价值，具体应该包含哪些内容呢？

         从方法论的角度私下以为PDCA的模型应该是最符合安全建设的场景，在此以重大的攻防演练活动的举例；如大家所知的一样，由于一年一度的攻防演练已经连续持续了好几各年头，很多领导专家和安全厂商也普遍有了一些自己的经验；在演练的实际现场专家们普遍会将参与的红队人员分为4组即安全监测组、溯源分析、应急处置、联络通报组；不同的分组往往承担着不同的职责，不同的现场由于人员与经验的缺少可能存在一定的差异：

• 1.安全监测组主要以安全告警alerts的研判、分析，从海量的告警当中筛选、分析出那些是真实有效的攻击行为；
• 2.溯源分析组则主要以确定的安全事件(Incident)作为主要的线索进行排查、通过各类相关的数据发现入侵者的攻击路径和手法剖析、并提取其中的TTPS、必要时候需要对攻击者进行反向控制；
• 3.应急处置组主要以熟悉业务网络的人员承担，在出现告警/事件的背景下能够进行及时的封堵、调整网络策略配置，阻止攻击者入侵或者堵住攻击者入侵的路线；
• 4.联络通报组则主要以用户侧的领导为主，负责对整体的事件进行响应、协调必要的资源和账号权限，联系不同的供应商、业务方进行紧急的处置与漏洞修复、业务调整等；

         整个攻防演练本质上是一个安全运营工作的缩影覆盖了问题的发现、处置、分析、加固预防的四个主要环节，只是在日常的工作开展中在没有明显的安全事件驱动之下工作重心会更加偏向于业务侧的安全加固、漏洞发现、业务的调整、安全开发流程、监管合规建设，而在演练期间则更加关注于安全告警的研判与分析。

如果把PDCA起点放在加固预防之上，在此阶段安全运营的工作思路有二个：

1. 堵住攻击者入侵的门；比如修复存在的高危漏洞、修改业务/系统的弱密码、加强对应SDL的开发流程跟进、收敛攻击的暴露面、部署安全设备实时进行拦截、进行安全意识教育等；
2. 减少入侵后的损失；没有攻不破的系统，则主要以出现入侵事件后能够快速发现，及时进行限制，该思路主要是第一种思路的一个补偿措施。

0x1 攻防演练之于日常的安全运营

        当前很多安全建设方已经很成熟的完成了基础的等级保护安全建设，但是在面对黑产团伙变化多端的攻击手法与复杂网络环境管理方法缺失的矛盾之间时，经常出现有心无力的局面，尤其是在对抗最近几年日趋APT化的定向勒索的黑产团队；数字化程度越来越高、业务越是复杂、安全运营的难度与所需要的精力就越大，日常需要梳理内外部的攻击暴露面，也需要和很多业务部门到最后也只能被动的打交道，然后正如前面所描述的安全部门本身无法直接产生价值，无事件驱动的背景下与业务方对线时则很容易落入下风；预防加固除开一些通用的技术方案(主机策略加固、部署网络防火墙、WAF)之外、往往也需要结合具体的实际业务进行定制化的防护，比如最近越发热门的开发安全SDL、RSAP等新技术；安全运营无对应的资源未能及时跟上，往往只能被动响应；所以安全运营工作一定是需要高层重视且大家配合的，需要有比较强的约束条件，人人为我，我为人人；

        与预防加固的组织协调能力相比，安全监测则更多的偏向于技术领域；现在招聘网站上的大多数的安全运营岗位需求都集中在安全监测方面，私下认为安全监测是一个技术门槛相比较高的岗位。先说数据来源层面，当前安全告警的主要来源也分为2类：

1. 基于开源的安全监测框架进行修改或完全进行自研；
2. 外购安全厂商专业化的安全产品；

        不用来源的安全设备都或多或少存在一些生态不适应的情况；开源的安全检测框架目前在Github也越发普遍，比较热门项目比如流量检测的Snort、Suricata、Zeek(Bro)，终端侧的Sysmon、Yara等、开源的蜜罐HFish、分析平台如一键部署的ELK、开源的工单流程、CMDB系统等等，很多都支持容器化一键部署；外购的安全厂商专业化产品则提供标准化的产品与独有的安全能力、服务等配套的整体方案，更加省心省力；无论是外购还是自研、安全监测阶段始终都面临着3个主要的矛盾十分棘手：

1. 海量告警的分析难以筛选
2. 层次不齐的研判举证
3. 真实攻击的漏报、攻击行为的误报

海量告警的本质上攻击行为的误报的直接体现；在这里先分析一下海量误报背后的原因，根据自己的一些经验主要有二个主要因素：

1. 业务场景复杂与攻击行为的重合度较高；
2. 规则/检测能力的不足或者缺陷；

0x2 海量告警的分析难以筛选

        为什么会把业务场景复杂放在第一位？总体上分析告警来看，大量的告警约90%都是业务误报，都是没有意义的；产生现有这个情况的主要原因是开发人员缺少一些基础的安全知识背景的，很很多的攻击行为的特征十分类似，比较典型的如在HTTP协议的传输字段直接传输的sql语句、传递文件路径、使用js语句、甚至执行系统命令的，往往会大量命中安全设备告警，造成比较多的业务误报。此外这几年的异常检测技术比较热门，典型的如账号异常登录的场景，这个大家应该也很熟悉，比如微信、QQ比如在非常用设备、地点登录也都需要二次验证，很多安全设备没有这么智能进行二次验证，发现有敏感账号在异常时间、异常地点、异常设备上登录则会产生直接的安全告警(可能就是一个低危、中危)，但是实际情况却很不一样，比如可能是当前用户出差了、或者使用了VPN、或者换电脑了、连接手机热点wifi、楼下星巴克上午之类的，都会触发此类场景；但是安全运营的监测人员无法从这些告警当中发现此类告警背后的场景，没有其他举证信息，危害等级或者程度也无法驱使他进行深度的调查分析，于是只能简单看看甚至直接过滤掉；也是目前安全监测阶段面临比较多的问题；

        规则误报则就更加明显，主要原因是安全开发/安全研究人员编写的特征规则泛化、使用的模型算法、获取的IOC情报本身是有质量问题或场景不适配；比如典型的是，之前攻防演练期间发现一些安全检测产品上检测Shiro反序列化的攻击时，只要数据包内命中包含rememberme=””的字符串、且字符串长度超过一定数值、就直接告警攻击；改规则则必然产生的大量的误报告警，或一些威胁情报是从一些恶意样本中获取未进行深度分析则直接纳入了恶意IOC库、也同样容易出现批量的误报场景；

         不同厂家的安全产品/甚至不同版本基于不同的检测技术，在误报和检出、漏报都不太一样。面临海量的误报哪是否就只能听之任之呢，好像也不是；有经验的安全运营人员往往也有一套自己的分析逻辑与处置方法；在不熟悉业务的背景下、除开基于举证类型的数据包特定字段和内容进行研判之外，一条告警是否为业务误报主要关注该告警的规律性与群体性；具体包括告警的时间、告警的类型、告警数量、告警的对象(源IP、目的IP)、告警的攻击载荷(payload)、检测的具体技术、业务资产的自身属性等维度；规律性举个简答例子、比如某个服务器资产每天都会在晚上11点触发一条与其他区域的数据库服务器数据外发的告警，且连续持续了1个月，每次同步大小都是一样，且请求的URL方法路径高度一致，要么就是攻击APT、要么就是业务误报(计划任务数据同步服务)，根据规律性则明显业务误报可能性更大，此类找机会与业务方的工程师咨询一下则能给予结论；群体性也比较容易理解，比如某安全产品升级之后，发现内网友80%的主机都告警中毒了，原因是访问某个域名的告警，则很大可能性就是误报大多数背景下一般不会中毒这么多资产(极小概率事件)，当然也有可能是某些隐蔽的蠕虫或者rootkit家族，具体场景可结合威胁情报的查询与进程举证进行分析；数量上也是一样重要的参考指标、比如发现内部有个主机对内网发起了ES的未授权访问告警，1天内的告警达到了1W+次、则基本上可以判定为业务误报，大多数攻击者不会发起这么多次的攻击行为；误报的研判方法还有很多比如(借助沙箱、威胁情报交叉验证、检测方法推测、查询业务资产类型等)，此处仅举几个简单的例子阐述。

         误报排查依赖于一定时间窗口内的告警聚合分析，更加符合一些日常安全运营的场景，在实际的攻防演练场景却不那么通用，对于很多做告警研判分析的安全人员来说最常用的方法主要为：

1. 根据告警的危害等级进行筛选、优先匹配那些危害等级比较高的告警或者事件；
2. 根据告警的攻击状态进行筛选、识别那些攻击成功、未知的告警；攻击失败的则不必重点关注(初始入侵阶段)
3. 根据核心/风险的资产的进行筛选，优先关注那些容易被攻击，存在安全隐患，具有攻击暴露面的资产，关键业务资等类型进行重点排查；
4. 根据特定的规则描述/告警名称、类型进行筛选，优先关注于一些特定类型的告警类型比如横向扫描、爆破、Shiro反序列化、S2系列、Webshell上传通信、DNSLOG等；
5. 根据攻击的方向；优先关注主动外联、横向移动的场景，外部入侵的攻击行为大多数危害程度相对比较低；
6. 随缘看看；告警实在太多无法有效进行分析研判的时候，则按照时间顺序排序、肉眼可视的随便点点看看，但可笑的是有时候的随便点点可能比针对性去分析效果更好、所谓的无心插柳柳成荫；

引用一段绿盟科技技术Blog的一段文字是，个人认为是对该问题的一个较好的解答。描述如下：

令人无奈的是，让攻防经验丰富的技术人员随意筛选，反而确实是目前所有告警筛选方法中最为有效的一种——几乎没有其它任何筛选方法的实战效果能超过专家的直觉。实际上，目前大部分安全团队在面对保障值守类工作时，似乎也都倾向于依靠人员培养体系解决问题，而自动化方案只作为辅助手段。

通过观察攻防技术人员筛选告警的过程，有两个现象值得我们注意：

1、只擅长防守的技术人员似乎很少。如果某个技术人员分析告警的能力很强，此人往往也是一名渗透测试高手；

2、技术人员在筛选告警时，实际上已经复合使用了多种筛选策略，但最终作出判断时所采用的决定性依据几乎全都是告警载荷。

0x3 层次不齐的研判举证

        从目前来看大多数安全产品都使用了规则引擎自带的举证信息，命中了那一条规则就讲对应的流量/进程数据包进行截取并加以展示、同时根据命中的位置针对性加以高亮/颜色区分等方式进行优化；基于这种模式则要求安全分析需要对当前的告警背后的攻击行为甚至于；漏洞原理具有较好的知识储备，否则看不到攻击payload里面的字符内容和特征字段，则无法对误报与正报进行有效的分析；

        除此之外，由于不同安全厂商的告警缺乏一个统一且标准的模板，大多数的安全告警无论是是告警的描述、事件的类型、危害程度、举证字段内容、标签甚至于ATTCK的分类都不一致、在一部分强调于安全产品异构的群体中原本希望不同的安全产品能够针对同样一个攻击行为可以相互佐证，到最后却变成了互相暗示对方是误报；对于专业的安全运营人员来看，最核心的能力依然还是对攻击手法的理解，无论字段怎么样的变化攻击的payload字段、流量数据包等内容，始终是攻击者难以躲开的特征内容，一个资深且专业的安全运营人员有时候比一个资深的红队(攻击队)专家要求可能更高；

         除开标准的特征举证字段之外、还有较多的行为类的告警；行为类的告警区别于特征类的攻击的举证维度，则多了一些关于数量/频率的概念。比如如何研判A服务器、对B主机的端口扫描行为，则需要结合一定时间内的TCP/UDP的扫描行为的网络日志进行剖析，目的端口的总次数(10次、还是100次)、端口类型(是否是常用端口、扫描端口是否呈现规律性)、扫描频率(100次/min)等维度、不同的安全产品对此类常见的定义也有较大的差异，但是该参数的阀指则对告警的误报/检出有较大的影响，敏感度低了会产生大量的误报、敏感度高了则不容易检出到真实的隐蔽攻击、时间窗口大了对系统资源消耗较多等等问题，结合不同的业务情况很多安全产品现在可以通过页面配置的方法可以进行调整，或许也是一个不错的方法；

        个人比较常用的方法除了以上的参考的类型之外，还额外关注其他几个方面可进行佐证，比较常用的包括攻击对象与受害者对象的资产自身属性；比如一个文件共享服务器经常出现SMB暴力破解就比较正常，DNS服务器经常访问病毒域名的IOC也很正常；第二个是威胁情报，通过对开源威胁情报的方式进行交叉验证，将C2-IP地址、攻击IP地址进行二次验证，样本的可进行静态/动态查询等方法；第三个是，根据告警描述和告警信息推侧安全人员的特征规则是什么。比如检到一个webshell的通信的连接，则下意识会推测安全人员是否仅仅通过访问的脚本的后缀类型、还是数据包当中的加密内容直接进行告警，而不是进行过成家深层次的思考研究，也能从一定程度上的缓解危害；第四个是结合攻击的上下文与历史发现的告警，攻击者攻击往往都是按照一定的攻击顺序的，先后顺序、因果关联等方法，可以参考一下当前告警的对象的历史告警都有哪些，并进行推测，如果一条告警每天都有持续不断、则误报的可能性较大，反之则需要重点专注和下一步的分析了。

0x4 真实攻击的漏报、攻击行为的误报

        误报还能结合多个的数据进行分析研判、但是漏报的问题一直都是比较难搞定的问题，而且往往都是在事后的其他途径获取到的对应消息；比如有其他人通知告诉你，某个服务器被植入了木马正在和境外的IP通信、或者内部的某些业务已经受到严重影响之后由业务侧的同事反馈才发现端倪。漏报的问题难以避免，那是否有什么关键的举措可以进行补充呢？国外现在流行一种新型的威胁狩猎服务(Threat Hunting)或者OverWatch，通过安全专家在云端分析网络环境当中的一些信息、低危类的告警，甚至于准备一个特别的狩猎分析的安全能力通过对告警结果进行分析，这些告警在日常的运营过程中可能无法被获取到；

         尤其是当前很多的隐蔽攻击行为，很多通过安全产品的明显告警发现；自身做安全运营的场景下，个人认为也是一样的思路需要花费一定的时间与精力在一些低危、信息类、异常类的告警上，结合资产类型、攻击的暴露面针对性的做一些威胁建模、能力补充、狩猎；当然部署一些蜜罐、饵账号也是主动发现一些隐蔽的攻击的方式，作为检测类的主动防御类产品、目前似乎还没有形成一个较好的认知、大家普遍还是认为蜜罐是用于获取攻击者身份信息类的一类溯源产品；

0x5 攻击溯源与处置响应

        安全监测工作完成的较好、依赖于安全产品与安全专家的共同努力；后续的溯源和处置，相对来讲能力就会省心省力的多，虽然很多时候做监测、溯源、处置的都是同一个人；溯源的难度，主要取决于二个关键因素：

1. 是否保存有充分完整、关键的日志/告警
2. 溯源人员是否有对应的渗透知识与时间范围

        溯源个人简单的分为主机层溯源、与多主机的网络攻击链溯源；巧妇难为无米之炊，参与主导过多次安全事件事件的专家会发现，大多数病毒类的传播普遍采用相同的攻击手法，无论是本地持久化、横向传播、病毒样本释放、执行的命令Cmdline、创建释放的问题、外联的IP地址/域名/IOC等内容，如果没有版本更新则都是一致的，代码已经写好了剧本，所以大多数的场景往往只需要确认攻击路径，影响的主机，传播范和先后顺序即可，有点类似梳理疫情的传播链，而且此类应急响应的事件处理的比较多了之后会逐步行为一些固有的经验，热门的活跃家族本身也不多容易被枚举，有时候一眼就能看出到底是哪个病毒家族种类。病毒场景下主机溯源难度较低、主机的网络传播链需要花费一些时间；但是一些针对性的入侵事件，就比较考验人的能力，往往需要从很多系统日志、应用日志、主机进程日志、账号登录日志等场景出发进行关联，比如攻击者是通过一个Web系统的0day作为主要的入侵点，则在过程中需要分析大量的access.log，业务系统复杂的一天的访问量或许就高达好几十G的日志文件，所以此类场景下的主机溯源更需要丰富的经验并依赖于安全人员自己写一个脚本代码的工具进行辅助，且往往时间周期也比较长；基于合规的思路，大多数的日志保存周期都在180天左右即6个月左右，但是一些长期的潜伏在高价值目标的攻击者可能周期更长，导致大部分的攻击是断链的，部分攻击者还有清理入侵日志的习惯也相同的场景下的增加了溯源难度，缺少的部分往往需要依靠安全人员自行进行补充；

         处置的安全告警的原则一定是在不影响业务的基础下尽可能的解决安全事件，稍许有点微妙的地方在于处置，并不一定是需要真真切切的将存留的病毒文件、服务项、持久化操作彻底给清理掉、需要定义与目标的差距才是首要关键；比如当前很多个人测试使用的虚拟机windows批量的使用一些带有后门的激活工具，往往会产生一些外联恶意域名的告警，我们可以选择在汇聚层或者网络边界进行拦截，不允许该请求的解析，或者通过本地重写Hosts文件的方式重定向该域名，也是一种积极有效的处置方法；很多感染类的病毒需要借助一些工具或者修复软件进行特别处理、一些恶意程序的母体被删除了后，可能存在一些残留的启动项本质也无法造成危害；当前一旦出现了安全事件、能尽量处理干净并进行加固的还是需要做到尽善尽美，只是大多数真实场景中或多或少都会存在较多的阻碍，有时候选择一个折中的处理方案，可能会得到更多的支持；

Ox6 总结

        安全运营是一个闭环、螺旋提升的过程；区别于运维保障围绕网络设备正常运行的工作不同，安全运营更为主要是在保障业务正常运行的基础上，提升组织整体安全能力；网络世界里，威胁不断演变，需要可持续的安全运营不断提升对抗能力。借周末二天时间总结一些关于安全运营一些经验与思路，个人觉得安全运营是一个技术复合型要求比较高的工作岗位，对个人素质/技术门槛要求都比较高，在一次一次攻击对抗、溯源的过程中也能获取到新的想法收获、那种充实的成就感也是安全运营带给人为数不多的喜悦；万丈高楼平地起，安全能力也需要一步步持续提升，攻防一体、知行合一；