Deep Dive - Security & DevOps (Guest: David Hafley)

Ben: Welcome to Masters of Data, the podcast where we talk about how data affects our businesses and our lives, and we talk to the people on the front line of the data revolution, and I'm your host, Ben Newton. One of the themes on this podcast is a need for speed. No, not fast cars, unfortunately, though that is great. We are talking about responsiveness, about agility, about making decisions faster. In the complicated world of security, hackers and attacks are just part of the landscape. The problem is how to respond to them quickly enough to limit the damage and protect your user’s data. Contrast Security is trying to change that equation for their customers. Their model of self-protecting software has the potential to change how companies think about security, and David Haley was the right guy to talk about it. David and I caught up on FaceTime and talked about all sorts of things, and most importantly about data, and how to secure it. So, let's dive in.
Everybody welcome to the Masters of Data Podcast, and I'm happy to have David Hafley with me from Contrast Security. Welcome David!
David: Hey! Thanks for having me!
Ben: Hey! So, uh, just to get started, uh, you know, everybody wants to know, tell us a little bit about your background. How did you, you know, what do you do at contrast and how did you as you get there? What's your career look like, so far?
David: Uh, I've been in contrast about three years, uh, I run our Server Side Development Team, as well, as our Operations effort, you know, do a lot of work around, sort, of the DevOps practices and tools at Contrast. Also, work with our Product Management Team on, you know, designing a roadmap, working on features execution, uhm, you know, and really, uh, put a high focus on, you know, rapid delivery of our product to our customers, and doing that, you know, with the highest possible, you know, audit quality.
Ben: So, I'm gonna ask you a question, and I've asked other people, I want to see how you...you respond to this. So...so, being from that area, what...what term do you see that applies more to what you're doing, DevOps or site reliability engineering? Because I've seen people use a lot of those there's term sometimes interchange little bit, but they don't see like they're quite interchangeably, how do you... how do you kind of view the…the terminology for what you and your team are doing now? Would you consider... do you call yourself a DevOps Team or is it...
David: No. I mean, I would fall into the camp of DevOps as, uh, what it’s like, cultural movement more than a team, uh, you know. I have friends and no colleagues that are, you know, DevOps engineers but...but really, I think, the difference between DevOps and site reliability engineering, site reliability engineering is a lot about, uh, you know, the automation of monitoring and reliability and measurement of... of your application, whereas DevOps is really pervasive in how you develop your application, and how you deliver it. Uh, the...the site reliability engineering aspect to me is...is more about... it's a lot about production operations, and then a lot about the measurement and transparency sort of the measurement and sharing aspect of, uh, of DevOps. So, there's...there's an acronym...acronym called CAMS, Culture Automation Measurement and Sharing, and so, site reliability is a lot about the last three, but DevOps is really, you know, all four.
Ben: I like that. Okay. That, uh, that makes sense. Yeah, I've...I've... that's come up in several conversations recently. I think, I'm gonna steal some of that if that's okay.
Dave: Sure.
Ben: [Laughs] Uh, so...so let's move on a little bit to kind of what we want to talk about today. So, you know, as always, we like to hear how people are using, you know, data to make their customer successful and access when the company, and...and, you know, and what you guys are doing as a product, and so, you know, when I was reading up a little bit on...on Contrast, you know, I just found that term self-protecting software just to be fascinating. It...It seems, like, very in line with where, you know, a lot of the movement around Microservices, and...and these kind of, you know, highly scalable applications is doing. So, just going a little more definitely, tell us a little bit more about what…what Contrast Security does and how you guys... what's the... what's the problem for...for customers that you guys are trying to solve, like, what's that burning issue that you think brings people to the door to want to use Contrast?
Dave: Sure. So, I think really, it's probably... it's two burning... two burning issues. One is... one is in a pre-production world and one is in a production world. In the pre-production world, we see tons of customers, you know, embracing DevOps. Uhm, they're embracing the automation of their pipelines. They're embracing Microservices and small development teams, uhm, you know, committing and releasing early and often, and...and the real struggle with that from a security perspective is that organizations have been developed in security teams specifically around a waterfall model, where at the end of your development cycle, you know, you send your source code, or your changes over to your security team. They review those and then get back to you. Well, that doesn't work if you want to... if you want to push three times in a day, you know. The security team can't scale with that. So...so, for us, we...we put an agent back in your pipeline, you know, as far to the left as possible, so, that you get that feedback about, you know, vulnerabilities and your libraries or vulnerabilities in your custom code that, you know, you may have introduced, so, that you can fix them, you know, during PR review, during, you know, code design, even during your own active development, so, that you don't have to wait for your security team at the end of that pipeline, and delay your release process, uhm, you know. We want... we want to be security to be part of the process. not a blocker to release at the end of...of the development cycle, and then, I think, second of all, uhm, you know, we...we have in the production world, uhm, we can take that same agent, and we deploy it with your application server, so, that you get the benefits of protection from, you know, known CVEs and, uhm, you know, common injection attacks in your production space, uhm, without having to, you know, fully commit to, you know, redesign your network for something like a WAP. [Phonetic] It's just... it lives with…with Tomcat or your Node... your Node application. So, that wherever you deploy it, Amazon or Google or Ashur [Phonetic] or your own data centre, that protection is just with the application. There's no... there’s no special configuration needed for it. It just... it lives in the application server and...and, you know, we find and I find personally that it works really well just to... just to have that baked into my automation, as I'm deploying an application. So, the security just goes everywhere. It's not this separate, like, sort of abstract concepts, or abstract device that...that lives on the network, or I trust a different team to manage, you know. It just lives with an application.
Ben: You...you know, when you... when you say that, it makes me think, it's like, you know, but even back to like the…the cultural issue we're talking about with...with...with DevOps as a discipline, I think, part of what...what the transition has been in the industry is that the engineering team instead of just adding more people with very siloed skills into, "Hey, you do this on this team. You do this thing on a team," that...that we're seeing engineering teams actually being responsible for the end…end process and so, they’re, you know it seems, like, now, what you're saying, every engineer actually has to be responsible for security and... so, what do they do now? This is not about bringing your...your typical security professional on to an engineering team and expecting them to contribute as a silo person. They have to contribute as far as a team. I mean that...that...does resonate with what you've seen with customers, is that... what do you think?
David: Yeah, I think so, absolutely. It's, uh, you know, security is the responsibility of the engineering teams. Security teams, you know, still act as a, you know, as a resource and as…as experts in the field but what we want to do is…is empower the engineers to solve their own problems. That's a, you know, a huge part about...about DevOps to me, is...is not... is not doing things in silos and keeping things hidden from your other teammates. It's, you know, if we have a bug, everybody knows about it. If an application is slowing production, everyone knows about it. If the pipeline is broken, you know, that's... its open and transparent and...and everyone is able to fix it. Uhm, you know, one thing that I think we've also seen as...as the scope of an engineer's responsibility has grown sort of from the... uh, through the pipeline into production is we've seen there... the applications shrink. So, that's like where we see Microservices. So, you know, on an engineering team, that you may develop a Microservice and be responsible for it from end to end, but that Microservice, you know, contributes to a tenth or, you know, 25 percent of your overall APIs for example, and, so, is... as a small engineering team, you can handle end to end what happens with that API, from security to performance, uh, production operations, data design because, it's encapsulated, it's a self-contained unit, and then you have other colleagues that are on other teams that run their own Microservices and run, you know, things their own way now, I think, that's also sort of our site reliability comes back into play, is there's...there's the contract between all of these small teams that do everything themselves, of how that they work together, and that...that's, like, really where site reliability fits in, I think.
Ben: Yeah, that makes a lot of sense, and, you know, one term that we've been... we've been seeing is, I remember back years ago, sometimes they would call it Rugged DevOps and now that seems to be turning into DevSecOps, is that... is that a term that you guys find customers using now or do you guys use that yourself or...
David: Yeah...yeah. We...We tried to use DevSecOps a lot. Uhm, you know, one of our founders, Jeff Williams, has...has been a big advocate for Rugged DevOps and DevSecOps. You know, for many years, uhm, we are really just trying to get security early in the process of your... the...the development of your application.
Ben: You know, it...it reminds me of back in my...my last job, I was at a another company, and I got into a Twitter war with a guy around Rugged DevOps because he...he was saying that well, you know, this it's a... it's a contra... I don't remember what he said, it was a contradiction in terms, it should all be rugged and it's funny it has come around now, where this...this is kind of where things are headed now, and people realize they, you know, security's part of the entire process, and the Ops team has to be responsible for it.
David: And I think, really, it highlights, just that security is another form equality. A huge discipline and, uhm, huge...huge component, I would say of DevOps is that your tests are automated. They're baked into your pipeline, and it goes that saying, that you should have security tests as well, and so, you know, having DevSecOps really just highlights that as a focus, I believe.
Ben: Yeah...yeah, you know, absolutely. Hey, so...so, maybe turn it a little bit on that. One of the things we...we... we've...we've talked a lot about before and I we talked about on the last podcast, was around when you think about how data plays into this, one of the things we've talked about is that there's a... there's a transition from, you know, it used to be about Big data, you get a lot of data in some big store, somewhere and you...you process it, may be days later you get answers to your questions, and it's... there seems to be a transition now, to where you want to have the data and act done it very...very quickly. You know, sometimes, uh, you know, uh, you know, we call it like fast data or something, like, that. Uh, do you... So, to talk a little bit more about how you view data as part of this process, because it seems from what you're saying, that if you're... if you're making decisions really quickly based on, you know, uh, security vulnerabilities or things that you're seeing coming in that, you know, expose certain vulnerabilities, you have to be able to act on it very quickly, and data seems to be a big part of that. So, maybe talk a little bit more how you see...see that as part of the process.
David: You know, I was actually reminded, uh, this is a bit of a tangent, but this is a... an old sticker from Contrast, it's on my water bottle. It's called the world's fastest application security...
Ben: [Laughs]
David: Product, I think, is what it says, but to me, you know, there is a massive amount of data out there, and there's a lot of really interesting work around, how to, you know, how to find insight in massive...massive data sets, uhm, and...and what we see is that the faster you can get feedback to the customer, the user, the developer, the better off they are, you know. There's no waiting period. There's no guessing game. There's no, you know, dependency on an unknown third party. It's...it's sitting like very clear and fair expectations around, you know, what you should do, what with the data that you have. So, if you've... if you'd like to introduce some new code or a new library in your application, then, you know, you're gonna want to know that that library is... had... has, you know, known CVEs in it as soon as possible. You don't want to get to the end of your cycle of development, you know. Your sprint two weeks later, and then come back and say, you know, "Well, I have to refactor all this stuff because now I've learned that my libraries out of date." So, getting that feedback fast is, you know, critical in...in my opinion to, you know, having a very smooth, like, delivery pipeline in DevOps practice.
Ben: You know, one thing that remind me as you were... you were saying that, so, as...as you been working with customers, and you've been seeing people try to adopt this. What...what do you think... where did... where do people struggle? So, I mean, you know, all this sounds really great on paper. We know obviously, if it was easy then everybody be doing it, right? So, what...what...what kind of holds people, you know, companies back to engineering teams back from being able to implement something like this?
David: That's a... that's a great question, uhm, from what I've seen, it's...it's really all over the place. A lot of it is maintenance of...of, like, legacy applications. So...so we talked earlier about how nowadays folks are developing small, uhm, sets of Microservices that interact with one another, and they have a defined set of API. So, with that, you know, that...that Microservice that may have, you know, a handful of APIs, uh, it's...it's a new development. Everything is modern. Everything is, you know, designed from the start, to be testable, you know, modular and be baked into components. The difficulty, I think, is if, uh, what we see is with customers that have very large monolithic deployments that, you know, been around for, you know, decades. It's really hard to unravel that, you know. How do you get into a DevOps friendly, uh, process, that they can get that feedback too quickly, whenever it takes 15 minutes to start up your application for a test, you know, or it requires a custom enterprise license to, uhm, set up a test server. There's just old legacy, uhm, decisions that were made 20... 25 years ago, you know, are...are difficult, I think, to shoehorn into this process. So, uhm, we've seen some…some folks, like, really embracing this and rewriting it and empowering Dev teams to replace components of, you know, large monoliths. I think, uhm, you know, we also work with...with teams, like, Automate and uhm, replace their testing infrastructure. So, if you have... some of your team is in AWS, and some of your team is in a colocation facility, how do you get sort of the...the service influence that you need to test your application effectively and quickly, and get that feedback, uh, with confidence?
Ben: Yeah, that make a lot of sense. You know, it reminds me too, I'm sure you're familiar with Conway's law, right?
David: Yeah.
Ben: Yeah. So...so, that the...the, uhm, organization... was organizational communication structure reflected in the architecture and vice versa?
David: Yeah.
Ben: That...that... it...it definitely sounds that it may be part of it because if...
David: Yeah.
Ben: You have a company that is still... like, a group that still running a model with the application, there is a good chance that they may not be culturally and organisationally ready for something like this either, right?
David: Right...right, and...and I think, we can, uhm, we see companies, you know, companies embrace it, and really work hard, it’s just the feedback cycle are slower. Uhm, them... you know, folks that are most successful with this fast feedback model are...are folks that have... that have newer services, that have been rapidly integrating already, but if...if you are trying to business part of, you know, one big initiative, uh, it...it is really challenging, uhm, from what I have seen.
Ben: Yeah...yeah. I think, sometimes though its culture issues are the hardest one to deal with because you can go out and buy some, you know, go to... go to some cloud...cloud platform or buy some new software platform...
David: Yeah.
Ben: But if you...if you don't change your culture...
David: Right.
Ben: You won't be able to, you know, adapt this, yeah. Uhm, you know, I think...i thinks this is... this is... this is absolutely fascinating and...and I, you know, it is very in line with, like, you know, some of the other, uh, companies that has talked to about this type of thing, where there is a lot of... when this engineering team are now being held responsible for the code, you know. There is a cradle degrade...David: Yeah.
Ben: They... there's struggling with, you know, this discipline that you should be handled by silo teams.
David: Right.
Ben: And, so, you know, now, they are trying to, you know, work in a... work at a, you know, what...what you guys actually saw on your... on your... like the speed of DevOps, so, like that. Uh, you know, they are trying to run it, like, a hundred miles an hour, and if they don't have those tool sets to help them do that, that mean... that seems to be a lot of where... a lot of the investments gonna be now. Is... you know, how can I get the data and the tool sets to analyze that data, to be able to help me make decisions faster. Does that sound right to you?
David: Yeah. That's... I think so.
Ben: David, based on... what we just talk about, what kind of trends do you see happening in the next few years based on self-protecting software and this kind of, built in embedded security? Are there any interesting you're seeing, that you...you wanted to talk about?
David: Yeah. I think, that uhm, really having security with your application, and wherever your application may live or go, is critical to, you know, the speed of DevOps. Like you said, it let you make decisions and...and your team itself is empowered to deploy confidently and quickly, and know the security is with you and with your process. There is no another team that you are relying on, there's no another dependency in your organization that, you know, that you're trusting that...that the team runs the web application firewall, uhm, you know, that it implies. You are able to verify that yourself. So, it’s...it’s very empowering to give you that...that transparency of...of what's going on with your application. Uhm, the, you know, some of the advantages of being with the application, if there is an attack that... we are able to see, you know, exactly where, uhm the attack could have manifest itself and then, how to fix it. So, uhm, I...I think, that were...were gonna see going forward as...as more things that are, uhm, you know, small components shift with application servers, as...as everything shifts to the application, you know. We used to see, uh, you know, a lot... a lot of practice around hardening operating systems, and, uhm, you know, things lower than the operating... in...in... lower in the OS, but I mean, you see things, like ECS Fargate where now, like, you can just run Containers on a managed cloud, you know, and that is just an example, uhm...
Ben: Yeah.
David: There is, uhm... everything becomes more about the application with...with Dagger, with...with managed cloud circuit... with...with managed Container services, like, ACS and Fargate, and, you know, Google has one, as well, but it...it would have more, and more, and more about the application as...as the attack vector... and, so, if you have your protection and assessment with the application, you know, it...it really... to me is...is into make, like, a common sense.
Ben: So, it’s, like, interesting, you are bringing up, uh, Fargate and kind of the... kind of the whole containerization part of this. Do you think that make things... Did you think that makes us kind of, self-protecting software and kind of, embedded, and, you know, security easier or harder with...with Containers?
David: Uh, I...I think, it makes it a lot easier, because it really narrows the scope of...of, uh, of where an attacker, you know, would go to explore the application. Uhm, you know, there's... and...and I think, also, it does put a...a degree of pressure on the club provider, some folks, like, Amazon and Google but, you know, they've...they've have hundreds of thousands of engineers that, uh, you know, are there to help with that problem. Uhm, so me as a... as a consumer of their service and a user of their service, I am able to focus on my application and the libraries in their application, and not worried about the additional layers and additional vectors of attack that...that may exist in the operating system. As we see, everything collapse, uhm towards the application delivery.
Ben: Yeah, that makes a lot of sense. You know, I...I have finally seen the...the whole idea of containerization is...is, so, compatible with the whole Microservices idea, and kind of, embedding very small components which are a lot easier to...to make with higher quality but also easier to protect, like, you said, I think that's a... it’s a... it’s...it’s a super interesting area. So, hey, well, uh, David, really enjoy the... having you on the podcast and this has been a great discussion, and, uh, we will have you back again sometime to talk more about Contrast. I appreciate your time.
David: Cool! Great catching up Ben!
Ben: And thanks everybody for listening to Masters of Data, and look for the next podcast newsfeed. Thank you!