There are many ways to address vulnerability management in a business’ security, but some of the most highly recommended include:
Identification and inventory of systems – performing a comprehensive audit of all software and hardware within an environment provides a clear picture of the business’ status and comparing known vulnerabilities to an inventory enables users to quickly discover what patches are needed.
Risk assignment – working out the level of risk applicable to each piece of inventory enables correct prioritisation of remediation, saving time spent on hours of patching the wrong systems, when the compromise is in a different area.
Software version consolidation – the more versions of a piece of software an organisation is using, the greater the risk of exposure, as well as the increased administrative overhead required to maintain and service all the various levels. One version of Windows, Linux, macOS should be chosen and deployed across the entire organisation and these should then be kept as up-to-date as possible with patches. Large organisations may buy different software products that perform similar functions, but periodically reviewing all of the software that’s in use and the purpose for which they’re used is important. When multiple pieces of software performing the same function are discovered, one should be deployed and the others removed. Fewer software products means fewer patches that need to be applied, saving time in remediating issues.
Patch announcements – following consolidation is the importance of keeping on top of fixes for vulnerabilities, which can be complex but vital when a business has a number of third-party vendors. Once there is a clear inventory, businesses should ensure they subscribe to updates, monitor each application and not let any of the remediable patches fall through the cracks, but get added to a patch schedule. Sometimes patches cannot be applied straightaway. For example, there may be an older application or system that uses Java and a patch to Java could break the business application, making it necessary to consider the changes that need to be made before the patch can work. In such cases it’s best to mitigate the risk as much as possible by, for example, setting user permissions on the server. Unpacked servers should never be left exposed to the internet. Instead, determine how to reduce the impact and likelihood of an exploit, so that the vulnerability can be patched and mitigated as soon as it is feasible.
Testing – every environment is unique, so a simple patch that may seem straightforward to apply could cause problems and even bring down entire systems or environments depending on the configurations involved. To avoid this, take a small subset of the systems and apply a patch in an environment where, if it does cause major issues, it is isolated, so recovery is easy and the business’ ability to operate is not impacted. Once this stage has been completed, it’s still important to not simply deploy the patch to the rest of the fleet, set and forget. Users should then be actively engaged in testing to avoid disparity between the administrator deploying the patch and the user using the system. As part of the PPT mentioned previously, it’s important for both to work together and liaise as part of the testing process.
Speed – patches must be applied as quickly as possible and this means patching highly critical vulnerabilities within 48 hours of release,
non-critical within a week and information or security patches within a month. Many organisations will find that the applications they build have a great deal of flexibility in operating systems and servers. For example, if security vulnerabilities are discovered in custom code, they would be added to the development (‘dev’ or software engineering) team’s backlog to be treated with the same degree of importance as a vendor patch. But when it comes to operating systems in servers – which are the core operating threat factor – this could mean leaving doors open to attack due to a patch that has been around for five to even 15 years and has not been remediated.
Automation – ensuring that there are systems and technologies in place to automate processes as much as possible will reduce attack surfaces. Using tools to help deploy a swift and efficient patching strategy will ensure that there are no extended periods of exposure, while adversaries are mobilising their attack plans.
Use case
Take, for example, an organisation looking to deploy a new ecommerce platform designed for 24/7 sales. This could be an example of having an in-house dev team code the back end traditionally, while an IaaS (Infrastructure as a Service) provider manages the actual infrastructure.
It’s vital that these two different teams, one internal and one external, work together on vulnerability management to ensure the organisation isn’t open to being compromised. Such a system may well require customers to enter personally identifiable information, such as credit card details, billing and delivery addresses, dates of birth etc. Perhaps when setting up this particular system for the purposes of sales, a Windows or Linux infrastructure has been leveraged, but is the organisation then checking for vulnerabilities and exploits applicable to the front end – the areas with which customers are integrating? Are these being patched? Is the code being tested for SQL (structured query language) injection?
A tried and tested vulnerability management strategy will ensure the business remains secure and doesn’t end up as a statistic in the media.