Magazine Article | June 1, 2017

Does Your Software Have Good Security Hygiene?

By The Business Solutions Network

The PCI Security Standards Council’s Troy Leach shares where ISVs are struggling when it comes to payment security.

We've often written how difficult it is for software developers to keep up with security standards and new payment technologies when all they really want to do is write code that makes their software better and more powerful for their customers. Unfortunately, if payments are involved, developers need to be involved as well.

The rapid pace of innovation taking place with POS software has created a challenge when it comes to security, a fact that’s not lost on the PCI Security Standards Council. Indeed, a recent conversation with Troy Leach, CTO of the PCI Security Standards Council, makes it clear that the council is putting a lot of effort into getting security and software developers onto the same page.

“One study showed that 43 percent of developers knew they put out bad code with potential vulnerabilities approximately 80 percent of the time.”

Troy Leach, PCI Security Standards Council

Modern Day Security Challenges
According to Leach, one challenge the industry faces today is how many developers have migrated to an agile programming model. “In the past, a software product might get a couple revisions in a year,” he says. “Today, revisions and customizations to cloud-based applications occur weekly.” The potential problem, he continues, is that each customization, if not done securely, can lead to security vulnerabilities. With so many revisions taking place, the number of vulnerabilities increases.

Leach goes on to cite the 2016 Trustwave Global Security Report that showed, back in 2013, the organization’s software reviews turned up, on average, six critical/ high vulnerabilities per application. By 2015, because of the rapid pace of change, that number grew to a median average of 20 vulnerabilities per application, and 98 percent had at least one vulnerability.

In some cases, vulnerabilities are known to the developers, but due to pressure to release their solutions or — more likely — a lack of understanding about best practices concerning financial security, the software is issued as is.

“We had a rash of compromises in the U.S. within one industry sector,” recalls Leach. “The software developer hardcoded the password into the software. Once the criminal was able to look at the code and see the password, they were able to compromise several merchants with the same attack.” Surprisingly, Leach says that 10 percent of passwords are hardcoded into software.

“One study showed that 43 percent of developers knew they put out bad code with potential vulnerabilities approximately 80 percent of the time. That is a reflection on the pressure they face to release quickly and often,” he says. “Many developers simply don’t understand the risks they may create for people and organizations throughout the payment ecosystem.”

Another challenge the council sees is the rising complexity of POS systems. “If you look at the POS systems VARs and ISOs were installing 10 years ago, they were pretty simple machines with a couple applications running with limited capabilities,” says Leach. “Today, things are much more complex. There are more ways to communicate [NFC, Bluetooth, Wi-Fi, etc.] and more apps running together while sharing and transferring data.” The smarter we make POS devices, the more opportunities for attacks and breaches are created for criminals.

Yet another modern challenge Leach identifies is that a lot of software development is being outsourced in some way or another. “I saw a stat that more than 80 percent of software contains some amount of third-party code, whether it’s borrowed from open source or other vendors,” he says. “By depending on third parties, there’s no way to know if the code is secure.”

One misconception the council is battling has to do with continuously checking security. “The biggest thing we hear is that the software was deemed secure at some point in the past so there’s no need to check against new threats,” he says. “Obviously, we know that criminals are always innovating and finding ways to break software so security must be a constant fight.”

Raising Security Awareness Among Developers
Listening to Leach, it’s clear that awareness is the number one goal of the council when it comes to developers. He has story after story related to incidents that could have been avoided. “We see many issues related to legacy code,” he explains. “We saw this earlier this year with an attack that took out 5.5 million web sites. Many developers are taking their code and adding it on to legacy code.” The problem, Leach says, is that you can’t just take an old secure piece of software and put it with a new secure piece of software and assume that they collectively create a secure application.

Leach also recalls speaking with the CEO of a small development startup who called to ask why PCI certification was important. “I started to explain the importance and was cut off because he said I was speaking too technically to him and that he was going to put his lead developer on the phone,” says Leach. “The lead developer was his 15-year-old son. Here’s someone who hopes to sell his new software to tens of thousands of merchants. I should add that I had a great conversation with his son, and he understood the importance and made the changes they needed.” It’s a common story, according to Leach: Coders and development companies have good intentions to seize an opportunity but might not understand the importance of financial regulations and how their software is directly responsible for the security of merchants, processors, and everyone in between.

What The PCI Security Standards Council Is Doing
To address these challenges, the PCI Security Standards Council has taken a number of actions. First and foremost, the council is campaigning to raise awareness within the developer community so it understands the importance of securing information such as account numbers and associated verification codes.

The council is also looking at its validation process. “Our process was built for software coming out every nine months,” he says. “As the pace of the industry has increased, we need to help developers make sure they’re following best practices when it comes to security. We’re looking at how to empower developers to write good code at the start of the project. Good design to begin with will eliminate future risks.”

Today, with new products popping up all the time, dealing with the number of applications coming to market is also a challenge. “The ultimate goal is to provide speed at the pace of change the industry expects, but still have security and integrity. The council is working on this right now with our community and hopes to have more to share on this at our fall annual event.”

The council has its work cut out for it. Leach and company know that they not only have to address the cutting-edge pace and methods of today’s latest software development, but also that developers are still doing things the slow and steady way.

Additionally, Leach says there’s a focus on ensuring a transparency to what applications were tested and what tests were performed, so merchants going forward can make educated investments. Finally, he says the council wants to create integrity in the security process so there’s a way for developers to make their changes responsibly. Leach talks of having “good security hygiene,” where software is put into production with the necessary security and integrity, with additional steps taken to ensure it stays secure in the future. In fact, last year the council launched a software security task force to build a framework for how one builds good software security.

If all of this sounds daunting to a software developer, there are ways to tap out of the process. If developers don’t have time and/or expertise to have good security hygiene, lean on what’s out there. Software providers can partner with third parties, processors, and gateways that have secure solutions to the payments segment of the application.