Innovation And Execution For Better Solutions With Erkang Zheng

[00:01:23] Guy Podjarny: Hello everybody. Welcome back to the show. We have another DevSecCon edition of the Secure Developer Podcast, and we have another great speaker with us, Erkang Zheng from LifeOmic. Welcome to the show, Erkang. 

[00:01:33] Erkang Zheng: Yeah, thank you. Great to be here. 

[00:01:36] Guy Podjarny: Erkang, before we kind of go and dig in to the talk and various other topics, tell us a little bit about yourself. What is it that you do? 

[00:01:42] Erkang Zheng: Sure. I am the CISO at LifeOmic. LifeOmic is a software company and we build a cloud-based platform for healthcare data, for patient data, genomic data and so on, we work with institutional partners, research organizations to build machine learning algorithms for things like cancer research and things like that.  

At the same time, the platform also supports a set of mobile apps that we’ve built for direct to consumer, direct to patient interactions and track wellness behaviors and so on. That enriches the platform for patients' usage as well. 

[00:02:23] Guy Podjarny: Got it. Okay. 

[00:02:24] Erkang Zheng: That’s what I do at LifeOmic, run the sec ops, security operations team over there. But in addition to that, I also build a product, a security product. Maybe later on, I can get to talk a little bit about that as well. It’s a security product called JupiterOne, focused around kind of cloud visibility and compliance.  

[00:02:42] Guy Podjarny: Excellent. Yeah. Definitely, you need to dig into that one as we run. Just as a picture. So you said you run sec ops. Before you can go to the talk, what does the overall sort of security team look like? 

[00:02:52] Erkang Zheng: The security team is really light and it is purposely so. We are still a startup. So overall we’re a little over 70 people and primarily all engineers and security team is only three people. That’s part of the whole concept of DevSecOps, is we want to have a lean security operation, so that we can leverage automation, we can leverage the broader engineering team so that everybody can participate in security. It’s not just a one person job or one team’s job and we don’t become the blocker of things. 

[00:03:30] Guy Podjarny: That’s the philosophy behind the security team, as well. 

[00:03:32] Erkang Zheng: Exactly. 

[00:03:33] Guy Podjarny: I guess that’s probably a pretty good segue to your talk. What is your talk about? 

[00:03:38] Erkang Zheng: Yeah. So my talk is about how we do DevSecOps, right? I think DevSecOps means different things to different people, and I actually look at DevSecOps very similar to DevOps with some of the security focus to it. My talk is about our culture and our implementation of how we implement and enable DevSecOps.  

Essentially, it is how do we allow our teams to move fast with security building and with assurance and confidence at the end of it? That’s through automation, through a lot of kind of culture aspect of things in addition to just tools and processes. 

[00:04:19] Guy Podjarny: Give us some highlights. We’re going to point people to the YouTube videos. So they’re going to see the full talk later on. Give us some of the key examples. 

[00:04:27] Erkang Zheng: Sure. The highlights, I mentioned two aspects. One is the organization and culture aspect of it. That particular one, we actually started a security manifesto. I think most people are very familiar with the agile manifesto. That’s what really sparked DevOps.  

We’ve done something quite similar, and that is our security manifesto. We have actually posted that on securitymanifesto.net. There are six things in there that speak to the way it works for modern cyber security in a DevOps and kind of cloud native type of way. That’s definitely one of the highlights. But without going into details you can actually check out the video or the talk to see the details.  

The second aspect would be sort of the enabling aspect, or how do you it? Once you have the culture and you have the manifesto, you have everybody on board with how are you going to do it. Now, what is the actual implementation to make that work is the second part of my talk. That has to do with a lot of automation and the tools that we’ve built, which later on became JupiterOne.  

Now, within that second part, now there are further two things. The way I look at DevSecOps, it really is, one, security as an enabler for DevOps. Now, this is what a lot of people were talking about throughout the conference. Shift left and build security in and stuff like that using automations, work with developers and as part of the CICD pipeline. That’s one aspect. Actually, a colleague of mine is giving a talk on the second day with very specific details on that. The security automations in the CICD pipeline. 

[00:06:16] Guy Podjarny: Yeah, which is the core. Is that sort of second component after you’ve agreed on your principles, automate it into the system. 

[00:06:24] Erkang Zheng: Exactly. To give you a little bit of background. As small as a team that we have, engineering-wise compared to the large organizations out there, we actually do anywhere between 20 to 50 production deploys every day, continuously. Not only do we do that but we have to ensure that with every production deploy and all the boxes are checked in this highly-regulated HIPAA compliant environment.  

That talk goes into details on what we did in automating those checks and balances. Without using people, without saying you have different teams, separation of duties and all implemented by people, how do we leverage code and tools and automation to implement it? So it has the same effect, or maybe even better effect because you make less mistakes by running a kind of pre-checked set of code.  

[00:07:17] Guy Podjarny: Right. 

[00:07:18] Erkang Zheng: That’s one. Then the second part, I mentioned that was development as an enabler or actually I should say security as an enabler for DevOps. The second part of the implementation details are going to be around how do we use development as an enabler for SecOps? That’s the second part of how I look at DevSecOps that a lot of people don’t talk about.  

Now, that has to do with the day-to-day work of the security team. Not the day-to-day work of developers, but the day-to-day work of the security team and the compliance people. Now, how do we use development to help make their jobs better and easier?  

To kind of give you a little preview of that, we actually have methods and we developed a platform to aggregate data from different sources and build a graph, a sort of visual graph around it to focus on the relationships of the things that we have.  

So these entities, and how they are connected within this massive digital environment that an organization may have. For us, again, we’re a startup. So we have a couple hundred thousands of entities and over a million relationships, just across our digital mutual environment.  

[00:08:37] Guy Podjarny: Yeah, they grow quickly. 

[00:08:39] Erkang Zheng: Exactly, and they get complex and it gets out of hand and you kind of lose control overtime. That’s the second part of our talk, is how do you solve that challenge. 

[00:08:47] Guy Podjarny: Yeah, I love that, because it’s indeed not often discussed. I think I’ve got sort of a couple of offshoots, from the topics that you mentioned. One is you mentioned about sort of security automation as something that allows you to stay compliant and build that security in without hiring a hoard of security people, which you probably can’t hire anyway because there’s a talent shortage. That’s a different problem in its own right. You have those.  

You live in a very kind of regulated surrounding, or at least you deal with patients with very private data. How do you balance or how much freedom do you give developers to go off the reservation, to sort of be able to choose to do the things a little bit differently? You’ve chosen a framework, you’ve chosen some tools. Is the developer allowed to disobey?  

[00:09:32] Erkang Zheng: That is a great question. We actually give developers tremendous amount of freedom to do the things that they want. To give you a couple of examples, right? We don’t restrict on the development frameworks or modules or libraries that developers can use. We don’t take away their controls on their local workstations. In our case, every developer is a local admin of their own workstation and they have the freedom to do whatever they want with it and they have the freedom to write whatever code and bring whatever component necessary. 

It sounds against security best practices, right? I think if you haven't, you’re probably going to ask, "How does that work from the compliance angle?" We’re putting a lot of kind of checks and balances when things actually get to production. For example, of course, there's a lot of code analysis that goes into it, and we have automated change management process using bots, using detections and kind of enforcing reviews of poll requests and sort of democratizing security to all developers, so that they help enforce and police their own work. Well, actually, their peers work but not just their own, right?   

For example, we have checks in place, automation checks, to ensure if your code hasn't been approved by another peer, of yours, and hasn’t been reviewed, that is one criteria for can you or can you not go to production with that code, right? Among other things like scans for vulnerabilities using where to use Snyk for our open source license package dependencies and license checks, right? A lot of those are covered with these automations and these tools.  

Even within production, I will say, the production environment is entirely kind of virtually air gapped using software in a way that there is no network connectivity into it. There's no VPN. There is no SSH. We are 100% server list, right? That has a tremendous amount of kind of guard rails around our production environment. Within production, those serverless functions we run from a tool called PeerSec, right? So we run integrated rasp type of protection in the functions themselves.  

[00:11:56] Guy Podjarny: Got it.  

[00:11:56] Erkang Zheng: By the nature of that, that allowed us to give developers a lot of freedom on their day-to-day work.  

[00:12:02] Guy Podjarny: Yup. Okay. That makes a lot of sense, and I think it’s kind of the brave new world and maybe your talk is titled 'Getting Away from the Old Ways and in Favor of DevSecOps'. What do you think when you think about an organization unlike LifeOmic who I sort of assume as more born into this philosophy? 

[00:12:18] Erkang Zheng: That’s right.  

[00:12:18] Guy Podjarny: When you see an organization that wasn't, that has existing security practices, what are some of the key ways to move into this reality that you're describing here? 

[00:12:27] Erkang Zheng: Yeah. I think anytime that you want to switch from legacy is hard and especially changing the processes. I think, first and foremost, you just have to embrace being uncomfortable. At the beginning of this change, you will be uncomfortable, right? You will feel like you're losing control. But as with anything, I think the key is to focus on what truly is important. Right? So going back to sort of the developer’s freedom type of discussion is to say, at the end of the day, as a business, you want the business to grow, to move fast. That’s why we have DevOps, right?  

Now, with that in mind, now, how do you enable that? How do you embrace that, right? Are you trying to make yourself feel better with the illusion of control, given that the manual processes and the old way of doing things that are in place? Or can you rethink and say, “Well, maybe I should give developers a better experience. Maybe that will help enable the business to go faster.” 

Then on the flip side, on the security side, maybe I should just – instead of saying I want to take control of everything, maybe I should just focus on what really matters. What really matters to us is the production environment. Is the data there? Is the workload in those environments? Can we just focus on what really matters and then let go? This is an experience of experimenting and letting go of things, right? I think that's part of the first step you have to take in making that organizational transition.  

[00:14:00] Guy Podjarny: Yeah. It makes a lot of sense. It’s a tough transition. It's sort of accepting imperfection, especially in the world of security is hard. If you try to chase everything that follows, it just doesn't scale. It's a core principle of scaling.  

[00:14:11] Erkang Zheng: Yeah, and you don't have to do everything. You don’t have to change your entire organization to be that way at the beginning, right? Just experiment.  

[00:14:18] Guy Podjarny: Yeah. Well, just as probably a small element but it is akin to the change to agile.  

[00:14:23] Erkang Zheng: Yup. That’s right.  

[00:14:23] Guy Podjarny: When organizations switch from waterfall to more of an agile methodology, that's not an easy process, but it is necessary. I don't think anybody regrets having made it, although many have scars from the process nonetheless.  

[00:14:36] Erkang Zheng: That’s right.  

[00:14:37] Guy Podjarny: Tell us a little bit about JupiterOne. You built this capability in house for your own needs and now it's turned into a product. Give us a little bit of the history here.  

[00:14:45] Erkang Zheng: Yeah. The idea there is to leverage code and automation to answer questions for security and compliance, because the way I look at it, and especially with a small team with a fast-moving team and I first and foremost do not want to run security and compliance as two separate functions. They have to be one in order to be efficient.  

The question I asked myself was now how do I make compliance as just an outcome of running security and doing things right rather than running compliance as its own initiative, which is what most companies do? That was the question. As I looked deeper into it, I realized that the auditors and the assessors for whatever compliance frameworks, what they do, essentially, they are asking questions to you at the time of auditing. Those are the questions that you should be asking yourself on a daily basis. For example, “Hey, what are the workloads that are relevant to this production application? Are the data stores around these encrypted?”  

These are the compliance questions the auditors are asking, but these are also the security questions the teams themselves should be asking on a daily basis. That led us to building this platform to solve actually one combined question, right? Not a separate problem, but a one combined challenge, which is can we operate security and compliance in this sort of question-answer format? Can we have enough data that can provide meaningful answers and have a way that we can just ask query questions?  

That’s what JupiterOne is about. JupiterOne, we build via API. This is actually only possible with cloud and APIs. So we can collect this data from different sources and we build queries and we build a graph to connect the dots, connect the resources. With the query language that we developed, we can then ask these questions. These questions can be set up in an automated way. Once you figured out what the answers are that you’re looking for, what are the questions that you want to ask, then you can say to yourself to be repeated because there are queries, there are code. You can have them run on a daily basis, on an hourly basis or however often that needs to happen.  

[00:17:06] Guy Podjarny: Yeah. It sounds excellent. Also, I always like when DevOps analogies kind of work out. Once again, you talked about how developers can kind of help the SecOps side of the fence. To me, like there’s a sentence from DevOps talks about if it moves measure it, and if it doesn’t move measure it, in case it moves. Basically, it’s along those lines. That allowed for risky deployments because you could trust, or least you’re working on it, that if something went wrong in production, you will find out.   

[00:17:34] Erkang Zheng: Exactly. 

[00:17:35] Guy Podjarny: That you’d be able to get to the bottom of why. To do that, you had to instrument everything and you had to do those. This sounds from an asset inventory, from a compliance perspective, it sounds of a similar philosophy, if I understand it correctly.  

[00:17:48] Erkang Zheng: Yeah. You mentioned asset inventory. If I can touch on that real quick, because asset inventory sounds like such a basic thing, but it actually is a very challenging and tremendous amount of work to get it done right. A lot of people think about asset inventory as IT assets, but that’s far from it, right? If you think about everything is digital of software-defined, all of those are assets. That is actually a very untapped challenge in the whole security industry, is that particular thing – 

[00:18:18] Guy Podjarny: Yeah. Just knowing what you have. It’s about security hygiene at scale, right?  

[00:18:20] Erkang Zheng: That’s right. Yeah. 

[00:18:21] Guy Podjarny: That’s the hard part. 

[00:18:21] Erkang Zheng: Yeah. You can’t protect what you can’t see. 

[00:18:23] Guy Podjarny: Exactly. If somebody wants to learn more JupiterOne, do they just go to that website?  

[00:18:27] Erkang Zheng: Yeah, jupiterone.com. 

[00:18:29] Guy Podjarny: Jupiterone.com. Excellent. I definitely encourage people to go check it out. Erkang, this has been a pleasure. Thanks for coming on the show. 

[00:18:35] Erkang Zheng: Yeah, sounds good. It’s been a pleasure.   

[00:18:37] Guy Podjarny: Thanks everybody for listening in and I hope you join us for the next DevSecCon edition of The Secure Developer podcast. Thank you.