概述

企业安全：根据企业自身所处的产业地位、IT总投入能力、商业模式和业务需求为目标，建立的安全解决方案以及为保证方案实践的有效性而进行的一系列系统化、工程化的日常安全活动的集合。

企业安全涵盖7大领域：

网络安全：基础、狭义但核心的部分，以计算机（PC、服务器、小型机、BYOD……）和网络为主体的网络安全，主要聚焦在纯技术层面。
平台和业务安全：跟所在行业和主营业务相关的安全管理，例如反欺诈，不是纯技术层面的内容，是对基础安全的拓展，目的性比较强，属于特定领域的安全，不算广义安全。
广义的信息安全：以IT为核心，包括广义上的“Information”载体：除了计算机数据库以外，还有包括纸质文档、机要，市场战略规划等经营管理信息、客户隐私、内部邮件、会议内容、运营数据、第三方的权益信息等，加上泛“Technology”的大安全体系。
IT风险管理、IT审计&内控：对于中大规模的海外上市公司而言，有诸如SOX-404这样的合规性需求，财务之外就是IT，其中所要求的在流程和技术方面的约束性条款跟信息安全管理重叠，属于外围和相关领域，而信息安全管理本身从属于IT风险管理，是CIO视角下的一个子领域。
业务持续性管理：BCM（Business Continuity Management）不属于以上任何范畴，但又跟每一块都有交集。BCM绝对是面向实操的领域。BCM提供了另一种更高维度、更完整的视角来看待业务中断的问题。对于安全事件，它的方法论也比单纯的ISMS更具有可操作性，对业务团队更有亲和力，因为你知道任何以安全团队自我为中心的安全建设都难以落地，最终都不会做得很好。

BCM的生命周期:

png

典型的BCP示例:

png

德勤的BCM方法论实施路径:

png

安全品牌营销、渠道维护：CSO有时候要做一些务虚的事情，例如为品牌的安全形象出席一些市场宣介，presentation。笼统一点讲，现在SRC的活动基本也属于这一类。
CXO们的其他需求：有很多公司需要做，但运维开发都不干，干不了或者不适合干的事情，安全团队能力强大时可以承包下来的部分。

互联网行业安全工作的各个方面：

信息安全管理（设计流程、整体策略等），这部分工作约占总量的10%，比较整体，跨度大，但工作量不多。
基础架构与网络安全：IDC、生产网络的各种链路和设备、服务器、大量的服务端程序和中间件，数据库等，偏运维侧，跟漏洞扫描、打补丁、ACL、安全配置、网络和主机入侵检测等这些事情相关性比较大，约占不到30%的工作量。
应用与交付安全：对各BG、事业部、业务线自研的产品进行应用层面的安全评估，代码审计，渗透测试，代码框架的安全功能，应用层的防火墙，应用层的入侵检测等，属于有点“繁琐”的工程，“撇不掉、理还乱”，大部分甲方团队都没有足够的人力去应付产品线交付的数量庞大的代码，没有能力去实践完整的SDL，这部分是当下比较有挑战的安全业务，整体比重大于30%，还在持续增长中。
业务安全：包括账号安全、交易风控、征信、反价格爬虫、反作弊、反bot程序、反欺诈、反钓鱼、反垃圾信息、舆情监控（内容信息安全）、防游戏外挂、打击黑色产业链、安全情报等，是在“吃饱饭”之后“思淫欲”的进阶需求，在基础安全问题解决之后，越来越受到重视的领域。整体约占30%左右的工作量，有的甚至大过50%。这里也已经纷纷出现乙方的创业型公司试图解决这些痛点。

传统企业与互联网企业安全建设的不同之处：

传统行业重视制度流程、审计等，有些行业关注等保等合规性要求
互联网企业的安全解决方案主要以攻防驱动
超过一定规模的大型互联网公司，安全解决方案开始围绕自身业务，局部或全部自研，以适应大规模的互联网架构

甲方安全建设方法论

CSO上任工作开展方法：

从零开始
- 组织结构图：开展业务的基础
- 线上产品和交付团队的映射：梳理问题响应流程
- 网络拓扑图、各系统逻辑架构图、物理部署图、各系统间的调用关系、服务治理结构、数据流关系等安全日常工作所需基础材料
处理历史遗留问题
初期做好三件事
- 事前的安全基线
- 建立事中的监控能力
- 做好事所的应急响应能力

不同阶段的安全建设重点：

战后重建：做好生产网络和办公网络的基础安全，建立配套的技术体系
进阶：拓展广义的信息安全,关注业务安全
优化：自研安全工具
对外开放：安全能力对外开放

推动安全建设，需要与组织上下达成一致，并通过安全策略的成效，促进全公司认可安全投入的价值。平衡开发、运维和安全三者的关系。

安全的本质是是风险管理，没有绝对的安全。需要追求安全的最佳ROI。而不能安全过头。

封堵一个安全风险的防御方法往往有多种，需要权衡选择性价比最高的手段。风险缓解的原则是在以下三者之间做最大平衡：1）风险暴露程度；2）研发运维变更成本；3）用户体验的负面影响。

微软SDL白皮书：https://www.microsoft.com/zh-cn/download/details.aspx?id=12379

威胁建模：使用STRIDE方法发现安全设计缺陷（http://msdn.microsoft.com/zh-cn/magazine/cc163519.aspx ）

STRIDE图表（http://blogs.microsoft.com/cybertrust/2007/09/11/stride-chart/ ）

SDL的日常流程：

事前基线：Web安全编码标准，各公司内部范围流传的APP应用安全设计文档，这个文档的质量水平通常可以差很远，当然文档永远只是文档，可能就是开发部门不强制不考试800年都不看的东西。
事中措施：代码审计，发布前过一轮扫描器+渗透测试。
事后机制：HTTP全流量IDS，Web日志大数据分析，等等。
事件驱动：发现了新的安全问题就“事后诸葛亮一把”，做点补救性措施。

安全标准是为安全体系的建设提供一个参考，而不是实操指南。最实用的参考有：ITIL(BS15000/ISO20000)、SDL、ISO27001

应急响应的PDCERF模型（参考NIST SP800-61）：

png

安全建设的需求层次：

png

传统安全场景和大型互联网场景的对比：

传统安全场景下通过采集各个终端安全软件的告警、日志，各个网络设备、安全设备的日志告警到一个数据源，用大数据进行多维度关联，最后展现告警，总体上用了一次大数据计算。

png

在大型互联网下终端可能不直接告警，而是以采集数据为主，在每一个维度的安全解决方案上都会有自己的大数据环境，即单点的安全监测手段全部大数据化，通过第一次大数据计算在自己的纵向层次（例如主机入侵检测）上产生告警，而关联分析则会在利用第一次大数据计算结果的基础上提供第二次大数据计算产生更多的信息。是否在单维度上需要用到大数据计算环境，取决于IDC规模、数据量是否足够大，不大的情况下关系型数据库+黑白规则也可以胜任，而很大的时候往往需要用到大数据和机器学习。

png

防御技术体系

攻防对抗主要是三个层面的对抗：信息对抗、技术对抗、运营能力对抗

png

互联网追求快速交付，把安全做得太厚重是“不满足业务需求的”，为追求极致的低缺陷率而大幅增加发布成本是不切实际的。但是互联网安全有几个比较核心的需求：快速检测、有限影响、快速溯源、快速恢复。

渗透路径思维导图：

png

纵深防御体系示例：

png

互联网安全架构设计原则：

纵深防御
多维防御
降维防御
实时入侵检测
伸缩性、可水平扩展
支持分布式IDC
支持自动化运维
低性能损耗
能旁路则不串联
业务无感知
去“信息孤岛”
TCO可控

业务安全的策略原则：

相对的风控而非绝对的防黑 ——业务安全的目标是相对意义上的风险控制，而不是绝对意义上的防黑。拖库只要发生一次就非常严重，但是业务安全，即使漏掉了一些，但解决了大部分的问题，那就算及格了。
增加黑产的成本而非阻断他们的行为 ——黑产，羊毛党的驱动力就是为了盈利，如果他们投入的成本超过损益点，那就没必要再去攻击你。比如注册一张银行卡的成本>获取一张手机SIM卡的成本>注册一个免费邮箱的成本。
永远的情报 ——知己知彼，百战不殆。了解黑产怎么干活事半功倍，深入敌后比躲在办公室更聪明，并非只有爬虫抓来的大数据才叫情报，蹲在对方的QQ群里也能搞到情报。
方法比技术更重要 ——上兵伐谋，最下攻城。技术的对抗是无止尽的，并且会不断地消耗内部的研发资源和IDC资源，改变战场规则可能起到一招退敌的效果。
数据比算法更重要 ——大数据的典型特征，算法可以不高大上，但是没有数据或数据太少，风控这件事也许你玩不起来。
勤能补拙 ——也许你没有大数据，但是不断地改变业务逻辑，不断地升级会使对手疲于奔命。自PS3/PSV时代起，sony不再封堵破解，而是以更短的迭代周期，更高的版本发布频率升级操作系统，新的游戏必须运行于高版本系统之上，使破解者疲惫不堪，盗版用户都懒得再破解。谁主导节奏，另外一方就疲惫。
忽略性能、用户体验和成本的风控没有意义 ——风控本身的意义在于保障正常用户和平台自身，如果正常用户体验受损或大面积误杀，则风控起了反效果。同样，一家创业型公司不太可能有资源为了做风控而爬遍整个ipv4的地址库。
纵深防御 ——纵深、多维度、降维防御在风控场景仍然适用，使用漏斗模型，由机器规则处理最原始的数据，逐步筛选过滤，由人工审核做最后一道防线。
杀鸡给猴看 ——只要条件允许，用法律武器端掉主力，用风控手段扫尾。2：8原则，对危害最大的部分不一定要用常规手段，无论什么土方法，能达成目的就好。能在安全大会上讲的高大上的方法不一定是解决问题性价比最高的手段。
人民的战争 ——教育正常的用户安全意识，动用一切资源和手段反剿黑产，以资鼓励全民情报。
社工库 ——敌人有的，我也要有。