Security is one of those things that most people don’t think about until it is too late and they’re left with a mess to clean up. At best, you’ll get a slap on the wrist from your boss, and at worst, you’re left with a costly PR problem that will linger for years to follow.
Since most people don’t get out of bed in the morning thinking about security (I’m one of the oddballs that do), let’s debunk a few common myths to save digital signage buyers from a potential security disaster.
“We offer bank-level security”
You often come across this phrase when web services are describing their security efforts. Now, don’t get me wrong, banks are regulated and need to adhere to very strict compliance rules.
However, this is rarely what this tagline references. More often than not, this description is used when they use TLS/SSL encryption for data in transit. That “security language” might sound impressive to a layman, but it really shouldn’t be. This blog has “bank-level security” too, as do most modern websites. If your address starts with “https://” instead of “http://”, you too offer “bank-level security.”
“Not exposing devices to the internet makes them more secure”
A long time ago, this was considered best practice. Times have changed, but many companies (particularly traditional enterprises) haven’t kept up.
The logic goes as follows: if the device can’t communicate with the internet and/or is isolated on a separate network, the device is more or less unhackable.
At face value, this might seem reasonable. However, this also means that these devices are most likely not receiving any security updates and are thus most likely vulnerable to an increasing number of attacks as the months pass by. What happens when the network is accidentally connected to another network or an attacker plugs their laptop into the network? Game over.
Modern security practice dictates that you should assume the worst possible scenario, meaning that the device should not only be able to connect to the internet but also should be exposed on the public internet. This philosophy comes from the Zero Trust movement that Google started when they overhauled how they secure their entire internal IT infrastructure. Today, this overhaul means they don’t even use VPNs to access internal services, but that’s a bigger topic for another article.
At Screenly, we’ve adopted this approach. Our digital signage players are assumed to be in a ‘hostile’ environment, and we’ve designed all the security around our players accordingly. (You can read more about this on our security page.)
“On-prem is more secure than cloud”
Some companies take pride in running everything “on-prem” (usually meaning on servers in their office somewhere) rather than in the cloud. The arguments are much like the arguments for isolating devices.
On-prem servers are generally considered less secure than cloud-based infrastructure for several reasons. First, the physical location of on-prem servers means that they are vulnerable to a wide range of risks, including natural disasters, theft, and unauthorized access. Additionally, maintaining and securing on-prem servers requires significant time, effort, and expertise.
Cloud providers like Google and Microsoft have armies of world-class Site Reliability Engineers (SREs) who are responsible for managing and maintaining their cloud infrastructure. These SREs have extensive experience in designing and implementing security measures, monitoring for potential threats, and responding to incidents quickly and effectively. This level of expertise and attention to detail is difficult, if not impossible, to replicate for an on-prem operation. As a result, organizations that opt for cloud-based infrastructure can benefit from the expertise and resources of these dedicated security teams, which ultimately enhances their systems’ overall security and reliability.
Why people argue for on-prem over cloud often really boils down to something completely different: job security. Someone argued for running things in-house some time ago, and now they need to justify their job. Don’t confuse this with security.
“We’re ISO27001/SOC2, so our security is stellar”
Don’t get me wrong, there are a lot of good things in both ISO27001 and SOC2, and any company going through the certification process will have to ask itself a lot of great questions about how various processes are performed (such as backups and disaster recovery), and then make them document this.
This self-reflection is great, and I’m in no way saying these certificates don’t matter. However, they are mostly about processes for running your technical operations with some security sprinkled over it.
For users who really are looking for security, look at NIST, for instance. This has a far bigger focus on real security.
So what should I be looking for as a buyer?
The problem with security is that you need to understand security in order to assess if something is or isn’t secure. Thus, it is hard for non-security-oriented buyers to assess a vendor’s security posture. This reality is why things like ISO27001 or SOC2 are often used as a proxy for security.
To help with this, I’ve created a quick checklist that can be used when assessing the security of a potential vendor.
How and when are updates and security updates performed?
There are two things to consider regarding updates: application updates (i.e. the digital signage software) and the operating system itself (e.g. Linux or Windows).
A term you will frequently run into when talking about updates is “over-the-air” (frequently abbreviated OTA) updates. This term simply means that the devices themselves will automatically receive updates over the internet. An example is how your phone will automatically (at least Apple devices) update at night when a new security update comes along.
If the proposed vendor doesn’t offer automatic OTA and instead requires you to do some manual intervention to update the operating system and/or software, you should move on. You’re dealing with a legacy vendor that is yet to see the light. What you want is automatic updates of both the operating system and software during a maintenance window (normally during the night local time) to minimize the operational impact.
Beyond this, you need to also inquire about how updates are downloaded and applied. A common attack vector for IoT devices is to try to inject a “rogue update” with a backdoor by abusing the update mechanism.
To mitigate this, most sophisticated vendors will send their updates over an encrypted channel (remember “bank-level security”) and cryptographically sign these updates. Thus, even if an attacker somehow manages to sneak in an update, the system should reject the update.
You might also want to make sure that the updates for both the operating system and software are what’s called “transactional.” This term means that if an upgrade fails for whatever reason, the device will automatically revert to the last known “good state” such that the device resumes normal operations until the next update attempt.
Are you using Secure Boot?
Secure Boot is a feature that most operating systems support. In simple terms, this means that if the operating system has been tampered with, the system will refuse to boot. This is important because it removes a lot of avenues for a potential attacker (such as rogue kernel modules).
Do you support device encryption?
Device encryption is mostly important if you are storing sensitive data (e.g. credentials to dashboards) or sensitive content on the digital signage players. If you are only displaying public content in a store front, you can safely skip this section.
This is an area where there is a lot of vaporware. A lot of vendors will say that they have ‘device encryption,’ but it won’t really hold up to proper scrutiny. The reality is that unless the device has a Trusted Platform Module (TPM) and this is used for the disk encryption, it’s probably vaporware.
The way encryption works is that you need a key (or passphrase) to unlock the encryption. This is the primary objective of a TPM. The TPM will perform these operations without leaking the actual key to what’s called user space (roughly speaking what’s running on the device). This rules out a lot of players, such as the Raspberry Pi (which is why we offer the Screenly Player Max).
If this key is stored anywhere other than in the TPM, the encryption is essentially void. Many operating systems support what’s called Full Disk Encryption (FDE). If FDE is used, with the TPM storing the key, this is more or less the north star for device encryption.
It’s also possible to encrypt partial things on the disk using the TPM (say secrets for accessing a dashboard), but this is where it gets a bit more complicated.
What is the operating system life cycle?
Every digital signage player needs to run on an operating system. In 99.9% of the cases, this is either a direct version, or slightly modified version, of something like Android, Windows or some flavor of Linux. Nobody writes their own operating system (unless you’re Google). Thus every digital signage vendor will have an operating system vendor that they may or may not have a commercial agreement with.
Every operating system has what’s called a life cycle. This means that the operating system vendor will support this operating system for a certain period of time. In most cases, this is something like five years from release, but can in some cases be longer. In the case where it is longer, this is frequently referred to as a Long Time Support (LTS) release. Once this is up, you’ll reach what’s called the End of Life (EoL) of the operating system. After the EoL date, the operating system vendor will stop providing security updates. You can see an example of this in action on the Ubuntu Release Cycle page.
Android devices (in particular budget ones out of China) are notirous for being sold close to, or after, the end of the maintenance window. As of this writing, anything older than Android 11 (“Red Velvet Cake”) is unsupported by Google, and thus will not receive any security updates. You can find the the release cycles for Android here.
The reason why this is important to know is that it has a big impact on your deployment. Imagine this, you’re rolling out several thousand screens, but the EoL is just a year or two away. This means that once this has passed, you’re on your own. The operating system vendor did their part of the deal. Now you’re left hanging.
In some cases you can pay (usually vast sums) to extend the life cycle of an operating system, but unless you have huge operations and are unable to upgrade for whatever reason, this is unlikely to be financially viable.
It’s very important to understand this before you roll out your devices. Otherwise you might be stuck with either outdated software or needing to manually upgrade all your devices before they are due to be replaced. In either case, it can be a costly endeavor.
Note that your digital signage vendor can’t magically extend the life cycle of the operating system (unless they have enormous engineering resources to back-port security updates, or are paying the operating system vendor for an extended life cycle).
Can you enforce 2FA/MFA for the web interface?
This should really be table stakes today, but it should go without saying that two/multi factor authentication (2FA/MFA) should always be used for accessing the web interface. Better yet, use Single Sign On (SSO) or SAML and make sure you have your policies defined in your authentication provider.
Most vendors should be able to support common platforms such as Google or Azure.
When was your last pentest?
The only proper way to independently assess the security posture of a service is by performing an independent penetration test, commonly known as a “pentest,” by a reputable industry player.
A pentest is when a company is paid to try to break into a system and then provide a report on their findings. Normally, a follow-up test is performed once the company has had the time to resolve the issues outlined.
The scope and scale of a pentest will vary a lot depending on the “rules of engagement” (meaning what attack vectors and targets the hacker-for-hire is allowed to go after). At minimum, this pentest should cover the company’s web infrastructure, but it should ideally also cover the digital signage players itself along with “social engineering” attacks on the company’s staff and facilities.
Because these pentests can vary a lot, the price for a pentest ranges from a few thousand up to 100s of thousands (or more). As such, it would be unrealistic for a smaller vendor to perform a fully extensive test that covers all avenues.
There are a number of services that can perform “automated pentests.” These will not be nowhere as extensive as a manual test, but is a good starting point for even a smaller vendor.
That’s a wrap
Hope these pointers were helpful. We’ve barely scraped the surface of security, but by asking a potential vendor the above questions should help you differentiate vaporware from proper security.
