Special Episode: Cybersecurity

Corey: Sure.

Jason: So I started the company right after college and I was sort of in their MBA equivalency program, but I was super technical and I really didn't fit in with that style of program. And what ended up happening was during that time period was around the same time that a lot of companies in the United States and abroad were starting to get attacked by what was sort of being whispered about as this thing called the advanced persistent threat, which now is kind of well known, at least in my circles as China actually, the State of China, individuals in China, but their actual military.

Jason: And what they were looking to do was to actually gather as much intellectual property and information from American companies so they could replicate a lot of that and kind of send it over to Chinese businesses, kind of bolster them up. And also for companies that were working with the department of defense, they really wanted to get as much intelligence as they could on any sort of military development. Like we had GE Aviation, so the Chinese were obviously really interested in anything that we were doing for the department of defense.

Jason: So this all started around the time I was a couple years into GE and I'd always been really into security and I had this great opportunity to really start my career on what was called like the computer incident response team. So back in those days, it wasn't called just cyber security, that term was still kind of new. People were still calling it information security. And still to this day, it's very much a model that's reliant on what I would call surveillance, what maybe others would call detection. And what we did at the GE Cert, was we serviced all of the other sub businesses of GE. And you've got to remember at the time, this is 2010, 2009, GE had a lot of businesses. We're not just talking about like the one I just mentioned, like GE aviation. And when we think of GE we're always thinking about like the appliances and the dishwashers and the refrigerators. We also had healthcare, we had GE Money, which was a major credit card processor. We had NBC Universal, we owned all of NBC and all the universal studios.

Jason: So around this time period we were doing things like the Chinese Olympics, the summer games, things like that. They all kind of created this massive security need that we had to fill from a central sort of team. So we were talking about monitoring 300,000 end points employees, it was a lot to do for a very small team.

Corey: How large was the team?

Jason: Yeah. Yeah. So we started off really small. I joined the team in the second wave of when they were recruiting internally for smart folks to really be there. And I was an intelligence analyst and I think when I started on the team, we were 10, 11, 12 folks that would be considered, I think a smaller cert now, but back in those days, dedicated teams inside of companies just weren't really the norm. Now you'll see even like major retailers and things like that, these teams can spend, whole departments, 40, 50, 60 people. That's usually the norm.

Jason: And you also have to remember how the federal government is set up with States, same with GE. We had GE Corporate, which is what I worked for. And then all these sub businesses that I talked about, they had their own little security teams as well. And we were there to kind of provide these Meta resources for them and to cover the things that they didn't necessarily have an incentive to look at.

Corey: Got it.

Jason: Yeah. Going back to what is enterprise security, how does it relate? So at the GE Cert we sort of really bet everything on monitoring the network. So kind of getting a little bit more technical, 2010, 2011, not every website was SSL encrypted. So we had really the ability to monitor all the traffic that was happening. We started off at the edges, we look at things that were traversing to VPN, really anything going in and out of the company. And then we would have simple rules on what was called intrusion detection software and we would look for patterns that looked like something bad was happening.

Jason: When I started, I was working with a lot of folks that were ex-military because the Air Force had heavily invested in training folks on cybersecurity. So there was a lot of talent there. I was sort of adopted into that mindset of we were the good guys against the bad guys. We're going up against a nation state that had military resources, they were targeting our organization. I felt like very proud and almost patriotic to be doing that. At least initially kind of gave me this attitude that it's great that we have all this access to all this data that we're getting over the network and eventually we got information on the devices themselves by installing an end point agent.

Jason: And we had all this data but we felt okay about that morally because we were the good guys and we were doing everything in our power to really stop something really bad from happening to our employer. So that was my first thought process and everything was going great over the first few months and we were dealing with real incidents, like this wasn't a made up problem. We were definitely responding to real attacks that were happening in the organization. But there was an instance where something happened and it really completely changed my perspective on what does it mean to be a good guy who has access to all this data.

Jason: So one evening we got pain because we saw an alert in our network monitoring tool that indicated some person in India was zipping up all these files, encrypting them, and then sending them over to this shady looking FTP site. This is like a prime indicator, like it's the emo of the Chinese ABT for how they operate. They kind of stage everything on one device. They encrypt it and they zip it up. They usually use WinRAR or something like that. And then they send it over to FTP site with just basic credentials.

Corey: So this is a red alert situation?

Jason: Red alert situation. Now what was interesting, this is the first time that we actually caught it in progress so we can actually see the transfer happening, we couldn't see what was in it, but it fit all the criteria. So we were really excited. We called up our boss, who called up their boss and it really all the way went up to the top of the food chain because what we wanted to do is we wanted permission to be able to hack back and actually stop, not only stop the transfer but actually take the credentials of the FTP server, which we could see go into that FTP server and then delete everything that they had actually successfully exfiltrated.

Jason: That was a really big deal and we needed special permission to do that, which we got. So everything went according to plan. We were able to stop the transmission. We went on the FTP server and we deleted everything and man we were so excited. We were like slapping each other on the back, high fiving, like this was a huge, huge milestone for us as a computer instant response team. And then days later we realized we hadn't stopped anything at all. We had actually done something really, really bad. We actually didn't detect a real exfiltration event. And what ended up happening is we somehow misidentified some contractor that worked for GE, who was just simply backing up and transferring their family photos to their personal FTP server.

Jason: So we ended up basically annihilating their backups, and then on top of that, there was obviously an investigation that went on afterwards because we wanted to identify what really happened. We had stopped the activity, but we wanted to write the whole incident report, really understand how the data got there. And in the course of doing this, of course we identified who the employee was and everything and we were like, "Oh, this was clearly a mistake." But I guess the wheels of justice at GE were already turning and I believe that employee ended up getting terminated because they were doing something they really shouldn't have been doing.

Jason: And that really left a really bad taste in my mouth because here was someone where, sure, they were doing some personal thing at work, but like don't we all do that stuff a little bit anyway? And they ended up getting fired for it because we overreacted to something that we were like 95% sure with the activity that we were looking for and we were supposed to be the good guys and we ended up, in my opinion, kind of causing a lot of harm to that person. And that's totally changed my perspective on this sort of good guy, bad guy mentality. And even with the best of intentions you may end up actually causing more harm than you intend to.

Corey: So how did that lead you to start a new kind of cyber security company?

Jason: Yeah, so that was sort of a very formative moment in my career and it didn't just change my perspective, like a light switch, but it really did put me on pause and really try to think about the privacy implications of what we do. And I eventually got into the mode of building software instead of actually doing the actual incident response work. And I tried to be mindful about that privacy portion, everything that I built. I started to Kolide in 2016. The reason why I started was I was really excited by this open source agent that of all companies, Facebook put together. Because to me having transparency in the code that is doing this detection on the end point I think is really important.

Jason: A lot of the security vendors that are out there today that do endpoint security, which essentially consists of, you put an agent that's monitoring the hardware and the operating system and then sends all that telemetry to a server and that server gives you analysis of what's going on. It looks for threats. Everybody on the market today, they really protect the agent in terms of what it can do with the source code because those are like the crown jewels of that organization. And Facebook had the complete opposite approach where they kind of rejected all of the existing solutions on the market. They didn't really scale and they were very windows focused and obviously Facebook is heavily macOS focused on the workstation side and then Linux focused on their server. So they built this great tool, Osquery.

Jason: So I saw an opportunity to really build something in the space where you could start with an end point solution that was transparent from the perspective of the source code is open and then could you really build something on top of that that was compelling and equivalent to the existing endpoint detection and response products in the market. So that was like the Genesis of the company. But this was in 2016 and I still hadn't wrapped my head around the second phase of that, which is sure, the open source agent is transparent in the sense that you can review the code. But we hadn't really done anything, we were still very much catering to the security team and sort of leaving the end users away from that.

Jason: So we've built several products on top of that concept and they all did reasonably well. But not to the point where I thought we were really taking off like a rocket ship. And so at the beginning of 2019 I had an opportunity with my team to kind of hit the reset button. We were just like, "Let's start from scratch and let's really build something that embodies the values that I have as the CEO and that we have as an organization around privacy and what we call end user focused security," where you're really kind of treating those folks as first class citizens. So that was how the journey eventually ended up where we're today, where we have a product that's really focused on that as a value.

Corey: Wow. So if I'm a user, my company uses Kolide, what is that experience like for me? What difference would I see from your typical endpoint protection agent software?

Jason: The way that I would describe Kolide today to anybody who asks whether you're the actual end user who's getting this installed in their device or you're even the security team that might be buying it. Kolide is essentially an app and it detects security issues on your company's devices and then it pings your employees in Slack with advice on how to fix those issues. And that's it. The reality is that we focus on not just things like, Oh, is my disc encryption, is my firewall enabled. But we also look for things that people typically get wrong. Like, Oh, I signed up for G Suite for my organization, they asked me to download some two factor backup codes. So I just threw those in my downloads folder. You don't necessarily want to do that, you want to put them in a password repository or I'm downloading a production backup because I need to troubleshoot something and I'm an engineer. Well that backup shouldn't live on your system for a period of time, more than maybe 24 hours.

Jason: So we try to really take a human approach where we have empathy for the types of things that you need to do in order to get work done. You might be creating risks for you and your organization and instead of just locking down the device, like let's enforce everything. We're going to turn this off, we're going to make it impossible for you to turn your firewall off. Let's instead just look for those things and those things alone and then put a hand on your shoulder through Slack and say, "Hey, we noticed you turned your firewall off." When you're done with whatever you're doing that requires that to be off, you should turn it back on and here's exactly how you do it. And here's even a button in the Slack application where you can click it and then we'll just tell you if you did it right or not, in terms of turning it back on.

Corey: Developers must love this because so many times we got to use Docker but then the security software freaks out or we end up hitting limitations. And it sounds like with your software you're not immediately restricting the user, you're letting them know when something is off and letting them fix it.

Jason: That's exactly right. And this is all based on the premise that especially as a software engineer, in order to do your job, you need to modify the security stance of your device. And usually with the best of intentions, like you just mentioned Docker, we had one engineer who was telling us a story about how the firewall was forced on their Mac and they were having issues with Docker. They assumed it was the firewall, so they went to their system preferences to turn it off. But of course they had management and software installed where that couldn't happen, it was grayed out and they didn't have the administrative privilege to deal with that.

Jason: So then they had to put in a ticket and then they had to wait and they were waiting and waiting and waiting and several days go by and then they're given special permission to turn off the firewall and then they turn it off and then they realize there's still an issue and it turns out the issue had nothing to do with the firewall, but because they didn't have the opportunity to troubleshoot it themselves, they couldn't actually go through that process and they just sort of hyper focused on this one thing and that's not good for anybody. I think that that's like a mistake for the business to have these blanket enforcements and I also think it's a mistake to have nothing.

Jason: I think this is really kind of like a nice compromise between those two things and it treats the end users like they're adults and that they're capable of making intelligent decisions but gives them the information in order to get the computer back to where it needs to be. If you forget to turn the on the firewall, for instance, after turning it off.

Corey: When you approached your first potential customers and said, we have this new way of doing enterprise security, you don't need these blanket restrictions. You can help the user fix it for themselves. How did you pitch it and how did they respond?

Jason: We're a small company, we're a startup, and so when you have a brand new idea with this, it's very important I think to start with people that get it right away. You don't want to do a lot of convincing for your first five or six customers because it may make you feel like you're headed in the wrong direction. So the folks that we started off with, it was a very easy pitch and it's very similar to how I just walked through it and it made sense then because the first few customers that we've had on the solution where other SaaS companies, they had large contingents of engineers who were exactly going through this problem. They were suspicious of the existing security software that they were evaluating. And there was this big cultural issue with, Oh wow, we're a startup but now because we have to "grow up" we're now installing all this surveillance software and these companies, they were doing it because they felt like they had to, there were no alternatives out there.

Jason: So for our first customers it was a very easy sell. But then you exhaust that pool of true believers I would say. And then you move on to people that there's an education process involved. And I think from our perspective, the best solution that we've had is to really start with software engineers, it's easy to understand. But where people kind of get caught up, they assume, Oh, this really is only for developers. It would be way too technical to have someone manage their firewall this way. And I pushed back pretty heavily on that. And I think people realize over time that this isn't just something for your super technical folks. This works for everybody in your organization.

Jason: And sure, you may have some folks who are totally disengaged and they just want you to take over their computer and really lock it down for them. But I would argue that those folks are in the minority in this situation and I think we can start dropping this cynical approach that we take to information technology and cybersecurity that the users really don't care or they don't want to learn. I think that may have been true 10, 15 years ago, but our workforce has evolved. The people that are in the workforce today grew up with these devices. They know them way more than I think people that saw this technology developed after they had joined the workforce. And we're in a position where people want to take that ownership and they derive a lot of productivity if they have full control over their device.

Corey: So I want to zoom in on that a bit. For non developer users, how do you make the messaging friendly and make it not scary or not overly complex so that the user is actually empowered to act on it?

Jason: Yeah, this is really hard and this is something that we had to learn through trial and error, because ironically we started off as too friendly. You wouldn't imagine it's possible, but if you're a little bit too friendly, it can come off as condescending. Like everything ends in an exclamation mark and Oh my God, we're doing security together and it's so much fun. We kind of hit that direction a little bit too hard, it took away a little bit from the sincerity of the product. If you go too much the other direction, here's a perfect example.

Jason: We see a lot of nontechnical folks that had a technical person over their shoulder to configure something for them really quick, and I'm doing air quotes right now and then put them in a state where their device wasn't secure, like they added an SSH key, so that they could like upload a markdown file to like a blog that's hosted on GitHub or something and they end up with this insecure state and now we're pinging them about, "Oh, you have an unencrypted SSH key that looks like it has something to do with production on your system." And this is a person that doesn't even know what an SSH key is.

Jason: So how do we deal with that? Well through trial and error there are things that you can do to walk them through the process of first let's treat them like adults and let's explain what this is and why it's a problem. A lot of security companies skip over that if they're even communicating at all. So what is an SSH key? What does an unencrypted SSH key mean? What is the risk to your organization? Why is it important that you fix it? So we start every message off at something like that type of a preamble.

Jason: And then when we go into the step by step instructions, we're talking in terms that are friendly to someone who already familiar with things like the terminal. But we're also talking in terms for people who may have never used the terminal before, can get through it. Like here's a perfect example, like when you're in the terminal and you type sudo and you're prompted for your password. It's normal for you and me to know that when I type on the keyboard, no characters are showing up because we've done it a thousand times and we've gone through that experience.

Jason: But for someone else who's never done that before, they may think their keyboard is broken or that's something's wrong or they don't understand what's happening. There's little nuggets of information that we can put in those steps that don't disrupt the advanced users but help someone like that get through the process. So it's really a balance and you have to be not too zany. You have to also not be too serious. And it varies from culture to culture and level of expertise. And we're still finding that balance, but it's hard and luckily we have enough customers where we can really hone it over time. And there's a lot of value in that.

Corey: So they give you feedback?

Jason: Oh, all the time. All the time. We get a lot of feedback and we iterate on it really quickly and luckily we've been into the position so far where all that feedback has been universally applicable. Eventually though, at some point as we grow and we start dealing with cultures that have different norms or different languages, we're going to have to expand. But I'm looking forward to that as someone who's really into user experience and the intersection between that and security. I think it's a lot of fun and it's something that I think is relatively ignored in our industry.

Corey: So really basic question, Jason, as a novice at this stuff myself, how do you know what to look for? What security issues might pose a problem in the first place?

Jason: User focused security, which is what we practice really starts with empathy and that's really being able to visualize the needs of the folks that are using the devices every day and trying to understand where risks might exist there. Now, it's very easy for developers to empathize with other developers that have similar workflows. But where the key is, can you empathize with people that are outside of your normal workflow and come up with things that are going to be compelling to them?

Jason: Because we take this approach, what's really interesting about our product is that we tend to find issues with the folks that are at the top of the food chain of these companies, like the CSOs and the CTOs. They will enroll their device and suddenly have like 15 alerts and even though they may already have a security product that isn't alerting on anything. And it's because we're able to visualize the entire chain of risk from start to finish. Let's take Heroku for instance. We have folks that use Heroku all the time and we can think through, wow, what is one thing that someone might do wrong with Heroku? Okay, well they may download a production backup from the user interface. They may store their two factor codes and their downloads folder. They may inappropriately store their credentials for the command line tool in these areas.

Jason: These are all things that we know are happening because we use Heroku and we can encode that type of rule set into our solution. And suddenly any developer, CTO who is really kind of getting their company started and kind of cut a few corners here and there and they know they weren't doing the right thing, suddenly we've caught those issues and now they're front and center. We have a Slack app actually telling you about them. And I think that's really powerful and I think that's the key is sitting down visualizing that. And that really is combined with talking to folks and really understanding the workflows. So we do a lot of both of those things and it's worked out really, really well.

Corey: Well, since you mentioned Heroku, I want to talk about your infrastructure journey and how you ended up hosting on Heroku and what your stack looks like now and your feelings about it.

Jason: Yeah. So we're a much different company from a technology perspective than when we started. Like most startups when we started, we had a very, I think forward thinking technology view where we wanted to try a lot of newer technologies that were more in their Springs rather than their Autumns, to take something from Steve jobs. You want to make bets like that, but the mistake that we made was that we made a lot of bets on the technologies that we were using to build the product instead of making the tech that's on technologies that actually integrate with our product that our customers are using and really thinking about that ecosystem.

Jason: It may sound very similar, but there is a subtle difference there. When we started the company, we react with sort of in the second phase of it's like hypergrowth, people were using react left and right for pretty much for every new project. GoLang was really picking up and really simultaneously that Kubernetes was really kind of getting a foothold across the SaaS world. So we had picked all three of those technologies. And I would say in retrospect, those decisions really hurt us because we as engineers, we had to learn those technologies simultaneously while you're trying to build something. And we made a lot of, I think, inefficient decisions because this technology has allowed us to do so.

Jason: So Kubernetes is a great example of that because Kubernetes allows you to really segregate everything through something called namespaces. We were like, "Oh, let's create all this separate virtualized infrastructure for every single one of our customers," which sounds really great and you can write a really impressive white paper about, but it ends up being like incredibly costly and you have to build all these other tools and things to kind of fill in the gaps where the solution isn't really fully baked yet. So we ended up pouring a ton resources into that type of stuff instead of the product that people really were paying us for. And we ended up spending a lot of money through these inefficient decisions. Not just an opportunity cost, but just frankly through our Google cloud bill where we were at one point spending like $2,400 a day just working through just a few trial customers. It was unbelievably inefficient.

Jason: So when we hit the reset button in 2019 we're like, all right, let's really flip the script here. Let's really make investments in things that are exciting but they're exciting to our users. Like our users don't care what backend solution we're using. They don't really care how the specific technologies that are in the infrastructure, they just want it to be fast, they want it to work. And what they do care about are the integrations that we're bringing in. So like, "Let's really invest in Slack and let's see what Slack is doing in terms of applications. Is there something to that? Let's then take the opposite approach on the backend and let's make very vanilla decisions that are going to be well supported that mature technologies around them."

Jason: And so may sound insane, but we chose Ruby on Rails for our backend stack. We chose Heroku because it has the best support for that stack. And we chose just PostgreS and Redis and basic things like that that would allow us to really kind of rely on the expertise of others through hosted services versus trying to just do all the same things that have already been solved. And that ended up working incredibly well for us.

Corey: And how has it been scaling?

Jason: It's been scaling really well. I would say that a lot of people come with the misconception that Rails can't scale and Oh my God. You're going to really regret it. Look at what happened to Twitter. There's all these sort of really scary things that happen in like the early 2011, 2012 period where people were using Ruby on Rails because it was the hot new thing. And then they got burned for it.

Jason: But I think there's a lot more counterexamples to that. You have GitLab, you have GitHub, you have Shopify, these are all incredible companies that are using Rails and they were able to scale. And in fact scale of being in the top 10 visited websites on the internet. I think there's a lot of counterexamples there. And for us, the majority of our scaling issues all relate to dumb things that we're doing on the database that are inefficient. They have nothing to do with the core technologies that we're facing. We've been able to scale in it because we have a ton of devices checking in, we've burst it up to a thousand requests per second on just Vanilla-Heroku hardware and that's growing pretty substantially.

Jason: We're always finding optimizations that, drop the traffic, because we can figure out a way to extend less or we're finding optimizations on how to get the most juice out of the database or how much work can we do asynchronously and how efficient per second we can do those things. But those are all working and we don't expect to have to switch off of that primary sack that I talked about probably for the next two to three years. Even at sort of exponential growth. I think that's awesome. And I think it just shows you that you can rely on other technologies and services to really handle that part and you can really focus on your product. That is a true statement in 2019 and 2020.

Corey: It sounds like a timesaver too. I mean we've all been on projects where weeks and weeks went into sort of generic infrastructure decisions instead of the product itself.

Jason: That's correct. And that's one of the reasons why I really like Rails is because it just makes those decisions for you. It's like, "Oh, what should we call our foreign keys in the database? Should we use underscore, should we use camel casing? How are we going to name the tables. Are they going to be plurals? Are they going to be singular? Oh, this one has like a weird pluralization. What are we going to do for that?" I'm sure there's people out there listening to this that love, absolutely love making those decisions.

Jason: But for me as someone who has a very small team, very narrow window in which we can succeed, those things are like death to me. I really can't stand them. And the fact that Rails takes on the perspective of we're just going to make those decisions for you because they're so arbitrary. Here they are. We are using underscores, we're using plurals here, but we're going to name the model singular nouns. That's what we're doing and that's how it's going to work, take it or leave it.

Jason: I love that approach because it really just clears the field for us to talk about how are we going to write this remediation step by step instructions in a way that's compelling to a customer. Like we can spend all of our time on crafting that language versus like the minutia of what we're naming things in our code base and where they should live and what folder structure they should be in. And that's the difference.

Corey: Makes sense to me. With our last few minutes, I want to reflect a little bit. You entered an established space security software, I imagine hundreds of millions of dollar industry with a new idea, a new product, a small startup. I'm sure many future founders are thinking now about how they might enter an established space and make waves in it. What advice would you have for someone who might be a little intimidated? Say they're entering the financial space with the startup or the medical space with a lot of big players already. What advice would you have for them?

Jason: I think the optimism that I have for them, the thing that they should look at is there are definitely established businesses that are already doing SaaS software likely in this area that you want to build your company in, but you need to look at how the environment is changing. Especially as people change how they work. This coronavirus situation right now, it's no different, this is a major shift culturally and how we are getting work done, which always opens up opportunities. And for us, that cultural shift started happening with Slack where Slack created this surface for us where we could solve a problem that really couldn't be solved before because there was no medium to express the notifications that we want to send out to the users where we wanted this very rich interaction with them. You couldn't do it over email, a web application works, but people don't want to be whisked away to another context.

Jason: So it was this creation of this ecosystem that allowed us to do that. And I would say to other founders, look for these fundamental shifts and really think about the things that you're passionate about and do these new changes, really open up an opportunity. And the reason why it's important to think about this as a scrappy startup is because the larger companies, they actually usually see those opportunities, but they're too big and the revenue opportunity is too small for them to attack them right away. So this gives you a really great reason to start investigating because for you, all you have to do is build up a business that's going to offset your opportunity costs, which is usually quite low, depending on what your salary is today, how old you are and things like that.

Jason: So if you can really find that foothold there, that's something that you should look at. And that was us because there are security companies, they're aware of what we're doing and they know that it's a threat and some of them are already starting to try to figure out how can we do this? But it kind of clashes with their existing surveillance. Every model there, it doesn't quite make sense. There's less revenue there, it's not really where they need to be growing. And those are the opportunities that you need to look at. And if you can find them, you will be in really, really good shape.

Corey: Wow, that's really good advice. I guess my last question for you is what have you seen that surprised you? You've been in the security space for a while now. What has stuck out to you as something that you maybe weren't expecting to see?

Jason: I guess what I was not expecting to see is how many companies, especially outside the US, maybe I shouldn't be too surprised by this that really care about the privacy and the conditions that their employees work under. The only reason we were successful is because there was a base set of companies out there that really believe very strongly in creating an environment that it feels good to work for that company. Like there's no psychic cost that you're constantly enduring for being surveilled and things like that.

Jason: The fact that that exists and it existed maybe outside of legislation, things like that. It's something that I'm kind of like a happy surprise that that's there and that people can see the value in what we're bringing. We don't have to do a ton of education. Now on the flip side, there are companies that are still very much in that mode of surveillance and we want to buy solutions that are going to allow us to surveil even more. Especially now with companies that are working from home. But those are folks that are diminishing every day. They're realizing that that's not the right approach and that makes me really happy. And I think that the scenario that I started with my career with, it's one where it can be avoided in the future and companies still get the protection that they need for the risks that are really going to be issues in their environment. It's a balance and I'm just super psyched that people are starting to get it.

Corey: That's good to hear that the trend is moving toward user privacy rather than away from it and respect for the user ultimately it sounds like.

Jason: Absolutely. And we want to be there to set the example and we're excited.

Corey: Great. So how can our listeners learn more about Kolide?

Jason: Unlike other security companies, we just let you sign up. So you could do a 30 day free trial at kolide.com or if you want to follow us on Twitter, we're just @kolide or if you want to follow me @JML on Twitter as well.

Corey: And would you spell collide?

Jason: K-O-L-I-D-E.

Corey: Alrighty. Jason, thank you so much for joining Code[ish]. It's been a great conversation.

Jason: Corey, thanks so much for having me. I appreciate it.