Yet Another Wake Up Call

A Time for Reflection and Change in Our Cyber Protection Strategy

We are once again confronted with another serious?security vulnerability?embedded within a very large number of public and private sector systems across the United States and worldwide.?Log4Shell?(exploited through the Java logging framework?Logj4), while previously only familiar to those who deal with software and systems development, operations, and sustainment, has become a household name overnight. Once the vulnerability was announced, we were all “on the clock” in a race to apply the prescribed patches to mitigate the risk of a successful cyber-attack exploiting the vulnerability.

This story is all too predictable in the modern world of complex systems, growing?attack surface, and a complete dependence on computing technology for virtually every societal function that matters, from lighting and heating our homes to defending the country from hostile adversaries. The security-related?technical debt incurred over decades of neglect in software and systems development, is now coming due in the form of increasingly destructive?cyber-attacks?at scale. We are in this position because we have failed to engineer our systems with sufficient rigor and discipline using principled design approaches that would enable us to adequately manage system complexity and obtain the levels of trustworthiness necessary for assured missions and business operations. To be fair, it is not an easy task to accomplish—but it is also not an impossible one to achieve given the will to do so.

My friend and colleague Sami Saydjari, a leading cybersecurity expert, summarized the problem and solution very succinctly and eloquently in his book,?Engineering Trustworthy Systems.

“For the first few decades as a burgeoning discipline, cybersecurity has been dominated by the development of widgets to address some aspect of the problem. Systems have become increasingly complex and interconnected, creating even more attack opportunities, which in turn creates even more opportunities to create defensive widgets that will bring some value in detecting or preventing an aspect of the attack space. Eventually, this becomes a game of whack-a-mole in which a simulated mole pops up from one of many holes and the objective is to whack the mole before it pops back in its hole. The moles represent new attacks, and the holes represent a huge array of potential vulnerabilities—both known and as-yet-undiscovered.”

“Underlying [the discipline of] engineering is science. Sometimes engineering gets ahead of science, such as in bridge building, where the fundamentals of material science were not well understood. Many bridges were built; many fell down; some stayed up; designs of the ones that stayed up were copied. Eventually, for engineering to advance beyond some point, science must catch up with engineering. The science underlying cybersecurity [and more generally, security] engineering is complex and difficult. On the other hand, there is no time like the present to start, because it is both urgent and important to the future…”

Sami also observed that “retroactive cybersecurity design is a?Sisyphean?task.” In that light, we desperately need a “factory reset” on how we develop systems and the myriad of components that make up those systems. After decades of a failed “penetrate and patch” strategy, we are finally starting to see an increased focus on developing trustworthy secure systems—systems that are grounded in the fundamentals of science and engineering.

This focus is reflected in zero trust concepts that bring back the principles [1] gleaned from decades of experience and engineering—much like the engineering associated with bridge building. These zero trust concepts and architectures are part of the movement toward increasing the level of assurance in systems and system components—the systems and components we depend on for the health, safety, and security of the Nation. It is a movement toward systems that are inherently more secure or “secure by design.”

So, after we put out this latest four-alarm fire and the smoke clears, let’s take some time for reflection. Real reflection. Let’s?think deeply about what security we want from our systems. How are we going to build organizations and cultures that produce this security and assurance? Let’s also take the time to thank all of the people on the front lines involved in getting us through this critical time of uncertainty and exposure—from the handful of volunteer security researchers who find these vulnerabilities (in roughly 40 million open-source libraries), to the response teams working 24/7 on mitigations, to the security and development teams doing the updating, patching, and monitoring. For those dedicated individuals, it’s exhausting... and we owe them a debt of gratitude.

The Logj4 vulnerability should be a huge wakeup call for significant change in system and software development practices, especially for critical systems and applications with the potential for loss of life and societal disruptions. But, like many alarms, we just might roll over and hit the snooze button (again).

[1]??These security design principles can be found in the update to NIST Special Publication 800-160, Volume 1, Revision 1, “Systems Security Engineering: Considerations for a Transdisciplinary Approach in the Engineering of Trustworthy Secure Systems,” targeted for release in January 2022. Current systems security engineering guidance can be found in?SP 800-160, Volume 1.

A special note of thanks to?Mark Winstead,?Greg Touhill,?Tony Cole, and?Jeff Williams, long-time cybersecurity and SSE colleagues, who graciously reviewed and provided sage advice for this article.