旧式应用管理备忘单¶

简介¶

旧式应用是指那些被认为是过时但仍被组织 actively 使用的应用程序。这可能是因为没有可行的替代方案，或者替换成本目前过高，又或者应用程序是高度定制的，并在组织的数字生态系统中扮演着非常特定的角色。旧式应用通常会给组织带来显著的安全风险，原因如下：

旧式应用可能已达到生命周期结束 (End-of-Life, EoL)，这意味着该应用程序不再接收补丁或供应商支持。这极大地增加了应用程序中漏洞被留在可利用状态的风险。
一些应用程序是使用不再常用或不再教授给技术人员的技术构建的。这可能意味着当出现漏洞时，排除故障或修复漏洞所需的知识可能不足。
旧式应用可能会生成自定义格式的数据，并/或使用旧的接口或网络协议。这可能会阻碍将应用程序生成的数据与用于漏洞管理或安全日志记录的服务（例如 SIEM（安全信息和事件管理）解决方案）结合使用的努力。

由于没有一劳永逸的方法来保护旧式应用，本备忘单旨在提供一些实用建议，以在没有替代方案的情况下加固旧式应用。首选方法将取决于多种因素，例如旧式应用存储和生成的数据类型、应用程序及相关基础设施是否存在已知漏洞，以及在多大程度上可以限制对旧式应用或其某些高风险组件的访问。可能需要与安全领域专家（内部或外部）合作，他们可以提供具体且有背景的建议。

库存与资产管理¶

作为基础，组织应该清楚了解目前正在使用哪些旧式应用以及使用这些旧式解决方案的预期风险。

库存管理： 首先编制文档，识别组织使用的旧式应用，包括版本号、生产日期和相关配置设置。理想情况下，这应包括到达应用程序及相关基础设施所需的网络主机位置详细信息。还应概述用于托管应用程序和/或数据存储基础设施上运行的服务记录。在某些情况下，文档可能包括与应用程序相关的服务器的物理位置和允许的访问信息。组织可以选择在此过程中生成正式的 SBOM（软件物料清单）。当应用程序依赖第三方依赖项才能运行时，SBOM 会发挥有用作用。

风险评估与威胁建模： 确保您的组织清楚了解使用旧式应用及其特定组件（例如，托管基础设施上的特定 API 路由或开放端口）理论上带来的风险级别和威胁类型。这可以根据《威胁建模备忘单》中描述的应用程序形式或非形式威胁建模来确定。通过使用行业标准风险评估框架，例如 NIST（美国国家标准与技术研究院）的风险管理框架，也有助于量化旧式软件带来的风险。有许多威胁建模和风险评估框架与工具，它们各有优缺点。

作为衡量保护应用程序所需的安全措施应有多保守的非正式指标，请考虑以下问题。这些问题可能有助于将特定旧式应用或其组件的风险概况置于语境中：

应用程序处理/存储了哪些信息？如果这些信息被泄露，将如何影响您的业务以及潜在的法规/合规要求？
应用程序/应用程序依赖项/用于支持应用程序的基础设施是否存在已知漏洞？如果存在，这些漏洞有多容易被利用？能否通过适当的资源（包括熟练的专业人员）进行修补？
旧式应用程序的可用性对组织业务连续性有多关键？
如果攻击者能够访问此应用程序，他们是否存在利用它从您的组织窃取其他关键信息的风险？攻击者是否可能通过入侵旧式应用程序来建立对特定特权网络或环境的访问？

认证/授权¶

授权措施强制执行关于谁可以访问给定资源以及他们如何建立对该资源的访问的规则。授权在《授权备忘单》中有详细介绍。

在将授权控制应用于旧系统时，组织应将这些应用程序视为固有高风险。最小权限安全原则（仅允许员工/用户/系统执行其所需角色和促进业务操作所严格需要的访问权限）尤其适用于旧式应用程序。请考虑实施以下适用措施：

对应用程序应用网络级访问控制。这可能需要将应用程序托管在受限制的子网中，并/或应用 IP 白名单，以防止任意用户从任意主机与特别是面向公众的旧式应用程序进行交互。在某些情况下，应用程序可能需要在气隙环境中运行。
可以通过减少最终用户可用的功能集，在更精细的层面考虑授权控制。例如，可能需要禁用某些高风险功能，特别是管理功能。
确保只有经过认证的用户才能访问应用程序。这可以由应用程序本身强制执行，或通过使用 IdP（身份提供商）服务强制执行。如果应用程序托管在受限网络环境中，则也应要求对该网络环境进行认证才能访问（例如，用户可能需要在访问应用程序之前向 VPN 服务器进行认证）。实施这些控制中的一项或多项将既能减缓攻击者的速度，又能帮助在发生事件时进行调查。有关认证控制的更多信息，请参阅《认证备忘单》。
关闭用于运行应用程序的主机上并非严格需要应用程序执行组织所需任务的任何端口。访问某些端口也可以使用防火墙/应用程序防火墙规则来限制，以锁定服务器基础设施。
在某些情况下，通过开发一个中间服务（例如，一组单独的 API）来处理数据进出旧式应用程序的基本移动，而最终用户无需直接与旧式应用程序交互，从而几乎可以限制所有用户直接访问旧式应用程序。

漏洞管理¶

漏洞扫描： 旧式应用程序应尽可能使用行业标准漏洞评估工具（如 Nessus 和 Qualys）进行定期漏洞扫描。这应定期进行，理想情况下，扫描应按设定的时间间隔自动进行。在适当的情况下，也可以使用代码扫描工具识别一些漏洞，例如 SAST（静态应用程序安全测试）工具来检查代码库中明显的漏洞，或 SCA（软件组成分析）工具来识别应用程序使用的易受攻击的依赖项。在某些情况下，上述选项均不适用于应用程序，在这种情况下，直接对主机配置进行人工评估和手动代码审查可能是评估旧式应用程序安全状况的唯一合适选择。

补丁管理： 在可能的情况下，应用上述工具发现的补丁。补丁工作应根据漏洞的严重程度以及漏洞是否有已发布的 CVE（通用漏洞披露）和/或公开列出的漏洞利用进行优先级排序。在旧式应用程序无法实际打补丁的情况下，考虑如“认证/授权”部分所述，对应用程序/受影响的组件施加额外的限制。

数据存储¶

确认在任何可能的情况下，应用程序处理的数据在静态存储时（即存储在数据库中时）和传输中都是加密的。《加密存储备忘单》和《HTTP 严格传输安全备忘单》可能会提供一些有用的进一步背景信息。在某些情况下，旧式应用程序可能仅限于使用仅支持明文数据传输的旧网络协议。在这种情况下，对应用程序施加最严格的网络访问控制尤为重要。这可能需要对应用程序进行临时或永久的气隙隔离（功能隔离）。

确保可维护性¶

在可能的情况下，争取保持对应用程序的高度机构专业知识，以便员工可以根据需要修复安全漏洞并对应用程序进行故障排除，以确保业务连续性。以下建议适用：

应有不止一名员工接受充分培训，能够对旧式应用进行故障排除/重新配置。这将降低如果一名受训员工离开组织，旧式应用维护能力完全丧失的风险。
鼓励员工定期记录流程，包括记录旧式应用常见故障场景的故障排除指南。
如果您的组织中不存在相关专业知识，可能需要教会核心员工小组使用旧式应用所用的语言编写基本程序。

变更管理¶

大多数旧式应用的最终目标是从无法维护的系统迁移到既可维护又能够抵御当代威胁的解决方案。分阶段的变更管理可能会考虑以下因素：

实际可以分配多少预算用于升级到现代解决方案，以及多久可以获得预算？
您的组织内部是否存在处理迁移所需的专业人员，或者是否可以获取/培养这些人？
根据应用程序的风险概况和组织的风险承受能力，升级到新解决方案的迁移有多紧急？

一个正式或非正式的变更管理计划应包括对迁移到升级解决方案的具体步骤的清晰描述、预期的完成日期，以及对变更的业务和安全案例的清晰阐述。为了制定一个现实的迁移计划，应广泛咨询负责监督和使用现有解决方案的员工，以了解旧式应用程序对您的组织有多关键，以及促进迁移或彻底淘汰应用程序可能存在哪些障碍。

持续监控与事件响应¶

旧式应用程序应受到特别高程度的安全监控，并对潜在事件进行快速响应。这可能会因互操作性问题而受到挑战，即应用程序生成的日志格式可能无法被组织使用的安全监控工具轻松摄取。潜在的变通方法可能包括：

开发自定义 API，将旧式应用程序及其日志中的安全相关信息修改为组织使用的安全监控解决方案可摄取的格式。
如果上述方法不可行，考虑使用自动化脚本生成报告，以评估是否存在入侵迹象。
警惕进出旧式应用程序环境的任何异常网络流量以及网络活动的任何激增。
如果您有内部或聘请的事件响应团队，请确保他们意识到对于关键旧系统，应优先处理事件响应和异常事件调查。处理应用程序停机和受损的流程 ideally 应该作为事件响应手册的一部分提前记录。这需要为员工提供清晰的应急程序概要，包括升级联系人以及事件响应负责人的详细信息。
事件响应计划应在更广泛的业务连续性计划框架内进行。