We get a lot of requests to improve the management of new software versions for computers and servers. Product updates are needed to enhance security against ever evolving threats, fix bugs and add features. We appreciate that any changes come with risks, and so there is a balancing of the risk of changing against the risk of not changing.
Sophos Central has had the controlled updates feature for some time (documentation here), allowing admins to determine when software updates take place and try them on a set of test machines first.
You can read more about the replacement functionality in our documentation here. Once visible, the new areas of the Sophos Central admin interface can be found in global settings as a new page called “Software Packages” and also as an extra section in the existing “Update Management” policy.
We’re replacing controlled updates with a better alternative which will:
The software management improvements will move version management into the policy model. This allows as much flexibility as needed to set and change the software version assigned to sets of machines.
As well as supporting simple scenarios like testing a single version on one set of machines and then rolling it out to the rest of the estate, it facilitates more advanced scenarios like testing different potential upgrade versions in parallel, and rolling out to the whole estate in as many stages as needed.
Using the existing Sophos Central groups helps admins to use or reuse their existing logical groupings of devices.
All Central managed devices will support this new feature once complete later this year.Like controlled updates it will be compatible with Windows computers, Windows servers and Linux servers, and it will also add Mac support for the first time.
For customers who wish to continue to have the latest software available to them straight away on some or all machines, Sophos will continue to have a default “Sophos Recommended” path.
Sophos will manage the changing of versions on machines using this option, meaning no admin action is required.
We will introduce new package types (more below) where the responsibility will be for the customer to choose which software is installed and change it at the right time. Sophos will not change it, only add new package choices for the admin to decide whether and when to use it.
Once a new software component has completed its rollout successfully, we will produce a “Fixed Term Support Package” including it.
These fixed term packages will last for 120 days from release, the expectation being that this allows time for the next fixed term version to be released, admins to test they’re happy with it and then complete their rollout to all devices.
Please see the FAQs below for what happens at expiry.
We will also have Long Term Support (LTS) packages which will come out each year in April and last for 18 months (to allow 6 months for testing and roll out). These are intended for systems where there are very strict change control procedures such a critical web servers or point of sale terminals. Ideally systems would be updated more frequently, but if that is not possible these packages are available to accommodate those needs.
All customers will see the same list of fixed and LTS packages and they will have the same release and expiry dates. We will provide alerts for newly available versions to consider testing/using and also alerts when a package is approaching expiry and still in use.
We will also show the current component versioning for Sophos Recommended. Note that this is account specific as we roll out new Sophos recommended versions gradually across the customer base, so will not necessarily be the same in other accounts.
The version info will link to dedicated release notes pages with more details about changes.
We plan to add a new software health report showing details related to the software such as version, and whether there are any issues (e.g. updating problems, or a broken install). This will offer account-wide visibility of the software version and status.
We will be delivering this feature incrementally over the next several months.
Later this week we plan to release the first stage, which is the new package list view and extension of the update management policy type to be able assign software. We will have the first fixed term support package for Windows 10+ 64 bit computers available.
By late February/early March we expect to have the first Windows server fixed term support package, and then follow on in April with the first LTS packages for Windows computers and servers.
Support for 32 bit and older Windows versions is planned later in the second quarter of this year.
The reporting improvements and Mac and Linux support will be added incrementally later in the year once ready, likely in the 3rd quarter of the year.
“What are the best practises for testing/trying new versions?”
The key thing is to have a representative sample. If, for example, you only test on IT devices you may not identify an issue in advance that will affect an application that the Sales department uses. Ideally you would have a group of devices that span departments, types of user, geographies etc that you can put new software on to first to identify any issues without affecting most users. Most issues are apparent fairly quickly, so testing for a week or two should be sufficient. Making sure the users know they’re in the test group and how to contact the administrator ensures they can report issues reliably. Notifying them of software releases may associate unrelated issues to Sophos changes, so you are likely to get clearer correlation (negative or positive) if they know they are always in the test group, but not when the version is changing.
“What package type should I use?”
Generally, staying as up to date as possible gives you the latest features and improvements. So Sophos Recommended is best, then fixed term packages and then LTS packages. If you can’t stay on Sophos recommended, then trying to stay as up to date as possible on fixed term packages is best, i.e. staying on the newest fixed package and adopting it as early as possible.
Having some devices running Sophos recommended, and ideally even the Early Access Program version, is advisable to allow early identification of any issues. Waiting until a fixed package to spot a problem will leave less time to get issues addressed before expiry.
LTS packages are intended for systems with stringent change control, such as critical website servers or point of sale tills.
As an example of what this could look like:
Some devices in EAPs and others on Sophos Recommended. This allows early identification of any issues, allowing plenty of time for them to be addressed.
A small but representative sample using a newly released fixed term support package for 2 weeks to validate there are no issues
A majority of devices running the previous fixed term package until testing of the new one confirms there are no issues. This set of devices can then be gradually upgraded, leaving any more important devices until later in the process.
Critical devices with complex change control processes may need to be in a final set, using the LTS package and changing version each year.
“What about reboots”
Generally reboots after Sophos updates are not urgent and so a reboot, if needed, can usually wait until the system reboots for another reason. Generally we would expect Sophos updates to be less frequent that other key updates requiring reboots, particularly OS updates, and so aligning Sophos updates with those patch cycles should let Sophos updates make use of those existing planned reboots.
“how does this work with controlled updates if I’m using that already”
Devices set to use the “Sophos Recommended” package will continue to respect controlled updates. Any devices compatible with and set to use fixed term packages will ignore controlled udpates.
This means there is a simple migration path- you can continue to use controlled updates as long as needed, and can transition off by starting to use fixed term support packages (or LTS once available). Clients not yet compatible with fixed term packages will continue to use controlled updates until they are compatible.
“Does this work with scheduled updates as well?”
Scheduled updates let you pick a day and time of day to perform updates, e.g. Sunday at 3pm. Initially, changing package choice in policy will cause endpoints to switch immediately, but we plan to add support later for scheduled updates. For now, if you need to schedule updates for a specific time you can either continue to use controlled updates or change policy at the day and time you want updates to take place.
“What happens if I’m using a version that has passed its expiry date?”
Sophos recommended packages won’t expire; Sophos manage the changing of versions so that endpoints will always be on a supported version with no admin involvement needed. If you don’t use Sophos Recommended then the expectation is that you will manage versions correctly for your organisation. If you leave endpoints using an expired version they will not receive further updates but continue to run the protection they had in place. Generally this should be avoided, but it might be necessary e.g. if you need a few extra days to get out of a change freeze period.
You can’t newly pick expired versions in policy, but policies already set to use them will not change.
“What happens if a vulnerability is found in a package I’m using- will Sophos change it outside of my control?”
If a critical issue (e.g. a vulnerability) is identified in a package, we do not intend to remove it or change its expiry date, but instead create an additional “.1” version with the necessary fixes in and with the same expiry date. Customers will need to move their endpoints to the fixed version. We would encourage rapid transition but customers will decide the appropriate balance of risk and timeline for the change. This is more likely for LTS packages but could apply to fixed term support packages.
“Is a package a product, a component, an installer or something else?”
The package is a full set of the software any endpoint running any combination of licensed products might need. For example, they will all include the encryption management software even though not all customers license this. Endpoints will only download and install the relevant pieces they need, but the package in the download source will contain everything.
This could mean that a non-encryption customer see a new package has been made available, but it only contains the same components they are already running, because the only change is the encryption components.
You can see more detail on the component versions in the packages list view, and you can also read the release notes pages to understand changes in a version.
“What is the “add software” button for?
This is only needed if support tell you to use it, and they will provide instructions. This will be used where there is a version of software with a specific fix for an issue a customer is identified as having.
“What if a fixed term support package expires before the next one comes out?”
New fixed term support packages will be created with a 120 day lifespan before expiry. If needed, we can extend the expiry to ensure there is at least a 30 day overlap between versions to allow testing and roll out. For example, if there is only one version currently available and it is approaching 30 days to expiry, we will extend its expiry date to ensure there is always an in-date fixed term package available and there is at least 30 days of overlap with a newer replacement.