As we noted back in November, it’s common knowledge that keeping device software up to date and securely configured is important. System firmware, on the other hand, is often overlooked. Despite being critical to the secure operation of a device, it’s frequently out of date.
But how bad is the problem? How widespread? And what can be done to remedy the situation?
To answer these questions we decided to put our money where our mouth is and run some simple tests on one of our research networks. The goal was gain an accurate picture of the BIOS version running on all connected devices.
The results were a wake-up call. The firmware of devices running on our own network required some attention. This may be the case for you as well.
The Initial Aim
Before we get to the test results, and our subsequent fixes, it’s worth looking at the tests themselves in a little more detail.
We set out with a simple objective: Collect basic BIOS information for all the Windows laptops connected to our research network. Specifically, we were interested in discovering the BIOS version running on each device and the date it was released.
With this information we could determine whether devices were up to date. We could also investigate whether there were any known vulnerabilities to the BIOS version in operation.
Modus Operandi
In order to tackle the problem, we put together a simple script using PowerShell that searched end user devices across the Active Directory domain and returned selected properties of the Win32_BIOS class and Win32_ComputerSystem class for further analysis.
The full script can be found here. This gave us a set of data that could tell us the BIOS version and release date, alongside other basic information for every computer active within the domain.
Smelling the coffee
The results were a little dismaying. We found that 85% of the devices sampled were running an out of date BIOS and many were several versions behind the latest release.
We also identified that a few machines were potential candidates for the CVE-2015-2890 vulnerability, which involves a failure to enforce appropriate BIOS write protections after the device has been woken from sleep.
It’s got to be automated
These discoveries certainly hit home with us. We immediately took action to update the out-of-date devices.
Unfortunately, we did not have any infrastructure in place to automate this, so we had to do it manually – by checking the individual serial number of the devices on the manufacturer’s website to determine the latest BIOS available. The latest version then had to be downloaded and applied by hand. In our case we also had to remember to suspend BitLocker.
Whilst this process as a whole is not difficult, it is far from efficient and certainly not suitable for large enterprise networks where there could be thousands of devices to be securely managed .
Many of our customers have networks of this size. So, over the next few months, we’ll be looking for ways to manage networks at scale. We’ll be updating our EUD guidance with our findings when we’re done.
Conclusions
Whilst we succeeded in identifying and patching systems running an out of date BIOS on our small research network, our approach is still not ideal.
The major downside was that determining the status of the BIOS version reported back from our script was a manual process. In addition, we were reliant on end users downloading and performing the update.
Whilst this is feasible on a small research network, for a large enterprise, it’s not scalable. Therefore, in the coming weeks, we plan to focus on testing automation of BIOS updates, with a view to scaling this for large enterprise networks.
This will be the subject of a future blog post. In the meantime though, we would love to receive any comments on your own experiences or feedback below, either positive or negative.
Source: National Cyber Security Centre
