Announcing the Firmware Analysis Public Preview
Consider an organization with thousands of smart sensors, IoT/OT and network equipment deployed on factory floors. Most of these devices are running full operating systems, but unlike traditional IT endpoints which often run security agents, IoT/OT and network devices frequently function as “black boxes”: you have little visibility into what software they’re running, which patches are applied, or what vulnerabilities might exist within them. This is the challenge many organizations face with IoT/OT and networking equipment - when a critical vulnerability is disclosed, how do you know which devices are at risk? To help address this challenge, we are excited to announce the public preview of firmware analysis, a new capability available through Azure Arc. This extends the firmware analysis feature we introduced in Microsoft Defender for IoT, making it available to a broader range of customers and scenarios through Azure. Our goal is to provide deeper visibility into IoT/OT and network devices by analyzing the foundational software (firmware) they run. Firmware analysis will also help companies that build firmware for devices better meet emerging cybersecurity regulations on their products. In this post, we’ll explain how the service works, its key features, and how it helps secure the sensors and edge devices that feed data into AI-driven industrial transformation. Securing Edge Devices to Power AI-Driven Industrial Transformation In modern industrial environments, data is king. Organizations are embracing Industry 4.0 and AI-driven solutions to optimize operations, leveraging advanced analytics and machine learning. The path to AI-driven industrial transformation is fueled by data – and much of that data comes from sensors and smart devices at the edge of the network. These edge devices measure temperature, pressure, vibration, and dozens of other parameters on the factory floor or in remote sites, feeding streams of information to cloud platforms where AI models turn data into insights. In fact, sensors are the frontline data collectors in systems like predictive maintenance, continuously monitoring equipment and generating the raw data that powers AI predictions. However, if those edge devices, sensors, and networking equipment are not secure and become compromised, the quality and reliability of the data (and thus the AI insights) cannot be guaranteed. Vulnerable devices can also be used by attackers to establish a foothold in the network, allowing them to move laterally to compromise other critical systems. In an industrial setting this could mean safety hazards, unplanned downtime, or costly inefficiencies. This is why securing the smart devices and networking equipment at the foundation of your industrial IoT data pipeline is so critical to digital transformation initiatives. By using firmware analysis on the devices’ firmware before deployment (and regularly as firmware updates roll out), the manufacturer and plant operators gain visibility into the security posture of their environment. For example, they might discover that a particular device model’s firmware contains an outdated open-source library with a known critical vulnerability. With that insight, they can work with the vendor to get a patched firmware update before any exploit occurs in the field. Or the analysis might reveal a hard-coded passwords for maintenance account in the device; the ops team can then ensure those credentials are changed or the device is isolated in a network segment with additional monitoring. In short, firmware analysis provides actionable intelligence to fortify each link in the chain of devices that your industrial systems depend on. The result is a more secure, resilient data foundation for your AI-driven transformation efforts – leading to reliable insights and safer, smarter operations on the plant floor. Firmware analysis is also a key tool used by device builders – by analyzing device firmware images before they are delivered to customers, builders can make sure that new releases and firmware updates meet their and their customers’ security standards. Firmware analysis is a key component to address emerging cybersecurity regulations such as the EU Cyber Resilience Act and the U.S. Cyber Trust Mark. How Firmware Analysis Works and Key Features Firmware analysis takes a binary firmware image (the low-level software running on an IoT/OT and network device) and conducts an automated security analysis. You can upload an unencrypted, embedded Linux-based firmware image to the firmware analysis portal. The service unpacks the image, inspects its file system, and identifies potential hidden threat vectors – all without needing any agent on the device. Here are the main capabilities of the firmware analysis service: Identifying software components and vulnerabilities: The first thing the analysis does is produce an inventory of software components found inside the firmware, generating a Software Bill of Materials (SBOM). This inventory focuses especially on open-source packages used in the firmware. Using this SBOM, the service then scans for known vulnerabilities by checking the identified components against public Common Vulnerabilities and Exposures (CVEs) databases. This surfaces any known security flaws in the device’s software stack, allowing device manufacturers and operators to prioritize patches for those issues. Analyzing binaries for security hardening: Beyond known vulnerabilities, our firmware analysis examines how the firmware’s binaries were built and whether they follow security best practices. For example, it checks for protections like stack canaries, ASLR (Address Space Layout Randomization), and other compile-time defenses. This “binary hardening” assessment indicates how resistant the device’s software might be to exploitation. If the firmware lacks certain protections, it suggests the device could be easier to exploit and highlights a need for improved secure development practices by the manufacturer. In short, this feature acts as a gauge of the device’s overall security hygiene in its compiled code. Finding weak credentials and embedded secrets: Another critical aspect of the analysis is identifying hard-coded user accounts or credentials in the firmware. Hard-coded or default passwords are a well-known weakness in IoT devices – for instance, the Mirai botnet famously leveraged a list of over 60 factory-default usernames and passwords to hijack IoT devices for DDoS attacks. Firmware analysis will flag any built-in user accounts and the password hash algorithms used, so manufacturers can remove or strengthen them, and enterprise security teams can avoid deploying devices with known default credentials. Additionally, the firmware analysis looks for cryptographic materials embedded in the image. It will detect things like expired or self-signed TLS/SSL certificates, which could jeopardize secure communications from a device. It also searches for any public or private cryptographic keys left inside the firmware – secrets that, if found by adversaries, could grant unauthorized access to the device or associated cloud services. By uncovering these hidden secrets, the service helps eliminate serious risks that might otherwise go unnoticed in the device’s software. All these insights – from software inventory and CVEs to hardening checks and secret material detection – are provided in a detailed report for each firmware image you analyze. Firmware analysis provides deep insights, clear visibility, and actionable intelligence into your devices' security posture, enabling you to confidently operate your industrial environments in the era of AI-driven industrial transformation. Getting Started and What’s Next If you have IoT/OT and network devices in your environment, use firmware analysis to test just how secure your devices are. Getting started is easy: access firmware analysis public preview by searching on “firmware analysis” in the Azure portal, or access using this link. In the future, firmware analysis will be more tightly integrated into the Azure portal. Onboard your subscription to the preview and then upload firmware images for analysis - here is a step-by-step tutorial. The service currently supports embedded Linux-based images up to 1GB in size. In this preview phase, there is no cost to analyze your firmware – our goal is to gather feedback. We are excited to share this capability with you, as it provides a powerful new tool for securing IoT/OT and network devices at scale. By shedding light on the hidden risks in device firmware, firmware analysis helps you protect the very devices that enable your AI and digital transformation initiatives. Firmware is no longer just low-level code—it’s a high-stakes surface for attack, and one that demands visibility and control. Firmware analysis equips security teams, engineers, and plant operators with the intelligence needed to act decisively—before vulnerabilities become headlines, and before attackers get a foothold. Please give the firmware analysis preview a try and let us know what you think.Automatic IoT Edge Certificate Management with GlobalSign EST
(Republish from Feb 15, 2023) When it comes to managing IoT devices, security is of the utmost importance. But you’d also rest easier if devices are secure without concern about manual certificate management. In this post, we'll show you a solution that streamlines IoT Edge certificate management using GlobalSign's IoT Edge Enroll EST service. An Analogy Think of each IoT Edge device as a new driver, ready to hit the road and communicate with the IoT Hub. And like a new driver, each device needs its own set of credentials that need renewal. Here's how GlobalSign's EST service makes it a breeze: Birth Certificate: During manufacturing, each device is given a unique Initial Device Identifier (IDevID) certificate and private key (ideally, something like Trusted Computing Group’s (TCG) Trusted Platform Module’s (TPM) Endorsement Key (EK) certificates with factory burnt secured hardware backed private keys). This is like the device's birth certificate, proving its identity. Driver's License: When the device connects for the first time, it uses its IDevID to authenticate with GlobalSign for certificate signing request (CSR). In return, GlobalSign provides a short-lived Locally Significant Device Identifier (LDevID) certificate from a trusted root CA. This LDevID acts as the device's driver's license, allowing it to operate for some time. The LDevID serves as the device's unique identifier in IoT Hub, registered through Device Provisioning Service (DPS). Automatic Renewal: To make sure your devices never lose their communication privileges, IoT Edge automatically renews the LDevID certificates before expiration. Like a driver license renewal, but automated! By using GlobalSign's EST service, you can enjoy secure certificate management for your IoT Edge devices. It's like having a personal assistant renewing your driver's license for you. Give it a try to start streamlining your IoT Edge certificate management. Prerequisites An IoT hub and Device Provisioning Service linked to it. A GlobalSign demo account: Sign up for Test Your Azure IoT Edge PoC with live device certificates from GlobalSign's IoT Edge Enroll. You'll receive an email with details for your EST server endpoint within a few days, including three endpoints (IDevID, LDevID, and Edge CA). Reply to the GlobalSign contact and ask to: Enable X.509 authentication (mTLS) for both the LDevID and the Edge CA endpoints Turn off “re-enrollment forcing” (the default behavior with GlobalSign IoT Edge Enroll is that it notices that a previously issued certificate was presented and "upgrade" the request to the reenrollment workflow. This overrides the subject CN to be the same as the previously issued certificate. Typically, customers would use a separate CA for the bootstrap/idevid, so in practice this outcome usually wouldn't be seen. But for simplicity of this post, it’s easier to ask GlobalSign to respect the certificate signing request (CSR) and not perform the “upgrade”). Linux machine, VM, or device with IoT Edge installed: Don't provision the IoT Edge device identity. Create the IDevID In this section, we create the IDevID certificate, which serves as the device's birth certificate. It’s a one-time process that occurs during device manufacturing, and ensures that the initial secret value for first-time authentication to GlobalSign never leaves the factory. Later, when the device wakes up, it will use the IDevID certificate to get a driver's license, or the LDevID certificate. On your local machine or SSH into the IoT Edge device, create directories to store certificates and private keys for IoT Edge and assign ownership of these directories to the "aziotcs" certificate service and "aziotks" key service. sudo mkdir -p /var/aziot/secrets sudo mkdir /var/aziot/certs -p Retrieve the GlobalSign demo root CA certificate with curl and convert it to PEM format using openssl. This certificate serves as the common root of trust between IoT Edge, GlobalSign, and DPS (and thus IoT Hub). curl https://<YOUR-IDEVID-ENDPOINT>.est.edge.dev.globalsign.com:443/.well-known/est/cacerts| openssl base64 -d | openssl pkcs7 -inform DER -outform PEM -print_certs | openssl x509 -out globalsign-root.cert.pem Use openssl to create a new private key and certificate signing request (CSR). openssl req -nodes -new -subj /CN=IDevID -sha256 -keyout IDevID.key.pem -out IDevID.csr Send the CSR to GlobalSign's simple enroll EST endpoint using curl, to obtain the IDevID certificate that is signed with the root CA and paired with the private key created earlier. curl -X POST --data-binary "@IDevID.csr" -H "Content-Transfer-Encoding:base64" -H "Secret-Value: <YOUR-SECRET-VALUE>" -H "Content-Type:application/pkcs10" https://<YOUR-IDEVID-ENDPOINT>.est.edge.dev.globalsign.com:443/.well-known/est/simpleenroll | openssl base64 -d | openssl pkcs7 -inform DER -outform PEM -print_certs | openssl x509 -out IDevID.cert.pem Move the certificates and private keys to the directories you created earlier, and give the IoT Edge certificate and key services the appropriate permissions to the PEM files and directories. sudo cp *cert.pem /var/aziot/certs sudo cp *key.pem /var/aziot/secrets sudo chown aziotcs:aziotcs /var/aziot/certs/*.cert.pem sudo chmod 644 /var/aziot/certs/*.cert.pem sudo chown aziotks:aziotks /var/aziot/secrets/*.key.pem sudo chmod 600 /var/aziot/secrets/*.key.pem sudo chown aziotcs:aziotcs /var/aziot/certs sudo chmod 755 /var/aziot/certs sudo chown aziotks:aziotks /var/aziot/secrets sudo chmod 700 /var/aziot/secrets Use the ls command to verify that the files are in place with the proper permissions and match the expected values. $ sudo ls -lR /var/aziot /var/aziot: total 8 drwxr-xr-x 2 aziotcs aziotcs 4096 Jan 11 14:38 certs drwx------ 2 aziotks aziotks 4096 Jan 11 14:38 secrets /var/aziot/certs: total 8 -rw-r--r-- 1 aziotcs aziotcs 1298 Jan 11 14:38 IDevID.cert.pem -rw-r--r-- 1 aziotcs aziotcs 1383 Jan 11 14:38 globalsign-root.cert.pem /var/aziot/secrets: total 4 -rw------- 1 aziotks aziotks 1704 Jan 11 14:38 IDevID.key.pem Prepare DPS for provisioning Here's how to get DPS ready for device provisioning: If you haven’t already done so, create an IoT hub and DPS, then link them together. Go to the DPS instance in Azure portal, then select Certificates > Add. In the pop-up, select your GlobalSign EST root CA certificate. You can use SFTP, VS Code Remote Extension to copy it from the IoT Edge device, or use curl to get it again. Select Set certificate status to verified on upload so that you can skip proof-of-possession. Click Save. Create a DPS enrollment group. Make sure attestation type is set to Certificate, IoT Edge device is set to True, certificate type is set to CA Certificate, and the root CA you just uploaded is set as the Primary Certificate. Now, your DPS is ready to provision the IoT Edge device when it wakes up, using the root CA certificate as the trusted source of authentication. Configure and start the IoT Edge device In this section, we set up the IoT Edge device with its birth certificate (IDevID) to communicate with the GlobalSign EST server and receive its driver license (LDevID). The LDevID allows the device to talk to DPS and get the proper authorization for communication with IoT Hub. On the IoT Edge device, create a config file config.toml. Replace marked parameters with details from your GlobalSign account and DPS. # The CA cert of the demo root we got from earlier [cert_issuance.est] trusted_certs = ["file:///var/aziot/certs/globalsign-root.cert.pem"] # Empty because the LDevID (device ID) and Edge CA endpoints are different [cert_issuance.est.urls] # Use the IDevID cert and private key for authentication to EST [cert_issuance.est.auth] identity_cert = "file:///var/aziot/certs/IDevID.cert.pem" identity_pk = "file:///var/aziot/secrets/IDevID.key.pem" # DPS provisioning with X.509 certificate # Replace with ID Scope from your DPS [provisioning] source = "dps" global_endpoint = "https://global.azure-devices-provisioning.net" id_scope = "<DPS-ID-SCOPE e.g 0AB12345678>" [provisioning.attestation] method = "x509" registration_id = "my-device-id" # Get LDevID (device ID) cert from EST with auto renew [provisioning.attestation.identity_cert] method = "est" common_name = "my-device-id" url = "https://<YOUR-LDEVID-ENDPOINT>.est.edge.dev.globalsign.com:443/.well-known/est/" [provisioning.attestation.identity_cert.auto_renew] threshold = "80%" retry = "4%" # Get Edge CA from EST also with auto renew [edge_ca] method = "est" url = "https://<YOUR-EDGE-CA-ENDPOINT>.est.edge.dev.globalsign.com:443/.well-known/est/" [edge_ca.auto_renew] threshold = "80%" retry = "4%" Copy the file over as root and apply configuration with iotedge config apply. This also starts the IoT Edge device. sudo cp config.toml /etc/aziot/config.toml sudo iotedge config apply Verify that the configuration was successful by using the iotedge check command. You should see successful checks on the connection with DPS and the status of certificates and keys. You can also check in your DPS Enrollment Group > Registration Records or IoT Hub to see that the IoT Edge device is registered (shown below). Note: if you haven’t configured an IoT Edge deployment, you might see an error about edgeHub container being missing in iotedge check and a 417 in IoT Hub. That’s normal until you add the deployment via Set modules. On the device, check the new certificates from the EST server. In the "/var/lib/aziot/certd/certs" directory, you should see three different certificates starting with "estid", "aziotedgeca", and "deviceid". Use OpenSSL to inspect them. Note: the certificate names are randomly generated, use "ls" to find their names and paste them into the OpenSSL command. sudo ls /var/lib/aziot/certd/certs sudo openssl x509 -text -in /var/lib/aziot/certd/certs/estid-<GUID>.cer sudo openssl x509 -text -in /var/lib/aziot/certd/certs/aziotedgedca-<GUID>.cer sudo openssl x509 -text -in /var/lib/aziot/certd/certs/deviceid-<GUID>.cer sudo openssl x509 -in /var/aziot/certs/IDevID.cert.pem -text | head -n 10 That’s it! When the time (80% to expiration) comes, IoT Edge will automatically renew both the device ID and the Edge CA certificates without manual intervention. Simplify IoT Edge Security This blog showed how to configure IoT Edge devices for secure communication using X.509 certificates without the need for manual certificate management. By using this approach, organizations can securely and efficiently manage their IoT Edge devices at scale, streamlining device enrollment and reducing the risk of security breaches. To adapt the example to fit your needs, consider the following: Security level: Your security requirements may vary based on your use case. Consider whether a unique IDevID certificate per device is necessary or if sharing the same certificate among multiple devices is acceptable. It's important to never store the initial EST secret value on the device in plaintext. Comprehensive security: For a more robust security approach, refer to The blueprint to securely solve the elusive zero-touch provisioning of IoT devices at scale | Azure. Dev/test scenarios: IoT Edge also supports basic authentication (username/password) for EST servers. To Restart If you need to restart midway through, stop the IoT Edge service first, delete any certificates and keys that were generated, reapply the config, and restart IoT Edge. sudo iotedge system stop sudo sh -c "rm /var/lib/aziot/certd/certs/*" sudo sh -c "rm /var/lib/aziot/keyd/keys/*" sudo cp config.toml /etc/aziot/config.toml sudo iotedge config apply sudo iotedge system logs -- -fPowering the next generation of Digital Transformation with Windows IoT and Azure Kubernetes Service
As edge computing becomes mainstream and a key strategy for enterprises to enhance their operations digitally, they require a reliable and comprehensive technology platform to fuel their ambitious goals. This platform needs to support a heterogenous device and cloud environment which enables running, deploying, and managing cloud-native applications. Microsoft is at the forefront of understanding evolving customer needs in this space and is providing solutions like Azure Kubernetes Service (AKS) Edge Essentials to run modern containerized applications on embedded devices running Windows operating systems. This blog explores the latest updates for these products and how they provide a rich platform for customers and partners to build intelligent, secure, cloud-native edge solutions with enterprise-grade security, reliability, and manageability.Bring all your workloads to the edge with AKS Edge Essentials. Now Generally Available!
Announcing the General Availability (GA) of Azure Kubernetes Service (AKS) Edge Essentials! AKS Edge Essentials has been developed as a managed Kubernetes for the operational edge on small-footprint devices to orchestrated workloads and drive business optimization.
