云安全实用指南--第7章安全事件的检测、响应与恢复

# 7.0 ready

发现一项泄露事件的平均时间是197天，并且那些能在100天之内发现泄露事件的公司要比那些需要100天以上才能发现的公司节省了100多万美元。

---
**杀伤链(kill chain)：**
网络杀伤链(根据真实战争模拟建模)，比较流行的模型:

- Lockheed Martin Cyber
 - MITRE ATT&CK

论文: the unified kill chain还收录了其他模型

这些杀伤链详细描述了常见的攻击者的步骤：

- 侦查跟踪(reconnaissance)
 - 武器构建(weaponization)
 - 载荷投递(delivery)
 - 漏洞利用(exploitation)
 - 安装植入(installation)
 - 命令和控制(command and control)
 - 目标达成(action on objective)

---

# 7.1 与传统IT区别

- 云提供商职责范围内的入侵检测和响应是它们的职责，客户不必操心所有的层
 - 传统环境，客户需要担心所有层的安全
 
云提供商不允许客户接触物理硬件，内置取证笔记本、硬盘复制器以及类似的技术的应急工具包

# 7.2 监控什么

任何系统都会有日志/监控指标，被庞杂的海量数据淹没
如果你有**TB级别的数据**，那么**网络流量规模**和**连接时长**这两个监控指标就非常重要。

---
日志/事件:对已发生的某件具体事情的记录
告警:事件的一种，此时系统觉得有必要通知某人
指标：一系列的数字，其中包含了某些事物的一些信息

---

## 7.2.1 特权用户访问

- 监控特权用户的访问并不意味着不信任管理员(四眼原则/双人原则)
 - 云提供商的日志详细记录了何人在何时使用云管理员接口(AWS CloudTrail/Azure Activity Log,但有时必须打开日志记录特性，指定日志存放位置，保存时间，以及相应的存储付费)
 - 有毒日志(包含敏感信息，定期抽查administrative session)
 - 有毒日志(**系统或云提供商不可避免的会记录一些敏感数据**)
    - secure shell会话日志,或其他包含了历史命令和选项的日志
    - 管理员通过云提供商特性在虚拟机上执行的精确命令，除非你有措施保证执行的那些命令不会被系统记录到日志中
    - 管理员在容器上执行的精确指令，例如以kubectl exec开始的命令，除非你有办法保证这些命令不会被记录到日志中
 - 无毒日志

## 7.2.2 防御性工具中的日志
查看这些系统中产生的日志，你无法确定所有的这些工具在防御所有攻击时都是有效的；

- 早期预警
 - 假阳性日志过滤或调优

## 7.2.3 DDoS防御系统

- 配置为检测到攻击就报警，可能攻击会升级或者会放烟幕弹，掩护其其他攻击

## 7.2.4 WAF
分布式/集中式

## 7.2.5 防火墙和入侵检测系统

- 公网的防火墙及入侵检测将告警灵敏度调低
 - 内网的防火墙及入侵检测将告警灵敏度调高

## 7.2.6 防病毒软件
确保资产管理系统当检测到任何目标范围内的系统在没有运行防病毒软件时，或存在恶意软件时，能及时发出告警。
当攻击者利用某个漏洞进入系统后，在系统上放置恶意软件防病毒软件会检测，恶意软件要确保这些恶意软件与防病毒软件一起运行而不被检测。

## 7.2.7 端点检测与响应
(Endpoint Detection and Response)EDR,允许团队调查已经越过第一层防御的威胁，并对此作出响应。

- 记录运行中的系统的大量信息，系统上运行的可执行文件或库的哈希值
 - 网络连接历史(通过操作系统或日志获得)

## 7.2.8 文件完整性监控
在常规情况下某些文件是不能发生更改的，如果发生了更改，就证明可能已发生了攻击
文件完整性监控FIM(File Integrity Monitoring)软件可以在特定文件发生变化时发出告警，云提供商IaaS服务

## 7.2.9 云服务日志和指标
云提供商除了对管理员的活动记录日志之外，还提供了其他日志与指标

- CPU使用率指标
    - CPU使用尖峰暗示可能又勒索软件加密或挖坑活动进行
 - 网络日志和指标
    - 流进/流出子网的数据 
    - 接受/拒绝的流量日志
    - 网络流量尖峰
 - 存储输入/输出指标
 - 平台组件(例如数据库或消息队列)请求指标
 - 数据库突然发生严重异常
 - SaaS产品上的终端用户登录和活动
    - 用户从云存储服务拉取大量数据，账户泄露；
    - 云资产安全代理(Cloud Access Security Broker,CASB)
 - 平台服务的日志和指标

## 7.2.10 操作系统日志和指标
[CIS Benchmarks](https://www.ibm.com/cloud/learn/cis-benchmarks)(公益组织，提供一些列针对配置系统/软件/网络等的最佳实践，可以基于此开发产品 检测配置情况)

## 7.2.11 中间件日志
访问敏感数据的告警，比如除合法应用ID或系统之外的所有对敏感数据库的访问或对特定表的访问

## 7.2.12 机密服务器

访问机密信息的日志：

- 机密服务器的认证或鉴权失败
 - 不寻常的获取机密活动的次数
 - 管理员级凭证的使用

## 7.2.13 应用
应用的日志和指标

# 7.3 如何监控
上一节介绍了哪些类型的事件和指标对监控你的环境很重要，接下来看看如何**有效收集和使用**
SIEM(Security Information and Event Manager安全信息和事件管理器)

<center>
![siem](https://leanote.com/api/file/getImage?fileId=5fd301dfab64411d110001af)
</center>

---

**tips:**
NTP时间源同步

---

## 7.3.1 聚合和保留

- 单个系统的磁盘可能会写满，导致日志丢失和运维出现问题，而且进入系统的攻击者还能删除这些日志以掩盖他们的行踪
 - 当发生问题时，跨几十个不同的系统去搜索日志并将其拼凑成一张全局视图，很低效
 
 - 云提供商一般会提供日志收集服务，**聚合/保留/搜索**

---
**tips:**
通常对日志保存一年时间，但要受行业或者管制的标准约束

---
 
## 7.3.2 解析日志

日志解析器例子：

- 对于操作系统，解析器会识别出时间戳、产生事件的系统名字，事件内容
 - 对于防火墙日志，解析器会识别出时间戳、源IP地址、目标IP地址、接受或拒绝结果
 - 对于防病毒日志，时间戳、主机名和事件详情，更新失败或发现恶意软件

日志格式上千种格式，常用的事件日志使得解析更容易：

- syslog是长消息的一种标准格式(RFC 3164/RFC 5424)
 - 时间戳/产生消息的系统/发送消息的进程的类型/严重等级，以及在一个大部分情况下都是自由格式的消息
 - 通用日志格式(Common Long Format)和扩展日志格式(Extended Log Format,ELF)主要是web服务器在使用
 - 通用事件格式(CEF,Common Event Format)是syslog格式的一个扩展
 - 云审计数据联盟(Cloud Audit Data Federation,CADF)在不更改日志聚合和解析系统的前提下，可以在云提供商之间进行切换

## 7.3.3 搜索和关联
基于解析后的字段进行搜索，并在不同系统之间进行事件的关联
在事件响应期间，跨多个不同日志源和日志类型来执行快速搜索的能力是非常重要的。

## 7.3.4 告警和自动响应
当系统出现异常，需要人为介入时，发出一个告警/或者自动响应(禁用或关闭某个组件)

- 特定事件
 - 事件发生的关联
 - 特定阈值

告警的反馈闭环(假告警/灵敏度)

现代系统可以处理**几十亿条日志**事件
一些大公司通常会自己构建一个系统，或者和某个托管的安全服务提供商(MSSP)签订合约，实现一个7*24安全运营中心(SOC:security operation center)
## 7.3.5 安全信息和事件管理器
SIEM 可以完成以上全部或者部分步骤，云提供商有低成本高容量的日志聚合服务，而且日志除用于安全事件监测和响应外还经常用于运营排障
SIEM规则可以用于检测潜在的坏行为
安全运营人员可能会问的问题(感觉比较**有趣**)：

- 数据库流量比月平均值增长200%，有可能我们的应用真正流行起来了,也有可能别人正在窃取我们数据
 - IP出向连接，根据这份威胁智能情报，这个IP地址一直被某个已知的威胁行为体使用，这是否表示这个系统已经被入侵了
 - 这个账户在成功登陆之前，有150次登陆都失败了，这是否是一次成功的暴力攻击
 - 约翰在正常情况下不会在东部时间凌晨三点登录，或者不会从哪个国家登录，也许登录的人不是约翰本人？

SIEM(安全信息和事件管理器)可以作为soc的一部分在公司内部运行

---

**tips：使用还是不使用SIEM**
对于规模较小的公司来说，使用一个简单地告警日志聚合设施就够了，或者由安全人员来找出威胁

SIEM：日志/关联/攻击/威胁智能情报 逻辑和规则比较复杂

---

## 7.3.6 威胁搜寻
做好日志/指标,解析日志和指标，并对系统产生的告警做出响应，下一步考虑的工作：威胁搜寻(threat hunting)
也许我正被APT(高级持续威胁)，需要你去寻找证据进一步来证明或推翻假设

# 7.4 为安全事件做准备
制定计划，以便知道这些告警中出现真告警时该做什么？

- 什么情况下需要外部帮助
    - 感知到风险、事件的严重程度以及安全团队的规模
 - 网络安全保险

## 7.4.1 团队
事件响应团队承担了在被攻击期间判断正在发生什么，并尽可能控制住事件

- 网络专家
 - web服务器专家
 - 数据库专家
 - 熟悉应用的内部设计和工作原理的专家

事件响应团队/救火队

## 7.4.2 计划

- 清楚云提供商的职责
 - 一笔预先已通过审批的预算,以应对可能出现的安全事件
 - 排定优先级
 - 公司层面指导大家报告可疑的安全事件
 - 测试你的计划，模拟演练

措施:

- 一个可以禁用所有云门户和API访问的计划
 - 一个可以关闭整个环境、锁定机密服务器和重新创建一个新环境的计划

## 7.4.3 工具
实体工具包
事件响应任务创建一些详细的并经过测试的流程

- 云感知的取证分析工具
 - 展示网络配置、数据位置和打印事件日志的位置的一些更新
 - 经过测试的通信系统

## 7.5 对事件做出响应
在不会销毁证据的前提下尽量控制住事件;
### 7.5.1 网络杀伤链
### 7.5.2 OODA闭环

- 观察(observe)
 - 确认(orient)
 - 决策(decide)
 - 行动(act)

### 7.5.3  云取证
### 7.5.4  拦截未授权访问

# 7.6 串联到示例应用中
<center>
![串联](https://leanote.com/api/file/getImage?fileId=5fd35bbaab64411d11000314)
</center>

信息安全从业人员^_^

导航

最近发表

友情链接