Azure Sphere can do so many things across many domains, but Security is a deep domain, so vast it seems sometimes to impact every line of code ever written. Sometimes security is a big, bright, and showy focal point, other times it sits humbly away from the spotlights; you might not even notice it if you don’t peer into the shadows. Through this series, I intend to share our team perspective and insights to give some context around the work we’re doing for the MT3620.
In our 21.09 Azure Sphere OS, we’re shipping a kernel update to version 5.10.60. This update has no new features. So, why take the risk of making the change then?
Can a product be known to be secure? Or is a locked-down product one that just has not yet been exploited? Evidence suggests that security is not a binary state but a spectrum of how often and how long a product can establish trust and regain trust once it has been lost. The key difference is time—how long it takes to find and exploit unknown vulnerabilities and how trusted something can be over time. By updating the Azure Sphere OS kernel version, we’re lowering the risk of exploitation. This minor kernel update includes bug fixes and security patches, and its configuration is newer and less familiar to exploits that have been packaged for mass application.
Last year we ran a public Azure Sphere research challenge. During the challenge we received a couple of complaints from legitimately annoyed researchers. Though the challenge spanned several months, each month the researchers’ findings were patched, making it hard to string together multiple vulnerabilities into exploits that dig deeper into the system. We had to explain that Azure Sphere’s security isn’t based on one build of its OS. Regular updates are part of the security story of Azure Sphere; making changes that disrupt exploits isn’t a bug, it’s a feature. Azure Sphere’s security is designed to take into account. Changes, patches, fixes, and updates build up a product whose We’ve taken to heart any complaints from participants to better design future challenges that play to researchers’ strengths. But we continue to make updates available for operational devices, like this latest kernel update, because these changes are an essential part of our security story, a story that drives us to renew trust at every opportunity and every interaction with the platform.
Azure Sphere defense-in-depth features are designed to mitigate potential impacts. Nominally, by the time a proper exploit has been packaged, Azure Sphere devices will be on a newer version, through another update, maybe even several updates from now. Azure Sphere changes with time. I think that’s worth thinking about when it comes to security.
Microsoft
