Security Unfiltered: The Journey of a Linguist turned IT Professional

Joe South

‍

How's it going, jeremy? It's great to finally have you on the podcast here. It's been definitely a crazy couple of months for me with a new board and whatnot and getting used to that whole thing, but I'm glad and excited to finally have you on.

‍

Jeremy Snyder

‍

Well, first of all, congrats, Joe, and second, thank you. It is a pleasure to be on here. I remember when my kids were little. I know what a difficult balancing act that is. I'm at the other end of the journey. Mine are now 23 and 19. So I don't really miss those days, in a way, but at the same time I kind of do. They're a lot of fun when they're little.

‍

Joe South

‍

Yeah, from what I hear, it's like you miss it when they're little, like them being so little, but like the struggles up in the middle of the night, no sleep. And yeah, you have to do a full workday. Right, it's hard.

‍

Jeremy Snyder

Yeah, yeah, and it's not always a normal workday, right Like when you work in IT and security, as we all know, you're always kind of carrying a pager, whether it's a literal one or a figurative one in the form of, you know, slack and SMS notifications for things that you got to pay attention to. So, yeah, I wish you the best in the journey and, again, congrats. It's got to be, enjoy the time.

‍

Joe South

‍

Yeah, thanks. So, jeremy, you know I start everyone off with getting into how they got into security or IT overall. The reason why I start there is because I there is a section of my audience that are trying to get into IT or security and I feel like always hearing someone's background is helpful, right, because maybe it's, maybe it's that background that matches up with them and they can hear like, oh, this is a possible thing for me, which is it's interesting, because I've done probably over 140 episodes by now and I haven't heard the same background once.

‍

Jeremy Snyder

‍

Yeah, and I don't think you're going to hear the same background from me there, because my upbringing was pretty weird, in many ways super nomadic. By the time I finished high school I'd lived in four states and four countries, spoke a few different languages, went through a very circuitous journey through college, actually dropped out of college twice, once here, once in Finland re-enrolled and completely changed directions in my studies partway through. 

‍

And without going through all the details of it, to answer your question, how did I end up in security? I kind of failed into it in a way. So after that second time of dropping out of college, I moved back to the US from Finland where I'd been studying chemical engineering, and I decided to study linguistics at this program at University of North Carolina where they had kind of this intersection of computer science and linguistics called computational linguistics really worked well for my background. I had a lot of well, I spoke a few different languages pretty fluently. At that point I had a lot of kind of exposure to a lot of languages and in Finland at that time in the early 90s, when I was going through school, linux had just been created, actually not at my school but at the school right across town and so a lot of our labs were running on Linux. So I had good exposure to some of these kind of new operating systems and things that were coming out. 

‍

So this intersection of computer science and linguistics was like perfect for me in a way. But when I say I failed into security, it's because I thought I would actually end up being a programmer but turns out I suck at coding and so I went through, got my degree, got a job with a company doing translation software or software designed to help human translators. So again, it's like the perfect convergence of all the things in my background. That would make it good. 

‍

But I wasn't good enough to program on our own software and the company was growing really fast at the time. So they came to me and they said hey, look, you're not going to cut it in the software development team, but we've got real big needs on IT infrastructure because of all the growth that we're having. We're opening new offices in a bunch of countries. You know. We've got a lot of network capacity that we need to expand. We're going through an IT professionalization kind of process things. 

‍

Everything on the IT side had been done very shoestring up to that point. You know this is in the days when we would have had a file server. That was just a tower sitting under somebody's desk right, and so we were going from that into actually having server rooms and, you know, having raised floor for the first time and you know some of these terms go over our audience's head, who's all born in the cloud, and they're like what is raised floor? I get it, but you know that's how I got into IT in general and we didn't really have a strong distinction between IT and security in those days. It was all just, you know, one team, you took care of everything. We did everything from installing drivers and standard, you know, laptop and desktop setup to install antivirus, patch operating systems, run boot scripts that forced updates to operating systems so people couldn't fall too far behind. All that kind of stuff fell into, you know, into my domain and I stayed with that company for seven years, kind of worked my way up through the ranks of IT and security. Had, by the way, like the two biggest breaches of my career, both at that company. Happy to talk about both of those. 

‍

I think the statute of limitations for staying quiet on them has well passed by this point. But some fun lessons learned out of that, and you know, and I kind of stayed in IT and insecurity as a practitioner for the next well, 13 years in total at the first half of my career and then kind of transitioned over more onto the vendor side. So not a typical journey, I would say, but I really learned a lot over over that 25ish years that I've been working in IT.

‍

Joe South

‍

So, with you know, a background of all that travel, speaking different languages and whatnot, was there ever a pull to go into any of the federal agencies or anything like that? I would think that that would be a skill set that would be extremely tempting for them. You know, and at least from my own experience, right Like I tried to go into federal law enforcement out of college, and I mean they could have sent me anywhere. Right, like I could have signed up with any of the agencies and they sent me anywhere. Right, I would have been cool with it, it would have been fun, it would have been the perfect time to do it. Was there ever that kind of temptation or curiosity on your end?

‍

Jeremy Snyder

‍

Have you ever seen the movie Spies? It's great. It's from the 80s Chevy Chase, Dan Aykroyd, one of the scenes in there. They're taking what's called the Foreign Service Exam and that's the process through which you kind of apply to become a State Department representative. I have twice taken that exam, twice passed it twice, made it all the way through to the final stage of interviews, and both times failed out on that final stage, for different reasons, you know, once when I was 22 and once when I was 36-ish, and very different reasons. I was at very different levels of maturity, but both times I'm glad that it didn't work out. There's a number of other reasons, you know. I think my career on that side would have been limited anyway because I am a dual national and so I think I would have been somewhat limited in how far I could have gotten clearances and all that good stuff. But certainly there was a pull in that direction Joe and I did explore. It didn't work out and that's just the path that I ended up going down.

‍

Joe South

‍

Yeah, it's really interesting. You know it's weird how stressful those interviews and that whole process can be, and it's like it's stressful in ways that you wouldn't even expect. You know, like there was, I think, I believe the NDA on this one was up a few years ago, right, but I was interviewing for the Secret Service and that won the physical test was like the hardest physical test I've ever been put through in my entire life. That was crazy. You know, 15 minutes into it you're gas and it's a two hour test, right, oh my gosh, it's insane. 

‍

But the interview part is the part that I struggled with. It was asking, you know, random, seemingly random questions that would fall under that type A personality that they're looking for and you trying to recall it under situations where you know they just read the question and you have to answer, right, they're not giving you any clarifying answers or anything like that. They can repeat the question and while you're talking they're writing down every single word that you say, right, so that's a whole stress factor right there. And then they're not even reacting to your answer, not nodding, not smiling, not nothing. And so it's like I don't know what is going on here. For someone fresh out of college, like myself, to go through that process. It was like all these other interviews, like it's going to be easier than this for the normal private sector, right? Like it's a crazy experience.

‍

Jeremy Snyder

‍

I mean both times. The final stage of the State Department process is a full day role play scenario on site and you're thrust into a bunch of different situations, which, on the one hand, is fine for me. I did improv comedy for a number of years. I'm very comfortable getting thrown into random situations, no issues at all. 

‍

But, to your point, you don't understand or you don't know what you're being graded against and you're getting almost no feedback along the way. And I just think about day to day meetings that you and I sit in, whether it's in person or Zoom. You've at least got some kind of visual feedback coming from the other side. 

‍

As we're talking, I can see you nodding your head. I know you're listening, you're paying attention, but zero from the evaluators in these contexts. All you get at the end of this full day is kind of a yes or no and maybe like two to three sentences of why it didn't work out if it didn't. Interviewing, I think, is still one of the things that we don't do well. By the way, it is also true in security. I don't think we're great at interviewing and I don't think we're great at giving people the opportunity to break into security.

‍

Joe South

‍

Yeah, that was probably my biggest hurdle with getting a break into security just getting a chance from someone. It literally took me almost three years to get into security, and that's with me getting certifications, starting a master's, owning all of security at my current company. But I didn't have a security title and so people looked at me differently, didn't give me the chance or anything like that. And I just remember one of the most frustrating parts was someone said I didn't get the job and I asked I said hey, why didn't I get the job? What can I improve on? What did I do bad or what do I need to do differently to get a job next time? And they said, well, you didn't have any experience with Splunk At this time. I worked for a very small company- like 30 people. There was no way we were ever going to get Splunk and there was no way that I was ever going to have a chance at affording 30 seconds of a Splunk instance in my whole lab. 

‍

And so it's like you're in an impossible situation. You're grading me against an impossible scenario that literally will never exist. Why wouldn't you take someone that's willing to learn, eager to learn, maybe knows a few things, has experience on help desk, and train them up, rather than just saying, oh, they don't know this industry-wide tool.

‍

Jeremy Snyder

‍

Yeah, and that's crazy because in that scenario in particular, whether you know a particular tool or not, I think is the least important thing in somebody's application for a position. If I think about the priority list of things that I think are important in hiring a security person, number one is just the frame of mind that you bring to the question about how you address security. 

‍

So if you're thinking about joining a new organization, do you think about it on a point-to-point or point-by-point basis, or do you think of a threat model and kind of prioritization? Because security is one of those things that is truly never done. Every single day, something will change within the organization that needs to be thought about, reassessed. Maybe it's just the volume of transactions, maybe it's a new employee, somebody coming or going. Whatever it may be, it may be a change in a cloud environment. I mean, all of these things are happening on a daily basis and so you are never done. But the point is, do you come in and all you're going to do is focus on one tool that you know? No, you should really have a more strategic view on approaching security in an organization. Maybe you start with the threat modeling, maybe you start with a framework of security evaluation. There's always questions of prioritizations and trade-offs, because ultimately and I know this is a little bit of a cliche security is a risk management thing. 

‍

The most secure organization is the organization that does nothing right, generates no data, processes no data, has no data right. But that's just not the reality. You always have to work with data and with people, and so it's always just a question of what trade-offs you want to make, and so you need to think about that. And the second thing in my mind is the creativity and the troubleshooting capabilities. 

‍

So, to your point, your experience doing help desk I'm sure you had a number of times when somebody came and was like, hey, it doesn't work, gives you the least useful information that they can give you, and then it's your job to figure out why. And you end up going through this troubleshooting exercise of eliminating possible causes. I actually think security has a lot of that as well, and when you've checked everything, then you just need to think more creatively. What else could it be? And, by the way, we all know most of the time it's a lot of the basics it's DNS, it's update to the latest patch version, whatever it's, reboot the machine. We all know that from experience over time. But yeah, I don't know. I don't think the fact that you do or don't know a tool should ever qualify you or disqualify you from a job.

‍

Joe South

‍

Yeah, yeah, I definitely agree. So you mentioned a couple breaches. Why don't we talk about the breaches? Maybe if you could talk about where you were, what they were, how it happened and what that environment was like, because I feel like this is a known thing slash risk with security, and very few people actually go through a very legitimate breach, and so it's difficult to imagine it, it's hard to go through to know what to do. Even it can be very stressful. It's kind of like a fog of war almost, and so I think hearing that would be very helpful to someone out there, especially myself.

‍

Jeremy Snyder

‍

Yeah, so I've had three in my career, two that were kind of larger than the others. The one that was the smallest is probably the easiest one to talk about. It was an internal wiki that, through one network configuration change, got made external, and it got picked up very quickly. 

‍

We were doing a lot of social media marketing at the time, trying to work with bloggers and so on, and there was some stuff on our wiki that didn't paint the bloggers in the best light, that got out there and got copy pasted and screen shot it and posted on other bloggers sites and so on. It was certainly a black eye to the organization. Thankfully, nothing beyond the marketing side and some customer support documentation got shared externally. We were able to dodge the bullet. The reputational damage, though, was pretty tough to deal with, and certainly the possibility of working with some of those bloggers on, let's say, like content placement or content syndication. That was all gone. That ship had sailed. There was no chance that these people were ever going to consider working with us after that point, and that took some time to repair and certainly forced the marketing team to go okay, what's plan B? What are we gonna work on next? 

‍

And it does show you that this was kind of one of the first kind of virtualized environments that I worked in, so this was a lot of open source software. We were using Media Wiki at the time for the internal documentation, the same platform that Wikipedia is built on. Decent open source package has its own set of issues, as many of those large scale kind of public facing things, especially ones built in PHP, do. We had relatively good practices around the Wiki itself and so there was nothing on Media Wiki itself that was a problem. It was really just our network configuration that caused this exposure. 

‍

So one of those things is, whenever you consider a network change, what are the implications? And I think a lot of people don't have the awareness. A lot of organizations that I go talk to. If you ask somebody the question what happens if I change this one firewall rule or this one IP address or this one load balancer, pointing from which instances to which instances, like what's gonna change, what would then become exposed? I still think a lot of people don't have that visibility. That is something that I think a lot of security teams struggle with. The other two were worse. They were at that first company that I joined, where I worked my way up through IT. This is again kind of the late 90s, early 2000s time frame.

‍

One of the things that we ended up having to build for our customer support organization was an anonymous FTP upload server. So we had customers working on very large documents, probably dating myself a little bit. But there were desktop publishing software packages, mostly from Adobe. I think none of them exist anymore, but you might hear of like page maker, frame maker I think InDesign is the new tool that's replaced all of that kind of stuff. Quarkxpress was another product in that same category, or then sometimes they were just like really large word files and back in those days most email clients couldn't do anything more than maybe a three to five megabyte attachment and we very often had customers that had documents that were well into the hundreds of megabytes. They would have problems using our software with those documents and they would need to upload those documents to our customer support team. 

‍

So we had an old server that wasn't really used for any other purposes and we said, hey, this will be great, it's got reasonably large raid on it. We've got about 25 gigs of disk space on it that are completely unused. Again, 25 gigs was big back then, by the way. So we set up this server to be an anonymous FTP server so you could connect an FTP client. You would not get a directory listing, so you couldn't see any of the files. You couldn't download anything. If you tried to list or download, you would just get an error message. But if you tried to just put a file that worked and that was by design and so then you would submit, you as a customer would submit your support case and then give your file name. Now the fact that it was an old server is actually where one of our biggest problems started. So it didn't support Windows NT4. So we were still running NT3.5, I want to say or 3. Can't remember what version. Everything was 8.3 nomenclature, meaning file names, max8 characters, extension, max3 characters. 

‍

What ended up happening was there was this vulnerability in that Windows version where if you created a folder that let's call the folder dash so just the hyphen symbol and then you create a subfolder of dash called double dash and you create a subfolder of that called triple dash, well, once you go down and you surpass 256 characters in total path length, none of the permissions work anymore. So it completely broke the Windows permission structure. So some people knew of this. We obviously didn't. So what did they do? They uploaded a few gigabytes of pornography, shared the links and, because it was so deeply down this path structure, the download permissions that we had prohibited were all of a sudden available. Now, we got notified of this when we got our bandwidth bill from our co-location provider at the end of the month. And for an organization that averaged roughly like four gigabytes of bandwidth utilization at that site, all of a sudden we were in the 200 range and thankfully we were able to show them hey, it was this breach event and thankfully they didn't steal data from us, but they did abuse our systems to distribute illegal content. What can we do here? And they gave us a break on that. 

‍

But it's one of those things that to me, that actually showed me that we were doing a terrible job of monitoring our own systems. So we didn't have anything in place to check bandwidth utilization on a regular basis or even to really monitor the disk drive space. It didn't fill the disk, but it certainly used a huge chunk of the disk and we weren't monitoring that actively at the time. So it's a little bit of a live and learn lesson. So some of these basics that you need to think about, even just checking in. If you're using servers as servers, as long-lived servers and not ephemeral instances, you do need to check in, you do need to put these monitoring tools in place. And so, yeah, those are two of the big ones. 

‍

The third one was nothing really major, just the usual email virus did send some documents from people's inboxes. People may have heard of the Melissa virus or the I Love you virus from those days. We got hit with a couple of those and most of them just created huge volumes of email traffic. Some of them would send documents from your send folder. They would forward them outside. Nothing huge there, thankfully, a few documents that went out, but mostly just clogged up our mail servers for a few days and that virus would then flare up again from time to time. Somebody would come back from vacation, see it in their inbox and double-click the document with the word macro. That kicked the whole thing off again. So it took a while. We ended up having to go into the exchange server and go into people's mailboxes one by one across the organization and make sure that there were no copies in anybody's email anywhere. Yeah, those are some of my fun stories.

‍

Joe South

‍

Yeah, the only breach experience that I have actually and it wasn't even my environment being breached when I was working at a credit bureau, equifax happened and obviously I wasn't working for Equifax, I was at a different place but there was so much fear in the space that we literally got a blank check for the first time ever from the CEO just saying whatever you need, just get it. If you need to hire more people, you can do it. Our team size quadrupled almost overnight. Within the next few months. We were hiring several people and in security that's unheard of. That is something that you do not expect. That is extremely difficult to pull off, even just hiring those people, and that was a really interesting time. 

‍

There was a lot of fear around it and, to give credit where it's due, the security team knew that and we knew that we had to use that opportunity as the opportunity to get some of the tools that we've been trying to get, to get the headcount that we've been trying to get, and I remember one of the architects was discussing how much money the breach actually cost Equifax and the number that they could come up with. The dollar amount right was in the billions, something like that, but the damage to the brand itself was almost incalculable, because now I bring up Equifax and everyone remembers that breach it was on morning news telling people go lock your credit reports and everything else right, because they have all this data. There's nothing we can do about it. They just have it and they sell it and they reuse it. It really almost opened Pandora's box to the credit bureaus in a way that people didn't really notice. They didn't even know about it or think about it beforehand. So it was a very interesting time for sure. Yeah.

‍

Jeremy Snyder

‍

And I'm curious about your experience going through that. When you kind of got this blank checkbook, what did you do first?

‍

Joe South

‍

Yeah, I think what we did first was we actually bought two different technologies for the IEM team, which was sold in a way that like, hey, if Equifax had these, the breach would have been impossible, Right. So that was like a no-brainer for the organization to do. And then we built teams of 12 or more people around these tools to run them for the entire organization, which was challenging, right? Because then you're questioning the talent that you're actually hiring, the people that you're bringing in, how you're bringing them in and all this stuff. 

‍

And then we ran into challenges where we had more interns or people fresh out of college than we had people that were actually two to three years in IT overall. I think at one point I was the only person on the team that had prior IT experience, and so when you build a team like that in security, I mean it's different, right. You're restricted with what you can actually do, what you can accomplish and pull off and whatnot.

‍

Jeremy

‍

Yeah, that's interesting. I'm curious, then you know, to follow up on that. So you bought this IEM tool that was sold as if you had this. That couldn't have happened. But after you implemented it, did you have that same conclusion? Did you believe that that was true?

‍

Joe South

‍

So I understood where they were coming from and you know they weren't the only solution on the market, that's for sure. If their solution was working you know, 100% of the time, the way that they claimed it would be working then, yeah, it would have been the right tool for the environment and it would have done what they wanted it to do and things like that. But you know, to be quite honest, the solution that we bought, due to, you know, external circumstances, right, it was just the wrong solution for the environment.

‍

 And so you know, there were key people in my org that, basically, you know, hitched their horses to this wagon and they were going to. They were either going to succeed or they were going to die with it. And they ended up, you know, not actually dying with it, but they died with it, you know, and it created a lot of issues, a lot of heartburn, you know, for basically everyone in the org.

‍

Jeremy Snyder

‍

I've been on the vendor side of security software for about seven, eight years now and the thing there's a couple things in what you said that really kind of stick with me, and I think anybody who says that their solution is bulletproof or is the silver bullet to solving this and preventing the next one and so on, is like if anybody who hears that should know that that's marketing, speak right and to your point. It may be the right solution or it may be the right category of solution, but if it requires that you change the way that your organization works in order to use it, I think its chances of success are very low within your organization. I just don't see a lot of the customers that I've worked with over the years saying, well, you tell me how to run security or how to run cloud over here at you know, insert corporation name, right and I just don't think that's realistic. 

‍

You know, when I joined a cloud security posture management company in 2016, and we were in the very early days of cloud security posture management, right and there was this big debate going on about what's the right approach quote unquote right approach to cloud security. Is it CSPM, which by nature, is kind of a let's observe what you're doing. We'll just kind of watch what you're doing, gather that up and then show that picture back to you with an assessment of what's good and bad as either defined by whatever number of standards, like this cybersecurity framework, cis, benchmark, whatever, or some rules that you yourself define. 

‍

Or is it this CASB approach? Right? Casb was a very hot topic at the time. You know, cloud access security broker, where you're only going to use the cloud in a way that this CASB tells you is okay. So some security team in theory would come along and define like, oh okay, you know, joe, he's with the development team and they have access to this, this, this, this, this here's a set of rules for what they can and cannot do. We're going to translate those rules into, like AWS, iam policies or VPC constraints or what have you right, and as long as you kind of color within those lines, you're fine and so it's. You know, does your organization continue to run and were they are observing it? Cspm approach or do you take this thing that prescribes to you how is you know what good cloud usage is and you change everybody's workflow to adapt to that. 

And I can tell you, like in those days what we observe time and time again not to cast aspersions on CASB vendors out there, but no company was going to change their operating model in order to accommodate this cloud. It just was not going to happen. Why people have day jobs, they have stuff that they're trying to get done and nobody's day job is to change the way that they're working in order to onboard this new vendor offering. Like nobody's even in the security department that bought the thing. That's not really anybody's job description, except maybe one or two people who are on that project team. So I feel like there's a common problem that we have as a security industry that we try to sell a solution to everybody and anybody who will buy it, regardless of whether they're actually the right fit or whether they're going to get benefit out of it. 

‍

And I can tell you, as like an early stage security company, that's a dangerous temptation, because of course, we all want customers and we want revenue and we want to be growing. But worse than having the customer it worse than not having the customer is having the customer that doesn't like the tool, that goes away with a bad experience or that churns after one year Because you've invested all this time and energy in cultivating the relationship and getting them on board, and then they're just going to walk away. And you know, maybe you've educated them on a new space like API security, like we're doing, but then they didn't like your approach because your approach required them to change and so they're just going to go to some other API security vendor who doesn't even have to really pay much to acquire the customer, because you've educated them on the market, you've educated them on the attack surface and the problems and so on. So I just feel like that's a bad temptation and a bad behavior that we as a vendor community have.

‍

Joe South

‍

Hmm, yeah, that is definitely something that I have experienced personally, so is that experience what you would say led you down the path of starting Firetail? Let's talk about the tech a little bit, maybe why you got involved with the company and what brought you down this path.

‍

Jeremy Snyder

‍

Actually, what brought me down this path was my experience doing Cloud Security, so a little bit less those kind of vendor things. I learned those lessons along the way. But the previous company, Divvy Cloud we were that early stage CSPM company. We grew very rapidly for a four-year period before being acquired. Partway along that journey I started working with some of our larger customers digital natives, global organizations and you started to observe how they were changing the way that they use Cloud. So now every year we go to re-invent or whatever Cloud conference you're going to go to and you hear from the CTOs and the CIOs about how they've really changed the way that they're operating their IT environments. The consistent things that you hear are like we're moving away from long-lived servers. We're doing cattle, not pets model. You'll hear that pets versus cattle analogy a lot in the Cloud space in general. 

‍

Really, what it comes down to is like a virtual machine on a Cloud network is not a server and you shouldn't treat it like a server. What is it? It's a temporary computing node that provides CPU memory, maybe a little bit of disk access in order to process a workload, but it should be ephemeral and it should be treated as ephemeral. 

‍

We really started to see that behavior from a lot of our large-scale customers, especially, again, those Cloud native customers. We'd ask them like and I'm much more familiar with AWS and the other Cloud providers, so excuse me for just using their lingo but we'd ask them what are you running on EC2? They're like as little as possible. In fact, we want to get everything off of EC2. You say, well, what are you going to do instead? Containers and serverless. Why? Easier to be ephemeral, lighter compute load. We can actually cycle things in and out much more quickly. Guess what? I don't have an operating system that I have to maintain. I don't need to install agents. I don't need to install an EDR agent or a management agent or an APM or any of that stuff. I'm just going to run my workloads on Lambda because, guess what? The vast majority of them fire up, run for 15 seconds, then wind down. That's how I should be using Cloud. That is the dream and the vision that Werner Fogels and everybody else tells me about every year. 

‍

When we started seeing that shift, one of the things that I realized in my conversations with some of them was that's going to dramatically change the architecture. If it changes the architecture, what are the implications? What becomes the target? It moves away from being that EC2 instance and then it becomes an API sitting on a network. Whether you're running Lambda, whether you're running Fargate, eks, ecs, I don't care, you're going to have an API somewhere. Chances are very high that API is going to be in front of a dataset, in front of a set of business functions, or both. That becomes your attack surface. That's what started me thinking about API security. I started thinking about this problem a ways back and started working on it after I left Rapid 7, the company that acquired us. That's really the journey. 

‍

When we started Firetail my co-founder and I we actually started by not having a piece of technology that we then wanted to build around, but we actually started by doing root cause analysis on all of the publicly disclosed API data breaches that we could find. There weren't that many at the time. We've now consolidated them all. If you look on our website, firetail.io, and the footer, you'll find an API data breach tracker, we call it, where we've put together a list of all of the ones we could find. There's been 40, 50 of them large-scale over the past 10 years that have been publicly disclosed probably far more than that that have not been disclosed. That tends to be the case. 

‍

What we realized was that the problem has actually not only has the attack surface moved, but the problem has also moved. It's become less a problem of, let's say, accidental data exposure, which is still one of the main problems on Cloud environments, and it becomes an application logic problem. It becomes things like abuse of poor authentication mechanisms or lack of, let's say, follow-up call authorization. I authorized you once, but then I assume that anything you request after that, any of your subsequent API requests, are also authorized. Very bad practice. You need to authorize every single call, but we saw things like that time and again. We actually started from that standpoint and we built out tech to match that. Then we followed requests from customers to continue to evolve what we're doing. 

‍

We actually ended up adding a completely new set of features and functionality based on some of our early beta customer feedback. That's been a great learning journey for us, but yeah, that's how we got started.

‍

Joe South

‍

Hmm, that's interesting. Moving to containerized environments, I mean it's difficult. I feel like it's easier said than done and a lot of companies or people don't quite understand the work that goes behind that, Because as soon as you throw an agent on there, you're eating up more utilization and you're spending more money on the solution than you would have been. It's a considerable amount too. Throwing an agent on something, to secure it or gain insight is a legacy process. It's a legacy solution. The industry as a whole is having to learn new ways of how to actually gain insight into these ephemeral workloads.

‍

Jeremy Snyder

‍

It's difficult for sure, yeah, For sure. I think to that point, Joe, you'll find people shifting a lot of their security efforts away from, let's say, the runtime monitoring that you might get from an agent into secure build. What all is in my pipeline? Have I done code scanning? Have I checked my third-party dependencies? What about all these third-party containers that I'm including to build my workload? Maybe I'm grabbing Nginx as a reverse proxy? Am I grabbing the right version? Is it the most secure version? Is it the compatible version? All of those types of questions. 

‍

They almost become more of a to use the buzzword, Sbom type of problem than they do a runtime problem. Especially if they are more ephemeral workloads that aren't going to be out there, or where you've got a lot of code updates that are pushing new versions very regularly, the secure build aspect becomes maybe more important than the secure runtime aspect. But that is a challenge and that is not something that a lot of security teams do, especially because who owns the build process? It's often not security. In fact, 99% of the time it's not security, it's developers. I don't know how it is where you work, but I've certainly observed my share of organizations where security and developers don't always see eye-to-eye.

‍

Joe South

‍

Yeah, that in and of itself, I feel like you need a security person that used to be a developer that converted to a security team. It's actually like speak their language and break down those walls and barriers, because it's a difficult I mean it's a difficult experience to bridge. It's a difficult gap to bridge, with someone coming in and saying, oh, we should restrict this in this way or do it a different way, and the developers had it's like have you ever been a developer before? Do you know what you're talking about? Do you understand why we did it this way, something that is pretty difficult for myself even and, thankfully, my current employer. We have an app site guy that is primarily a developer that is just having a security focus, and even at my last employer, the entire app stack team was former developers that you know wanted to have a security focus and they created this team around them. I really feel like that's the only way to really do it successfully, because I've I've tried it just about every other way and it just doesn't work.

‍

Jeremy Snyder

‍

Yeah, it can be really challenging and I think like, thankfully you've got this app stack person in place that's able to maybe kind of bridge the gap and speak the language of both sides. But I find that even you know, on the most basic level, a lot of the times the organization is not set up for success because the, let's say, the KPIs or the targets are very different. You've got a development team for whom security is, at best, a secondary responsibility and at worst, not even on their list of responsibilities. They're tasked with delivering features and they've got, maybe, time pressure, they've got pressure to release, because why you're in a competitive market and management says we need this feature to be competitive or to be ahead of the competition or whatever. 

‍

And they've got, you know, their bosses breathing down their necks to deliver, deploy, deliver, deploy right, and nowhere in that list is security. And then you've got your job, which is keep the organization safe, and so sometimes even just the basic kind of misalignments at the organizational level I've seen can really cause a lot of strife, and that's really unfortunate, because nobody wants to ship insecure codes, nobody wants to open the organization up to vulnerabilities. But when you create these systems that don't have a holistic view. I think that's a pretty, you know, poor management structure.

‍

Joe South

‍

Yeah, absolutely so. Where do you, where do you envision this space going? Cause it seems like you're taking this approach from a different angle. That I mean personally. I would like to see more solutions. Approach it from. Where do you see it going?

‍

Jeremy Snyder

‍

So we came to API security from cloud security, and one of the other things I observed aside from, let's say, the architectural changes on the cloud security side was that I saw the customers that we were working with struggling to implement cloud security because of any number of reasons, but one of the big ones was, a lot of the times, once security comes to the table, on the cloud security side, development is way out ahead. A number of workloads are already out there, Applications are already running in production, et cetera. So a lot of these customers that we would work with, let's say, on a POC process or whatnot, one of the very first things they would do on the cloud security side is they would say, okay, great, now I have a picture of my entire cloud, let's say a state. Help me now slice it up and break it down into manageable chunks, like application workloads, and that I saw really becoming like a consistent theme. 

‍

So, company after company, customer after customer, we would see like the first set of workloads it would be like, hey, help us manage tags or help us create these structures that we can then measure security against, because it's not one size fits all. You've got a different risk profile for different workloads depending off their internal, external, what data might be in them? Do they have customer PII in them, all these types of questions that might be in the cloud security side we change the security requirements for them. So what I see happening is I think it cloud security will continue to go that direction, and so you know people like you who work in cloud security day to day. I think, whether you're there already or not, or whether you're going to get there in the next couple of years, I think you will get pulled down the direction of slicing your cloud security practice up into manageable workloads, namely applications. What we've seen from the API security side is that cloud security is starting to encompass everything that kind of sits below the API. 

‍

So infrastructure layer, identity and access management, operating system, especially for things like Kubernetes, clusters that's all kind of part of a cloud security platform. Nowadays, you talk to any of the now called CNAP vendors CSPM is very last decade, right but you talk to any of the CNAP vendors and they'll be able to give you all of that. What they're missing is the API security piece on the top of it, which is a really interesting intersection of data, business logic, application functionality and external exposure, and so our goal with what we're doing at Fiertail is to make kind of the discovery of APIs very easy and then something that you can take and integrate into a cloud security program or an application security program. Also make it so that you can deploy controls for some of those types of or some of those top attack vectors that we've observed. 

‍

So can we do good authentication and authorization checks, can we give you good visibility into when API calls aren't looking the way that they should relative to some of those risk factors. That's where we're trying to take it and we're trying to make it a piece that is very easily consumed as part of a broader kind of cloud slash, cloud app, sec program.

‍

Joe South

‍

Yeah, it's a very interesting take and I wish that we had more time today to talk about it, but that just means that I'll have to have you back on to talk about it more in depth. Well, jeremy, yeah, absolutely Jeremy. Before I let you go, how about you tell my audience where they could find you if they wanted to reach out, where they could find Fiertail and all that good information if they wanted to learn more?

‍

Jeremy Snyder

‍

Yeah, the website's real easy. We are just Firetail.io. I am just Jeremy@Fiertail.io, so very easy to get in touch with me. I have a Twitter handle, but I won't even share it because I never use it. The company has a Twitter handle which is Firetail_io. We're not super active on there, so I would say email is probably the best way to reach out to us. Last thing I'll probably mention on that side is not a lot of people are super aware of API security and the risks that it might pose. So one of the things we've tried to do is to really summarize some of that root cause work that we did at the beginning of our own journey. So if you go to our website now, across the top, you'll see the state of APIs in 2023. There's a free download report there That'll tell you some of the analysis that we've done around API security breaches, what went wrong in those situations, et cetera. That's a great place to get started if you're looking at the space. Otherwise, just reach out anytime.

‍

Joe South

‍

Thanks, Sherry, for coming on. I really appreciate our conversation, Really enjoyed it and I hope everyone enjoyed this episode.

‍