Every single server is running around 100 pieces of software, each of which might have security vulnerabilities!
You have a lot of servers to manage, and every single server is running 100 pieces of software, give or take, each of which might have security vulnerabilities. When a CVE (i.e. a vulnerability alert) is released, the thought of patching the affected servers can be a daunting one, especially if you have a large deployment footprint. Geographically dispersed servers exacerbate the problem.
How do you develop a software security remediation process to keep up with all these vulnerabilities that doesn’t require doubling the staff in your IT department? How do you identify if a vulnerability affects you, match the affected version to servers in your infrastructure that are running it, and remediate?
Lastly, how do you prioritize remediation, accounting for other servers, applications, and end users that depend on each server you are remediating, all the while ensuring you give users the requisite 24 hours’ notice?
How do you bring sanity to the process?
A vulnerability alerting system?
Maybe you could set up a vulnerability alerting system. You’ll get an e-mail when new CVEs are released, detailing out what software has been compromised. Now, all you need to do is find out if you’re running that software.
If your organization’s asset management solution is an Excel spreadsheet, then the first step is finding the latest Excel spreadsheet and trying to determine what servers are running affected software. But is the spreadsheet up to date? What’s that? You never actually recorded software on your spreadsheets? Or worse, you did, but none of your co-workers took the time to follow suit?
Or, you know the installed software, but not the versions and the CVE is of course specific to a version. The variations of possible nightmare scenarios are endless; but they all have one thing in common. They’ll all keep you up all night — both literally, and figuratively, because you’re in for a very daunting remediation process. I hope for your sake that it’s not a Friday…!
License Management & Vulnerability Alerting?
Maybe better yet, you have a License management system set up as well as a vulnerability alert system. Now, when the CVE alert comes in, you can check your License Management system and produce a tentative list of servers that need patching. You’ve gone ahead and read up on the issue and determined the appropriate remediation, and you’re just about ready to take each server down and … you realize some of the server’s hostnames have been changed. You manage to get IP’s instead, and then realize you don’t have access credentials. A (vulnerable) day later, you finally have the list.
Your remediation plan calls for taking down the server and patching the affected software. You then realized that you don’t know what other software and services are running on each server, nor which users or other servers will be affected during the downtime.
Asset Database, Software License Management, & a Comprehensive Installed Software Database
To bring sanity to the software security process, an ideal CMDB system would handle Asset Management and License Management, and complete information about installed software. This system contains all information necessary to sanely handle remediation. Now, when a CVE is published, the system can show you exactly which affected software products are running in your environment, and exactly what servers that software is running on. Since the system is aware of all software running on each server, as well as the servers’ interdependencies, you are now able to prioritize remediation efficiently. You can now easily provide users proper maintenance notice, and then begin remediation.
Device42 gracefully manages all of your assets, tracks all of your licenses, and knows about all of the software and versions thereof running on each and every server. This data includes all of the necessary information and relevant details you need to plan and tackle your remediation.
Grab a free trial, today!