Memory-safe languages and more: first officer's blog - week 26

Memory-safe languages, log4shell and more. Here are the some of the biggest stories of the week, from the world of cyber risk.

Mike Parkin | November 21, 2022

First Officer’s log, Terrestrial date, 20221121. Officer of the Deck reporting.  

Our work at Frontier Station [REDACTED] has been proceeding as expected. While the station used a range of tools across their departments, some standard, some decidedly not, and some built on the fly by the local engineering team to meet specific needs, we are well equipped to get people speaking the same language. 

Fortunately, we haven’t had any crisis situations come up during this engagement. That’s something the crew always welcomes because if we’ve learned nothing else, it’s that deployments never go exactly to plan and being agile enough to catch your feet and get everything back on track is vital for a support ship’s crew. 

While things have been going smoothly, we have also been watching the 3D Chess tournament unfold.  

Under normal circumstances, a tournament like this would only be of interest to the hard-core fans. But with one of our own participating, the crew was understandably much more involved. Some of them had even gone so far as to set up a betting pool to see how far various players would get. Our Ensign was an internal favorite, as much because he was one of ours as his legitimate chance of winning. 

Something we had noted though was a [REDACTED] who had come out of nowhere to defeat some highly placed and widely respected players. They had an endorsement from their own system’s governing body, but their record coming in hadn’t indicated they’d be such a strong contender. 

The [REDACTED] were broadly known, and grudgingly respected, for their skills as traders and merchants, with a cultural focus on the acquisition of wealth. However, 3D chess wasn’t really a common hobby in their space, which made this all the more unusual. 

Definitely someone to watch as the tournament progresses. 

The long, long, tail of Log4Shell 

What happened 

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) and the Federal Bureau of Investigation (FBI) put out a joint cybersecurity advisory that details how threat actors associated with the Iranian state compromised a federal agency’s network by exploiting Log4Shell. 

Why it matters 

The Apache Log4J vulnerability was a Big Thing™ and got a lot of attention. While a lot of organizations acted quickly to patch their affected systems and get things under control, a “long tail” effect was expected from the beginning. There are always systems and applications that get missed when people are trying to patch holes, and sometimes that can mean finding vulnerable hosts weeks, months, or even years after the patches came out. 

Federal agencies are held to a higher standard, but even there it can be hard to track down every vulnerable instance. Unfortunately, that means we can expect to see threat actors leveraging the log4j vulnerability until that long tail finally plays out. 

What they said 


Even a year later, Log4Shell continues to cause a stir

The push for memory-safe languages

What happened 

The NSA recently advised developers to shift away from programming languages with potential memory handling issues to others that are more inherently “memory safe” than the alternatives they suggest replacing.  

Why it matters 

Fortunately, a large number of projects are already being developed in the suggested memory-safe languages and the advice is generally welcome. It can be challenging to shift to a new coding language, especially when applications are leveraging specific features that may be unique to the original language without a lot of additional work. After all, there are still applications written in Cobol in the wild. But in the long run, the shift to memory-safe languages will be worth it, even realizing that at some point new languages will come along and require another shift. 

What they said 

memory-safe languages

The suggested shift to memory-safe languages has plenty of people talking

How to lower morale in a few easy steps 

What happened 

While not directly related to cybersecurity, Twitter is a widely used platform in the community to release initial information about vulnerabilities, security incidents, and industry news. Elon Musk’s recent purchase of the platform has led to mass layoffs, changes in policy, and pushing the remaining employees to work harder and longer, which has led some to question whether the platform will survive, let alone remain viable for disseminating cybersecurity information.  

Why it matters 

The “sound bite” nature of Twitter means it has never been a platform suited to detailed and nuanced discussions of security issues. But it is often where people get their first news that something is happening so they can shift focus to a platform better able to handle detailed discussions. Politics aside, there are a few notable things happening over at Twitter. 

Some of the new policies have already reduced trust in the veracity of information people are seeing, and the “you’ll have to work a lot of hard hours if you want to stay” message bodes ill for the people who remain with the organization. 

Even if the platform doesn’t implode, it’s likely that cybersecurity professionals will be looking for, or creating, a new platform to handle the quick “sound bite” information that can be the first we hear about a major new vulnerability. 

What they said 

Anything Elon Musk does instantly gets attention, and this is no different


Want to get ahead of the stories? Join the conversations as they happen with the Vulcan Cyber community Slack channel

Free for risk owners

Set up in minutes to aggregate and prioritize cyber risk across all your assets and attack vectors.

"Idea for an overwhelmed secops/security team".

Name Namerson
Head of Cyber Security Strategy