 Okay, welcome everyone to Cube Conversation here in Palo Alto, California, the Cube Studios. I'm John Furrier, the co-host of the Cube and co-founder of SiliconANGLE Media. Next guest is Mike Kyle, who's the CTO of Cybrick, a security company, industry veteran. Welcome, good to see you. I'm glad we got you, get some time, your time today. No, absolutely, John, thanks for having me. Yeah, so you've been through, you've seen a lot of growth in the waves. You know, the big web scale, and now as we go full cloud and hybrid cloud, private cloud and public cloud, whole new paradigm shift on security. Many have Dave Vellante's, has Pat Gelsinger many times. Do we need security to do over? And the general consensus from everyone is, yes, we need to do over. What's the state of the market with security right now? As people scratch their head, they've been thrown in the kitchen sink at everything. But yet, the attacks are still up. So that's not good. So what's the solution? What's going on? I mean, I think the level set, like we talked about the definition of insanity is doing the same thing over and over. And in security, for sure, we've been doing the same thing. We have firewalls, next gen firewalls, endpoint, you know, product X, product Y. This has got a better algorithm. Has anything really helped? I think in this post-equifax world and now post-SEC world, things are not getting better. So I think we need to step back. And I think we need to really think about how do we bring security assurance into the assembly and delivery of applications and move it back into the code as well, which is our thesis on shifting left and embedding security into the SLC. And I think there needs to be some design thinking around security as well. I mean, today it's like this fear and certainty and doubt and it's sold on fear and that bad things are happening and let's bring the conversation into visibility. I mean, it's something different in life cycle you just mentioned. It's really key. And I think I want to just chill down on that because the observation I'll get your reaction to this is security shouldn't be a cost center. Security should be tied to core objectives of a company, should be reporting to the board, C-level type access, should be invested in. At the same time, the architecture of security, not just organizationally funded, the cloud and data center needs to be looked at. Holistically, there's no one product. So that means, okay, Juan, that's the customer viewpoint, but then you got to actually put the software out there. So what's your reaction to that trend of security being not actually a part of the IT department, whether it is or not irrelevant, it's more of how it's viewed. Are you staffing properly? How are you staffing? Is it a cost center or is it tied to an objective that doesn't have free reign to set up policies, standards, et cetera? What's your thoughts on this? I think, and I've talked about this recently, like the technology is there, the culture is lagging behind. So security's always been- Culture is lagging or not? Is lagging. So the security's traditionally been kind of this, like IT was in the past, pre-DevOps culture, security is the department of no. And coming in and not thinking about driving business revenue and outcome, but like pointing fingers and accusing people and yelling at people, and it creates this contentious environment, and there needs to be collaboration around, like how do we drive the business forward with more security assurance, not insurance? Like the latter is not helping. So that's a good point. I want to drill down on DevOps, you mentioned DevOps, I think you and I have talked about this before, events. DevOps movement has happened, it's happening and continuing to happen at scale. DevOps is pretty much on the agenda, make it happen. But it's hard to get DevOps going when there's so much push on application development, right? So you have old school, transitional application development now with DevOps, and then you got pressure for security. It seems to be a lot on the plate of executives and staffs to balance all that. So how do you roll up the best security into a DevOps culture, in your opinion? I think you have to start embedding security into the DevOps culture and the software development lifecycle and create this collaborative culture of DevSecOps. What is DevSecOps? So it's making, as you think about the core tenants of DevOps being collaboration, automation, measurement sharing, security needs to take that same approach. So instead of adding or bolting on security at the end of your development and delivery cycle, let's bring it in and find defects early on from what we talk about from code commit to build to delivery and correlate across all of those instead of these disparate tasks and manual tasks that are done today. Where are we on this? First of all, I agree with that, I love that idea because you're bringing agility concepts to security. How far, what's the progress on this relative to the industry adoption? What's, is it kind of like pioneering right now for stage, is it a small group of people? Remember, go back to 2008, you remember, the cloud was a cloud of rarity, it was a handful of people. I would go to San Francisco, there'd be six of us. And then engineer, come on, then there's Haruku, then there's like Rackspace, and then Amazon was still kind of rising up. It feels like DevOps, DevSecOps is beyond that. I mean, where is the progress? I think out in the real world, especially outside of Silicon Valley, it's still really early days. People are trying to understand, but as we were chatting about before the show, I feel like in the past few months, there's definitely momentum gaining rapidly. I think with conferences like DevSecOps, Security Boulevard coming out from Alan Schimel and his team, like there's building more and more awareness, and we've been trying to drive it as well. So I think it's like the early days of cloud. You'll see that, okay, there's a bunch of, okay, I don't think this is a real thing. And now people are like, okay, I need to do it. I don't want to be the next Equifax or large breach. And so how do I bring security in without being heavy-handed? It's just to mention Equifax. I mean, our reporting soon to be showing will demonstrate that a lot what's been reported is actually not what really happened, that they've been sucked dry 10 times over and that the state actors were involved as a franchise and all this. I mean, it's beyond amazing like how complicated these hacks are. So how does a company prepare against the coordination at that level? I mean, it's massive. I mean, some of them, you know, they drop the ball on the VPN side. But I mean, clearly they were outmaneuvered. Outfoxed a few. I mean, I think it has to come from the top. Like security has to stop being quote unquote important and become a priority. Not the number one priority, but you have to think about it with respect to business risk. And Equifax aside, a lot of companies just have poor hygiene. They don't practice good security hygiene across all of the attack vectors. And if you look at now, the rise of the developer, Docker containers, moving to cloud, mobile, there's all of these ways in and the hackers only have to be right once. We on the defensive side have to be right. I mean, hygiene is a great term, but it's also maybe even more than that. It's like they just need an IQ as well. So you got to have, you got this, the growth in Kubernetes, you got containers, you got a lot going on at layer four and above in the stack that are opportunities. As you said, the techs out there. So again, back to the organizational mindset, because this is where DevOps really kind of kicked ass. You had an organizational mindset, then you had showcases. People built their own stuff. You go back to the early pioneers, you were involved in a few of them, then Facebook built their own stuff, because they had to. Yeah, there was nothing else. There was nothing else, so they had to build it. And a lot of the successes in the web scale days were examples of that. So is that a similar paradigm? Are people building their own? Are you guys working with one? Is that right? How should people think about how to look for use cases? How should they look for successes? Who's doing anything? Who's, can you point to any examples of that's kick ass DevSecond? I mean, obviously I'm biased, but I think the Cybrick platform is really trying to take all the different disparate tools and hyperconverge them onto an automation orchestration platform. So now you can be at all parts of the SDLC and give the CIO and CISO visibility. I think the visibility aspect with the move to cloud and containers and Kubernetes and you name your favorite technology, there's a lack of visibility. And you can't secure what you don't know about. Take a minute to talk about Cybrick for a minute. Cause you brought the product I want to just delve down on that. What do you guys do? What's the product? Just give a quick one minute, two minutes update for the folks on what you guys do. Sure. So we're a cloud security as a service platform. So it's Delivered SAS that has a policy driven framework to automate code and application security testing and scanning from code commit to build assembly to application delivery and correlate that testing and the results and it provide you your business resiliency. So we talk about internal rate of detection internal rate of remediation. And if you can narrow that window you become much more resilient. All right, so let me give you an example just throw it aside since we're here. We'll test your security mojo here. I go to China. I happen to bring my phone and my Mac. I connect to the, oh, free Wi-Fi. Boom, I get a certificate. My phone updates from Apple. I think I'm on a free Wi-Fi network. It's a certificate from China. I get the certificate here. They read all my mail while I'm over there. But I'm not done. I come home. How, and I go back to the enterprise. How do you guys help me, the company identify that I'm now infected at maybe the firmware level or, you know, I mean, that's what people are talking about all the time right now. You're smiling. He's like, yeah, that happens. First of all, I would never let you leave to go to a country like that without a burner phone and a burner laptop and not take, and don't log into anything. Don't connect to anything. And so I, But it's about building awareness. Hold on, and also advice. That's essentially best practice in your opinion, not to have your laptop in China, is that the thing? Yeah, I don't think, you're not going to be safe. Like there's so many ways to subvert you, whether you accidentally connect to public Wi-Fi, you joined the wrong network, somebody steals your laptop. I mean, there's just all the, there's a lot of things that, bad things that can happen, and not much upside for you. Okay, so now back to the enterprise. So I get back in, what's kind of security? How do you guys look at that? So if you're doing agile or DevSecOps, what is their software that does that? Is it the methodology? Is there mechanisms? How do companies think through some basic things like that entry point? Because then that becomes an insider threat from a back door. Right, so I think you have to have this continuous scanning approach. The days of doing a pen test on your application once a quarter, meanwhile hackers are doing it continuously behind the scenes, you have to close that chasm. But I think we need to start early on and build awareness to developers. So one reporter used the analogy of it's like spell check for Microsoft Word. So as now as I'm committing code, I can run a scan and say, okay, you have this vulnerability, here's how to go remediate it and you do that and we don't impact velocity. Okay, so you guys have to be on top of a lot of things. But that also is into the team's approach. What is the product that you guys have? Software, is it a box? How do you guys, what's the business model for Cyber? We're software that overlays into the SDLC and we plug in at the key points of the SDLC. So committing it to your code repo such as GitHub or BinBucket at the artifact build stage. So Jenkins, Travis, Circle. So you're down at the binary level? Yeah. So there we look for open source and third party library and do source code composition of the artifact. So now you make sure that you're not vulnerable to it's patchy struts. You have updated and patched to the latest version. And then pre-delivery, we replicate your application environment and aggressively scan for the OOS top 10. So SQL injection, cross site scripting, and alert you and allow you to play offense. So we now remediate the vulnerability before it's ever exposed to reduction. Where are you guys winning? Give some examples of when someone needs to get you guys in. Is it a full on transformational thing? Can I come in and engage with Cyberg immediately and little kind of POCs? What's the normal use case that you guys are engaging with companies on? It really depends where you are in your company with this whole dev ops, dev sec ops migration, but we're agnostic to the methodology and your environment. So we can start at the far right and just do abstract scanning. We can start at the middle of the build at the left code or all of that. But you don't, there's this notion of I have to be ready for security. You don't have to be ready. The hardest part is getting started and we help you get started. You'll see a blog post or an article from us saying, stop the fud, just get started. That's how you have to approach this. This paralysis that exists has to ask it. Well, let's talk about the paralysis. Like pretend I'm a customer for a second. Mike, I'm burnt out. I got a gun to my head every day. I come in, I got every single security vendor lining up begging for my attention. Why should I pay attention to you? What's in it for me? How do you answer that? So first of all, what do you want to achieve? Like what is your current state? Like where are your code repos? Where are your application deployments? What are you doing today? And how do we make that a continuous process? So it's understanding the environment, having some situational awareness and a bit of EQ instead of going in and pounding on them with a product. So do you guys then go in and train my staff? I'm trying to think, what's the commitment for me? What do I need to do? Our policies are very simple. You define a target, which is your source repo, your build system or your application. You define the tool or integration you want to run. So I want to run Metasploit against my application. I want to do it every hour. And I want to be notified via a Slack channel notification. It sounds really easy to implement. It sounds easy. It's four steps. So it's literally like a POC takes 15 minutes to onboard. So what's the outcome? What's some of the successes you've had on the after POC? So it sounds complicated, but really the methodology really is more of a mindset for the organization. So I love the DevOps angle on that. But okay, I can get in, I kick the tires, I do the four steps, I go, oh, this is awesome. What happens next? What normally goes on? So what often happens in the past is you run a test and you're inundated with results. It's, you know, there's critical warnings, some informational and some like blood red ones. But you don't know where to start on, like prioritizing them. We've normalized the output of all these tools. So now you know where exactly to start. Like what are the important vulnerabilities to start with and go down versus throwing this over the fence to dev and upsetting them and having a contentious conversation. So we implicitly fostered the collaborative nature of DevSecOps. Cool. So competition, who you guys compete with? How do you guys, who do you run into the field against what are customers looking at that would compare to you guys that people could think about? I think like our biggest competition to be honest is the companies that want to, they tried to do that themselves. The DIYs are not invented here. I mean, we've talked to a couple of companies, they've tried to do this for two years and they failed. Outside of us trying to sell something, like is that really in your company's best interest to have a team dedicated to building this platform? And I think there's a couple other big companies out there that do part of it. But like we architected this from the ground up to be unique and somewhat differentiated in a very crowded security market. What's your general advice? And you know, friend comes to you, CIO friend. Hey Mike, you know, dude, bottom line. What's going on with security? How do you like, I mean, what's your view of the landscape right now? Because, you know, it certainly is noisy. Again, like I said, the number of software tools and billions of hundreds of billions of dollars being spent is quite in the gardener. Yet the exploits are still up, so it's not like having any effect. It's something someone's winning. So if there's more tools, either something, the tools are ineffective or there's just more volume on attacks, probably both, but you'd go, oh my God, there's nothing really going on here. There's no innovation. What's the landscape look like? How do you describe that in kind of simple terms? Unless security landscape, crazy, out of control, chaotic. I mean, what is that? I mean, if you go to RSA and walk the floor, it's like all of the same buzzwords got exploded and there's no real solutions like that address the near, like we talked about, I said earlier, the definition of sanity is doing the same thing over and over, like we keep deploying the same products and having the same results and not being more secure. So I think there needs to be a rationalization process. You can't just go buy tools and expect them to solve all of your problems. You have to have a strategic framework instead of a tactical approach. All right, so I'll say to you as another example, I got IoT on my agenda, I got a lot of industrial equipment that's now going to connect to the IP network. It used to go to some, its own proprietary backhaul, but now I'm on the IP network. Mike, how does this play into that? And obviously it's going to open up some more surface area for attacks. How do you guys work with that? So I think it goes back to having this continuous security scanning. Like if you have all of these IoT devices, you have to know how they're operating and you can't just send a bunch of log data to your SIM and try to extract that signal from the noise and overwhelm your security operation center. So how do you run that through the kind of a, let's call it map reduce for lack of a better term, to extract that signal from the noise and find out like, is this device talking to this one? Is that correct or is this anomalous? But it has to be continuous. That cannot be periodic. Obviously, data is important. My final question to end the segment is, the role of data and the role of DevOps' impact to the security practice. What's the reality? Where are we? First inning, second inning? Data, obviously important, comment on that. And then DevOps impact to security. Obviously, you see momentum. What's your thoughts? I don't think we've got out of the dugout yet to start the first inning, which is exciting in some ways, if you're a startup or depressing if you're an enterprise. But we have to take a different approach going back to how we started this conversation. The current approaches aren't working. We have to think differently about this. Okay, so we're in the early innings. I'm a pioneer in early adopters, so I'm desperate or I really want to be progressive. Why am I calling Cyberg? I think because you understand that security needs to be more of a priority. You want to shift that left and find defects and vulnerabilities early on in your product life cycle. If you're ahead of product, wouldn't you want to have some security assurance before I delay your delivery date because the security team comes in and finds a bunch of vulnerabilities the day before your launch? Yeah, so security is a service, as you said. Mike Kyle with Cybrick, CTO, bringing his expert opinion here and some CUBE conversations here at Palo Alto. I'm John Furrier, thanks for watching.