When it comes to deploying secure infrastructure as code in your own organization, how are you doing? It might be somewhat of a learning curve, but learning the ropes will be a great chance to level up your skillset, stand out among your peers, and keep more end-user data safe.

Before we get started on this next chapter of our latest Coders Conquer Security series, I'd like to invite you to play a gamified challenge of the sensitive data storage vulnerability; play now and choose from Kubernetes, Terraform, Ansible, Docker, or CloudFormation:

How was that? If your knowledge needs some work, read on:

The key to most computer security these days involves passwords. Even if other security methods are employed, like two-factor authentication or biometrics, most organizations still employ password-based security as one element of their protection. For many companies, passwords are exclusively used.

We use passwords so much that we even have rules about how to create them. This is supposed to make them less vulnerable to brute force attacks or even wild guessing. Of course, some people still use weak passwords, as evidenced in a recent report from NordPass. It's hard to believe that in 2020 people are still using 12345 as well as a bunch of other guessable words like chocolate, password and God to protect their most sensitive assets.

There will always be those who don't care to use strong passwords, but most professional organizations will force users to craft their access words or phrases in certain ways. We all know the rules by now with passwords needing to be at least eight characters and comprised of both capital and lower case letters with at least one number and a special character required.

The bad thing is that even if users adhere to the rules for making the strongest kinds of passwords, it may not do any good if they are all stored in plaintext. The password 12345 is just as bad as Nuts53!SpiKe&Dog12 if a hacker is able to read the entire password file.

Why is storing passwords in plaintext dangerous?

Storing passwords in plaintext is bad because it puts both the system and users at risk. Obviously, having a hacker able to find and read every single password used to access a system would be a disaster. They could simply find a user with administrator credentials and compromise the entire system or site. And because they would be utilizing proper user names and passwords, internal security may not catch the intrusion or catch it long after the damage is done.

Making it easy for attackers to steal passwords stored in plaintext also hurts users, because many people reuse passwords. Because we have made passwords so difficult to create, a lot of people resort to reusing ones that they can remember on multiple sites. If an attacker compromises a password file, they will almost certainly try to access other systems using the same name and password, which puts users at great risk of secondary crimes.

It's relatively easy to accidentally store passwords in plain text or not realize that this could cause major problems down the road. For example, the following code is a common method employed to store passwords when defining an AWS resource using Terraform templates:

resource "aws_db_instance" "default" {
 engine                 = "mysql"
 allocated_storage      = 10
 instance_class         = "db.t2.micro"
 username               = "admin"
 password               = "s3.cr3t.admin.p2ss"
 db_subnet_group_name   = aws_db_subnet_group.default.name
 vpc_security_group_ids = [aws_security_group.default.id]
}

In that example, the password used to manage the MySQL database instance in AWS is being stored in plaintext. That means that anyone with access to the source code repository could read, or even copy it.

Protecting passwords varies depending on the framework, but protection methods exist for every platform. For example, MySQL password can be stored in a  secure storage like AWS Secrets Manager:

resource "aws_db_instance" "default" {
 engine            = "mysql"
 allocated_storage = 10
 instance_class    = "db.t2.micro"
 username          = "admin"
 password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
 db_subnet_group_name   = aws_db_subnet_group.default.name
 vpc_security_group_ids = [aws_security_group.default.id]
}

In that example, the Terraform template will get the password from AWS Secrets Manager service and it will never be stored in plaintext in template files.

Protecting passwords by avoiding plaintext storage

Passwords are the keys to your kingdom and should never be stored in plaintext. Even those internal to an organization shouldn't have access to a big, unprotected repository of passwords, nor should this be an accepted business protocol (there are plenty of password managers that allow encrypted credential sharing these days - no excuses!). There is also the danger of malicious insiders snooping files and gaining access where they shouldn't.

And with an outside attack, just imagine the double-whammy that is possible if a back door to your database is found through something as simple as a SQL injection vulnerability, and they gain access to the directory where the passwords are stored as well. Think this is too many error-laden steps to come to fruition? Sadly, this exact scenario happened in Sony's 2011 breach. Over one million customer passwords were stored in plaintext, and the Lulzsec hacking group accessed those and much more through a common SQL injection attack.

All passwords should be protected by whatever defenses are available within the supporting framework. For Terraform, passwords should never be stored in template files. It is recommended to use secure storage like AWS Secrets Manager or Azure Key Vault, depending on the infrastructure provider.

Forcing users to create secure passwords is a good idea, but then you need to do your part on the backend as well. Keeping passwords out of plaintext storage will go a long way to protecting your users and your systems. The main danger of plaintext password storage is the poor access control; essentially, anyone can see them. It's imperative (especially in an IaC environment where suddenly, more people have access to sensitive information) that they are adequately hashed and only those who absolutely require access are granted it.

Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and your customers from the ravages of other security flaws and vulnerabilities. You can also try a demo IaC challenge within the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up to date.

Anyone who has worked in software production is likely aware of the tension that can arise when it comes to factoring in security, mostly between developers and the security specialists scrutinizing their code.

In the old days, it wasn't uncommon for the development team to ship code as late as possible, deliberately shortening the window in which the security gurus could check for vulnerabilities - after all, this delayed releases if anything happened to be wrong, and there was already the desire to move on and start building the next awesome feature. However, this had an eventual negative impact, as when the code was eventually checked -- sometimes after an external breach had already occurred -- the code would still bounce back to the developers, their software babies were still called ugly by the security team, and they'd have to drop everything to hotfix code they'd last touched months ago.

This dysfunction continues today, but there is a huge problem: there is much more code being developed, and society is at far greater risk in the event of data breaches occurring. We no longer have time to keep fighting this ancient battle, and in 2020, it's time we all joined the same side against the bad guys.

We must get to a stage where security is seen as a shared responsibility across the entire organization, and throughout the SDLC. This is certainly possible when you commit to a fully-fledged, highly supportive DevSecOps environment. What's more, when you ignite the security fire in your development team with the right training and tools, they are a powerful force in not only squashing bugs, but taking the load off the security specialists who have been spread too thin, for too long.

I'd love you to watch one of my latest webinars, How to put the "Sec" in DevOps:

This was part of the AllTheTalks 24-hour summit event, and it takes a deep look into:

• Why older development methodologies made security best practice so much harder
• Why DevSecOps is the latest game-changer in stopping common security vulnerabilities
• What security as a shared responsibility looks like in an organization
• How you can empower developers to ship secure code with confidence, without sacrificing what they love (hint: it's building awesome features).

See you there!

Threats to cybersecurity these days are ubiquitous and relentless. As more facets of our lives are digitized, the higher the stakes for cybercriminals - there is too much code to keep secure, and private data is too valuable. And, well, trying to keep up with and defend every aspect of the attack surface after programs are deployed has become almost impossible.

There are approaches that can alleviate some of these symptoms, and one of them is apparent when shrewd organizations embrace the concept of Infrastructure as Code (IaC). Of course, as with any development, there are some security pitfalls to navigate. And since developers are working on the code that generates vital infrastructure to host applications, security awareness is critical at every stage of the process.

So, how exactly would a developer new to a cloud server environment go about upskilling, learning the ropes, and approaching the build with heightened security awareness? We have created the next Coders Conquer Security series to tackle common IaC vulnerabilities, and these next few blogs will focus on steps you, the developer, can take to begin deploying secure infrastructure as code in your own organization.

Let's get started.

There is a fable from the American Old West about a man who was paranoid that bandits would attack and rob his homestead. To compensate, he invested in all kinds of security like installing an extra-strong front door, boarding up all of his windows, and keeping lots of guns within easy reach. He was still robbed one night while he slept because he forgot to lock the side door. The bandits simply found the disabled security and quickly exploited the situation.

Having disabled security features in your infrastructure is a lot like that. Even if your network has a strong security infrastructure in place, it does very little good if elements have been disabled.

Let me pose a challenge before we dive in:

Visit the link above, and youll be transported to our gamified training platform, where you can attempt to defeat a disabled security feature vulnerability right now. (Heads up: It will open in Kubernetes, but use the drop-down menu and you can choose from Docker, CloudFormation, Terraform and Ansible).

How did you do? If you still have some work to do, read on:

Security functions can be disabled for a variety of reasons. With some applications and frameworks, they may be disabled by default and must first be turned on to start functioning. It's also possible that administrators have disabled specific security functions in order to more easily perform certain tasks without getting constantly challenged or blocked, (i.e. making an AWS S3 bucket public). After their work is complete, they may forget to reactivate those disabled functions. They might also prefer to leave them turned off to make their job easier in the future.

Why disabled security features are so dangerous

Having one or more disabled security features is bad for a couple of reasons. For one, the security feature was put into infrastructure resources to protect against a known exploit, threat, or vulnerability. If it's disabled, then it won't be able to protect your resources.

Attackers will always attempt to find easily exploitable vulnerabilities first and may even use a script to run through common weaknesses. It's not unlike a thief checking all the cars on a street to see if any doors are unlocked, which is a lot easier than smashing a window. Hackers might be surprised to find that a common security defense is inactive. But when that happens, it won't take them long to exploit it.

Secondly, having good security in place and then disabling creates a false sense of security. Administrators may think they are protected from common threats if they don't know that someone disabled those defenses.

As an example of how an attacker could take advantage of a disabled security feature, consider the AWS S3 security feature of block public access. With Amazon S3 block public access, account administrators and bucket owners can easily set up centralized controls to limit public access to their Amazon S3 resources. However, some administrators encountering problems when accessing the S3 bucket decide to make it public in order to complete the task as soon as possible. If they forget to enable that security feature, an attacker will have complete access to the information stored in that S3 bucket, causing not only information disclosure but also incurring extra costs due to data transfer charges.

Lets compare some real-world code; check out these CloudFormation snippets:

Vulnerable:

CorporateBucket:
   Type: AWS::S3::Bucket
   Properties:
     PublicAccessBlockConfiguration:
       BlockPublicAcls: false
       BlockPublicPolicy: false
       IgnorePublicAcls: false
       RestrictPublicBuckets: false
     VersioningConfiguration:
       Status: Enabled
     BucketEncryption:
       ServerSideEncryptionConfiguration:
         - ServerSideEncryptionByDefault:
             SSEAlgorithm: "AES256"

Secure:

CorporateBucket:
   Type: AWS::S3::Bucket
   Properties:
     PublicAccessBlockConfiguration:
       BlockPublicAcls: true
       BlockPublicPolicy: true
       IgnorePublicAcls: true
       RestrictPublicBuckets: true
     VersioningConfiguration:
       Status: Enabled
     BucketEncryption:
       ServerSideEncryptionConfiguration:
         - ServerSideEncryptionByDefault:
             SSEAlgorithm: "AES256"

Preventing disabled security features

Stopping disabled security features from negatively harming your organization is as much a matter of policy as practice. There should be a firm policy in place stating that security features should only be disabled under very specific circumstances. Incidents where features must be temporarily disabled to work on a problem or update applications should be logged. After the required work is complete, the features should be checked to ensure that they have been fully reactivated.

If a security function must be permanently disabled in order to streamline operations, other protections should be provided to affected data to ensure that hackers won't be able to access it in the absence of the default protection. If a needed protection feature has been disabled, it's only a matter of time before an attacker finds that unlocked door and exploits the situation.

Learn more, challenge yourself:

Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and your customers from the ravages of other security flaws and vulnerabilities.

Ready to find and fix this vulnerability now youve read the post? Time to try an IaC gamified security challenge on the Secure Code Warrior platform to keep all your cybersecurity skills honed and up to date.

This is a weekly series covering our top eight Infrastructure as Code vulnerabilities; check back next week for more!

It's time for the next installment of our Infrastructure as Code series, the blogs that will take developers like you to a whole new level of security awareness when deploying secure infrastructure within your own organization.

Oh, by the way... how did you fare with the security misconfiguration challenge in the previous blog? If you want to go ahead and tackle a missing functional level access control vulnerability right now, head on over to the platform:

(The link above will take you to the Kubernetes challenge, but once youre on the platform, use the drop-down to choose from Ansible, CloudFormation, Terraform or Docker as well. Your choice.)

Almost every application deployed today has some kind of access control mechanism that checks to see whether or not a user has permission to perform the requested functions. It's pretty much the cornerstone of good security, as well as functionality, when creating an application. In fact, all web applications need access controls in order to allow users with different privileges to use the program.

Problems can occur however when those same verification functions for access control are not performed at the infrastructure level, or are misconfigured. Without infrastructure-level access control in perfect order, it opens up an entire enterprise to hackers, who can use that vulnerability as their gateway for either unauthorized snooping or a full attack.

In fact, exploiting missing or misconfigured function access control vulnerabilities is extremely easy. Attackers don't even need to be overly skilled. They just need to know what commands execute functions within whatever framework is supporting the application. If they do, it's just a matter of trial and error. They can continually submit requests that shouldn't be allowed, and as soon as one succeeds, the targeted website, application, server, or even the entire network could be exposed.

How Do Missing Function Level Access Control Exploits Work?

There are a few ways that function level access controls can creep into an organization. For example, function level access can be left to an application and not verified by the underlying infrastructure. Or, infrastructure-level access control can be misconfigured. In some cases, administrators assume that non-authorized users won't know how to get to infrastructure resources that only higher-level users should be able to see and use a "security by obscurity" model which rarely works.

For an example of security by obscurity, the following URL is likely vulnerable to attack:

http://companywebsite.com/app/NormalUserHomepage

If an authenticated user employs a technique called Forced URL Browsing, they could try to reach a page that is only shown to administrators. An example might be:

http://companywebsite.com/app/AdminPages

If no server-side verification exists, they will simply be shown the admin pages (if its name matches the request) and will then have access to whatever additional functions that administrators do from the new page. If the server returns a "page not found" error to the attacker, they can simply keep trying until they figure out whatever name the admin page is given.

For attackers, exploiting missing function level access controls is a similar process. Instead of trying to browse unauthorized pages, they instead send in function requests. For example, they might try to create a new user with administrator rights. So their request would look something like this, depending on the framework:

POST/action/createuser name=hacker&pw=password&role=admin

If no function level access control exists, then the example above would be successful and a new administrator account would be created. Once the attacker logs back in as the new administrator, they would have the same access and permissions as any other administrator on that network or server.

The Fix for Missing Function Level Access Controls

Because it's so easy for attackers to exploit missing function level access control vulnerabilities, it's critical that they are found, fixed, and prevented. Thankfully, this is not overly difficult with some know-how and basic Infrastructure as Code security training.

The main protection will come from implementing role-based authorization at the infrastructure level. Never trust applications to handle that function. Even if they do, having infrastructure-side authorization will ensure that nothing is missed. Ideally, the authorization should come from a centralized location (for example, AWS IAM, Azure IAM, etc.) that is built into your organization's routine and applied to every new application. These authorization processes can come from the framework itself or any number of easy-to-use external modules.

Finally, your organization should embrace the concept of least privilege. All actions and functions should be denied by default, with the authorization process used to give valid users permission to do whatever they need. They should only be given enough permission to perform the required function, and only for as long as required.

Having missing function level access controls can be devastating. But thankfully, by building good infrastructure-level authorization practices into your organization, you can easily prevent this problem from ever happening.

Think you're ready to spot an access control bug in the wild? Compare these Docker code snippets; one vulnerable, one secure:

Vulnerable:

FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=mysqld_exporter-${VERSION}.linux-amd64
ARG URL=https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$FILENAME.tar.gz && \
   tar -xvf $FILENAME.tar.gz && \
   mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER root
EXPOSE 9104
ENTRYPOINT  [ "sh", "~/entrypoint.sh" ]
CMD  [ "/bin/mysqld_exporter" ]

Secure:

FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=mysqld_exporter-${VERSION}.linux-amd64
ARG URL=https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$FILENAME.tar.gz && \
   tar -xvf $FILENAME.tar.gz && \
   mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER nobody
EXPOSE 9104
ENTRYPOINT  [ "sh", "~/entrypoint.sh" ]
CMD  [ "/bin/mysqld_exporter" ]

Learn more, challenge yourself

Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and your customers from the ravages of other security flaws and vulnerabilities.

And if you missed it earlier, you can try an IaC gamified security challenge on the Secure Code Warrior platform to keep all your cybersecurity skills honed and up to date.

Stay tuned for the next chapter!

This is part 2 of a mini-series on PCI-DSS compliance within an organization. In this final chapter, we detail how CTOs and CISOs can lead from the top in reducing cyber risk and making the process seamless, successful... and maybe a little fun for developers. (Did you miss part 1? Check it out here and learn how AppSec specialists can seize this opportunity for better security outcomes).

PCI-DSS best practice is undoubtedly a shared responsibility, but CISOs and CTOs can harness their considerable influence in crafting a thriving, positive security program from the top. They are the figurehead for cybersecurity trust and related sentiment with end-users, and a focus on awareness early has a powerful trickle-down effect, helping developers and AppSec professionals get the knowledge, tools and support they need to contribute to a robust security posture within the company.

Its important to stay compliant, but when everyone is on board with the "why", seeing results and being nurtured in the right way, a program can transcend legislation and become second-nature.

CTOs and CISOs have a role in creating mutual trust

Have you been on a site recently, and thought twice about handing over your credit card details? Unless it's the sketchy-looking web app powering the online ordering for your local pizza shop, this likely isn't something you experience very often, especially not with large corporations and household names in online retail.

Unless they disclose a data breach, of course.

Global accommodation giant, Marriott, just disclosed their second breach in the space of three years, with this one resulting in the theft of 5.2 million customer records. This time, it doesn't yet appear as though payment information was part of the heist, though their catastrophic breach in 2018 took care of that; 383 million customers were compromised, with 5 million unencrypted passport numbers stolen, as well as 8 million credit card numbers.

If customer trust in the Marriott brand wasn't already as low as it could get, I'd say it's close to hitting rock bottom soon. This is the sort of stuff that keeps CISOs awake at night, as they feel like sitting ducks in the war against cyber threats. Just look at Equifax, Yahoo, Sony, Target - these are just a few huge names that have endured large-scale breaches, representing billions of stolen data records, hundred of billions of dollars in damage, and customer-shaped holes punched right through their economic hearts. It's a disaster for the business (Target reported a $440 million profit plunge in the quarter following their 2014 breach), and while individual people aren't typically held responsible -- after all, software security should be a shared responsibility -- it's something you don't exactly want on an otherwise glowing resume if you happened to work for these organizations at the time.

Foregoing a robust security program to achieve compliance in an organization dealing with payments, sensitive data and the intangible gold that is positive customer sentiment, is an indicator of a company that is not only at-risk, but seriously lagging behind in innovation.

Everyone should care about trust issues in the customer/organization relationship.

Apart from the stress and calamity the IT, development, and security departments face after a breach, the trust factor is a major element in the long-term success of a newer company, or the continued growth of an established one. The obvious thing you stand to lose is your job, should the company be faced with an economic downturn as a result of lost faith.

The PCI-DSS regulations hold businesses accountable -- and as above, ignoring these well-laid plans has enormous implications -- but they're only as good as the security program that is put in place, and the people working within it. If you take them seriously, stay aware, and set an example for others, then you are setting yourself apart in a very positive way.

Awareness is everything.

A failing security awareness program is going to make most attempts to stay PCI-compliant close to useless. Organization-wide security awareness forms the most critical part of the best practice guidelines; they even offer their own training modules on how this can be implemented in cross-functional roles, and what this looks like in businesses who are doing it right.

As we move towards DevSecOps as the current gold standard in secure software development -- in which security as a shared responsibility is fundamental -- businesses must spend the time, money and effort to ensure everyone, including vendors and contractors, is security-aware and following best practices.

A security-aware developer is a compliant developer (and getting there doesn't have to be boring)

When it comes to becoming a "certified" compliant PCI-DSS developer, there aren't a whole lot of obvious options. Why? Probably because it cannot be a "one and done" exercise.

The OWASP organization is one of the best on the planet when it comes to learning how to thwart common vulnerabilities, and their Top 10 is formally listed in the PCI-DSS guidelines for developers. However, keeping security front-of-mind and honing skills takes time and continued effort. And nobody wants this to be uninspiring and a waste of effort.

A positive security culture is not a "nice to have" in an organization; if they're taking security seriously, then it needs to be part of the everyday running of the company.

Developers are on the front lines of battle when it comes to stopping vulnerabilities. Are they receiving the support, tools, and training to hold up their part of the security deal in PCI-DSS compliance?

The truth is, the right training is more seamless; it shouldn't feel like a lecture, and it should be highly relevant to the work being done every day. And this kind of hands-on training is an upskilling opportunity - a career move that only has positives for developers who are serious about stopping vulnerabilities and working with the rest of the team to produce a higher standard of code.

Want to test your secure coding skills right now? Choose your mission.

This is part 1 of a two-part series on successful PCI-DSS compliance within an organization. In this chapter, we detail how AppSec specialists can work closely with development managers to empower developers, strengthen the SSDLC and get specific outcomes from general legislation.

The word "compliance" isn't very exciting. It's formal, dry, directive... even a little restrictive in its tone. If it had a color, it would be beige. And, well, it seems at odds with any sort of creative environment or innovation.

As a developer myself, my experience of "being compliant'usually meant (vertically) reading through some guidelines or watching a presentation, before going back to coding features and focusing on creating software that customers will use and love. Everyone retains what they can in the moment (and tries to do the right thing at all times), but compliance guidelines -- especially those surrounding security best practice -- are not typically written with developers as the target audience, and any required actions can be unclear. In that scenario, it's all too easy to just stay on-task with current objectives.

The thing is, secure software development is no longer a "nice to have" in any company; it is (or should be) front-of-mind in every organization... and if it's holding vast amounts of sensitive customer information, then that company is ripe for the picking when it comes to cyberattacks. Developers are the first to get hands-on with code, and as such, should be just as involved as the rest of the team in any security compliance measures.

But, wait... hear me out. This doesn't mean everyone has to become a slave to rigid, creativity-free development and software outcomes. It means the business has the opportunity and power to create a higher standard of code, together. Ever so slowly, the world is catching up to the fact that, to date, developers haven't exactly had the right tools at their disposal to make security a priority (and siloed security specialists cannot shoulder the responsibility alone). However, as the industry moves towards a DevSecOps future with security as a shared responsibility, they can help stem the flow of recurring vulnerabilities when set up for success.

The PCI-DSS guidelines cover online security compliance for card payment gateways - a service most of us use on a regular basis. These guidelines are globally applicable, and they have actually outlined in detail what developers must do to maintain standards in-line with their mandates, alongside several compliance documents across aspects of eCommerce business.

Data breaches are scary, reputation-destroying risks that businesses can ill-afford, and with Cyber Security Ventures tipping zero-day breaches to reach one per day in 2021, this is something that everyone in the software delivery process can help fight.

Let's break down the PCI-DSS recommendations, and how they can work across the team:

Hey, AppSec and Compliance teams: All developer training is not created equal

Developers in large (or even small) organizations rarely have a whole lot of input into the training they receive on-the-job. In order to retain star employees, some companies do offer comprehensive programs, but these are still less common than they should be. A need for security training presents a great opportunity to not only kick-off organizational compliance without boring everyone to tears, but also start to warm up any frosty relationships with the development team.

In terms of PCI compliance, you can see that their guidelines are specific as to the outcomes they would expect from any software running payment gateways; among other objectives, they want applications hardened (vital for thwarting malicious code injection or tampering), least-privilege controls and full-scale awareness of common vulnerabilities... at a minimum. All personnel working with cardholder data must be adequately trained, and for developers, that training can make or break their success in writing secure code from the start of their process.

The official Best Practices for Maintaining PCI-DSS Compliance document details some direct concepts around security awareness, developer needs, and appropriate training, like:

Copyright © 2006 - 2020 PCI Security Standards Council, LLC. All rights reserved.

This gives insight into the specific, in-depth training required to arm developers with the necessary skills, but still doesn't point to any particular types of educational solutions as more effective than another. The PCI-DSS Guide for Developers gets a little more direct, identifying the OWASP Top 10 as one benchmark for learning to find and fix the most common vulnerabilities, as well as some certification programs.

But... here's the rub. As you would no doubt know from various workplace training and compliance initiatives, they can vary wildly in quality and future success. And when it comes to developers, so many secure coding training programs don't seem to cater to our needs, ways of working or even our day-to-day jobs in any meaningful capacity. In this scenario, not all training is created equal, and not all training is going to result in software that is more secure. This is, of course, the exact opposite of your desired outcome, and won't make the stress of your own job reduce in any significant measure. If you want to reduce the burden and stop common vulnerabilities from causing potential disasters, you'll need to build a bridge.

Bridging the security skills gap with engineering managers on your side

Working directly with engineering managers to find a solution that is fit for purpose, while still being embraced by the people who actually have to do it, is a fast-track to positive security outcomes. They will have more immediate insights into their own team, and can speak to any blockers that have previously made compliance training difficult (other than it not being a great experience, most of the time).

Classroom-based training, video-on-demand and any once-off, tick-the-box exercises make staying current very difficult; these are static solutions that cannot keep pace with the ever-changing landscape that is the cybersecurity industry. Ultimately, the engineering manager will want to see value for the time commitment, and it's important to work with them and provide viable options that work to meet everyone's shared goal: code that is more secure and compliant.

So, what does good training look like? There is very little point to learning how to code securely via big, once-off hits of information. A bite-sized, gradual learning process makes it far easier to remember and apply in-context, and it absolutely must be in the languages and frameworks used every day. Personally, I want to be challenged, and I want to see a purpose for my efforts - we're all busy enough as it is, right?

To comply with the PCI-DSS best practices outlined above, depending on the solution chosen, managers might find themselves a having to stitch together a patchwork of different courses to cover all languages and frameworks used across the business, and that's when things get very messy, not to mention difficult for AppSec and compliance teams to assess as making an impact on security and vulnerability reduction in software. Work together to find the right fit, instead of rushing into the wrong option chasing a fast result. Otherwise, you might end up with a Frankenstein training solution... and that looks very scary.

Thanks for checking out part one of this PCI-DSS mini-series. In the final chapter, we will discuss how CISOs and CTOs can help this culture transformation, enable teams, and how the security front lines " your developer cohort " can use PCI-DSS awareness and compliance to their advantage.

Much like technology itself, the tools, techniques and optimum processes for developing code evolve quickly. We humans have an insatiable need for more software, more features, more functionality... and we want it faster than ever before, more qualitative, and on top of that: secure. Just a few years ago, Agile development was the next big thing being used to break up big chunks of work into smaller pieces, and being able to quickly adapt to rapid feedback cycles coming from the customer. Before that, the Waterfall method was king of the hill.

While many people and organizations are moving on from Waterfall to Agile -- and not everybody is there yet, let's be real -- they are already encountering a new problem: Development teams and their operations counterparts are still working in silos. In this environment, how can small teams working in an Agile way deliver on that promise of faster deployment, and faster delivery?

DevOps, a moniker that is a combination of development and operations, was created to merge the functions of both developers and operational teams when creating new software. Essentially, this was to help developers take ownership of putting things into production, instead of throwing it over the fence to the operations team and making it their responsibility.

They can certainly ship faster -- even a couple of times per day -- which seems to play in the alley of Agile. However, DevOps still creates one big, mixed team of engineers and operations personnel, which may not be as Agile-aligned in reality. Ultimately, it's best to think of DevOps as an evolution of Agile, as the methodologies are similar in many ways, and complementary in their difference. DevOps promotes an automated, continuous integration and deployment pipeline, which is essential to enable frequent releases, but not as sufficient at the team level - and this is where Agile steps in. Agile allows teams, especially small teams, to keep pace with these rapid releases and changing requirements, while staying on-task and collaborative. It certainly seems ideal -- and the process can keep teams on track with the end goal -- but it is not without its own issues.

Software created using DevOps best practice still has the potential to stumble at the first boss fight: the security team. When the code is examined by traditional/Waterfall AppSec specialists, either with tooling or complex manual review, they often find unacceptable risks and vulnerabilities which must then be fixed after the fact. The process of retrofitting security fixes into completed apps is neither quick nor easy... and it's far more expensive for the organization.

So, then, if the world is moving on past Waterfall, Agile, and now DevOps, what is the solution? And as a developer, what is your role in keeping pace with these changes in approach?

Development techniques are in a constant state of evolution, but thankfully, this one isn't such a huge change. Organizations just need to put the "Sec" in "DevOps"... and so, DevSecOps was born. A primary goal of DevSecOps is to break down barriers and open collaboration between development, operations and, last but not least, security teams. DevSecOps has become both a software engineering tactic and a culture that advocates security automation and monitoring throughout the software development lifecycle.

This might seem like yet another organization-level process, perhaps one with "too many cooks" when it comes to a developer with a long list of features to build. However, the DevSecOps methodology opens up an opportunity for security-aware developers to really shine.

The bright future of DevSecOps

So, why would a coder want to become a DevSecOps engineer? Perhaps you have some experience with DevOps (or even Agile) but want to take the next step to become proficient in DevSecOps. First off, it's good to know that it's a very smart move, and not just in the quest to make the world safe from costly cyberattacks. Experts say that the demand for talented cybersecurity personnel is skyrocketing with no end in sight. Those who master DevSecOps can expect a long and profitable career.

Job security for DevSecOps engineers is even more assured, because unlike traditional cybersecurity tactics like vulnerability scanning with an array of software-based tools, DevSecOps requires people who know how to implement security as they code. As Booz, Allen and Hamilton's analysts noted in their blog entitled 5 Myths of Adopting DevSecOps, organizations want and even need DevSecOps, but simply can't buy it. DevSecOps is a methodology that lets cross-functional teams integrate technologies and collaborate during the whole software development lifecycle, and that requires skilled people, change management and an ongoing commitment from multiple stakeholders.

According to Booz, Allen and Hamilton, companies can purchase apps and tools to help with certain aspects of DevSecOps, like release management software, "but it's really your delivery teams that make it happen." They are the ones driving the continual improvement offered by DevSecOps and its cultural and paradigm shift.

Organizations cannot  "buy" a viable DevSecOps program; it must be built and maintained, using a range of tools, in-house knowledge and guidance that uplifts the security culture, while also making business sense. It's not easy, but it's far from impossible.

How you can kick ass in the DevSecOps movement

One of the first steps on the path to becoming a DevSecOps engineer is realizing that it's as much a culture as it is a set of techniques. It requires the will to implement security as part of every bit of code that you create, and the desire to proactively protect your organization by actively looking for security flaws and vulnerabilities as you code, fixing them long before they make it into production. Most DevSecOps engineers take their profession and skillset very seriously. The DevSecOps professional organization even has a manifesto stating their beliefs.

The manifesto is kind of heavy-handed, as manifestos are rarely light reading. But at the core are a few truths that all great DevSecOps engineers should learn to embrace, like:

• Realize that the application security team is your ally. At most organizations, the AppSec specialists are at odds with developers, since they are always sending completed code back for more work. AppSec teams don't often have much love for developers either, since they can delay completed code from getting into production through introducing common security bugs. However, a smart DevSecOps engineer will realize that the goals of the security teams are ultimately the same as the developers and coders. You don't have to be best friends, but forming a calm and collaborative work relationship is vital to success.
• Practice and refine your secure coding techniques. If you can find ways that apps are vulnerable while they are still being built, then closing those loopholes can stop future hackers in their tracks. Of course, this requires both an understanding of vulnerabilities and the tools to help fix them. The Secure Code Warrior blog pages can give insight into the most common and dangerous vulnerabilities you will encounter, as well as practical advice and challenges to test your knowledge. The most important aspect is keeping security front-of-mind, and making time for bite-sized training that helps you build on existing knowledge. It's common for a developer's interactions with security to be fairly unremarkable - even negative - but upskilling in security is a great career move, and it doesn't have to be a chore.
• Remember: DevSecOps superstars contribute to a positive security culture at their organization. Instead of focusing on the goals of the past, like delivering apps quickly regardless of their inherent problems, it's important to make finding and fixing vulnerabilities in developing code a top priority. Security must be seen as everyone's job, and everyone should share in the adulation and rewards that come from deploying effective and highly secure applications each and every time.

You can assist in cultivating an incredible security culture at your organization by championing secure coding and security best practice from the ground up, recommending training solutions and ensuring no coder is left behind in the all-hands-on-deck, fast-paced world of DevSecOps. The only good code is secure code, and skilled, security-aware developers are vital pieces of the puzzle. The personal and professional rewards are certainly worth the effort, and with billons of personal data records compromised every year (and growing), we need you. Take your spot on the front lines and help defend against the bad guys in our digital world.

Matias Madou, Ph.D. is the CTO and co-founder of Secure Code Warrior. He is a security expert, long-time developer, and Fortnite junkie.

There's a well-known theory that cockroaches can survive basically anything - even a nuclear explosion. While that theory only rings true to a point, their simple body composition makes them extremely hardy for their size, and difficult to eradicate under most conditions.

I've been thinking... if cockroaches had an equivalent in the digital world, it would have to be SQL injection (SQLi) vulnerabilities in code. This has been a known vulnerability for more than twenty years, yet organizations fall victim to them time and time again. The widespread, costly attack on Target was the result of SQL injection, as was an instance of election hacking in Illinois in which 200,000 voter records were exposed, prompting the FBI to recommend all IT admins work quickly to strengthen their security practices.

Imperva's Hacker Intelligence Initiative Report revealed that between 2005 and 2011, SQLi attacks were used in 83% of all reported data breaches. Today, injection vulnerabilities remain the number-one threat in the OWASP Top 10. They are relatively simple, yet they just won't die.

It seems ridiculous that this same vulnerability is still appearing in a significant number of application security scans. We know how it operates, and we know how to stop it. How is this possible? The truth is, our software security has a vast amount of room for improvement.

Veracode's State of Software Security Report - based on 400,000 application scans in 2017 " revealed an alarming statistic: just 30% of applications passed OWASP Top 10 policy. This has been a consistent theme over the past five years, with SQL injections appearing in almost 1 in 3 newly scanned applications. This is evidence of an endemic issue; we are not learning from our mistakes, and CISOs seem to face an uphill battle in being able to procure enough security talent. Typically, the ratio of AppSec specialists to developers is an inadequate 1:100.

Why is software security on life support?

It's no secret that specialist security talent is scarce, but we must also pay attention to the fact that developers are not fixing issues as they arise, and are quite clearly ill-equipped to not introduce vulnerabilities in the first place. In the same Veracode report, it was divulged that there were documented mitigations for just 14.4% of all development vulnerabilities. In other words, most vulnerabilities were submitted without development mitigation. Fewer than one-third of vulnerabilities were closed in the first 90 days, and 42% of vulnerabilities were never closed within the development period.

I speak to security professionals, CISOs and CEOs all the time, and anecdotally, I've become aware that many companies become so frustrated with the number of vulnerabilities found that can't be mitigated (in addition to the scourge known as false positives), that they stop scanning for them altogether, cross their fingers and hoping for the best.

Why do AppSec professionals let this happen?

Make no mistake: AppSec people are painfully aware of problems in code. After all, that's one of their core skills that makes them such a valuable team resource. However, they are often hamstrung by several factors.

For instance, an AppSec manager will find an issue and ask the developer, "can you fix the code?". The answer to this important question differs from organization to organization, but in general, the developer is so stretched meeting strict feature delivery sprints that they simply don't have the time to fix these problems, nor decent tools to help them. AppSec professionals themselves might be able to identify vulnerabilities, but they often don't have the skills and/or access to remediate them on the spot.

We must also realize that for every problem, there is a process of needing to find a solution, implement it, and then test it. For even the slightest issue found in the code, the time it can take to fix, not mention the resources required, is immense. There are over 700 vulnerabilities that can be introduced into software, and it's simply impossible for any one person to be able to defend against them all. It is for this reason that most companies stick to following the OWASP Top 10 only. All the while, developers keep building features and in turn, they keep introducing vulnerabilities into the code they write.

What is the solution?

The simple fact is, we don't give our developers the tools and training to foster secure coding success. There are no regulations that force organizations to ensure developers possess adequate security skills, and it's a sad reality that most universities and internships don't prepare junior developers to code securely, either.

When someone wants to fly a plane, there is a very rigorous process that ensures training, practical experience, medical checks, safety knowledge and exams before they are able to fly. No-one would dare imagine that they would be let loose in the sky without this extensive preparation and validation of skills, yet this is what happens on a day-to-day basis with code writing.  

We need to spend the time to educate developers on writing secure code. However, in todays world, where software development is fast-paced as well as good developers and security professionals existing in short supply, it never seems to be a priority. It's time we changed the conversation.

A recent headline from the World Economic Forum screamed: "There can be no digital economy without security", with the accompanying content arguing the need for security to be a core part of any digital transformation strategy. "Security is what protects businesses, allowing them to innovate, build new products and services. Beyond a defensive role, security provides businesses with a strategic growth advantage."

Improving secure coding skills and outcomes will add a powerful layer of cyber protection for organizations, assisting them in creating better, faster code. Developers don't need to become security experts, but they must be empowered positively and practically to be the first line of defense against cyberattacks. Developers can be the next security and innovation heroes. They are very clever people, they are creative problem-solvers, and generally keen to build their skills. Play to their strengths with the specialized training they deserve, and commit to a higher software security standard. Read our white paper to find out more.

When someone wants to fly a plane, there is a very rigorous process that ensures training, practical experience, medical checks, safety knowledge and exams before they are able to fly. No-one would dare imagine that they would be let loose in the sky without this extensive preparation and validation of skills, yet this is what happens on a day-to-day basis with code writing.

I was recently interviewed for the Silver Bullet podcast, hosted by Gary McGraw where I discussed the advantages of industry over academic research, why it was non-trivial to start a business in Europe and where the Application Security industry is moving towards in the future.

While it was never my intention to start a business, I did because I saw too many companies struggling with the same problem; writing secure code is a challenge for most developers. We have an entire industry focused on finding security problems in code, and these problems are just piling up.

There are very few solutions that are actually focused on efficiently helping organizations and their development team that struggle with fixing the problems found, and even less on trying to prevent more problems being introduced in code. More and more, organizations are becoming aware of this vicious cycle and are realizing that their development team need to be trained on writing secure code from the beginning and they need to be equipped with the tools and processes to enable them.

If you want to know more about how Gary McGraw and myself see the industry moving forward, check out the the Silver Bullet podcast!

Show 139: Matias Madou discusses secure development training and software security testing research

https://www.synopsys.com/software-integrity/resources/podcasts/show-139.html