This research paper will focus on issues and concerns with Patch Management. Wit

Question

This research paper will focus on issues and concerns with Patch Management. With the advent of many types of software and systems, patch management is major nightmare. Patching the system may cause the system to crash, and not patching it can leave it vulnerable to attacks. Please research the issues and concerns with patch management and provide your views on the topic. Please consider this at an enterprise level where the complexity is increased exponentially with the increase in the number of systems. Paper Requirements: APA Format Number of Pages: Minimum of 3 Pages not including Cover, Table of Contents and References. Safe – Assignment comparison will be done

Explanation / Answer

What is patch and Patch management?

A patch is a piece of software designed to update a computer program or its supporting data, to fix or improve It.This includes fixing security vulnerabilities and other bugs, with such patches usually called bugfixes or bug fixes,and improving the usability or performance. Although meant to fix problems, poorly designed patches can sometimes introduce new problems (see software regressions). In some special cases updates may knowingly break the functionality, for instance, by removing components for which the update provider is no longer licensed or disabling a device.

Patch management is the process of using a strategy and plan of what patches should be applied to which systems at a specified time.

From my point of view, despite a few problems, I always look for up gradation/ patching the systems. This will give me new technologies and new experience.

Advantages:

Patch management assumes you have some regular way of keeping up with what you need to do, what machines need patching, testing patches, and deployment in an efficient manner. You could also -- just in Windows -- allow automatic updating, which may or may not be suitable. For the home user, or a tiny network, auto update may be the best solution. But for most networks, you need a way to manage patch deployment. Patches correct security and functionality problems in software and firmware. From a security perspective, patches are most often of interest because they are mitigating software flaw vulnerabilities; applying patches to eliminate these vulnerabilities significantly reduces the opportunities for exploitation. Also, patches are usually the most effective way to mitigate software flaw vulnerabilities, and are often the only fully effective solution. Sometimes there are alternatives to patches, such as temporary workarounds involving software or security control reconfiguration, but these workarounds often negatively impact functionality. Patches serve other purposes than just fixing software flaws; they can also add new features to software and firmware, including security capabilities. New features can also be added through upgrades, which bring software or firmware to a newer version in a much broader change than just applying a patch. Upgrades may also fix security and functionality problems in previous versions of software and firmware. Also, vendors often stop supporting older versions of their products, which includes no longer releasing patches to address new vulnerabilities, thus making older unsupported versions less secure over time. Upgrades are then necessary to get such products to a supported version that is patched and that has ongoing support for patching newly discovered vulnerabilities. As Section 3 explains, there are several challenges that complicate patch management. Organizations that do not overcome these challenges will be unable to patch systems effectively and efficiently, leading to compromises that are easily preventable. Organizations that can minimize the time they spend dealing with patching can use those resources for addressing other security concerns. Already many organizations have largely operationalized their patch management, making it more of a core IT function than a part of security. However, it is still important for all organizations to carefully consider patch management in the context of security because patch management is so important to achieving and maintaining sound security. Patch management is required by various security compliance frameworks, mandates, and other policies. For example, NIST Special Publication (SP) 800-532 requires the SI-2, Flaw Remediation security control, which includes installing security-relevant software and firmware patches, testing patches before installing them, and incorporating patches into the organization’s configuration management processes. Another example is the Payment Card Industry (PCI) Data Security Standard (DSS)3 , which requires that the latest patches be installed and sets a maximum timeframe for installing the most critical patches.

Challenges of patching;

Timing, prioritization, and testing are intertwined issues for enterprise patch management. Ideally, an organization would deploy every new patch immediately to minimize the time that systems are vulnerable to the associated software flaws. However, in reality this is simply not possible because organizations have limited resources, which makes it necessary to prioritize which patches should be installed before other patches. Further complicating this is the significant risk of installing patches without first testing them, which could cause serious operational disruptions, potentially even more damaging than the corresponding security impact of not pushing the patches out. Unfortunately, testing patches consumes even more of an organization’s limited resources and makes patch prioritization even more important. For patch management, timing, prioritization, and testing are often in conflict. Product vendors have responded to this conflict by improving the quality of their patches and bundling patches for their products. Instead of releasing dozens of patches one at a time over a period of three months, necessitating testing and patch deployment every few days, a vendor might release their patches in a single bundle once a quarter. This allows an organization to perform testing once and roll out patches once, which is far more efficient than testing and rolling out all the patches separately. It also reduces the need to prioritize patches—the organization just needs to prioritize the bundle instead of separately prioritizing each patch it contains. Vendors who bundle patches tend to release them monthly or quarterly, except for cases when an unpatched vulnerability is actively being exploited, in which case they usually issue the appropriate patch immediately instead of delaying it for the next bundle. There is a downside to patch bundling; it lengthens the time from when a vulnerability is discovered to the time a patch for it becomes publicly available. If an attacker discovers the same vulnerability before the patch is released, the attacker may have a longer window of opportunity to exploit the vulnerability because of the intentional delay in releasing the patch. However, there are two mitigating factors here. One is that if exploitation is known to be occurring, the vendor is likely to release the patch immediately. The other factor is that patches may be installed more quickly if they are bundled than if they are all released separately. So operationally, bundling patches may effectively shrink the window of opportunity for vulnerabilities in some environments. There are even more issues to consider with timing. The release of a patch may provide attackers with the information that they need to exploit the corresponding vulnerability (e.g., reverse engineer the vulnerability from the patch), meaning that a newly released patch might need to be applied immediately to avoid compromises. However, if a vulnerability is not being exploited yet, organizations should carefully weigh the security risks of not patching with the operational risks of patching without first performing thorough testing. In some operational environments, such as virtual hosts with snapshot capabilities enabled, it may be preferable to patch without testing as long as the organization is fully prepared to roll back the patches if they cause usability or functionality problems.

Related Questions

Navigate

• Browse (All)
• Browse T
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.