2

When running vulnerability scans, often a particular version of, say, Node.js is reported to be vulnerable along with a recommendation to update to a higher version. Then we also have insecure SSL/TLS protocols, like TLS 1.0 and SSL 3.0, and it’s recommended to disable them altogether. For me, any of the above recommendations is a change that needs to be applied to a given application, host, etc.

Now I’m wondering, how can one make sure that any of the changes does not lead to reduced or compromised security? How one can make sure that the new Node.js version is not introducing even more severe weaknesses / vulnerabilities? How does change management fit into this? In the end, updating the Node.js version or disabling unsecure TLS/SSL protocols is a change request, isn’t it?

Community
  • 1
user211245
  • 79
  • 3

3 Answers3

2

Let's take your Node.js example. You are using a version of with a known vulnerability. Therefore you have two options:

  1. Stay on the version that you know is vulnerable
  2. Upgrade to a version that may be vulnerable.

The only correct choice is #2. Is it possible that you are upgrading to a version that also has vulnerabilities? Absolutely! In fact that is probably the case, as there is rarely such a thing as bug-free software.

However, the potential presence of unknown vulnerabilities is a red-herring here. When you know there is a vulnerability (especially when the vulnerability is publicly known), then fixing it is important. Obviously you don't want to push out a half-baked fix, but staying on a known vulnerable version simply because you are afraid the upgrade may have its own vulnerabilities is definitely a bad idea.

Conor Mancone
  • 29,899
  • 13
  • 91
  • 96
2

For me, any of the above recommendations is a change that needs to be applied to a given application, host, etc.

Totally agree on that point, and if you have a Change Management Process, all those changes should pass through it.

how can one make sure that any of the changes does not lead to reduced or compromised security? How one can make sure that the new Node.js version is not introducing even more severe weaknesses / vulnerabilities?

You cannot. It is just a matter or risks. The old version has a known security problem, meaning that the problem is also known to attackers which could use it against your system. The new one probably has others, but until someone knows how to use it, the system is not vulnerable to current attacks.

How does change management fit into this? In the end, updating the Node.js version or disabling unsecure TLS/SSL protocols is a change request, isn’t it?

Yes it is. And before upgrading a production system, you should carefully test that your application works correctly with the new versions by using documented non regression tests on a development or pre-production platform. And the result of the tests should be an input for the change management process. This is of course essentiel for major versions, recommended for minor ones, optional for simple patches.

Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
0

I would focus more on proactivity, decisiveness, and resilience and do not await the perfection of a change.

Some areas to continuously look for improvements:

Business Decisions and Change Management

  • mapping and understanding of dependencies
  • dynamics of business impact assessments
  • dynamics of the change management process
  • speed of system security patching
  • ability to revert failed changes
  • emergency incident response process
  • fast track processing high priority changes
  • workflow deputies assignment
  • errors in workflow
  • exception handling

Security and vulnerability scanning

  • understand and tag false positives to reduce noise
  • making sure vulnerability databases are up to date
  • identification of vulnerabilities
  • reaction to newly reported vulnerabilities
  • exploratory penetration testing

Software Development Lifecycle

  • quality control process, automation of integration and regression tests
  • the security review process, automated unit testing, automated penetration testing
LLub
  • 1,246
  • 10
  • 21