如何确保漏洞管理不会导致安全性降低或受损

Question

当运行漏洞扫描时，通常会报告Node.js的特定版本易受攻击，并建议将其更新到更高的版本。然后，我们还有不安全的SSL/TLS协议，比如TLS 1.0和SSL3.0，建议完全禁用它们。对我来说，上述任何建议都是需要应用于给定应用程序、主机等的更改。

现在，我想知道，如何确保任何更改都不会导致安全性降低或受损？如何确保新的Node.js版本不会引入更严重的弱点/漏洞？改变管理是如何适应这一点的？最后，更新Node.js版本或禁用不安全的TLS/SSL协议是一个更改请求，不是吗？

Answer 1

让我们以您的Node.js为例。您正在使用具有已知漏洞的版本。因此，您有两个选择：

1. 保持你知道的版本是脆弱的
2. 升级到可能易受攻击的版本。

唯一正确的选择是#2。您是否有可能升级到同样存在漏洞的版本？绝对一点儿没错!事实上，情况可能是这样的，因为很少有无bug的软件。

然而，潜在的未知漏洞的存在是一个红鲱鱼在这里。当您知道存在漏洞时(特别是当漏洞公开时)，那么修复它就很重要。显然，您不想推出一个半生不熟的修补程序，但是只因为您担心升级可能有自己的漏洞，所以保持已知的易受攻击的版本肯定是个坏主意。

Answer 2

对我来说，上述任何建议都是需要应用于给定应用程序、主机等的更改。

在这一点上完全一致，如果您有一个变更管理流程，那么所有这些更改都应该通过它。

如何确保任何更改都不会导致安全性降低或受损？如何确保新的Node.js版本不会引入更严重的弱点/漏洞？

你不能。这只是一个问题或风险。旧版本存在一个已知的安全问题，这意味着攻击者也知道这个问题，攻击者可能会将其用于攻击您的系统。新系统可能还有其他的，但在有人知道如何使用它之前，系统不会受到当前的攻击。

改变管理是如何适应这一点的？最后，更新Node.js版本或禁用不安全的TLS/SSL协议是一个更改请求，不是吗？

是的。在升级生产系统之前，您应该在开发或生产前平台上使用有文档的非回归测试，仔细测试应用程序是否正确地使用新版本。测试的结果应该是变更管理过程的输入。当然，这对于主要版本来说是必要的，对于次要版本推荐，对于简单补丁则是可选的。

Answer 3

我将更多地关注主动性、决断性和弹性，而不是等待变革的完美完成。

有些领域需要不断寻求改进：

业务决策和变更管理

• 映射和理解依赖关系
• 业务影响评估的动态
• 变更管理过程的动态
• 系统安全修补的速度
• 还原失败更改的能力
• 紧急事件反应过程
• 快速轨道处理高优先级变化
• 工作流代理分配
• 工作流中的错误
• 异常处理

安全与漏洞扫描

• 了解并标记假阳性以降低噪音
• 确保漏洞数据库是最新的
• 查明脆弱性
• 对新报告的脆弱性的反应
• 探索性渗透试验

软件开发生命周期

• 质量控制过程，集成和回归测试的自动化
• 安全审查过程，自动化单元测试，自动渗透测试