[read]互联网安全建设从0到1


=Start=

缘由:

整理标记一下前段时间看过的《互联网安全建设从0到1》这本书的内容,方便有需要的同学参考。

正文:

参考解答:

和企业安全相关的书籍我基本都会买/借回来看(为的是较为系统的了解业内同行都是怎么想的和怎么做的,学习吸收其中做的比较好的地方)。

这次看的《互联网安全建设从0到1》是找同事借的,因为之前书刚出来的时候,快速浏览过目录结构,看到前几章的libpcap和scapy等关键字,潜意识里觉得这本书的”等级”不高,对于大中型互联网公司来说参考价值不大(因为大中型互联网公司的很多方案架构都是自研或是在开源基础上经过二次开发,以适应高并发、大流量以及复杂的流程/架构,开源的工具/方案是很难满足这些需求的)。但本着看一看也没坏处的想法,快速翻阅了一下,感觉还可以,并不像我之前仅翻目录时以为的那样。

作者本身的诚意还是挺足的,从书中的大量截图就能看出来,但很多地方也确实如书名所说只是从0到1(有广度但深度还不够),对于中小型公司来说还是很有参考意义的;另外就是因为作者曾在几家公司都担任过安全负责人,所以基本上是很全面的介绍了企业进行互联网业务时所必备的安全技术和安全体系,对于一些主要做传统安全攻防对抗方向的同学来说,最后几章和业务安全相关的内容还是可以多学习了解一下的。

另外就是根据我个人看过的和互联网安全相关的书籍/文章来看,现在市面上没有书能够覆盖大型互联网企业安全的内容(当前最接近的一本应该是《互联网企业安全高级指南》,其中的理论思路是很好的,但介绍具体技术方法的内容已经稍微有点陈旧了;最近出的另一本《大型互联网企业安全架构》,其中的”主机安全”相关的内容很好,但是在数据安全和业务安全以及一些其它方向上就明显不够了),感觉以后也很可能不可能会有。

一方面是因为,现在企业中安全涉及的领域越来越多,新技术新思路乃至新业务层出不穷,企业安全团队面临的形势/重点也在不断变化,一个人写的话太难了(除非是很早就在一直做安全的大佬,要有长期的一线经验,还要有高层次的视野,才能cover住大部分内容,但这种人凤毛麟角,而且还不一定愿意写),那最可能的就是由一个团队来写,但这也会有问题,比如:不同的人背景不一样,技术能力不一样,语言风格很难统一……

另一方面就是,安全很多时候是在和人对抗,而且企业安全很多时候还会借助信息不对称的优势,这种情况下,你出书/写文章,就很容易面临一种困境——写的浅了,会被喷没有干货;写的深了,如果涉及到对外暴露策略的问题,很可能是自己给自己挖坑。

不过总的来说,近些年好的、体系化的安全文章越来越多了,也有更多的公司愿意去分享,所以说不定以后会有的,一起加油吧。


第1章 网络安全

1.1 网络流量的收集
1.1.1 最传统的抓包方式libpcap
1.1.2 scapy
1.1.3 gopacket
1.1.4 丢包与性能提升
1.1.5 PF_RING、DPDK与af_packet

1.2 Web流量的抓取方式
1.2.1 TCP流还原
1.2.2 HTTP
1.2.3 使用packetbeat抓取网络流量
1.2.4 其他方案
1.2.5 一些常见问题

1.3 其他流量收集方式
1.3.1 tcpdump
1.3.2 Wireshark
1.3.3 tshark

1.4 开源网络入侵检测工具Suricata
1.4.1 Suricata安装
1.4.2 Suricata suricata.yaml 配置介绍

1.5 DDoS简介及检测
1.5.1 DDoS基本防御手段
1.5.2 建立简单的DDoS检测系统

1.6 本章小结

第2章 运维安全

2.1 Web组件安全
2.1.1 Nginx安全
2.1.2 PHP安全
2.1.3 Tomcat 安全

2.2 其他组件安全
2.2.1 Redis安全
2.2.2 Elasticsearch 安全
2.2.3 其他相关组件:Kafka、MySQL、Oracle等

2.3 上云安全
2.3.1 流量获取
2.3.2 边界管理
2.3.3 云存储安全
2.3.4 小结

2.4 其他安全建议

2.5 本章小结

第3章 主机安全

3.1 Windows主机安全
3.1.1 Windows主机补丁
3.1.2 补丁管理工具WSUS
3.1.3 Windows系统加固建议
3.1.4 Windows经典漏洞简介

3.2 Windows入侵溯源分析
3.2.1 系统
3.2.2 服务
3.2.3 文件
3.2.4 网络

3.3 Linux主机安全
3.3.1 Linux补丁
3.3.2 Linux系统加固建议
3.3.3 bash安全设置
3.3.4 Linux经典漏洞介绍

3.4 Linux入侵溯源分析
3.4.1 系统
3.4.2 服务漏洞检查
3.4.3 恶意进程排查
3.4.4 文件
3.4.5 网络

3.5 主机入侵检测系统
3.5.1 OSSEC简介及其应用
3.5.2 商业Agent
3.5.3 其他主机Agent简介

3.6 本章小结

第4章 办公网安全

4.1 办公网安全总览
4.1.1 设备安全
4.1.2 网络安全
4.1.3 无线安全
4.1.4 人员安全
4.1.5 DNS监控
4.1.6 物理安全

4.2 Windows域控安全
4.2.1 SYSVOL与GPP漏洞
4.2.2 不要轻易在其他机器中使用域控密码

4.3 网络准入控制技术
4.3.1 802.1X
4.3.2 Windows 网络策略和访问服务
4.3.3 网络策略服务器
4.3.4 Cisco 2500无线控制器+NAS + AD实现802.1X
4.3.5 有线交换机+NAP实现802.1X
4.3.6 Portal登录

4.4 其他办公网络安全技术
4.4.1 DHCP Snooping简介和配置
4.4.2 DAI简介及配置

4.5 浅谈APT攻击
4.5.1 防御阶段
4.5.2 防御节点

4.6 本章小结

第5章 开发安全

5.1 SDL

5.2 代码安全

5.3 漏洞扫描系统建设
5.3.1 业务丰富型企业的扫描系统建设
5.3.2 业务单一型企业的扫描系统建设

5.4 扫描系统运营

5.5 本章小结

第6章 日志分析

6.1 Web日志分析
6.1.1 常见Web服务器日志配置
6.1.2 常用的Web分析命令(Linux)
6.1.3 Web 日志分析思路

6.2 Windows日志分析
6.2.1 Windows 日志介绍
6.2.2 常见日志代码介绍
6.2.3 Windows日志分析工具介绍

6.3 Linux日志分析
6.3.1 Linux日志介绍
6.3.2 Linux重要日志详细介绍及相关命令解释
6.3.3 配置syslog发送日志

6.4 日志分析系统ELK的介绍及使用
6.4.1 Logstash
6.4.2 Elasticsearch
6.4.3 Kibana
6.4.4 OSSEC+ELK
6.4.5 Suricata+ELK

6.5 本章小结

第7章 安全平台建设

7.1 设置安全层级

7.2 安全平台建设步骤

7.3 安全平台实现案例
7.3.1 日志分析平台
7.3.2 漏洞记录平台

7.4 其他安全工作

7.5 关于安全工作的一点心得

7.6 本章小结

第8章 安全监控

8.1 知己:了解自身

8.2 知彼:了解对手

8.3 监控策略

8.4 ATT&CK

8.5 本章小结

第9章 隐私与数据安全

9.1 GDPR介绍

9.2 企业针对GDPR的主要工作

9.3 国内个人信息数据安全相关规范

9.4 数据安全

9.5 数据保护影响评估系统简介

9.6 本章小结

第10章 业务安全

10.1 账号安全
10.1.1 账号安全问题
10.1.2 保护账户安全

10.2 支付安全

10.3 内容安全

10.4 其他业务安全

10.5 本章小结

第11章 风控体系建设

11.1 羊毛党和黄牛
11.1.1 工具和角色
11.1.2 刷单类型

11.2 设备指纹系统

11.3 风控系统建设
11.3.1 数据平台
11.3.2 规则平台
11.3.3 处理平台
11.3.4 处罚平台
11.3.5 运营平台
11.3.6 回放平台

11.4 安全画像服务

11.5 风控案例
11.5.1 签到获月卡
11.5.2 领取奖励后退款
11.5.3 通过废弃接口注册/登录
11.5.4 HTML 5页面刷单
11.5.5 商户刷单
11.5.6 异地核销
11.5.7 余额大法
11.5.8 小结

11.6 关于风控系统建设的一些建议

11.7 风控工作的经验总结

11.8 本章小结

第12章 企业安全体系建设

12.1 概述

12.2 安全体系建设的内容
12.2.1 建立管理体系
12.2.2 建立技术体系
12.2.3 建立运营体系

12.3 安全体系建设步骤

12.4 本章小结

参考链接:

互联网安全建设从0到1
https://book.douban.com/subject/35118713/

=END=


《 “[read]互联网安全建设从0到1” 》 有 7 条评论

  1. Application-level Purple Teaming: A case study
    https://labs.f-secure.com/blog/application-level-purple-teaming/
    `
    This post describes our approach to application-level purple teaming for a specific app; yours would likely be different. We’ve started discussing this approach with a few different organisations, who each have different requirements and levels of sophistication. For this case study, the general flow looked like this:

    1. We first performed a threat modelling exercise to understand the app, its technology stack, the attackers who might target it, higher-likelihood attacks and existing controls. We used this to decide on baseline metrics we would need to capture, as well as the main categories and test cases we would benchmark the app against.
    2. In iteration #1, we focused on baselining the app’s current attack-awareness, specifically its logging and alerting across our test cases.
    3. In iteration #2, we assessed the improvements to logging and alerting across those test cases, using common toolsets for this. At this stage, we also began considering what response could look like.
    4. In future, we will seek to close gaps in logging and alerting for remaining categories and start introducing responsiveness for those categories we’ve already covered.
    `

  2. 诸子笔会 | 刘顺:企业数据安全体系建设实践
    https://mp.weixin.qq.com/s/oywY73UnO0wK6sK4YP4tNw
    `
    本文从数据安全事件的风险类型,数据安全法律法规的指引与要求出发,输出了企业数据安全体系的总体框架,并就框架中的重要举措,提出了落地执行方面的参考建议。

    # 数据安全事件的风险类型
    (一) 风险1:外部攻击窃取数据
    (二) 风险2:业务人员泄露数据
    (三) 风险3:运维人员泄露数据
    (四) 风险4:研发人员泄露数据
    (五) 风险5:外部第三方泄露数据

    # 数据安全法律法规及相关标准

    # 企业数据安全体系总体框架

    # 数据生命周期安全管控
    (一) 安全管控思路

    (二) 数据分类分级
    1. 分类分级的必要性
    2. 数据分类工作的落地
    3. 数据分级工作的落地
    4. 结构化数据的自动分类分级

    (三) 基于业务场景的数据流转梳理与风险评估
    1.非结构化数据
    2.结构化数据

    (四) 数据存储安全管控

    (五) 数据使用安全管控
    1. 严格控制授权
    2. 数据查询(编辑)安全管控
    3. 数据下载安全管控
    4. 数据共享、联合风控场景下安全管控
    1) 静态自动化脱敏
    2) 动态自动化脱敏
    3) 隐私计算
    A.多方计算
    B. 联邦学习
    C.可信执行环境

    (六) 数据风险感知
    1.流量分析感知数据风险
    2. 应用日志感知数据风险

    # 办公终端安全管控
    (一) 办公终端数据安全风险
    (二) 办公终端数据安全管控

    # 运维安全管控
    (一) 数据库访问行为审计
    (二) 数据库安全审计产品

    # 数据安全管理体系建设
    除上述一系列技术举措的建设外,数据安全同样离不开完善的管理体系建设。包括:设立数据安全管理委员会,建立自上而下的覆盖决策、管理、执行、监督四个层面的安全组织体系,明确数据安全的组织架构和专业岗位设置。建立统一的、分类分级的数据安全管理制度体系,明确各部门和相关岗位的数据安全职责,规范工作流程。建立覆盖人员职业生命周期的人员安全管理机制,包括背景调查、保密协议、安全培训、权限管理、合同终止权限回收等。建立完善的第三方安全管理机制,包括审查评估、合同约束、保密协议等等。管理体系的建设工作在此不再展开详述。

    # 总结
    如何保护数据的安全是目前各行业广泛面临的挑战,是各企业安全建设的重点和难点,如上面《企业数据安全体系总体框架》所示,数据安全涉及企业安全建设的方方面面,某一项工作没有做好可能会因为“木桶原理”导致数据安全事件的发生。数据安全没有一招见效的“银弹”,唯有明确目标、砥砺前行。
    `

  3. 浅谈企业安全建设“道”与“术”–道篇
    https://mp.weixin.qq.com/s/6JMofN8KlLj03nFfFIKsxg
    `
    # 漏洞防御、威胁防御与双向安全治理

    一般在企业安全建设的早期,风险收敛主要围绕漏洞进行挖掘和治理,做漏洞的管理,有点类似于打地鼠,这种方式是比较简单、快速和高效,在早期是能够快速看到明显的效果;但毕竟非体系化的治理,所以也确实会存在不够全面的问题,受限于相关漏洞挖掘活动覆盖的面、深度等。

    而威胁防御则更强调是全生命周期的安全治理,更类似于航母战斗群,所以对应会更全面,但对应一个周期下来也会有比较长的执行周期,同时对于安全投入是有比较大的要求,安全组织、文化、工具等,也需要更多的适配业务研发运维体系。

    很难说只用其中一种方式进行整体的安全治理,或者哪种方式比另一种更好,更多还是看不同企业的模式来进行适配,以及更多时候是结合使用。

    * 威胁防御是从左到右,收敛源头,规避漏洞上线;
    * 漏洞防御是从右到左,收敛结果,消减漏洞影响;
    * 漏洞防御的起始通过攻防对抗驱动,威胁防御的尽头通过攻防对抗验证。

    我称之为 “安全双向线模型” ,通过 双向安全治理 ,后者核心收敛重点问题,前者实现全生命周期风险消减,通过攻防对抗促进与验证,最终达成 “平行安全” 。

    # 安全需求与安全建设

    就目前而言,大家通常对安全的需求一般总结为“安全合规与可控”,合规好理解,何为可控?我的理解是“有限影响,安全可达”,也就是出现的安全问题与事件不超出预期,安全可以检测、监测、响应、恢复、溯源。

    拆解到下一层对于安全团队,我理解主要是这样一个公式:快速检测+有效监测+及时响应+快速恢复+能够溯源=有限影响,公式的左边是安全可达,右边是有限影响,只有安全达成几个要素,才能实现有限影响。

    基于这样的要求,安全建设怎么做?
    * 由外及里:虽然现在都在讲零信任,当然能达成更好,但在达成不了的情况,对于大部分企业而言,边界是个有效的做法,先管控对外风险面,比如高危服务、管理后台对外的开放,外网IP、域名的上线;再到内部治理,内网的服务、应用治理与各种监测的覆盖,统一的鉴权等
    * 抓大放小:优先抓主要矛盾,消减大的问题;对业务和场景分级分类,抓重要和与核心业务,适配不同方案和要求
    * 从点到面:先解决突出的问题点,快速消减,规避损失,再考虑面的解决方案,通过管控手段与卡点彻底消除问题
    * 由粗到细:从粗粒度管控,再到精细化运营,比如针对自研、OEM或者线上发布、私有化交付的不同形态的产品,制定大的统一安全要求,再针对不同形态产品和场景识别细粒度安全需求,精细化运营
    * 从解决问题到讲究效率:先解决问题,小步快跑,快速迭代,再考虑工具系统、标准化,提升效率
    * 从安全可感知到可度量:先让安全可感知,业务侧认可安全重要性,然后需要重点关注安全的度量建设与指标化度量,有安全建设的度量与价值呈现,也有业务安全成熟度的度量

    # 安全攻击与防御

    * 防御:防御优势,信息反制
    * 攻击:攻防差距,技术压制

    # 专项重保与防御

    整体分为前中后,事前组织协调与梳理加固,事中主要是安全值守,监测响应,事后主要为复盘总结。
    这里安全团队需要懂得抓住时机,通过相关活动查缺补漏,然后推动相关的安全建设和管理措施落地,切实消减风险和推动防御体系水平提升,而不是仅仅为了专项活动做准备。
    `

  4. 业务风险枚举与规避知识 v0.1.0 BREAK(Business Risk Enumeration & Avoidance Kownledge)一个开放式框架
    https://break.jd.army/
    https://github.com/JDArmy/BREAK
    `
    分为 业务、内容、身份、对抗 几个维度的风险

    # 业务维度

    ## 营销风险
    流程自动化
    卡券枚举
    营销活动作弊
    批量小号作弊
    虚假裂变
    广告欺诈

    ## 交易风险
    恶意退货
    批量退款
    恶意占库存
    恶意差评
    秒拍出价
    拍卖狙击
    低价购风险
    退货造假
    闪退套利
    恶意拒收
    拆单套利
    恶意索赔
    虚假交易
    虚假好评
    洗钱/诈骗
    违规商品
    刷单
    恶意客诉
    权益滥用

    ## 游戏运营风险
    团伙代充
    账号倒卖
    游戏外挂/脚本

    # 内容维度

    ## 用户内容风险
    文本内容风险
    图片内容风险
    音频(流)内容风险
    视频(流)内容风险
    消息骚扰

    ## 违规引流风险
    刷量刷榜
    外部链接风险
    干扰搜索结果
    恶意挖墙脚
    实时评论广告引流
    广告引流

    # 身份维度

    ## 身份风险
    批量注册
    撞库攻击
    凭证破解
    密码喷射
    自动化养号
    凭据复用
    多因素破解
    第三方账号聚合
    登录扫码欺诈
    手机二次号

    ## 盗号变现风险
    撞卡攻击
    支付卡破解
    盗卡盗刷
    黑卡支付
    仿冒转账
    积分盗刷
    信用卡/借款套现

    # 对抗维度

    ## 身份对抗风险
    未成年人识别对抗
    人机识别对抗
    人脸识别对抗
    代登录、代下单

    ## 设备对抗风险
    风险设备识别对抗
    逆向分析
    HTTP请求分析
    虚拟设备对抗

    ## 非法请求风险
    验证码恶意消耗
    经营数据盗爬
    敏感数据泄露
    CC攻击
    `

  5. 合规性:虚假的安全感?
    https://mp.weixin.qq.com/s/Icmf2wFCWVcfohoClhNHkA
    `
    在国外,也有人对合规性带来的虚假安全感进行了自己的观点输出,我们一起看看。

    谈到合规性,很多人会读到这个标题并认为我疯了。如果我符合 NIST、HIPAA、ISO、PCI 等,那么我正在运行一个安全网络。

    并且在某种程度上是正确的。

    但是让我们这样看。如果在州际公路上以规定的限速行驶,并且面前的驾驶员之间保持三个车距,那么在州际公路上真的安全吗?

    一点也不。虽然我们已经习惯于了解周围的环境,但在田纳西州,我猜其他州和国家总会发生一些情况。有时,拖拉机拖车会在车道上行驶直到它结束,然后如果有人在相邻车道上,就会不小心合并。因此,我们训练自己不断检查周围的环境,寻找潜在的危险,并能够迅速采取行动以避免事故。

    安全性必须相同。正如我们使用镜子寻找潜在危险一样,我们需要四处寻找潜在的漏洞。如果我们训练自己和我们的员工不断寻找潜在的漏洞,那么我们就会为自己创造一种安全心态。

    让我们继续驾驶类比。遵守交通法规的司机通过限速或接近限速,在转弯前发出信号并注意行人,比盲目地走在路上希望一切都好,每个人都让开的人更安全。这类似于 HIPPA、PCI 和 GDPR 兼容,安全,但可以进一步收紧。

    当我们去商场时,我们把车停在停车场人口稠密区的灯光附近,并锁上车门以保护车内物品。我们也不会停在离线路太近的地方,这样我们就不会收到任何门铃。为了保护我们珍贵的数据,我们需要确保我们的系统受到最新病毒定义的保护,使用最新的安全补丁进行更新,并且位于防火墙后面。在您的防火墙上实施入侵检测系统会在威胁行为者试图在您的防火墙中放置 dings 以发现您的弱点时提醒您。

    我们轮换轮胎,更换机油,更换刹车,所有这些都是为了在我们需要的时候有可靠的交通工具。同样,我们需要在我们的应用程序中实现冗余,使用最新的更新来更新我们的系统,并强制执行最低权限访问,以便我们拥有可靠的系统。

    必须记住的是,即使采取了所有预防措施并且驾驶员/员工训练有素并且知识渊博的事故仍然可能发生。

    甚至对我来说。

    一个星期六的早上,我参加机器人赛季启动会议迟到了。我赶紧把我的笔记本电脑连接到电视上,然后打开了我们的 Kickoff 视频将在 15 分钟后开始播放的网站。该网页说我需要更新 Java 才能继续,我点击了确定,因为我没有时间花在这上面。然后它突然袭击了我。该 Java 更新窗口有一个蓝色徽标,而不是正常的红色 Java 徽标。我看了一下网址,我拼错了。哎呀,在我匆忙的状态下,我并没有回到我的安全心态。现在我有一台笔记本电脑要重建。

    如果我们将我们的安全计划建立在我们需要满足的法规遵从性之上。我们的计划仍然存在弱点。

    安全链的强度取决于其最薄弱的环节。然而,如果我们训练自己有安全的心态,它就像我们需要的肌肉记忆一样。我们将以更安全的方式每天运营,并不断了解我们的周围环境。一旦我们作为一个组织以这种方式运作,监管合规性就会到位。

    后记:总的来说,前面是一个外国人通过国外的安全媒体,发表了自己对合规性的看法。这个看法,至少在国内也是很有市场的。在这里,我并不是能给出更多的参考,不过我一直认为被动合规或名义上的合规,都是伪合规。只重其形式,不注重其意义,可以说是背离了安全的合规动作。但是,没有这形式化的合规,更谈不上真实意义上的合规。其实,凡事都是一样,先是见样学样,完成初步或被动合规;再者理解安全的真正价值属性,使之真实意义上合规;再者是所有完备,超越合规要求而为自身业务追求安全。而人常常落于第一层,无法动弹了。
    `

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注