Prevention in the age of the never-ending attack surface
A version of this article appeared in the SD Times. It has been updated and syndicated here.
When we talk about progress, typically, digital advancement is at the forefront of the conversation. We want everything better, faster, more convenient, more powerful, and we want to do it for less money, time, and risk. For the most part, these “impossible” objectives are eventually met; it might take several years and multiple versions (and a team of developers who might start a coup if they’re asked to switch gears on feature design one more freaking time), but every day, code is out there changing the world.
However, with great software expansion comes great responsibility, and the reality is, we’re simply not ready to deal with it from a security perspective. Software development is no longer an island, and when we account for all aspects of software-powered risk - everything from the cloud, embedded systems in appliances and vehicles, our critical infrastructure, not to mention the APIs that connect it all - the attack surface is borderless and out of control.
We can’t expect a magical time where each line of code is meticulously checked by seasoned security experts - that skills gap is not closing any time soon - but we can, as an industry, adopt a more holistic approach to code-level security.
Let’s explore how we can corral that infinite attack surface with the tools at hand:
Be realistic about the level of business risk (and what you’re willing to accept)
Perfect security is not sustainable, but neither is putting on a blindfold and pretending everything is blue skies. We already know that organizations knowingly ship vulnerable code, and clearly, this is a calculated risk based on time to market with new features and products.
Security at speed is a challenge, especially in places where DevSecOps isn’t the standard development methodology. However, we only need to look at the recent Log4Shell exploit to discover how relatively small security issues in code have opened up opportunities for a successful attack, and see that the consequences of those calculated risks to shipping lower-quality code could be far greater than projected.
Get comfortable with being an (access) control freak
An alarming number of costly data breaches are caused by poorly configured cloud storage environments, and the potential of sensitive data exposure resulting from access control errors continues to haunt security teams in most organizations.
In 2019, Fortune 500 company First American Financial Corp. found this out the hard way. An authentication error - one that was relatively straightforward to remediate - led to the exposure of over 800 million records, including bank statements, mortgage contracts, and photo IDs. Their document links required no user identification or login, rendering them accessible to anyone with a web browser. Worse still, they were logged with sequential numbers, meaning a simple change of number in the link exposed a new data record.
This security issue was internally identified before being exposed in the media, however, failings in categorizing it properly as a high-risk security issue, and failure to report it to senior management for urgent remediation caused a fallout that is still being navigated today.
There is a reason that broken access control now sits at the very top of the OWASP Top 10: it’s as common as dirt, and developers need verified security awareness and practical skills to navigate best practices around authentication and privileges in their own builds, ensuring checks and measures are in place to protect sensitive data exposure.
The nature of APIs makes them especially relevant and tricky; they are very chatty with other applications by design, and development teams should have visibility across all potential access points. After all, they can’t take into consideration unknown variables and use cases in their quest to provide safer software.
Analyze your security program: how much emphasis is placed on prevention?
It makes sense that a large component of a security program is dedicated to incident response and reaction, but many organizations are missing valuable risk minimization by not utilizing all the resources available to prevent a security incident in the first place.
Sure, there are comprehensive stacks of security tooling that assist in uncovering problematic bugs, but almost 50% of companies admitted to shipping code they knew was vulnerable. Time constraints, the complexity of toolsets, and a lack of trained experts to respond to reporting all contribute to what has essentially been a calculated risk, but the fact that code needs to be secured in the cloud, in applications, in API functionality, embedded systems, libraries, and an ever-broadening landscape of technology, ensures we will always be one step behind with the current approach.
Security bugs are a human-caused problem, and we can’t expect robots to do all the fixing for us. If your development cohort is not being effectively upskilled - not just a yearly seminar, but proper educational building blocks - then you are always at risk of accepting low-quality code as standard, and the security risk that goes with it.
Have you overestimated the readiness of your developers?
Developers are rarely assessed on their secure coding abilities, and it’s not their priority (nor is it a KPI in a lot of cases). They cannot be the fall guys for poor security practices if they’re not shown a better path or told it is a measurement of their success.
Too often, though, there is an assumption within organizations that the guidance provided has been effective in preparing the engineering team to mitigate common security risks. Depending on the training and their awareness to apply security best practices, they may not be prepared to be that desirable first line of defense (and stop endless injection flaws clogging up pentest reports).
The ideal state is that learning pathways of increasing complexity are completed, with the resulting skills verified to ensure it actually works for the developer in the real world. However, this requires a cultural standard where developers are considered from the beginning, and correctly enabled. If we as an industry are going out into the wilderness to defend this vast landscape of code we’ve created ourselves, we’ll need all the help we can get… and there is more right in front of us than we realize.
Software development is no longer an island, and when we account for all aspects of software-powered risk - everything from the cloud, embedded systems in appliances and vehicles, our critical infrastructure, not to mention the APIs that connect it all - the attack surface is borderless and out of control.
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 demo
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.
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 the SD Times. It has been updated and syndicated here.
When we talk about progress, typically, digital advancement is at the forefront of the conversation. We want everything better, faster, more convenient, more powerful, and we want to do it for less money, time, and risk. For the most part, these “impossible” objectives are eventually met; it might take several years and multiple versions (and a team of developers who might start a coup if they’re asked to switch gears on feature design one more freaking time), but every day, code is out there changing the world.
However, with great software expansion comes great responsibility, and the reality is, we’re simply not ready to deal with it from a security perspective. Software development is no longer an island, and when we account for all aspects of software-powered risk - everything from the cloud, embedded systems in appliances and vehicles, our critical infrastructure, not to mention the APIs that connect it all - the attack surface is borderless and out of control.
We can’t expect a magical time where each line of code is meticulously checked by seasoned security experts - that skills gap is not closing any time soon - but we can, as an industry, adopt a more holistic approach to code-level security.
Let’s explore how we can corral that infinite attack surface with the tools at hand:
Be realistic about the level of business risk (and what you’re willing to accept)
Perfect security is not sustainable, but neither is putting on a blindfold and pretending everything is blue skies. We already know that organizations knowingly ship vulnerable code, and clearly, this is a calculated risk based on time to market with new features and products.
Security at speed is a challenge, especially in places where DevSecOps isn’t the standard development methodology. However, we only need to look at the recent Log4Shell exploit to discover how relatively small security issues in code have opened up opportunities for a successful attack, and see that the consequences of those calculated risks to shipping lower-quality code could be far greater than projected.
Get comfortable with being an (access) control freak
An alarming number of costly data breaches are caused by poorly configured cloud storage environments, and the potential of sensitive data exposure resulting from access control errors continues to haunt security teams in most organizations.
In 2019, Fortune 500 company First American Financial Corp. found this out the hard way. An authentication error - one that was relatively straightforward to remediate - led to the exposure of over 800 million records, including bank statements, mortgage contracts, and photo IDs. Their document links required no user identification or login, rendering them accessible to anyone with a web browser. Worse still, they were logged with sequential numbers, meaning a simple change of number in the link exposed a new data record.
This security issue was internally identified before being exposed in the media, however, failings in categorizing it properly as a high-risk security issue, and failure to report it to senior management for urgent remediation caused a fallout that is still being navigated today.
There is a reason that broken access control now sits at the very top of the OWASP Top 10: it’s as common as dirt, and developers need verified security awareness and practical skills to navigate best practices around authentication and privileges in their own builds, ensuring checks and measures are in place to protect sensitive data exposure.
The nature of APIs makes them especially relevant and tricky; they are very chatty with other applications by design, and development teams should have visibility across all potential access points. After all, they can’t take into consideration unknown variables and use cases in their quest to provide safer software.
Analyze your security program: how much emphasis is placed on prevention?
It makes sense that a large component of a security program is dedicated to incident response and reaction, but many organizations are missing valuable risk minimization by not utilizing all the resources available to prevent a security incident in the first place.
Sure, there are comprehensive stacks of security tooling that assist in uncovering problematic bugs, but almost 50% of companies admitted to shipping code they knew was vulnerable. Time constraints, the complexity of toolsets, and a lack of trained experts to respond to reporting all contribute to what has essentially been a calculated risk, but the fact that code needs to be secured in the cloud, in applications, in API functionality, embedded systems, libraries, and an ever-broadening landscape of technology, ensures we will always be one step behind with the current approach.
Security bugs are a human-caused problem, and we can’t expect robots to do all the fixing for us. If your development cohort is not being effectively upskilled - not just a yearly seminar, but proper educational building blocks - then you are always at risk of accepting low-quality code as standard, and the security risk that goes with it.
Have you overestimated the readiness of your developers?
Developers are rarely assessed on their secure coding abilities, and it’s not their priority (nor is it a KPI in a lot of cases). They cannot be the fall guys for poor security practices if they’re not shown a better path or told it is a measurement of their success.
Too often, though, there is an assumption within organizations that the guidance provided has been effective in preparing the engineering team to mitigate common security risks. Depending on the training and their awareness to apply security best practices, they may not be prepared to be that desirable first line of defense (and stop endless injection flaws clogging up pentest reports).
The ideal state is that learning pathways of increasing complexity are completed, with the resulting skills verified to ensure it actually works for the developer in the real world. However, this requires a cultural standard where developers are considered from the beginning, and correctly enabled. If we as an industry are going out into the wilderness to defend this vast landscape of code we’ve created ourselves, we’ll need all the help we can get… and there is more right in front of us than we realize.
A version of this article appeared in the SD Times. It has been updated and syndicated here.
When we talk about progress, typically, digital advancement is at the forefront of the conversation. We want everything better, faster, more convenient, more powerful, and we want to do it for less money, time, and risk. For the most part, these “impossible” objectives are eventually met; it might take several years and multiple versions (and a team of developers who might start a coup if they’re asked to switch gears on feature design one more freaking time), but every day, code is out there changing the world.
However, with great software expansion comes great responsibility, and the reality is, we’re simply not ready to deal with it from a security perspective. Software development is no longer an island, and when we account for all aspects of software-powered risk - everything from the cloud, embedded systems in appliances and vehicles, our critical infrastructure, not to mention the APIs that connect it all - the attack surface is borderless and out of control.
We can’t expect a magical time where each line of code is meticulously checked by seasoned security experts - that skills gap is not closing any time soon - but we can, as an industry, adopt a more holistic approach to code-level security.
Let’s explore how we can corral that infinite attack surface with the tools at hand:
Be realistic about the level of business risk (and what you’re willing to accept)
Perfect security is not sustainable, but neither is putting on a blindfold and pretending everything is blue skies. We already know that organizations knowingly ship vulnerable code, and clearly, this is a calculated risk based on time to market with new features and products.
Security at speed is a challenge, especially in places where DevSecOps isn’t the standard development methodology. However, we only need to look at the recent Log4Shell exploit to discover how relatively small security issues in code have opened up opportunities for a successful attack, and see that the consequences of those calculated risks to shipping lower-quality code could be far greater than projected.
Get comfortable with being an (access) control freak
An alarming number of costly data breaches are caused by poorly configured cloud storage environments, and the potential of sensitive data exposure resulting from access control errors continues to haunt security teams in most organizations.
In 2019, Fortune 500 company First American Financial Corp. found this out the hard way. An authentication error - one that was relatively straightforward to remediate - led to the exposure of over 800 million records, including bank statements, mortgage contracts, and photo IDs. Their document links required no user identification or login, rendering them accessible to anyone with a web browser. Worse still, they were logged with sequential numbers, meaning a simple change of number in the link exposed a new data record.
This security issue was internally identified before being exposed in the media, however, failings in categorizing it properly as a high-risk security issue, and failure to report it to senior management for urgent remediation caused a fallout that is still being navigated today.
There is a reason that broken access control now sits at the very top of the OWASP Top 10: it’s as common as dirt, and developers need verified security awareness and practical skills to navigate best practices around authentication and privileges in their own builds, ensuring checks and measures are in place to protect sensitive data exposure.
The nature of APIs makes them especially relevant and tricky; they are very chatty with other applications by design, and development teams should have visibility across all potential access points. After all, they can’t take into consideration unknown variables and use cases in their quest to provide safer software.
Analyze your security program: how much emphasis is placed on prevention?
It makes sense that a large component of a security program is dedicated to incident response and reaction, but many organizations are missing valuable risk minimization by not utilizing all the resources available to prevent a security incident in the first place.
Sure, there are comprehensive stacks of security tooling that assist in uncovering problematic bugs, but almost 50% of companies admitted to shipping code they knew was vulnerable. Time constraints, the complexity of toolsets, and a lack of trained experts to respond to reporting all contribute to what has essentially been a calculated risk, but the fact that code needs to be secured in the cloud, in applications, in API functionality, embedded systems, libraries, and an ever-broadening landscape of technology, ensures we will always be one step behind with the current approach.
Security bugs are a human-caused problem, and we can’t expect robots to do all the fixing for us. If your development cohort is not being effectively upskilled - not just a yearly seminar, but proper educational building blocks - then you are always at risk of accepting low-quality code as standard, and the security risk that goes with it.
Have you overestimated the readiness of your developers?
Developers are rarely assessed on their secure coding abilities, and it’s not their priority (nor is it a KPI in a lot of cases). They cannot be the fall guys for poor security practices if they’re not shown a better path or told it is a measurement of their success.
Too often, though, there is an assumption within organizations that the guidance provided has been effective in preparing the engineering team to mitigate common security risks. Depending on the training and their awareness to apply security best practices, they may not be prepared to be that desirable first line of defense (and stop endless injection flaws clogging up pentest reports).
The ideal state is that learning pathways of increasing complexity are completed, with the resulting skills verified to ensure it actually works for the developer in the real world. However, this requires a cultural standard where developers are considered from the beginning, and correctly enabled. If we as an industry are going out into the wilderness to defend this vast landscape of code we’ve created ourselves, we’ll need all the help we can get… and there is more right in front of us than we realize.
Click on the link below and download the PDF of this resource.
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.
View reportBook a demo
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.
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 the SD Times. It has been updated and syndicated here.
When we talk about progress, typically, digital advancement is at the forefront of the conversation. We want everything better, faster, more convenient, more powerful, and we want to do it for less money, time, and risk. For the most part, these “impossible” objectives are eventually met; it might take several years and multiple versions (and a team of developers who might start a coup if they’re asked to switch gears on feature design one more freaking time), but every day, code is out there changing the world.
However, with great software expansion comes great responsibility, and the reality is, we’re simply not ready to deal with it from a security perspective. Software development is no longer an island, and when we account for all aspects of software-powered risk - everything from the cloud, embedded systems in appliances and vehicles, our critical infrastructure, not to mention the APIs that connect it all - the attack surface is borderless and out of control.
We can’t expect a magical time where each line of code is meticulously checked by seasoned security experts - that skills gap is not closing any time soon - but we can, as an industry, adopt a more holistic approach to code-level security.
Let’s explore how we can corral that infinite attack surface with the tools at hand:
Be realistic about the level of business risk (and what you’re willing to accept)
Perfect security is not sustainable, but neither is putting on a blindfold and pretending everything is blue skies. We already know that organizations knowingly ship vulnerable code, and clearly, this is a calculated risk based on time to market with new features and products.
Security at speed is a challenge, especially in places where DevSecOps isn’t the standard development methodology. However, we only need to look at the recent Log4Shell exploit to discover how relatively small security issues in code have opened up opportunities for a successful attack, and see that the consequences of those calculated risks to shipping lower-quality code could be far greater than projected.
Get comfortable with being an (access) control freak
An alarming number of costly data breaches are caused by poorly configured cloud storage environments, and the potential of sensitive data exposure resulting from access control errors continues to haunt security teams in most organizations.
In 2019, Fortune 500 company First American Financial Corp. found this out the hard way. An authentication error - one that was relatively straightforward to remediate - led to the exposure of over 800 million records, including bank statements, mortgage contracts, and photo IDs. Their document links required no user identification or login, rendering them accessible to anyone with a web browser. Worse still, they were logged with sequential numbers, meaning a simple change of number in the link exposed a new data record.
This security issue was internally identified before being exposed in the media, however, failings in categorizing it properly as a high-risk security issue, and failure to report it to senior management for urgent remediation caused a fallout that is still being navigated today.
There is a reason that broken access control now sits at the very top of the OWASP Top 10: it’s as common as dirt, and developers need verified security awareness and practical skills to navigate best practices around authentication and privileges in their own builds, ensuring checks and measures are in place to protect sensitive data exposure.
The nature of APIs makes them especially relevant and tricky; they are very chatty with other applications by design, and development teams should have visibility across all potential access points. After all, they can’t take into consideration unknown variables and use cases in their quest to provide safer software.
Analyze your security program: how much emphasis is placed on prevention?
It makes sense that a large component of a security program is dedicated to incident response and reaction, but many organizations are missing valuable risk minimization by not utilizing all the resources available to prevent a security incident in the first place.
Sure, there are comprehensive stacks of security tooling that assist in uncovering problematic bugs, but almost 50% of companies admitted to shipping code they knew was vulnerable. Time constraints, the complexity of toolsets, and a lack of trained experts to respond to reporting all contribute to what has essentially been a calculated risk, but the fact that code needs to be secured in the cloud, in applications, in API functionality, embedded systems, libraries, and an ever-broadening landscape of technology, ensures we will always be one step behind with the current approach.
Security bugs are a human-caused problem, and we can’t expect robots to do all the fixing for us. If your development cohort is not being effectively upskilled - not just a yearly seminar, but proper educational building blocks - then you are always at risk of accepting low-quality code as standard, and the security risk that goes with it.
Have you overestimated the readiness of your developers?
Developers are rarely assessed on their secure coding abilities, and it’s not their priority (nor is it a KPI in a lot of cases). They cannot be the fall guys for poor security practices if they’re not shown a better path or told it is a measurement of their success.
Too often, though, there is an assumption within organizations that the guidance provided has been effective in preparing the engineering team to mitigate common security risks. Depending on the training and their awareness to apply security best practices, they may not be prepared to be that desirable first line of defense (and stop endless injection flaws clogging up pentest reports).
The ideal state is that learning pathways of increasing complexity are completed, with the resulting skills verified to ensure it actually works for the developer in the real world. However, this requires a cultural standard where developers are considered from the beginning, and correctly enabled. If we as an industry are going out into the wilderness to defend this vast landscape of code we’ve created ourselves, we’ll need all the help we can get… and there is more right in front of us than we realize.
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
Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise
The Secure-by-Design movement is the future of secure software development. Learn about the key elements companies need to keep in mind when they think about a Secure-by-Design initiative.
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
Trust Score Reveals the Value of Secure-by-Design Upskilling Initiatives
Our research has shown that secure code training works. Trust Score, using an algorithm drawing on more than 20 million learning data points from work by more than 250,000 learners at over 600 organizations, reveals its effectiveness in driving down vulnerabilities and how to make the initiative even more effective.
.png)
Reactive Versus Preventive Security: Prevention Is a Better Cure
The idea of bringing preventive security to legacy code and systems at the same time as newer applications can seem daunting, but a Secure-by-Design approach, enforced by upskilling developers, can apply security best practices to those systems. It’s the best chance many organizations have of improving their security postures.
The Benefits of Benchmarking Security Skills for Developers
The growing focus on secure code and Secure-by-Design principles requires developers to be trained in cybersecurity from the start of the SDLC, with tools like Secure Code Warrior’s Trust Score helping measure and improve their progress.
Driving Meaningful Success for Enterprise Secure-by-Design Initiatives
Our latest research paper, Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise is the result of deep analysis of real Secure-by-Design initiatives at the enterprise level, and deriving best practice approaches based on data-driven findings.
Developer-driven coding.
Securely.
Contact us today and make software security an intrinsic part of your development process.
