My esteemed colleague Aapo Kettunen wrote about best practices in application distribution in his blog entry. While I trust his take on the subject completely, I was left to wonder: where does the whole of application updating fit in all of this?
Aapo seeked answers to these questions, for example:
- How to distribute applications?
- What is a good distribution process like?
I have had the privilege to discuss these subjects with plenty of organizations in Finland. One of my job functions is to support our sales, so I’ve traded thoughts on application updating with people from organizations of different sizes and industries. According to my personal experience, Finns do seem to be very well informed on application updating and understand its implications concerning cyber security.
Application Lifecycle and Cyber Security
I feel the need to address application lifecycle management especially from the perspective of cyber security. The application itself could be an OS or a third-party application such as Adobe Reader or Google Chrome. From application release to the end of its lifecycle, X amount of updates will be released. Those updates fall into many different categories:
- security updates
- bug fixes
- feature updates
- feature improvements.
When there is a need to increase cyber security, usually security updates are prioritized, as they are meant to fix vulnerabilities found in applications or proactively enhance data security. That is however a quite black-and-white way to look at the situation. I can’t fit every possible cyber security framework in this blog post, but one of the most used basic principles of cyber security is the so-called CIA triad, which is nicely explained in an F5 article, for example.
In this very basic model, all three aspects – confidentiality, availability, and integrity – must actualize for the system to work.
To make things even more simple: availability must also concern applications. When a user wants to use an application, it has to be available for them. Things that may influence the situation include:
- changes in application (vs. user routines)
- compatibility issues
- wide variety of versions
- endpoint rebooting.
From here on it should be easy to understand that vulnerabilities aren’t the only things to decrease application cyber security. Looking at the whole picture, application updating is far from the sole factor. Keeping an application up to date decreases the risks of bugs and vulnerabilities. On the other hand, standardizing or locking down the environment and thorough testing of version updates solve problems regarding the overabundance of versions, and compatibility issues.
Controlled application update processes for their part support these things. (As Kettunen wrote in his blog post.) A well-thought process aims to update applications in a controlled manner and, if needed, in phases to get certainty that the new version runs as it should. In that case, you should switch automated updating off.
Application Update Processes
There are lots of different recommendations, processes and models to manage vulnerabilities and security updates – you have obviously heard about patch management, vulnerability management, change management and so on. One of these models is a six-step process, used by Microsoft and many other organizations:
- Acquire data on application vulnerability and the update patch.
- Assess risk caused by the vulnerability and plan updating.
- Get the update.
- Test the update and its functionality.
- Install the update.
- Make sure the installation succeeded.
This example process may seem quite tedious, especially when there are various applications in the organization, with different operating systems that update on a fast rotation. According to our statistics, for example Adobe Reader, Adobe Flash, Google Chrome, and Mozilla Firefox updated 79 times combined during 2019.
As those are very popular applications, it is justifiable to presume there are various updates every month in a standard organization. Of course, 79 updates does not mean 79 security updates for a vulnerability.
The aforementioned things make it reasonable to say, that every organization needs a customized process for application lifecycle and update management.
Processes in Different Organizations
Finding and maintaining a suitable process may be quite challenging when you have to juggle between cyber security and usability issues. In addition to that, day to day operations with the process can be laborious and challenging. According to personal experience, there are environments of several thousands of endpoint devices with no well-thought process, and workarounds are used in many cases. In smaller organizations the situation is usually even less well-executed.
This is one of the reasons there are lots of solutions on the market that automate control concerning the most common vulnerabilities. Usually these solutions are quite capable in managing the vulnerabilities, but as noted, application lifecycle management is much more.
Every organization should set a process for themselves with clear goals. It could mean doing everything manually, automating certain parts, or automating everything. Concerning cyber security, all vulnerabilities should be taken care of as quickly as possible, but without hindering the use of applications and endpoint devices.
Figure 1 shows how the risks of a vulnerability increase during its lifecycle. It is possible to flatten the curve by quick application updating processes.
Figure 1 – Vulnerability lifecycle
Major factors in application update process are the time you have to combat potential abusers of the vulnerabilities and on the other hand, testing the update patch. By quick updating you limit the window in which the vulnerability is most exploitable. By testing you enhance the availability of applications and endpoints.
But what does quick updating even mean? According to a survey conducted by Ponemon, exploitation of a vulnerability rated critical or high-level is noticed approximately 43 days after an update patch is released.
The same survey also says that organizations update a critically vulnerable application in 16 days on average. It is possible to draw conclusions from these approximations, when you design the application update process and scheduling for your own organization.
Then what is the appropriate timeframe for your organization to state that a new update version doesn’t cause anything negative in your environment in which the vulnerability should be fixed? It may be a bit abstract and difficult, but let’s delve into it!
- How long do you need time to have a new version installed and delivered to your endpoint environment? Let’s say that it’s 5d, and in that timeframe most of your endpoints have installed the new version, in certainty.
- Then: how wide should testing be in your environment? Intensive testing per group takes at least two workdays (2d per phase) when you take into account delivering the application to an endpoint and activating its user.
- How much time do you need to download the new version and deliver it to first users in your endpoint environment? Do you have to edit the package? If so, take at least one day to do it manually.
- How quick do you get the information on a new version or a vulnerability? Do you keep yourself up to date or does a system do it for you? In my view, quick reaction time means a couple of days, not weeks.
These parts of the process take approximately 10 to 16 workdays – from the release of the vulnerability to installation of a new version, and depending on how quick is the vulnerability detected and the number of test phases. I dare to say that this is the timetable you should keep to be sure that a vulnerability isn’t exploited.
This timetable also includes a solid amount of testing. Is your organization up for it? If no part of the process is automated, you will surely have your hands full. Update management process is a tough one. Of course, I have to state that organizations are different.
A fresh, great example of a more agile solution is Windows Update for Business. It enables to pause updates or to restore endpoints to a previous update version in case of an emergency. That is a common way for smaller organizations to work.
Third-party updates are a necessary evil but as important as OS updates. If you want to automate everything aforementioned but on your own terms, I recommend using Centero Softaware Manager.
As an endpoint cyber security expert, Tuukka works as a versatile middle man between customers, sales, and development. His functions include implementations and other customer service. Once in a while, Tuukka takes part in customer meetings as a technical adviser and participates in product and service development. His main strength is endpoint management development from the standpoint of cyber security.