在开篇《安全事件运营SOP【1】安全事件概述》中，介绍了安全事件的定义、分级、处置原则及处置流程。当发生某类安全事件时，该如何快速处置？以及如何保证不同人员处置的效果都达标？安全事件的种类虽然繁多，但是处理起来并非无据可循。为了解决上述两个问题，同时提升工作效率和降低安全风险。经过大量的运营处置实践，总结出以下常见的处置标准操作程序（SOP）。
本文将从攻击、检测处置和防范三个维度，分别对应介绍网络攻击方式、事件运营SOP及防范措施。由于作者所处平台及个人视野有限，总结出的SOP虽然经过大量重复的操作、总结及提炼，但仍会存在错误或不足，请读者同行们不吝赐教，这也是分享该系列实践的初衷。
01
—
常见网络攻击
1.1 网络攻击概述
互联网上每天都充斥着各种网络安全攻击，如漏洞扫描、已知漏洞利用、DDoS攻击、CC攻击、网络爬虫等。本文介绍的网络攻击SOP主要指边界突破阶段，针对应用系统使用到的一些攻击手法，比如web渗透、供应链攻击等。
1.2 网络攻击方式
就web渗透而言，实际涉及到的漏洞，范围远不止字面意思上的应用系统层面。因为应用系统不可能单凭自身就可以运行，渗透又是一系列的操作，至少还包括：
-
敏感信息探测：从外部视角看对攻击有用的信息，如端口开放扫描、源码备份文件扫描、应用服务框架识别、Swagger存在敏感信息泄露；
-
已知漏洞攻击：通常是使用漏洞扫描器（单一漏洞/综合漏洞）对目标系统进行扫描，根据漏洞检测规则发现已知漏洞，并进行利用导致系统被攻击。漏洞如果按照不同层面可分为基础层的系统及服务配置类漏洞，如基础环境的已知可利用漏洞、未授权类漏洞、弱账密类漏洞；应用层面的（即开发编写代码带来的安全问题），如SQL注入、Java反序列化命令执行、文件上传等漏洞；基于业务场景的漏洞发现和利用，如已注册用户枚举、任意账号密码重置、短信/邮件炸弹、短信/邮件纵向炸弹等。
-
非法外连攻击：开发使用的开源组件被投毒，应用所在服务器被远控涉及到的metasploit行为、CobaltStrike行为等。
1.3 网络攻击检测
-
FW：对应用上外网权限、对外暴露权限实现管控； -
Waf：对应用层的漏洞探测、利用进行检测及阻断； -
NTA：对网络流量进行安全分析，引入威胁情报提升已知攻击检测能力； -
HIDS：对主机层面如登录、进程异常等进行安全检测，往往作为最后一道防线。
02
—
安全运营SOP
2.1 攻击告警初判
2.2 攻击地址封禁
2.3 攻击告警研判
2.4 应急响应处置
2.5 附SOP流程图
03
—
网络攻击防范
3.1 减少对外暴露面
-
管住公网出口：所有的内网地址均用NAT转化，统一形成几个出口对外暴露，通过使用负载均衡或防火墙进行收口管控。 -
互联网侧资产监控：在外网部署资产扫描的节点，对公司所有的网段、域名和多级子域名进行全端口扫描及服务识别，7*24h的进行资产监控。关于网段和域名的收集，实际的业务场景中除了传统IDC，可能还有国内/外不同云厂商的地址，在最初的扫描前应该确定网段和域名范围。
-
互联网侧高危端口监控：高危端口包括21、22、23、873、1080、1433、1521、3306、6379、7001等端口，其对应的服务可能存在弱口令、未授权、已知高危漏洞等风险，常常被攻击者所关注。需要注意的是服务的端口号是可以修改的，在一些企业中懂技术的人员通常会将远程连接的端口如22做映射为2200，以逃过信息安全部的限制或检测。
-
互联网侧高危API监控：敏感信息泄露、管理后台、密码找回、短信发送等接口，可能会存在安全问题，也常是攻击者喜欢寻找的点位。通过对应用日志进行关键字搜索，比如管理后台可能的url为/admin、/manage、/login等。
3.2 系统上线前提测
-
内网发布系统：申请内网域名前，检查是否进行安全提测及是否通过； -
外网发布系统：申请外网域名映射前，检查是否进行安全提测及是否通过； -
已经发布系统：收集线上业务应用日志，对API资产进行监控。若出现API异常新增，就触发web漏洞漏洞扫描器进行扫描。
3.3 供应商安全管理
供应链攻击的主要战场是其产品，对于安全水位高的企业而言，供应商的系统可能就是安全短板。如：服务部署在本地，中控服务在供应商侧，由于供应商中控服务失陷而导致被攻；服务部署在本地，与供应商系统无关联，仍旧会由于供应商被攻击而导致被攻击…
对于供应商产品的安全管理，业内其实已经有很多实践，如检查其产品的安全性报告（安全测试/代码审计/渗透测试）、要求其提供对外端口通信矩阵、提供系统框架及开源组件、系统上线前进行安全提测、签署应急响应协议保障其在运营阶段提供应急服务…这些都是有效的措施，但有时还是难以避免被攻击。目前做的比较好的应该是华为，对供应商进行赋能，并考量供应商自身的网络安全建设情况及产品研发流程的安全。
3.4 正确使用安全产品
-
基于白盒产品安全能力验证：保证产品发挥效果的最佳实践方法。以安全告警及有效性运营为例，设计出关心/常用的安全功能并准备场景进行测试。
-
产品自身安全加固能力验证：保障产品不被攻击的最佳实践方法。关注安全产品的历史漏洞修复情况、安全加固情况及重点产品（集控类&边界类）加强防护措施落地情况。
3.5 开设对外收洞渠道
SRC作为企业安全团队对外宣传、接收漏洞的官方渠道，既起到沟通桥梁的作用，又可以通过接收到的漏洞反向优化安全防护策略。建设SRC早的企业，各类规则完善、人气高，基本拥有一群稳定的白帽子为其挖洞，白帽子也对业务越来越熟悉，也能发现更多有质量的安全漏洞。对于新建的SRC，则需要通过不断的运营活动来提升行业影响力，吸引更多的白帽子加入。
-
SRC建立：包括门户建立、漏洞接收范围确定、奖励机制确定等。
一是门户的建立，作为一个对外的门户，可以自研也可以通过国内的一些漏洞平台建立企业SRC，漏洞平台的好处是有一定的白帽子基础、运营机制，相比较自研会更加高效快速上线，但也存在定制化功能和效果不佳的弊端。若是自研，可借助开源的程序进行修改，比如SRCMS、腾讯xSRC（开源版）。值得注意的是，如果使用开源方案，则需要持续关注平台本身的漏洞情况，目前已经被发现不少安全漏洞。
二是确定漏洞接收范围，仅限于主域名的子域名，还是包括所有与公司相关的资产漏洞？SRC经常会接收到内部已知管理资产外的资产漏洞，白帽子的能力不容小觑，为避免发生争执需要提前明确。
三是设置有明显区别的漏洞奖励机制，可根据资产重要性、漏洞利用直接造成的影响、漏洞利用条件等进行评判。比如核心系统可利用前台SQL注入漏洞的评级，应该比核心系统管理员之后可利用的SQL注入和一般系统前台可利用SQL注入高，对应的奖励机制也会更高。对于奖励机制，直接进行RMB奖励会更吸引白帽子的参与度。
-
S
RC活动：漏洞接收数量直接取决于参与白帽子的数量，衍生开可能涉及到平台影响力、奖励机制等因素。白帽子拉新、
白帽子促活、每逢佳节奖金翻倍、月/季/年度额外奖励…需要有规划、有吸引力的发起线上或线下活动，保持和白帽子的联系
。
-
其他事项：把跟白帽子的关系处理当做一项正式运营工作，给予白帽子感谢与尊重；注重在安全圈内的品牌，加入生态圈，与其他SRC一起活动，能吸引更多白帽子；制定内部漏洞审核和修复效率，别让线上漏洞暴露太久，也别让白帽子等待太久。
3.6 漏洞情报及预警响应
-
预警监测输出高危漏洞POC：通过从安全媒介、软件官网、国内外漏洞平台、社交软件等途径，实时获取漏洞情报信息、漏洞利用信息等，尤其应该关注重大保障活动前的“漏洞弹药”，并编写对应的POC在内/外部发起扫描。
-
联动资产优先发现互联网资产：无论是漏洞的发现，亦或是漏洞的修复，均需要明确存在漏洞的资产归属情况。基于资产（操作系统/应用/组件）进行漏洞扫描，可以提升扫描效率、降低网络流量；基于资产（重要级别/网络位置）进行漏洞修复判断，可以提高互联网侧的漏洞修复速率；基于资产（使用人/运维负责人/安全负责人）进行漏洞修复推动，可以提高整体的漏洞修复率。
长按识别二维码，和我交流
More...
--------- 软件安全 ---------
--------- 企业安全 ---------
--------- 渗透测试 ---------
--------- 安全开发 ---------
--------- 个人体验 ---------
原文始发于微信公众号（我的安全视界观）：安全事件运营SOP：网络攻击
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论