Secure Code Warrior

The cybersecurity issues we can’t ignore in 2022

When it comes to battling against cybercriminals, we need to stay as in step with them as possible, preempting their playgrounds with a preventative mindset. Here’s where I think they might start making waves in the coming year:

A version of this article was published in Infosecurity Magazine. It has been updated and syndicated here.

The past two years have been somewhat of a baptism by fire for, well, everyone, but the cybersecurity blueprint for most organizations was put to the test as many of us were dropped into a remote working model virtually overnight. We really had to up the ante and adapt as an industry, especially in the wake of desperate threat actors causing a 300% spike in reported cybercrimes since the pandemic kicked off.

We’ve all learned a few lessons, and I’m comforted by the fact that not only is general cybersecurity being taken more seriously, so too is code-level software security and quality. Biden’s Executive Order on securing the software supply chain brought to light critical issues, especially in the wake of the SolarWinds mass breach. The idea that we all need to care more about security, and work to reduce vulnerabilities with measurable security awareness is definitely a larger part of the conversation.

That being said, when it comes to battling against cybercriminals, we need to stay as in step with them as possible, preempting their playgrounds with a preventative mindset. 

Here’s where I think they might start making waves in the coming year:

The metaverse is a new attack surface

The metaverse might be the next evolution of the internet, but a similar transformation is yet to materialize in the way most industries approach securing software and digital environments. 

While general cybersecurity pitfalls like phishing scams will be inevitable (and likely plentiful while everyone is finding their feet with the metaverse), the actual infrastructure and devices that make this immersive virtual world possible will need to be secure. Similar to the way smartphones helped us to live online, peripherals like VR headsets are the new gateway to mountains of user data. Increasingly complex embedded systems security is required to make IoT gadgets safe, and the brave new world of mainstream VR/AR is no exception. As we have seen with the Log4Shell exploit, simple errors at the code level can bloom into a backstage pass for threat actors, and in a simulated reality, every movement creates data that can be stolen.  

While in its infancy, a successful metaverse is going to require practical adoption of cryptocurrency (not just random hoarding of the latest meme coin), and items of value like NFTs, meaning our real-life wealth, identity, data, and livelihoods are potentially opened up to a new “Wild West” that can put people at risk. Before we engineers start going crazy with epic features and enhancements, minimizing this new, vast attack surface from the ground up should be a priority.

Legislation in the wake of Log4Shell

For the scores of developers who were thrown into chaos, scrambling to find if there were any instances of, or dependencies associated with, an exploitable version of the widely-used Log4j logging tool, I don’t think the holiday period would have been a joyous time. 

This zero-day attack is among the worst on record, with comparisons made between Log4Shell and the devastating Heartbleed OpenSSL vulnerability that is still being exploited over six years later. If this timeline is anything to go by, we will be dealing with a Log4Shell hangover for a long time into the future. It is clear that even with the lessons learned from Heartbleed - at least in terms of the need to roll out and implement patches as quickly as possible - many organizations just don’t act fast enough to keep themselves protected. Depending on the size of the company, patching can be incredibly difficult and bureaucratic, requiring cross-department documentation and implementation. Quite often, IT departments and developers don’t have an encyclopedic knowledge of all libraries, components, and tools in use, and are hamstrung by strict deployment schedules to minimize disruption and application downtime. There are valid reasons for this method of working (read: nobody wants to throw a spanner in the works and break something), but to patch too slow is to be a sitting duck. 

Just as the SolarWinds attack changed the game for the software supply chain, I predict that similar will happen in the wake of Log4Shell. While there are already patch management mandates and recommendations in some critical industries, widespread legislation is another story. Preventative software security will always be the best chance we have to avoid urgent security patching altogether, but security best practices dictate that patching is a non-negotiable priority measure. I think this will be a hot topic, and lead to not-so-subtle recommendations to patch quickly and often. 

More emphasis on architectural security (and developers aren’t ready)

The new OWASP Top 10 2021 had some significant new additions, as well as a surprise with Injection vulnerabilities falling from the top spot to a lowly third place. Those new additions speak to something of a “stage two” for a developer’s journey in secure coding and security best practices, and sadly, most are ill-equipped to make a positive impact on reducing risk here unless properly trained. 

We have known for some time that developers must be security-skilled if we are to combat common security bugs in code, and organizations are responding better to the premise of developer-driven prevention. However, with Insecure Design claiming a spot in the OWASP Top 10 and being a category of architectural security issues rather than a single type of security bug, developers will need to be pushed beyond the basics once they’ve mastered them. Learning environments that cover threat modeling - ideally with support from the security team - take serious pressure off once developers are successfully upskilled, but as it stands, it’s a significant knowledge gap for most software engineers.

Countering this “takes a village”, and the organization can play a role in creating a positive security culture for developers, inviting their curiosity without causing major disruption to their workflow.