To understand patches well, let's start by analyzing what patches are, why they exist, why they are so important, or why sometimes they are necessary and sometimes not.
Well, the first thing to accept is that software is made by humans, and to err is human. That's why software is usually full of errors and opportunities for improvement.
It's also challenging to anticipate that the software will work well in different environments, for example, with low memory or running alongside other programs that consume resources that the programmer assumes will always be available.
Of course, it's about planning as best as possible and testing in as many environments as possible. However, once it's distributed, it can be in millions of different environments, and that's when problems start to appear. Then, the software producer creates a patch, which could be a new .dll or .exe file or another type of file that needs to be changed. Perhaps it's just one file within that large software, but not only does that file need to be updated, but a new installer also needs to be created.
Finally, this is a new software that also undergoes testing and then gets distributed.
But remember, this is still software... made by humans.
This one can also bring errors or miscalculations; it might no longer conflict with one program, but now it does with another. Maybe the original software worked perfectly on your machine, but the patch might not.
So distributing patches is a task in itself that can be manual or automatic, but deciding whether to patch or not and which processes to follow to ensure that the company is not affected is another task that can be more complicated.
Distributing a patch to thousands of user machines can be a logistical problem (like delivering small packages to thousands of PCs in different locations) and can cause an impact due to the large number of "small" issues. But causing a server to crash when patching it can be another major problem.
Then, to study this problem, let's divide the machines into 3 groups:
Machines of regular users that have very similar office software and if they fail the impact is not very significant, but of which there are a large number.
Normal machines used by key business users.
Servers
Common mistakes distributing software
Reason #1: Lack of technical knowledge
On a global scale, there is a shortage of people with technology knowledge, and when a company has personnel available, they often allocate them to other tasks they consider more prioritized. Various tools can help automate part of these tasks, such as monitoring tools that detect where patches are missing, others that manage process flows by alerting responsible individuals of pending tasks, and others that securely and efficiently distribute patches.
Reason #2: Not testing the patch in test environments similar to where it will be installed.
Every patch carries a risk of failure. It's possible that no one has tested that patch in the specific characteristics of our environment. It's essential to have testing environments and a strategy for patching progressively, not all at once. If something goes wrong at the beginning, it's important to be able to stop there and avoid many problems.
Reason #3: Overloading the network by sending the patch from one PC or server to each of the other PCs.
Strategies can be employed to send the patch from servers close to groups of PCs and then install it in those areas. In the case of machines outside the network, it's better to send these patches from a server on the internet with security schemes like hashing and public-private key encryption, ensuring that the patch arrives without any modifications and is truly authorized by the company.
Reason #4: Patching critical servers or computers without a formal change process.
In summary, a formal change process involves several steps. It begins with change planning, where proposed dates for patch preparation, testing procedures, installation, rollback plans in case of failure, verification of successful implementation, and associated risks are outlined. Someone must review everything, particularly the risks, and provide an assessment. Then, depending on the criticality of the change, a council or individual must authorize it. These processes ensure that various individuals from different backgrounds participate in the change, thus reducing the risk.
Reason #5: Not patching to avoid risks. "Leave it as it is..."
When a server is critical and the company doesn't want it to be down for even a second, they may choose not to patch it, which in certain cases is understandable. Why take the risk of applying a patch that isn't necessary? However, what happens when a patch is closing a security loophole? If there isn't a well-executed change process, it's common for companies to opt to leave the system without security patches. Who would notice? Well, there are programs randomly scanning or probing addresses used by other programs to find which ports are open and attempt to exploit security vulnerabilities on those ports. If, by chance, the patch isn't installed on that machine, the hacker could gain entry and take control or install ransomware.
If you need advice, we can help you!
We understand how challenging it can be to implement a cybersecurity framework. Start with us from the basics by identifying the technological assets you have.