Vulnerability Remediation

During my last blog post, I discussed the differences between vulnerability scanning and a penetration test.  Now that I, hopefully, explained why you want both and how they are useful, it is time to discuss what to do with this information.  Both a vulnerability scan and a penetration test will give you the standard way to fix the vulnerability.  I hate to say this, but I doubt your network is standard, and if you do fix it, you will most likely break something else.

Not every vulnerability is like this.  Many of the vulnerabilities that show up, can be fixed with a simple update to the system, which will work perfectly and won’t cause a problem.  But there are also those vulnerabilities that sit on the list and won’t go away.  Those are the ones you will probably want to put on a white board to get a better understanding on how to fix them.

A good example, which I have worked with in the past, is TLS.  Vulnerability scanners will recommend all servers allow only TLS 1.2 connections.  You might be thinking, ‘great, that is easy’.  Just make a couple of registry changes on the server and suddenly you are only allowing TLS 1.2!  But wait, how come none of the Windows 7 workstations are connecting?  Windows 7 doesn’t have TLS 1.2 on by default, which requires you to push changes to those machines.  So unfortunately, your end users can’t connect until you either revert or push these new changes to their workstations.

None of this is extremely hard, but it does require forethought before implementation.  Look at both the client and server aspect of the connection.  If you upgraded the workstations first, then did the servers, nobody would have noticed an issue. But you also must look at who is connecting.  Are people outside the organization connecting to this machine?  If so, do you want to force them to use TLS 1.2?  Some older operating systems do not support it, and not all end users will know how to make changes to the system to allow them to connect.  You might at this point want to accept the risk of not using TLS 1.2.  Before you make that decision, you do need to do a risk analysis, because some risk is just too high to accept.  That topic is a little too big for today’s blog, so we will tackle that next time.

If you have questions on vulnerability management, give Thrive a call and we would be happy to talk with you.