Zero-day attacks are on the rise. It's time to plan a defensive edge.
A version of this article appeared in SC Magazine. It has been modified and syndicated here.
If you’ve ever had your home broken into by thieves, you’ll understand that initial sinking feeling that something is wrong, followed by the realization that you have, indeed, been stolen from and violated. It usually results in lasting discomfort, not to mention a pivot to security measures that would rival Fort Knox.
Now imagine your home is breached, because the thieves have made themselves a key. They creep around, coming and going as they please, but are careful to remain undetected. Then, one day, you notice all too late that the jewelry you hid in the freezer is gone, your safe has been emptied, and your personal belongings have been ransacked. This is the equivalent reality an organization faces if it falls victim to a zero-day cyberattack. In 2020, a study by the Ponemon Institute revealed that 80% of successful data breaches were the result of zero-day exploits, and sadly, most companies remain ill-equipped to make a significant improvement on this statistic.
Zero-day attacks, by definition, give developers zero time to find and patch existing vulnerabilities that could be exploited, because the threat actor got in first. The damage is done and then it’s a mad scramble to fix both the software and reputational damage to the business. Attackers are always at an advantage, and closing that edge as much as possible is crucial.
The holiday gift nobody wanted - Log4Shell - is currently blowing up the internet, with over a billion devices said to be affected by this catastrophic Java vulnerability. It’s shaping up to be the worst 0day attack on record, and we’re just getting started. Despite some reports stating that exploits started a few days before public disclosure, a presentation given at Black Hat Conference in 2016 would suggest this has been a known issue for some time. Ouch. Worse still, it’s painfully easy to exploit, and every script kiddie and threat actor on the planet is chasing paydirt with this vulnerability.
So, what is the best path forward for defending against a slippery, sinister threat, not to mention vulnerabilities that have been missed in the software development process? Let’s take a look.
Zero-day attacks against big targets are rare (and expensive)
There’s a huge market for exploits on the dark web, and zero-days tend to go for a pretty penny, with one example in this article listed for $2.5M at the time of writing. Reported to be an exploit of Apple iOS, it’s no surprise that the security researcher’s asking price is through the roof; after all, this could indeed be the gateway to compromise millions of devices, harvest billions of sensitive data records, and do it as long as possible before it’s discovered and patched.
But who has that kind of money, anyway? Typically, organized cybercrime syndicates will come up with the cash if it’s deemed worthy, especially for ever-popular ransomware attacks. However, global governments and defense departments are among the clientele for exploits they can use for threat intelligence, and in more positive scenarios, the companies themselves may be buyers of their own potential zero-day exploits so they can mitigate disaster.
2021 saw records broken for live zero-day exploit discoveries, and it is large organizations, government departments, and infrastructure that are most at risk of being probed for any weaknesses. There is no way to be completely safe from the possibility of a zero-day attack, but you can “play the game” somewhat by offering a generous and well-structured bug bounty program. Rather than wait until someone offers the keys to your software castle on a dark web marketplace, get legit security buffs on your side and offer them decent rewards for ethical disclosure and potential fixes.
And if it just so happens to be a hair-raising zero-day threat, it’s safe to assume you’ll need to cough up more than an Amazon gift card (and it will be worth your while to do so).
Your tooling could be a liability for your security personnel
Cumbersome security tooling has been an issue for a long time, with the average CISO managing anywhere from 55 to 75 tools in their security arsenal. Aside from being the world’s most confusing (metaphorical) Swiss Army Knife, 53% of enterprises aren’t even confident they’re working effectively, according to a study by the Ponemon Institute. Another study revealed that just 17% of CISOs thought their security stack was “completely effective”.
In a field known for its burnout, lack of security-skilled people to meet demand, and need for agility, forcing security professionals to work with information overload in the form of data, reporting, and monitoring of huge toolsets is burdensome. This is exactly the type of scenario that can cause them to miss a critical alert, which may well have been the case when it came to properly assessing Log4j for its weaknesses.
Preventative security should include developer-driven threat modeling
Code-level vulnerabilities are often introduced by developers, and they need precision guidance and regular learning pathways to build secure coding skills. However, next-level secure developers have been given the opportunity to learn and practice threat modeling as part of their software creation process.
It shouldn’t come as a surprise that the people who know their software best are the developers who have sat there and created it. They have powerful knowledge on how users interact with it, where the features are used, and when sufficiently security-aware, potential scenarios where it could break or be exploited.
If we bring this back to the Log4Shell exploit, we are unfortunately seeing a scenario where a catastrophic vulnerability has escaped detection by experts and complex toolsets, however, it may not have occurred at all if the library was configured to sanitize user input. The decision against doing so seems to have been an obscure feature for added convenience, but made it painfully easy to exploit (think SQL injection-level, certainly not genius stuff). If threat modeling was done by a group of keen, security-savvy developers, it’s highly likely this scenario would have been theorized and considered.
A great security program has an emotional component, with human intervention and nuance at the heart of solving human-created issues. Threat modeling takes empathy and experience to be effective, as does secure coding and configuration at the architectural level of software and applications. This is not something that developers should be thrown into overnight, but a clear pathway to upskill them to a level where they can take the pressure off the security team for this important task is ideal (and it’s a great way to build rapport between both teams).
Zero-days lead to n-days
The next part of dealing with a zero-day is getting patches out as fast as possible, hoping like hell that every user of the vulnerable software applies it as soon as possible, and certainly before an attacker gets there first. With Log4Shell, it could eclipse Heartbleed in its endurance and potency in the face of it being embedded in millions of devices, and creating complex dependencies across a software build.
Realistically, there is no way to completely stop this type of insidious attack. However, with a commitment to using every avenue to create quality, secure software, and approaching development with the same mindset as you would critical infrastructure, we can all have a fighting chance.
Zero-day attacks, by definition, give developers zero time to find and patch existing vulnerabilities that could be exploited, because the threat actor got in first. The damage is done and then it’s a mad scramble to fix both the software and reputational damage to the business. Attackers are always at an advantage, and closing that edge as much as possible is crucial.
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoMatias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
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.
A version of this article appeared in SC Magazine. It has been modified and syndicated here.
If you’ve ever had your home broken into by thieves, you’ll understand that initial sinking feeling that something is wrong, followed by the realization that you have, indeed, been stolen from and violated. It usually results in lasting discomfort, not to mention a pivot to security measures that would rival Fort Knox.
Now imagine your home is breached, because the thieves have made themselves a key. They creep around, coming and going as they please, but are careful to remain undetected. Then, one day, you notice all too late that the jewelry you hid in the freezer is gone, your safe has been emptied, and your personal belongings have been ransacked. This is the equivalent reality an organization faces if it falls victim to a zero-day cyberattack. In 2020, a study by the Ponemon Institute revealed that 80% of successful data breaches were the result of zero-day exploits, and sadly, most companies remain ill-equipped to make a significant improvement on this statistic.
Zero-day attacks, by definition, give developers zero time to find and patch existing vulnerabilities that could be exploited, because the threat actor got in first. The damage is done and then it’s a mad scramble to fix both the software and reputational damage to the business. Attackers are always at an advantage, and closing that edge as much as possible is crucial.
The holiday gift nobody wanted - Log4Shell - is currently blowing up the internet, with over a billion devices said to be affected by this catastrophic Java vulnerability. It’s shaping up to be the worst 0day attack on record, and we’re just getting started. Despite some reports stating that exploits started a few days before public disclosure, a presentation given at Black Hat Conference in 2016 would suggest this has been a known issue for some time. Ouch. Worse still, it’s painfully easy to exploit, and every script kiddie and threat actor on the planet is chasing paydirt with this vulnerability.
So, what is the best path forward for defending against a slippery, sinister threat, not to mention vulnerabilities that have been missed in the software development process? Let’s take a look.
Zero-day attacks against big targets are rare (and expensive)
There’s a huge market for exploits on the dark web, and zero-days tend to go for a pretty penny, with one example in this article listed for $2.5M at the time of writing. Reported to be an exploit of Apple iOS, it’s no surprise that the security researcher’s asking price is through the roof; after all, this could indeed be the gateway to compromise millions of devices, harvest billions of sensitive data records, and do it as long as possible before it’s discovered and patched.
But who has that kind of money, anyway? Typically, organized cybercrime syndicates will come up with the cash if it’s deemed worthy, especially for ever-popular ransomware attacks. However, global governments and defense departments are among the clientele for exploits they can use for threat intelligence, and in more positive scenarios, the companies themselves may be buyers of their own potential zero-day exploits so they can mitigate disaster.
2021 saw records broken for live zero-day exploit discoveries, and it is large organizations, government departments, and infrastructure that are most at risk of being probed for any weaknesses. There is no way to be completely safe from the possibility of a zero-day attack, but you can “play the game” somewhat by offering a generous and well-structured bug bounty program. Rather than wait until someone offers the keys to your software castle on a dark web marketplace, get legit security buffs on your side and offer them decent rewards for ethical disclosure and potential fixes.
And if it just so happens to be a hair-raising zero-day threat, it’s safe to assume you’ll need to cough up more than an Amazon gift card (and it will be worth your while to do so).
Your tooling could be a liability for your security personnel
Cumbersome security tooling has been an issue for a long time, with the average CISO managing anywhere from 55 to 75 tools in their security arsenal. Aside from being the world’s most confusing (metaphorical) Swiss Army Knife, 53% of enterprises aren’t even confident they’re working effectively, according to a study by the Ponemon Institute. Another study revealed that just 17% of CISOs thought their security stack was “completely effective”.
In a field known for its burnout, lack of security-skilled people to meet demand, and need for agility, forcing security professionals to work with information overload in the form of data, reporting, and monitoring of huge toolsets is burdensome. This is exactly the type of scenario that can cause them to miss a critical alert, which may well have been the case when it came to properly assessing Log4j for its weaknesses.
Preventative security should include developer-driven threat modeling
Code-level vulnerabilities are often introduced by developers, and they need precision guidance and regular learning pathways to build secure coding skills. However, next-level secure developers have been given the opportunity to learn and practice threat modeling as part of their software creation process.
It shouldn’t come as a surprise that the people who know their software best are the developers who have sat there and created it. They have powerful knowledge on how users interact with it, where the features are used, and when sufficiently security-aware, potential scenarios where it could break or be exploited.
If we bring this back to the Log4Shell exploit, we are unfortunately seeing a scenario where a catastrophic vulnerability has escaped detection by experts and complex toolsets, however, it may not have occurred at all if the library was configured to sanitize user input. The decision against doing so seems to have been an obscure feature for added convenience, but made it painfully easy to exploit (think SQL injection-level, certainly not genius stuff). If threat modeling was done by a group of keen, security-savvy developers, it’s highly likely this scenario would have been theorized and considered.
A great security program has an emotional component, with human intervention and nuance at the heart of solving human-created issues. Threat modeling takes empathy and experience to be effective, as does secure coding and configuration at the architectural level of software and applications. This is not something that developers should be thrown into overnight, but a clear pathway to upskill them to a level where they can take the pressure off the security team for this important task is ideal (and it’s a great way to build rapport between both teams).
Zero-days lead to n-days
The next part of dealing with a zero-day is getting patches out as fast as possible, hoping like hell that every user of the vulnerable software applies it as soon as possible, and certainly before an attacker gets there first. With Log4Shell, it could eclipse Heartbleed in its endurance and potency in the face of it being embedded in millions of devices, and creating complex dependencies across a software build.
Realistically, there is no way to completely stop this type of insidious attack. However, with a commitment to using every avenue to create quality, secure software, and approaching development with the same mindset as you would critical infrastructure, we can all have a fighting chance.
A version of this article appeared in SC Magazine. It has been modified and syndicated here.
If you’ve ever had your home broken into by thieves, you’ll understand that initial sinking feeling that something is wrong, followed by the realization that you have, indeed, been stolen from and violated. It usually results in lasting discomfort, not to mention a pivot to security measures that would rival Fort Knox.
Now imagine your home is breached, because the thieves have made themselves a key. They creep around, coming and going as they please, but are careful to remain undetected. Then, one day, you notice all too late that the jewelry you hid in the freezer is gone, your safe has been emptied, and your personal belongings have been ransacked. This is the equivalent reality an organization faces if it falls victim to a zero-day cyberattack. In 2020, a study by the Ponemon Institute revealed that 80% of successful data breaches were the result of zero-day exploits, and sadly, most companies remain ill-equipped to make a significant improvement on this statistic.
Zero-day attacks, by definition, give developers zero time to find and patch existing vulnerabilities that could be exploited, because the threat actor got in first. The damage is done and then it’s a mad scramble to fix both the software and reputational damage to the business. Attackers are always at an advantage, and closing that edge as much as possible is crucial.
The holiday gift nobody wanted - Log4Shell - is currently blowing up the internet, with over a billion devices said to be affected by this catastrophic Java vulnerability. It’s shaping up to be the worst 0day attack on record, and we’re just getting started. Despite some reports stating that exploits started a few days before public disclosure, a presentation given at Black Hat Conference in 2016 would suggest this has been a known issue for some time. Ouch. Worse still, it’s painfully easy to exploit, and every script kiddie and threat actor on the planet is chasing paydirt with this vulnerability.
So, what is the best path forward for defending against a slippery, sinister threat, not to mention vulnerabilities that have been missed in the software development process? Let’s take a look.
Zero-day attacks against big targets are rare (and expensive)
There’s a huge market for exploits on the dark web, and zero-days tend to go for a pretty penny, with one example in this article listed for $2.5M at the time of writing. Reported to be an exploit of Apple iOS, it’s no surprise that the security researcher’s asking price is through the roof; after all, this could indeed be the gateway to compromise millions of devices, harvest billions of sensitive data records, and do it as long as possible before it’s discovered and patched.
But who has that kind of money, anyway? Typically, organized cybercrime syndicates will come up with the cash if it’s deemed worthy, especially for ever-popular ransomware attacks. However, global governments and defense departments are among the clientele for exploits they can use for threat intelligence, and in more positive scenarios, the companies themselves may be buyers of their own potential zero-day exploits so they can mitigate disaster.
2021 saw records broken for live zero-day exploit discoveries, and it is large organizations, government departments, and infrastructure that are most at risk of being probed for any weaknesses. There is no way to be completely safe from the possibility of a zero-day attack, but you can “play the game” somewhat by offering a generous and well-structured bug bounty program. Rather than wait until someone offers the keys to your software castle on a dark web marketplace, get legit security buffs on your side and offer them decent rewards for ethical disclosure and potential fixes.
And if it just so happens to be a hair-raising zero-day threat, it’s safe to assume you’ll need to cough up more than an Amazon gift card (and it will be worth your while to do so).
Your tooling could be a liability for your security personnel
Cumbersome security tooling has been an issue for a long time, with the average CISO managing anywhere from 55 to 75 tools in their security arsenal. Aside from being the world’s most confusing (metaphorical) Swiss Army Knife, 53% of enterprises aren’t even confident they’re working effectively, according to a study by the Ponemon Institute. Another study revealed that just 17% of CISOs thought their security stack was “completely effective”.
In a field known for its burnout, lack of security-skilled people to meet demand, and need for agility, forcing security professionals to work with information overload in the form of data, reporting, and monitoring of huge toolsets is burdensome. This is exactly the type of scenario that can cause them to miss a critical alert, which may well have been the case when it came to properly assessing Log4j for its weaknesses.
Preventative security should include developer-driven threat modeling
Code-level vulnerabilities are often introduced by developers, and they need precision guidance and regular learning pathways to build secure coding skills. However, next-level secure developers have been given the opportunity to learn and practice threat modeling as part of their software creation process.
It shouldn’t come as a surprise that the people who know their software best are the developers who have sat there and created it. They have powerful knowledge on how users interact with it, where the features are used, and when sufficiently security-aware, potential scenarios where it could break or be exploited.
If we bring this back to the Log4Shell exploit, we are unfortunately seeing a scenario where a catastrophic vulnerability has escaped detection by experts and complex toolsets, however, it may not have occurred at all if the library was configured to sanitize user input. The decision against doing so seems to have been an obscure feature for added convenience, but made it painfully easy to exploit (think SQL injection-level, certainly not genius stuff). If threat modeling was done by a group of keen, security-savvy developers, it’s highly likely this scenario would have been theorized and considered.
A great security program has an emotional component, with human intervention and nuance at the heart of solving human-created issues. Threat modeling takes empathy and experience to be effective, as does secure coding and configuration at the architectural level of software and applications. This is not something that developers should be thrown into overnight, but a clear pathway to upskill them to a level where they can take the pressure off the security team for this important task is ideal (and it’s a great way to build rapport between both teams).
Zero-days lead to n-days
The next part of dealing with a zero-day is getting patches out as fast as possible, hoping like hell that every user of the vulnerable software applies it as soon as possible, and certainly before an attacker gets there first. With Log4Shell, it could eclipse Heartbleed in its endurance and potency in the face of it being embedded in millions of devices, and creating complex dependencies across a software build.
Realistically, there is no way to completely stop this type of insidious attack. However, with a commitment to using every avenue to create quality, secure software, and approaching development with the same mindset as you would critical infrastructure, we can all have a fighting chance.
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Click on the link below and download the PDF of this one pager.
DownloadSecure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demoMatias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
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.
A version of this article appeared in SC Magazine. It has been modified and syndicated here.
If you’ve ever had your home broken into by thieves, you’ll understand that initial sinking feeling that something is wrong, followed by the realization that you have, indeed, been stolen from and violated. It usually results in lasting discomfort, not to mention a pivot to security measures that would rival Fort Knox.
Now imagine your home is breached, because the thieves have made themselves a key. They creep around, coming and going as they please, but are careful to remain undetected. Then, one day, you notice all too late that the jewelry you hid in the freezer is gone, your safe has been emptied, and your personal belongings have been ransacked. This is the equivalent reality an organization faces if it falls victim to a zero-day cyberattack. In 2020, a study by the Ponemon Institute revealed that 80% of successful data breaches were the result of zero-day exploits, and sadly, most companies remain ill-equipped to make a significant improvement on this statistic.
Zero-day attacks, by definition, give developers zero time to find and patch existing vulnerabilities that could be exploited, because the threat actor got in first. The damage is done and then it’s a mad scramble to fix both the software and reputational damage to the business. Attackers are always at an advantage, and closing that edge as much as possible is crucial.
The holiday gift nobody wanted - Log4Shell - is currently blowing up the internet, with over a billion devices said to be affected by this catastrophic Java vulnerability. It’s shaping up to be the worst 0day attack on record, and we’re just getting started. Despite some reports stating that exploits started a few days before public disclosure, a presentation given at Black Hat Conference in 2016 would suggest this has been a known issue for some time. Ouch. Worse still, it’s painfully easy to exploit, and every script kiddie and threat actor on the planet is chasing paydirt with this vulnerability.
So, what is the best path forward for defending against a slippery, sinister threat, not to mention vulnerabilities that have been missed in the software development process? Let’s take a look.
Zero-day attacks against big targets are rare (and expensive)
There’s a huge market for exploits on the dark web, and zero-days tend to go for a pretty penny, with one example in this article listed for $2.5M at the time of writing. Reported to be an exploit of Apple iOS, it’s no surprise that the security researcher’s asking price is through the roof; after all, this could indeed be the gateway to compromise millions of devices, harvest billions of sensitive data records, and do it as long as possible before it’s discovered and patched.
But who has that kind of money, anyway? Typically, organized cybercrime syndicates will come up with the cash if it’s deemed worthy, especially for ever-popular ransomware attacks. However, global governments and defense departments are among the clientele for exploits they can use for threat intelligence, and in more positive scenarios, the companies themselves may be buyers of their own potential zero-day exploits so they can mitigate disaster.
2021 saw records broken for live zero-day exploit discoveries, and it is large organizations, government departments, and infrastructure that are most at risk of being probed for any weaknesses. There is no way to be completely safe from the possibility of a zero-day attack, but you can “play the game” somewhat by offering a generous and well-structured bug bounty program. Rather than wait until someone offers the keys to your software castle on a dark web marketplace, get legit security buffs on your side and offer them decent rewards for ethical disclosure and potential fixes.
And if it just so happens to be a hair-raising zero-day threat, it’s safe to assume you’ll need to cough up more than an Amazon gift card (and it will be worth your while to do so).
Your tooling could be a liability for your security personnel
Cumbersome security tooling has been an issue for a long time, with the average CISO managing anywhere from 55 to 75 tools in their security arsenal. Aside from being the world’s most confusing (metaphorical) Swiss Army Knife, 53% of enterprises aren’t even confident they’re working effectively, according to a study by the Ponemon Institute. Another study revealed that just 17% of CISOs thought their security stack was “completely effective”.
In a field known for its burnout, lack of security-skilled people to meet demand, and need for agility, forcing security professionals to work with information overload in the form of data, reporting, and monitoring of huge toolsets is burdensome. This is exactly the type of scenario that can cause them to miss a critical alert, which may well have been the case when it came to properly assessing Log4j for its weaknesses.
Preventative security should include developer-driven threat modeling
Code-level vulnerabilities are often introduced by developers, and they need precision guidance and regular learning pathways to build secure coding skills. However, next-level secure developers have been given the opportunity to learn and practice threat modeling as part of their software creation process.
It shouldn’t come as a surprise that the people who know their software best are the developers who have sat there and created it. They have powerful knowledge on how users interact with it, where the features are used, and when sufficiently security-aware, potential scenarios where it could break or be exploited.
If we bring this back to the Log4Shell exploit, we are unfortunately seeing a scenario where a catastrophic vulnerability has escaped detection by experts and complex toolsets, however, it may not have occurred at all if the library was configured to sanitize user input. The decision against doing so seems to have been an obscure feature for added convenience, but made it painfully easy to exploit (think SQL injection-level, certainly not genius stuff). If threat modeling was done by a group of keen, security-savvy developers, it’s highly likely this scenario would have been theorized and considered.
A great security program has an emotional component, with human intervention and nuance at the heart of solving human-created issues. Threat modeling takes empathy and experience to be effective, as does secure coding and configuration at the architectural level of software and applications. This is not something that developers should be thrown into overnight, but a clear pathway to upskill them to a level where they can take the pressure off the security team for this important task is ideal (and it’s a great way to build rapport between both teams).
Zero-days lead to n-days
The next part of dealing with a zero-day is getting patches out as fast as possible, hoping like hell that every user of the vulnerable software applies it as soon as possible, and certainly before an attacker gets there first. With Log4Shell, it could eclipse Heartbleed in its endurance and potency in the face of it being embedded in millions of devices, and creating complex dependencies across a software build.
Realistically, there is no way to completely stop this type of insidious attack. However, with a commitment to using every avenue to create quality, secure software, and approaching development with the same mindset as you would critical infrastructure, we can all have a fighting chance.
Table of contents
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
DigitalOcean Decreases Security Debt with Secure Code Warrior
DigitalOcean's use of Secure Code Warrior training has significantly reduced security debt, allowing teams to focus more on innovation and productivity. The improved security has strengthened their product quality and competitive edge. Looking ahead, the SCW Trust Score will help them further enhance security practices and continue driving innovation.
Resources to get you started
Coders Conquer Security: Share & Learn - Cross-Site Scripting (XSS)
Cross-site scripting (XSS) uses the trust of browsers and ignorance of users to steal data, take over accounts, and deface websites; it's a vulnerability that can get very ugly, very quickly. Let's take a look at how XSS works, what damage can be done, and how to prevent it.
Coders Conquer Security: Share & Learn - Cross-Site Scripting (XSS)
Cross-site scripting (XSS) uses the trust of browsers and ignorance of users to steal data, take over accounts, and deface websites; it's a vulnerability that can get very ugly, very quickly. Let's take a look at how XSS works, what damage can be done, and how to prevent it.