The Vision of DevOps for Devices, Part 4: Compliance and Security

Welcome to part four of our DevOps for Devices series, where we discuss what it means to adopt a DevOps philosophy in a device management context. Up to this point, we’ve covered how to manage by exception, automated drift management tools, and repeatable, reliable software delivery to edge devices. So, where do we go from here? 

To a favorite topic of ours: compliance and security. Let’s get to it by starting with a big question: What is compliance? 

What Do We Mean When We Say “Compliance?” How is Compliance Different from Security? 

If you already deal with compliance needs in your organization, then you know exactly what I’m talking about. For others, you are likely already “being compliant” in some way.

Depending on your industry and company, there are probably regulatory rules or compliance policies that you need to adhere to or enforce. Imagine a clinical trial setting where you are required to have the devices you deploy adhere to a certain set of rules. Any deviation from these rules might render a particular study invalid — or, at the very least, you will need to report to an authority when a deviation happens.

On the other hand, there are many rules that your company (or even your team) might want to enforce in order to achieve a certain goal with your fleet. Think of rules such as:

• A specific app should always be running on your device
• Only a certain set of ports can be used 
• The device should always be in kiosk mode, 
• Etc.

The most common reasons why you’d have these rules are for:

• Security: From this perspective, compliance is a security tool. It’s about ensuring your devices adhere to the best security practices and guidelines defined by your company (or authority). 
• User experience: From this angle, compliance ensures your devices enforce the ideal customer / user experience.

This is an important distinction as you think about compliance because people often associate compliance solely with security. And while that is a critical aspect of compliance enforcement, it’s not the only one! This is what I mean when I say you are most likely already “being compliant.”

Further, in regulated environments, there is often a compliance officer involved who will demand a report and perform audits of your adherence to policies. In this case, it is important to not only have the fleet compliant at any given time, but also to be able to obtain and deliver reports to the compliance officer.

Why Compliance Enforcement Is So Hard

Given the complex and nuanced nature of compliance as a concept, it’s not difficult to understand why compliance enforcement is a challenge. While we consider compliance enforcement non-negotiable, we also recognize that this is a weighted scale of importance, where you must enforce critical security functions at all costs while other things might be a little more lenient. 

That’s where the challenges of compliance enforcement start. For example, maybe you want to enable a company wallpaper during device provisioning to adhere to company standards. Is that something you want to enforce? Or simply enable once? That’s a question only you can answer. 

On the other hand, let’s say all of your devices at a given location have access to three different Wi-Fi networks, and you want to ensure they don’t connect to any other network for any reason. This is almost certainly a setting you want to strictly enforce all the time — no exceptions! 

And that’s just two scenarios. Multiply these complexities across every setting on every device, and suddenly, you have dozens (or even hundreds) of settings that need to be enforced — or don’t. That raises the question: Can you even enforce these settings? 

If you’re using Esper, then yeah, of course you can! You can make policy enforcement a blanket setting or granularly control every setting and option. The importance of your company’s policies is for you to decide, so we built a way to give you complete control. But we can take it a step further. 

Automated Compliance Enforcement = Reliable Security and Predictable Experiences

Now that we’ve established the need to enforce compliance with varying levels of importance, you might be wondering how to actually do that. On the Esper platform, we enable granular policy enforcement through our Blueprints feature (which you should be somewhat familiar with if you read the first three posts from this series!) with “when to apply” options for every setting. 

In short, this allows you to define when the specific setting is enforced — either during provisioning, always, or never. It’s the most straightforward way to control policy enforcement at scale. This way, you can strictly enforce your Wi-Fi allow list, but only push the wallpaper at provisioning (if you so choose). Check out this post to learn more about “when to apply” on Blueprints. 

But now’s when compliance enforcement gets, dare we say, fun? Using these settings, you essentially automate the process! Sure, you could manually check each setting daily, weekly, or monthly, but why bother? You can simply use the “always apply” setting and have these settings automatically re-applied every time you converge the Blueprint. Talk about a time saver! 

This gives you precise, granular control of every setting on every device in your fleet, which legitimately changes the game. 

Looking to the future, think about more granular drift management options. You could get notified when a device drifts from any single desired setting, and be able to automatically remediate it! In addition, the ability to automatically generate drift reports for auditors and compliance officers could make compliance audits a cinch! You could even define separate reports as needed and then have them automatically generated on a regular schedule. We’re not quite there yet, but that should give you an idea of some of the potential we see for advanced capabilities. 

It All Comes Full Circle

This brings us back to the beginning: managing by exception and automated remediation — two core concepts we covered in parts one and two of this series! When you can rely on drift detection to help you manage by exception, and automated remediation to strictly enforce the policies, you just achieved device management nirvana. Think about it: a self-healing device fleet that requires very little oversight and limited manual intervention. Bliss. 

And, if you’ll allow me to future-cast a bit, we could take “self-healing” to another level — what if your device fleet could also self-diagnose and preemptively perform a series of actions based on predicted behavior? For example, let’s say a device loses Wi-Fi connectivity. An automation might include toggling airplane mode after five minutes without a connection. If that doesn’t work, the device could reboot. 

To go one level deeper, what if the device could “understand” if it’s the only one affected by having localized information about other devices on the same network? If all of the devices on the network lose Wi-Fi connectivity around the same time, the device could “understand” that this is likely a network-wide outage and not an issue with the device itself. 

This is where the power of AI comes in — both in the Esper platform and on the edge! Lots of great stuff happening there that I’ll cover in my next post! The world is our oyster now!

Stay tuned for the next (and final) piece in this series, where we’ll discuss AI on edge devices. It's curious timing. 😉