Aches
If you’re going to the dentist when you have a toothache, it’s clearly too late. To some extent, that’s also true when you only start updating when the breach has already occurred. However, there’s a difference because vulnerabilities can first be detected and exploited by hackers before the development community is aware of this and provide a patch.
No open backdoors
There’s little that you can do about this, the complexity, the widespread use and a multitude of (open source) vendors makes it hard to check everything. Many of these probabilities are not the equivalent of leaving the back door open in your house. But rather a combination or special circumstances of that must be met to open your back door. Think along the lines of: when system A has been configured such and such (call this B) and a hacker is able to intercept a message C with content type D, they could insert a malicious payload.
This should point out the need for regular updates. WSO2 created WSO2 Update Manager (WUM) which allows you to create a local repository of WSO2 products and check for any updates pertaining to the product. If desired, you can create a new baseline version. It will take into account and deploy all known available updates up until that time. The result is an updated WSO2 ZIP file with all of the patches applied to it. However, it should still be seen as a pre-packaged but updated version that is agnostic of any configuration. You will need to configure it before you run it in your environment. The orange steps are performed using the WUM command line tool. The blue steps are what you need to do manually, where the WUM installation is a one-time-action (or when new WUM versions are released) and more frequent push updates, depending on your organization’s preferences and requirements.
As mentioned, the deliverable is a time stamp version of the WSO2 product as a ZIP file. To assess the value of the update, check the PDF that was sent to the email address associated with WSO2 Product Support or look for the PDF in the ZIP file itself. This PDF shows all patches in the update and also the links to the issues they solve. But how do you make the WUM Update process repeatable, manageable and fast? It’s a matter of defining: who, when and how. Once you know that, you can convert this into a plan or process description.
Who
The responsibility for updating WUM is usually carried out by people with an administrative role. They should trigger or schedule the process manually and view the outcome. The file can be found locally in the repository.
When
It makes sense to plan a regular check for updates, let’s say monthly. Apart from the planned check, there’s the urgency driven update due to a recent security bulletin. Or if a much-needed bug fix or feature update is relegated to a WUM patch.
How
The mechanism of updating itself is done by WUM. The ZIP file must then be deployed in an area where we can configure the WSO2 product to mirror the actual deployment settings. This is typically something that needs an automated tool because it shortens the time to configure and makes the process repeatable and less error prone. However, it’s also something that requires investment to develop and stay up-to-date of, for example, an Ansible playbook.
But any new version must be tested. How do you do that? Normally you should have an automated baseline test that tests the main functionality of the product, regardless of which WSO2 product it is. For APIs you may use an automated tool like RestAsssured , SoapUI, postman, Selenium. For WSO2 Enterprise Integrator it can also be SoapUI, Postman or your own custom-built test scripts. Or you could do it the hard way:
- – Backup the current version;
- – Unpack the new version;
- – Apply changes to the configurations to the new version.
Now because you’re dealing with an X number of updates… this can be tricky. In general, the changes WSO2 makes are limited to stuff in jar/binaries, these are covered by the unpacking of the new version. However, sometimes they make changes to the configuration files that you have “touched”. This is where it gets tricky and you should basically verify whether you can use the config file of your “old version” or not.
In theory, however, WSO2 tries to maintain backwards compatibility, so copying over the configuration from the old to the updated version files should also work. If it doesn’t, then you must identify the changes that are required to make those files work.
Requirements
In general, you start with an actual manual check of the updates provided. Do they apply to your situation? Do they have many or only a few changes? Are there any high impact changes? Usually, you can only verify this if you are aware of the context of your own environment. This is part of a process description that you should have as repeatable process for updates.
What’s in such a process? Now, without going into detail, you must have the following:
- – Update plan and procedures to check, execute and deploy updates both planned and ad hoc;
- – Invest time in deployment automation and test automation to make updating an automated and optimized process;
- – Assign tasks to people to perform them if necessary.
Much ado
If this sound like a lot of work, there’s of course always the possibility of using our Connext platform. This is a Platform as a Service and all these update aspects are taken care of, so you can just use the product without thinking about updates. Read more about the additional benefits of Connext.
