I recently sat down with John Bullard and Benji Taylor from Distil Networks to discuss their path to Payment Card Industry (PCI) security standards compliance and the role DevOps played in their journey. Here are some highlights from our talk.
1. What were your main challenges getting to PCI compliance at your company?
Bullard: The first was timeline, as we only had three to four months to achieve PCI compliance. We had to move quickly in order to close prospective customers who required security that maintains compliance. Budget constraints were another challenge. As a company, Distil is scaling quickly, so every dollar counts. That’s why Benji and I were the full team working on this project. Balancing our normal workloads with setting up PCI compliance was another challenge in and of itself, but it made it that much more rewarding in the end to see what we had accomplished.
Taylor: We were both also very new to this process, so it took some time to gain a thorough understanding of everything needed to start the effort. But in the end it felt great knowing we did it all on our own, without the help of anyone else who had prior experience going through compliance.
2. Why did you choose a DevOps approach?
Bullard: Given our backgrounds, we approach a lot of problems through the lens of a software engineer. Approaching PCI compliance from the DevOps perspective made sense and was a natural step for us to take based on our expertise. Additionally, using DevOps really helped us face our hurdles in regard to budget constraints, because it required minimal investment.
Taylor: We’ve taken that approach to everything we do. Also, since everything was documented through code, using DevOps helped make it simple to show auditors exactly what we did throughout the process, and how we did it.
3. Which tools did you use?
Taylor: Although there are a lot of tools that can be used for various tasks when achieving PCI compliance, we primarily used Chef from the automation perspective.
Bullard: We used a lot of other open source tools as well, and contributed back to many of those projects based on our own experiences. We enjoyed sharing our story to hopefully improve the experiences of others going through the compliance process.
4. What didn't go so well?
Bullard: Generally speaking, the DevOps software engineering approach is a very iterative process. Security compliance is often less so; you either meet the specs to achieve compliance, or you don’t. Although we made it through, trying to square off those two different approaches was difficult and contributed to the learning curve. DevOps is very agile and moves quickly, while compliance is a slower process. We learned that DevOps is not a substitute for having formal security processes and authorities in place; it can be complementary, but should never serve as a replacement.
5. You're speaking at the Security Conference in New York this November. What presentations are you looking forward to attending while there?
Bullard: “Economics of Cyber Security” by Fernando Montenegro (vArmour). I’m interested in this session because at the core of what we do, blocking bots, we are solving an economics problem. The reason adversaries use bots is because it’s too expensive to use human labor. We thwart automated attacks, thus changing that equation. I’m interested to see this mindset applied to security more broadly.