Skip to main content
banner image
venafi logo

Why You Need End-to-end HTTPS in DevOps [PCI-DSS Requires It]

Why You Need End-to-end HTTPS in DevOps [PCI-DSS Requires It]

DevOps PCI compliance
August 10, 2020 | Guest Blogger: Kim Crawley

More and more organizations are deploying their applications through DevOps these days. DevOps is responsive, agile and dynamic—as long as everything’s properly set up! As a newer model for application development, there’s sometimes some confusion about what DevOps is. Considering that AWS runs a significant percentage of the DevOps applications out there, perhaps Amazon’s definition is best:
 

“DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organizations to better serve their customers and compete more effectively in the market.”


 


Now, a lot of DevOps applications enable ecommerce of some sort, either directly or indirectly. Even if your organization doesn’t really have any retail per se, you may very likely be selling services to your clients. Either way, there would be an interface where users input their credit card numbers somewhere in your application’s frontend. From there, that very sensitive financial data travels through applications developed in your DevOps system. And there’s also other sorts of highly sensitive data to contend with—user identification data, geolocation data, public keys, and the list goes on.
 

And there’s another matter to add to the mix. It’s not only your sensitive data that should be encrypted. Any cleartext in transit whatsoever creates an opportunity for cyber attackers to execute devastating man-in-the-middle attacks back into your DevOps system. It’s an easily breakable window to your metaphorical bank vault.
 

So those are the practical reasons why you need end-to-end HTTPS in DevOps for security. So, what about compliance?
 

If your organization deals with any sort of payment data, you must be compliant with PCI-DSS, the Payment Card Industry Data Security Standard. These regulations are incredibly important. Stolen credit card data can ruin lives. Not just in money lost, but also through the ever-growing threat of identity fraud. I see databases of stolen credit card data being sold on the Dark Web. Imagine how much worse it would be if there weren’t regulations about how payment data should be handled!
 

So, if you run a DevOps system for applications that handles payment data to any extent whatsoever, what do you need to know about PCI-DSS? Here’s a brief excerpt from an official document on PCI-DSS version 3.2.1:
 

“In the past, theft of financial records required a criminal to physically enter an organization’s business site. Now, many payment card transactions use PIN entry devices and computers connected by networks. By using network security controls, entities can prevent criminals from virtually accessing payment system networks and stealing cardholder data and/or sensitive authentication data...
 

Do not store sensitive authentication data after authorization (even if it is encrypted). Render all sensitive authentication data unrecoverable upon completion of the authorization process. Issuers and related entities may store sensitive authentication data if there is a business justification, and the data is stored securely...
 

Render PAN unreadable anywhere it is stored—including on portable digital media, backup media, in logs, and data received from or stored by wireless networks. Technology solutions for this requirement may include strong one-way hash functions of the entire PAN, truncation, index tokens with securely stored pads, or strong cryptography.”
 

And that illustrates why your DevOps applications and process needs end-to-end HTTPS. In fact, any system that transmits payment data through the web must do so through HTTPS. Not just in the frontends that users see in their browsers, but each and every step of the way.
 

A new matter to consider is PCI-SSS, otherwise known as the PCI Secure Software Standard. Here’s what you should know about it. According to PCI’s CTO Troy Leach:
 

“The Secure Software Standard outlines security requirements and assessment procedures to help ensure payment software adequately protects the integrity and confidentiality of payment transactions and data.
 

Key security principles addressed in the Secure Software Standard include critical asset identification, secure default configuration, sensitive data protection, authentication and access control, attack detection, and vendor security guidance.”
 

So, whereas the PCI-DSS applies to all payment data through brick-and-mortar point-of-sale and web-based ecommerce alike, PCI-SSS specifically pertains to the software applications and how they manage that sensitive payment data. Leach continues:
 

“The PCI Secure Software Standard is intended for payment software that is sold, distributed, or licensed to third parties for the purposes of supporting or facilitating payment transactions.
 

We also encourage bespoke products that are developed in-house by large organizations to consider using these same practices.  We’ve already heard from several merchants that have expressed interest in adopting these practices as a way for them to demonstrate integrity of their unique development practices.”
 

Your organization may not be developing your payment software in-house. But even when you use a third-party vendor, you must make sure that your data that goes through the payment software is handled with great care.
 

Now here’s some additional advice. If you can possibly manage it, please use TLS 1.3. Provided you don’t need backwards compatibility, it should be no trouble at all. The standard was published in August 2018. It’s supported by pretty much all current web browsers, both on desktop and mobile. Browsers are now trying to strongly discourage TLS 1.1, a fourteen-year old standard. TLS 1.2 is only two years newer, so you can expect it to be depreciated in the next couple of years. All major cloud providers also support TLS 1.3, both for your web content and for your containers. Considering that TLS 1.3 also drops support for weak hashing algorithms and weak elliptic curves, choosing the most recent standard for your DevOps will help you to fulfill the spirit of PCI-DSS, not just comply with the letter of the law.
 

For a really professional commercial web deployment, use extended validation TLS certificates for your DevOps driven applications. It’s worth the extra effort to have your business verified, to have your domain ownership checked, and to have your pertinent legal documents looked at. Users can see the security of your HTTPS setup in their browser address bars, and you want it to look rock-solid for a good first impression. You can’t make a first impression twice!
 

Finally, you must protect the public key infrastructure that the TLS certificates for your DevOps applications are generated through. Watch your certificate authorities and their hierarchies. Rotate your key frequently. Watch your configurations. And of course, get rid of obsolete technologies and standards!
 

A little bit of extra effort to secure your DevOps is always worth it. And one of the most essential ingredients is to ensure end-to-end HTTPS. No ifs, ands, or buts!
 

Related posts


 

Like this blog? We think you will love this.
blueprint-securing-modern-software-development-pipelines
Featured Blog

Blueprint for Securing Modern Software Development Pipelines

Prior to this submission, we have been actively working

Read More
Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

See Popular Tags

You might also like

TLS MIM For Dummies
eBook

TLS Machine Identity Management for Dummies

CIO Study: Certificate-Related Outages Continue to Plague Organizations
White Paper

CIO Study: Certificate-Related Outages Continue to Plague Organizations

About the author

Guest Blogger: Kim Crawley
Guest Blogger: Kim Crawley

Kim Crawley writes about all areas of cybersecurity, with a particular interest in malware and social engineering. In addition to Venafi, she also contributes to Tripwire, AlienVault, and Cylance’s blogs. She has previously worked for Sophos and Infosecurity Magazine.

Read Posts by Author
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon
Venafi Risk assessment Form Image

Sign up for Venafi Cloud


Venafi Cloud manages and protects certificates



* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
(@%+^!#$?:,(){}[]~`-_)
* Please fill in this field
* Please fill in this field
* Please fill in this field
*

End User License Agreement needs to be viewed and accepted



Already have an account? Login Here

×
get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more