I recently had the opportunity to participate in Zebra’s Developer podcast hosted by Dan Quagliana and Mark Jolley from Zebra. I spoke a bit about some of our experiences dealing with deploying Software and OS Patches on Android devices in the Enterprise.
Listen to the full Podcast here:The following are some of the highlights and notes from the questions that I covered during the discussion:
Software Patch Cycles – “Do it more often to make it easier”
For software patch cycles on enterprise mobile devices, my experiences have formed a belief that companies should spend more time building capabilities that will support being able to patch software.
With the shift from Legacy Windows CE devices in the enterprise to modern Android and iOS devices, the risk exposure associated with un-patched devices has increased. A few of the key trends that I see contributing to this risk exposure include:
- Usage of cloud services – Historically, companies had put their line of business applications on servers that were located inside the corporate network (protected by their network controls and firewalls). Over the last 7 years we have seen more enterprises adopting cloud technology to help reduce infrastructure spend and increase scalability.
- External apps and libraries – Leveraging external libraries or applications can introduce additional vulnerabilities if not patched correctly. The Equifax breach in 2017 was related to a known vulnerability that went un-patched by the team running the application that was hacked.
- Wireless Usage – Before 2003, I observed very few mobile applications that we based on wireless. These legacy applications were designed to sync data at the beginning of the day from a cradle or wired connection. As wireless has become more prevalent, mobile devices and wifi networks have become a potential point of breach into your corporate infrastructure. The release of the KRACK patch in late 2017 was a good example of why it is necessary to patch devices.
A mindset change is needed to the way we did software 15 years ago. We need to get into a practice of working out our patching and updating process. Some of the best practices I would recommend implementing include:
- Planned Patch Cycles – Plan patches on at least a quarterly basis for planned OS patches or upgrades
- Repeatable Process – Build a process and team that can support updates and patches to your enterprise devices. Have the rigor and cadence to be able to handle standard patches and emergency patches.
- Involve Other Teams – Involve application teams in your planned regression. Confirm that they are reviewing the 3rd party libraries they are using for critical security updates.
- Involve the Finance Team – Budget for OS patches should be included as part of your annual maintenance costs.
Take a look at this blog post for more best practices around improving your upgrade and patching processes: https://bluefletch.com/blog/simplify-zebra-android-os-upgrades-by-embracing-them/
Usage of 3rd Party Library – “Stick with the big guys”
A bulk of applications in use today make use of 3rd party libraries (both open source and paid). These libraries reduce your application development times and improve the overall quality of your applications. But there are potential risks to using 3rd party libraries. Generally we look for libraries with the following criteria:
- Usage – If there is a lot of usage for a library, it is more likely to receive critical security patches.
- Size of Contributing Companies – Normally larger companies have the resources and bandwidth to make updates to libraries that they have created. Use trusted libraries from companies that are focused on maintaining and supporting the libraries.
- Longevity and Age – look for libraries that are not too new, but have had multiple updates since they were created.
Based on a review of our Enterprise Android Application, I Identified the following three vendors were the most common sources of our 3rd party libraries in applications:
- Google Android Arch Components
- Android Arch Examples
- Leveraging Google Maps
- Google github examples (note that some are not supported)
Square
Zebra
Understand risk of Updates. – “Change is Chance”
For the process of determining which updates to apply, I always force myself to think of the quote “Change is chance”. One of my former mentors would always tell this to a younger version of me whenever I would get excited about the newest and hottest technology or product update that I was considering having my team implement. The main take-way from this mentality is that you should be mentally performing a risk analysis of any changes you are considering making.
From a basic filtering perspective, if it doesn’t meet one of these criteria, don’t do it:
- Does it make your application meaningfully more secure.
- Does it substantially improve the business results of the application.
- Does it make the application substantially easier to support.
If you are planning on making changes to your applications or process. I do recommend thinking about the following processes to make it easier to reduce the amount of work for each of your
- Build Process / CICD – Be able to build all of your applications in a consistent manner. You should have a shared code repository, shared asset repositories, and a shared automated build box.
- Regression Testing – You should have at a minimum: a dedicated test environment that mirrors prod (or a region in prod), a consistent smoke test process for updated apps, a team that is capable of signing off on an updated build.
- Business Acceptance Testing – Have a process where the business stakeholders are able to review and accept applications updates before you send it to all devices.
- MDMs for Deployment – Use an MDM to control your deployments and deployment cadence. Expecting end users to install an application update will cause you problems. If you are using web based apps, have a Blue/Green method for selectively activating an updated application version for pilot sites.
- Pilot Process – Have a consistent process for piloting changes. A process should include pilot pre-requisites, communication process, feedback process, and roll-back process.
- Device Analytics – Be able to perform analytics of devices as you roll out application updates. You should be able to measure at a minimum: Devices reboots, battery consumption, network usage, application launch count, application crashes, and application usage time.
Next Steps
BlueFletch built a Zebra OS Update application from field experience to increase success rates via validations and checkpoints. We’ve also included helpful features such as smart downloading from multiple locations, power conditions, external logging and more.
If you would like more information about BlueFletch’s best practices around building and deploying enterprise mobile applications, reach out to us at: info@bluefletch.com
