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

本文最后更新于2016年9月24日,已超过 1 年没有更新,如果文章内容失效,还请反馈给我,谢谢!

=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=

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

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

  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

  3. Mozilla的信息安全团队介绍(Security/InfoSec)(Enterprise Information Security Team)
    https://wiki.mozilla.org/Security/InfoSec

    1. Security Information and Event Management (SIEM 安全信息事件管理平台)
    2. NSM: Network Security Monitoring (网络安全监控)
    3. Real-time systems forensic (实时系统审计)
    4. Test driven systems security (测试驱动的系统安全)
    5. Rapid Risk (Impact) Assessment (RRA) (快速风险评估)
    6. Vulnerability Assessment (脆弱性评估)
    7. Threat Modeling (威胁建模)
    8. Penetration Testing (渗透测试)
    9. Security Incident Response (安全事件应急响应)

  4. 从粗放到智能 一个资深研发眼中的安全系统建设
    https://mp.weixin.qq.com/s/–j37thnS4guO3Wm5oNxFg

    0x01 粗放对抗阶段 #规则硬编码
    0x02 专业分工对抗阶段
      2.1 基于机制而不是策略 #规则动态更新、实时生效
      2.2 DO分离 #提供界面、平台
      2.3 服务化 #功能、专业细分
    0x03 数据对抗阶段
      3.1 机器学习模型
      3.2 行为模型
        3.2.1 聚焦
        3.2.2 离散化
        3.2.3 不可能
        3.2.4 行为 # UEBA
      3.3 关联模型 # SOC/SIEM (将事件都汇聚在一起,并提供机制进行关联)
    0x04 智能对抗阶段

  5. 态势感知
    https://help.aliyun.com/knowledge_detail/42302.html

    建设云上安全体系

    事前:
    弱点分析,资产态势监控,资产依赖关系梳理,定时漏洞扫描,安全配置监控
    预防:漏洞补丁,资产弱点告警

    事中:
    入侵检测,攻击识别,异常检测 ,实时发现web层,主机层攻击,通过全网威胁情报和大数据分析对入侵事件进行实时检测
    阻断:攻击阻断,入侵防御

    事后:
    回溯:对安全事件进行回溯和调查,并提供全量原始日志的检索功能,对攻击事件的影响和系统防御效果态势进行自定义调查

  6. 信息安全运营中心建设分享
    https://mp.weixin.qq.com/s/4pTwDxfkCufprJG-eOa9Tw

    解密阿里巴巴安全技术体系
    https://mp.weixin.qq.com/s/awalKKE3IMZSWEqGpRxOHA

    “安全实验室”技术矩阵:

    阿里安全图灵实验室专注于计算机视觉、自然语言处理、机器学习和深度学习等领域的技术研发。

    阿里安全猎户座实验室是以通用系统平台、软件供应链、终端和设备为研究对象,以提升攻防对抗能力方法论为目标的实验室。

    阿里安全双子座实验室专注于数据时代的前沿的数据保护技术研究和能力输出。

    阿里安全潘多拉实验室主要聚焦于移动安全领域,包括对iOS和Android系统安全的攻击和防御技术研究。

    阿里安全米诺斯实验室是专注于应用防护技术的团队,一直在业务前沿进行攻防对抗。其致力于代码混淆、防逆向、防篡改等技术领域的研发,并通过工具化、产品化的方式输出端应用防护能力。

    阿里安全归零实验室致力于网络空间威胁技术、产业链的研究,用技术手段来应对日益严重的网络违规和网络犯罪。

    阿里安全钱盾实验室专注于全领域反病毒、反钓鱼、反诈骗技术研究,以保护和服务消费者。

    蚂蚁金服光年实验室是赋能金融支付领域的安全技术研究团队。不仅致力于护航蚂蚁金服相关产品安全性,也通过前沿的安全技术来赋能合作商户/厂商以及生态伙伴的安全性,给予用户、合作商户/厂商以及生态伙伴最大程度的保障,助力全球移动互联网安全的发展。

    蚂蚁金服非攻实验室深耕在业务线,面对新时代动态、复杂、多变的安全风险,将漏洞研究和AI算法结合,通过数据驱动安全,主动提升攻防门槛,以更动态更智能的方式进行全面业务风险管控。

  7. 浅谈企业安全建设
    https://mp.weixin.qq.com/s/EDZVfGFiAwcq45Aj6EyV4Q

    企业安全建设是保障业务正常运行,保护用户数据不被窃取,保全企业资产的首要任务。
    做安全建设一定是围绕:业务、用户、企业这三个方面来进行的。
    一下这些安全产品:

    1. 防火墙
    具有划分和隔离内网网段,设置在互联网开放的主机和端口,封堵恶意ip的流量等功能。

    2. 网络应用防火墙
    简称WAF(Web Application Firewall),针对HTTP/HTTPS协议的流量进行协议解析,检测攻击并拦截攻击,同时记录攻击流量和来源。

    3. 入侵检测
    简称IDS(Intrusion Detection Systems),检测攻击行为,查杀webshell、反弹shell、木马,检测内网端口扫描、弱口令爆破等疑似服务器权限被黑客夺取后发起的敏感行为,来发现入侵。

    4. ADS(抗DDoS系统)
    ADS(Anti-DDoS System),抗DDos系统,主要用来清洗DDos的攻击流量和防御CC攻击。

    5. 蜜罐系统
    蜜罐(HoneyPot),通过在目标网络中预埋蜜罐,引诱攻击者进入蜜罐来发现攻击,同时在监控和掌握攻击者使用的攻击手法,追查攻击来源上起到一定的作用。是一种被动感知的入侵检测系统。

    6. APT防御设备
    APT防御设备,在浏览器下载,word、pdf、ppt文档打开,邮箱附件下载,U盘自动播放等APT常见的攻击面上监控,在0day漏洞利用(exploit)攻击链上进行狙击,检测和防御APT攻击。

    7. 流量分析
    流量分析系统,从网络流量中捕获异常发现数据偷取、反弹shell、webshell上传等攻击行为。

    8. 威胁情报
    威胁情报系统,通过订阅安全博客、CVE漏洞库、微博等情报来源以及搜索引擎爬取进行情报监控,第一时间获取情报。当系统使用的软件版本受到最新公开漏洞影响时,可以快速响应,修复漏洞。

    9. 扫描器(企业安全巡检)
    扫描器,现在也叫企业安全巡检系统,可以定期轮询扫描企业全量的线上业务。扫描方法集成了已公开的安全漏洞的POC(POC:指的是漏洞的验证程序或代码,通过判断提交返回结果可快速判断漏洞是否存在)和常见web漏洞(例如:SQL注入、XSS)检测引擎。

    除了上述的通用安全产品之外,还有一些比较有针对性的安全产品和工作。

    1. 移动APP加固系统
    针对移动APP为主的业务提供加固方案,例如:代码混淆、加壳、数据加密等,主要是Android和IOS客户端。

    2. 业务安全防护产品
    防止外部黑客恶意爬取网站数据,防止机器人自动操作完成网站悬赏任务,防止薅羊毛、业务刷单等。

    3. 代码审计
    代码审计有服务也有产品,这里是指提供代码审计功能的产品,可以扫描业务代码,输出安全报告,开发人员可根据漏洞详情修补漏洞。

    4. 应急响应中心
    应急响应中心,简称SRC(Security Response Center),并非安全产品,而是需要建设的一部分工作,公司设立应急响应中心可通过悬赏的方式吸引白帽子(白帽子:在安全界是指愿意将漏洞报告给厂商的网络安全爱好者)。一定程度上可以减缓企业内部漏洞被外部恶意利用,同时还可以收集威胁情报,快速响应和处理安全突发事件。

  8. 甲方安全防御体系建设的随笔
    https://my.oschina.net/9199771/blog/3032796?from=timeline

    核心思想——投入产出比(先从让攻击者的投入产出比降低开始,然后再思考自己该怎么做才能提升自身工作的投入产出比)

    饿死了,写了好几个小时,哈哈,总结来说对于安全建设来说,首先要看自己能创造的价值,价值可以通过缩减成本或者扩大收益来获取的,每一位甲方安全建设者都要面临一个巨大的问题就是你带来了多少的价值?而这个价值越高,代表着你的建设工作的有效性。而安全建设具体落地的时候,我未来的方向会定位就是按照过去的成功历史经验,使攻击者的行动成本畸高,导致攻击者的行动付出和回报不成正比,以此作为解决企业安全建设的核心思想。

  9. 甲方IT负责人视角看安全
    https://mp.weixin.qq.com/s/ac_to2d59lcD7JdyNdmUSg

    这几年,因工作的关系,我们在安全领域做了不小投入,下了不少功夫,对从事安全领域的甲乙方小伙伴们有了更多的了解,接触下来,真觉得十分有趣,也很欣赏。安全圈无论是国内外,颇有江湖侠客之风,黑客之文化:英雄不问出处,尊重个性,崇尚技术,追求卓越。靠着先天之悟性加后天之勤奋,从业者可以一战成名,受众人尊重甚至追随。

    当下,尤其是对金融机构而言,信息安全的重要性已经不需要再特别论证。或许各家企业起心动念起点不同,但无论是主动谋求长治久安,还是仅仅为形势环境所迫,无一例外都已经将信息安全作为一项重中之重的任务来抓。但真正要做好,却着实不易。借此机会,我也从我的角度(甲方IT主管)浅谈一二。

    一、关于信息安全工作的定位:金融企业的商业价值是为客户提供金融服务,业务永远是其根本和主业,IT的价值在于把技术做好,为公司提供先进的、安全的、有市场竞争力的IT平台和工具,服务好客户。因此IT万不可跳脱出来,就着技术论技术,甚至倒逼公司做投入。信息安全作为IT的一个细分领域,也同样必须统一到这个认识上。作为甲方的安全从业人员,必须基于公司的业务、发展阶段和内外部环境,综合统筹制定安全规划和实施路径,帮助企业达成商业目标,和业务的差别仅仅是分工不同、职责不同而已。

    二、关于信息安全工作的重要性:经常听到这句话:信息安全做的好不好,首先取决于领导的重视程度。在我看来,这话对也不对。对的方面是:结果是否达成确实和领导有很大关系,如果公司不做投入,领导该承担的责任不承担,任谁都不可能做好这份工作;那为什么又说这话不对呢,因为领导不是神仙,在缺少信息支撑的情况下不可能作出预判和决策。安全人员自身要做好领域规划和布道宣传,有意识的提炼工作、向上管理。有时往往是因为自身能力的欠缺,这方面的工作做得不够,不同职场层次之间存在较大信息不对称,才造成了公司投入没有及时跟上。因此,无论是安全人员还是IT人员,这是需要时刻提醒自己和提升自己的地方。

    三、关于信息安全工作的复杂性:信息安全领域包罗万象,涉及技术与管理、研发测试运维全链条,从物理层到应用层、从机器到人都需要纳入到工作范畴里,从体系、规划、架构、管理与技术落地以及运营迭代形成闭环。这是一个复杂的系统工程,需要很强的系统性思维,持续不断的学习自驱力和卓越的执行力。

    四、关于信息安全工作的横向协作:在IT团队内部,信息安全与研发、运维、测试等都需要密切的协作,但因为安全工作更多承担了制定规范、监控监督的职责,所以,在协作方面处理不好,容易出现工作冲突,损伤士气。甲方安全人员尤其需要对这一点有深刻的认识,在工作中能够客观的看待事物和艺术的处理矛盾,积极主动、不忘初心的去达成目标,慢慢历练出专业感和职业感,当然要达到这一点是不容易的,但也是很重要的。

  10. 企业网络安全之主机入侵检测
    https://mp.weixin.qq.com/s/LZYMkorXHinDZWKEgTJdIQ

    一、开源产品OSSEC
    二、MIG
    三、OSquery
    四、自研Linux HIDS系统
    在大型互联网企业中重点关注两个方面:
    (1)海量环境影响
    大型网络中,动辄上万甚至几十万的部署量,对于每次的更新必须谨慎。这里需要设定以下原则:
    ● 发布前必须通知业务方,必须有应急预案和回滚手段。
    ● 遵循灰度发布原则,未经一个可靠的时间周期(通常一个月)稳定运营验证,不得批量部署。不同业务环境分别灰度。
    ● 节假日前不部署。
    ● agent更新行为由Server端推送任务完成。

    (2)安全性
    曾经有人开玩笑说,部署的这么多Agent就相当于一个大型的分布式僵尸网络。确实,假设恶意攻击者能操纵任何的HIDS集群系统的控制指令和平台,那么真的是“一损俱损”。为确保管理控制系统的安全性,必须设定几个安全原则:
    ● 控制(更新)指令仅允许选择固化的指令,严禁在Agent端预留执行系统命令的接口;
    ● 更新包必须经过第三方安全工程师审核之后上传至更新Server保存,更新仅允许选择更新Server上已有的安装包;
    ● 控制指令下发时必须由第三方审核批准才可执行。

    企业网络安全之数据库审计
    https://mp.weixin.qq.com/s/A0eWT7t5th3OAf4dajeHxA

  11. 用于记录企业安全规划,建设,运营,攻防的相关资源
    https://github.com/AnyeDuke/Enterprise-Security-Skill
    https://anyeduke.github.io/Enterprise-Security-Skill/

    1.企业安全规划
    2.企业安全建设:基础防护,代码审计和SDL落地,HoneyPots(蜜罐)(New)
    3.企业安全运营:基于威胁情报的安全运营
    4.书籍:企业安全规划建设运营推荐书籍
    5.思维导图:企业安全架构思维导图
    6.企业安全相关资讯:包括安全资讯,企业安全规划建设运营,其他高质量安全资讯
    7.工具:企业安全规划建设运营使用的工具
    8.攻防(目前只有攻击部分):OSINT(情报收集),**PT(持续威胁)(New)**后续会加入漏洞库,攻防对抗,APT
    9.其他
    - 1.技术部分:APT,IDS,IPS,威胁情报,安全运营
    - 2.行业翘楚实战

  12. Blade:企业安全研究团队建设运营思考
    https://mp.weixin.qq.com/s/Ya5CGXpuSEsB_vxAmF8H6g

    一、他山之石
    wushi曾经说过,科恩实验室研究方向的选择基于三个“能不能”原则:能不能持续提高核心能力;能不能影响一个产业或业务;能不能对目前的业务有所帮助。这三个原则也就是让研究工作与实际相结合做到学以致用,指导着科恩实验室走向胜利。

    二、思路探讨
    学习完了先进案例,现在我们回过头来总结一下思路。

    ① 首先我们要想清楚安全研究团队的目标是什么。
    安全研究团队肯定是需要结合业务实际情况对新技术新趋势进行预先研究,提前发现安全风险并且输出解决方案。这里的“结合业务实际情况”非常重要,作为企业的安全研究团队,我们要紧跟企业业务的实际需求才能让研究工作是有用的。一些研究项目太不切实际(或者说太超前),即使有成果但最终成果却在几年内都没法落地也只能束之高阁。基础研究自然另当别论。
    因为研究团队往往会脱离工程团队的目标甚至本身就没有KPI,很容易走偏进入自娱自乐的境地,就像脱缰的野马,最终与企业实际需求脱节,这个时候就需要类似科恩的三个“能不能”原则来判断研究方向是否值得投入。

    ② 其次是想清楚研究团队的组织结构。
    笔者认为安全研究团队要脱离工程团队的日常运营,结合业务实际发展需求,能够轻装上阵比较纯粹快速的对某个新领域进行学习和研究,通过研究成果指导工程团队布局新领域。简单说就是研究团队负责发现新的安全风险并提出解决思路和概念证明,然后交由工程团队落地执行。
    为什么要脱离工程团队呢,这样研究团队的目标能够更纯粹,不会受累于其他事务,所以能够专注去做研究有更多的产出,同时也能轻松进入新领域。

    ③ 接下来就是人才了。
    专业能力和兴趣缺一不可。专业的人很重要,特别对于攻坚突破的安全研究团队,可以说人的专业能力直接决定了事情的成败。所以我们要根据待研究领域的专业能力分类,招募具备或者有潜力具备这部分能力的人才。同时大部分时候研究工作又是很枯燥的,兴趣是能够长期坚持下去的主要因素。

    天时地利人和之后,剩下的一切就交给时间了。要尊重客观规律,研究工作不是简单加大人力投入就能提速的。比如我们做的智能音箱安全研究,足足花了一年时间,也就是说一年时间内大部分时间里可能没有任何输出,团队心态要好,既要坐得了冷板凳又要抗得住聚光灯。

发表评论

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