devopsy.kinsta.cloud

Category: Podcasts

  • Automating Security with Palo Alto

    Automating Security with Palo Alto

    Today, automation is more important than ever before. Integrating security and automation early into the SDLC decreases the risk of potential cyberattacks, provides early and relevant feedback, reduces time to market and improves product quality.

    In this TechStrong TV episode, Taylor Smith, senior product marketing manager with Prisma Cloud, Palo Alto Networks, discussed the need to take a software-centric and cloud-focused approach to security. He explained the importance of automating security to keep pace with rapidly changing applications and software infrastructure.

    The video is immediately below, followed by the transcript of the conversation. Enjoy!

    Transcript

    Mitch Ashley: Well, I’m very privileged to be joined by Taylor Smith. Taylor is Senior Product Marketing Manager with Prisma Cloud, of course, of Palo Alto Networks. Welcome, Taylor.

    Taylor Smith: Thanks so much.

    Ashley: Good to be joined by you today. Tell us a little bit about yourself. I know you fairly recently joined Palo Alto Networks and you have an interesting background in the industry, and of course, tell us a little bit about Prisma Cloud.

    Smith: Yeah, absolutely. So, I’m coming up on my six month mark and I’m really enjoying it. I came from both big and small companies, so previously at infrastructure companies and then I did a little stint in the DevOps space working on some DevOps tooling and chaos engineering. Really enjoyed that, but glad to be back into cyber security, which is really my passion, and covering cloud security and shift left security for Palo Alto Networks.

    Ashley: Excellent. Tell us a little bit about Prisma Cloud. I know it’s pretty comprehensive, a lot of things there, but how would you give a kind of brief overview of what it is?

    Smith: Yeah, absolutely. So, Prisma Cloud, we have the benefit of being best in class in multiple different categories in cloud security. So, we really cover the full life cycle of cloud security, from the infrastructure all the way up to the code level, the code that’s the applications that are running on top of it, and we do that across the full life cycle of your cloud application. So, we’re securing your infrastructure as code all the way to your container images, and we do that at the build time and the run time.

    Ashley: Excellent. Well, as a—I’ve used Palo Alto Network products myself. As a networking company, if you wanna think of it that way, maybe that’s an outdated way of thinking of Palo Alto Networks, which is the point of my kind of thought here is, we’re talking about application security and applications and really, everything is becoming software now. So, the network itself, of course, has been turned into software and now is in cloud and on prem. But the whole stack, the entire stack, you know, infrastructure as code.

    So, that brings some obvious benefits, maybe some challenges with it. What are your thoughts on that?

    Smith: Yeah, absolutely. So, it’s an interesting time to be in the application space right now. Before, you had to go in and physically provision servers, you had to connect cords to routers and network switches, and all of that and then maybe get into the CLI to make some changes.

    All of that’s moved to code, all the way from the infrastructure as code all the way up to the containers that you’re defining how they’re gonna operate, the operating systems are all contained in code. Which is great for developers, they’re able to move a lot faster, they can provision things on the fly, they can use things as they need them or scale them down if they don’t. It saves us costs and makes things move a lot faster.

    The double-edged sword to that is, now it’s out of the security and infrastructure, the IT team’s hands. Developers are just deploying things, it’s kinda the Wild West. And so, to kinda bring that in, rein that whole world in and make sure they’re secure and doing all the right things, it’s good to embed that security in their process. So, making sure you’re scanning in infrastructure as code templates, scanning container images before it gets to the repository and before it gets deployed into production. And that really gives us a chance to actually patch more often, because now developers are getting the direct feedback, and frankly, they’re more qualified to make those fixes than the security team. So, they can actually go into the code that they wrote and make the changes if they’re given that right feedback.

    Ashley: Yeah, I think that’s one of the things, as a security engineer when you think about software, it’s not—I can think of this now as, instead of a solid, it’s almost a fluid.

    Smith: Yeah. [Laughter]

    Ashley: It’s constantly changing, right? And that makes it really difficult to secure, it also sometimes can be difficult from a quality standpoint. But, really, it is almost that kind of a form of matter and the things are constantly changing. So, you can’t expect manual processes were stopping the line to be what’s going to bring security back into the fold. You’ve got to equip people, you’ve got to equip the toolchain, the pipeline that’s creating code and delivering it out to production, and then guiding that process through what you want secured, how you want it secured, what you deal with, those issues as they come up.

    Smith: Yeah, absolutely. Microservices has really revolutionized this where we have a couple customers who, the application that they have, one at the beginning of the week looks nothing like what it looks like at the end of the week. They’ve completely redeployed the full stack, and that’s great for innovation, it really opens up the world, but it does—and you don’t want, as a security engineer, to be going in there and slowing things down. You wanna be a part of that development and actually be a supporter, be someone who actually enables that speed to happen, but still make sure it’s done secure and you don’t get bitten by the misconfigurations, the vulnerabilities in your applications.

    Ashley: Mm-hmm. What is it about the cloud, too—I mean, we talked about microservices containers, those don’t have to be run on the cloud, but of course, we think of them as cloud native architecture. Is it from infrastructure management all the way through to the application itself? How do we have to rethink things than maybe what we did when everything was running in our own private data center? What’s fundamentally different that we might try to do it the old way in the cloud, but really, we’ve got to fundamentally change how you think about it?

    Smith: Yeah, I think a lot of it comes down to that everything is accessible. I mean, there are private links and there are VPNs to make sure that it’s locked down, but at the end of the day, you don’t have physical access to these data centers. So, a lot of it comes down to, there is somehow public access, and we lock that down as much as possible.

    But if you have an EC2 instance in AWS or a VM instance in Azure or GCP, it can be exposed to the world. And making sure that the security groups or the firewall rules are set so that they’re blocking, there’s no catch—I had a customer who explained it to me very well. Where you kinda get these layers of checks in the on prem world where, even if somebody goes in and provisions a virtual machine that is exposed and has all these misconfigurations, most likely, it’s not gonna be touching the world. No one’s gonna be able to access it, so it’s not a big deal. But cloud security, those misconfigurations can really bite you, because they are exposed. And so, getting that right is more critical, and making sure the misconfigurations are found and fixed, it’s much more important than it was in the on prem world.

    Ashley: That’s interesting. I’m wondering how you approach a platform like Prisma. Obviously, people who are already Palo Alto customers may come to it kinda naturally through their relationship with you. But how is it, is it a network engineering team that says, “I need to figure out how to secure the cloud?” Is it a software Dev team saying, “I need better tools to make sure I’m configuring and writing secure code?” Who is it that usually is engaging you for Prisma and then how do they bring it into the organization and kind of spread the love, if you will? [Laughter]

    Smith: Yeah, yeah. No, it’s fun. Part of what I really enjoy about being at Prisma versus some of my previous jobs is, I’m not working with a single person or archetype, I’m working with some cloud engineers, who they, it’s this new—frankly, new to me engineering type where they’re covering everything cloud. They’re doing full stack up to the application for everything provisioning infrastructure in the cloud. Where before, you might have a network specialist and a compute specialist, now you have a single engineer that covers the full cloud. And then we also have developers and DevOps teams that work with us, and so it’s not necessarily the security teams. And then, we also still work with the security teams, so the SOC, the security engineers and the cloud security specialist.

    And all of them have different us cases that they come into Prisma Cloud with, but all of them in the end are trying to use Prisma Cloud to make their lives a lot easier to automate that security and make sure the checks are happening. So, the developers are much more worried about the pre-deploy time where they can secure their applications, their infrastructure as code when they’re container images before they’re actually running containers.

    And then, the security teams are actually going into our system to see what’s the posture in the cloud, getting that view, the complete, comprehensive view of all the things that are running in their cloud environments, and then securing their containers, their Kubernetes environments, their serverless environments, all the things that are actually running. And running incident management through Prisma Cloud, running through the incidents and all the trace data that we give them if there’s an incident that happens.

    Ashley: It’s really fascinating how the security engineer/network engineer job has changed, that role and the skills that are involved. I wonder, I’m just curious what your experience is being more, dealing with software and configuration of software, maybe automating, scripting, things like that as a network engineer/security engineer. It seems like that would make that job more relatable to what a software developer might be doing. They’re not the same thing, but much different than someone who is rack and stacking and, as you mentioned, plugging things in and thinking of networks and physical devices like we used to, not that long ago.

    Smith: Yeah. Yeah, it’s funny, I agree. The role of the infrastructure engineer is becoming much more like a software developer. So, they’re actually learning Python or HCL so they can write Terraform scripts or they can write Ansible scripts and deploy infrastructure using code. And that can now go through pipelines. So, now, I’m hearing infrastructure people start talking about CI/CD, which you would never expect in the on prem world. They’re using a lot of the same language, like unit testing static analysis of their infrastructure as code.

    So, they’re kind of learning to be a developer, but specifically for infrastructure.

    Ashley: I remember the day, it was actually about, I guess, 11 years ago when I took over an IT organization and a network engineer asked me, “What should I be learning? What’s the next thing I should be thinking about?” and I said, “Learn Python,” and he looked at me cross-eyed.

    Smith: [Laughter]

    Ashley: Ended up going to a conference, maybe it was yours, came back and said, “Now I know why you said that, now that we see what’s happening in”—yeah, that’s a huge transformation that’s happened in, really, less than a decade. Think about how massively the network stack has changed and really folded into infrastructure as code as its part of it.

    How has your job changed through your career, and have you progressed with how this has happened in our industry?

    Smith: Yeah, so, like I said, I came from a big infrastructure company and I covered traditional network security back then, and I moved to a DevOps company. And so, I kinda saw this complete transformation where things were automated, people were moving fast. Reliability is kind of—it’s a whole new definition in the cloud. And so, now, you can, even small companies can have redundancy where they didn’t before.

    That makes things very different for the security person. And so, if I’m—now that I’m covering security, again, but now from a more developer focus, I’m seeing how that automation is much more important than ever before, and how that network perimeter is no longer the only place where you can apply security. And it’s becoming less and less important, but it’s still critical to have that perimeter, but all the things happening inside, too. So, that zero trust networking inside your infrastructure, inside your applications, securing your Kubernetes deployments, making sure your containers aren’t over privileged or you’re not pulling in images from open source that are vulnerable.

    All that is now just as important or more important than the traditional security that I kinda started my career with.

    Ashley: Mm-hmm. Yeah, it’s a fascinating journey we’ve been on.

    Smith: Absolutely.

    Ashley: Well, we’re kinda running out of time, here. Where can folks find out more about Prisma Cloud and offerings from Palo Alto Networks?

    Smith: Yeah, absolutely, you can check out our website. So, you can go to PaloAltoNetworks.com/Prisma and you can find out a lot more there, or we have a lot of useful resources like blogs or white papers, and so, if you want to find out more about container security or cloud security, go there, and there’s a lot more information for you.

    Ashley: I was just gonna suggest, right, developers as well as security and network folks, if we wanna say whatever your role or title might be. Well, it’s been fascinating talking with you, Taylor, and good to be on this journey with you through the evolution of the technology that we use and innovation that’s happening.

    So, hope you are doing well and you’ll come back and talk to us again.

    Smith: Thanks so much, Mitch. It was a pleasure.

    Ashley: You bet.

  • Managing Cloud Security with Check Point Software

    Managing Cloud Security with Check Point Software

    Managing cloud security across multiple cloud providers, private cloud, AppSec and software as infrastructure, is highly complex.

    In this TechStrong TV episode, TJ Gonen, head of cloud security product line at Check Point Software, advises a security strategy that meets the challenges of cloud environments and cloud-native software architectures, and DevOps toolchains.

    Information about Check Point’s cloud offerings is available here.

    The video is immediately below, followed by the transcript of the conversation. Enjoy!

    Transcript

    Mitch Ashley: I have the pleasure of being joined by TJ Gonen, who is head of cloud security product line at Check Point Software. Welcome, T.J.

    TJ Gonen: Hey, thanks for having me, Mitch.

    Ashley: I love your name. A guitar player in a band in college was named TJ, a good friend of mine.

    Gonen: Oh, really? [Laughter]

    Ashley: So, it’s always nice when I come across another TJ. Well, hey, would you introduce yourself and, as we were joking before, for the two people who might not know, in the world, Check Point Software, tell us a little bit about Check Point.

    Gonen: Right, yeah, so TJ Gonen, and I joined Check Point actually about a year and a half ago from an acquisition of the company. I was one of the founders in the serverless security space, in the cloud security space, so I’ve been around Check Point for 18 months, about 18 months.

    Check Point has been around for a bit more than that, 27 years, one of the OGs of cyber security—literally invented the firewall. [Laughter] So, it sounds crazy, but that’s literally what happened and over the last 27 years or a bit more now, one of the largest individual or independent cyber security companies in the world, billions of dollars, traded on NASDAQ, 100,000 customers over the years, 60,000 active customers, enterprises, I think we secure literally everyone and provide solutions across the full gamut of cyber security with a lot of focus on cloud security over the last two, three years, just because that’s a topic. And that’s what I do for Check Point, I round the cloud security product line.

    Ashley: Excellent. Yeah, I was sharing with you the second firewall I implemented was a Check Point firewall back in the ‘90s, so it goes back a ways. You’ve been around—

    Gonen: It does, it does.

    Ashley: – tried and true solution, for sure. Well, we wanna talk about not just the old days of when maybe you or I started in security. You know, obviously, the environments of what we manage and have to deal with the threat, the attack surface, all of those things has become infinitely more complex, and it’s continuing to go that way, if that’s an accurate phrase.

    I’m sure one of the issues that you deal with is helping customers with how do they manage all of their security across, you know, multiple clouds, cloud providers, their applications, their on prem, stuff that they’re running, SaaS services—whatever it might be that anybody in the organization is touching, whether they’re inside a firewall or outside, right, especially with remote work. Tell us a little bit about that.

    Gonen: Right. Yeah, I think—I mean, because both you and I go a long way back, then we have the privilege, if it’s a privilege, to look at the generations. So, it’s interesting. I think, you know, we talked about Check Point inventing the firewall in ’93, ’94 when the Internet revolution started, and I think that differently, when you look at security before the Internet and you look at security since then, obviously, that changed dramatically. And I think that what we’re experiencing now with cloud is sort of that thing happening again. It’s another inflection point.

    Ashley: Mm-hmm.

    Gonen: And if you—and realistically, from the invention of the Internet and the ultra-connected world, most of what we had to deal with was, generally speaking, in the same domain. Yeah, more complex, more bandwidth, more stuff, more operating systems, but the blueprint—I think people figured out sort of the blueprint over the last 20-something years of what you are supposed to do after the Internet came across, right? Cloud, I think, restarts a lot of this discussion, and it’s not just the sheer notion of, yeah, your data center is somewhere else and your stuff is somewhere else—I think it’s just velocity and scale.

    I think the biggest struggle we hear from customers and prospects, and honestly, even if you own your own environment, is just, you think you figured it out and then a day after, it’s 10 times bigger, 50 times more people have access to it, and you lost control. It’s so easy to lose control. So, I think where we were, where we had, “Hey, you know what? Oh, you have a data center? Okay, let’s put the firewall, let’s put some segmentation, let’s put AV or whatever—okay, here’s the blueprint.” Now, we are in this place where, how many data centers do we have? One, day after it’s 50, and now, how do you know, even, what’s going on there?

    So, I think scale and speed has been the biggest problem, and I think cloud is a real revolution. It’s not incremental, it’s not another thing you need to deal with.

    Ashley: Mm-hmm.

    Gonen: It’s a thing you need to deal with, and it’s a big issue.

    Ashley: The evolution of, we move things to the cloud, but we do things the same way we did on prem.

    Gonen: Right, right—it’s not that.

    Ashley: Then there’s the next evolution of how do you do it within, truly within a cloud environment that matches that. I mean, I remember the days of just managing the rules and what were they all in there for and who put what in, and just—that was complex, you know, when you’re an enterprise, multi-location.

    Gonen: Yeah.

    Ashley: Talk about the management capabilities that you have to have in a cloud environment, multi-cloud environment.

    Gonen: Actually, you sort of touched on something that is a no-no in the cloud environment. You literally mentioned something that, like—hey, someone was sitting down and writing firewall rules and configuring who has access.

    Ashley: Mm-hmm.

    Gonen: Manual, right? There is just no way you can do anything manually in the cloud. I mean, think about this, Mitch. Everything that happened over the last 10 years in Dev and infrastructure has been focused on automating everything.

    Ashley: Mm-hmm.

    Gonen: Literally. We talk about CI/CD, and obviously, DevOps and now cloud, if you look at cloud—cloud totally automated infrastructure and then it totally automated application infrastructure and now it’s automating everything, no code and stuff like that.

    Ashley: Including infrastructure as software, right?

    Gonen: Yes, exactly.

    Ashley: Not all of them are in a stack.

    Gonen: Everything. So, everything has moved towards automation. So, if we are going to, let’s say, you can imagine saying someone is gonna configure something manually on security, by definition, we’ve failed. So, the biggest challenge that’s facing security is how do I automate security? Because it has to secure stuff that’s fully automated.

    So, I would say, you asked about management—the first thing I would say about management for cloud, it can’t be manual. If there is, we have a saying inside Check Point that we say in the CloudGuard team, it ain’t done ‘til it’s automated. Whatever you were working on, whatever capability feature security for, if it’s not automated, if you can’t automate it, you are not done, because by definition, you are gonna be left behind and something is gonna be open, because the rest of the stuff is automated.

    So, I think the biggest—and when we talk with a prospect and when I talk on the stage, even, I always say, “Listen, when you talk about your security blueprint for the future for the cloud, number one is automation. It’s not how secure it is, it’s how automated it is.” Because it doesn’t matter, you can have rocket science technology for security—if it’s not automated, you’re gonna miss half of your footprint, anyway. So, automation has—

    Ashley: Mm-hmm. [Cross talk] the same way twice, right?

    Gonen: Right, exactly. [Laughter]

    Ashley: Without the audit trail. Well, talk a little bit about, you know, there was sort of the orchestration phase, right?

    Gonen: Right, right.

    Ashley: What we thought of as automation now, you’re talking about the entire Dev and Ops process.

    Gonen: Yeah, right.

    Ashley: The infrastructure as code, applications, dynamic environments—you know, things are changing very quickly.

    Gonen: Right, right.

    Ashley: How does it differ today from maybe folks that remember orchestration as [Cross talk]?

    Gonen: Right, yeah. So, it is different, and I think in security—let’s talk from a security perspective, because I think that’s the angle that, definitely, we deal with today. We feel like there’s two pieces to automation that are critical in this world. I call it, I split it into the first one being the presence of security needs to be automated. We lost the luxury of someone telling us that it’s doing something so we can put security in place.

    Ashley: Mm-hmm.

    Gonen: That luxury is gone, so the presence of a security control or mechanism has to be there automatically. So, if someone—just to keep it really simple, if someone is deploying new container to the cloud, which happens a billion times a day, and I decided that that container needs to be secured, then whatever the security mechanism I chose for that container needs to be there automatically. The container is deployed, security is there. How? Magic. I don’t know, but the presence of security has to be automated.

    The second thing that has to be automated is the security configuration itself. Because, again, we lost the luxury of someone saying, “Hey, I deployed an application, how about you call someone to configure the web application firewall and fine tune it to the application?” or, “I changed the application, now someone needs to fine tune the rules.” What? Find new what? It’s gonna change in five seconds, again.

    So, two things have to be automated—the presence of security, and that really talks to DevOps and integrating into the infrastructure as code pieces, just like code is automated or the deployment process is automated, the presence of security and deploying serverless functions, security has to be there. I’m deploying a new VPC and I decided that I need a firewall at the entrance, it has to be there automatically. No manual, no human intervention. And the second piece is the actual configuration. So, if I decided—let’s follow that thought process—if I decided that I’m deploying a serverless function, a Lambda function with AWS, security needs to be there. The security needs to be there automatically, but also the profile of that security, the allow and block rules has to be there automatically and they need to auto adapt to changes.

    And I think that’s such a—this is such a different breed of security automation. This is not just orchestrating security into where it needs to be, and it needs to be in a billion places, it’s also the sheer notion of how do I keep things maintained and configured correctly. And that’s why I think a big change is the definition of who does security engineering.

    Ashley: Mm-hmm.

    Gonen: Like, you and I started a billion years ago—me a billion, maybe you half a billion.

    Ashley: I’m two billion, so.

    Gonen: Two billion? You’re two billion, okay, there you go. [Laughter] So, between us an average of one and a half billion years ago. A security engineer is the one that configured the Check Point firewall, right?

    Ashley: Mm-hmm.

    Gonen: And part of the process was, “Hey, open this port for me, close this port for me, what’s the”—that’s gone. The new engineering is, the new engineer is not only the DevOps guy and the DevSecOps guy, because everything is as code and security has to be as code. I would argue that the new security engineer is the machine itself. Because you have to eliminate, as much as possible, even the process of an intervention, even by a DevOps person.

    There is, the security just needs to find itself there and auto-configure itself. That’s where it needs to go, and that’s where we put in a lot of effort. That’s why I said it ain’t done ‘til it’s automated, because I can give you the best solution ever, but if I actually require you to know what’s going on, there is just no way. You can’t keep up. There’s not enough humans in the world to keep up with the change of what’s happening now in the cloud.

    Ashley: Let me ask you this, because something that I’ve believed for quite a while now is that we are always talking about educating developers about security and helping to write a more secure code.

    Gonen: Right, right.

    Ashley: But the opposite is true, too. Not that security engineers need to be software developers, but security engineers need to understand software architecture as more than a temporary cloud. You obviously know it, you’ve been using the language of containers and Kubernetes and software as code. It’s not that you need to—it isn’t the old way of let’s go to the security team and have them set this all up for us, which is the whole premise of what you’re talking about. That happens, that has to be built into the process, it has to be built into the environment.

    So, what is the role of the security engineer in that kind of a shift left, DevSecOps, that kind of an automated environment—what skills do they need to have today that they maybe didn’t need 5 or 10 years ago?

    Gonen: It’s so fascinating. I mean, this topic, I think that there’s—we’re in this real point in time where there is a new role, architecture, or let’s say hierarchy defined. Because I think you’re gonna find security people, just to your point, when you come to a CISO and you say, “Hey, can you tell me what’s happening in my Kubernetes environment inside Azure?” And the average CISO is gonna say, “I have no clue.” The Dev guys, they do whatever they want with this environment. My security guys know how to read dashboards. They don’t know how to read code.

    Ashley: More of a SecOps kind of—

    Gonen: More of a SecOps, yeah. And I think, then—and to your point, though, when you go to the develop and you say, “Hey, developer, what’s your security strategy?” and he says, “Dude, I’m a developer—what security strategy?” So, I think you’re right that there’s new roles being defined, and I think where the world is coming to is one that you’re gonna find more, like I mentioned a bit earlier, the SecOps and Sec engineering roles are gonna be more and more definitely, in the world of the cloud, people who can write scripts.

    Ashley: Mm-hmm.

    Gonen: I think that you come back in five years from now, you talk with a SecOps guy, and you say, “Hey, can you write item scripts, can you write bash process, do you understand how to connect to the AWS API?” and he says no, he’s gonna have a real problem managing engineering, security engineering in the new world.

    Now, so, I think where the world is gonna go is that you’re gonna have what today is traditional, security do policy, defining what needs to happen, and governance. So, these are the two ends of the spectrum. I’m gonna define what I expect to happen, which measures what do I test for, what do I scan for and so forth, and I’m gonna make sure that it’s being done. And then, inside that sandwich, inside that Oreo cookie, the piece in the middle is gonna be more of the developer people—DevOps, DevSecOps. Because they’re gonna be in charge of actually doing a lot of the security work, so if the policy says applications have to be segmented in the cloud, so the payment application has to be segmented, you know, separated from the CRM application. The security people are gonna say that. That’s the policy, because it’s PCI data or whatever.

    The people that are actually gonna implement segmentation are gonna be DevSecOps people or DevOps people, because the segmentation is done in Kubernetes, and the security guy doesn’t know how to write Kubernetes microsegmentation over Calico and CNI, and these are all buzzwords, he doesn’t even know what they mean. And there’s gonna be governance at the other end to say, “Okay, that was being done. That might be a dashboard or something like that.”

    Ashley: You know, there may be—we could spend a whole other conversation on this.

    Gonen: Oh, yeah, I’m sure. [Laughter]

    Ashley: There might be a nice parallel, the analogue to this was what’s happened on the Ops side, because SRE is big, right?

    Gonen: Right, yeah.

    Ashley: And those are people that know how to code and know how to write scripts, and maybe something like that is the emergence of the security engineer role is going to be as, “My job is to automate the security.”

    Gonen: Exactly.

    Ashley: “Work with the teams, whether it’s the tool pipeline or it’s the software Dev team, the infrastructure teams.”

    Gonen: Right, right.

    Ashley: And almost that kind of a role, I wonder if that might be where we’re headed.

    Gonen: It’s actually very much true, I think that you are heading in the right direction. The SRE was born exactly from that necessity—hey, I need an Operations guy, but I need him to be able to actually orchestrate stuff using code. And I think it’s exactly what’s gonna happen or is already happening to some extent, but it just doesn’t have a name yet, except DevSecOps, right? Like, maybe DevSecOps is the closest thing, which just doesn’t come down to an acronym—DSO, maybe, I don’t know. [Laughter]

    Ashley: Yeah, we need a new job title, I’m sure.

    Gonen: We need a new job title. [Laughter] But other than that, that’s exactly it. And really, I mean, in the cloud world—listen, if you’re a cloud native company and your data center and applications are cloud native, if you hire a security guy from 10 years ago, he’s gonna be lost.

    Ashley: Mm-hmm.

    Gonen: I mean, everything is code. He needs to be able to—

    Ashley: Plus, a lot of developers are moving into security that have an interest, right?

    Gonen: Yeah, right, yeah.

    Ashley: So, that may be the best way to acquire. Well, hey, we’re running out of time, T.J., and I look forward to having you back.

    Gonen: Yeah, sure.

    Ashley: I’d love to chat with you more, especially as we get into sort of the DevOps and the CI/CD pipeline and integrating security into that.

    Gonen: Yeah, I’d love to.

    Ashley: Who knew 27 years ago we’d be having this conversation—

    Gonen: [Laughter] There you go.

    Ashley: – with Check Point? So, things have certainly advanced. Where can folks find out more and check out your cloud offerings?

    Gonen: Yeah, so, CheckPoint.com, and it says in very large letters cloud. That’s where you can go and you can start a demo, you can read a lot of the white papers around these things. And actually, I think more than anything else, we were just talking about developers—experiment with it yourself. Developers, that’s what they like to do.

    Ashley: Mm-hmm, absolutely—write a little bit of code, see what it does.

    Gonen: [Laughter] Right.

    Ashley: TJ Gonen, great talking with you, Check Point Software. I look forward to chatting again. Take care.

    Gonen: Sounds good. Take care.

  • Data Needs and Challenges with CData

    Data Needs and Challenges with CData

    The data businesses and applications need are everywhere and access through a multitude of technical interfaces, including APIs, database queries, data layers like ODBC, cloud services and SaaS applications (to name a few).

    In this episode of TechStrong TV, Jerod Johnson, technical evangelist at CData, joins Mitch Ashley to discuss the challenges of meeting the data needs applications require to support digital and transformation initiatives.

    The video is immediately below, followed by the transcript of the conversation. Enjoy!

    Transcript

    Mitch Ashley: I’m joined today by Jerod Johnson. Jerrod is technology evangelist with CData. Jerod, good to be talking to you today.

    Jerod Johnson: Yeah, no, it’s my pleasure to be here.

    Ashley: Well, as an old ex-DBA, data is always kind of a passion of mine, interest of mine, so I’m anxious to hear more about CData. Would you introduce yourself and tell us a little bit about what CData does?

    Johnson: Yeah, sure. So, like you introduced me, my name is Jerod Johnson, I’m a Technology Evangelist for CData Software. I’ll start with CData. So, we call ourselves a leading provider of data connectivity solutions. In short, what that means is, we make it easier for every user in an organization to connect to their data, which lets them focus on the job of finding value from that data or building applications on top of that data instead of having to focus on the integration, instead of tasking IT teams to build connectors or pipes or flows, whatever the case is, in order to work with the data that they need to drive business.

    Ashley: Mm-hmm. You are number two on my list of what are the reasons people come to IT when they’re building apps.

    Johnson: Yeah.

    Ashley: And that is, security, data, and other apps.

    Johnson: Yeah. [Laughter] 

    Ashley: So, always need data. Well, tell us a little bit about yourself. I’m curious—how did you become a technology evangelist? How did you—

    Johnson: Yeah, so, I actually spent six years teaching before I got into software. So, my education background was in teaching and computer science, and spent six years in a classroom teaching math and computer science, and just decided that we needed a change, for myself and my family.

    So, I started at CData, I was actually a member of the support team, which meant I was answering e-mails and helping solve customer problems. And then I moved into engineering, and spent some time there, but it really became obvious that there was a need in the company for somebody with a skill set that I had, being able to speak to people, being able to present information, even write technical documents. 

    And so, I was pulled into the marketing team, and I’ve been doing that since 2016 for the company. So, writing technical documents, giving talks at trade shows when those used to happen, through webinars.

    Ashley: When we were [Cross talk], right? Hopefully soon, hopefully soon.

    Johnson: Yeah.

    Ashley: Interesting. You’re not the first person I’ve talked to who’s come out of an education background and moved into technology and, in your case, moving into an evangelist role. That whole skill of being able to explain sometimes very complex concepts, sometimes not so complex, but you may not necessarily have the context or the background for a certain thing that you need to learn or understand—

    Johnson: Sure.

    Ashley: Or even explain to non-technical folks, right? So, a great thing to have, especially in the DevRel world that we all live in now of really focusing on how we work with service and kinda think like a developer.

    Johnson: Sure.

    Ashley: Because that’s the people who are using it, whether they’re business developers or people inside IT. Let’s talk about sort of the data challenges, and I’m curious, maybe you’ve seen some things over the last kinda year plus, too, with the acceleration of digital transformation projects.

    Johnson: Yeah.

    Ashley: It seems that one of the challenges always is data sprawl—it’s everywhere, and every application is creating data, consuming data, sometimes creating data exhaust that’s unused or somebody else might be able to use it. It’s no small feat just to find where it is, more or less find out how you can get to it and use it.

    Johnson: Yeah, no, absolutely. I think there have been studies done, I think programmable web is probably the best place to look if you’re looking for a list of APIs. And I think that they have 22,000 public APIs listed at this point.

    Ashley: Wow.

    Johnson: So, I mean, and each of those APIs, you know, there’s data behind it. So, you have that kind of explosion, the API explosion. On top of that, you’ve got private APIs and then databases, data warehouses, these traditional stores. So, data is everywhere.

    One of the things that we’ve found is that, as data explodes, as businesses transform digitally, you get the opportunity to pick the best service for your needs. So, you know, you’ve picked your CRM application because it meets your needs the best. You’ve picked your ERP solution because it meets your needs the best.

    The consequence of that is that your data is now spread everywhere. So, your CRM data is somewhere, your ERP data is somewhere, your warehousing data is somewhere else. And so, there’s this, as you said, this data sprawl where data is everywhere.

    And what we do is, we make it all look the same. So, we like to say that CData lets you see the world as a database. So, we’ve created technologies that allow users to connect to their data, no matter where it is, as if they were connecting to a database. And so, I’ll drop some buzz words, some acronyms here—so, JDBC, ODBC, ADO.NET, these are all database connectivity standards that we’ve produced that now can connect to things that are not databases.

    And so, you know, what that does is, it really democratizes data access. Now, anybody can get to data, from any of the tools or applications that they’re using. So, whether you’re looking at an IT team or a DBA or something like a citizen analyst or a data scientist, it doesn’t matter. As soon as your data looks like a database, anybody can work with it.

    Ashley: Mm-hmm. That’s interesting you say that citizen data scientist—it’s not just developers. Of course, developers are very familiar with ODBC and other connectivity layers for data access, which are fantastic for developers, but you have to have some pretty specific development skills to be able to [Cross talk] this thing.

    Johnson: Sure.

    Ashley:  A lot of this data is sitting on a Dropbox file server in some cloud application, you know, we signed up for a CRM system—well, guess what, I need to connect that with my workflow for when an order comes in. And, you know, as good as Zapier and things like that are for doing kinda nice integrations for automation, that’s not even gonna cut close to solving these kinda problems.

    And you mentioned, too, making it look like a database. I’m curious, from my experience, it’s how you get to it and making that understandable.

    Johnson: Sure.

    Ashley: But it’s also understanding the data and what it means and how it’s represented, because a customer is not necessarily defining the attributes similar in a CRM that they might be in an order system, there may be some variations in just the format of how we capture that data.

    Johnson: Yeah. Yeah, so, you know, what we do is, everything that we make sits on top of the API. So, your API is gonna have endpoints, and those endpoints are gonna expose fields for entities.

    So, let’s take a customer, for example. When you hit a customer using one of our drivers—hit the customer, well, now, it’s a table, it was an API endpoint. What we’ve done is, we’ve kinda tabularized that data model. So, now, every customer is a row in a database table and then each of the fields for that customer becomes a column.

    And then, you know, what we do from there is basically free you to map the data from one system to another as you need, in the tool that you’re using. So, we don’t force a model on you, we’re not trying to create one universal picture of a customer across your organization. We’re gonna let your business specialists do that part. We just make it easier to see, and because it looks like a database, the schema, the metadata, however you define it is really self-describing. 

    Ashley:  Mm-hmm.

    Johnson: You know, if you can talk to a database, you can point your tool. So, let’s say you’re looking at something like Tableau. When you point it to a database, it’s gonna show you all of the tables that are available and then all of the columns that are available for each of those tables.

    Well, we do the same thing, but for something that isn’t a database. So, it could be a NoSQL store like MongoDB or Couchbase or even Amazon S3. It could be a SaaS application like NetSuite, or even Dynamic CRM. So, whatever it is, you get that full tabular model where you can see exactly what’s there and then you can decide how best to work with that data.

    Ashley:  I mean, think about the advantage of, if you don’t have, necessarily, all the programming skills you might want, to go get that data, just not having to use an ABI, but use the driver instead.

    Johnson: Right.

    Ashley: And so, just get that to me in a table form that I can—now, I can compare how one customer is _____ and one, I’m just making that example, to another customer set of attributes and other applications.

    Johnson: Yeah.

    Ashley: Sometimes it’s hard enough just defining who is—what a customer is. [Laughter] 

    Johnson: Sure.

    Ashley: I remember that modeling. But now, you can see what the data is without writing a whole bunch of software and translation and trying APIs and learning specifics about this particular service or this cloud application or whatever it might be.

    Johnson: Right. Yeah, yeah. And that’s one of the things that we really offer is, we free you from that integration problem. We free your developers, we free up IT resources. So, APIs are constantly changing. I don’t know if you’re familiar with the Facebook API, but I think they give a new version, like, every three minutes. I think it’s realistically like every three weeks, but it feels like three minutes when you’re a developer.

    Ashley:  I try not to be familiar with the Facebook API. [Laughter] 

    Johnson: Yeah, which—that’s fair. [Laughter] But with our drivers, our engineers are the ones that are keeping up with those changes. So, every quarter, we release a new product, and that includes all of the API changes that have happened on the back end. So, the only thing you have to do is literally install a new driver into your system. There are no changes—no breaking changes to the API, we merge everything as much as we can. And it really, as I said in the beginning, it lets your business experts focus on your business, whatever that is.

    Ashley: Mm-hmm. I’m curious, too, is it primarily developers that are using CData and the drivers that you have? How many folks may be from a non-super technical environment, maybe some maybe a little technical skills and might use CData?

    Johnson: Yeah, so, that’s a good question. I think it’s a pretty solid blend. So, you know, one customer story might be a mom and pop shop, they wanna be able to look at their QuickBooks data in Excel, they wanna be able to work with it, print it out, edit it, even, and update it that way. They don’t like the QuickBooks UI, they’re familiar with Excel, and so they simply install our Excel add-in, and now they’re connecting directly to QuickBooks from Excel, with full read and write capabilities.

    We can get more complicated than that with customer stories. We have one customer who was dealing with that data sprawl, the data silos where their data is everywhere, and they needed a solution that allowed them to replicate all of their data into the data warehouse that they were already using for BI and analytics. And so, we have a tool, CData Sync, that allows them to do that. So, connectivity—solving the connectivity problem and solving the replication problem, so they get automated, incremental replication of all of their business data into one place for BI and analytics.

    And then, you know, I touched on this before, but we solved that BI and analytics problem in other ways. So, you know, you have data scientists that are familiar with, that really love their reporting tools, whether that’s Tableau or Power BI or any other tool on the market. They don’t wanna have to change tools just to be able to connect to the data. And with our connectors, that’s exactly what they get to do. They get to stay in the tool that they’re already using.

    Ashley: Mm-hmm.

    Johnson: But when it comes to developers, this is where we kind of get into our most complex customers. Ultimately, the customer is an organization that’s building a data-centric tool or a platform, and their developers, you know, they’re the ones responsible for maintaining the connections to data from those tools and platforms. So, you know, you’re building the best BI tool on the planet but if it only connects to SQL server, is it really the best? So, we’ve had companies come to us and use our drivers to build products. And what it really frees up there is one-off API integration.

    So, if you’re building a tool and you’re connecting directly to the API from your tool, integrating against Salesforce looks one way, integrating against NetSuite looks another way. Integrating against Google BigQuery looks a completely different way. But as soon as you use our drivers, it all looks the same. If you can develop a tool that can talk to a database, you can develop a tool that can talk to anything.

    Ashley: And one of the situations I’ve run across several times is through M&A, when you start bringing companies together through acquisitions and of course—

    Johnson: Right.

    Ashley: – you know, you need information, you need data to operate. I mean, just imagine combining a sales organization across two or multiple companies together and ones in Salesforce and one’s in HubSpot and one’s in homegrown whatever.

    Johnson: Sure.

    Ashley: And, you know, getting that data quickly, you don’t wanna have to go through a whole conversion and, “Okay, now everybody’s in Salesforce” or whatever your tool of choice.

    Johnson: Right.

    Ashley:  Maybe that’s where you go, but you may live six months, two years, where you need data out of multiple systems to see your pipeline, see the sales bundle, see, you know, how we’re closing the deal and what’s the conversion rate and all those kinda things for. And tools like CData are extremely valuable in getting to data very quickly to get value out of that [Cross talk].

    Johnson: Right, yeah. I mean, that’s, legitimately, our own personal story. So, when we first started as a business, we had a homegrown CRM, and then we started incorporating HubSpot. And now, you know, as we grow, as we get bigger, those systems don’t work for us anymore, and so now, we’re using Salesforce. And we’re in a place right now where we are concurrently using all three, and actually using our own technology internally to build reports, to do analytics, and then, as part of that process, to migrate data from one system to another—so, moving our data from our internal CRM into HubSpot and then into Salesforce.

    So, because the drivers are standard based, because they make things look like a database, it’s incredibly empowering for IT teams and DBAs to work with the data and to either consolidate it or migrate it, or leave it where it is, but build up connections to it in a way that lets the other data experts, the C suite, whoever needs to see the data, see it quickly and easily.

    Ashley: That’s a good point. We don’t always wanna take on the work of combining things, migrating things. If you can leave data in place, that makes sense to do.

    Johnson: Yeah.

    Ashley:  Boy, what an asset, because now you can get to it, but—okay, just manage it the way you were. And it’s great that you could relate to that example that I brought up where we didn’t coordinate that, at all.

    Johnson: Yeah.

    Ashley: I’m curious, how about the security? What comes with data, security is always super important to access control, things like that. Where in the stack does that fall, and how does CData play in those roles?

    Johnson: Yeah, so, we will leverage whatever security is available from the API. So, you know, as one example, Salesforce users have different permissions, whether that’s permissions to access different entities, permissions to only read entities, to write entities, whatever the case is. 

    So, when you connect to Salesforce using any of our connectors, you choose the user that you wanna connect through and then everything that they can do, you can now do through our connector. Anything that they couldn’t do before, you can’t do. And then we support the full gamut of authentication protocols. So, if an API supports OWASP, we’ll support it. If an API supports other authentication schemes, even—so, like, your Microsoft based products, on premise, we do NTLM. If you’re looking at Kerberos authentication, we can manage single sign-on—just whatever is available there, we allow.

    And then the protocols that the API uses for security—so, SSL, the encryption, all of that is supported as well, so.

    Ashley: I think an advantage you have, since you’re not pulling the data out of those systems and storing it somewhere else, it’s still data that’s living there—

    Johnson: Right.

    Ashley: – all the security systems, the access controls permissions, policies, et cetera, are still within those applications, however they’re managed, either standalone or collectively across those. So, you’re not having to devise some new data permission scheme from that, right?

    Johnson: Right, right.

    Ashley: That’s gotta be a huge plus.

    Johnson: Yeah.

    Ashley: Cool. What do you see as—while we have some time left, here—I’m interested in what you see as sort of emerging applications. You know, we’ve seen a lot of acceleration with digital transformation.

    Johnson: Yeah.

    Ashley: Digital engagement with customers, automation—there’s many more things happening, and of course, those both need data and create data.

    Johnson: Yeah. So, you know, I think one of the things that we’ve seen of late is just this migration to the cloud, where everything is in the cloud, your data’s in the cloud, you’re doing BI in the cloud. So, through products like Tableau Online or the Power BI service, instead of Power BI Desktop, Google Data Studio, AWS QuickSight, whatever the case is, you know, you’re working with data from a cloud platform now instead of something on premise.

    So, what we’ve created is, we have a cloud platform that creates a cloud to cloud connection. A lot of the tools that exist today, you know, even if you wanna go from a cloud platform to a cloud data store, you’re still required to put a gateway on premise somewhere. You know, this is the case with a lot of the Power BI connectivity. And, you know, if that doesn’t—why would you go down from the cloud, to on prem, back up to the cloud in order to work with your cloud data? And so, that’s—the CData Connect Cloud Platform is what it’s called, but it allows live, real time cloud to cloud connectivity. 

    And so, you know, that’s one of the, kinda the emerging trends that we’ve seen is people wanting to just do everything in the cloud. And it makes sense, especially—you know, I think about this past year, right? Everybody’s working remote, you know, you don’t have an on premise server sitting somewhere that can run your platform, you have to move it to the cloud so that everybody that’s working from home can access it, and that’s just one example of this cloud migration that we’ve seen.

    Ashley: Nothing like a pandemic—I say that knowing the human tragedy side of it, all due respect, but—

    Johnson: Yes.

    Ashley:  – to really force some very aggressive changes in our business and how we operate and some really interesting things. Is there a particular area of, you mentioned cloud and more usage of cloud services—what’s sort of the next frontier, if you will, that CData is tackling of how to make this data problem easier?

    Johnson: Yeah, so, I think—you know, we’re thinking about that cloud integration problem and trying to look for ways to help that. But you know, an area that we’ve started pushing into recently is kinda low code developers. So, I had mentioned you have your IT teams and your full stack developers that are used to working with data, that are used to writing code. But something else that we’ve seen crop up is this low code application development—whether that’s in a cloud platform or an on premise platform. And it’s great. You can build a workflow or an app using a drag and drop menu. These platforms tend to be intuitive. And now, your citizen analysts can build a workflow to combine data to get what they need into their BI tool.

    The problem that we’ve seen there is connectivity to data from these platforms, and so, that’s kind of an area that we’ve been pushing in an integration kind of marketing side is reaching out and trying to connect with low code and shoring up our integration with these platforms.

    Ashley: Yeah, and by the way, that happens to be an area of research that we’re working on with CData, and we’ll talk a little bit more about that here coming up in a few weeks—some really good, interesting findings from that research.

    And that was really interesting to Accelerated Strategies, the analyst firm that I run, because there is so much interesting in low code/no code right now.

    Johnson: Yeah.

    Ashley: And of course, it’s so broad of what that means. It could mean a spreadsheet to somebody, you know, as well as low code or platform, you know, there’s a number of platforms for creating applications and accessing data through a CData kinda combined platform. So, it’s really interesting, to me, of kinda who is using low code technologies to create applications.

    And I think the world used to view it, or maybe currently views it as, those are the business users, non-technical. That’s certainly a population, but it’s more and more coming into IT is what I’m seeing.

    Johnson: Yeah, that’s cool. I mean, as somebody who was a developer, was a support engineer, it’s fascinating for me to get my hands on a low code platform and figure out, you know—well, what exactly can I do with this?

    Ashley: Mm-hmm. Yeah, it’s interesting technology. Another way to solve problems, another technology, right, to build the applications.

    Johnson: Right.

    Ashley: How about the mobile side of this? With so many more mobile apps, we’re almost in an era, maybe we’re in the era of, “I’d like fries with that, I’d like a mobile app with that.”

    Johnson: Sure.

    Ashley: Or maybe it is mobile first. Does that change the dynamics of some of the data needs or challenges?

    Johnson: So, I think once you start looking at mobile applications, you’re looking for lightweight applications, right? You can’t—I mean, phones are impressive now, right? Like, I think about the amount of data that I can store on my phone versus the first smartphone that I got, you know, the amount of space that I have for apps. But at the same time, you know, embedding a software library or a driver or whatever the case is into your app, it doesn’t always make sense. Especially if you’re building an app that supposed to be able to connect to hundreds of different data sources.

    Ashley: Mm-hmm.

    Johnson: You know, are you gonna install 100 different 7 megabyte drivers with your app? Like, is that really the best way to go? And that’s another place where our cloud platform makes sense. So, you can be on your mobile app, you can connect—you can build an application that connects to a cloud platform that then allows users to connect to data from anywhere.

    Ashley: Mm-hmm.

    Johnson: So, you know, using the same technology that we have, it’s just consolidated into one single platform. So, you hit that platform and now, you know, you can pull in Salesforce data, you can write back to HubSpot, you can dump a report as CSV into AWS S3, all through one platform.

    Ashley: And you know, so many of those apps aren’t necessarily greenfield apps, right? All that data, maybe even the transactions processing, much of it is happening in other apps, other cloud locations.

    Johnson: Right.

    Ashley: So, when you’re building a mobile app, you know, you’re not inventing everything from the bottom up, right?

    Johnson: Right.

    Ashley: You’re merging a lot of existing resources—functionality as well as data. So, it seems like no better—what better of a kind of application where making it easier to get the data? Because, you know, mobile developers don’t like writing database access code, right? They like building interfaces and doing cool interactions and useful interactions with customers.

    Johnson: Right, right.

    Ashley: So, when you can let them focus on that and really create great experiences with that data, that’s a win/win for everybody, it seems like.

    Johnson: Yeah, no, I agree.

    Ashley: Well, cool. I really enjoyed talking with you, and where can folks find out about CData? What kinds of abilities do they have to check you out, from free accounts or sandboxing or things like that?

    Johnson: Yeah. So, CData.com is our website, and you’ll find all the information that you need there. For any of our installable products, we offer 30-day free trials, and they’re fully functional trials. You know, we’re not rate limiting, we’re not doing anything like that. And then with our trials, you get access to our support team, which we’ve been called world class, we have testimonials on our website if you really wanna dig into those.

    Ashley: Comes from a man who was on the support team, so.

    Johnson: That’s right. [Laughter] 

    Ashley:[Laughter] No, I’m sure it’s really great.

    Johnson: And then, you know, for the Cloud Platform, I think we offer a two-week trial, and so, you can kinda kick the tires on that as well. So, CData.com/drivers is where you wanna go if you’re interested in an installable driver. CData.com/connect is where you can go if you’re interested in that Connect platform, that Cloud Platform for connectivity. And then, you know, you can find us on LinkedIn, you can find us on Twitter, we’re @CDataSoftware. You can find us on Facebook. A lot of our posting there is upcoming events or recent articles or other news announcements, so.

    Ashley: Yeah, and I have checked out your drivers, and you know, an analogy like a Swiss Army knife falls apart very quickly, because you have so many technologies, so many platforms that you interface with—it’s about 50 Swiss Army knives. [Laughter] 

    Johnson: Yeah. So, I’m just gonna plug this—so, I think we’re 250 plus different data sources across 11 technologies. So, somebody out there is doing the math right now in their head to figure out how many SKUs we’re sitting on right now.

    Ashley:  The number of permutations—well, good. It’s really been good talking with you, and I look forward to having you all on again and talking some more, I think, about the low code/no code space and some things that are happening there, so we’ll look forward to that.

    Johnson: Yeah. Alright, yeah. Thanks, Mitch, it’s been my pleasure.

    Ashley: Great. Jerod Johnson, who’s Technology Evangelist with CData.

  • DevOps Chat: Maximizing the Benefits of DevSecOps

    DevOps Chat: Maximizing the Benefits of DevSecOps

    When discussing security in DevOps, we often focus on the security tools instead of the DevSecOps process itself. In this DevOps Chat, ZeroNorth CEO John Worrall takes us to the root of “why” DevSecOps, focusing on the business benefit, gain and measurement of what we seek to accomplish through DevSecOps. John advocates we concentrate on the process and data enabling us to assess risk, prioritize the most beneficial security work and for decision making to creating business value.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Mitch Ashley: I have the pleasure of being joined by John Worrell, who is CEO of ZeroNorth. Welcome, John, good to be talking with you today.

    John Worrell: Thank you, Mitch. Good to be here as well.

    Ashley: And we’re talking about security and DevOps, DevSecOps. But before we get to that topic, would you tell us a little bit about yourself, let our audience know a little bit about ZeroNorth, too?

    Worrell: Sure, I’d be happy to, Mitch. I’m John Worrell, CEO of ZeroNorth. We’re in the DevSecOps space, maybe with a different approach that, a lot of times people focus on tooling. We believe that you need to kinda build a process out first for DevSecOps to actually have business value, and I’d like to maybe talk through that with you, Mitch.

    Ashley: That’d be excellent. I’m all about the business value, too. [Laughter] So, let’s talk about that. So, usually, when you say DevSecOps, it’s about shift left, how you need to get to the security people working with the software folks, how do you help developers write more secure code? You get to the tooling conversation.

    So, I think you’re talking about—well, let’s stop for a minute and ask why are we doing all that stuff? Yes, let’s create better app security, but why do we need to make this a process that produces, maybe, some business value, measurable results, those kinda things?

    Worrell: Yeah, you bet. That’s exactly right. We’re all for the tooling, we’re all for building the bridges between security and the Dev teams. But you have to have an objective in mind, and you have to have some help along the way. You have to have some data along the way that’s gonna actually get you there to pull all that together.

    One of the best quotes I ever heard that got applied to this was channeling your inner Deming, which is, you know, if you can’t describe what you’re doing as a process, you don’t know what you’re doing, right, and there is a real lot of truth to that. If you step back and look at AppSec over the years, it’s been very tool-centric, very sporadic, anything but a process. When you look at DevOps, it’s a process, it’s repeatable, it’s scalable. It’s kind of a self-learning or positive flow of information with telemetry so you can get better and better at it over time just by learning from your past experiences.

    And when you think about integrating security into Dev to drive DevSecOps, you have to think about it the same way, and I think that’s where it all starts. This is a process, this is not a tool selection, this is not just a scan or an integration, it’s that process that you need to build first, and then you can start building out your tooling, your technology underneath that.

    Ashley: You have a really good point, and if I’m being over general here and generalizing this, as security professionals, we kind of think of, “Let’s buy boxes, let’s buy software, let’s put functions into the network, into software, and not into the software development process that will solve our security problem.”

    But security is not just people attacking you, it’s also how you do your work and making sure you create a secure environment, you operate securely, write secure code. So, I think you’re spot on about the process and how you can do that consistently, referring back to Deming, right?

    Worrell: Yep.

    Ashley: You can’t manage what you can’t measure, your adaptation of that phrase. So, talk to us a little bit about how do you make that real? When you talk with people, how do you help them sort of elevate the conversation to that and then get on the right track?

    Worrell: So, I think it starts out with that process conversation and whichever analogy you’d like to us for that. Think about it this way—the process, in our view, works like this. You’re gonna set some kind of a governance standard for your organization. You can’t have each Dev team setting their own or each business unit setting their own, you’re gonna wanna try to get global visibility so you can actually have effective global risk management. And we’ll start that as a kinda catch-all for the business objective—but in a sense, that really captures what we’re trying to do with DevSecOps. You need global risk management across your organization. That means you have to have some visibility into it, but you have to have a way to impact your current state to make it better, and you need a process to drive that in a continuous way.

    It starts with setting some governance standards and saying, “Okay, what is our ideal objective for our top tier applications? What is our ideal objective or governance model we wanna put around our mid-tier?” or whatever the application categorization might be. Then you wanna make sure you’ve got a continuous process to build the data that’s gonna inform you, whether or not you’re actually meeting those objectives. You have to look at performance reporting so you can measure how you’re doing against that. 

    And then you have to be able to action that intelligence to say, yeah, that data is helpful to me for a number of reasons. Number one, I get visualization of risk, I can get prioritized remediation if I do this right so my developers can make intelligent business decisions about which vulnerabilities get fixed now before we progress the build and through the build. The third piece of that is, which teams need what kind of training on security coding, good security coding practices? Instead of trying to treat everybody the same, use this telemetry to say, “You know what? Team A is struggling with cross-site scripting. Let’s go do a lunch and learn with those guys and watch the immediate impact we’re gonna get from that” and then let the process continue and go all through. There’s a lot of technology in there, there’s a lot of things in there, but it starts with the process.

    The next piece that’s really critical is the data that comes out of that, right?

    Ashley: I was just gonna ask you about the data part of it. [Laughter] 

    Worrell: [Laughter] That data drives everything. It drives so much. You know, we had talked about this idea that you’ve got different tooling—well, sure you do. You want the best tool that you can get, you want best of breed. But trying to pull those tools or the data from those tools into some meaningful, actionable intelligence is a key step in the process, right? You wanna take different data points and put them together so you get a complete view of what the risk posture is for that particular target or entity or application you’re working with.

    We talk about the analogy of the blind man and the elephant. You have four blind men all experiencing an elephant from different places, and they all can come up with a different understanding of what they’re really touching and trying to investigate. And it’s a perfect analogy for a multi-tool environment when you’re scanning across the pipeline that, if you just look at one experience or one tool, you’re not gonna get a complete view of what’s going on.

    Imagine the difference of being able to just do static scanning and realize that you’ve got all these highs and criticals, but not compare that with your dynamic. So, a lot of those highs and criticals may not be exposed in my environment, right? I wanna pull those together.

    I’m trying to understand, number one, where the risk is, but I’m also trying to optimize my developer productivity and making sure they’re not fixing a bunch of stuff that doesn’t need to get fixed, if I’ve got a compensated control in place or it’s just not exposed already. That’s not high on my list. I want to really focus in on what’s valuable.

    So, that data can be used for making good business decisions on risk. It can be used for prioritizing remediation. That data can be used for, you know, call it the wall of fame, wall of shame. It’s how do you really measure and incent and reward your business units for meeting their risk management targets, right? Again, how do you help those that are lagging behind, how do you help them get better?

    And that, to me, built into this process, is where you get real business value. You’re getting the faster delivery of software, you’re getting the better developer productivity out of this, you’re getting that risk management layer and visibility you need, but you’ve got it as a process, and you can measure week to week, month to month, quarter to quarter, how much better you’re getting at it. That, to me, is a real business solution.

    Ashley: You know, you described a lot, so let’s unpack some of those things. The third piece of it usually is, you know, you talk about people process and technology people. What are the kinds of roles of people who are gonna be using that kind of information, that kind of data? Because we’re often talking about getting security information into the developer’s hands so they can fix things, but you’re also talking about, “Well, what should we fix? Let’s not waste our time on things that don’t matter, right? The environment secures against cross-site scripting, so let’s not worry a much about maybe that as something that can be exploited.” Who uses that information?

    And then I guess the third part of it is, it’s about continuous improvement, that’s a cyclical process of, “Are we getting better? Are we getting value? Is there benefit to the work we’re putting in on this?”

    Worrell: You bet. So, you’ve actually said a lot there, too, so, I’ll try to—

    Ashley: I did. I’m just following your lead, John. [Laughter]  

    Worrell: Yeah. [Laughter] Good, we can confuse each other in this whole process.

    So, you know, if we start with this idea of the continuous improvement, just kinda going backwards here, the whole goal is to have that process, which is a continual healing process, if you will, you’re always gonna get better. DevOps does that with telemetry about, “What is the productivity of my developers? What are my key metrics on how many story points I’m taking down, how many am I delivering, and am I getting better, sprint after sprint after sprint?” All great stuff—the same model plays out in security.

    That ties back to one of your comments about the role of the CISO. You mentioned, you know, typically, security guys, via technology, they deploy it. And that works or a proactive control, which is what security’s been doing so much for. My days of running the product for RSA SecurID and working at CyberArk and any kind of blocking technology or control—it is. You buy it, you deploy it, you set it and forget it, for the most part, and it works, right?

    By the same token, this isn’t really responding on the SOC side, either, right? This is not responding to an in process attack, this is a different approach to security. And I think the reason that’s important is, number one, businesses are demanding more business metrics, business telemetry out of their security programs, what am I getting for my investment? How do I know I’m investing in the right things? Am I spending in the right places? All of those things are really important, right?

    And the role of the CISO, by definition, is evolving as well. And you can see the people that were running security teams 10 years ago are very different than the model who’s out there now. Many people have grown into that role. Other people have come from the business side of the house, and they’re not the technology experts that were good at configuring firewalls that were really trying to deliver business value to the organization. And if you’re gonna step from infrastructure into the world of application security, you need to be able to have value to the business, and this data is a great way to deliver value to the business.

    Ashley: Really important point, because the CISO role is evolving, and oftentimes, it’s becoming a CIO/CISO kind of role, which means you’re getting into the application stack, not just the network stack. Not saying that they weren’t worried about the app stack, but now you’re getting much more into the nitty gritty of it. And are your security people software people? Well, not necessarily, but they are very accustomed to getting data and responding to that data, and in this case, maybe helping development teams, developers, others with understanding what the true severity, not what some scanning tool might say, right?

    Worrell: You bet.

    Ashley: Which is sort of our history with vulnerability management, [Laughter] to really help them understand, “Okay, great”—and then demonstrating to the business, to compliance, to whoever you may need to be reporting to, it could be customers as well, to say, “Here’s what we’re doing. Here’s the actions that resulted from investment in these tools, people, and processes.”

    Worrell: And that customer angle is actually really important. And I hate to use the word SolarWinds, but I’ll use it. It’s just put, yet again, a big spotlight on software supply chain, software security, and how critical that is. And so many organizations now are asking of us, as well as our customers, “What is your software development process? Prove to me you’ve got one.” Right? Great use of this data.

    When you think about your business line risk owners, the people that are actually responsible for data, they work for the GM or the SVP of that business unit, they’ve got the risk management challenge. They need this data to do their job well. If you take that data to the board, our data is being used as part of the quarterly board package to talk about how they are addressing and how they are improving the risk posture of the organization.

    And then, I wanna go down, really, one level deeper. Because when you think about this, you know, integrating into the DevOps process means that it’s not necessarily just about the developer making that independent decision. Typically, there’s a product owner in there some place that’s gonna be making some decision about what’s gonna get done now versus what’s gonna get done later, right?

    So, being able to feed that product owner with the data they need to help do the triage and make those decisions, that’s another great use case of this data we’re pulling together.

    Ashley: You know, you mentioned a lot of roles, too, including the product person. In your experience with ZeroNorth—and I really appreciate your background in security, too, so we can relate about those days as well—what’s most often, when people come to ZeroNorth and say, “Hey, we need your help, here’s what we need your help with?” Is it the software team, is it the product team, is it the compliance group, is it the CISO/CIO? Usually, what’s that initial driver for engaging with you.

    Worrell: Yeah, there’s probably two different ones we hear most commonly. One is, “Hey, I’ve got a somewhat mature program, I’m running two or three different tools. I can’t make heads or tails out of the data, or if I try to do it, it’s manual, I can only do it once a quarter or once a month, it’s just too labor intensive. So, I think I’m getting good, I’ve got a decent process right now for scanning, but I wanna start pulling that data together.”

    The second use case is those that wanna start out on building what we would call a federated or a shared governance model, and it’s led by the security team, perhaps, but they know they’ve gotta bring in the business line owners into this process, or business line risk owners into the process. And they say, “Hey, can you help me get data out there so I’ve got a single source of vulnerability truth or my applications?” And I’m looking at the same data that they’re looking at, we’re all making decisions off that same set of data so we can build a governance model that makes sense. 

    The security guys wanna work in partnership with the business owners and the people that are actually doing the software development and risk owners in the business. But that relationship is gonna get built on having really good data and everyone using the same data. I think that’s another use case.

    The third one, which is a variation of that, is people that are coming in and really saying, “Hey, listen, I need to go to full DevSecOps right away. I know that I can put this layer of reporting and analytics on top of my current tooling and that’s a great start, and I’m gonna build this over time.” It’s a fine strategy. Other people are coming in because they’re just getting started or they just have a business imperative to do it and they’re saying, “We’re going to DevSecOps right now, and we wanna do the pipeline integrations as well as the reporting and analytics that we’ve been talking about so that I do get that data in real time, I do have a consistent scanning process, it is automated, I don’t have to worry about the developer forgetting or not doing it, and I’m gonna get that data value out of this in that particular way.” 

    Ashley: Yeah, “Help me accelerate through the learning curve instead of making all those mistakes myself to get to DevSecOps, if you will.”

    Worrell: You bet, you bet.

    Ashley: That second example especially kind of is a multiplication of the first one, which is, you have Dev teams with all this data, maybe it’s the primary group—usually, it’s multiple, right? How do you pull it together into something? They can’t make sense of it. How do you do that across the enterprise to meet compliance requirements or even just your own internal assessment and reporting up the management chain maybe to the board.

    Worrell: You bet. If you step back, the biggest concern we get out of just about everyone we talk to is a CISO or a Risk Manager saying, “Hey, help me, I’m flying blind. I don’t know what highs and criticals I’ve got in my production environment right now. I just don’t know. I don’t have visibility into it. And for me to get it, it takes too much effort, and once I get it, it’s outdated, because it’s 30 days old. I’m pushing code every day” or every week or whatever it might be.

    And that is the primary motivator or so many people who just say, “Gimme that visibility, and that’s the starting point. And then at least I know what I’m dealing with and then I can start building out a program that’s gonna help me address that over time.”

    Ashley: You know, you brought up SolarWinds, so I’ll bring up COVID. What have you seen happening over the last 12 to 18 months with the acceleration to the cloud, acceleration of digital transformation projects? Has it taken these same issues and just made them even more visible critical to address, or have new problems emerged?

    Worrell: I think it’s more of an acceleration of the entire process. In general, COVID has driven people to be more comfortable or more reliant on relationships with their customers, with their partners, with their employees. And that means more software, by definition.

    So, as digital transformation accelerates because of more online interaction and new business models that this opens up, it’s just really accelerated the pace and some of the maturity of people coming. The types of questions we’re getting from our prospects now are much more advanced than they were a year ago. And that just shows that the market is really getting smart about this and they’re kind of moving beyond the tool only approach to say, “Okay, how do I get some business value out of this that can really, really help us move our risk management program forward?

    Ashley: That’s one of many indicators I see, kind of data points that are saying the technology groups, the software groups are getting out from under, looking at themselves and starting, trying to get aligned with the business and meet where the business is headed.

    Worrell: And as a big consumer of software, as we all are in our lives today, I’m really happy to see that, right? I mean, that’s what I—I know it’s gonna take bringing the two together and working cooperatively in that federated or shared model to make this work, and I’m really happy to see that kind of a progress. Because, like you and everybody else, software just drives so much of our daily experience.

    Ashley: It is. Can’t do much without it these days. Well, it’s been great talking with you, John. Where can folks learn more about ZeroNorth?

    Worrell: Well, that’s easy, ZeroNorth.io. We’d be happy to talk to you. Take a look, see what we have, and if we can help you out or you wanna hear more about it, we’d love to chat with you. Thank you very much.

    Ashley: Yeah, I think we’ve had a great conversation. Hopefully, that’ll spark some folks to elevate that conversation with you and the ZeroNorth team, so take care, we’ll talk to you again soon.

    Worrell: Thank you, Mitch. I appreciate it.

    Ashley: You bet. 

  • Web Isolation and Secure Web Gateways with Menlo Security

    Web Isolation and Secure Web Gateways with Menlo Security

    Since the COVID-19 outbreak, many enterprises have implemented remote work policies to monitor network traffic and protect sensitive data. Organizations have been adjusting and adopting new practices and technologies to improve data security across cloud-based environments.

    In this episode of TechStrong TV, Nick Edwards, vice president of product management at Menlo Security, joins Mitch Ashley to discuss the move from network and application firewalls to creating web isolation, using secure web gateways for updated, contemporary cloud security.

    The video is immediately below, followed by the transcript of the conversation. Enjoy!

    Transcript

    Mitch Ashley: I have the distinct pleasure of being joined by Nick Edwards. Nick is VP of product management at Menlo Security. Welcome, Nick—good to be talking to you.

    Nick Edwards: Hey, Mitch, thank you. Glad to be here.

    Ashley: Excellent. Well, tell us a little bit about yourself, and tell us a little bit about Menlo Security for folks who may not know much about Menlo.

    Edwards: Sure, yeah. So, I am VP of product management at Menlo Security. So, my team is responsible for kind of product direction and definition of our company and where we’re taking our product line. 

    I came from somewhat of a circuitous background. I spent time in the Navy, I was a Submarine Officer, so I kinda feel like I’ve been, you know, in the good guys versus bad guys world for a while. And, you know, cyber security has always been something that’s kind of near and dear to my hart, just because, as a society, I think technology can bring on so many positive changes, but it’s unfortunate that we have to deal with this overall drag of embracing it because people are capitalizing on it.

    Ashley: Mm-hmm.

    Edwards: And Menlo was started with the fundamental notion that how we’ve been going around fighting security is just not keeping pace with kind of where the bad guys are and where the threats are. You know, in the traditional world, it’s around letting traffic in and then inspecting it. You know, you basically put the traffic stream underneath the magnifying glass, you have the Petri dish, “Is this a virus, is this malware, is this phishing?” or whatever it may be. And the industry has gotten a lot better at detection, but the bad guys only have to be right once.

    And so, our fundamental approach is different, which is—you know what? We’re gonna not let anything in, and instead, we’re gonna give you a clean stream that is reconstructed via our technology called isolation. And so, you’ve probably heard this term of web isolation—that’s what the company was founded on, and that’s what we do. And it’s been primarily made more simple to adopt and execute on by the advent of cloud computing and the capabilities that are continuing to expand kind of on that front. So, we’re excited to be here, excited to talk to you more about it, and let me know what you think about, what you wanna talk about.

    Ashley: Cool. Well, you know, as more and more of the network stack has been virtualized and turned into software, it makes sense that you’d see innovations like what Menlo Security is doing, right? Because you can do things very quickly and innovate very quickly in that space. And it’s kind of interesting to me that—you know, we hear about network isolation in WiFi and other technologies, because the pipes are just getting bigger, of course.

    Edwards: Mm-hmm.

    Ashley: And just, that much more of trying to inspect as it’s coming in in real time, it makes sense that—I can see how reconstructing that web stream, as you’re talking about.

    I’d love to get your perspective of what’s the thing that somebody goes, “You know what, we need a secure web gateway instead of what we have”—what is the impetus, or impetuses, if that’s a word, to say, “I need to get to the next thing, because this ain’t workin’ for me”?

    Edwards: So, I think a couple of factors. I think one, and we saw COVID and the work-from-home dynamic of the past year expedite this, is just that when you and I were growing up in the office of 20 or 30 years ago, everyone got in their car, they drove to the parking lot, they walked in, their computer was waiting for them, and everything was in one location. And that made it easy to apply security and controls. 

    I remember my first spam message that I got, you know, in 2001 and I thought that was really weird. And I remember not being able to go to certain websites, and it was very easy to do that because everyone was in one location or, okay, maybe a big multi-national had three different locations, but it was all connected to the same network and it was easy to provide policy, and kind of what proxies merged from that environment.

    Now, you fast forward even to 2019, you know, roughly 20% of the workforce worked remotely. Then, during COVID, it quickly became 75% or greater. And so, with that, it meant that everyone is everywhere. You know, you might be at home, at a coffee shop, in the old days at a WeWork or something. And in that environment, it was very difficult to apply security based off of different devices they were accessing the Internet with, what they were doing, where they were coming from, and COVID just made that worse.

    So, I think what we’re seeing in our customer base, the people we’re talking to is, they realize that they’ve been kind of using Band-Aids to hold the old notion together, but they realize that the cloud offers a new way to think about things. And it isn’t just taking the old widgets and just dumping it in a VM, it’s about—hey, is there a way to fundamentally rethink how we can leverage this technology to advance our business needs?

    And I think all that combination of factors, you know, different users coming from different places, different devices, what they’re trying to do, applying policy based off the context of the user—all those factors have combined to really, I think, kind of introduce this tipping point of new ways of thinking about leveraging technology. I think web gateways delivered via cloud form factor is one of the primary kind of locomotives for people to rethink about their architecture.

    Ashley: It’s interesting you say that. I’ve had several discussions in the last month or so about, as people are thinking about a hybrid office or something about returning to the office, it’s really easy to kinda fall back into, “Well, let’s do what we’ve been doing, right, and make some adjustments.” And I had to go through this transition, actually, a few years before this of thinking about it as just a work anywhere strategy, whether they’re sitting in Starbuck’s or sitting in the United Club, they’re in London or Denver or South Florida—wherever they are, or in an office, or at home, or on the beach or whatever, you just have to think about it.

    And I think that was one of the choke points we ran into with COVID was, the natural tendency was, “Well, okay, swing all the traffic onto the corporate VPN, push it all through our existing pipes” and sometimes, that can fall apart on you, right?

    Edwards: Yeah.

    Ashley: It’s just so much of a big swing. How do people need to rethink this, you know, thinking in a secure gateway, web gateway mode?

    Edwards: Yeah, so, I think that whole trend that we described of, “Put everyone on the VPN” and then—uh oh, VPNs can’t keep up, call up our VPN vendor, give us 50 more boxes. 

    I think what we’re seeing customers re-evaluate is, instead of giving everyone access to everything, let’s flip it on the head and say, “Let’s give them access to only what they need.” And this notion of zero trust is what is kind of capturing this movement, you know? “Okay, we know this is who you are, this is your role. You may be a salesperson—you don’t need to have access to Jira or Jenkins or these development tools, but maybe you need to have access to our CRM system, our customer application for managing pricing and quotes and all this kinda stuff.”

    So, zero trust [Video freezes].

    Ashley: Oh, we lost Nick, there. Let’s see if he comes back—oh, there, you’re back.

    Edwards: Okay.

    Ashley: Okay, so, just, why don’t you re-start with, you were talking about Salesforce and getting access to the applications, you don’t need Jenkins and Jira and stuff. So, you can just pick up on—so, zero trust in a secure gateway, web gateway means this.

    Edwards: Yeah. So, zero trust in a secure gateway mans that, instead of giving users the ability to go wherever they want just because they’ve authenticated, you give them the ability to access the content that they need associated with who they are and their job. You know, a sales rep might need access to certain applications that an engineer might not need access to.

    The VPN model allows anyone who gets connected to have access to whatever, and cyber criminals realize that and they can move around laterally and they can exploit that. And a similar type of construct applies when you’re facing the Internet side of the network. Get people access to what they need and secured gateways via the cloud have much more granular capabilities to do that with tools like CASB, DLP inspection. 

    I think cloud gives the ability to do things at scale that on premise proxies can’t. So, for example, something as seemingly mature and pedestrian as SSL inspection, you know, that’s been around a while, but I remember in the old days, having to scale X number of proxies to be able to address the traffic. Now, almost any website that is being used in a professional manner has SSL and cloud allows you to inspect that very easily and very seamlessly. 

    And on a Menlo perspective, zero trust says, “Hey, look, for Internet related applications, deploy the same type of mentality,” except you flip it on its head and say—don’t trust any of this content from these websites. Okay, maybe you wanna trust O365 for Microsoft, dedicated IP space, domains, you may wanna do that. Or Zoom, for example. But other than that, you might wanna say, “Let’s just allow a clean stream to come in.” And that’s what Menlo does with our isolation by kinda stripping away all the active content, rewriting the web traffic, and giving this native experience to users in a way that doesn’t disrupt their flow or doesn’t require another agent to be deployed on their endpoint.

    Ashley: Plus you have the scalability of the cloud, right? So, you’re not looking to add another box, right, to do this.

    Edwards: Yeah.

    Ashley: It’s, “Okay, great, traffic doubles, we’ve got the resources right there to handle it.”

    Edwards: Yeah. Yeah, that’s right. And, you know, there are some vendors out there, I think, in the cloud web gateway world who have done a lot to mature the industry’s understanding of it. But there’s, again, I mentioned this earlier that properly capitalizing on the benefits of the cloud doesn’t mean taking what you were doing on premise and then just dumping it in a cloud data center. 

    It gives the opportunity to think about things anew and potentially consider new architectures, and leverage the autoscaling of public cloud infrastructure where it makes sense, leverage the near infinite compute and all these things where it makes sense, but still be able to deliver the same type of capabilities. And that was kind of the approach that Menlo took, being kind of more of a cloud native security company delivering these capabilities to our customers.

    Ashley: Mm-hmm. I wonder, too, if—you know, we have different software architectures that can tend to be more porous, you know, with microservices, service mesh, et cetera. We have hybrid, multi-cloud—so, we’ve got a much more, in some ways, complex environment than we had in our on premise data center if that, I don’t know if you wouldn’t say it was complex, it was. But it’s a different world, and the pace at which it can change is so much faster. I mean, you can have an application pop up in a week or a day or an hour that wasn’t there, and now you have to be able to respond to, “Oh, sorry, we didn’t enter a ticket for security to configure us,” right?

    Edwards: Yeah.

    Ashley: You need to be able to react quickly. What do you think are some kinda new applications that are pushing the boundaries of security that make it easier to do it in the cloud?

    Edwards: So, I mean, I think in general, there’s a proliferation of engineering teams inside organizations that are adopting the same type of model of just rapid iteration and agile development for their own products that they’re releasing to their customers. And so, the companies that we’ve seen are some that, they may actually use a combination of AWS or Azure or Google, but they’ll also probably use some of their own data center infrastructure that they’ve already leveraged in a model that is very similar to AWS.

    So, I think this notion of customers going through this migration path, of going from all on prem, maybe with a target of landing with nearly all SaaS, there will be this period of kind of hybrid modes where multi-clouds exist, their own or a public cloud. And I think what we see is customers kind of chipping away at this over time, and an application that was on prem, they say, “Okay, let’s run it in our own kind of cloud data center type of thing” and then slowly migrate that over to AWS or whatever.

    So, we see a lot of this kind of sequenced staging of applications and assets, and with that, it means that the data ends up living in these different places as the application evolves. So, from our perspective, this requires of our customers a rethinking not only of the technology assets, but also the team structure and the profile of the teams. All these teams have to have some level of application understanding, scripting, automation capabilities, whether you’re the application developers or the networking teams, or the SOC teams. 

    And I think the vendors who will end up winning in this world from a security perspective will build security tools that play well in that environment. So, we’re talking about having APIs that will work with their SOC teams, have APIs that will work with, come to their networking teams, so if they need to make network changes quickly, then the cloud applications will be able to respond accordingly.

    And so, in that world, it helps kind of being API friendly and kind of cloud native, because hopefully, that will easily extend to the environments that we’re deploying in from a customer point of view.

    Ashley: There we go. I keep hitting my mute button. You’d think I’d be used to this by now. [Laughter] You mentioned several things I thought were really interesting, and one of them is that, we’re using many, many more SaaS applications, as you referred to, Office 365 as well as SaaS applications, but think how much more Slack and Team and other online non-premise applications that are being used in the cloud. And a lot of times, those things don’t go through IT, and maybe the Finance Department does their own conversion from what they’re using to some cloud financial system or adding other apps to what they’re doing.

    It seems like that ability to be able to isolate some of those environments, make sure that SSL is being used across all of that, and making sure that it’s not a bigger pipe into a bigger world that’s opening up the rest of the network through somebody else’s service is a huge value, and having that visibility is super important.

    Edwards: Yeah, I completely agree. And I think one of the things, when we talk about isolation as a technology construct, not only do we essentially kind of rewrite the web stream that lands on your browser, we also have a similar capability of doing that for documents.

    So, for example, a good application is exactly what you mentioned with SaaS services, and let’s say you’re posting something on Dropbox or maybe you’re accessing something from webmail. Well, what we see customers wanting to do with our CASB solution is say, “Hey, look, we know there’s all these SaaS apps. There’s a world that we know are sanctioned by our company based off policy. So, we’re gonna let people do what they need to do there, maybe insert security for file scanning and all that kinda stuff. But if it’s an unsanctioned application, maybe we want our employees to still be able to go to webmail, but we don’t want them to necessarily download documents and potentially infect our environment.”

    So, what they can use Menlo’s approach for is to basically use isolation of the document. In this case, the document gets kind of rendered as a safe .pdf, so someone can actually still access it. You know, because IT Departments don’t want to be Dr. No and just say you can’t do anything, because in today’s environment, you know, younger employees, Millennials, that doesn’t work for them. But I think people realize that there is a balance between security and still being able to do your job and maintain your own kind of life.

    So, with unsanctioned applications, we’ll give people the ability to actually still go to these applications, but then use isolation to render documents in a secure fashion, or render the content in a secure fashion to give kinda the IT teams maximum flexibility based off policy and the use cases of the users. And I think that’s something that kinda gives the users the ability to strike the right balance based off their employee base and their business needs.

    Ashley: Mm-hmm. I think that’s a really good point. Where do people typically make this transition to a secure web gateway? Is it, “I’m in the process of moving to cloud, I’m setting up my infrastructure, getting ready to move my apps and interconnect with third party apps that I’m using, let me set it up then” or is it oftentimes, “No, I’m in the cloud, I’ve gotta figure out a better way to do security. Let me add a secure web gateway to it”?

    Edwards: Yeah, so, I would say there are kinda two types of customers, as you alluded to. There’s next gen companies who were born in the cloud and they’ve only ever known the cloud, you know? Like, consider any of your contemporary startups that are now successful public companies. They were predominantly born in the cloud, they might have added some on prem stuff for a variety of use cases, but predominantly, they’re cloud first, and they’re a different type of sell and they get it, and they understand it. And, as they have their workforce more broadly deployed, it just makes sense for them to have a way to instrument policy and security across their workforce.

    The customers who are coming from an on-prem environment, maybe traditional large financial institutions, health care, maybe military and defense environments—for them, I think, we’ve seen an acceleration of their adoption over the past several years, and really culminating with COVID as they realized, “Hey, look, this is just very problematic and costly and the TCO associated with maintaining this is problematic.” Main drivers that are the tipping point—remote us, SSL inspection and just having to deploy another box to do CPU intensive scanning. And I think just this overall notion that they realize that the SaaS adoption of all these applications, it’s here to stay, you’re not getting that genie back in the bottle. Oh, and by the way, it is making the company more effective, efficient, and in a more cost friendly manner—so, how can we find a way to embrace that trend and make our business more successful during this march toward digital transformation, but do it in a way that aligns with our own cadence of adoption?

    And I think those trends kinda culminate, and we’ll see a lot of customers start with the kind of CASB use case of securing these applications and doing it in a way that makes sense for their policy, DLP, and security related reasons, and that’s one of the main drivers we’ll see for a lot of our customer engagements when they’re coming from on prem.

    Ashley: Interesting, too. I can totally see that evolution that people have to go through.

    Edwards: Yeah.

    Ashley: Are there any operational considerations that folks need to make in thinking about security differently? Is it different from an operational world making it easier, less false alarms, those kinda things? Because we’re adding more stuff, right? I had a CISO tell me once, “Every product, I evaluate whether it adds any work. If it adds any extra work, I don’t look at it, because I just, we don’t have resources to do it. I can’t add more stuff to my team.”

    Edwards: Yeah, yeah. I think that’s a very valid concern from buyers, and we hear that a lot. They don’t want more loads for the SOC team, they pretty much don’t want another pane of glass to manage, configure and look at reporting.

    So, I think that all of these products need to think about it through the lens of, you know, not only who’s gonna be typing away setting policy, but also, the CIO, CISO, the people who are gonna be consuming the reporting and where they can get access to the information they need to evaluate their purchase decisions and that sort of thing.

    So, I think, on that level, having an API friendly platform that can integrate seamlessly with security orchestration tools, that might be a place in the Security Operations Center that can integrate with other networking devices. All that stuff helps alleviate that friction and that pain. And I think, you know, one of the things that we’ve seen for customers who deploy Menlo is that, with isolation, we actually reduce the number of spurious alerts. Because, you know, you’re not getting all this gray area vendors who rely on detection saying, “Hey, we don’t know enough to say this is bad, but we don’t know enough to say it’s good, so we’re gonna just flag this as an orange” or, you know, whatever. [Cross talk] But hey, you’ll have a human being who can look at it and they’ll decide.

    All that stuff goes away with Menlo, you know? So, what we’re able to do is just deliver this clean stream and we’ve seen multiple customers who, you know, their alerts dropped 80, 90% because of the fact that the data that they’re seeing of their users is no longer being triggered by their endpoint detection tools, these other tools that were kinda living in this gray area. And that means a lot to our customers and kinda their SOC teams.

    Ashley: Cool. What does it take to set up something like this? What’s the implementation process?

    Edwards: Yeah, so, there are a couple different ways. It depends on where the customers are coming from. I mean, I think the most fundamental, simple approach since it is SaaS is that they don’t need to deploy any hardware. There’s the PAC file that lives on all their endpoints, which basically will point traffic from their computers, laptops, et cetera to our cloud form factor, and that’s easily disseminated. Or in some cases, they might want to route traffic from their firewalls or other upstream network devices to us.

    All those things typically take less than one business day, you know, to get up and running. And we’ve had customers, one of our biggest accounts is the Defense Information Security Agency, and they’ve entered into a long-term business relationship with Menlo, and they have all these different teams who are deploying our technology. You know, different military groups, different defense agencies. And it’s basically, “Hey, Menlo, we need to get up and running on this particular agency” and it usually can happen within a matter of several days at a maximum. We’ve had customers scale to tens of thousands of users in a matter of hours. 

    And that’s, again, leveraging the benefits of cloud computing. You know, in the old days, it would be, “Okay, let’s have a pilot for a couple users, and let’s get one or two boxes—okay, great. Let’s do the math. Okay, we have 10,000 users, we need 5 more boxes.” And then if they need to scale quickly, then they’ve gotta make a phone call, I’ll have the box get shipped and all that kinda stuff—cloud takes all that headache, all that thrash away, and you can just leverage the autoscaling that’s inherent in cloud computing. And I think that’s something that really will help expedite the adoption of this as customers become more and more comfortable with security and the compliance associated with it.

    Ashley: I’m glad to hear that. You gave me a few flashbacks to the, “Where is it? It’s in shipping? Okay. Who’s gonna rack and stack it? Okay. Who’s configuring it? Okay. Who’s putting testing and putting in for”—you know? Whoa.

    Edwards: Yeah, yeah, the weekend change requests, you know, [Cross talk] by the IT guy coming in on Saturday night, you know? All that stuff, a lot of that pain has gone away by the new form factors.

    Ashley: Mm-hmm. Cool. How do folks get ahold of this, get access, try it out? Where do they go?

    Edwards: Yeah so, come to MenloSecurity.com, we have a Contact Us, you can try now. We have ways where you can kind of go down the self-service path to play around with it and see that, you know, try menlo.com. Or just feel free to shoot me an e-mail directly, you know, Nick.Edwards@menlosecurity, happy to help point you in the right direction and to cut through all the red tape. You know, we have customers who call up on a Monday with a security issue, we can be out and deployed within that week to get them the security they need, and we’re happy to help customers meet them where they are.

    Ashley: Excellent. Cool. Well, it was really fun talking to you, Nick. Thanks for joining me today and haring more about secure web gateway technology and services that you guys offer from Menlo Security.

    Edwards: Alright. Thanks a lot, Mitch. I appreciate you having me. I appreciate it. See ya.

    Ashley:  You bet. Look forward to talking with you again. Join me in thanking Nick Edwards for joining us today, VP of product management with Menlo Security.

    Edwards: Thanks.

  • Application Security and Continuous Observability with DeepFactor

    Application Security and Continuous Observability with DeepFactor

    Today’s modern applications are becoming increasingly complex and released more frequently than ever before, therefore increasing security, privacy and compliance risks. How do you identify the security and compliance risks hidden in your application before you deploy it to production?

    Continuous observability enables DevSecOps teams to observe millions of application telemetry events and find runtime security, compliance and privacy risks within the DevOps pipeline, while providing AppSec teams the ability to set guardrails and have continuous visibility with every build.

    In this TechStrong TV interview with DeepFactor Founder and CEO Kiran Kamity, we discuss the concept of observability and how to apply it for security and compliance. We also talk about the increasingly important role of AppSec and DeepFactor’s new Observability-as-Code API, which enables DevSecOps engineers to leverage observability functionality in their CI pipeline and gate builds.

    The video of the conversation is below, followed by the transcript. Enjoy!

    Transcript

    Mitch Ashley: I have the pleasure of being joined by Kiran Kamity, who is founder and CEO with DeepFactor. Welcome, Kiran.

    Kiran Kamity: Thank you, Mitch.

    Ashley: Great to have you. We’re gonna be talking about observability, super-hot topic, but before we get there, tell us a little bit about yourself, a little bit about your background, and then a little bit about DeepFactor.

    Kamity: Awesome, yeah. I came to the Bay Area about 20 years ago. I did my undergrad at the Indian Institute of Technology in India in Chennai, and then I came here to Stanford for my grad program. Once I came to the Bay Area, you get addicted to the entrepreneurial spirit, you never leave, this becomes your home. Happened to most people—happened to me as well.

    So, the Bay Area is my home, and I’ve had a mix of enterprise and infrastructure cloud computing, virtualization, and DevOps/AppSec kind of background over the last 20 years. I’ve done two companies as a Founder, which were acquired by other companies like Citrix and Cisco. My first company, RingCube Technologies, was acquired by Citrix. We built a container run time for the Windows Operating System before the Docker days. This was acquired by Citrix in 2011, so I was responsible for some of the product teams at Citrix after the acquisition.

    Then the bug bit me again, and I started ContainerX, which was a turnkey containers in a box type company, which was acquired by Cisco, and it’s now called Cisco Container Platform. While at Cisco, I was Head of Product for the Cisco Cloud Business Unit, which included container—container networking, OpenStack, and some of the other initiatives that they had.

    During that time, as I was looking at what to do next and analyzing the market, a lot of the learnings came to the following. There’s a lot of momentum that has happened so far in cloud native architectures, DevOps, et cetera. And the learnings were that the next wave of innovation is going to be as DevOps becomes DevSecOps. And that’s why I started DeepFactor, and we believe that the next wave of innovation in the world of DevSecOps is observability.

    Ashley: That’s something I both relate to and also am just fascinated by other entrepreneurs is that story of, you’re working on what you’re doing now and you’re still kinda looking at, “Well, what’s the next thing coming up, and what might I go do next?” and then you go off and solve the next problem.

    Kamity: Yeah, absolutely.

    Ashley: Start another company to do that—like you said, you get the bug, it’s kind of a fever. [Laughter] It definitely is.

    Well, cool. We’re talking about observability, and it does seem to be the hot topic of kinda late 2020, early 2021. So, let’s first start with kinda how did we get there—get here? How did we get to this place where suddenly observability is a thing and not only a thing, but important to a lot of people?

    Kamity: Yeah. Just to qualify it a little bit, our focus at DeepFactor is applying the concepts of observability for security and compliance, which is truly novel, and there’s very few companies that are trying to do that.

    Ashley: True. Observability can mean just sort of the next elevated monitoring, right?

    Kamity: Exactly.

    Ashley: So, you’re [Crosstalk] around security.

    Kamity: So far, a lot of the observability plays have been in the logs metrics tracing. Applying the concepts of observability, truly as the next generation of evolution of APM. But at DeepFactor, we’re leveraging the concepts of observability for identifying security and compliance risks in your applications before they go to production.

    So, to answer your question about how did we get here, let’s take a step back and analyze what has happened over the last few years, with respect to application development, right? Apps have become a lot more complex than they have ever been today. I mean, think about it—a common application is made of a bunch of different languages. You have a Java service, you have a Node.js service, and you have Angular in the front end, you have lots of different pieces, you have a database, et cetera.

    You have a lot of third parties—third party libraries that are baked into your services, third party components that are not built by you such as Nginx and MySQL and MongoDB, et cetera, that become part of your application.

    Ashley: A lot of open source, right, in that stack.

    Kamity: A lot of open source. Applications are now also being deployed in a bunch of different ways. You have applications that are not containerized, still mainstream. You have containerized applications, you have full on Kubernetes applications, and you have land applications as well, so the deployment of applications has become complex as well.

    So, in this world of applications becoming a lot more complex than they’ve been, what essentially happened from a security perspective is that the attack surface area of your application has significantly increased. It is the highest it’s ever been so are, and it’s only gonna go that way.

    Let’s take a look at a few other trends that have bene happening in industry. The velocity of releases—that has gone up as well due to DevOps. You’re no longer building or releasing an application once at three months, once at six months. You’re releasing that multiple times a week with DevOps, and different companies are different aspects of that spectrum, there.

    Now, when things are more complex and they’re being released at such a rapid pace, there is no way humanly possible for your AppSec teams to find all of the security risks and compliance risks that lie in your application before they deploy to production. At the same time, the risk of these issues being in production is higher than it’s ever been. If you think about it, the sophistication of the bad actors has increased significantly as well over the last few years, and therefore, the nature of the breaches, the size of the breaches, and the damage that they can cause has increased as well. Coupled with that, privacy concerns have increased, resulting in standards like GDPR and CCPA and all of those things emerging as well.

    Now, in such a landscape, you’ve got to automate identifying the security and compliance risks that are hidden in your application before you deploy your application to production. And that is where the current tools of just code scanning or identifying issues based on signatures or just DAST scanning your application, et cetera, don’t cut it. You need something that watches your application while the application is actually running in both pre-production environments as well as in a canary deployment of minimal production deployment before you release it to your broader production deployment.

    And in that environment, you’ve got to be able to watch the millions of events that are happening inside your application, take that data, analyze and find the needles in the haystack, and therefore determine where the security and compliance risks are and pass on all of this information with rich evidence such as stack traces, metrics, and whatever it takes to fix these issues back to the developers. And a lot of this has to happen in a seamless manner that is nicely tied into your DevOps kinda pipeline, and that’s where observability applied to security and compliance comes in, and that’s exactly what we call continuous observability at DeepFactor.

    Ashley: Interesting. I know, talking with you previously and kinda hearing about DeepFactor, you all talk about start left, not shift left—this idea that, really, it starts from the beginning, not, “Let’s kinda push it as far left as we can.”

    Kamity: Yeah, absolutely. If you think about it, we’ve had operator specific tools emerged in the last five years with respect to security. So, you’ve had container security tools that identify issues in your Kubernetes configuration or your Docker configuration or vulnerability scanners that identify issues in your host operating system if you’re deploying your app in a VM.

    Now, those are all the types of insights. Are there any misconfigurations that could lead to security issues that are very relevant for the Ops people? And those tools are coming up with the idea of shifting left, because you need to find these configuration issues before you go to production so that the Ops people can deploy these applications properly.

    But when it comes to developers, their agenda is not securely deploy your application. They don’t care, honestly, about how you’re Docker or Kubernetes is configured, for the most part. They care about what is in their application, securing at the source. And when the agenda for Dev teams is to secure at the source, then all you care about is—what is my application doing, whether it’s my application or some third party that I brought in, or just my interpreter itself when it is running? And can I identify the risks involved and understand my attack surface within the application ahead of time? And that’s why we call it start left.

    So, we think that operators care about shifting left. Developers should truly care about starting left.

    Ashley: Yeah, it’s interesting, because your point about code scanning and DAST approaches to security is, from a code standpoint, you do wanna be writing a secure code, so it’s a valid thing, of course, to be doing. But you mentioned Lambda, you mentioned, of course, infrastructure as code, essentially, where all this is dynamic, right, in our environments today, and more so, not less, every day, right?

    Kamity: Yes.

    Ashley: Every day, it gets to be more dynamic. Now, you’re really talking about the whole context of the environment with the application. Kind of, if you thought about it in the network, you’d say all seven layers, right? If you think about it in the security stack of software, it’s application plus all of the other things, right?

    Kamity: Yes.

    Ashley: It’s interesting what—how do you find people are accepting this idea of run time information being provided with context, you know, this rich information you were talking about, is that something new to developers or like, “Oh, my gosh, I’ve been waiting for this forever” or, “Well, this is really cool. Look at—let me see what I can do with it”? What’s more the experience that developers have?

    Kamity: Yeah, so, I think different organizations react differently to something like this. The old way of thinking is—oh, developers don’t care about security or compliance.

    Ashley: I’ve never met a develop that wants to write insecure code or unsecure code. [Laughter]

    Kamity: Exactly, right? That is exactly what’s happening now where, given the consequences of shipping insecure applications and given the need to be more and more secure at the source, I think developers—and just simply because it’s just not humanly possible for your AppSec teams to identify all these things. Given the talent shortage of the AppSec skill set as well, it is, the responsibility if identifying these risks has to be borne by the developers. Because at the end of the day, the developers are the ones that are writing the code and you’ve got to make sure that you’ve shipped secure code.

    Engineering leadership and AppSec teams in various organizations that we’ve been working with have been fully accepted. In fact, they’re fully aware. In fact, a lot of them want this kind of concept, it’s just the lack of tooling today. Because if you think about the current tools that are available, they’re doing the best they can with the existing set of tools.

    I mean, they’re scanning the code, they’re trying to scan the application from time to time—but those tools don’t lend themselves well, nicely into seamless integration into your CI pipeline, and therefore, giving developers the insight about, “Hey, here’s where we saw your application did this.” That can only happen with observability tools like what we’re building, because we watch every thread of every process of every service in your application when it is running in test and even canary deployment in your part of production before you deploy that thing widely to a larger section of production. And that is the kind of insight developers do care about.

    What we have gotten repeated feedback as we have been building this product with a few development partner type enterprises so far is that, the insights that we have needs to be enriched with richer evidence information so that developers can actually take that evidence information and directly go fix the problem. So, we’ve augmented our insights with stack traces wherever appropriate. You know, obviously, the good old things like CVE numbers and things like that, we have that.

    But what we focus more on is not just giving you a list of CVEs, but complementing the insights that your software composition tools give you by giving you run time usage information of that CVE. For example, we can tell you if a tool like Snyk will tell you there are 250 vulnerabilities in your application, DeepFactor will tell you, “Hey, there are 250 vulnerabilities according to what Snyk is telling you. Fifteen of those things have been used by your application at this time, when your application was executing here, ad here is the function, here is the call stack.”

    So, that will make it easy for a developer to go, “Okay, now I don’t have to get overwhelmed with fixing all of the 250 things or adding that to my backlog, I can actually prioritize which ones to fix first, because that’s what my application is actually doing.” It’s not about the whole thing that has been checked into your source code, it is what your application’s actually doing that will help you catch the more important things. It’ll help you also reduce the number of alerts that can inundate you.

    Now, with all of these changes, the rich evidence, reducing the number of alerts, and to the point, alerts based on what your app is actually doing, developers are finding it more and more meaningful, our insights. And as we grow the company, that’s gonna be our primary focus.

    Ashley: That’s always been the challenge with vulnerability scanners and code scanners is, yes, I get all of those results. What of those are real? Yes, they’re all theoretically possible. I may not be using it in a way that actually exposes me to that CVE, that vulnerability.

    But what you’re saying is, you’ve actually detected the use in the application or the software stack of something around that CVE that’s worth looking at. Hopefully, you’re cutting down on the number of things that are actually, they go look at. You can ignore the rest, if you will, or at least know that they’re much less likely to be an issue.

    Kamity: Yeah. We do not give you too many alerts. We give you the alerts that are relevant for your application because we watch the millions of events that are happening in your application in every part of your application, across various layers of the stack—like, system caller interface, library calls that your application has made, network behavior, web and API, all of that.

    And based on that data, we treat it as a data problem. So, we take that data and then we try to identify anomalies and detect that these are the risks that lie in your application from a security perspective, and this is how it maps into compliance. So, we will tell you that these are the security risks in your application and in our next module of the product, we’re gonna tell you that this can hurt your PCIDSS, and here’s the number, basically.

    Ashley: Mm-hmm. It definitely is gonna improve your relationship with the security and compliance team, right? If you’re solving these problems before it gets to them, they have to ask, “Well, did you do anything about this? Are we susceptible?”

    Kamity: Yeah.

    Ashley: Talk a little bit about—so, where in the tool chain and the workflow pipeline, where do you fit? Where does DeepFactor play?

    Kamity: Yeah. The best way to think of us is, if you take a step back, if you are thinking about your DevSecOps initiative in total, you want to plug in into a bunch of different points from a security perspective into your CI pipeline. Your developers write code. The next step should be you try to find risks in your code. That’s where the SaaS tools come in, they find the risks that are there in your code.

    Then you create your build artifacts—let’s say, your executables, your container images, and whatnot. Then you try to find risks that lie in your build artifacts. That includes your code, any third parties that you’ve compiled together and created your services. It’s still static, though. You’re not running them yet. Tools that allow you to identify risks in your build artifacts could be container scanning tools, like image scanning tools that scan your container images and find issues or software composition analysis tools like Snyk and Black Dock and tools like that. These tools find vulnerabilities that exist in your components after they’ve been built.

    Then you run your application, you’re testing your application. Either you’re testing it in a test environment or you’ve deployed and you’re testing it in a minimal configuration of your—like, a canary deployment in your production. During that time, you’ve flicked DeepFactor on. DeepFactor doesn’t require any changes to the code of your application; you’re simply running your application.

    And that’s where we’ve built a significant amount of IP. You know, my Co-founder, Mike Larkin, he’s the CTO, he’s the father of the OpenBSD hypervisor. And our senior engineering leadership members came from Qualys and FireEye, having been in the area for 20 plus years working on security products, each.

    So, we’ve created something that involves zero touch, pretty much. You don’t have to touch your application at all, you simply run a command called DFCTL, just like KubeCTL, we came up with DFCTL. So, you do DFCTL, run your app; or DCFTL, run your container; or you drop it into Kubernetes. We have a webhook admission controller that you simply drop into Kubernetes, and then any pod that you want to be monitored, you simply can specify a config file and that pod gets monitored automatically with DeepFactor.

    Now, the way DeepFactor inserts itself is completely behind the scenes. It’s language agnostic. You don’t have to worry about, is it Java, is it Node.js—DeepFactor figures out that it’s Java or Node.js and does some specific things and finds out more information.

    So, you simply run this, your application is running in your test environment or your minimal production environment, DeepFactor observes everything that it’s doing. When the tests are done, it tells you—you throw your automated tests at it while your application is running, just like normal. And then when it’s done, DeepFactor gives you all of that information about what insights have been found and what’s the evidence information that’s pointing to the insight. Is the issue or the risk presenting the attack factor lying in the code that you wrote? Is it lying in a third party that you brought in, or is it at the interpreter level itself? All of them are risks as far as the attacker is concerned that could be exploited, so you need to be aware of where your risks are.

    Ashley: Now, are developers putting in some library calls or DeepFactor code into their application stack as well, then? Is that how you’re getting into the software, knowing what’s happening inside as well as outside?

    Kamity: Actually, that’s the beauty of our IP, and we’ve filed a few patents in that area. Developers do not need to write any code to change, or change anything in their application. You simply enter DFCTL and run your app and DeepFactor inserts itself into the application at your run time, completely seamless to the developer, and when it’s done, it unplugs itself and your application and gives you all the insights.

    Ashley: Wow. That sounds pretty cool. I can imagine that’s a big plus for developers. [Laughter] Yet something ls they don’t have to debug, right?

    Kamity: Exactly, yeah. That’s the significant part of our IP.

    Ashley: You know, it’s interesting you mentioned your team comes from a number of other security companies that have been around for a while—you know, you mentioned Qualys and others starting in the scanning, the vulnerability management space some time ago; that’s about when I got into security, too.

    What do you think we’ve learned from those types of companies and those experiences that we’ve sort of changed our perspective about where we are today, just given—yes, we have much more complexity in software, much more porous security issues, but what have we learned from all of that security scanning that’s helping us?

    Kamity: Yeah, no, I think there have been numerous, numerous learnings, and the learnings have evolved over time as the landscape of application development has changed as well. You know, you’ve had tools in the past that were designed based on the applications of the past. But tools of today and tools of tomorrow are different, because the applications of today or the applications of tomorrow are definitely trending in a different direction.

    One example of the thought process itself is that, you know, when things are in single digits or a lesser number, it’s okay to have manual scanning, manual testing, once in a while test it and then find information, which is kinda the old kind of scan once in a while, identify it, or bring in a pen tester once in three months, you know, check some boxes and get it done kind of thing.

    Those are all great and they’re still relevant even now. What has become even more important is why you do those once in a while scans and checks. You’ve got to make sure that you get in the habit of securing at the source. You can no longer imagine that your infrastructure or the perimeter is gonna secure your application properly. You’ve got to make sure that you build your application securely to start. And that fundamentally has changed the kind of tools that we need to build in order to equip the developers who build applications to secure at the source.

    At the same time, I think the role of AppSec has become even more important than it has ever been. Because, you know, sometimes I keep getting asked, “Oh, are you saying that developers should use these security tools? That means the AppSec teams are no longer relevant?” That is totally wrong, because AppSec teams, their job is increasingly more relevant. Because if you take a step back and you look at the number of attack vectors that are there in your application, we just talked about how your pipeline should be architected—secure at the source, making sure that you scan your code, scan your builds, test your running applications, and identify risks in all of these areas—who ties them together? Who comes up with this overall strategy? Who comes up with that triaging process and passing the evidence back to the developers, identifying which ones are important and which ones are not?

    All of that should come from the AppSec person in the team—AppSec or if AppSec is assimilated into your DevOps and we call it the DevSecOps person, that’s the role of this person is to make sure that he or she is the shepherd of your CI pipeline from a continuous security perspective and then feeds all of that information back to the relevant parties. Some of that could be your developers, some of that could be to your engineering leadership, and some of that could be to your security leadership.

    Ashley: Mm-hmm.

    Kamity: That is how I see the organizations of tomorrow shaping up, learning from what has happened over the last 15 years to 20 years of innovation in this area.

    Ashley: I think that makes a lot of sense. Otherwise, (a) we’re just throwing tools at it, everybody’s doing whatever and who knows whether that’s helping us improve and improve security. And you mentioned the data coming out of it, right? That can also be used for continuous improvement, continuous learning, what are trends that are happening in our application?

    Suddenly we’re seeing much more of this technique or this architecture or this environment being deployed that, you know, not always do the security people have exposure to that early on in the process. So, it’s a good way just to know what the heck is goin’ on and then also, you have an idea about how all of your security tools, developer or non-developer, fit into an architecture that makes sense.

    Kamity: Yeah, exactly. I mean, imagine flipping a switch and identifying, “okay, these are all the touch points that my application has and these are the millions of things that it’s doing” and condensed very well to, “these are the red dots in that whole story, and this is where your risks lie.” That’s powerful, and I think it’s the AppSec person’s job to set all of that up and make sure that a framework is created and then say, any time something that comes up, you know, make sur that you pass it on to the developer with the appropriate evidence and work with the engineering team to decide.

    Because when you have so many different services and so many different languages, the AppSec people, especially because they’re already short staffed, cannot possibly know everything about the business logic of the application, resulting in those decisions that could have been made to bring in component X and component Y and whatnot.

    Ashley: Mm-hmm. You know, Kiran, one of the things that I’ve said over time is that security people need to get a greater understanding of software architecture. They don’t need to have to be developers, right, that’s not what their skill set is, nor necessary their desire. But you can’t treat security as this hard outer shell, you know, we just keep making it smaller and smaller. And now all you’ve got is thousands or hundreds of thousands of small outer shells and now you’re not securing anything, any more.

    It seems like the AppSec team can play a really important part of helping bridge that gap of what are we doing specifically, what are the architectures that we’re using, what might be some of the security risks that maybe a security engineer is just not fully up to speed on or trying to keep up to speed on as it’s changing?

    Kamity: Yeah, absolutely. Imagine the power of flipping the observability switch and the AppSec person going and saying, “Hey, Dev team, we noticed that in this particular piece of your code, you’re using an API that has been deprecated by the operating system” or, “In this particular piece of code, you’re invoking memory improperly, because this tool is showing me exactly what was done when this particular area of memory was allocated with the wrong permissions. Or, “This is an area of code where your interpreter is doing something wrong. Is it possible for us to go change the version of the interpreter that we’re using, maybe upgrade it to the latest version or put a patch?” Or, “Do we need to, in order to mitigate this thing, assuming that there’s no fix in the interpreter, do we need to go put something in our WA in our infrastructure to block the particular attack from happening?” Or, “Should we report this problem upstream to Java itself, the Java community itself, so they can go fix the problem in there?”

    So, lots of different things that could be done once the AppSec team is empowered with this much rich information about what’s happening in the application.

    Ashley: You know, something I don’t know that we talked enough about, we talked about how rapidly and how quickly we’re delivering software applications now. The environment of the software, the API calls we’re using, the libraries, the services, interpreters—all of that is changing in parallel very quickly. Sometimes you don’t feel like you have time to keep up with it, or that’s all you do is spend your time keeping up with that, not kinda delivering business value.

    I think folks that are maybe not involved too deeply in the software creation process really realize not only the complexity but how much change there is to deal with. There’s a lot that goes into that. We talk about technical debt or backlog or whatever—it’s a lot more than that, there’s much more to it. [Laughter]

    Kamity: Absolutely, there’s a lot more than that, and I think having an informed security team as well as, you know, coupled with a structure and the right tools baked into your pipeline, which results in informed Dev team, can result in goodness overall. You’ll end up identifying security and compliance risks earlier in your Dev cycle. You’ll end up fixing those things earlier, and therefore, you will end up shipping a much more secure application, and it’s a cycle. Every time more developers check in code, you know, this kind of identification happens automatically, and you end up identifying more and more risks and fixing more and more things, resulting in more and more secure applications into prod.

    Ashley: Mm-hmm. Awesome. Well, what are some things folks might have access to you can help them get started? Obviously, they can download HIV testing product or get involved that way. Do you have some other tools or things that they might be able to use to make it approachable to get into this kind of an approach?

    Kamity: Yeah, they can go to DeepFactor.io to check out the product, understand more about the product. And if they want to get started, they can either download the community edition that is now free for 10 user teams or less. If you need any help with setting up the product, you can reach out to our Customer Success person.

    We’re also giving away a free DevSecOps Risk Assessment to companies that are working with us as we expand our organization more. This will help any engineering team or any security team to get a free assessment of what DeepFactor can find in their applications so that they will be able to identify, “Okay, these are the kinds of things DeepFactor finds, and it’s useful for me and here’s where I need to go next” kind of thing.

    So, that DevSecOps Risk Assessment is completely free. Contact us, hello@deepfactor.io or just go to the website to learn more.

    Ashley: Awesome, great. I know you’re also speaking at the Cybersecurity 2021, I think you have a couple of sessions there, right? The dates are March 4th and 5th for that event.

    Kamity: Yeah. We have a couple of speaking sessions at Cybersecurity ’21. We have a virtual booth there as well, so do check us out. There is a—you know, our team can answer any questions or even try to explain to you or help you understand what DeepFactor can do and identify in your application.

    Also, today, we’re launching Observability-as-Code. It’s a new module that we’ve created, and a product that allows people to bake in observability into their CI pipeline, similar to how Infrastructure-as-Code enables DevOps and DevSecOps folks to spin up, spin down infrastructure in their CI pipeline itself and other related scripts. You can do, now, the same thing with observability for security and compliance with DeepFactor. So, you can use our API, we have a Swagger doc ready, you can use our API to invoke DeepFactor as part of your CI pipeline, get the results, triage the results, use that results to block, if there’s any P1s you want to block the _____, you can do that. You can do things like that with the Observability-as-Code API that we just announced.

    Ashley: Excellent. Well, I hope folks will check you out. I think it’s a great path to be going down, and I’m sure developers appreciate writing more secure code, but completing an application that’s more secure that they’re involved in developing.

    So, Kiran Kamity, great to have you here, CEO and founder, co-founder—I guess founder [Laughter] of DeepFactor.io. And be sure and check out the speakers that you all have at Cybersecurity 2021. It’s a great conference and we look forward to hearing more from you, there. Thanks for joining me today. Great to talk with you.

    Kamity: Thank you much. Appreciate the opportunity.

    Ashley: You bet.

    Kamity: Bye.