Virtual patching is a task that needs to be part of every conscientious administrator’s duty. It is a responsibility that is critical to the survival of a business.
A malicious attacker will always be on the lookout for weak points or vulnerabilities in a network. They prowl around the Internet looking for weaknesses in software, hardware, or connectivity device configurations that they can exploit. Virtual patching is one way to make sure they don’t succeed.
Hackers are always a step ahead of software and hardware manufacturers as they continue to seek out these vulnerabilities. This makes virtual patching a critical part of a network or system administrator’s duties.
OK, but what is patching?
Patching is the process of upgrading software to their latest and most secure versions with the hopes of plugging any “holes” – known as “vulnerabilities” – in an application or operating system. The intention is to close them from being used as “exploits” whereby cybercriminals gain unauthorized access to them.
There is a window, between a vulnerability being discovered and the possibilities of an exploit being used, that is only closed when an administrator has “patched” the hole and made the network and applications safe again.
In larger networks, this can be a tedious affair as patching is done on an individual, host-by-host, or device-by-device basis. It is also a repetitive occurrence since vulnerabilities are too common an occurrence.
What is virtual patching?
When it comes to virtual patching, it is also the process of removing any vulnerabilities. But, in this case, it focuses on stopping vulnerabilities and exploits at the network level and not the end-point software solutions.
In this case, the actual task is a lot less tedious because the rollout is focused on a few networking devices. In other words, it is rolled out via a network – and addresses the vulnerabilities at the end-points from the network itself.
Looking at the process in more detail – it is rolling out a layer of security policies that, by analyzing data packets and traffic, prevent and intercept the exploitation of vulnerabilities.
For a virtual patching solution to be effective it must have the following capabilities:
- Deep packet inspection – to inspect and then stop malicious packets and malevolent activities from hiding in web and network traffic.
- Prevention – once the packets have been identified, they need to be destroyed before they reach their intended target hosts.
- Deployable anywhere – it should be able to be run in both cloud as well as on-premises network architectures.
Necessity for virtual patching
By now, we should have an idea of what virtual patching does. But, let’s have a look at why we need it:
- It prevents the risk of a successful breach or attack until a vendor-supplied patch is released or while the patch is being tested and applied.
- It reduces any conflicts from appearing in the software environment as there is a lesser chance of introducing conflicts because libraries and support code files are not changed.
- It prevents downtime of mission-critical systems that cannot be taken offline.
- It cuts the costs of time and money spent performing emergency patching.
- It allows businesses to maintain normal patching cycles.
It can be said that virtual patching is important for the security of digital assets, which require considerable planning as well as zero downtime before a permanent patch can be deployed to protect them.
Examples of such systems would be pipeline monitoring systems or machines running critical systems – which play a vital role in a nation’s infrastructures like hydroelectric dams and electrical grids, which can’t be taken down.
And then, there is the fact that in these days of cloud-based and remote-hosted architectures, businesses may not have direct, seamless access to their digital assets. The only way they can secure their hatches until their hosting or cloud service provider patches them is with the help of virtual patching.
Virtual patching – Pros
The advantages of virtual patching include:
- When it is done in time, it can protect a business and its clients before a breach or unauthorized access.
- It shows that a business is a professional entity that proactively undertakes steps to ensure its own security – especially if there is a wave of attacks and it remains unaffected by them.
Virtual patching – Cons
Looking at some drawbacks, we have:
- When done wrong or too late, it could spell disaster to businesses and customers alike – this means a professional is required to perform virtual patching. This is because a single misconfiguration could result in processing errors, bring the business to a halt or even crash the whole network completely.
- Unless it is done with the correct resource allocations, other critical processes might lag or even crash because of virtual patching eating up bandwidth due to misconfigurations or traffic being diverted to networks that can’t support the sudden influx, for example.
Therefore, it needs to be noted that an effective virtual patch makes sure that the vulnerabilities are addressed – i.e., patched – without modifying an application or system’s code or diverting traffic to infrastructures that can’t support surges.
The virtual patching process
Here are the six essential steps in a typical virtual patching campaign:
- Awareness – virtual patching is initiated or necessary as soon as an administrator is aware of the vulnerability. This could be via alerts received from a WAF, SIEM, IDS, or IPS following attack attempts, post-breach, or in lieu of suspicious activity. It could also be thanks to proactive actions taken following critical alert advisories or patch update bulletins from software and hardware manufacturers or their governing bodies.
- Analysis – once the threat has been detected, and positively identified, it is time to analyze the situation on the ground. Typically, administrators will take stock of all their assets and find out which ones need to be patched and what software version should be used. For this to work, of course, they will also need to know how the vulnerabilities are exploited and what needs to be done to stop it from happening.
- Strategizing – at this point, when all the information is in, it is time to start creating IPS rules; reviewing and fortifying policies, searching for patching tools, and mapping out which device should be patched first or last, and preparing for crashes by implementing disaster recovery plans, etc., can also be part of this step.
- Testing – this is the stage where all scenarios are played out, all holes are plugged, and everything is thrown at the system to see if it holds up. It would also be ideal to do this testing phase on a dummy network (or a test environment). This phase is repetitive and exhaustive until all lights are green and it is deemed safe to actually start applying the patch.
Some testing tools that can be used include:
-
-
- A web browser – to test if there is communication between systems or whether web applications are working as they are supposed to.
- Linux command line commands to test connectivity and accessibility – like curl and Wget.
- Web app scanners, security and events testing tools, as well as penetration testing tools like OWASP ZAP and ModSecurity AuditViewer.
-
- Application aka Virtual Patching – here, the patches are pushed out and applied to each device or website in the production environment. There are tools that can help at this stage and that we will see later.
- Monitoring – once this stage is reached, it is time to see how successful the previous steps had been. All changes in performance, response times, service delivery, process completion, and such should be monitored. Any deviation should be looked into to detect anomalies and their causes. If it leads to the virtual patching, it means it is back to Step 4, the Testing Phase – and into a loop – until the expected right results are achieved.
What would influence a virtual patching campaign?
A successful virtual campaign needs careful planning. Here are some of the questions that need to be asked in order to make it so:
- Determine the scope of the campaign – is the data to be protected stored in a central location or is it dispersed to multiple network segments?
- Be aware of the architecture to cover all the vulnerable assets – what is the network configuration and how does the data flow through the network?
- Awareness of manufacturers and technologies involved – what type of hardware and applications are running on the network and are there systems from multiple vendors?
- Operating systems involved to avoid conflicts – is the network running Windows, UNIX, or Linux operating systems, or some combination?
- Access and permissions required to reach assets – is the network managed locally or outsourced to a third-party security provider?
- Virtual patching team’s capabilities – will the virtual patching system be run by employees or a managed security service provider?
Answering all of these questions will result in a well-defined plan and a team that knows what to do – resulting in successful virtual patching.
What would happen without virtual patching?
To answer this question, we would need to have a look at the worst-case scenarios:
- Network and system compromise – this is an obvious one. But then, one website can lead to the full compromise of a network, all the other devices connected to it, as well as the applications and software running on them.
- Compromised security measures – once unauthorized access is successful, the rogue user can pretty much see the “blueprint” of the security that has been put in place and use this knowledge to bypass it and stage further enhanced attacks like distributed attacks of both local and global networks.
- Critical data exposure – one script, injected into the right input feature (a URL, text box, query box, etc.) can allow unauthorized access to SQL data that should never be shared, for example.
- Financial loss – crashing websites keep customers away. This kills a business’ income and revenue streams that are based on such websites. And then, of course, there is the matter of exploits that use vulnerabilities to steal valuable personal and financial information and use it to cash in in real life. Fighting the ensuing lawsuits alone would break most companies.
- Reputational loss – no business can appear to be a professional entity if it keeps having regular system crashes, let alone breaches leading to data losses. The business world, and especially the paying customers, expects confidential data to be held, well, in confidence.
Bottom line: no one would want to deal with a business that had a website that is always down, owns a network that keeps crashing at every other transaction request, or runs servers that leak data as fast as they can capture them.
Are there any virtual patching tools?
As we reach the end of this post, it will come as welcome news that there are tools out there to help administrators with virtual patching.
But, before we jump into the tools themselves, let’s have a look at what makes a tool the best one for virtual patching.
The features that would make it so include:
- End-to-End visibility – it should cover the whole architecture, regardless of the operating system, processes, services, and hardware that is being used.
- Accuracy – a virtual patching tool should be able to identify the issue before it can recommend a solution or point towards alternative ways of handling it; it should, therefore, be able to rely on a large database allowing it to cover a wider, more recent variety of vulnerabilities.
- Auto-patching – the tool should be able to send out the correct type, and version, of patches and then install or apply them without any manual intervention required; in fact, it should know the sequence of the patches that are applied so as to avoid conflicts or, worse, crashes.
- Remote access – the administrator doesn’t need to be on-campus when rolling out a patching campaign; it doesn’t matter if it is an on-premises, cloud, or hybrid network – it should be remotely accessible whenever patching needs to be done.
- Testing – the tool should be able to run tests to see if the patching was successful before calling the campaign a success. In fact, it should be able to test the patching campaign both before and after the patching process.
Examples here could be testing the patches on isolated sample networks or even on individual subnets instead of finding out later (when the wrong patch has crashed the entire network) that they don’t work.
- Price and licensing – while “free” is always the best price, it doesn’t mean that paying a little more for premium, mission-critical features won’t be a better option; especially, if it can do a better The trick is finding that sweet spot between price, features, and the current requirements.
