[read]互联网企业安全高级指南

=Start=

缘由:

无意之中看到的这本书,翻了一下之后感觉如获至宝,一方面恨自己差点错过这本书,另一方面又觉得非常幸运能看到这本书。本书的赞誉非常多,我也不一一列举了,一句话概括——是互联网企业安全从业人员的必读经典

全书还没有读完,先把目录列出来方便以后快速检索,但其实更推荐的是买几本书分别放在公司、家里,随时翻阅。在本文最后列出了作者的博客地址,其中有非常之多的干货,非常值得关注。

正文:

理论篇

第1章 安全大环境与背景
1.1 切入“企业安全”的视角
1.2 企业安全包括哪些事情
1.3 互联网企业和传统企业在安全建设中的区别
1.4 不同规模企业的安全管理
1.5 生态级企业vs平台级企业安全建设的需求
1.6 云环境下的安全变迁

第2章 安全的组织
2.1 创业型企业一定需要CSO吗
2.2 如何建立一支安全团队

第3章 甲方安全建设方法论
3.1 从零开始
3.2 不同阶段的安全建设重点
3.3 如何推动安全策略
3.4 安全需要向业务妥协吗
3.5 选择在不同的维度做防御
3.6 需要自己发明安全机制吗
3.7 如何看待SDL
3.8 STRIDE威胁建模
3.9 关于ISO27001
3.10 流程与“反流程”
3.11 业务持续性管理
3.12 关于应急响应
3.13 安全建设的“马斯洛需求”层次
3.14 TCO和ROI

第4章 业界的模糊地带
4.1 关于大数据安全
4.2 解决方案的争议

技术篇

第5章 防御架构原则
5.1 防守体系建设三部曲
5.2 大规模生产网络的纵深防御架构

第6章 基础安全措施
6.1 安全域划分
6.2 系统安全加固
6.3 服务器4A

第7章 网络安全
7.1 网络入侵检测
7.2 T级DDoS防御
7.3 链路劫持
7.4 应用防火墙WAF

第8章 入侵感知体系
8.1 主机入侵检测
8.2 检测webshell
8.3 RASP
8.4 数据库审计
8.5 入侵检测数据分析平台
8.6 入侵检测数据模型
8.7 数据链生态——僵尸网络
8.8 安全运营

第9章 漏洞扫描
9.1 概述
9.2 漏洞扫描的种类
9.3 如何应对大规模的资产扫描
9.4 小结

第10章 移动应用安全
10.1 背景
10.2 业务架构分析
10.3 移动操作系统安全简介
10.4 签名管理
10.5 应用沙盒及权限
10.6 应用安全风险分析
10.7 安全应对
10.8 安全评估
10.9 关于移动认证

第11章 代码审计
11.1 自动化审计产品
11.2 Coverity

第12章 办公网络安全
12.1 文化问题
12.2 安全域划分
12.3 终端管理
12.4 安全网关
12.5 研发管理
12.6 远程访问
12.7 虚拟化桌面
12.8 APT
12.9 DLP数据防泄密
12.10 移动办公和边界模糊化
12.11 技术之外

第13章 安全管理体系
13.1 相对“全集”
13.2 组织
13.3 KPI
13.4 外部评价指标
13.5 最小集合
13.6 安全产品研发
13.7 开放与合作

第14章 隐私保护
14.1 数据分类
14.2 访问控制
14.3 数据隔离
14.4 数据加密
14.5 密钥管理
14.6 安全删除
14.7 匿名化
14.8 内容分级

实践篇

第15章 业务安全与风控
15.1 对抗原则
15.2 账号安全
15.3 电商类
15.4 广告类
15.5 媒体类
15.6 网游类
15.7 云计算

第16章 大规模纵深防御体系设计与实现
16.1 设计方案的考虑
16.2 不同场景下的裁剪

第17章 分阶段的安全体系建设
17.1 宏观过程
17.2 清理灰色地带
17.3 建立应急响应能力
17.4 运营环节

附录 信息安全行业从业指南2.0

更多参考链接:

=END=

声明: 除非注明,CrazyOf.me文章均为原创,转载请以链接形式标明本文地址,谢谢!
https://crazyof.me/blog/archives/2913.html

《[read]互联网企业安全高级指南》上有12条评论

  1. 6.2 系统安全加固 → 6.2.1 Linux加固
    1.禁用LKM(规避类似于 knark、adore 这类的LKM rootkit,把入侵检测聚焦于用户态)
    # echo 1>/proc/sys/kernel/modules_disabled

    2.限制/dev/mem(规避类似于 suckit 这种在用户态实现内核rootkit的功能)
    # cat /boot/config-$(uname -r) | grep 'DEVMEM'

    Linux on-the-fly kernel patching without LKM – Phrack Magazine [http://phrack.org/issues/58/7.html]
    http://www.xfocus.net/articles/200201/340.html

    3.内核参数调整
    4.禁用NAT(在常规机器上禁用NAT)
    # echo 0>/proc/sys/net/ipv4/ip_forward

    5.Bash日志
    6.高级技巧(修改shell源代码)

  2. 企业安全3张表

    第一张表:组织结构图。
    这是开展业务的基础,扫视一下组织结构中每一块安全工作的干系人。例如行政、HR、财务部门是跟公司层面信息安全管理的全局性制度的制定和发布相关的部门,内部审计也跟他们强相关;基础架构的运维团队,运维安全相关的要跟他们合作;研发团队,可能在组织结构中分散于各个事业部、各产品线,不一定叫研发,但本质都是产品交付的团队,应用安全和基础服务器软件安全相关的要找他们,也是SDL实施的主要对象;运营、市场、客服类职能他们可能没有直接的系统权限,但是会有一些诸如CMS的后台权限(被社工的对象),广告的引入发布(挂马的iframe,黑链)等乱七八糟的安全问题的关联者,他们也是某些重大安全事件上升到社会影响的危机管理的公关部门;(大)数据部门,因为安全也要用到大数据,看是复用一套技术架构还是自己搞,这个取决于每个公司的实际状况,有的自己搞,有的则复用;产品部门,一些跟业务安全和风控相关的安全建设要跟他们合作;CXOs这里泛指组织中的决策层,什么问题要借助他们自己拿捏吧,双刃剑。

    第二张表:每一个线上产品(服务)和交付团队(包括其主要负责人)的映射。
    这张图实际就是缩水版的问题响应流程,是日常安全问题的窗口,漏洞管理流程主要通过这些渠道去push,一个安全team的leader通常需要对应一个或若干产品的安全改进。不过这里也要分一下权重,比如支撑公司主要营收的产品需要一个主力小团队去负责其SDL全过程,而边缘性的产品一个小团队可以并发承接好几个甚至10个以上的产品,粒度相对粗一点过滤主要的安全问题即可,通常这样做符合风险管理方法论,但对于深知大公司病又创业过的我来说,还是稍微有些补充的看法,很多成长中的业务,出于起步阶段,没有庞大的用户群,可能得不到公共职能的有力扶持,例如运维、安全等,明日之星的业务完全可能被扼杀在摇篮里,这种时候对有责任心的安全团队来说如何带着VC的眼光选择性的投入是一件很有意思的事。在一个公司里是安全团队的话语权大还是支柱产品线的话语权大?当然是支柱产品,等产品成长起来了再去补安全的课这种事后诸葛亮的事情谁都会做,说的难听一点业务成长起来时自己都能去建安全团队了,不一定再需要公共安全团队的支持。锦上添花还是雪中送炭业务团队的这种感受最后也会反馈给安全团队,so, up 2 u!

    第三张表:准确的说应该是第三类,包括全网拓扑,各系统的逻辑架构图,物理部署图,各系统间的调用关系,服务治理结构,数据流关系等。
    这些图未必一开始就有现成的,促成业务团队交付或者自己去调研都可以,以后的日常工作都需要这些基础材料。如果运维有资产管理也需要关注一下。

    企业安全初期要做的3件事

    第一件是建立「事前」的安全基线,不可能永远做事后的救火队长,所以一定要从源头尽可能保证你到位后新上线的系统是安全的;
    第二件是建立「事中」的监控的能力,各种多维度的入侵检测,做到有针对性的、及时的救火;
    第三件是做好「事后」的应急响应能力,让应急的时间成本更短,溯源和根因分析的能力更强。

    http://www.ayazero.com/?p=50

发表评论

电子邮件地址不会被公开。 必填项已用*标注