1 业务安全的责任主体与职责划分

云计算行业共同认可并实践“安全责任共担模型”，在全链路云服务中，云运营商只负责维护和监控基础设施的安全，而基于云计算建立的业务的安全应由客户自己负责。“安全责任共担模型”给了客户一个提醒，安全不能完全依赖云服务商，还要不断提升自身在应用层面的安全保障措施，毕竟应用层的管理权限完全在用户自己手中。 在云服务的内部，业务团队与安全团队之间也存在类似的责任共担模型。安全团队基于自身的专业能力提供相关的方法、工具等能力支持，但最终需要产品团队完成落地实践。没有良好的执行，所有的策略都将停留在纸面。

1.1 安全责任主体

业务团队是云计算信息安全责任的主体和第一安全责任人。从现代的信息安全治理方法论的角度看，信息安全和整个软件开发生命周期紧密相关，它不仅仅是一种能力，更是一种理念和方法。单独依靠某一个孤立的系统无法解决一项业务或一个组织整体的安全问题，因为安全问题可能出现在生产环节的方方面面。而就如云计算服务运营商于客户的关系一样，业务团队团队拥有对产品自身的管理权，因此解决风险和实现安全价值除了安全团队在与明处的入侵和攻击行为对抗以外，更多的是依赖业务团队团队将责任扎实落实。这种关系好比病人与医生、或者驾驶员与交警。无论医生和交警有多么强大的能力与特权，但是否认真配合治疗，是否遵守交通规则，是病人或驾驶员自身无法让别人替代的。

然而，这并不意味着安全团队不会承担任何责任。安全团队需要向对外提供的产品能力和服务负责，这既包括云计算安全防护基础设置的产品（包含运行于其上的各类规则）、各种内部安全工具和相关文档等有形的内容，也包括安全团队参与的产品架构和功能设计的安全属性和安全元素（如产品的身份认证、网络访问控制、加密与数据保护等）、各种内部DevOps工具平台的安全管控能力的设计、各种安全规范和最佳实践等无形的能力输出。安全团队在必要的场合需要获得某些特权，以确保安全策略在全局范围严谨地落地，例如配置全局统一的网络访问控制策略，或者在产品遭到入侵后登录到主机进行调查溯源，这些行为都需要很好的管理权限，安全团队同样也为此承担责任。总的来说，安全团队的职责有时处在一种略微妙的状态下，安全团队必须同时承担教练员和守门员的角色，这其中的尺度取决于组织的管理者对安全团队的定位。但无论如何，安全团队需要责权对等。

1.2 安全责任的识别与划分

业务团队与安全团队的责任划分可以用一个原则概括，即：谁管理谁负责，这也符合责权对等的管理理念。安全责任的识别有很多角度，根据工作程序，我们参考微软的的SDL安全开发生命周期模型设计安全责任识别的框架。

根据SDL安全开发生命周期流程，软件的安全实施分为1.训练 2.需求 3.设计 4.执行 5.验证 6.发布 7.响应 共七个阶段。每个阶段的安全责任划分对应到业务和安全两个部门的情况如下表（少数情况下需要双方共同负责）。

SDL阶段	产品团队	安全团队	双方共同
训练	参加安全编码和安全规范的学习并通过考核。	设计安全编码规约和安全规范，对产品开发人员进行培训和考核。
需求	对产品的使用场景进行抽象，整理出产品的功能需求列表，并明确需要使用的用户数据和数据内容的类型，整理出产品的数据需求。	根据产品的功能需求分析可能存在的交互风险，根据数据需求分析可能存在的数据泄露和隐私保护风险点，并依据这些风险点整理产品的安全需求列表。
设计	依据相关的设计规约和最佳实践，按照产品需求（包括功能需求）完成产品的功能、交互、架构方案设计。	根据产品的设计方案，评估其中的风险点，并提出安全方案（或改进建议）。
执行	完成产品的编码开发工作。	提供安全编码的最佳实践和自助工具，协助研发完成代码安全检查。	代码评阅和审计。
验证	修复验证过程中发现的产品安全缺陷。	对照产品的安全需求和安全方案（或改进建议）中的所有安全要求对产品进行黑白盒验证，同时根据安全工程师的经验对产品的编码实现和其他非常规使用场景的风险点进行挖掘。	常规验证过程由安全团队完成，个别场景需要产品研发配合共同完成。
发布	发起产品的发布流程，并完成安全反馈意见的整改和确认。	制定应急响应计划，并对产品最终状态进行安全检测和确认，完成审批流程。
响应	协助安全工程师进行应急响应阶段的必要工作，执行业务连续性计划保障产品运行的稳定性。	对安全实践执行应急响应。

2 SDL落地实践

安全团队从SDL视角提供配套工具和能力，同时从攻防视角提供安全防护基础设施及其运营能力（在安全团队内部会有不同分工，相关说明将在后文中标注）。本章节介绍安全团队提供的产品和服务（可能重复的内容仅选择相关性较高的标题下介绍）。

2.1 架构安全

能力项	内容说明
产品架构评审 & 威胁建模	以安全左移视角，在设计初期定义产品安全架构，零成本消除架构层面潜在安全风险。
安全架构技术方案设计	针对产品自身的内部设计提出安全需求；结合产品应用场景，面向用户设计产品安全能力和实现方法。
定制化安全架构需求，设计解决方案	根据业务诉求，依据场景定制产品安全架构，包括网络架构、软件架构、数据交互模型等。

2.2 风险识别与治理

能力项	内容说明
漏洞运营平台	提供漏洞从通知到修复的管理链路
产品配置基线扫描平台	检查某个产品依赖的内外产品、组件的配置是否满足安全规范
黑盒漏洞扫描平台	检查产品系统、网络、应用、中间件等不同层面安全漏洞
白盒扫描平台	自动化代码审计工具
供应链扫描平台	扫描产品依赖的二三方组件的已知安全风险
敏感信息扫描平台	自动化代码敏感信息扫描，发现AK、密码或其他不宜在代码中出现的敏感信息
SRC应急响应中心	收集外部报告的安全漏洞，从真实的对抗角度提示关键风险
SDL流程管理闭环	在整个SDL链路中，将一个个具体问题抽象成事件，在统一的管理平台解决事件的全生命周期管理，例如流程的跟踪、事务审批、工单下发等。
核心管控系统安全监测	针对核心管控系统进行渗透测试，发现自动化工具难以覆盖的真实安全风险。
外部漏洞收集与响应	专项预算支产品外部漏洞收集，对有价值的漏洞进行复现，设计修复方案，并跟踪修复过程。

2.3 产品安全设计与最佳实践

能力项	内容说明
产品安全能力设计方案	从用户视角出发，提供产品应用场景下的安全功能和特性，提升安全维度的产品竞争力，满足用户侧安全功能需求，提升用户使用产品的安全感。
产品安全最佳实践	基于产品安全功能和特性，提供产品安全最佳实践文档。
产品安全测评支持	针对国内外主流咨询公司的产品测评，支持产品进行安全领域专业测评。

2.4 安全基础设施

能力项	内容说明
SOC运营平台	产品发布审核管理平台
资产管理平台	资产管理平台，包括域名、IP、账号等
云WAF	在产品边界Web层抵御已知和未知风险
云防火墙	在产品边界网络层抵御已知和未知风险
SIEM	事件管理
安骑士	主机层面入侵监测工具
灰盒扫描平台	代码层运行态入侵监测工具

2.5 事件响应

能力项	内容说明
入侵检测	基于安全威胁检测能力，提供面向产品的威胁告警。
应急响应	发现入侵事件后，快速止血响应
黑灰产情报	监控黑灰产情报，打击犯罪团伙。
内容安全&风控	识别涉黄涉政等内容安全风险、账号安全管控
漏洞应急响应服务	处理内外发现的漏洞和应急事件，管理漏洞生命周期，确保漏洞如期修复。

2.6 攻防演练

能力项	内容说明
内部攻防演练	以攻击者视角模拟真实入侵行为，挖掘产品和产线 内部应用的安全弱点，并在演练后提供整改建议。
国家、区域、行业攻防演练支持	面对护网等重要场合，开启重保模式，全方位护航产品安全。护网相关事项全包，包括护网前安全建设和加固、护网过程的值班和响应、护网后的沙盘推演。

3 安全管理

业务团队团队是落实信息安全责任的主体，安全团队从安全管理的角度出发，设计安全管理流程，提供安全管理工具，与业务团队共同将安全责任落到实处。

3.1 安全规范

能力项	内容说明
代码编码安全开发指引	代码编码的安全规约，帮助研发人员减少在编码阶段引入安全风险
安全规范与制度红线	制定安全规范要求，定义违规行为和处罚原则，降低内部操作风险。
培训与考核	安全红线、安全规范和安全意识培训和考试。

3.2 数据安全

能力项	内容说明
数据链路监控	监控内部员工、外包的数据访问异常情况。
数据泄漏应急排查	发生数据泄漏事件时，协同进行排查，快速定位泄漏源。

3.3 合规应答

能力项	内容说明
应审与应答	针对外部监管机构的合规要求，提供合规证明材料，对需要整改的项目制定整改方案，支持业务方完成整改落地。

4 小结

在建立安全运营体系的过程中，业务团队团队和安全团队必须相互依赖相互支持，而业务方必须要经历的重大思想转变，就是业务是安全的第一责任人。许多公司的管理团队要求安全团队为安全的最终效果兜底，实际上这样的制度设计很不科学。俗话说羊毛出在羊身上，那拔羊毛也要去羊身上拔，剃毛推子不长毛。本文从SDL的角度出发，借助“责任共担模型”的思路，尝试建立一个安全运营责任的全景图，并明确业务团队与安全团队的角色。从职责角度看，建立清晰的责任边界并定义共建区域，可以帮助双方理解各种职责和需要负责的结果。很多企业团队在建立这样的职责框架的过程中产生过不少摩擦、争执，也属于业务成长期的艰难探索，希望这篇文章介绍的思路能够帮助一些企业建立合理的责任和分工体系。

Reference

——————————

https://zhuanlan.zhihu.com/p/29822421 周璞 如何实现“默认安全”？这是云服务商的下一道考题

»

第七部分 钓鱼防护

1 概述（what）

1.1 含义

经历了多年的护网攻防演练，在攻击队与防守方多次角逐对抗之下，常规的攻击点已经不再具有太多可被利用的漏洞。而人一直是系统当中最薄弱的环节，因此攻击队将目光转移到组织的成员身上。网络钓鱼堪称网络攻击中最大的威胁之一，攻击者往往伪装成可信的组织和个人诱骗受害者下载恶意程序、输入敏感信息以达到控制人员终端设备的目的。攻击者可以利用获得权限的设备及账户访问内部应用系统，而内部应用系统通常的防护水平低于互联网应用，因此攻击队更容易得手。而在现实世界中，恶意的攻击者可以通过网络钓鱼盗取金钱、诈骗等，笔者在十年前见过一起配合电信诈骗手段盗取被害人20万元的案件。

1.2 原理

钓鱼攻击一般通过社交媒介接触并诱骗被害人，要求被害人接受可执行应用程序并启动，或点击包含恶意功能的网络链接，输入敏感身份信息、下载恶意程序等。常见的钓鱼手段有即时消息钓鱼、邮件钓鱼、短信或电话钓鱼，以及物理设备钓鱼。

案例1.伪装成招聘人员

近期，有人在脉脉、微信上冒充HR以大厂高薪诱惑进行招聘，发送含有病毒的JD文件，从而实现对特定人员钓鱼，对公司网络进行攻击。

案例2：伪装成公司或内部同事

冒充公司名义发送邮件，且正文中包含外部链接，诱导输入密码、账号等敏感信息或伪装成内部同事账号添加钉钉好友，发送钓鱼链接和钓鱼简历压缩包（解压后为木马）、文件等。下图是一次护网项目的真实案例，攻击队通过Nday漏洞拿掉客户coremail邮件系统的权限，然后伪造客户单位领导身份想全员发送钓鱼邮件。同图片内容可以看出攻击队十分狡猾，利用护网期间的事件背景和人们的警惕心理，加上领导的特殊身份引导人们运行恶意程序。

案例3：利用物理设备扩散恶意程序

某著名富二代创立的视频平台授权的渗透测试，测试人员编写windows系统下的病毒，利用U盘传播。攻击者将U盘放置在被测试公司的入口，捡到U盘的人出于好奇获得打开U盘，并点击木马程序，木马运行后攻击者从远程控制了这台电脑，而中毒的当事人还不知情。

1.3 原则

防范钓鱼事件，在宏观上应该把握好以下几个方向：

1. 做好组织范围内的安全意识宣贯工作，要有培训和考核，确保知识要点被所有组织成员掌握。
2. 做好数字媒体的安全检测工作，例如邮件附件、在线文档。对存在风险但必须打开的文件，应当安排专门的沙箱环境。
3. 对接入网络的硬件的设备身份进行验证，否则禁止接入。

2 方案（how）

信息安全意识培训：

1. 在组织范围内宣贯，在特殊时期、敏感时期对不信任的信息来源保持高度警惕，尤其对于充满诱惑性的措辞和内容的信息，应当保持警觉。注意任何外部人员可使用的沟通媒介，例如邮件、社交软件、手机短信、办公IM软件等。
2. 在组织范围内宣贯，对任何需要输入个人身份信息或与登录认证相关的敏感信息的网页、文件，要验证其真伪，谨慎的输入。要警惕在陌生的环境输入账号、密码、短信验证码。尤其要警惕来自邮件、办公IM软件的需要输入敏感信息的网站链接。
3. 对上述内容组织专门的培训和考核，并对考核结果建立一定的奖惩措施。

安全风险检测：

1. 对可疑的数字文档本身及其传播媒介进行安全检查，例如通过杀毒软件对文件进行扫描，通过恶意邮件扫描软件发现并拦截可疑的邮件。
2. 对接入办公网、生产网的任何设备的安全性进行检查和验证，防止带有病毒和恶意代码的设备接入网络。
3. 对组织成员的工作终端设备进行定期的病毒查杀、补丁更新，保持系统版本和病毒库保持在最新的状态。

3 需要注意的一些问题

钓鱼已经成为护网攻防演练中非常高频使用的攻击手法，并且通过使用免杀手段，让防守方检测起来更有难度。目前比较好的防范方案是零信任方案，但零信任方案部署成本较高，组织成员也需要花时间去适应。除此之外，对于这种攻击方式少有显著的防范手段，最简单有效的办法还是做好安全意识培训，并且管理好内部成员的权限，即便当攻击者通过钓鱼成功获得办公网的访问权限，也不一定具备内部关键业务系统的使用权限，使得攻击成功的概率降低。

4 小节

写到这里，这个系列的文章正式告一段落。从第一章的网络隔离开端，到最后一章钓鱼防护结尾，对于没有专业安全从业人员而言，这个系列文章提到的各种防护手段是可行的相对全面的一套防护方案。笔者有信心，如果能将这套方案扎实落地，必将为信息系统的安全打下坚实的基础，也有信心在护网这种高强度的攻防演练实践中取得不错的成绩。鉴于个人的知识和经验所限，文档应当存在许多错误疏漏，也有许多方案的考虑和设计带有主观的倾向性。希望看到这个系列文章的读者，如果有任何想法和意见都欢迎与我交流。我的git地址是这里，大家可以在wangzf0225.github.io这个分支下提issue留言，也可以通过邮箱 wangzf0225@gmail.com 发邮件和我讨论。

»

第六部分 攻击诱捕

1 概述（what）

1.1 含义

写在前面:按照最开始的想法，这一章会写关于特权访问的问题。直到写到这里，发现特权管理的主要内容其实已经在账号扫雷这一章节中包含，只不过账号扫雷针对所有的账号对象，特权访问只是其中的操作系统、数据库、管控系统等这些特权系统的用户管理。特权访问是近年来新兴的一个概念，从信息安全体系上讲概念的内涵是很丰富的，只不过在这里我们只关心其中的一小部分，如果读者感兴趣可以搜索privileged access关键字了解其内容。

1.2 原理

攻击诱捕即以蜜罐为基础的诱骗和溯源技术，近年来商业化产品开始使用“攻击诱捕”这一词汇作为商业包装，而这个提法也比较贴切，因此我们在这里沿用。攻击诱捕通过制造伪装的应用系统迷惑和诱骗攻击者，并通过伪造的业务流程引导攻击者留下与个人身份直接或间接相关的信息，从而达到识别攻击意图、检测攻击行为以及溯源攻击者的目的。此外，攻击诱捕系统还可以引诱攻击者进行文件交互，通过在在攻击者主机上安装具有木马特性的程序，对攻击者进行反制。

1.3 原则

攻击诱捕是积极防御型的方案，因此其部署的优先级要低于前文中提到的集中防御方案。但攻击诱捕有一些特点不容忽视，首先是其检测效率高，由于是专门为攻击者设下的陷阱，因此正常情况下并不应有任何访问请求，并且由于访问量小，可以进行人工分析。其次攻击诱捕系统可以用来收集攻击者数据，用来追踪和定位攻击者个人。为了让攻击者能够被蜜罐吸引，通常需要注意以下几点：

1. 高度伪装的应用系统。为了能够骗过攻击者，蜜罐要看起来非常接近真实的业务系统，这要求蜜罐在基本功能、视觉交互、架构设计和模拟数据方面都尽可能做到接近真实的状态。
2. 可用但无风险的漏洞。如果攻击者完全没有机会突破，那么蜜罐可能也会被攻击者放弃。蜜罐应该留有一些漏洞，可以让攻击者尝试去突破。这些漏洞应该尽可能多的让攻击者暴露自己，并且让攻击者能够在进行一些努力后获得一些回馈，例如让攻击者以为漏洞利用成功，或者返回一些伪造的数据。
3. 密切监控蜜罐访问日志。在内网部署的蜜罐由于正常情况下不应该被正常的用户访问到，因此一旦有用户访问了蜜罐，极大可能存在风险。应该在蜜罐被任何形式访问的时候密切关注访问源的动作，并排查系统中是否有同一来源的其他异常行为。在公网部署的蜜罐有时会被互联网的扫描器无差别的扫描，访问日志可能较多，平时分析的意义不大，但在护网期间也是重要的信息来源。
4. 蜜罐系统自身的安全性。由于蜜罐本身是具有一定漏洞的，因此很可能被攻击者利用来作为内网渗透的跳板，给正常的信息系统带来一定风险。因此，蜜罐应该部署在隔离的环境中，但隔离的效果需要伪装，不然容易被攻击者发现。隔离可以从网络(ACL)、主机(虚拟机或容器)、进程（沙箱）层面进行设置。运行蜜罐的主机、数据库、应用框架、中间件等组件也应当具备相当的健壮性，否则别攻击者利用后蜜罐反而成了入侵的工具。

2 目的（why）

对于普通用户而言，攻击诱捕最主要的作用还是发现入侵行为，降低检测的成本以及提高效率。对于能力较强的用户，蜜罐是很好的溯源信息收集的入口。

3 方案（how）

1. 产品选型

Awesome Honeypots是一个开源蜜罐合集，囊括了从数据库蜜罐、web蜜罐等等众多蜜罐类型。开源蜜罐适合有一定系统研发能力的组织，但开源蜜罐存在一定的特征，有概率被攻击者识别到。如果使用小众的开源产品，被识别到的可能性会降低，但可维护性要差一些。对于大多数组织，使用商业化产品是一个较好的解决方案。商业化产品能够提供相对充分的技术支持，而通常产品的稳定性和功能也较开源产品更好。

如果研发能力比较强，也可以尝试自行搭建和开发蜜罐系统，自建蜜罐系统能够有比较好的定制化能力，对于模拟真实业务系统有一定优势。自建蜜罐系统需要注意蜜罐系统自身的安全性，以及日志记录和告警能力。

1. 设计网络架构

对于传统的网络架构，蜜罐比较适合部署在DMZ区或者在DMZ和网络边界之间规划一块单独的区域，此区域最好禁止与真实业务系统互通。这是由于蜜罐本身有一定风险，如果一旦被突破，容易向内网蔓延，因此需要控制其扩散半径。如果是业务系统部署在云上，则可以单独创建一个VPC用来部署蜜罐系统。

1. 日志集成

开源和商业化的蜜罐产品自身已经具备日志收集和告警功能，如果是自建的蜜罐系统，则需要将伪装成业务系统的相关组件的日志全部收集起来并集中管理。通常蜜罐系统的任何访问记录都可以成为告警的素材，而精心设计的漏洞陷阱也可以单独定制告警规则，例如ssh服务的登录口令暴力破解。

4 需要注意的一些问题

首先，蜜罐系统自身的安全性是值得被反复强调的，从运行环境的独立性、基础组件的安全性到蜜罐应用代码自身的健壮性，都应该被足够关注。

其次，对于蜜罐系统的伪装，模拟成业务系统的复杂度比较高，需要投入一定时间打磨，否则容易被攻击者识破。所以内网蜜罐往往被设计成内部系统的伪装者，例如CRM、OA等，这些系统与主要业务有一定差异，因此即便因为伪装的不精致而看上去有一些问题，也相对不容易引起攻击者的怀疑。

»

第五部分

1 概述（what）

1.1 含义

笔者个人理解的基线是一个信息系统的运行环境的初始化定义，广义的基线是指任何一种可认为干预的系统初始状态的变量，例如网络的ACL；狭义的基线是指构成信息系统的各种组成部分的配置参数，安全的系统需要对这些参数进行安全的设置，这些配置参数的选择形成了系统整体的基线安全。

本章中谈到的基线具有以下几个特点：

首先是可复制性，基线存在于不同的组件中，而不同的组件的基线应该是一致的，基线是一种标准，在系统扩容时配置的新环境也默认使用相同的标准基线。

其次是可观测性，由于人为或非人为的原因可改变基线的配置设置，那么基线的标准可能就会被破坏，需要一种发现破坏基线的状态的机制，以便及时纠正。

再次是可管理型，基线除了是一种系统从状态，同时也是一种可被记录和管理的模板，其本身应该被妥善保存，并且应该像代码一样进行版本管理。

最后就是安全性，基线的配置应该具备一定的抗攻击的特性，在有些系统中，这些安全设置尤为重要。

1.2 原理

基线安全应该作为系统默认的初始化策略，在任何状态都被维护和确认，在任何新的元素被引入的时候都应该被校验。说人话的表达就是，系统的基线需要在系统运行的过程中被监控，任何改变系统基线的行为都应该有能力被发现，并且应该被禁止。当系统增加新的硬件或软件，其响应的配置应该满足标准基线的要求。

1.3 原则

基线安全的原则比较简单，就是不要破坏基线。

2 目的（why）

很多时候，基线代表这合规，尽管合规水平不能代表信息系统的真实安全水平，但基线检查仍然是信息安全体系中非常重要的一个环节。在大多数信息系统中常用的组件，在行业中已经形成了比较丰富的安全最佳实践，本章节我们将摘录一些常见的基线配置选项共读者参考。

3 方案（how）

3.1 基线规则

关于基线规则，由于笔者在此做的功课不多，因此在这里只能做一下互联网搬运工。总体而言，基线检查的规则网上流传着很多版本，但核心的检查点都是相同的。通常互联网公司的基线规则不需要特别多，而金融机构因为各个层面的合规要求，他们的基线规则就非常丰富。如果感兴趣，各位读者可以自行搜搜看。这里笔者找到一份大部分以CIS标准为基准的基线规则库，内容涵盖了主机、数据库、中间件等常见软件的基线配置建议：来自AV1080p的安全基线合集。但这个规则库没有包含容器的基线规则，这里又找到一组来自yangrz的docker安全基线整理。此外，信息安全等级保护的要求也是一个不错的基线的标准蓝图，根据系统的重要性和复杂程度选择对应的级别，然后根据内容制定基线标准也是一个简单高效的办法。

最后希望大家能明白，基线规则不是越多越好，通常一个软件配置好最关键的十到二十条足矣。

3.2 基线流程

关于基线建立的流程，在FreeBuf有署名cihack的作者发表了一篇，内容已经介绍的比较清楚，读者可以从这里跳转阅读：安全基线，让合规更直观

这篇文章罗列了建立基线的总体流程，其六个步骤分别是：

1. 建立基线配置管理规划
2. 定制基础操作系统镜像
3. 制定基线配置模板
4. 分发基线配置
5. 基线配置应用
6. 基线配置变更

但考虑到实际运营的效果以及本文的主旨目标，这篇引用的文章在原有的基础之上还应该补充日常基线配置检查的要求。因为对于已经下发的基线标准，有很多场景可以造成实际配置的变化。安全基线不但要讲标准基线下发到系统中，还要把发生变化的基线找出并纠正。这需要在每一个主机上工作的客户端程序（简单的话可以通过脚本加定时任务的方式实现。检查的结果，需要定期被收集，发现有变化的检查点需要定位变化的原因并视情况纠正。如果需要自动化收集信息，那么有能力的单位可以通过自己开发一套服务来实现，如果需要简化快速实现的，也可以将检测结果写入文件，然后通过syslog协议发送至日志服务器进行分析。

4 需要注意的一些问题

基线检查的主要问题，有以下几方面。一是系统中的组件多而复杂，由于缺少早期的规划和日常管理，导致使用的组件没有规律且非常庞杂，因此一方面需要系统管理员尽量收集信息并整理成有序的数据，另一方面需要筛除掉一些使用量较少的组件，以提高工作效率。二是基线配置的变更有时需要重启服务和软件，甚至重启操作系统，也会带来一定风险，因此务必做好正式变更前的测试和验证工作，同时安排好灰度策略。

»

第四部分 漏洞修补

1 概述（what）

1.1 含义

任何系统都存在各种各样的漏洞，广义的漏洞是指任何可以引起系统的功能、数据、配置、设计等被破坏的交互点，这里可以包括一些不安全的配置、业务逻辑等，而这一章节的漏洞，是指应用、组件、基础软件自身的代码漏洞，这些漏洞可以通过修改代码、安装补丁等方式进行修复。

近些年来随着三方应用、开源组件越来越丰富和广泛被使用，一些重大的代码安全漏洞也通过这些组件被引入到组织的信息系统当中。而漏洞利用，仍然是攻击者入侵的最核心得分手段。

1.2 原理

漏洞修补的过程相对简单，主要步骤分为四步：1.发现漏洞 2.修复漏洞 3.验证效果 4.风险规避。

发现漏洞是指，通过已知信息推理系统可能存在的漏洞或通过具有特定特征的交互请求获得目标的响应，以判定系统是否存在漏洞。翻译成人话，一种是白盒，就是通过已知的软件名称、三方库、版本信息等数据，通过在公开漏洞库中检索，已获得系统可能存在的漏洞信息；另一种是黑盒，就是通过扫描器等漏洞发现工具，在假设系统是黑盒的情况使用枚举的手段探测和推测系统可能存在的漏洞。

修复漏洞是指，通过修改漏洞形成的机制或逻辑，使破坏系统的交互行为无法进行。通常修复漏洞需要修改代码，如果使用三方产品则需要升级版本或安装补丁包。

验证效果是指，模拟漏洞利用的手段，对漏洞利用的过程进行尝试复现，如果没有出现漏洞被成功利用，或者返回具有漏洞存在的特征的响应结果，那么代表漏洞修复成功。漏洞验证具有一定的技术能力要求，对于技术储备不足的组织来说，可以根据能力所及的水平，选择性的进行。

风险规避是指，在漏洞修复过程中，往往会存在一些客观原因，某些漏洞无法被修复（例如稳定性风险的考虑），此时需要通过其他方式让漏洞无法被利用，简而言之最简单的做法就是网络隔离或者将系统下线。

1.3 原则

1. 有效原则。通过各种手段发发现的系统漏洞数量之多往往超过管理员的预期，而且大量漏洞甚至看不懂什么意思。此时需要对漏洞进行分拣，有必要修复的漏洞务必要修复，没有必要修复的漏洞直接忽略即可。

2. 暴露面优先原则。从整体架构的角度，如果能够缩小风险暴露面，优先选择缩小暴露面，而后再考虑通过修复的方式处理漏洞。

3. 完全原则。很多漏洞修复的时候只处理某种验证或利用方式造成的后果，而没有从根本上解决问题，另一些时候，一些三方组件提供的补丁包存在被绕过的情况，面对这种问题需要充分考虑漏洞形成的机制和原理，从根源上将漏洞封堵，而不只是防止某一种利用方式。如果是三方组件，则需要安装到最新版本，并注意是否有补丁被绕过的情况。

4. 稳定原则。不是所有的漏洞都能已简单的方案修复，漏洞修复往往伴随着系统的变更，而系统的变更又可能产生风险。尤其是在操作系统层面，安装漏洞修复补丁可能引起补丁功能与其他组件甚至操作系统自身的不兼容，因此漏洞修复要秉承稳定性优先的原则，通过充分测试、充分灰度验证的方案降低稳定性风险。

2 目的（why）

漏洞是攻击者为获得系统权限而选择的核心攻击对象之一，攻击者通过利用漏洞，可以达到获得系统权限的目的，从而获得分数，或者进一步向内渗透。漏洞修补不仅是一个技术问题，也是一个治理问题，因此漏洞修补不一定在单点上追求极致的修复效果，但在整体上要尽可能做到充分的覆盖，以尽可能减少漏洞被利用成功的宏观概率。另一方面，对于系统的关键组件的关键功能（例如身份认证、权限管理），要确保漏洞修复的效果，避免单点脆弱性造成重大风险。

3 方案（how）

1.暴露面分析

漏洞修补需求确定漏洞产生的范围，因为全局的漏洞100%完成修复是一项极其艰难和工程浩大的工作，短期之内无法完成，同时亦无必要。因此，在制定漏洞修补计划时要对系统的暴露面有所了解，并且在完成第一章节提到的网络隔离后，将系统的风险暴露面进一步缩小，在此基础上对必须暴露的风险点、线、面收集漏洞信息，并完成修复。

2.漏洞扫描

漏洞扫描是发现漏洞的主要手段，对于缺少安全技术运营能力的团队，也可以使用漏洞扫描工具进行扫描。漏洞扫描器的检出率和准确率是其主要的性能评价指标。检出率是指在测试条件下，漏洞的检出数量与已知的全部漏洞数量的百分比；准确率是指对于扫描出的结果，有效的漏洞占全部检出漏洞的百分比。选择一个检测性能良好的扫描工具，对于提升漏洞修补工作的质量非常关键，但是在扫描技术没有代际差异的同一时期的产品面前，扫描器的检出率和准确率往往反向相关，也就是说除非扫描器技术有了进步，否则漏洞的检出率相对高的时候，准确率会降低，反之亦然。当然这是理论上的相对效果，近些年各厂商在扫描器上的持续提升使得这个产品的检测结果已经非常友好，而不像十年前的漏扫工具，扫描的结果几乎无法直接使用。

漏洞扫描工具的检测结果报告往往包含着对漏洞的修复建议，使用者需要通过分析自身情况决定使用何种修复方案。

3.版本管理

三方组件的版本管理是主动发现漏洞的途径之一，相比漏洞扫描，三方组件的版本管理能够更直接有效的定位到漏洞极其影响范围。系统管理员应该对系统环境（尤其是生产环境）建立三方组件引入、使用、记录的流程，这些组件应该包括任何非自研的开源或商业化的软件或组件，包括但不限于操作系统、数据库、中间件、开源应用框架、开源工具软件、开源代码编码语言、运行环境和三方库等。系统管理员可以建立内部的软件仓库或者linux软件、代码三方库源提供下载，下载的日志整经过解析后存储在数据库中，作为内部的资产库。

如果由于缺少早期的基础设施导致无法跟踪和记录上述信息，那么可以登录到主机采集相关的软件信息。如果软件都是通过仓库安装的，那么收集到这些信息并不困难，但是如果通过源码编译的软件则很难收集完整。因此在系统环境中应该严格禁止通过源码编译的方式安装程序。

完成软件信息收集后，则可以根据厂商发布的漏洞补丁信息升级到最新的版本。对于使用量比较小的软件则可以使用爬虫软件从CVE等标准漏洞库检索组件相关的漏洞信息。

4.自研的应用漏洞

信息系统的自研应用漏洞的发现对于缺少专业安全团队的组织来说是比较困难的。而形成漏洞的原因五花八门，因此修复的手段也是不尽相同。这里我们总结在护网中容易造成丢分的代码层面漏洞的几种问题的防范措施。

（1）不信任一切用户输入

常见的应用层漏洞如SQL注入、XSS、命令注入等漏洞都是由于过分信任用户输入而形成的。这类漏洞的一个特点是用户输入可以被当做代码执行，而功能的开发人员没有意识到用户可能构造特殊的输入信息将文本组合、拼装、转换成可执行代码，从而按照攻击者的意图控制服务端的逻辑。

对这类漏洞的防范方案是对一切用户输入进行过滤，杜绝或降低用户输入构造成代码的可能性，例如对><\/;’,等特殊字符进行转换（如果对这类基础知识不够了解，可以自行搜索）。如果某个输入点的内容类型是特定的，则可以以白名单的方式限制用户输入，例如只允许输入数字、字母、下划线或者横杠等。

（2）确认用户的身份和权限

对于业务逻辑层面而言，权限漏洞是较为常见的一类漏洞，例如水平越权、垂直越权。这类漏洞的特点是功能与用户数据关联，而用户的身份由由来自用户输入的参数决定，而这个参数容易预测，例如根据用户uid更改用户昵称。假如传入参数的uid被修改为他人uid，那么他人的昵称则会在非本人操作的情况下呗篡改。另一种情况是用户执行某个本身不具备权限的操作，但是由于没有对用户身份和权限进行严格验证，则出现了可以被成功访问的结果。上述第一种情况称作水平越权，第二种情况称为垂直越权。

对这类漏洞的处理办法是每次操作前验证当下的用户身份，身份标签具有不易被猜测的特点（例如用sessionID关联用户ID），同时在每次操作先验证用户是否具有响应的权限。

（3）禁止无限提交

对于攻击者，利用身份劫持获得系统权限也是一种常见的突破方式。利用弱口令暴力破解、密码重置漏洞可以有一定概率劫持普通用户或管理员的身份。此类漏洞有一些存在验证码过短、有效期过长（有时甚至不会设置过期时间）等问题。攻击者可以通过暴力破解的方式获得正确的登录密码或验证码。

对于这类漏洞，最好的解决方法是限制同一个账号、IP等主体的提交次数，一旦超过限制的上限，便锁定会话或中止流程。此外，如果有参数过短的问题，请加固参数，如果有参数可预测的问题，请随机化参数，如果有时间窗口过长的问题，请缩短有效期。

5.临时下线应用

对于不能修复的漏洞或系统重要性较低，可以临时下线应用系统，避免被攻击队攻击。从暴露面优先原则来看，临时下线应用也是一种高效的修复方案。

6.接入WAF

WAF对于大多数扫描器行为也有很好的防护效果，由于攻击者发现漏洞也会依赖扫描器，因此使用WAF相当于一种对漏洞的通用修复手段。尽管WAF有一定概率被绕过，但仍不失为一种有效的漏洞修补的替代手段。尤其是接入云WAF，云端的安全工程师可以在护网时期实时观测攻击队行为并及时响应，防护效率大大提高。

4 需要注意的一些问题

漏洞修补的周期较长，从制定计划、发现问题、实施变更到最终验证，整个过程会遇到方方面面的细节问题，导致计划进度受阻。当变更遇到预期较大差异时，还可能引发故障，从而不得不执行回滚计划，项目的推进信心也会大大受阻。因此要及早启动漏洞修复计划，通常三个月时间是至少的。

漏洞修复也会带来来自业务方的阻力，尤其是当漏洞的危害风险不能被准确描述或验证的时候，业务部门为了稳定性或者其他原因或习惯性的倾向于采取保守的工作策略。因此漏洞修补一方面需要做好沟通，统一认识，另一方面也需要拉高管下台背书，大树底下好乘凉。

»