Keyfactor Leaders Give Their Take on the White House’s National Security Strategy

Last month, the White House released the Biden Administration’s National Cybersecurity Strategy. The nearly-40-page document identifies five key pillars for meeting the security demands, challenges, and threats of the future.

Largely, the strategy aims to align government, public, and private sectors behind innovations in security in hopes of raising the regulatory bar for security, encouraging security by design, and positioning the U.S. to thrive in a post-quantum world. 

To parse the document, we sat down with Keyfactor CTO Ted Shorter, Chief PKI Officer Tomas Gustavsson, and VP of Software Engineering David Hook for a quick Q&A. 

Ted Shorter: There’s a lot to like about this strategy, in my opinion. Fostering better collaboration between public and private sectors will be vital, and the report’s intention to make security more affordable is a step in the right direction.

Ted Shorter: Cybercriminals and hostile nation-state actors can attack infrastructure on a broad scale, and silos between Public and Private will hinder our ability to recognize and understand these attacks, as well as respond to them.

To be clear, it’s not a fair fight when private entities are defending themselves against nation-state actors. It’s certainly not a fair fight when real ammunition and armaments are used, and it’s no fairer a fight with cyberattacks.

It’s easier said than done, but the public and private sectors need better ways to share critical information. Today, private-sector security leaders are often discouraged from sharing information about attacks due to fear of fines, bad press, and so on.

Ted Shorter: This activity will pave the way for security regulations on a much broader set of devices than exists today — which is a good thing. When everyone is playing under the same security rules, device manufacturers won’t have to worry about the relative security spend on their devices.

The caveat, of course, is that these regulations will need to apply globally because devices are manufactured everywhere. Otherwise, the standards won’t have much of an effect.

Tomas Gustavsson: There’s a lot going on here. Software development teams must develop new solutions with security in mind from the outset. In regards to machine identities, hard-coded credentials or credentials held in code repositories must be removed and protected much better. 

While product identities aren’t necessarily part of the software development lifecycle, the development process itself may consume a number of certificates. Machines and APIs need strong authentication, developers need SSH certificates and signing certificates, and code is signed in different stages, which demands code-signing certificates and strong protection of private keys.

In a zero-trust architecture, the whole end-to-end flow of code and communication simply necessitates a modern, API-driven, scalable PKI.

Tomas Gustavsson: In the recent GitHub breach, attackers downloaded code-signing keys that were stored in the code repository, which highlights the need to keep code and keys separate. 

In this specific case, the keys were encrypted, and there’s no evidence that the attacker managed to decrypt the keys, but still, it created an unnecessarily nervous time. Following best practices and using external systems (HSMs) for code-signing keys would have saved them from scrambling in their investigation.

For organizations seeking to adopt secure development practices, I’d recommend three pieces of advice: 

• Study up on best practices and guidelines from industry leaders and government agencies like NIST and ENISA.
• Never keep code and credentials in the same place.
• Keep systems updated and adopt zero-trust architectures.

David Hook: Leaders should ask themselves, ‘What do I need to protect?’ and ‘How am I currently protecting it?’

The first is important because attack vectors are changing. In the face of techniques like data harvesting, we must appreciate that not all data is equal. Some data only needs to be protected for short periods, while other things need protection for much longer. Leaders should prioritize data that need long-term protection. 

Answering the second question has proven harder than it sounds. Most systems have many moving parts, some of which have been worked on for years by multiple developers, who often use libraries and tools of uncertain provenance. In the absence of a proper software bill of materials, leaders will likely discover that not everything has been done as has been documented or claimed. 

Supply chain resilience isn’t just being confident that critical infrastructure will be maintained and supported, but also knowing how they were built.

David Hook: While it falls on organizations like NIST to sponsor the development of PQC algorithms, it’s our job to convert these algorithms into something tangible and useful to the general community. We’re actively doing this by introducing post-quantum algorithms to Bouncy Castle and supporting post-quantum certificates for Keyfactor EJBCA and Keyfactor Command.

Keyfactor has also taken a lead in securing the supply chain. The transparency that comes with open-source software can be an advantage — it certainly helps with the question of how things were built — but the missing link is user support and sustainability. Bouncy Castle and EJBCA have found a place in the critical infrastructure of many organizations, and they are made sustainable and resilient through support when those organizations when needed.

As digital trust becomes a more integral focus of governments, regulatory bodies, and enterprise strategies, Keyfactor will continue to make these developments accessible and actionable to security leaders. 

To see how the enterprise world is approaching machine identity management and PKI, check out Keyfactor’s 2023 State of Machine Identity report.