No software is programmed perfectly. As problems and bugs are discovered, the developer or a third party may fix them. This fix is what is referred to as a software “patch”. If the problem is related to a security issue, it is referred to as a software “vulnerability”. This does not mean that viruses, worms, or other programs that could exploit this vulnerability exist, but that such exploitation is possible.
Functioning Of Patch Management System
Simply having patch management software running on a computer system does not equate to a functioning patch management system. While patch software is an important part of the patch management system, it is only one component.
A patch management system manages the patch process throughout the organisation to ensure software patches are installed in an orderly and timely fashion to all systems that need it.
Patch management systems have built-in controls to ensure that patches will not impact the current configuration and functionality of the existing information system.
Patch management systems generate metrics that allow management to track the patching process, identify weaknesses, and provide auditable documentation on the effectiveness of internal control.
**
Best Practices For Patch Management**
Management commitment: Patch management system must be supported by board of directors and it should be among the strict corporate policies regarding usage of corporate technology assets. Without management’s support, patch management systems will fail to achieve the level of security expected.
Assign responsibility to: Once the management recognises the importance of a proper patch management system, a technology group must be assembled to oversee it. It is critical that this group be able to work quickly to identify vulnerabilities, understand the organisation’s exposure, determine the necessity of installing any available patch, test the patch to ensure that it will not interfere with the existing system, and implement the patch through a predetermined installation hierarchy. Identifying the individuals responsible for the patch management system mitigates the possibility that dangerous vulnerabilities known to have circulating exploits will go unaddressed.
Prioritising patch management process through risk assessment: Process of prioritising hardware assets should be set. A typical prioritisation uses an organisational risk approach, which includes identifying hardware that the organisation cannot do without.
First, software should be prioritised in terms of which programs would present the greatest risk to an organisation if they were not available.
Second, high priority should be given to those applications that are most at risk of attack because they are exposed to the Internet or other offsite access (web browsers and e-mail applications), as well as security software, including firewall and virus protection.
Specialty software, such as banking software, enterprise software, customer information, sales contact information, or personnel applications that contain confidential data is often targeted by computer hackers, making it a high priority. Assuming that the network is configured to protect this data and there is only limited accessibility to it, a lower risk priority can be assigned.
End-user awareness: Compliance by end users is essential. For example, if end users are constantly downloading programs that affect the security baseline, patch implementation will be negatively affected. In addition, the downloading of programs is an invitation for spyware, Trojan horses, viruses, or worms to enter the system. Training end users is essential for their effective participation in the patch management system.
Controlling patch management system: It’s important to look at patch management as a process, ideally, a closed-loop process. This essentially means that patch management should be automated to the point where it can maintain your desired patch levels with as little human intervention as possible.
Success of patch management system: System success/effectiveness to be measured to be able to identify weaknesses so that improvements to the system can be made. Some of the metrics include:
Susceptibility to attack metrics- include number of patches (in total and per system), number of vulnerabilities (in total and per system), and number of network services (i.e., more services means higher susceptibility).
Mitigation response-time metrics- include response time for vulnerability and patch identification, patch deployment, patch testing prior to deployment, and compliance on at-risk systems.
Cost metrics- include the patch management group, system administrator support, patch software, and system failure.
**Patch Management Is Not A Technical Problem
**
Every information system today is under constant attack. As no software program is without flaws, entry points to an information system may be many more than expected. This problem inflates when vulnerabilities are discovered and companies fail to install patches for programs when they are made available. Without a systematic process of patch management, companies are essentially leaving the doors of their information systems wide open to potential troublemakers.