The cybersecurity issues we can’t ignore in 2022

Published Mar 28, 2022
by Matias Madou, Ph.D.
cASE sTUDY

The cybersecurity issues we can’t ignore in 2022

Published Mar 28, 2022
by Matias Madou, Ph.D.
View Resource
View Resource

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.

View Resource
View Resource

Author

Matias Madou, Ph.D.

Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.

Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.

Want more?

Dive into onto our latest secure coding insights on the blog.

Our extensive resource library aims to empower the human approach to secure coding upskilling.

View Blog
Want more?

Get the latest research on developer-driven security

Our extensive resource library is full of helpful resources from whitepapers to webinars to get you started with developer-driven secure coding. Explore it now.

Resource Hub

The cybersecurity issues we can’t ignore in 2022

Published Mar 28, 2022
By Matias Madou, Ph.D.

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.

We would like your permission to send you information on our products and/or related secure coding topics. We’ll always treat your personal details with the utmost care and will never sell them to other companies for marketing purposes.

To submit the form, please enable 'Analytics' cookies. Feel free to disable them again once you're done.