Micro Focus Fortify is proud to be the exclusive sponsor of the TestGuild Security Podcast hosted by Joe Colantonio. This weekly podcast, dropping every Thursday, aims to be 30 minutes or less, and is an interview-style series featuring some of the top Security Testing experts in the field.
This episode of the TestGuild Security Podcast, DevSecOps Blind Spots, features Wilson Mar. Wilson has been building and bringing enterprise applications to market on major platforms—from mobile to server clouds—as an architect, developer, performance tester, and manager. His DevSecOps website provides concise, in-depth advice on leading technologies. Below is a recap of the episode:
Wilson, you’ve been doing functional testing and performance testing since the 90s. What got you into security testing?
“Yeah, (security) is the issue that’s really bothering us, right? It’s one thing to be slow, it’s another thing to not quite work, it’s quite another to get ransomware notices. So I think that is really the biggest concern that a lot of companies have. So I got kind of dragged into it—I was just horrified to see how some organizations leave big holes in their systems.
There was this one (organization)—they didn’t even have the TLS set up. They weren’t using a TLS 1.3, which is the latest now, and they only had 1.1 and 1.2. So that really is a big huge thing if you look at the concerns that people have about being able to get snooped. Also, the more I looked into it, the more I realized that that’s where the money is. So that’s the reason why I got pulled into that kind of stuff. So over time I’ve learned a lot about protocols, so I took the Security Exam and was able to pass it. So that kind of nailed it as far as what I can do.”
What is the Security Exam? Would you recommend it for other folks that want to get into security testing or security in general?
“Oh yeah. In fact, there was a project that I did in federal government, and that was one of their pre-requisites to get in to do some government projects. So that’s a big thing, and it’s a tricky exam. Everybody says it’s so tough, but I think the issue is that it’s tricky. So I found some sample exams and just kind of went through it just out of curiosity. You know, as a performance person, we’ve had to deal with protocols a lot of times, and we’ve always had problems with encryption in terms of how long they take and so forth, so it wasn’t something that was totally foreign to me. So it was good.
One thought I had for today, Joe, was some of the blind spots that people have in DevSecOps, specifically around metrics and what they have to do to get breakthroughs in DevSecOps. I don’t know if any of the other people have looked into that, but I was thinking we could take a look at that.
Absolutely. Before we dive into it, I think a lot of people listening to this may be beginners to security, I know I am, so let’s just set the stage: how do you define “DevSecOps” because I think different people have different interpretations of what it is.
“Yeah, that’s a good question, and really, we do need to identify that. My biggest go-to is, of course, Gene Kim through his DevOps handbook, Phoenix project, and his work on Accelerate. If you go to itrevolution.com/forum-paper-access they have a group that gets together every year and they write these papers. I think that is a huge effort that not a lot of people know about. He’s been doing it since 2016. But I think his biggest contribution has been, not just popularizing the word, but the DORA report, and it stands for DevOps Research and Assessment. What they’ve done is talk about the correlation between performance, in terms of the financial impact, as well as achievement of availability against these four metrics that he’s got. And I think that’s been very helpful because then people know “okay, we’ve got uptime we have to get to. We have this recovery point objective that people need to define in terms of how much data loss are [we] willing to give up after recovery, and then this recovery time objective, which is really the same as the MTTR (mean time to restore), and a few others.
So I think those metrics have really been helpful, because now people have a smaller number. Usually you’ve got some management, they come in and they have like 15 different metrics, right? So his group shortened the list to like four—five if you already count availability. So that, to me, is kind of like a summary of the whole situation: the time to restore, how much lead time that you have from code commit to running in productive use—not cycle time by the way. You know the difference between cycle time and lead time? Cycle time is an internal calculation: how much time it is for an internal process. Lead time is counted in terms of the customer viewpoint. And I think that’s really the key to effectiveness for DevOps, and one of the blind spots as well. Because looking at the customer is not just an agile concept, it’s really a good business factor. So, it’s easy to forget about that kind of stuff.
Also, deployment frequency, you know, how often code deploys to production. And the flipside of that, the last one here, is change failure rate. Now you would think “okay, change failure rate, you want to keep measuring my failures, right?” It’s not like your mother-in-law. There is a balance between change failure rate and deployment frequency, and also lead time. Because if you squeeze people to deploy faster, and you want to squeeze people to have shorter leads times, shorter times to restore, you need to also accept some difference in change failure rate. So, the issue for us is: how do we achieve better results in all five of these in order to get good uptime, not have as many change failures, have lower lead time, higher deployment frequency, and shorter time to restore. I think that’s really the game in terms of figuring out what to do, and I can go into a couple of things I’ve seen in terms of what people do to achieve that stability and yet have a faster rate.
That faster rate is really the key for, not just DevOps, but also for security issues. How I got into this whole security looking is, there are literally people staying up late at night trying to hack in. You can only really recover from that in a not easy way, hence the whole issue with ransomware and so forth. So, you really have to keep the doors pretty well locked, because all it (takes) is one to ruin your reputation, right? And so that is, really frankly, to me the biggest driver for a lot of this work, this DevSecOps work. Because the faster you can prove that you can change things, the faster you can respond to any of these CVEs or the vulnerabilities that they found. So, that to me is really the key—not doing it just to squeeze people and make them work harder. This speed is needed in order to respond as soon as you have a published vulnerability in the product that you’re using, you’ve got to move fast. Because, by the way, if somebody finds a vulnerability, they have like 90 days before the government publishes and says “this is a defect.” And you have this situation called a zero-day vulnerability where there are no patches.
So the time it takes to create a patch and all that is really crucial. So that’s what I do when I evaluate a product. The first thing I do is look for vulnerabilities that they’ve had over time. This national vulnerability database maintained by MITRE and the US Government will tell you, for every product, their history of vulnerabilities found. If you see that there’s a bad trend or things are not attended to, then that’s not a very good vendor. So that really is the issue, I think, today.
Listen to the full DevSecOps Interview with Wilson Mar
About Micro Focus Fortify
Fortify helps you build secure software fast with an end-to-end application security solution that secures and protects code throughout the entire development lifecycle of any type of software—from development to testing, release to production and every iteration in between. Fortify static, dynamic, interactive, and runtime security testing technologies are available on premise or on demand, offering organizations the flexibility needed to build an end-to-end software security assurance program.
Have technical questions about Fortify? Visit the Fortify Community. Keep up with the latest Tips & Info about Fortify. We’d love to hear your thoughts on this blog. Comment below. Or go to the Fortify Users Discussion Board to start a conversation.