作为其专业活动的一部分，开发人员、渗透测试人员和安全专家必须处理漏洞管理 (VM)、（安全）SDLC 等流程。
这些短语的背后隐藏着不同的实践和工具，它们相互交织，尽管它们的用户不同。
技术进步还没有达到一种工具可以代替人来分析基础设施和软件安全的程度。
了解为什么会这样以及人们面临哪些问题是很有趣的。
流程
漏洞管理流程旨在持续监控基础设施安全和补丁管理。
安全 SDLC 流程（“安全开发周期”）旨在维护开发和运营期间的应用程序安全。
这些流程的类似部分是漏洞评估流程——漏洞评估、漏洞扫描。
VM 和 SDLC 扫描之间的主要区别在于，第一种情况的目标是检测第三方软件或配置中的已知漏洞。 例如，过时的 Windows 版本或 SNMP 的默认社区字符串。
在第二种情况下，目标不仅是检测第三方组件（依赖项）中的漏洞，而且主要是检测新产品代码中的漏洞。
这造成了工具和方法的差异。 在我看来，在应用程序中发现新漏洞的任务更有趣，因为它并不归结为指纹识别版本、收集横幅、暴力破解密码等。
为了对应用程序漏洞进行高质量的自动扫描，需要算法考虑应用程序的语义、其目的和特定威胁。
正如我所说，基础设施扫描仪通常可以用计时器代替 。 要点是，纯粹从统计角度来看，如果您没有更新基础设施（例如一个月），您可以认为您的基础设施容易受到攻击。
工具
与安全分析一样，扫描可以使用黑匣子或白匣子进行。
黑盒子
进行黑盒扫描时，该工具必须能够通过与用户使用该服务相同的界面来使用该服务。
基础设施扫描器（Tenable Nessus、Qualys、MaxPatrol、Rapid7 Nexpose 等）搜索开放网络端口、收集“横幅”、确定已安装软件的版本，并搜索其知识库以获取有关这些版本中的漏洞的信息。 他们还尝试检测配置错误，例如默认密码或开放数据访问、弱 SSL 密码等。
Web 应用程序扫描器（Acunetix WVS、Netsparker、Burp Suite、OWASP ZAP 等）还可以识别已知组件及其版本（例如 CMS、框架、JS 库）。 扫描仪的主要步骤是爬行和模糊测试。
在爬网过程中，扫描器会收集有关现有应用程序接口和 HTTP 参数的信息。 在模糊测试期间，变异或生成的数据被插入到所有检测到的参数中，以引发错误并检测漏洞。
此类应用程序扫描器分别属于 DAST 和 IAST 类 - 动态和交互式应用程序安全测试。
白盒
白盒扫描还有更多差异。
作为 VM 流程的一部分，扫描仪（Vulners、Incsecurity Couch、Vuls、Tenable Nessus 等）通常通过执行经过身份验证的扫描来访问系统。 因此，扫描器可以直接从系统下载已安装的软件包版本和配置参数，而无需从网络服务横幅中猜测它们。
扫描更加准确和完整。
如果我们谈论应用程序的白盒扫描（CheckMarx、HP Fortify、Coverity、RIPS、FindSecBugs 等），那么我们通常谈论的是静态代码分析以及 SAST 类适当工具的使用 - 静态应用程序安全测试。
问题
扫描有很多问题！ 在提供构建扫描和安全开发流程的服务以及进行安全分析工作时，我必须亲自处理其中的大多数问题。
我将重点介绍三组主要问题，这些问题是通过与多家公司的工程师和信息安全服务负责人的对话得到证实的。
Web 应用程序扫描问题
- 实施难度。 需要为每个应用程序部署、配置和定制扫描仪，为扫描分配测试环境，并在 CI/CD 流程中实施，才能使其有效。 否则，这将是一个无用的正式程序，只会产生误报
- 扫描持续时间。 即使在 2019 年，扫描仪在重复数据删除界面方面的表现也很差，尽管负责它们的代码相同，但考虑到它们不同，扫描仪可能要花几天时间扫描一千个页面，每个页面有 10 个参数。 同时，必须在开发周期内快速做出部署到生产的决定
- 糟糕的建议。 扫描仪给出的建议相当笼统，开发人员并不总是能够快速从中了解如何降低风险水平，最重要的是，是否需要立即完成，或者是否还不可怕
- 对应用程序产生破坏性影响。 扫描程序很可能对应用程序进行 DoS 攻击，并且还可以创建大量实体或更改现有实体（例如，在博客上创建数万条评论），因此您不应在生产中轻率地启动扫描
- 漏洞检测质量低。 扫描器通常使用固定的有效负载数组，很容易错过不适合应用程序已知行为场景的漏洞。
- 扫描仪不理解应用程序的功能。 扫描仪本身不知道什么是“网上银行”、“支付”、“评论”。 对于他们来说，只有链接和参数，因此大量可能存在的业务逻辑漏洞仍然没有被完全暴露；他们不会想到进行双重核销，通过ID刺探别人的数据，或者通过四舍五入增加余额
- 扫描仪不理解页面的语义。 扫描仪无法阅读常见问题解答，无法识别验证码，并且它们自己无法弄清楚如何注册然后重新登录，无法单击“注销”以及如何在更改参数时签署请求价值观。 因此，大多数应用程序可能根本不会被扫描。
扫描源代码时出现问题
- 误报。 静态分析是一项复杂的任务，涉及许多权衡。 通常必须牺牲准确性，即使是昂贵的企业扫描仪也会产生大量误报
- 实施难度。 为了提高静态分析的准确性和完整性，需要细化扫描规则，而编写这些规则可能过于费力。 有时，找到代码中存在某种错误的所有位置并修复它们比编写规则来检测此类情况更容易
- 缺乏依赖支持。 大型项目依赖于大量扩展编程语言功能的库和框架。 如果扫描器的知识库没有有关这些框架中“接收器”的信息，它将成为盲点，扫描器根本无法理解代码
- 扫描持续时间。 就算法而言，查找代码中的漏洞是一项复杂的任务。 因此，该过程很可能需要很长时间并且需要大量的计算资源。
- 覆盖率低。 尽管存在资源消耗和扫描时间，SAST工具开发人员仍然必须做出妥协，并分析并非程序可能处于的所有状态
- 研究结果的可重复性。 指出导致漏洞的特定行和调用堆栈固然很好，但实际上，扫描程序通常无法提供足够的信息来从外部检查是否存在漏洞。 毕竟，该缺陷也可能存在于攻击者无法访问的死代码中
基础设施扫描问题
- 库存不足。 在大型基础设施中，尤其是那些地理位置分散的基础设施中，通常最难知道要扫描哪些主机。 也就是说，扫描任务与资产管理任务密切相关
- 优先顺序不佳。 网络扫描仪通常会产生许多带有缺陷的结果，这些缺陷在实践中无法利用，但从形式上看，它们的风险级别很高。 消费者收到一份难以解释的报告，并且不清楚首先需要纠正什么。
- 糟糕的建议。 扫描仪的知识库通常只包含有关漏洞以及如何修复它的非常一般的信息，因此管理员必须用谷歌武装自己。 白盒扫描仪的情况要好一些，它可以发出特定的命令来修复
- 手工制作的。 基础设施可以有许多节点，这意味着潜在的许多缺陷，必须在每次迭代时手动解析和分析这些缺陷的报告
- 覆盖率差。 基础设施扫描的质量直接取决于漏洞和软件版本知识库的大小。 其中， ，即使是市场领导者也没有全面的知识库，而免费解决方案的数据库包含大量领导者没有的信息
- 打补丁的问题。 大多数情况下，修补基础设施漏洞涉及更新包或更改配置文件。 这里的一个大问题是，系统（尤其是旧系统）可能会因更新而出现不可预测的行为。 本质上，您必须在生产中的实时基础设施上进行集成测试。
方法
怎么会是这样？
我将告诉您更多有关示例以及如何处理以下部分中列出的许多问题的信息，但现在我将指出您可以工作的主要方向：
- 各种扫描工具的聚合。 通过正确使用多个扫描仪，您可以显着提高知识库和检测质量。 您可以发现的漏洞数量比单独启动的所有扫描程序的总数还要多，同时您可以更准确地评估风险级别并提出更多建议
- SAST 和 DAST 的集成。 通过在 DAST 之间交换信息，可以提高 DAST 的覆盖范围和 SAST 的准确性。 从来源中您可以获取有关现有路由的信息，并使用 DAST 您可以检查漏洞是否从外部可见
- 机器学习™。 2015年我 （和 ）关于使用统计数据为扫描仪提供黑客直觉并加快扫描速度。 这绝对是未来自动化安全分析发展的素材。
- IAST 与自动测试和 OpenAPI 的集成。 在 CI/CD 管道中，可以基于充当 HTTP 代理的工具和通过 HTTP 工作的功能测试来创建扫描流程。 OpenAPI/Swagger 测试和合约将为扫描器提供有关数据流的缺失信息，并使其能够在各种状态下扫描应用程序
- 正确配置。 对于每个应用程序和基础设施，您需要创建合适的扫描配置文件，同时考虑接口的数量和性质以及所使用的技术
- 扫描仪定制。 通常，如果不修改扫描仪就无法扫描应用程序。 一个例子是支付网关，其中每个请求都必须签名。 如果不编写网关协议的连接器，扫描仪将盲目地用带有错误签名的请求进行轰炸。 还需要为特定类型的缺陷编写专门的扫描器，例如
- 风险管理。 使用各种扫描仪以及与资产管理和威胁管理等外部系统的集成将允许使用许多参数来评估风险级别，以便管理层能够充分了解开发或基础设施的当前安全状态
请继续关注，让我们破坏漏洞扫描！
来源： habr.com