This is Vectrix

Hi there everyone. Today I'm excited to be talking with the three co-founders of Vetrix, a SaaS security startup that was recently acquired by Cloudflare in early February. My name is Tarika and I've had the privilege to work with Corey who is CEO of Vetrix, Matt who is CTO and Alex who was COO as the product marketing manager for Vetrix. Today I work at Cloudflare supporting marketing for the Zero Trust platform. Before we get started, I think we should do a little bit of introductions on each of your backgrounds and how you came to found security. So Corey, I'll start with you. Sure, thanks Tarika. So I'm Corey Mahan. Background is starting building and breaking things from studying at university to early working at large infrastructure and energy companies, always in the security space. So I like to say a rack stack, cabled, clean sub floors, did all the fun stuff, but always interested in kind of the security space. And always worked there to probably more the middle of my career in the last say five to eight years, working more on the cloud and SaaS security side is that kind of as emerged as the new place to be as we move more and more data and users there. So always in the space and definitely continue to be excited by it. Hence the founding of Vetrix and now we're excited to continue that at Cloudflare. Alex, what about you? Yeah, sure. My name is Alex Dunbrack, like Tarika mentioned, one of the co-founders of Vetrix. I think it's a common theme for all people that started in security, breaking things, finding the back doors, all those things was my interest in starting point. Worked in security professionally at a few other companies before Vetrix and now Cloudflare, somewhat in a compliance capacity, but then moving into security automation, which was a likely genesis of Vetrix with my co-founders here, but never a dull moment in security and love being in it. Absolutely. And Matt? Yeah, thanks Tarika. Yeah, Matt Lewis, probably one of many. That said, I come primarily from red teaming background for sure. Really started kind of in like the pentesting and vulnerability assessment space. Later being a security engineer and really focused on like internal blue teaming and a lot purple teaming across different tech companies. And subsequently, we identified a common problem, I'm sure we'll lead into here in a moment, that we found in Vetrix to solve for and now we're at the end of that journey. Yeah. So Matt, I wanted to ask you, since you kind of were the first person to really kick off Vetrix and then bring Alex and Corey onto your idea, what was it like in the beginning and early days of Vetrix and how did you really come to realize that there was a need for a platform like this? Yeah, I think we can put rose-colored glasses on it later on, but the company I was working for at the time, I was a security engineer and turned out that it was a Sunday morning and on that great Sunday morning, it so happened that somebody got access to our Slack workspace. And of course, there's pretty critical business information in there. And of course, as a security engineer, you first go ahead and say, hey, how do we remediate this? And we go ahead and action that. And quickly, they were out of the Slack workspace and all had been resolved in that instance from kind of the surface level. But as a good engineer, you say, hey, I did this once, maybe I can like automate this in the future. And from that security perspective, you always kind of have this natural mindset towards like, can this be exploited in the future? And why did I not know about it when it happened from the start? And so I think it was really kind of like one of the birthing moments. I don't think there's this perfect rose where I came down with the 10 commandments from the hill. That said, I think it was kind of this death by a thousand cuts moment if I had to index it like that, where we continue to see that. And it was spawned through conversations with Alex and Corey as we were continuing to just try to kind of retro our security programs internally and solve for that. So that's a lot of the starting points here. Yeah. And Alex, I know at the time when Matt came up with this idea, you were working at a different company. Why did this specific concept of building a SaaS security platform that would help not just detect various security issues, but also help automate processes, as Matt said, really resonate with what you were doing in that space? Yeah. Yeah. Great question. And like I mentioned earlier, I was on the compliance side of the house at those previous companies I was at. And so one of the responsibilities that I had was being able to review, usually on a quarterly basis, all of the users that had access to the various SaaS apps we were using org-wide. And a difficulty that I was running into was I didn't have a great way across all of those applications to see who are the users that have access? Who are they actually? What employee are they? And then further than that, how have these SaaS tools been configured? I did not have a simple, straightforward, repeatable way to be able to identify those kinds of glaring security risks. And so from my perspective, this was just a huge gap in the market with regards to solutions. And so when Matt vocalized on his end that he had kind of experienced something in the same domain broadly with our SaaS applications, and Corey, the same at the company he was with, it very quickly became clear that this was a large issue that did not have a great solution for it. So that really got me started on getting going with Vectrix. Yeah. And Corey, as the most tenured security professional in this group, I'm sure this is an issue that you've seen time and time again of having difficulty managing and securing SaaS applications. For those who aren't familiar with Vectrix, could you give a brief description of what the Vectrix platform was built to do and how it works? Yeah, totally. So we started out to build Vectrix and I think arrived there for the most part to provide IT and security administrators a way to quickly gain visibility, control, and an understanding of their SaaS environments through detecting security issues ranging from misconfigurations, shadow IT, user activity, all the way to data loss prevention or DLP. And so through that kind of platform approach, we use what we call integrations to connect with those SaaS services that they use, understand the data and activity occurring within them, and then provide that through a pretty seamless, easy to understand dashboard. And so the platform took on this approach of a modern industry term we would call as an API CASB or Cloud Access Security Broker, out of band, very easy to set up. We're talking no agents, no installs, no downloads, so that the IT or security administrator can get up and running in literally minutes. Yeah. And Matt, why do you think it was so important right off the bat to create a platform that had no agents, installs, or downloads? Because I think today especially, there's a lot of platforms that need a lot of, specifically in the security space, that need a to get up and running using it. So why did you feel like that was a really important thing to build? Yeah, I think there's kind of multiple facets to that question. And I think from a technical perspective of kind of the problem that we were looking to solve, natively, it made the most sense to go and source our data from the API. A lot of security companies, I'd say all security companies are data companies at the end of the day, they kind of need a source of data, whether it's a operating system itself, or it's on the network, or API, or whatever method that you want to use as your kind of conduit for data. We chose the API, not only from that user facing perspective, and that security perspective of really the best insight of data, but exactly the kind of the point here of agents are fantastic and security teams, you know, definitely glean a lot of value from them and point security and lots of other offerings require agents. And it's something that's a little bit harder, though, from the deployment lifecycle and management lifecycle as a user. And so just so happened to work out as kind of this magical moment of, oh, hey, great, this makes sense from the engineering and security perspective, but we can bestow that value proposition. And on top of that, it can serve as a competitive advantage to us to also have an easy to use platform. So definitely like agents continue to be a measure that has to be taken. And it's wildly interesting and has to be done. However, being able to do it through the API was was really a win on all sides if I had to kind of frame it up. Yeah. And Alex, if you were to describe like, what in a layman's term, what the primary use cases of the metrics platform would be? How would you describe that? Yeah, yeah, I would say the one that we would start with at minimum is visibility, that that's really where where everything begins is knowing about where is your data, who has access to it, all of these principles and security apply here as well. But beyond visibility, the sky is the limit with regards to what you can take action on when you know what's going on in your environments. So let's say you see a problem, you're able to then triage it and go down the list of how do I reconcile reconcile these issues. So for us, it was just a visibility is really this broad umbrella of use case for end users. Yeah. And just doubling down on that, I know that it's like specifically visibility into like the SAS applications that people that really are companies and businesses manage on a day to day basis. Like I know at Vectrix, we probably used over like 80 different SAS applications, and we were a team of seven. So you can only imagine how many SAS applications, larger scale companies really are using. What type of challenges did you hear when talking to industry and security professionals? Yeah, I mean, you don't know what you don't know, right? I think that's a golden rule in understanding and security. And the first stop is understanding and getting that visibility into issues like misconfigurations, as Corey mentioned. How have these files been shared with and with whom? These questions are glaring, and I think security practitioners are aware of where their blind spots are, but don't necessarily always have the right tools to go shine a light in those dark corners. So something that we just hear, I don't know what's wrong, but I know there's probably something in there for me to go identify. And that's the starting point for most security folks. So that's what I heard, at least. Not sure, Corey, if you heard any, or Matt, go for it. Yeah, I mean, Alex, to double down on that too, right? I think what exactly your point, what we also heard was this interesting like evolution, and it's a net new concept for them of going back to the castle mode model where you're self-hosting these applications and you have this mode of L3, L4, like the actual network layer, being able to kind of thwart those issues, that motion to the SaaS applications, at least in kind of the previous day, the administrator of these applications could at least trust that their firewalls were doing what they were doing and their network perimeter could be the solution there. And so they didn't have to understand kind of the topology of each application, comparatively exactly what you just said, the lack of visibility, insight, and even knowledge and understanding of each application and what critical data lives there was something that was not only this major value proposition and like pain point in their jobs, it was also a kind of shift of mentality and understanding for them as what a good security administrator knows and understands that they can no longer just kind of rely on the network to be protecting their crown jewels. And rather it's a really shifting, evolving landscape, Tariqa, to your point of the hundreds, if not thousands of SaaS applications that continue to scale as companies continue to grow and leverage more and more SaaS for efficiency. Yeah. And Corey, like, especially in the early days, I'm sure like prioritizing what SaaS applications were most important to support was really important. Do you have any interesting customer stories that where you were shocked that the customer didn't really know that they had these exposed files or if there were certain features that you were surprised that customers were asking for? Yeah, great question. First of the prioritization, yeah, it was definitely fun. I think as always, the customer, we listened very, very closely. We worked very closely with an early few to make sure that we were able to meet what they needed. What that normally looked like was your critical or core business apps where your mail and files and folders and users live. And so that was a repeating theme that we saw over and over. Some of the really cool, one really cool story that stands out in my mind is something that we had not even thought of until asked by a customer. And this relates to kind of a business suite of applications that includes file storage, email, calendars, apps, et cetera. And what had happened was the user experienced an issue where someone had publicly shared one of their calendars and had someone that was not supposed to be on a meeting find the meeting invite and join. Something very potentially harmless as a public calendar caused a bit of a ruckus, if you want to call it that. So they asked, hey, would you be able to find one who has invites publicly available? And then is there a calendar or a meeting link in that? Within literally 24 hours, we turned that around and they were able to go through that list and basically reign all of that in. And so something very much in this new kind of SaaS paradigm that we wouldn't think about. I mean, this is just a single configuration that one user intended or misintended to do that resulted in them having to take action. So that's a really cool story that stands out from kind of the early days. But yeah, most of the prioritization was really listening to what customers wanted. And we're going to continue doing that here. Yeah. And Matt, I'm sure you also have some pretty interesting customer conversation stories when trying to build out scans and stuff. Yeah, for sure. It was very interesting getting to go on user meetings where you're touching base and seeing what their experience has been on the platform. And you continue to find why Combinator often calls it like some hacking your product and using it for something that you didn't really realize is intended to do. And kind of one component of our platform is that we ingest a large amount of metadata and we kind of clean it up and normalize it and then show it to the user such that they can not only glean kind of the finding that we're producing for them, but they can also start gleaning interesting metadata around that finding and understanding a little bit more about their environment that they might not have understood previously with our insights. And so it was always very interesting to be able to jump on customer calls and saying, oh, hey, we're surfacing something like user installed a third-party app that has Google Drive access. And then yet meanwhile, also comes out, we didn't know that that app was even being utilized in our company. And that's a shadow IT use case right there. And we just continue to dilate the use cases like that kind of based on the polymorphic nature of the platform or what data we can ingest. So it was always very interesting to be able to interact with customers and we would shake out use cases that our platform could do even better based on our customer conversations or we're already surfacing. Well, yeah. Sorry, just to add to it, I'll give you one more cool story just while we're talking about shadow IT. And this is, since we're talking about metrics, I encourage obviously all founders and other people building stuff to use your own tools. Speaking of shadow IT, there was a morning where I tried to be cool and order the team breakfast and I owe off into DoorDash, the food delivery service, which then triggered an alert to the entire team that said, hey, Corey just signed up for DoorDash and the breakfast surprise didn't go as well. But as a cool use case of one, use your own tools, but two, like exactly to Matt's point, maybe that wasn't an approved or authorized or clearly okay app. It could have been something else that I was giving permissions to. And so we've seen users take advantage of that exactly to Matt's point of being able to know, hey, who is granting what permissions to who? Is that allowed? Is that not supposed to be there? Why did they do it at this time or this hour? And there's a lot of data that can be gleaned from that. So just a cool story if you wanted cool stories on the early days type thing. Yeah. And I think that kind of like hones into the point of why an API driven CASB is really, really crucial in today's day and age, because you can actually derive real time findings about activities that you normally would not have full visibility into. Alex, can you speak into like why you think an API CASB will really help? Or for those of you who don't know, Vectrex is now going to be an API CASB under the Zero Trust platform for Cloudflare. How do you think that's going to affect the Zero Trust platform as a whole? Yeah. Yeah. So first of all, Zero Trust is such an interesting concept, and it's been very fascinating to watch it over the last few years evolve and mature into something that arguably most, if not all enterprises really need to think about and address. So the state of Cloudflare Zero Trust prior to us joining comprised of the access, gateway, and browser isolation products. And so I think Matt and Corey can agree with this. We saw ourselves as a likely addition to that suite of full enterprise level grade security software. And so while you've got these other ways of detecting security problems that Zero Trust previously had only revolved around, which was mostly network based as this Cloudflare's how they operated before us, at least, we're adding this other angle of security that previously went unaddressed data at rest. So like Matt mentioned, the things that live behind to be an API, those are things that security organizations using Zero Trust might not have had the ability to peer into like a traditional CASB, but because we're API driven, we're able to add this additional layer of security and visibility that creates and adds to this concept of Zero Trust being this final solution altogether that gives enterprises a way to keep their organizations secure. Yeah. And Corey, do you have anything to add to that since you're right now in the midst of helping integrate the Vectrix platform into the Zero Trust platform? Yeah. I think one thing I'm most excited about is how seamless it will feel for users and customers. The idea that they know we existed in a previous context, ideally they won't ever know that, right? We want the platform to be a fabric so that it's all just intertwined. What I'm most excited about is when we do that is you get the benefit of having controls that are offered in products like Access or Gateway, where you can provide a shadow IT visibility report. So you know on the wire where your users are going. And then you're able to go from unsanctioned app to sanctioned app with the API CASB driven product in literally a matter of minutes. And so just kind of that one plus one equals three narrative within the whole Zero Trust platform of, hey, it's definitely better together, right? By using multiple products here, you're able to one, secure more and you get more value from it versus just individual point solutions. So I'm most excited about kind of the slingshot effect of, oh, I use this to do this, so I can use that now across the suite of tools. So that is something that I continue to be excited about. It's something that I use for ourselves, right? It's just a super, super cool story and the value is undeniable. Yeah. And just looking forward thinking as well, Matt, I'm sure that tech at Cloudflare right off the bat really, really excited you. Is there anything in specific that you are looking forward to in terms of, from a build standpoint? Yeah, for sure. I'm the technical one here, so that's what I care about first. Yeah. I think the architecture of Cloudflare is effectively globally unique in the ability to be able to have that level of network presence globally, such that when you have the Zero Trust offering products like Access and Gateway and RBI already sitting at the network and that kind of source of data is already right there and primed, ready to go, and we continue to execute at what we do best with data at rest, if we want to call it that, as security practitioners, where we're kind of tapping that data from those third-party SaaS applications. I think kind of like first plan is, of course, let's continue being excellent in that, but then comes the larger and more important question as a security operator is, data at rest and data in transit, it's the same data in different forms. And so how do we look and introspect into both of those things together to come up with truly the industry-leading insights that make a security operator really have the best, easiest job of being able to get the highest quality alerts with the highest quality context, so they can action those right away, really between the full lifecycle of where that is moving at any given time or where it's historically been at rest. Yeah, and I guess I think another interesting thing about this collaboration as well is just the fact that the CASB product can kind of pave its way through already the Gateway product because it already has CASB-like functionalities and same thing with Access and same thing with RBI. Corey, could you speak more into how you feel like even the term CASB in itself, really, what does that mean? Really, what we're all looking to solve for is to help secure systems more effectively. Yeah, definitely on the terminology, it's interesting talking in terminology because when I talk to customers and continue to build security products, acronyms don't really mean much and they're not that helpful. And terms evolve over time. The term CASB, for example, is over a decade old and it's evolved. It takes on different forms. There's the inline model, the API-driven model, which we are akin to. But what I'm most excited about is the problems that we're solving that mostly live around exactly as we've talked about, data at rest, and then now the users that live within those SAS systems. And users are a form of data to some degree, so we can summarize it as data at rest. But I think that's what's so cool is that we're able to provide that, one, the visibility into it, two, the control. So hey, I see something bad or I don't want to allow that action. I have that capability. And then three is, hey, that's not something that I need to respond to immediately, but I want to keep an eye on it or trend or track, provide analytics on. And so as the technology has evolved to meet the needs, our data used to live in data centers only, it demands Castle Remote Model 2. Now it's literally all over the place in a good and perhaps some scary ways. So the more that we can integrate, the more we can take advantage of the native SAS offerings, i.e. via communicating through APIs, the more we can reign in. And so that's, I think, kind of ingests what I'm most excited about. Yeah. And Alex, I guess from a Cloudflare customer standpoint, why should people even get excited that a CASB is being introduced or an API-based CASB specifically is being introduced into this platform? Yeah. I mean, I think it would be rash to argue that CASB hasn't proven themselves over the last 10 plus years as really this trusted source when it comes to securing your network and your systems, as you mentioned. So as a user of Cloudflare for years, and I know Corey and Matt come from the same camp, I think for us, we just recognize it as this, they're going to be, if they put their minds to it and if they're looking to tackle a space and solve a problem for their users and customers, they're going to do it. And so we found for ourselves, we know that this is an evolving space and maturing as well and only becoming bigger and bigger. Cloudflare is looking to tackle this hard problem that we've already gotten a leg start on, but to come and join forces, we really see this as, Corey will probably laugh at this, but product synergies that exist, it was a match made in heaven for sure. And I just know that our whole team is so excited to be here and contributing to the mission they're on to build a better Internet. Yeah. And so I want to spend the last few minutes now, just kind of reflecting on the fact that you guys built a startup from the ground up during a very difficult time across the world and going through a pandemic has not been easy for anyone here. Corey, can you speak to what was really, really important since our team had to be fully remote during this time in building up the Vectrex team? Yeah. I think for, without a shadow of a doubt, it's the people element. I think that that is what drove and contributed to any success that we've been gathered as a group, as a unit. So I think that we were a resilient group. I think that we were a very determined group. And I think that we were a very scrappy group in the best way possible. It was always a pleasant surprise talking with whether it be a customer or an investor, an outside party, and then thinking we were a team of 20 or 30 or 40 or 50 in some cases. And that was really powerful to me. And you don't get there overnight. It's a process to find those right people and to build a community with the right values and with the right beliefs, supporting each other throughout. So to me, it always comes back to the people. Once you have the right people, I think we built a pretty good product and we'll continue to iterate on that. And then everything else is downstream. So it was definitely the resilience of the team and to the drive that we brought every day. Yeah. And Matt, being the technical leader of the Vetrix team, do you have any advice for other startup co-founders when trying to build their company from the ground up, especially in a remote workspace? Yeah. I think there's a lot to unpack there. That said, if I had to kind of frame it up in two different ways, when you're remote, we definitely found a writing culture to be very helpful in that, making sure that everybody was on the same wavelength as when you're remote, it's not so simple as turning around and saying, hey, can you just change that one line of code there? So I think that's number one in terms of kind of the remote first nature of engineering. I think from a startup perspective and the technology side of the house, it's always a fun conversation. One of the best strengths that I think we led into most was really being disciplined engineers first still and making sure that our code base was maintainable and was well-tested. Everything that might kind of fly in the face of often like a startup that's trying to build something net new and has kind of like no idea of where they're going and maybe they're not testing their code base, but we knew that we wanted to build a rock solid product from day one. And in order to do that, we need to have a solid code base from day one. I think that's number one, but I think number two, from that startup perspective and being a founder in a startup, you have to make sure that the code you're building is maintainable and tested, but yet also flexible in how the value proposition is going to be bestowed. And I think that's why we often kind of allow the platform and the utilization of it to expose a little bit more data and maybe simplify it in a table view such that users can really glean multiple use cases from it in a more simplistic point of view so that we can have a little bit better leverage both from the engineering perspective and from a value proposition perspective to discover more from the customer and also not have to reinvent the wheel every time we made a small little adjustment in a feature here or there depending on feedback. So I think flexibility, good code, and I think a culture of writing definitely would help kind of that founder mindset of being a CTO. Yeah. And then Alex, finally to you, from like a customer perspective, how do you go about, what is your advice in building a strong customer relationship? Well, actually, to build a good customer relationship, you just need to be there, be present, be willing to help where possible, be transparent and communicative all the way through. And I think you earn respect and relationships grow off of that. But almost to Matt's point of just a startup founder mentality, just something I think so important is pragmatic optimism where you look for the bright side, glass half full mentality, but be real about problems and the things that you're looking to solve. But yeah, our customers were so great. They did everything for us. Well, thank you for chatting with me today. This has been really insightful for me, even though I've been working with you guys for over the past nine to 10 months now. Really excited to see what's coming next for both Zero Trust and CASB. And for those of you who want to stay tuned on any updates, please go check out the two blog posts that are linked in the description. And if you're interested in signing up for CASB's early access, we do have a beta waitlist for them. Well, thank you all so much. Thanks.