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

| 分类 安全工程师  | 标签 反入侵  知识回顾 

整体上来讲,这本书对我这个菜鸟扩充了视野,同时在不同的方面又引出了不少值得深思的问题。例如哪些父进程权限较低但是子进程较高的场景等。可以很明显的从书中感受到,作者不仅在安全架构上的视野和思考面,同时针对技术细节依旧有着较深的功底。在国内的安全书中不可多得。对于我自身而言,也是收获颇丰。让我在安全架构和入侵检测体系有了一些新的认识。同时整本书也不止一次的指出了当前情况下的解决方案以及安全公司推出产品有种新瓶装旧酒的感觉。并指出了新兴的一些技术所带来的变化并不能完全覆盖住现在的需求。这些观点可能有人知,有人不知,而且知道的那一部分中大多是心照不宣,不会说出来。作者能够抛出耿直的观点,还是蛮令人佩服的。我一向敬佩敢于说真话的人。以及作者在文中也指出了安全行业的现状,具体不必多言。但是不知为何,在本书的后几章有些拼凑之感,质量有所下降。尤其是10,15章,从一个读者的角度来看,是失败的。既然是高级指南,就不能玩些滥竽充数的操作。

以下记录了我在阅读时的一些思考。

第一章

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

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

第二章:

  • keep peace and love ,针对那些乱七八糟的jd放缓心态,讨论后才知道问题所在。
  • 极客型,创业型,中小型,大型等企业的安全水平必然不一样,而且即便在一个企业中,他的每一阶段的安全建设也是不一样的。
  • 事前基线做好,新的服务器要确认安全,旧的逐步建立入侵检测系统。基础安全(10%的精力)做完之后投入一定的精力在业务安全,输出新的成果。领域要关注到反爬,账号等等,不同的行业关注的不一。其次要关注工具的自动化,和动作的自动化。

第三章

  • 管理的最初驱动是事件驱动和管理驱动。
  • 针对以WEB产品为主的安全建设,一是事后修复的成本较低,二是部分的产品生命周期较短。
  • 看来STRIDE是一个常用的方法,还好我读过《威胁建模》这本书。我记得谁之前说过,研究一个东西就把这个领域下的书籍都买回来读一读。

TODO:

  • 需要了解的规范 ITIL(BS15000/ISO20000)
  • 需要了解的规范 ISO27001

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

第四章

  • OWASP的崛起在于,防火墙如同内衣一般起到了端口收拢和netfliter的作用。当一切收口至80,那么针对HTTP应用产生的攻击自然而然成为了防御的重点。其次也可以将WAF看做一个为七层流量清洗的NIDS设备。
  • 当一个复杂生产网络的成千上万服务器分布在世界各地的IDC,资产附属也归不同的SA时。作为安全人员其实应该事先考虑到:逻辑架构与部署架构的差异点,以及当前架构下的资产由什么样的组织架构所属。

第五章

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

  • 纵深防御的前提应该是以业务层次划分域后,针对相同主机组具有同一安全级别的继续划分新的安全域。同时在数据库序列(可能业务无关)的层次划分新的安全域。
  • 在设计通过特定途径访问生产网机器的时候,在考虑网络划分的前提下仍需要考虑用户角色需要使用到的一些特殊工具。比如devops的可能拥有自动化部署工具,针对这些工具的访问方式做好怎么样的限制。
  • 在威胁层层防护的过程,可以通过考虑同一风险项的不同层位置,以及不同层的不同风险。
  • 对抗不仅仅在技术上,运营方面,情报获取方面等等
  • 架构方案至少A,B,C三个以上,这样才能够提供有效的灾备。
  • 安全域层面隔离基本上是业务上的,数据链路层隔离基本是网络上的,针对端口过滤即是网络层也是主机层的,属于更加具象化的东西。

注意点:

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

第六章

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

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

TODO:

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

第七章

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

  • 什么时候D什么时候P要选择好,控制好自己可消耗的时延或者说可接受的时延。做出对应的检测和防护。无论是D还是P,二存一是必须的。
  • WAF架构部署上有不同的方式,机房/CNAME/主机上等方式,混搭着来,视情况而定,同时针对规则的反馈补充应该做到行之有效。
  • 如何建设T级的DDOS防御能力,从运营商的近源清洗到CDN的选择或自建。HTTP-DNS也不失为一种好的选择,但是各种措施之间即便都有部署,也要确定对应的调用接口的可用性。否则就会出现空有能力而无法使用的场景。(主要还是依靠运营商)

TODO:

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

第八章

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

  • 企业应该根据业务特性适应性的调整入侵检测的重点,不应该针对全场景的覆盖。
  • 发现攻击从web层到cgi层到系统层的调用趋势,即关注上下文事件
  • 自研HIDS的架构设计中的一些细节性问题是之前没有考虑到的。同时根源设计的最初需要考虑适应企业自身的运维体系。从行业法规需求,基础安全需求,企业自身特殊安全风险需求以及网络环境自适应等。
  • 控制管理的功能有时候需要具有自杀功能。一些功能要偃旗息鼓,从而降低利用率。
  • 之前做的webshell是针对文本的检测,从业务特性中针对业务请求建立基线行为,以该方式针对特定业务检测。
  • 架构部署上需要考虑到企业的服务规模。设备的所处位置是否能够起到作用。
  • AST解析依旧是个不错的方式

TODO:

  • 如何能够准确的发现一个函数变动带来的整个系统中其他附属影响的变动?比如sudo的提权会导致env字段变化之类的。怎么样制造这样的实验环境并发现对应的问题?
  • 监控文件的手法,除inotify之外呢?
  • 进程信息获取的技术方案手法?

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

  • 哪些父进程权限较低但子进程权限较高的正常场景?
  • 怎么样针对蠕虫和僵尸网络建立特定的检测策略?并具有一定的抑制能力。

第八章

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

  • 先做好端口扫描和高危端口的监控, ACL扫描每天都要做
  • 在系统和应用的扫描上不一定完全依赖于网络扫描器
  • 漏扫也可以用来补充资产库
  • 减少漏扫的网络开销是件很重要的事情,同时也应该减少扫描任务。都是跟着轻重缓急来的。

第九章

由于对移动安全不是很了解,感想不多。似乎写的也是马马虎虎

第十章

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

第十一章

本章主要讲述办公网相关

  • 针对特定的办公人员制定不停的安全策略,可以以此避免不同用户群的抵抗。研发给什么策略,运营给什么策略,市场给什么策略。

第十二章

本章讲述的办公网安全,总觉得后面章节的质量下降严重

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

第十三章

本章终于开始讲到了安全管理体系。

  • 图13-1 信息安全全集
  • 安全的客户是什么? 内部和外部两部分,一部分是对安全依赖的兄弟部门,另一部分外部看是2c还是2b,总之都是用户,也都是我们的客户。
  • KPI的设定参考IT平衡计分卡
  • 内部评价指标和外部评价指标都要具备

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

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

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

TODO:

  • ISMS需要阅读
  • BCM业务持续性管理
  • DRP
  • 业务营销分析
  • 全生命周期可用性管理
  • 安全影响隔离

第十四章

本章隐私保护相关

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

TODO

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

第十五章

第十六章

纵深防御的视角,提出了数据流视角,服务器视角,idc视角,逻辑攻防视角等方便考虑。 针对不同的IDC规模,业务类型做出适应性的定制。 但是怎么把这些话拆成几个段落写呢?着实不容易。

第十七章

基础的事情做了就能防御大部分的攻击。在防御初期投入80%的精力去做这些事情。当具有一定基础之后,进入系统性的建设。各种产品维持出一个解决方案体系。可能有精力投入到自研之中。最后全方位的开始关注SDL的事情。等等。都做好了可能才完成60-80分,其后需要清理灰色地带,资产的遗漏,系统的遗漏,变革的bug,新增的ACL覆盖,弱口令等等。 其次就是简历完善的应急响应能力,具有多方位的止血能力。从组织到流程到技术实施都能找到对应的负责人依照一定的流程采用相应的技术完成对应的操作。快字当先,一切都要快。发现快,响应快,完成快。 持续性的运营占用整个生命周期中80%以上的精力。在整个安全团队存在的过程中持续运营起到了保障作用。当然运营也不仅仅是纯粹运营,也需要考虑技术深度的上的进步。单点的入侵检测到大规模的入侵检测,降低海量的告警(一大坨谁看呢)等等。完成风险的闭环才能完成可持续化的运营。


上一篇     下一篇