The past two years have been a baptism by fire for our cybersecurity systems.
Almost overnight, organizations adopted a remote working model that put cybersecurity blueprints to the test. We had to 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 learned a few lessons, and I’m comforted that general cybersecurity is taken more seriously, as is code-level software security and quality. President Biden’s Executive Order on securing the software supply chain illuminated 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 a more significant part of the conversation.
However, when battling against cyber-criminals, 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 make waves this 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 how 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 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 exposed data.
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 between Log4Shell and the devastating Heartbleed OpenSSL vulnerability, which remains exploited over six years later.
If this timeline is anything, we will deal with a Log4Shell hangover for a long time. 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 don’t act fast enough.
There are valid reasons for this working method (read: nobody wants to throw a spanner in the works and break something), but to patch too slowly is to be a sitting duck. Depending on the company’s size, patching can be incredibly difficult and bureaucratic, requiring cross-department documentation and implementation. IT departments and developers often don’t have comprehensive knowledge of all libraries, components and tools in use. Also, we are hamstrung by strict deployment schedules to minimize disruption and application downtime.
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.
More Emphasis on Architectural Security (And Developers Aren’t Ready)
The new OWASP Top 10 2021 had significant new additions and a surprise, with Injection vulnerabilities falling from the top spot to third place. Those new additions speak to a “stage two” for a developer’s journey in secure coding and security best practices. Sadly, most are ill-equipped with the proper skills.
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 severe pressure off once developers receive upskilling, but as it stands, it’s a significant knowledge gap for most software engineers.