What Does "Build Secure" Mean, Anyway?
Recently, the Cybersecurity and Infrastructure Security Agency (CISA) Director, Jen Easterly and Tom Fanning, Chair of CISA’s Cybersecurity Advisory Committee, released a blog discussing lessons learned from the Colonial Pipeline attack two years ago. After a healthy amount of self-promotion, Easterly and Fanning call for “security to be built into the creation of new technology – as a foundational imperative – rather than bolted on at the end requiring continuous security updates from consumers.” At Star Lab we’ve long called for this approach, but many might not know what it means for security to be built in. For this reason, I thought I’d write this blog and describe my view of the different built into paradigms that exist today.
Observable Security
The first and most popular is what I call Observable Security. Ever since I started in cyber security back in 2000, observability has been an obsession. When I served at the Air Force Computer Emergency Response Team (AFCERT) we cared about network observability. Next came end-point observability, where software agents were installed on desktops and servers to monitor and report back the state of a system. This approach has been carried into today’s modern cloud infrastructures and, as would be expected, is a consideration for embedded systems as well, particularly legacy OT systems. While observation is important, availability and reliability measures often require the immediate reporting of relevant system events, observability capabilities for security are almost always introduced after a system is designed and developed, and they often are the most detrimental to system performance.
Let’s not also forget that observing a security event in no way means you’ve mitigated it or are resilient to it; it simply means you aren’t in the dark about it. Ultimately commercial security vendors like it because it can be sold while customers are under duress (like during an incident), it can be bolted on, and they can charge for also analyzing the data generated. If all you ever hear from your security vendor is an ability to detect zero-days or advanced malware, you likely still need to deal with the insecurity of your system.
Software Security
Next is Software Security. This is a rapidly growing area of security, and it will surely be captured under the built into mantra. After doing a bit of research, I’ve learned that the total addressable market (TAM) for Software Security is approximately $4.5B – $6.5B. Solutions in this space are attempting to provide security by ensuring software running on a system is secure. Like Observable Security, Software Security is an approach that attempts to be as little involved in the actual design of the system as possible and instead simply provide you with tools that analyze code, either source code or binary code. The weakness with this approach is that it assumes all threats come in the form of software exploits, but there are ample ways for a system to be compromised without having to exploit software:
An insider intentionally configures a system with a backdoor;
A system is configured with poor security controls like weak passwords; or
Trojanized software or firmware binaries might be written over benign versions.
Formal Security
The third paradigm, Formal Security, is the most involved built into approach on this list. Formal Security is the systems engineering practice that uses design, analysis, and verification tools to build-in security and manage tradeoffs between security and other functional and non-functional system requirements. Systems engineers use modeling tools and modeling languages, and they express systems requirements as ‘shall’ statements. In addition to modeling tools, formal methods are often used to formally specify the behavior of a system and its components, as well as to prove the correctness of the system with respect to its specifications.
This involves creating a formal specification, using mathematical logic to verify the formal specification, and automatically generating code from the verified specification. This approach provides strong guarantees that code will perform correctly according to the formal specification, practically eliminating the possibility of the introduction of software flaws; however, the use of formal methods comes with several disadvantages. First, the resulting code and behavior are only as good as the formal specification. If the specification is incomplete or incorrect, formal verification will fall short. Further, if any code must be modified, the process must restart. This makes the process of software evolution very cumbersome, time consuming, and expensive. Finally, very specialized skill sets in mathematics and modeling are necessary to pursue this approach.
Layered Security
Finally, Layered Security, is the fourth built into paradigm and it strikes the right balance between Observable / Software Security and Formal Security. Like Formal Security, it requires doing the upfront engineering work to describe use-cases, formulate requirements for system updates, and perform threat modeling; however, instead of trying to achieve the costly and time-consuming goal of correctness, Layered Security calls for employing layers of known and possibly novel security techniques to impede or deny attackers access, maneuverability, and impact. These capabilities could include attack surface reduction techniques, runtime protections, access controls, secure boot, and hardening configurations.
By integrating many layers across interfaces and attack surfaces, and throughout a system’s software stack, from firmware to bootloader to OS kernel to user-space, attackers who do gain access are greatly hindered and will likely move on to easier targets. Furthermore, determining which layers to employ can be guided by the beforementioned threat models and by tradeoff testing performed in continuous integration / continuous testing environments. Also, with a Layered Security approach, attempted violations can also be observed, but with the assurance that malicious actions have been prevented.
The below figure summarizes the above and provides a simple comparison of each built into paradigm from the perspective of Efficacy (ability to stop malicious activity), Range (the reach of the security across a system attack surface), and Plug-n-Play (the ease of integrating the security into a system).
Learn about our Build Secure Methodology
At Star Lab, we are an advocate of the Layered Security approach. It’s the most economical approach, while also having a real impact on addressing the insecurity of a system. It does require effort on the designer of the system, but at Star Lab we can help by offering design and security integration tools, and we stand ready to assist those who really want to get better. In the coming months and years, I believe a lot of security vendors will be crafting a lot of marketing material to try and convince people their solution is a built into solution. Hopefully this blog will help you better assess whether such claims are true.
