SCW Icons
hero bg no divider
Blog

Comment les RSSI et les DSI créatifs peuvent innover et transformer leur programme de sécurité

Pieter Danhieux
Published Jul 23, 2019
Last updated on Mar 08, 2026

A version of this article appeared on DevOps.com; it has been re-titled and updated to include new information.

While CISOs and CIOs have the unenviable position of taking the lions share of accountability for software security, especially in the event of an embarrassing company data breach, they are also afforded a unique opportunity of increasing relevance: they are the new innovators, and they can be highly influential with the right approach. Every organization on the planet, both public and commercial, is fighting to retain (and gain) their market space in a rapidly digitizing world. Customers expect a seamless online experience from both past and future products, and a "digital-first" business approach is becoming mandatory. After all, if these expectations are not met, there's almost certainly a competitor ready to swoop on the opportunity.

So, what does that mean for the modern CISO, or CIO? Naturally, it means they are employing teams of developers, each creating line after line of the code that forms their digital product or service. Cybersecurity, while a chief consideration for many years, is an increasing risk factor as more and more business operations are conducted online and in the sights of attackers. The implications of a breach are enormous, but opting out of digitization is not an option.

Creative CISOs and CIOs are in a prime position to continue forging the path of our digital futures, together with their AppSec and development teams. They will undoubtedly shape the long-term innovation of business, government and public services online, but they bear the heavy responsibility of balancing rapid speed-to-market goals, high software quality and mitigating security risk.

This balance has been, to date, immensely difficult to strike. It has led to development teams that are often fragmented, with a general primary focus on delivering features and functions, without consideration of the vulnerabilities they could be creating in the code they are so quickly churning out. AppSec specialists constantly fix the same mistakes, while the threat of a breach from a relatively simple back door being left open looms large.

If our data is to remain safe, CISOs and CIOs need to get creative with the way their teams work together, and forge a culture of positive security and shared responsibility from the top down. Just look at the catastrophic consequences faced by Marriott as a result of their 2018 breach: A GDPR fine of over USD $123 million, more than 500 million records stolen and a security reputation in tatters. This disaster occurred in major part as a direct result of insecure coding practices, with SQL injection vulnerabilities uncovered as early as 2014 on Starwoods servers, a company acquired by Marriott in 2016. Their subsequent use of the software clearly went unchecked from an application security perspective. This gave malicious attackers multiple years to access and acquire data, while other vulnerabilities, like weak passwords, left more holes to exploit over time.

CIOs and CISOs need to consider the state of their own software security climates very carefully. How security-aware is the average developer? How well are the AppSec and development teams working together? There is no "magic wand" fix, but the culture, training and support can be worked on and improved. Development teams can transform from the first line of data breach risk in the organization, to the security superheroes that stop bad code before it ever goes to production.

Secure coding health check: Is yours on life support?

Where does your own dev team fit? I have created this secure coding checklist to help CIOs and CISOs identify whether their development teams are truly equipped to be secure coding champions, helping to innovate with faster, better and safer code (or, indeed, whether you're in need of security program overhaul):

1. How supportive is the rest of your C-Suite? Do they understand that traditional network security is no longer enough?

In the future of software, securing the network layer using outdated security measures is simply not good enough (and, let's face it, is rarely successful anyway) even against semi-professional hackers. Among many consistent reports, Verizon's "2017 Data Breach Investigations Report" cites that a staggering 35 percent of data breaches today are caused by web application vulnerabilities.

Web application security is equally as important as network security; ignoring this and failing to budget for and instill the fundamental, basic protective layer of AppSec measures could leave you well and truly open to a breach.

2. Do you shift far enough left, and are you doing it early enough?

The current approach to application security is quite tool-heavy, focusing on moving from right to left in the software development life cycle (SDLC). This, by definition and design, acknowledges the process is flawed and supports a detection and reaction outcome. Security teams are searching for and detecting vulnerabilities in code that is already written, reacting to fix committed code instead of ensuring it is bug-free as it crafted. According to the National Institute of Standards and Technology (NIST), it is 30 times more expensive to detect and fix vulnerabilities in committed code than it is to prevent them as they are written in the IDE. This doesn't even take into account the production delays, double-handling and time spent in remedying the same well-known security issues over and over.

A truly robust security culture insists on starting left, inspiring security champions within the developer cohort, while giving the development team the right tools and training to grow and act with a secure coding mindset. There is a focus on continuous self-development, and flexing their problem-solving muscles so they can be the first line of defense in their organization, preventing common vulnerabilities from occurring in the first place.

3. Are you making the effort to build practical security skills, or are you just feeding one-way knowledge?

The vast majority of security training solutions (online and CBT) focus on building knowledge instead of practical skills that directly relate to their jobs. For developers to thrive and engage in writing secure code, they need regular access to contextual, hands-on learning that actively encourages them to keep training and developing skills in a real environment. They need to learn about recently identified vulnerabilities, with real code examples, and be able to work in their preferred languages and frameworks. This learning experience is effective in helping them understand how to locate, identify and fix known vulnerabilities in the code they are actively working on in the course of their jobs.

While there are many knowledgeable teachers out there, and plenty of information on fixing security vulnerabilities, thumbing through textbooks or watching hours of video fails to engage the mind of many creative, problem-solving developers, and if the constant stream of data breaches is any indication, remains largely ineffective in preventing vulnerabilities from entering code.

4. Are you measuring your secure coding skills with real-time metrics?

A vital step in ensuring a security-first mindset is being built within a development team is to collect and review evidence. This should not be an assumption or a guessing game: developers are either security-minded, or they are not.

Metrics seek to prove to the developer and their organization that their hard work is paying off, and their individual secure coding skills are improving. You can't improve what you cannot measure. There should be relevant assessments, and these should help identify the progress of your development teams in real-time as well as benchmarking their secure coding strengths and weaknesses for continuous improvement.

Too often, security training becomes a "tick-the-box" exercise for organizations, with no emphasis on ensuring this training has been effective, engaged with or even retained.

5. Are your outsourced vendors using robust secure coding techniques?

Many organizations decide to contract out development work to third-party agencies. Whether they exist on- or offshore, their general secure coding abilities and practices are a relative mystery to their client. In the best case, the only form of assurance an organization will receive relating to security is a statement in the contract requiring the deliverable to be "secure." Very few companies take measures to verify the skills of these development houses upfront, thus running the risk of being delivered software that works as briefed, yet has been built without following sound secure coding practices. Worse yet, if the purchasing company is not aware of any inherent security flaws within the application, it risks sending vulnerable software out into the wild.

The most common scenario is that any vulnerabilities get picked up by dedicated security specialists (individuals that are difficult to source and come at a high cost) you are faced with a delay of your go-live date, and possible contractual discussions on who needs to pay for fixing these security weaknesses. However, if you're smart upfront and assess the application security skills of the developers who are going to build your next application, you save a lot of potential delays, frustration, and cash.

6. Are your developers aware of the most commonly exploited security weaknesses?

More than 85 percent of exploited web application vulnerabilities are attributed to just 10 known vulnerabilities"the OWASP Top 10. At a bare minimum, your application security training must cover these, in addition to many more vulnerability types. The training challenges your developers contend with must be revised and updated on a regular basis, with new challenges for either new coding frameworks or new vulnerability types.

Precision training using real-world secure coding scenarios should be the standard; vague general knowledge is simply not effective. (Wondering what these secure coding scenarios could look like? Check out our Coders Conquer Security blog series; there's a playable challenge in each post).

7. Do you have in-house security champions?

Every developer-heavy organization should invest in a security champion"someone who is going to take responsibility for upholding a high security standard within the dev team. Their purpose is to be a support point of contact for anyone with questions around security, as well as become the chief advocate for following security best practices.

They are a vital piece of the security culture puzzle; a great security champion can keep the momentum going from intensive training, ensure all members of the team have what they need and continue advocating for support.

8. Have you invested in tools for your developers to make secure coding easier?

If your organization is one in which agile development is practiced, or indeed you are faced with frequent updates to company-built applications, automating parts of your security is one of the only ways to keep up with the frantic pace and volume of work.

There are tools available at each stage of the SDLC that will serve as advisers, quality gatekeepers or detection tools. In addition, some tools run automated tests over the code, simulating attempted hacking once the software is in production. All have their own set of benefits and challenges, and none can provide a catchall, 100 percent guarantee that no security threats exist within the application. The number-one preventative measure you can employ is that the earlier you can capture the weakness, the faster and cheaper it is to remediate it with the least impact on your business.

The next step for forward-thinking CISOs

So, how did your organization fare against the above checklist?

While CISOs and CIOs are essentially forced to aggressively build their enterprise DevOps and DecSecOps capabilities, that doesnt mean there is no time to consider and implement the right tools and training across teams. Secure coding skills will be a weapon"not a hindrance to"innovation, and foregoing them could spell the absolute destruction of company reputation and data. These skills represent critical capabilities and a much cheaper long-term solution to reducing vulnerabilities and mitigating risk.

A brilliant, innovative CISO has the power to orchestrate a healthy security culture from the top down; ensure your staff has what they need to execute security best practices effectively.

Pieter Danhieux is a security expert and the co-founder of Secure Code Warrior.

Afficher la ressource
Afficher la ressource

Les RSSI et les DSI créatifs et inspirants ont le pouvoir d'innover et de façonner notre monde numérique, mais ils peuvent également jouer un rôle déterminant dans la transformation de la culture de sécurité d'une organisation.

Vous souhaitez en savoir plus ?

Chief Executive Officer, Chairman, and Co-Founder

learn more

Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Réservez une démo
Partagez sur :
linkedin brandsSocialx logo
Auteur
Pieter Danhieux
Published Jul 23, 2019

Chief Executive Officer, Chairman, and Co-Founder

Pieter Danhieux is a globally recognized security expert, with over 12 years experience as a security consultant and 8 years as a Principal Instructor for SANS teaching offensive techniques on how to target and assess organizations, systems and individuals for security weaknesses. In 2016, he was recognized as one of the Coolest Tech people in Australia (Business Insider), awarded Cyber Security Professional of the Year (AISA - Australian Information Security Association) and holds GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA certifications.

Partagez sur :
linkedin brandsSocialx logo

A version of this article appeared on DevOps.com; it has been re-titled and updated to include new information.

While CISOs and CIOs have the unenviable position of taking the lions share of accountability for software security, especially in the event of an embarrassing company data breach, they are also afforded a unique opportunity of increasing relevance: they are the new innovators, and they can be highly influential with the right approach. Every organization on the planet, both public and commercial, is fighting to retain (and gain) their market space in a rapidly digitizing world. Customers expect a seamless online experience from both past and future products, and a "digital-first" business approach is becoming mandatory. After all, if these expectations are not met, there's almost certainly a competitor ready to swoop on the opportunity.

So, what does that mean for the modern CISO, or CIO? Naturally, it means they are employing teams of developers, each creating line after line of the code that forms their digital product or service. Cybersecurity, while a chief consideration for many years, is an increasing risk factor as more and more business operations are conducted online and in the sights of attackers. The implications of a breach are enormous, but opting out of digitization is not an option.

Creative CISOs and CIOs are in a prime position to continue forging the path of our digital futures, together with their AppSec and development teams. They will undoubtedly shape the long-term innovation of business, government and public services online, but they bear the heavy responsibility of balancing rapid speed-to-market goals, high software quality and mitigating security risk.

This balance has been, to date, immensely difficult to strike. It has led to development teams that are often fragmented, with a general primary focus on delivering features and functions, without consideration of the vulnerabilities they could be creating in the code they are so quickly churning out. AppSec specialists constantly fix the same mistakes, while the threat of a breach from a relatively simple back door being left open looms large.

If our data is to remain safe, CISOs and CIOs need to get creative with the way their teams work together, and forge a culture of positive security and shared responsibility from the top down. Just look at the catastrophic consequences faced by Marriott as a result of their 2018 breach: A GDPR fine of over USD $123 million, more than 500 million records stolen and a security reputation in tatters. This disaster occurred in major part as a direct result of insecure coding practices, with SQL injection vulnerabilities uncovered as early as 2014 on Starwoods servers, a company acquired by Marriott in 2016. Their subsequent use of the software clearly went unchecked from an application security perspective. This gave malicious attackers multiple years to access and acquire data, while other vulnerabilities, like weak passwords, left more holes to exploit over time.

CIOs and CISOs need to consider the state of their own software security climates very carefully. How security-aware is the average developer? How well are the AppSec and development teams working together? There is no "magic wand" fix, but the culture, training and support can be worked on and improved. Development teams can transform from the first line of data breach risk in the organization, to the security superheroes that stop bad code before it ever goes to production.

Secure coding health check: Is yours on life support?

Where does your own dev team fit? I have created this secure coding checklist to help CIOs and CISOs identify whether their development teams are truly equipped to be secure coding champions, helping to innovate with faster, better and safer code (or, indeed, whether you're in need of security program overhaul):

1. How supportive is the rest of your C-Suite? Do they understand that traditional network security is no longer enough?

In the future of software, securing the network layer using outdated security measures is simply not good enough (and, let's face it, is rarely successful anyway) even against semi-professional hackers. Among many consistent reports, Verizon's "2017 Data Breach Investigations Report" cites that a staggering 35 percent of data breaches today are caused by web application vulnerabilities.

Web application security is equally as important as network security; ignoring this and failing to budget for and instill the fundamental, basic protective layer of AppSec measures could leave you well and truly open to a breach.

2. Do you shift far enough left, and are you doing it early enough?

The current approach to application security is quite tool-heavy, focusing on moving from right to left in the software development life cycle (SDLC). This, by definition and design, acknowledges the process is flawed and supports a detection and reaction outcome. Security teams are searching for and detecting vulnerabilities in code that is already written, reacting to fix committed code instead of ensuring it is bug-free as it crafted. According to the National Institute of Standards and Technology (NIST), it is 30 times more expensive to detect and fix vulnerabilities in committed code than it is to prevent them as they are written in the IDE. This doesn't even take into account the production delays, double-handling and time spent in remedying the same well-known security issues over and over.

A truly robust security culture insists on starting left, inspiring security champions within the developer cohort, while giving the development team the right tools and training to grow and act with a secure coding mindset. There is a focus on continuous self-development, and flexing their problem-solving muscles so they can be the first line of defense in their organization, preventing common vulnerabilities from occurring in the first place.

3. Are you making the effort to build practical security skills, or are you just feeding one-way knowledge?

The vast majority of security training solutions (online and CBT) focus on building knowledge instead of practical skills that directly relate to their jobs. For developers to thrive and engage in writing secure code, they need regular access to contextual, hands-on learning that actively encourages them to keep training and developing skills in a real environment. They need to learn about recently identified vulnerabilities, with real code examples, and be able to work in their preferred languages and frameworks. This learning experience is effective in helping them understand how to locate, identify and fix known vulnerabilities in the code they are actively working on in the course of their jobs.

While there are many knowledgeable teachers out there, and plenty of information on fixing security vulnerabilities, thumbing through textbooks or watching hours of video fails to engage the mind of many creative, problem-solving developers, and if the constant stream of data breaches is any indication, remains largely ineffective in preventing vulnerabilities from entering code.

4. Are you measuring your secure coding skills with real-time metrics?

A vital step in ensuring a security-first mindset is being built within a development team is to collect and review evidence. This should not be an assumption or a guessing game: developers are either security-minded, or they are not.

Metrics seek to prove to the developer and their organization that their hard work is paying off, and their individual secure coding skills are improving. You can't improve what you cannot measure. There should be relevant assessments, and these should help identify the progress of your development teams in real-time as well as benchmarking their secure coding strengths and weaknesses for continuous improvement.

Too often, security training becomes a "tick-the-box" exercise for organizations, with no emphasis on ensuring this training has been effective, engaged with or even retained.

5. Are your outsourced vendors using robust secure coding techniques?

Many organizations decide to contract out development work to third-party agencies. Whether they exist on- or offshore, their general secure coding abilities and practices are a relative mystery to their client. In the best case, the only form of assurance an organization will receive relating to security is a statement in the contract requiring the deliverable to be "secure." Very few companies take measures to verify the skills of these development houses upfront, thus running the risk of being delivered software that works as briefed, yet has been built without following sound secure coding practices. Worse yet, if the purchasing company is not aware of any inherent security flaws within the application, it risks sending vulnerable software out into the wild.

The most common scenario is that any vulnerabilities get picked up by dedicated security specialists (individuals that are difficult to source and come at a high cost) you are faced with a delay of your go-live date, and possible contractual discussions on who needs to pay for fixing these security weaknesses. However, if you're smart upfront and assess the application security skills of the developers who are going to build your next application, you save a lot of potential delays, frustration, and cash.

6. Are your developers aware of the most commonly exploited security weaknesses?

More than 85 percent of exploited web application vulnerabilities are attributed to just 10 known vulnerabilities"the OWASP Top 10. At a bare minimum, your application security training must cover these, in addition to many more vulnerability types. The training challenges your developers contend with must be revised and updated on a regular basis, with new challenges for either new coding frameworks or new vulnerability types.

Precision training using real-world secure coding scenarios should be the standard; vague general knowledge is simply not effective. (Wondering what these secure coding scenarios could look like? Check out our Coders Conquer Security blog series; there's a playable challenge in each post).

7. Do you have in-house security champions?

Every developer-heavy organization should invest in a security champion"someone who is going to take responsibility for upholding a high security standard within the dev team. Their purpose is to be a support point of contact for anyone with questions around security, as well as become the chief advocate for following security best practices.

They are a vital piece of the security culture puzzle; a great security champion can keep the momentum going from intensive training, ensure all members of the team have what they need and continue advocating for support.

8. Have you invested in tools for your developers to make secure coding easier?

If your organization is one in which agile development is practiced, or indeed you are faced with frequent updates to company-built applications, automating parts of your security is one of the only ways to keep up with the frantic pace and volume of work.

There are tools available at each stage of the SDLC that will serve as advisers, quality gatekeepers or detection tools. In addition, some tools run automated tests over the code, simulating attempted hacking once the software is in production. All have their own set of benefits and challenges, and none can provide a catchall, 100 percent guarantee that no security threats exist within the application. The number-one preventative measure you can employ is that the earlier you can capture the weakness, the faster and cheaper it is to remediate it with the least impact on your business.

The next step for forward-thinking CISOs

So, how did your organization fare against the above checklist?

While CISOs and CIOs are essentially forced to aggressively build their enterprise DevOps and DecSecOps capabilities, that doesnt mean there is no time to consider and implement the right tools and training across teams. Secure coding skills will be a weapon"not a hindrance to"innovation, and foregoing them could spell the absolute destruction of company reputation and data. These skills represent critical capabilities and a much cheaper long-term solution to reducing vulnerabilities and mitigating risk.

A brilliant, innovative CISO has the power to orchestrate a healthy security culture from the top down; ensure your staff has what they need to execute security best practices effectively.

Pieter Danhieux is a security expert and the co-founder of Secure Code Warrior.

Afficher la ressource
Afficher la ressource

Remplissez le formulaire ci-dessous pour télécharger le rapport

Nous aimerions avoir votre autorisation pour vous envoyer des informations sur nos produits et/ou sur des sujets liés au codage sécurisé. Nous traiterons toujours vos données personnelles avec le plus grand soin et ne les vendrons jamais à d'autres entreprises à des fins de marketing.

Soumettre
scw success icon
scw error icon
Pour soumettre le formulaire, veuillez activer les cookies « Analytics ». N'hésitez pas à les désactiver à nouveau une fois que vous aurez terminé.

A version of this article appeared on DevOps.com; it has been re-titled and updated to include new information.

While CISOs and CIOs have the unenviable position of taking the lions share of accountability for software security, especially in the event of an embarrassing company data breach, they are also afforded a unique opportunity of increasing relevance: they are the new innovators, and they can be highly influential with the right approach. Every organization on the planet, both public and commercial, is fighting to retain (and gain) their market space in a rapidly digitizing world. Customers expect a seamless online experience from both past and future products, and a "digital-first" business approach is becoming mandatory. After all, if these expectations are not met, there's almost certainly a competitor ready to swoop on the opportunity.

So, what does that mean for the modern CISO, or CIO? Naturally, it means they are employing teams of developers, each creating line after line of the code that forms their digital product or service. Cybersecurity, while a chief consideration for many years, is an increasing risk factor as more and more business operations are conducted online and in the sights of attackers. The implications of a breach are enormous, but opting out of digitization is not an option.

Creative CISOs and CIOs are in a prime position to continue forging the path of our digital futures, together with their AppSec and development teams. They will undoubtedly shape the long-term innovation of business, government and public services online, but they bear the heavy responsibility of balancing rapid speed-to-market goals, high software quality and mitigating security risk.

This balance has been, to date, immensely difficult to strike. It has led to development teams that are often fragmented, with a general primary focus on delivering features and functions, without consideration of the vulnerabilities they could be creating in the code they are so quickly churning out. AppSec specialists constantly fix the same mistakes, while the threat of a breach from a relatively simple back door being left open looms large.

If our data is to remain safe, CISOs and CIOs need to get creative with the way their teams work together, and forge a culture of positive security and shared responsibility from the top down. Just look at the catastrophic consequences faced by Marriott as a result of their 2018 breach: A GDPR fine of over USD $123 million, more than 500 million records stolen and a security reputation in tatters. This disaster occurred in major part as a direct result of insecure coding practices, with SQL injection vulnerabilities uncovered as early as 2014 on Starwoods servers, a company acquired by Marriott in 2016. Their subsequent use of the software clearly went unchecked from an application security perspective. This gave malicious attackers multiple years to access and acquire data, while other vulnerabilities, like weak passwords, left more holes to exploit over time.

CIOs and CISOs need to consider the state of their own software security climates very carefully. How security-aware is the average developer? How well are the AppSec and development teams working together? There is no "magic wand" fix, but the culture, training and support can be worked on and improved. Development teams can transform from the first line of data breach risk in the organization, to the security superheroes that stop bad code before it ever goes to production.

Secure coding health check: Is yours on life support?

Where does your own dev team fit? I have created this secure coding checklist to help CIOs and CISOs identify whether their development teams are truly equipped to be secure coding champions, helping to innovate with faster, better and safer code (or, indeed, whether you're in need of security program overhaul):

1. How supportive is the rest of your C-Suite? Do they understand that traditional network security is no longer enough?

In the future of software, securing the network layer using outdated security measures is simply not good enough (and, let's face it, is rarely successful anyway) even against semi-professional hackers. Among many consistent reports, Verizon's "2017 Data Breach Investigations Report" cites that a staggering 35 percent of data breaches today are caused by web application vulnerabilities.

Web application security is equally as important as network security; ignoring this and failing to budget for and instill the fundamental, basic protective layer of AppSec measures could leave you well and truly open to a breach.

2. Do you shift far enough left, and are you doing it early enough?

The current approach to application security is quite tool-heavy, focusing on moving from right to left in the software development life cycle (SDLC). This, by definition and design, acknowledges the process is flawed and supports a detection and reaction outcome. Security teams are searching for and detecting vulnerabilities in code that is already written, reacting to fix committed code instead of ensuring it is bug-free as it crafted. According to the National Institute of Standards and Technology (NIST), it is 30 times more expensive to detect and fix vulnerabilities in committed code than it is to prevent them as they are written in the IDE. This doesn't even take into account the production delays, double-handling and time spent in remedying the same well-known security issues over and over.

A truly robust security culture insists on starting left, inspiring security champions within the developer cohort, while giving the development team the right tools and training to grow and act with a secure coding mindset. There is a focus on continuous self-development, and flexing their problem-solving muscles so they can be the first line of defense in their organization, preventing common vulnerabilities from occurring in the first place.

3. Are you making the effort to build practical security skills, or are you just feeding one-way knowledge?

The vast majority of security training solutions (online and CBT) focus on building knowledge instead of practical skills that directly relate to their jobs. For developers to thrive and engage in writing secure code, they need regular access to contextual, hands-on learning that actively encourages them to keep training and developing skills in a real environment. They need to learn about recently identified vulnerabilities, with real code examples, and be able to work in their preferred languages and frameworks. This learning experience is effective in helping them understand how to locate, identify and fix known vulnerabilities in the code they are actively working on in the course of their jobs.

While there are many knowledgeable teachers out there, and plenty of information on fixing security vulnerabilities, thumbing through textbooks or watching hours of video fails to engage the mind of many creative, problem-solving developers, and if the constant stream of data breaches is any indication, remains largely ineffective in preventing vulnerabilities from entering code.

4. Are you measuring your secure coding skills with real-time metrics?

A vital step in ensuring a security-first mindset is being built within a development team is to collect and review evidence. This should not be an assumption or a guessing game: developers are either security-minded, or they are not.

Metrics seek to prove to the developer and their organization that their hard work is paying off, and their individual secure coding skills are improving. You can't improve what you cannot measure. There should be relevant assessments, and these should help identify the progress of your development teams in real-time as well as benchmarking their secure coding strengths and weaknesses for continuous improvement.

Too often, security training becomes a "tick-the-box" exercise for organizations, with no emphasis on ensuring this training has been effective, engaged with or even retained.

5. Are your outsourced vendors using robust secure coding techniques?

Many organizations decide to contract out development work to third-party agencies. Whether they exist on- or offshore, their general secure coding abilities and practices are a relative mystery to their client. In the best case, the only form of assurance an organization will receive relating to security is a statement in the contract requiring the deliverable to be "secure." Very few companies take measures to verify the skills of these development houses upfront, thus running the risk of being delivered software that works as briefed, yet has been built without following sound secure coding practices. Worse yet, if the purchasing company is not aware of any inherent security flaws within the application, it risks sending vulnerable software out into the wild.

The most common scenario is that any vulnerabilities get picked up by dedicated security specialists (individuals that are difficult to source and come at a high cost) you are faced with a delay of your go-live date, and possible contractual discussions on who needs to pay for fixing these security weaknesses. However, if you're smart upfront and assess the application security skills of the developers who are going to build your next application, you save a lot of potential delays, frustration, and cash.

6. Are your developers aware of the most commonly exploited security weaknesses?

More than 85 percent of exploited web application vulnerabilities are attributed to just 10 known vulnerabilities"the OWASP Top 10. At a bare minimum, your application security training must cover these, in addition to many more vulnerability types. The training challenges your developers contend with must be revised and updated on a regular basis, with new challenges for either new coding frameworks or new vulnerability types.

Precision training using real-world secure coding scenarios should be the standard; vague general knowledge is simply not effective. (Wondering what these secure coding scenarios could look like? Check out our Coders Conquer Security blog series; there's a playable challenge in each post).

7. Do you have in-house security champions?

Every developer-heavy organization should invest in a security champion"someone who is going to take responsibility for upholding a high security standard within the dev team. Their purpose is to be a support point of contact for anyone with questions around security, as well as become the chief advocate for following security best practices.

They are a vital piece of the security culture puzzle; a great security champion can keep the momentum going from intensive training, ensure all members of the team have what they need and continue advocating for support.

8. Have you invested in tools for your developers to make secure coding easier?

If your organization is one in which agile development is practiced, or indeed you are faced with frequent updates to company-built applications, automating parts of your security is one of the only ways to keep up with the frantic pace and volume of work.

There are tools available at each stage of the SDLC that will serve as advisers, quality gatekeepers or detection tools. In addition, some tools run automated tests over the code, simulating attempted hacking once the software is in production. All have their own set of benefits and challenges, and none can provide a catchall, 100 percent guarantee that no security threats exist within the application. The number-one preventative measure you can employ is that the earlier you can capture the weakness, the faster and cheaper it is to remediate it with the least impact on your business.

The next step for forward-thinking CISOs

So, how did your organization fare against the above checklist?

While CISOs and CIOs are essentially forced to aggressively build their enterprise DevOps and DecSecOps capabilities, that doesnt mean there is no time to consider and implement the right tools and training across teams. Secure coding skills will be a weapon"not a hindrance to"innovation, and foregoing them could spell the absolute destruction of company reputation and data. These skills represent critical capabilities and a much cheaper long-term solution to reducing vulnerabilities and mitigating risk.

A brilliant, innovative CISO has the power to orchestrate a healthy security culture from the top down; ensure your staff has what they need to execute security best practices effectively.

Pieter Danhieux is a security expert and the co-founder of Secure Code Warrior.

Afficher le webinaire
Commencez
learn more

Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.

Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Afficher le rapportRéservez une démo
Télécharger le PDF
Afficher la ressource
Partagez sur :
linkedin brandsSocialx logo
Vous souhaitez en savoir plus ?

Partagez sur :
linkedin brandsSocialx logo
Auteur
Pieter Danhieux
Published Jul 23, 2019

Chief Executive Officer, Chairman, and Co-Founder

Pieter Danhieux is a globally recognized security expert, with over 12 years experience as a security consultant and 8 years as a Principal Instructor for SANS teaching offensive techniques on how to target and assess organizations, systems and individuals for security weaknesses. In 2016, he was recognized as one of the Coolest Tech people in Australia (Business Insider), awarded Cyber Security Professional of the Year (AISA - Australian Information Security Association) and holds GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA certifications.

Partagez sur :
linkedin brandsSocialx logo

A version of this article appeared on DevOps.com; it has been re-titled and updated to include new information.

While CISOs and CIOs have the unenviable position of taking the lions share of accountability for software security, especially in the event of an embarrassing company data breach, they are also afforded a unique opportunity of increasing relevance: they are the new innovators, and they can be highly influential with the right approach. Every organization on the planet, both public and commercial, is fighting to retain (and gain) their market space in a rapidly digitizing world. Customers expect a seamless online experience from both past and future products, and a "digital-first" business approach is becoming mandatory. After all, if these expectations are not met, there's almost certainly a competitor ready to swoop on the opportunity.

So, what does that mean for the modern CISO, or CIO? Naturally, it means they are employing teams of developers, each creating line after line of the code that forms their digital product or service. Cybersecurity, while a chief consideration for many years, is an increasing risk factor as more and more business operations are conducted online and in the sights of attackers. The implications of a breach are enormous, but opting out of digitization is not an option.

Creative CISOs and CIOs are in a prime position to continue forging the path of our digital futures, together with their AppSec and development teams. They will undoubtedly shape the long-term innovation of business, government and public services online, but they bear the heavy responsibility of balancing rapid speed-to-market goals, high software quality and mitigating security risk.

This balance has been, to date, immensely difficult to strike. It has led to development teams that are often fragmented, with a general primary focus on delivering features and functions, without consideration of the vulnerabilities they could be creating in the code they are so quickly churning out. AppSec specialists constantly fix the same mistakes, while the threat of a breach from a relatively simple back door being left open looms large.

If our data is to remain safe, CISOs and CIOs need to get creative with the way their teams work together, and forge a culture of positive security and shared responsibility from the top down. Just look at the catastrophic consequences faced by Marriott as a result of their 2018 breach: A GDPR fine of over USD $123 million, more than 500 million records stolen and a security reputation in tatters. This disaster occurred in major part as a direct result of insecure coding practices, with SQL injection vulnerabilities uncovered as early as 2014 on Starwoods servers, a company acquired by Marriott in 2016. Their subsequent use of the software clearly went unchecked from an application security perspective. This gave malicious attackers multiple years to access and acquire data, while other vulnerabilities, like weak passwords, left more holes to exploit over time.

CIOs and CISOs need to consider the state of their own software security climates very carefully. How security-aware is the average developer? How well are the AppSec and development teams working together? There is no "magic wand" fix, but the culture, training and support can be worked on and improved. Development teams can transform from the first line of data breach risk in the organization, to the security superheroes that stop bad code before it ever goes to production.

Secure coding health check: Is yours on life support?

Where does your own dev team fit? I have created this secure coding checklist to help CIOs and CISOs identify whether their development teams are truly equipped to be secure coding champions, helping to innovate with faster, better and safer code (or, indeed, whether you're in need of security program overhaul):

1. How supportive is the rest of your C-Suite? Do they understand that traditional network security is no longer enough?

In the future of software, securing the network layer using outdated security measures is simply not good enough (and, let's face it, is rarely successful anyway) even against semi-professional hackers. Among many consistent reports, Verizon's "2017 Data Breach Investigations Report" cites that a staggering 35 percent of data breaches today are caused by web application vulnerabilities.

Web application security is equally as important as network security; ignoring this and failing to budget for and instill the fundamental, basic protective layer of AppSec measures could leave you well and truly open to a breach.

2. Do you shift far enough left, and are you doing it early enough?

The current approach to application security is quite tool-heavy, focusing on moving from right to left in the software development life cycle (SDLC). This, by definition and design, acknowledges the process is flawed and supports a detection and reaction outcome. Security teams are searching for and detecting vulnerabilities in code that is already written, reacting to fix committed code instead of ensuring it is bug-free as it crafted. According to the National Institute of Standards and Technology (NIST), it is 30 times more expensive to detect and fix vulnerabilities in committed code than it is to prevent them as they are written in the IDE. This doesn't even take into account the production delays, double-handling and time spent in remedying the same well-known security issues over and over.

A truly robust security culture insists on starting left, inspiring security champions within the developer cohort, while giving the development team the right tools and training to grow and act with a secure coding mindset. There is a focus on continuous self-development, and flexing their problem-solving muscles so they can be the first line of defense in their organization, preventing common vulnerabilities from occurring in the first place.

3. Are you making the effort to build practical security skills, or are you just feeding one-way knowledge?

The vast majority of security training solutions (online and CBT) focus on building knowledge instead of practical skills that directly relate to their jobs. For developers to thrive and engage in writing secure code, they need regular access to contextual, hands-on learning that actively encourages them to keep training and developing skills in a real environment. They need to learn about recently identified vulnerabilities, with real code examples, and be able to work in their preferred languages and frameworks. This learning experience is effective in helping them understand how to locate, identify and fix known vulnerabilities in the code they are actively working on in the course of their jobs.

While there are many knowledgeable teachers out there, and plenty of information on fixing security vulnerabilities, thumbing through textbooks or watching hours of video fails to engage the mind of many creative, problem-solving developers, and if the constant stream of data breaches is any indication, remains largely ineffective in preventing vulnerabilities from entering code.

4. Are you measuring your secure coding skills with real-time metrics?

A vital step in ensuring a security-first mindset is being built within a development team is to collect and review evidence. This should not be an assumption or a guessing game: developers are either security-minded, or they are not.

Metrics seek to prove to the developer and their organization that their hard work is paying off, and their individual secure coding skills are improving. You can't improve what you cannot measure. There should be relevant assessments, and these should help identify the progress of your development teams in real-time as well as benchmarking their secure coding strengths and weaknesses for continuous improvement.

Too often, security training becomes a "tick-the-box" exercise for organizations, with no emphasis on ensuring this training has been effective, engaged with or even retained.

5. Are your outsourced vendors using robust secure coding techniques?

Many organizations decide to contract out development work to third-party agencies. Whether they exist on- or offshore, their general secure coding abilities and practices are a relative mystery to their client. In the best case, the only form of assurance an organization will receive relating to security is a statement in the contract requiring the deliverable to be "secure." Very few companies take measures to verify the skills of these development houses upfront, thus running the risk of being delivered software that works as briefed, yet has been built without following sound secure coding practices. Worse yet, if the purchasing company is not aware of any inherent security flaws within the application, it risks sending vulnerable software out into the wild.

The most common scenario is that any vulnerabilities get picked up by dedicated security specialists (individuals that are difficult to source and come at a high cost) you are faced with a delay of your go-live date, and possible contractual discussions on who needs to pay for fixing these security weaknesses. However, if you're smart upfront and assess the application security skills of the developers who are going to build your next application, you save a lot of potential delays, frustration, and cash.

6. Are your developers aware of the most commonly exploited security weaknesses?

More than 85 percent of exploited web application vulnerabilities are attributed to just 10 known vulnerabilities"the OWASP Top 10. At a bare minimum, your application security training must cover these, in addition to many more vulnerability types. The training challenges your developers contend with must be revised and updated on a regular basis, with new challenges for either new coding frameworks or new vulnerability types.

Precision training using real-world secure coding scenarios should be the standard; vague general knowledge is simply not effective. (Wondering what these secure coding scenarios could look like? Check out our Coders Conquer Security blog series; there's a playable challenge in each post).

7. Do you have in-house security champions?

Every developer-heavy organization should invest in a security champion"someone who is going to take responsibility for upholding a high security standard within the dev team. Their purpose is to be a support point of contact for anyone with questions around security, as well as become the chief advocate for following security best practices.

They are a vital piece of the security culture puzzle; a great security champion can keep the momentum going from intensive training, ensure all members of the team have what they need and continue advocating for support.

8. Have you invested in tools for your developers to make secure coding easier?

If your organization is one in which agile development is practiced, or indeed you are faced with frequent updates to company-built applications, automating parts of your security is one of the only ways to keep up with the frantic pace and volume of work.

There are tools available at each stage of the SDLC that will serve as advisers, quality gatekeepers or detection tools. In addition, some tools run automated tests over the code, simulating attempted hacking once the software is in production. All have their own set of benefits and challenges, and none can provide a catchall, 100 percent guarantee that no security threats exist within the application. The number-one preventative measure you can employ is that the earlier you can capture the weakness, the faster and cheaper it is to remediate it with the least impact on your business.

The next step for forward-thinking CISOs

So, how did your organization fare against the above checklist?

While CISOs and CIOs are essentially forced to aggressively build their enterprise DevOps and DecSecOps capabilities, that doesnt mean there is no time to consider and implement the right tools and training across teams. Secure coding skills will be a weapon"not a hindrance to"innovation, and foregoing them could spell the absolute destruction of company reputation and data. These skills represent critical capabilities and a much cheaper long-term solution to reducing vulnerabilities and mitigating risk.

A brilliant, innovative CISO has the power to orchestrate a healthy security culture from the top down; ensure your staff has what they need to execute security best practices effectively.

Pieter Danhieux is a security expert and the co-founder of Secure Code Warrior.

Table des matières

Télécharger le PDF
Afficher la ressource
Vous souhaitez en savoir plus ?

Chief Executive Officer, Chairman, and Co-Founder

learn more

Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Réservez une démoTélécharger
Partagez sur :
linkedin brandsSocialx logo
Centre de ressources

Ressources pour vous aider à démarrer

Plus de posts
Centre de ressources

Ressources pour vous aider à démarrer

Plus de posts