CISSP官方学习指南第7版#第15章

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

=Start=

缘由:

备考CISSP,学习、整理在看《CISSP官方学习指南(第7版)》时的一些知识点,方便以后快速复习。

正文:

参考解答:
第15章 安全评估和测试

本章中覆盖的CISSP考试大纲包含:
6.安全评估和测试(设计、执行和分析安全测试)
A.设计与验证评估和测试策略
B.进行安全控制测试
B.1 漏洞评估
B.2 渗透测试
B.3 日志审核
B.4 综合事务
B.5 代码审核和测试(如手动测试、动态测试、静态测试、模糊测试)
B.6 误用情况测试
B.7 测试覆盖分析
B.8 接口测试(如API测试、UI测试、物理测试)
C.收集安全处理数据(如管理和操作控制)
C.1 账户管理
C.2 管理审核
C.3 关键性能和风险指标
C.4 备份验证数据
D.分析和报告测试输出(如自动、手动)
E.实施或促进内部审计和第三方审计

安全评估和测试要进行定期检查,以确保安全控制数量足够、部署到位并且能够有效地执行它们的指定功能。

15.1 创建安全评估和测试程序

信息安全团队维护活动的基石就是他们的安全评估和测试程序。这个程序包括测试、评估和审计,它们用来定期核实机构有充足的安全控制以及这些安全控制可以正常运作以便有效地保护信息资产。
在本节,你将学习安全评估程序的三大主要构成:
•安全测试
•安全评估
•安全审计

15.1.1 安全测试

安全测试能够验证控制运行正常。这些测试包括自动扫描、工具辅助渗透测试和手动测试。安全测试应该定期进行,需要关注保护组织的每个关键安全控制。

15.1.2 安全评估

安全评估是对系统、应用程序或其他测试环境的综合评价。在进行安全评估的过程中,受过培训的信息安全专家会执行风险评估以识别受测环境的漏洞,由此可根据需要做出折中处理和提出修复建议。

安全评估通常包括使用安全测试工具,但不只是自动扫描和手动渗透测试,还包括彻底审核威胁环境、当前和未来面临的风险以及目标环境的价值。

安全评估工具的主要产物通常是一份用于管理的评估报告,这份报告以非技术性的语言描述了评估结果,并且以具体建议作为结论,从而提高被测环境的安全性。

15.1.3 安全审计

安全审计会使用与安全评估期间相同的许多技术,但必须由独立的审计员执行。虽然组织的安全人员可能经常进行安全测试和评估,但并不适用于审计。评估和测试结果仅供内部使用,旨在评估控制以求发现需要改进之处。从另一方面来说,审计就是评估,目的是向第三方展示控制的有效性。为组织设计、实施和监测控制的员工在评估这些控制的有效性时存在固有的利益冲突。

审计员对安全控制的状态做出的评判应公正、无偏见。他们编写的报告与安全评估报告非常类似,但这些报告的阅读对象不同,可能是公司的董事会、政府的监管人员和其他第三方。审计的类型主要有两种:内部审计和外部审计。

  • 内部审计由组织的内部审计人员执行且通常也是为了内部使用。
  • 外部审计由外部审计公司执行。
15.2 执行漏洞评估

漏洞评估是信息安全专家工具箱中的一个重要测试工具。漏洞扫描和渗透测试为安全专家提供的视角是系统或应用在技术控制方面的弱点。

15.2.1 漏洞扫描

漏洞扫描会自动对系统、应用手和网络进行探测,寻找可能会被攻击者利用的弱点。用于这些测试的扫描工具能提供快速、仅通过点击操作的测试,并执行这些单调乏味的任务,而无须手动干预。大多数工具允许以循环为基础的预定扫描,并且能够提供报告,显示不同时间各项扫描之间的差异,向管理员提供安全风险环境的变化情况。
漏洞扫描的类型主要有三种:网络发现扫描、网络漏洞扫描和Web应用程序漏洞扫描。每种类型的扫描都由多个工具执行。

1.网络发现扫描(Nmap)
网络发现扫描使用多种技术对一系列IP地址进行扫描,搜索配有开放网络端口的系统。网络发现扫描器实际上不能探测系统的漏洞,只是提供一份网络检测的系统显示报告和一份端口清单,这份清单通过网络和服务器防火墙公开了隐藏在扫描器和扫描系统之间网络路径中的端口。

2.网络漏洞扫描(Nessus)
网络漏洞扫描远比网络发现扫描深入。它们不会在检测到开放端口后就停止扫描,而是继续调查目标系统或网络来查找己知的漏洞。这些工具包括数以千计已知漏洞的数据库,它们还能执行一些测试,来确定系统是否易受系统数据库中每个漏洞的影响。

3.Web漏洞扫描
Web应用程序对企业安全构成重大风险。就其本质而言,许多运行Web应用程序的服务器必须向五联网用户公开服务。防火墙和其他安全设备通常包含一些规则,可以允许网络流量通过Web服务器而不受约束。运行在Web服务器上的应用程序是复杂的,经常对底层数据库有访问特权。攻击者通常使用SQL注入和其他针对Web应用程序安全设计缺陷的攻击来发现这些情况。

15.2.2 渗透测试(Metasploit)

渗透测试超越了漏洞测试技术,因为它实际上试图利用系统漏洞。漏洞扫描只是调查漏洞的存在,通常不会对目标系统采取进攻行动(也就是说,一些漏洞扫描技术可能会破坏系统,尽管这些选项通常在默认情况下是禁用的)。另一方面,安全专家进行渗透测试是为了试图让安全控制失效,进入目标系统或应用程序来展示缺陷。

渗透测试需要训练有素的安全专家集中注意力来应对比漏洞扫描更广的范围。当执行渗透测试时,安全专家通常的目标是一个系统或一组系统,并使用许多不同的技术来访问。

渗透测试人员可能是公司员工,他们执行这些测试作为职责的一部分,也可能是由聘请的外部顾问执行渗透测试。测试通常分为三组:

  1. 白盒渗透测试为攻击者提供了目标系统的详细信息。这绕过了攻击之前经常会有的许多侦察步骤,缩短了攻击时间并增加了发现安全漏洞的可能性。
  2. 灰盒渗透测试也称为部分知识测试,有时会选择这些来平衡白盒和黑盒渗透测试的优缺点。如果想要黑盒渗透测试结果,但是成本或时间有限,就意味着需要一些知识来完成测试,这种情况特别常见。
  3. 黑盒渗透测试攻击之前不为攻击者提供任何信息。这模拟了外部攻击者在进行攻击之前试图获取业务和技术环境信息的情况。

渗透测试耗时较长,并且需要专门的资源,但它们在良好的信息安全测试的持续运行中扮演着重要角色。

15.3 测试你的软件

软件是系统安全的一个关键组成部分。仔细测试软件对每一个现代组织的机密性、完整性和可用性要求都是至关重要的。

15.3.1 代码审查和测试

软件测试项目的最关键部件之一是进行代码审核和测试。这些程序在将代码移交生产环境之前由第三方对开发人员执行的工作进行评审。代码审核和测试可能会在缺陷生效并对经营产生负面影响之前发现安全、性能或可靠性缺陷。

1.代码审查
代码审查是软件评估项目的基础。
代码审查可能会有许多不同的形式,不同组织之间的形式也是不同的。最正式的代码评审过程称为Fagan检查,遵循如下严格的审查和测试过程,有6个步骤:
(1)规划
(2)概述
(3)准备
(4)检查
(5)返工
(6)后续行动

2.静态测试
静态测试在不运行软件的情况下通过分析源代码或编译的应用程序对软件进行评估。静态分析通常涉及用来检测常见软件缺陷(如缓冲区溢出)的自动化工具。在成熟的开发环境中,应用程序开发人员能够使用静态分析工具,并在设计、开发和测试过程中使用它们。

3.动态测试
动态测试是在运行环境中评估软件安全,对于部署别人写的应用程序的组织来说通常是唯一选择。在这种情况下,测试人员经常不能访问底层的源代码。动态软件测试的一个常见例子是使用Web应用程序扫描工具来检测Web应用程序中的跨站脚本、SQL注入或其他缺陷的存在。对生产环境的动态测试应该进行小心协调,以避免意外中断服务。

4.模糊测试
模糊测试是一项专门的动态测试技术,向软件提供了许多不同类型的输入,来强调其局限性并发现先前未被发现的缺陷。模糊测试软件向软件提供无效的输入,或是随机生成,或是特别制作,以触发特殊的软件漏洞。然后,模糊测试监控应用程序的性能,监视软件崩溃、缓冲区溢出或其他不良和/或不可预知的结果。

有两个主要类别的模糊测试:

  1. 变异模糊测试从软件的实际操作中提取之前的输入值,对其进行处理(或改变)以创建模糊输入。它可能改变内容的字符,为内容的结尾附加字符串或执行其他数据操作技术。
  2. 智能模糊测试基于对程序所使用数据类型的理解,开发数据模型并创建新的模糊输入fuzz工具根据用户规范操纵输入,将变异模糊测试的过程自动化。

15.3.2 接口测试

接口测试是开发复杂软件系统的一个重要组成部分。

15.3.3 误用案例测试

在某些应用程序中,关于软件用户可能试图滥用应用程序有明确示例。例如,银行软件的用户可能会试图操纵输入字符串来获取其他用户的账户。他们也可能试图从一个已经透支的账户取出资金。软件测试人员使用称为误用案例测试或滥用周例测试的过程来评估他们的软件对这些己知风险的脆弱性。在误用案例测试中,测试人员首先列举己知的误用案例。然后他们试图使用手动和/或自动攻击技术开发这些用例。

15.3.4 测试覆盖率分析

虽然测试是软件开发过程的重要组成部分,但遗憾的是,不可能对全部软件都进行测试。有太多的方法会造成软件故障或用于对它们进行攻击。软件测试专业人员经常进行测试覆盖率分析,进行估计对新软件进行测试的程度。

15.4 实现安全管理过程

除了进行评估和测试,有效彻底的信息安全项目还包括各种管理流程,用来监督信息安全程序的有效运行。这些过程在安全评估过程中是关键的反馈回路,因为它们提供管理监督,并对内部攻击的威胁起到震摄作用。满足这一需求的安全管理评审包括日志审核、账户管理、备份验证、关键性能指标和风险指标。

15.4.1 日志审核

安全信息和事件管理(SIEM)系统在这些过程中发挥重要作用,将日志审查的大部分日常工作自动化。信息安全管理人员还应该定期进行日志审查,特别于敏感功能来说,以确保特权用户不滥用特权。

15.4.2 账户管理

账户管理审核确保用户只保留授权权限,而没有发生未经授权的修改。

15.4.3 备份验证

管理人员应该定期检查备份的结果,以确保过程有效执行,并满足组织的数据保护需要。这可能涉及审核日志、检查散列值或请求对系统或文件的实际恢复。

15.4.4 关键性能指标和风险指标

安全管理人员还应该持续监视关键性能指标风险指标他们所监视的确切指标将根据组织的不同而不同,但可能包括以下:
•开放漏洞的数量
•解决漏洞的时间
•被盗账户的数量
•在生产前扫描(preproduction scanning)中发现的软件缺陷数
•重复审计发现
•访问恶意网站的用户尝试
一旦组织识别了希望跟踪的关键安全度量,管理人员可能希望开发一个仪表板,以清楚地显示这些指标的值随时间推移的变化,并将其放在管理人员和安全团队能够经常看到的地方。

15.5 本章小结
  • 安全评估和测试程序在确保组织的安全控制随时间保持有效性方面发挥着重要作用。业务操作、技术环境、安全风险和用户行为的变化,可能会改变用于保护信息资产的机密性、有效性、完整性和可用性的控制的有效性。评估和测试程序监控这些控制,并强调要求管理员干预的那些变化。安全专家应该仔细设计评估和测试程序,并根据业务需求的变化进行修改。
  • 安全测试技术包括漏洞评估软件测试。在漏洞评估中,安全专家执行各种各样的测试,以确定系统和应用程序中的配置错误和其他安全缺陷。网络发现测试确定网络上带有开放端口的系统。网络漏洞扫描能够在这些系统上发现已知的安全漏洞。Web漏洞扫描对Web应用程序的操作进行探测,以寻找己知的漏洞。
  • 软件在任何安全基础设施中都发挥着至关重要的作用,因为它处理敏感信息并与关键资源进行交互。组织应该使用代码审核过程,在移交生产环境之前进行井行代码验证。严格的软件测试项目还包括使用静态测试、动态测试、接口测试和误用案例测试,以有力地评估软件。
  • 安全管理过程包括日志审查、账户管理、备份验证和跟踪关键性能指标和风险指标。这些流程帮助安全管理人员验证信息安全项目的持续有效性。第三方不太频繁地进行的正式内部审计和外部审计可作为补充。
15.6 考试要点
  • 了解安全评估和测试程序的重要性。安全评估和测试程序为验证安全控制的持续有效性提供了一个重要的机制。它们包括各种工具,包括漏洞评估、渗透测试、软件测试、审计工具以及旨在验证控制的安全管理任务。每个组织都应该有明确定义和可操作的安全评估和测试程序。
  • 进行漏洞评估和渗透测试。漏洞评估使用自动化工具来搜索系统、应用程序和网络中的己知漏洞。这些缺陷可能包括缺失的补丁、配置错误或错误的代码,它们会使组织暴露于安全风险中。渗透测试也使用相同的工具,但以攻击技术作为补充,评估人员试图利用漏洞并访问系统。
  • 执行软件测试来验证进入生产环境的代码。软件测试技术能验证代码功能符合设计,并不包含安全缺陷。代码审核使用并行评审过程在代码部署到生产环境之前进行正式或非正式的验证。接口测试利用API测试、用户界面测试和物理接口测试评估组件和用户之间的交互。
  • 理解静态和动态软件测试的区别。静态软件测试技术,如代码审核,通过分析源代码或所编译应用程序,在软件未运行时对软件安全进行评估。动态测试在软件运行时评估软件安全,对于部署由别人写的应用程序的组织来说通常是唯一选择。
  • 解释模糊测试的概念。模糊测试使用修改过的输入来测试软件在意外情况下的性能。变异模糊测试修改己知输入来生成合成输入,这可能会引发意想不到的行为。智能模糊测试基于预期输入模型来开发输入,以执行相同的任务。
  • 执行安全管理任务以提供对信息安全项目的监管。安全管理人员必须执行各种活动,以保证对信息安全项目的适当监督。日志审核,特别是对于管理员的活动来说,能够确保系统不被滥用。账户管理审核确保只有授权用户具有对信息系统的访问权限。备份验证保证了组织的数据保护过程正常运作。关键性能指标和风险指标提供了安全计划有效性的高级视图。
  • 执行或促进内部和第三方审计。当第三方对用于保护组织信息资产的安全控制进行评估时,安全审计便会出现。内部审计由组织的内部员工进行,仅用于管理。外部审计由第三方审计公司进行,通常用于组织的治理机构。
参考链接:

=END=

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

《CISSP官方学习指南第7版#第15章》上有10条评论

    1. 初创公司从创业之初到上市的安全建设之路
      https://mp.weixin.qq.com/s/1e-f6OVPEdKMdxcG_Npo3A
      https://github.com/forter/security-101-for-saas-startups

      在创业的早期,应该做哪些安全方面的考虑呢?
      1、你的产品中哪些安全特性是用户期待并且会为之买单的?
      2、你所在的行业(金融、医疗、企业)对于安全的期待是什么?
      3、你的目标市场法规对安全的要求是什么(等级保护、隐私保护等)?
      4、哪些安全策略、使用的安全工具不会影响员工的工作效率?
      5、存在哪些安全风险:知识产权、商业计划书、数据等被窃有哪些影响?如何防止数据泄漏?如何在数据泄漏后减少损失?

      下面是在企业的不同阶段需要考虑的安全建议,初创企业掌握的资金和数据越多,那么相应的对于安全方面的投资就要越多。

  1. 灰盒自动化漏洞挖掘实践
    https://mp.weixin.qq.com/s/zwcpmM9rKDDaT8luoVK7xA

    一、什么是灰盒扫描

    二、灰盒扫描架构设计
    灰盒扫描系统一般分为三部分:
    (1) HOOK部分
    主要实现对一些危险函数进行HOOK,确保在运行时环境中能够获取到传入函数的任意参数。
    (2) Fuzz部分
    主要生产一些精心构造的污染数据,比如包含一些特殊符号的字符串等。通过扫描发包的方式将脏数据插入到各个待检测的地方。
    (3) 规则部分
    主要负责对漏洞的识别。通过和Fuzz系统进行配合,检查HOOK到的参数是否符合判别规则,从而判断是否存在漏洞,如果存在则发起上报流程。

    三、构建灰盒扫描系统
    3.1 构建HOOK层
    3.1.1 HOOK原理
      3.1.1.1 Zend和PHP
      3.1.1.2 PHP Opcode
    3.1.2 Hook实现
      3.1.2.1 Hook FCALL
      3.1.2.2 Hook Opcode
      3.1.2.3 Hook PHP_FUNCTION

    3.2 构建Fuzz层
    基于特殊字符
    基于特征字符串
    基于复杂逻辑判断

    四、灰盒扫描形态与部署
    4.1.1 灰盒扫描HOOK选择
    4.1.2 信息收集难点与解决方式
    受于上述的原因,我们使用了Agent + so 的搭配,让Agent常驻系统中,开辟IPC通讯给so使用。so将收集到的数据传递到Agent。IPC通讯时,不建议使用有锁通讯。针对性能这块,只能慢慢尝试调优,将性能调整到预期的水平即可。

    五、漏洞检出效果
    目前自灰盒扫描上线以来,准确率达到99%以上,基本实现了零误报,大大降低了运营成本。同时也和传统漏洞扫描进行了互补,通过将灰盒扫描嵌入到上线前安全测试阶段,可以把大多数高危漏洞扼杀在上线前阶段。

  2. 企业级自动化代码安全扫描实战
    https://mp.weixin.qq.com/s/T6EYwGpEQr64OGXGj2R5eA

    源代码安全检测是安全开发流程(SDL)中举足轻重的一部分,一般通过人工审计或者自动化工具来进行检测。在大型企业中,业务线情况较为复杂,项目开发往往使用不同的编程语言、开发框架,编码风格也大不相同。此外,存量的代码有上亿行、每天又会有大量的新增代码与项目,这些因素导致在大型企业安全实践中是无法通过人工审计代码的方式来进行检测的。因此,在人力紧张以及工作量庞大的情况下,最优的选择是依赖自动化检测工具了。

    本篇文章中,主要介绍我们自主研发的静态代码安全检测平台的整体技术原理、研发部署方案与架构、总体检出效果,以及一些具体生产环境的检出场景。

    2.1 基于污点传播分析的自动化挖掘技术

    总结
    基于语义分析、语法分析技术,并且将各个语言和框架特性进行集成和识别而构建的静态代码安全扫描器,无论是误报率还是检出率都远远低于传统的商用扫描器。

    此外,将自动化的静态代码安全扫描嵌入到开放与上线流程中,可以有效地在上线前阶段就发现代码中的安全漏洞,并将源代码漏洞报告第一时间推送给业务线的开发同学进行修复,做到防患于未然。

    而安全部门需要做的就是持续运营安全扫描规则,处理误报反馈与安全能力增强上,可以在人工代码审计上节省很多人力。

    对于大型互联网公司,拥有可以与CI流程进行结合的源码安全扫描平台是非常必要的,源码安全扫描不仅可以对安全漏洞进行扫描,还可以配合一些源码指纹识别技术与安全开发规范,对内部的一些高危开源框架、不良的编码习惯进行有效治理,可谓一举多得。

  3. 自助安全扫描与代码审计系统架构实践
    https://mp.weixin.qq.com/s/3N3eJzTaMwbznL_aofOjnQ

    公司如果有不同的业务线,各业务系统上线发布之前要进行基本的安全检查。业务在国内的其它城市,机房位置不定,发布时间不定,这时候就需要设计一套自动化机制,在业务上线新功能之前,进行自动安全扫描与代码审计。自助自动是在传统方式上的一种改变,是对即存安检查系统的重新组合使用。传统的扫描和代码审计有历史课题。 对于粗放型的安全扫描任务实施,可能会对业务造成伤害,比如Payload脏数据让业务方服务挂掉,为了避免此类情况发生,需要将扫描的粒度细分的更精准,可以定位到新机能具体接口入口位置,再进行扫描和代码审计。

    1.安全扫描:一般安全扫描实施会有一个扫描列表,并且配有白名单和不可扫主机,如果被扫业务代码不够强壮, 一旦扫描payload被业务认为是无效的脏数据,服务会受影响。解决此问题,如上所述,需要定制化扫描,针对新业务上线,老业务回归扫描检查,进行细化到接口级的扫描,不是一个域名一把梭。

    2.代码审计:代码审计误报率, 审计程序和策略都是人来写的,存在误报场景。但自动化安检处理可以突出重点误报率低的问题, 对代码审计特别擅长的漏洞,给于突出的展示空间,抓主要问题,核心威胁。 当业务方触发自动安全检查流程时,让代码审计与安全扫描强强联合,针对那些不能轻易通过扫描被发现的漏洞,或是非常耗时,依赖设计各种复杂Payload扫描发现漏洞的场景,让扫描和审计协同来完成,比如:挂马问题,代码审计可直接扫描代码发现问题,再联合扫描执行进行多重威胁确认。

    自助安检需多统协同:
    1.发布系统客户端服务:嵌入到业务发布上线系统中的,安全检查请求客户端。可以是表单,也可是后端批处理程序。
    2.网关服务:网关一般是请求的分发与重定向,简单是直接用Openresty写,复杂的可以使用Kong,活是orange这种网关产品。
    3.接口服务:具体实现REST接口的后端程序,也是安查任务调度系统。
    4.扫描系统:接受调度,进行安全检查,返回扫描报告。
    5.代码审计系统:接受调度,进行代码审计,返回扫描报告。
    6.存储系统:保存安全检查请求历史数据,跟踪检测结果。

  4. 漏洞扫描的一些运营常识
    https://mp.weixin.qq.com/s/W-nWf7tB5I4NMMEw_1SndQ

    1. 什么是漏洞扫描
    漏洞扫描是信息安全工作里,完成风险评估最常见的一种手段。就像是医生用X光来检查一下病人的身体,是不是有毛病一样,安全工作者经常通过漏洞扫描来评估目标系统是否存在漏洞,进而决策如何做下一步的安全防护。

    2. 漏洞扫描的原理是什么
    发送特定的请求,到远程服务,根据远程服务返回的行为,判断是否存在某个具体漏洞(也有很多时候是根据返回的版本号信息来判断)。

    3. 漏洞扫描有什么影响
    3.1 网络影响
    请求网络包的频率、数量,对网络和应用造成影响,交换机/路由器可能因此宕机,引发连锁反应,QPS过高可能超出服务的性能极限,导致业务中断;

    3.2 异常处理影响
    业务无法正确处理请求包里的特殊输入,引发异常宕机,比如一个私有协议的服务也许只是碰巧监听在了TCP 80端口,收到一个HTTP Get请求就直接挂了;

    3.3 日志影响
    请求公网的业务时,每一个URL的探测,都可能造成一个40x或者50x的错误日志。而业务的正常监控逻辑正是用Access Log里的状态码来进行的。不做任何处理的话,突然40x猛增,业务的SRE和RD必然要进行响应,如果他们从半夜、假期着急忙慌的登录VPN查了半天发现是安全工程师触发的,甚至还连带了3.1、3.2的影响,把某业务弄出事了,这个责任一定是安全工程师要背负的。

    4. 产生了什么问题

    · 对于安全工程师而言,不扫描可能意味着无法开展工作了,无法得知公司风险,无从开展治理工作;
    · 对于业务方而言,扫描意味着添乱,业务不可用的风险是最大的风险;
    · 有不少同行因此背锅黯然受伤的,也有一些强势的同行得罪了业务的。

    5. 错在了哪儿

    漏洞扫描对于业务侧来说,是一种新的变化。一个变化的首次引入,有问题是必然的,没问题才是异常的。合理的做法是遵循ITIL里的“变更管理”。

    变更计划:扫描的时间、IP/URL/端口范围、QPS、测试用例集(有DoS的测试用例选择、有Delete/Update相关的资产选择、有POST隐蔽接口的选择)

    变更风险评估:交换机路由器的流量和容量、业务的QPS、业务/网络挂掉的最极端风险评估

    变更知会:业务的管理者、RD、SRE、DBA、QA甚至网络维护方,是否知道上述所有关键信息,并授权同意进行扫描(全公司强制的至少做到知会)

    回滚计划:如果出了问题,怎么最快速的停止扫描和恢复业务(有些动作要上面的变更知情范围的关键干系人配合)

    变更观察:执行扫描的时候,大家有没有在盯着服务是否出错(以及判断业务是否正常),以便在出问题的第一时间响应;

    变更总结:灰度执行过程中总结不到位的地方,在下一次工作中改进

    严格的说,不按照这些方法,上来就一通猛扫的,的确是安全同行自身没有做到足够专业。不能怪业务侧不理解不支持。

    6. 解决建议:公网坚决扫,内网谨慎

    按网络分类:互联网公开业务、内网业务

    按服务类型分类:Web类、高危服务类、私有协议类

    公网Web服务,业务必须接受安全检查,因为我们不扫,黑客也会没日没夜的盯着业务扫。与其未来无计划的被黑客扫挂,不如有节奏的按变更计划,逐步适应被扫描。

    公网高危服务:只识别协议,不做漏洞检测,因为高危服务的端口开放出来就是不可取的,直接关掉服务比较直接,检测漏洞只是浪费更多的资源罢了;

    公网私有协议:大多数扫描器并不能支持这些协议的漏洞检测,只能忽略不做扫描,当然这里会存在盲点,暂时不展开;

    内网服务的复杂度比上面高很多倍,一方面,内网你不扫,黑客进来扫的几率没那么大。另一方面,大家对传统的特权的依赖导致内网漏洞比公网多很多,也更禁不住扫,你一扫,大概率就是会出事的。所以,如果仅仅做端口扫描,确定交换机路由器还扛得住的情况下(嗯,之前遇到过老旧的网络设备你稍微开一点扫描请求它直接挂掉的现象),相对可接受。

发表评论

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