《互联网企业安全高级指南》读书笔记

Introduction

有幸拜读此书,来源iami师傅的读书笔记,本文结合师傅的笔记添加自己的一部分内容和思考。

第一章 安全大环境与背景

企业安全要关注的项目范畴似乎更加广义

  • 网络安全
  • 平台和业务安全
  • 信息安全
  • IT风险管理, IT审计&内控
  • 业务持续性管理BCM
  • 安全品牌营销和渠道维护

大型互联网企业安全建设的方法论
自研或对开源软件进行二次开发+无限水平扩展的软件架构+构建于普通中低端硬件之上(PC服务器甚至是白牌)+大数据机器学习的方式,是目前大型互联网公司用来应对业务持续性增长的主流安全解决方案。是否真的到了机器学习阶段这个有点难说,但是安全进入大数据时代则是肯定的。

第二章 安全的组织

  • 极客型,创业型,中小型,大型等企业的安全水平必然不一样,而且即便在一个企业中,他的每一阶段的安全建设也是不一样的。
  • 事前基线做好,新的服务器要确认安全,旧的逐步建立入侵检测系统。基础安全(10%的精力)做完之后投入一定的精力在业务安全,输出新的成果。领域要关注到反爬,账号等等,不同的行业关注的不一。其次要关注工具的自动化,和动作的自动化。

第三章 甲方安全建设方法论

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

    ​ 生产网络和办公网络的网络安全的基础部分

    ​ 广义信息安全,业务安全

    ​ 自研工具

    ​ 对外开放

  • 用“我们”去和其他部门沟通安全问题

  • 管理的最初驱动是事件驱动和管理驱动。

  • 针对以WEB产品为主的安全建设,一是事后修复的成本较低,二是部分的产品生命周期较短。

  • STRIDE威胁建模工具

  • 应急响应有一个PDCERF模型

TODO:

  • 需要了解的规范 ITIL(BS15000/ISO20000)
  • 需要了解的规范 ISO27001
  • 需要了解微软SDL
  • 开拓视野,技术+标准系统
  • 读《威胁建模》这本书

CSO面临的问题: 如何推动安全策略? 如何被认可,提高可信度? 如何看待SDL? 无法完全落地的原因是什么?

第四章 业界的模糊地带

  • 而在大型互联网下终端可能不直接告警,而是以采集数据为主,在每一个维度的安全解决方案上都会有自己的大数据环境,即单点的安全监测手段全部大数据化,通过第一次大数据计算在自己的纵向层次(例如主机入侵检测)上产生告警,而关联分析则会在利用第一次大数据计算结果的基础上提供第二次大数据计算产生更多的信息。是否在单维度上需要用到大数据计算环境,取决于IDC规模、数据量是否足够大,不大的情况下关系型数据库+黑白规则也可以胜任,而很大的时候往往需要用到大数据和机器学习。
  • OWASP的崛起在于,防火墙如同内衣一般起到了端口收拢和netfliter的作用。当一切收口至80,那么针对HTTP应用产生的攻击自然而然成为了防御的重点。其次也可以将WAF看做一个为七层流量清洗的NIDS设备。
  • 当一个复杂生产网络的成千上万服务器分布在世界各地的IDC,资产附属也归不同的SA时。作为安全人员其实应该事先考虑到:逻辑架构与部署架构的差异点,以及当前架构下的资产由什么样的组织架构所属。

第五章 防御架构原则

本章更多的讲述了安全架构上的一些原则性问题。

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

  • 互联网安全有几个比较核心的需求:快速检测、有限影响、快速溯源、快速恢复。通俗解释一遍就是:允许带着一些问题上线,但是有bug或入侵时安全人士能快速检测到而不是处于无知无觉的状态,就算发生了攻击或入侵,安全人士能做到使入侵者所获取的权限和造成的影响尽可能的小,并且安全人士有途径或快照还原入侵过程做根因分析,安全事件能在基本不影响业务的情况下恢复到健康状态。

  • 纵深防御的前提应该是以业务层次划分域后,针对相同主机组具有同一安全级别的继续划分新的安全域。同时在数据库序列(可能业务无关)的层次划分新的安全域。

  • 互联网安全架构设计原则
    1.纵深防御

    2.多维防御

    3.降维防御

    4.实时入侵检测

    5.伸缩性、可水平扩展

  • 在设计通过特定途径访问生产网机器的时候,在考虑网络划分的前提下仍需要考虑用户角色需要使用到的一些特殊工具。比如devops的可能拥有自动化部署工具,针对这些工具的访问方式做好怎么样的限制。

  • 在威胁层层防护的过程,可以通过考虑同一风险项的不同层位置,以及不同层的不同风险。

  • 对抗不仅仅在技术上,运营方面,情报获取方面等等

  • 架构方案至少A,B,C三个以上,这样才能够提供有效的灾备。

  • 安全域层面隔离基本上是业务上的,数据链路层隔离基本是网络上的,针对端口过滤即是网络层也是主机层的,属于更加具象化的东西。

注意点:

  • 防御的伸缩性和水平扩展能力。当前云计算环境下,安全如何自适应服务的扩展。
  • 检测的高性能,性能的低损耗。
  • 业务的无感知,架构上降低耦合。(其实旁路和透明代理的模式,差不多这样)
  • 成本要可控。大型互联网公司的海量IDC情况下怎么使得成本可控?
  • “信息孤岛”不可取,信息孤岛是个很严重的问题,极大的降低了劳动效率

第六章 基础安全措施

本章主要讲述基础安全实操相关的一些技术点

  • 需要多端协同,迫使数据收拢和运行态收拢。比如说通过定制镜像杜绝一些内核开关,同时迫使特定方面的数据收敛至用户态。
  • 网络上的基线,主机上的基线,ACL的基线,应用的基线(可写不可解析,可解析不可写),其他基础设施(LDAP,之外,重要的点应该是一个策略针对不同环境上的映射。baseline往往是管理策略。一切可变需要处于可控变化。
  • 以白过滤黑。建立正常管理员和运维人员的行为profile,离线训练识别。

TODO:

  • 搞一份安全基线的checklist (协同网络,安全组配置,系统配置,应用配置,ssh策略,账号密码策略等等,从多方位去降低,减缓攻击的过程)

第七章 网络安全

本章主要讲述了企业安全中的网络安全部分

  • HIDS(主机入侵检测系统)依旧有用 ,HIPS多了一个P多功能,比较典型的场景是在出口处部署NIDS,做统一流量监控,或者在此处部署NIPS。

  • 什么时候D什么时候P要选择好,控制好自己可消耗的时延或者说可接受的时延。做出对应的检测和防护。无论是D还是P,二存一是必须的。

  • WAF架构部署上有不同的方式,机房/CNAME/module部署/网络层部署/主机上等方式,混搭着来,视情况而定,同时针对规则的反馈补充应该做到行之有效。

  • 如何建设T级的DDOS防御能力,从运营商的近源清洗到CDN的选择或自建。HTTP-DNS也不失为一种好的选择,但是各种措施之间即便都有部署,也要确定对应的调用接口的可用性。否则就会出现空有能力而无法使用的场景。(主要还是依靠运营商)

    1.网络层攻击:Syn-flood ACK-flood UDP-flood ICMP-flood

    2.应用层攻击 :CC Dns-flood 慢速连接攻击 DOS攻击

    3.攻击方式 : 混合型攻击 反射型攻击 流量放大型攻击 脉冲型攻击 链路泛洪型攻击

  • 多层防御结构

TODO:

  • 每种ddos攻击后常见的实现选项。例如反射型背后常见的易被放大的协议

第八章 入侵感知体系

本章讲述了入侵检测相关的一些架构和技术细节,包含但不限于HIDS和NIDS,RASP,数据库审计等。也就是说以上都被算作了入侵检测体系里的产品。

  • 企业应该根据业务特性适应性的调整入侵检测的重点,不应该针对全场景的覆盖。

  • 文本检测webshell 观测同目录其他文件inode是个比较有意思的想法

  • 流量检测webshell

  • 发现攻击从web层到cgi层到系统层的调用趋势,即关注上下文事件

  • 自研HIDS的架构设计中的一些细节性问题是之前没有考虑到的。同时根源设计的最初需要考虑适应企业自身的运维体系。从行业法规需求,基础安全需求,企业自身特殊安全风险需求以及网络环境自适应等。

  • 控制管理的功能有时候需要具有自杀功能。一些功能要偃旗息鼓,从而降低利用率。

  • 之前做的webshell是针对文本的检测,从业务特性中针对业务请求建立基线行为,以该方式针对特定业务检测。

  • 架构部署上需要考虑到企业的服务规模。设备的所处位置是否能够起到作用。

  • 基于Java RASP的攻击检测:基于高危行为组合的检测模型 基于调用栈的检测模型

  • AST解析依旧是个不错的方式

  • 入侵检测数据分析平台

TODO:

  • 如何能够准确的发现一个函数变动带来的整个系统中其他附属影响的变动?比如sudo的提权会导致env字段变化之类的。怎么样制造这样的实验环境并发现对应的问题?

  • 监控文件的手法,除inotify之外呢?

  • 进程信息获取的技术方案手法?

    周期性遍历/proc 用户态Hook Libc函数 利用LSM模块接口 内核态Hook Libc函数

  • 哪些父进程权限较低但子进程权限较高的正常场景?

  • 怎么样针对蠕虫和僵尸网络建立特定的检测策略?并具有一定的抑制能力。

第九章 漏洞扫描

本章主要讲述了漏洞扫描相关的知识,当然依旧提到了大数据在其中的应用。

  • 漏洞扫描、入侵感知和应急响应是技术维度日常工作中最重要的3个部分。

  • 先做好端口扫描和高危端口的监控, ACL扫描每天都要做

  • 弱口令扫描也不可大意,需要注意培训安全意识以及是否应用了默认的和简单的口令

  • 在系统和应用的扫描上不一定完全依赖于网络扫描器

  • 自动化Web安全检测平台

  • 漏扫也可以用来补充资产库,在vpn服务器中会设置一个透明代理

  • 被动式扫描器可以对处于灰色地带的资产进行防护。

  • 减少漏扫的网络开销是件很重要的事情,同时也应该减少扫描任务。都是跟着轻重缓急来的。

  • 在实践中,需要从以下几方面进行优化:
    1)不做全网的漏洞扫描,先做端口扫描,

    2)做好高危端口监控

    3)在系统和应用扫描上,不完全依赖于网络扫描器,可同时借助于本机agent扫描

第十章 移动应用安全

  • 从整体业务角度来看,业务逻辑为皮,移动应用端的展示为毛。如何避免移动客户端做不应承担的判断,如何将应用安全和业务服务端逻辑进行划定是首先需要明确的。
  • 以支付宝为例,限定数额以下的付款甚至不需要认证。这背后有很多需要背景数据收集,从第一次正常登录时设备本身的信息,包括用户日常操作行为收集的大数据等。在发现异常时,就会触发完整的认证过程了。当然在攻击者完全控制手机的情况,如果所有认证信息的要素都可以通过手机获取到,例如保存的认证信息,动态认证短信等,更多能够做到的也只有提高攻击的成本,而不能完全避免认证信息的盗用。

第十一章 代码审计

本章写的就更水了,只是介绍了一下开源的代码神奇工具。Coverity. 参考链接: https://scan.coverity.com

第十二章 办公网络安全

本章主要讲述办公网相关

  • 安全网关中行为审计可以对员工上网行为做审计,可以抓内鬼和防止内部的某些安全问题。
  • 针对特定的办公人员制定不停的安全策略,可以以此避免不同用户群的抵抗。研发给什么策略,运营给什么策略,市场给什么策略。
  • 关注不同受众的团体特点,适应性的进行调整策略。比如说研发爱自由,运营不懂计算机。针对这些不同特点的群众,放不同的安全策略进行管控。
  • 办公网需要明确自己防控的重点
  • beyondcorp不是指真的没有边界,Google也只是针对办公网做了这个。其背后依赖的是完整的鉴权体系,以及确切可控的终端。
  • APT既不能两手一摊不管,也不能钻牛角尖。治理APT一定要考虑ROI,或许部署蜜罐是个不错的选择。
  • 不差钱就照着Gartner买买买
  • 文化管理,终端管理(杀软,防泄密,远程访问),安全网关,研发管理。凑在一起
  • 确实很多方案都是防君子不防小人。小人总有办法绕过。一定要技术管理两半搞,都要硬。

第十三章 安全管理体系

本章讲述的讲到了安全管理体系,项目管理方面

  • 安全管理体系图

  • 大型安全部门组织结构图示例

  • 安全的客户是什么? 内部和外部两部分,一部分是对安全依赖的兄弟部门,另一部分外部看是2c还是2b,总之都是用户,也都是我们的客户。

  • KPI的设定参考IT平衡计分卡,安全团队的kpi衡量是 覆盖率,覆盖深度,检出率,TCO/ROI,技术维度指标。一句话就是拿数据来说话,别用空话衡量kpi。

  • 内部评价指标和外部评价指标都要具备

    内部评价指标:覆盖率,覆盖深度(比如sql注入的检测,从代码扫描到waf防御,到db代理和db审计),检出率,主动止损率,TCO/ROI, 技术维度指标(在技术上的进步)

外部评价指标: 攻防能力,视野和方法论,工程化能力,对业务的影响力

  • 资产管理一定要做好,系统关联影响也是其中的一部分。
  • 争取事情处于可控的最小集合,能够事前事中事后,均有布放。
  • 职责矩阵要实现定义好。 RACI, Responsible, Accountable,Consulted, Informed。联系人,执行者,指挥人。要细看下这个职责矩阵。表13-3和图13-5
  • 事前做好预案,临阵有人指挥,事情有条不紊,损失可最小化。
  • SRC要生态化,这个不仅是src,内部产品也要从平台化过渡到生态化。从全公司到全集团到全行业。

第十四章 隐私保护

本章隐私保护相关

  • 访问控制(Identity&Access Management,IAM)示意图:

    谁,对哪些资源,拥有,哪些权限,有效期是多长。

  • 对于在线应用的后台数据存储而言,敏感数据(例如用户库、口令、密保、支付等)应考虑分表分库存储,应尽量减少一个上层应用出现漏洞时的影响

TODO

  • 文中提到的一些数据加密不了解,需要自己详细了解。
  • 文件/磁盘加密

第十五章 业务安全与风控

  • 永远的情报一知己知彼,百战不殆。

  • 方法比技术更重要——上兵伐谋,最下攻城。技术的对抗是无止尽的,并且会不断地消耗内部的研发资源和IDC资源,改变战场规则可能起到一招退敌的效果。自己退一步可以让对方无计可施

  • 数据比算法更重要——大数据的典型特征,算法可以不高大上,但是没有数据或数据太少,风控这件事也许你玩不起来。

  • 纵深防御——纵深、多维度、降维防御在风控场景仍然适用,使用漏斗模型,由机器规则处理最原始的数据,逐步筛选过滤,由人工审核做最后一道防线。

  • 账号安全

    1.注册,

    2.登录环节的问题包括:撞库、暴力破解、盗号登录、非常用设备登录、黑产小号和僵尸号登录等。

    3.账号风控架构示意图

  • 大型平台一般有很多应用,凭借一个登录token直接无障碍登录所有子应用在安全上并不是一个好的设计,一旦被XSS盗取token就相当于全线溃防。所以在功能和应用入口比较多的平台,会对业务划权重,分类分级,涉及个人认证信息、个人隐私、支付类的一般属于高级Web安全域,信息发布类的归入一般Web域

第十六章 大规模纵深防御体系设计与实现

纵深防御的视角,提出了数据流视角,服务器视角,idc视角,逻辑攻防视角等方便考虑。 针对不同的IDC规模,业务类型做出适应性的定制。

  • 常见入侵感知数据源采集的维度

  • 逻辑攻防视角

第十七章 分阶段的安全体系建设

基础的事情做了就能防御大部分的攻击。在防御初期投入80%的精力去做这些事情。

当具有一定基础之后,进入系统性的建设。各种产品维持出一个解决方案体系。可能有精力投入到自研之中。

最后全方位的开始关注SDL的事情。等等。都做好了可能才完成60-80分。

其后需要清理灰色地带,资产的遗漏,系统的遗漏,变革的bug,新增的ACL覆盖,弱口令等等。

其次就是简历完善的应急响应能力,具有多方位的止血能力。从组织到流程到技术实施都能找到对应的负责人依照一定的流程采用相应的技术完成对应的操作。快字当先,一切都要快。发现快,响应快,完成快。 持续性的运营占用整个生命周期中80%以上的精力。

在整个安全团队存在的过程中持续运营起到了保障作用。当然运营也不仅仅是纯粹运营,也需要考虑技术深度的上的进步。单点的入侵检测到大规模的入侵检测,降低海量的告警(一大坨谁看呢)等等。完成风险的闭环才能完成可持续化的运营。


转载请注明来源,欢迎对文章中的引用来源进行考证,欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论,也可以邮件至 951207194@qq.com

文章标题:《互联网企业安全高级指南》读书笔记

文章字数:5,264

本文作者:Mang0

发布时间:2020-03-04, 18:17:30

最后更新:2020-03-04, 18:32:00

原始链接:http://mang0.me/archis/a7cdea15/

版权声明: "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。

目录
×

喜欢就点赞,疼爱就打赏