Over the past several weeks I’ve written two blogs in response to the build into signals coming from the U.S. government, namely the Cybersecurity and Infrastructure Security Agency (CISA). The first describes how the security of intelligent edge systems will evolve. This blog also touches on how build into requirements will play a critical role in improving overall security so companies can focus on true resiliency.
Read MoreRecently, 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.”
Read MoreWorking at Star Lab requires we give considerable thought to how security will evolve over time as it relates to intelligent systems. Below are my predictions, with a small shameless plug for Star Lab’s approach. The trend in the 20s will be one that moves from Enterprise Influence, i.e, just apply current enterprise and cloud security solutions to the intelligent edge (IE), to Fight Through, where systems have the intelligence to automate attack discovery as well engage survival defenses such as reconfiguration and / or engaging response actions to minimize or neutralize the threat.
Read MoreFinally, after a mere four and a half years in draft form, the FDA has released updated cyber security requirements for new (medical) devices seeking approval this fall. These updated requirements highlight how medical devices are falling far behind other industries and are currently in a game of catch up. In what’s sure to be a fast paced and slightly chaotic version of catch up, medical device makers are currently faced with a slightly guided version of “choose your own adventure”, which let’s be honest here, is both good and bad. In the good column, device manufactures aren’t forced to use specific technologies or methodologies (unlike some other industries).
Read MoreReal system security is only effective with a measured boot design. (No, this is not a blog entry about footwear…)
Although a lot of attention is placed on Operating System (OS) protections (SELinux, ASLR, etc.), these protections mean little if an attacker tampers with the OS early in the boot process. For example, although SELinux is a powerful access-control mechanism, it can be disabled with a single boot argument passed via a bootloader. OS runtime protections also mean little if an attacker can just remove the hard drive and edit configuration files offline without restriction. A measured boot design can handle this attack too.
Read MoreAs part of the Star Lab sales team, I attended the Wind River Annual Kick Off in early February. As a “newbie” to the Star Lab team with only 4 months under my belt, I was attending with a high degree of curiosity about where our security solutions fit into the larger story of a company that has created embedded development tools for decades.
Read MoreBring your own filesystem (BYOF) attacks have become increasingly common. In a BYOF attack, an attacker delivers payloads to a target, as it minimizes their footprint and system-level interactions. From a practical perspective, how would (or could a system designer) defend against these attacks? Even more so, how can a system designer implement proper defenses to even prevent similar types of attacks in the future without just trying to plug all the possible holes retroactively.
Read MoreIt's not fair.
When attacking an embedded system, it takes only one vulnerability to lead to an exploit, or at least an exploit chain. Of course, this all depends on what the attacker’s goals are in the first place.
This means, when tasked with securing an embedded system, the defender must think through and be prepared to protect against every possible vulnerability, across all layers of the system and overall architecture. Overlook just one opening and the attacker may find it, take control, steal your secrets, and create an exploit for others to use anytime, anywhere.
Read MoreLike many companies, we run our own private gitlab server, and while it’s highly configurable, it doesn’t always meet our needs out of the box. Sometimes we have to automate complex tasks outside of the normal workflow. As we discovered, the complexity of a tool such as gitlab would necessitate interaction with its backend API in order to automate some fairly complex tasks.
Read MoreIn part one, we focused on identifying what data needs to be secured in your system. In this part, we will consider where our applications and data reside, so we can make sure any applied protections are meeting the desired goal. Identifying where our applications and data reside is critical to protecting it at rest, runtime and in transit.
Read More