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.
