tl;dr

We put our money where our mouth is and joined CISA’s Secure by Design program as the world’s first digital signage company to publicly commit to producing secure software. This article discusses Principle 1. Additional posts for Principles 2 and 3 will be published later.

Backstory

Every once in a while, you come across something that really resonates with your core values. For me, the most recent time this happened was when I came across CISA’s Secure by Design. At Screenly, we’ve been trying to lead the way in security since our inception. It is fair to say that we’re way ahead in the digital signage industry. Publicly committing to Secure by Design allows us to really put our money where our mouth is.

This is why we are very excited to be the first digital signage company to have signed CISA’s Secure Design Pledge. For those not familiar, the Cybersecurity and Infrastructure Security Agency (CISA) is a government agency under the Department of Homeland Security (DHS). The agency’s purpose is to advise both other government agencies and the industry on security best practices. This is the agency that is also lobbying for the use of Security Bill of Materials (SBOMs) as mentioned in the State of Security at Screenly - Ongoing Efforts and Improvements. However, Secure by Design is not just a US program; it is also a collaboration with the following agencies:

• Australian Cyber Security Centre (ACSC)
• Canadian Centre for Cyber Security (CCCS)
• Computer Emergency Response Team New Zealand (CERT NZ) and New Zealand’s National Cyber Security Centre (NCSC-NZ)
• Cyber Security Agency of Singapore (CSA)
• Czech Republic’s National Cyber and Information Security Agency (NÚKIB)
• Germany’s Federal Office for Information Security (BSI)
• Israel’s National Cyber Directorate (INCD)
• Japan’s National Center of Incident Readiness and Strategy for Cybersecurity (NISC) and Japan Computer Emergency Response Team Coordination Center (JPCERT/CC)
• Korea Internet & Security Agency (KISA)
• Netherlands’ National Cyber Security Centre (NCSC-NL)
• Norway’s National Cyber Security Center (NCSC-NO)
• OAS/CICTE Network of Government Cyber Incident Response Teams (CSIRT) Americas
• United Kingdom’s National Cyber Security Centre (NCSC-UK)

The core principles for Secure by Design are outlined in the whitepaper. In this article, we’ll go through our current assessment and what we are doing to improve.

This article is limited to “Principle 1”; additional posts will be published that focus on Principles 2 and 3.

Principle 1: Take Ownership of Customer Security Outcomes

This is something that really resonates with us. Some of the items in this list are really obvious, but it’s good that they are highlighted to ensure no corners are cut. Too many vendors (particularly in the world of digital signage) just push the burden of security onto their customers. While some savvy customers have the tools and infrastructure for doing this, the reality is that the vast majority will just deploy the devices on the network and call it a day. This cohort will either assume (incorrectly) that security is owned by the vendor or not be savvy enough to even entertain the problem space.

Secure by Default Practices

1. Eliminate default passwords

I can’t believe we’re still talking about this in 2024, but concerningly, many IoT devices are still shipped with default passwords.

None of our devices are shipped with default passwords. In fact, they don’t even have any open ports (see Security).

2. Conduct field tests

This one has a very noble purpose. In short, the goal is to understand how users are actually using a product versus how it was designed. For Screenly, we are taking a slightly different approach to this. Our goal is to raise the bar across the entire customer base. As such, we are planning to dive into the data and look at how users are using our security features. This will then be used in conjunction with “Implement attention-grabbing alerts” to drive the adoption of security features.

In the spirit of Secure by Design, we are also planning to publish statistics related to this.

Follow-up Action(s)

• Pull statistics and publish findings.

3. Reduce hardening guide size

Hardening guides are popular in enterprise software. Many of these are very long, complex, and convoluted. A good example of this is CIS Benchmarks. This is a 3rd party guide and applies to something as complex as an operating system, but is often considered somewhat of a gold standard for hardening guides.

The purpose of this sub-principle is to try to make these hardening guidelines less complex and convoluted by building security into the product and defaults, rather than being bolt-ons (a recurring theme in Secure by Design).

At Screenly, we have gone out of our way to make things secure by default. A good example of this is that we assume all our devices are deployed in hostile environments and make all our implementation decisions with this baseline. Much of this is inspired by the Zero Trust model. As such, our hardening guide has been largely communicated to customers in support tickets as it can be distilled down to a few bullet points.

To be compliant with Secure by Design, we’ve created an initial Hardening Guide.

4. Actively discourage the use of unsafe legacy features

The purpose of this feature is great, especially in legacy products. We are fortunate enough not to have many legacy features. While we will likely encounter that in the future, our plan is to use our in-app notifications to drive awareness.

What’s more current is device players with End-of-Life operating systems. Since we ship a complete solution, we own the management of the operating system. Subsequently, the onus is on us to notify the customer about deprecation.

Our primary goal is to take care of this on behalf of our customers. However, this isn’t possible for the Ubuntu Core 16 based devices. In newer versions, it is possible for us to remotely upgrade the operating system over the air (OTA), allowing us to take that burden away from our customers.

Follow-up Action(s)

• Implement notifications for devices approaching End-of-Life (EoL) in the operating system.

5. Implement attention-grabbing alerts

This is a good one. For us, this practically means a few things.

• We want to drive users towards either using SSO or enabling multi-factor authentication (MFA) through UI/UX nudges.
• Encourage the use of shared playlists as a security boundary.

Follow-up Action(s)

• Implement notifications and create content to highlight this.

6. Create secure configuration templates

This one is not super applicable for us at Screenly. Our devices are automatically hardened, and the main configuration for hardening lies in access control in our user interface, along with referencing the new hardening guide.

We have included this in the initial Hardening Guide.

Secure Product Development Practices

1. Document conformance to a secure SDLC Framework

The objective of this sub-principle is to ensure that the software is developed (and documented) securely. While we do not strictly adhere to NIST’s Secure Software Development Framework, we are confident that we’re in a good starting place.

Here’s a quick outline of what we are doing today:

• All our software goes through Pull Requests (PR) before it can get shipped. Each PR needs to be reviewed by two separate team members.
• All commits must be signed (usually using PGP/GPG, but GitHub’s new SSH signing is also allowed).
• All our software is built and deployed using our CI/CD pipeline both for our back-end and for our device software. No manual deployment is allowed anywhere in the pipeline.
• All PRs are automatically checked with static code analysis through SonarCloud.

Follow-up Action(s)

• Update our Security page with details on our current SDLC.
• Review NIST guidelines to see where there is room for improvement.

2. Document Cybersecurity Performance Goals (CPG) or equivalent conformance

This sub-principle deals with Operational Security (OpSec) among other things. Understanding the threat model is key, and we’ve already done exercises around this as part of our penetration tests (pentest). While there is room for improvement, the safeguards that we have in place (such as signed commits and code reviews) will help here. We also practice the Principle of Least Privilege when granting access to services internally, which reduces the attack vector.

Follow-up Action(s)

• Review our internal principles and aspire to align them with NIST’s Cybersecurity Framework (CSF) 2.0.

3. Vulnerability management

This sub-principle spans more than the title suggests. Doing vulnerability management is table stakes for anyone committing to Secure By Design. But let’s talk a little bit about how we do vulnerability management at Screenly.

Since all our source code and CI/CD lives in GitHub, this is where we also want our vulnerability management. One of the tools that we use for vulnerability management is Dependabot from GitHub. While it should not be seen as a panacea, it does pick up a lot of vulnerabilities in our dependency tree and makes remediation very quick and fast. As per our SOC 2 Type II compliance, we have an internal SLA for how quickly these vulnerabilities need to be resolved and deployed.

Beyond this, we are also using SonarCloud for automatic static code analysis, which again integrates directly into our code review process. If a violation is detected (such as a false positive), this needs to be justified as part of this process.

What we are planning to do next is to generate SBOMs for all our products, which will enhance our vulnerability management and give us greater visibility.

We are also exploring using more hardened Docker images (e.g., Chainguard) to reduce the attack surface further.

Follow-up Action(s)

• Adopt SBOMs across all our products.
• Explore using more hardened Docker images to reduce the attack surface.

4. Responsibly use open source software

This is a really good one. We, like most modern companies, rely heavily on open source in our products. We are also big fans of open source ourselves and publish a fair bit on our GitHub. Understanding the dependency tree of components can be a daunting task, but by generating SBOMs we will be in a better position to analyze and understand our footprint.

Understanding the current state of affairs is one thing, but we also need better guidelines for adopting new open source libraries. We need a way to quantify what we can use (both in terms of licensing) and to quantify the maturity of a project. Work is needed here to better establish a baseline for what this looks like, as it has largely been done on a per-case basis so far.

While we try to contribute to upstream projects, the reality is that we have limited resources to do this. However, we do try to ship patches upstream whenever we do patch open source software. An example of this is our JSON improvement to PostgREST.

Follow-up Action(s)

• Document the requirements for open source libraries that we can use.
• We have discussed an internal open source donation program where we will donate money to projects that we depend on (with a bias towards smaller projects).

5. Provide secure defaults for developers

This is an area where we have been actively working in the last few years, but there is lots of room for improvement in this domain (and there always will be). The three areas where we have identified ways to raise our security bar across various components in our software stack:

• Complete the migration to Python’s Django framework. We still have some legacy code that is yet to be migrated to Django/Django REST Framework (DRF). Completing this migration will give us more guardrails that allowed us to write less code but deliver a more secure product.
• We have also adopted PostgREST for strategic API endpoints, which is a RESTful framework that sits on top of PostgreSQL. We use this as a complement to our Django DRF APIs to not only get better performance for many of our API endpoints but also to benefit from PostgreSQL’s built-in Row-Level Access Control. By doing this, we have yet another safeguard against a whole category of attack vectors against our API and database.
• Rewriting our player stack to Rust. Historically, our software stack for our digital signage players was written in Python and QT (with some C++). We are currently rewriting the Python part in Rust. We are doing this to improve the security of our signage player, as well as to improve reliability and performance.

It’s also worth mentioning that we are big fans of workload isolation, as mentioned on our Security page. This is true both in our back-end where we use containers, but also on our digital signage devices, where we use Snaps.

Follow-up Action(s)

• Finalize migration to PostgREST/DRF of APIs.
• Finalize migration of the Python stack to Rust.

6. Foster a software developer workforce that understands security

This is important. As part of our company onboarding for developers, we review our internal OpSec guide. This covers everything you expect developers to understand, including our mandate for Full Disk Encryption (FDE), along with other security hygiene. While the documentation covers the basic training, along with our SOC 2 Type 2 mandated orientation, ongoing training is performed in the form of code reviews. This is where a lot of our ‘real world’ security training happens.

7. Test security incident event management (SIEM) and security orchestration, automation, and response (SOAR) integration

This is a good one. We have most of these building blocks in place, but more work is needed to get to the point where we are fully satisfied with the setup.

Follow-up Action(s)

• Perform testing and optimization with regards to Google Security Center.
• Configure alerts between Google Security Center and PagerDuty.

8. Align with Zero Trust Architecture (ZTA)

We’re big fans of Zero Trust. Over the last year, we’ve begun the migration of all of our digital signage devices to use Zero Trust (mTLS to be precise) for communication to our backend. When a new device comes online for the first time, a Certificate Signing Request (CSR) is issued. On devices that support it, the cryptographic operation is performed in the Trusted Platform Module (TPM) to ensure the private key is never written to disk.

For internal users accessing our systems, MFA is required in the form of a Yubikey (i.e., FIDO).

We would like to protect sensitive endpoints even further. Options to explore include Google Zero Trust, Cloudflare’s Access, and Tailscale.

Follow-up Action(s)

• Evaluate and expand our Zero Trust usage further.

Pro-security Business Practices

1. Provide logging at no additional charge

For some time, we have logged security-related application logs by default for all users. This is done using an append-only table in PostgreSQL to ensure these logs cannot be tampered with.

These logs are only exposed to Enterprise users by default but can be retrieved on behalf of any customer in the event of a security incident.

2. Eliminate hidden taxes

We fully agree with the theory behind this sub-principle, but the devil is in the details.

All our users are able to:

• Use Single Sign-On (SSO) with our supported SSO providers.
• Use 2FA (via TOTP).

3. Embrace open standards

We generally prefer open standards. Most of our communication is HTTPS-based. For identity, our mTLS implementation is heavily inspired by SPIFFE/SPIRE. No proprietary protocols have been invented and everything (with exceptions of things like NTP) is encrypted.

4. Provide upgrade tooling

This sub-principle is not super relevant for Screenly. Our signage players are automatically updated over-the-air (OTA). Our SasS service is offered hosted in the cloud, meaning that there is no customer workflow for these upgrades.

More to come

Stay tuned in the coming weeks as we will provide an update on Principle 2: Embrace Radical Transparency and Accountability.