网络安全风险评估的步骤

网络安全风险评估可以在产品开发周期的前期和后期进行。

前期进行主要为了做安全加固：

资产识别/系统分析 > 威胁分析 > 识别风险 > 制定消减措施 > 产品响应

后期进行主要为了做安全测试来检验安全效果(审计/稽核)：

资产识别/系统分析 > 威胁分析 > 安全测试设计 > 安全测试执行 > 安全问题定级 > 制定消减措施 > 产品响应

资产识别/系统分析

资产识别是指识别出被评估系统中的关键资产，也就是回答“需要保护什么？”这个问题。一般来说，一个系统的关键资产是这个系统的业务和数据，包括核心业务组件、用户的数据、用于鉴权和认证的密码、密钥等。

系统分析是进行威胁分析的前提，只有充分了解被评估系统的功能、结构、业务流等信息后，威胁分析才有依据。系统分析也为漏洞识别提供需要的输入。系统分析的第一个步骤是了解系统及其所在的解决方案对外提供的业务功能，知道系统能够做什么，对被分析系统有一个High Level的感性认识，之后通过多个维度（viewpoint）对系统进行分解，最后通过业务流将各分解后的组件串联起来，实现“整体-局部-整体”的分析过程。需要注意的是，在进行系统分析前，必须根据项目的目的和限制条件对系统分析进行约束，否则，系统分析是分析不完的。

下面举一个例子。笔者以前从事的一个Android指纹认证系统的解决方案级的安全评估（相关敏感信息已经删掉），做系统分析的时候，需要对整个业务有一个概括理解，并画出总体的系统架构图。这个指纹认证系统，涉及Android、Trustzone、APP客户端、APP后台等，有什么接口，如何交互，关键资产存储在哪里，都需要在图中分析出来：

做完这种系统架构图后，再去根据业务场景或者系统组件来进行多维度的细化分析，方式五花八门，没有什么固定套路，只要分析清楚了就OK。一般来说，可以做以下的分析：

系统的组网情况（处在什么位置/周边系统/…）

硬件架构分析（设备/单板/总线/CPU/…）

软件架构分析（OS/DB/Platform/Web后台/…）

内/外部接口分析（维护接口/业务接口/调试接口/…）

典型业务流程/场景分析（业务场景1/业务场景2/…）

管理/维护场景分析（近端维护场景/远程维护场景/…）

关键事件分析（登录/鉴权/认证/数据读写/…）

威胁分析

学习如何做威胁分析之前，需要了解什么是威胁。

Threat:

A set of potential incidents in which a threat agent causes a threat event to an asset using a specific entry point into the system

那么一般来说有什么威胁呢？可以从安全三元组来理解：

CIA（confidentiality, integrity, and availability），指“机密性”、“完整性”、“可用性”，加上“抗抵赖性”是需要确保的系统安全属性。

威胁分类：

• 对机密性的威胁

如Information Disclosure：通过嗅探、暴力破解等手段窃取用户身份，认证信息，仿冒合法用户访问系统。攻击者非法获得系统中保存的或传输过程中的机密数据，如用户认证信息、用户业务数据、系统代码等

• 对完整性的威胁

如Tampering with Data：通过修改发送给系统的数据或从系统收到的数据，影响系统业务逻辑，比如绕过认证机制、欺骗计费系统、执行越权操作等

• 对可用性的威胁

如Denial of Service：通过Flood、畸形报文等攻击等手段造成系统不能提供正常的服务

• 对抗抵赖性的威胁

通过修改系统访问日志、审计日志来隐藏攻击痕迹、修改业务行为记录

威胁分析就是识别威胁，根据“威胁”的定义，实际上是要识别构成威胁的各组成部分，来总结出一个句子：

攻击者（威胁源），利用XXX漏洞（漏洞），通过XXX方式（攻击界面、攻击手段），对XXX（关键资产）产生了XXX威胁（后果）

说白了，这个阶段就是造句。

但威胁分析是整个安全评估最难的环节，需要采用多种方法去YY有什么威胁、有什么可能性、有什么攻击面、外部攻击者如何攻击系统、内部攻击者(内鬼)如何攻击系统。

虽说威胁分析套路很多，只要识别出威胁就可以，但业界也有一些比较成熟的建模，比如X.805分层分析、攻击树模型、微软的STRIDE威胁建模等。这里就不再详述，请自行google。

这里给个STRIDE作为例子：

分析完威胁，就要根据这些威胁点来进行安全测试。

这里就有很多领域，比如web安全(前端+后端)、Android/IOS安全、云安全等等。