Humans of InfoSec Episode 69: Inside the Mind of a Developer

Will: If the security professional just says, "Oh, this is a CSAF issue and you need to do blah, blah, blah." When you tell that to developers, that's a work item. If you go over there to them and you go, "Hey, I found this thing, take a look at this." And you let your nerd flag fly and you walk them through what you did, the developer is now on your side, right? Because they saw your eyes light up, they heard the tone in your voice, you know, because we're pretty attuned honestly, to other people who are very, very interested in something, even if it's not something that we like because we recognize that feeling. Because that's why we're convinced to sit in the basement somewhere, looking at a screen all day. You know, that's the thing that brought us here, and so we recognize that, and when we see it in other people, it makes us more empathetic to where they're coming from and stuff.

Caroline: From Cobalt at home, this is, "Humans of Infosec." A show about real people, their work, and its impact on the information security industry. My guest today is Will Gant, an accomplished developer, author, and software architect. He's been interested in computers since grade school and he made his passion for technology official, when he decided to major in computer science. He hosts a podcast called the "Complete Developer," which he describes as buy coders, for coders. Will is writing a book for new developers to help them be successful in their careers, and he writes at gantsoftwaresystems.com. He is self-described as a cross between, "a giant dork and a weightlifting hillbilly." And in his free time, he makes homemade wine, mead and cider, among other hobbies. Will, welcome.

Will: Thanks.

Caroline: So, how's it feel to be on the other side of the podcast table?

Will: It is somewhat strange. I've done quite a few, but it is always kind of odd to not be the one asking the questions, and to not have to write the outline. Because, you know, we do ours every week and so there's kind of a mad rush on, you know, Sunday and Monday to try to get an outline together, and have all the pieces and, you know, have the other guy approve it, and it's way better this way. I wanna say it's easier.

Caroline: Cool. Well, sit back, relax. It's kind of like being a guest at a wedding, right? Just get dressed up, show up, and have a great time. So, today we are taking the humans of the InfoSec podcast in a slightly different direction. I usually have InfoSec people on the show and today we've got a developer. Will, welcome. Introduce yourself before I tell our listeners why we've decided to mix things up and bring a coder on with us.

Will: Okay. Well, I'm a software developer. The first time I got paid to write code was in 1998. And I think that code is actually still running and maybe older than some of my coworkers, which is a very weird feeling. I've always really enjoyed computers. I thought it was the coolest thing in the world to be able to basically tell the machine to do something for me, and then it does it. You know, and I saw my dad kind of do similar stuff with mechanical things in a greenhouse, right, with turning on the water and those kind of things. And I always thought that was really a neat process. Not only how he designed everything, but how he hooked all the pieces together and was like, "Okay, I've got this vision and I'm messing with something that looks nothing like that vision, and I make that vision happen."

And, you know, it's kind of the same thing with me, with software development. So, I grew up basically, the best way to put it is out in the sticks, but it was at the end of the power line. So, we were way out there. And, you know, my dad had a couple different businesses, he had a nursery and then he had a oil distributorship. So, I got to go in and play with the computers at the oil company. I guess it was probably more junior high, because he had me like in the office doing stuff. So, I've always had some degree of computing in my life. I mean, we even had a TRS-80 when I was a kid, which probably, well, I would say that dates me, but I'd say starting to get paid for development in '98, probably does as well.

And, you know, I got on through college, got a software development job, was pretty happy and content there. And then my best friend was in med school and went through a pretty serious personal crisis. And it resulted in him basically, you know, leaving med school, and his marriage fell apart, and there's a bunch of other stuff that happened. And when he was trying to recover from all this, you know, we were kind of talking to him and we were trying to keep him busy because he had been on a med school schedule. So, we're like, "Okay, he is used to perseverating on something for 16 hours a day, what do we do?" And it was me and a couple other developers sitting at the table and we look at each other and we're like, "Oh, I know." And he had already done some programming like in high school and had, you know, gotten out of it. And we started talking to him. He's like, "Yeah, I think I'd like to do that again." And so we got him back into it, initially, to keep him busy. And then one day he started asking harder questions and we're like, "Okay, we've set the hook now because he's enjoying it." And he's like, "I think I wanna do this for a living." And that's my partner on the podcast and he's a senior developer as well.

So, the thing that really interested me, you know, recently, is that it's not just about the tech, but it's like, I can change people's lives in a really, really positive way. Like I've got a tremendous amount of leverage as a developer for doing good things. Of course, a lot of, you know, developers have a tremendous amount of leverage in doing bad things too, which is something you're probably aware of in the security space, but that, you know, kind of led me towards writing a book. I've got two books out and I am actually working on another one, although it's not for entry-level developers anymore. The first one was on, surviving whiteboard interviews for developers and then the second one was on, "Remote work." And, you know, both of those things were, here's how to make a transition in your life that is meaningful and makes it better. So, yeah, I went on a rant. Sorry, it's a Gant rant.

Caroline: I love a good Gant rant. Keep the Gant rants coming. You know, I think that you touched on something that is so fundamental to human life, really. You know, there are things that our lives that we cannot control and there are some things that we can control. You know, there's something so natural about watering a plant and watching it grow. There's something so satisfying about writing some code and watching it work. I think that, you know, I love a good doctor turned software developer story. And I couldn't agree more that, you know, we and technology, we do have such a tremendous ability to do good. You know, software at this point, it's an unavoidable part of my life. I interact with software the majority of my day, every day. And, yeah, I think that's cool. You know, the way that I think about software, being in cybersecurity, is that the job of cyber security folks is to protect digital value, and it is developers who are creating that digital value. I've spent tons of time thinking about the software development life cycle and the interactions between InfoSec professionals and devs, and I'd really like to hear about your perspective on what those relationships look like.

Will: It's interesting because I have worked in places where the InfoSec person with somebody we never met. It was some dude at the end of the line that ran Burp Suite on our stuff and told us where we screwed up, with no real guidance on how to fix it. It's just like, "Hey, you failed." And so that wasn't helpful. And then I've worked in places where either it was former devs or there was actually like a real, you know, actual security professional in the building, and those were some of the best because what those people did... Well, I guess I'll back up. I think software developers, you know, because we're in the creative aspect of things, to a large degree, you said, you know, we're creating value, but we're creating castles in our minds, right?

But we're not thinking about, okay, somebody's gonna storm that castle. You know, we don't have a model for that, which is, I think one place that the security professionals that are really good, they come in and they give us that. I worked on one system and it's been many years ago and actually, this was one of the turning points I guess for me, was working on that system because I had some very positive people around me, where I actually found a security hole. And it was a form that people could get to, they could log in, and they're changing their credit card information. And there was a validation control there to say, okay, this card number's valid. Well, if they're entering a new card, you know, there were PCI-compliant, all this stuff. But if the card information was already there, you know, instead of shipping just the last four digits, they needed the whole thing for that validator to work, and some developer put that there. And so it would hit a rest end point and get that card info.

And that was coming down to the client and it's like, well, you know, you might think that that would work, the problem is that, if that person is not who they say they are, you know, they got a, you know, breach password or something, and they're in there, now they have somebody's credit card, you have an escalation of privilege type situation. And, you know, I looked at it and, well, you know, I looked at source control and I was like, "Okay, who wrote this?" And I looked and it was the best developer on the team, like by far. And then I kind of sat there and I'm like, "Well, I gotta tell him." And I did, but, you know, that particular job was interesting to me because I started looking at stuff and going, okay, if I see bad code, I stopped saying, its bad code, and I start saying, how did I get there? Or how did he get there in that case?

And I realized, you know, his problem wasn't that he was a bad developer. You know, he was a very good developer. I learned a lot from him. The problem was, you know, he was working on the thing he was working on and, you know, it wasn't in his head, "Hey, if somebody's coming in here and they're already doing something malicious, what happens?" You know, in other words, he did not have an effective model of evil for that situation. And I think that's the biggest thing that a security professional can give to developers is because, you know, we're looking at the creative aspects and, you know, we have to be focused on that.

We've got our user personas. We go, "Okay, Sally's an accountant and she's better at Excel than anybody, you know, and she can do this and this and this and this." And then, you know, "Bob is a welder and he hates computers and he's just gotta get in here to put in inventory every so often, and he's trying to get in and get out and he's gonna do these things." Well, you know, those are user personas and we go, "Okay, here's effectively their security access for different things and their, you know, what shows on the screen and all that." But we never think about what if somebody's impersonating Sally, right? That's a third person, a third persona that is actually in your system that you are not aware of as a developer, most of the time. And as a result of that, it's very easy to impersonate somebody and get into something that you shouldn't because the developers weren't thinking about that, they weren't thinking, "Okay, if there's a destructive action that Sally can take, I need to actually make sure that it's her right before that action happens." Not just a login and trust, if that makes sense.

Caroline: Yeah. Makes perfect sense. You know, and I think it's so interesting because with this sort of creative mindset that a developer is in, as they go into to make something, I wonder, you know, what is it like for you, Will, kind of, I wonder if it's fair to say, think of yourself in a state where you only considered the personas that were assumed? And then, you know, you're talking to me here on this podcast, you're describing some scenarios to me, it's clear that you totally understand that, you know, someone's account can be compromised and they can act maliciously. Do you then move forward thinking about that as either an additional persona or does that change the way that you think about personas? Or, you know, I wonder if it's one of those things you kind of think about all the time or if you don't, unless a security person brings it up? I'm just honestly curious about what that experience is like for you.

Will: I think it is very similar to early 20th century food processing, right? They new microbes were everywhere, right? And so, like, in a food processing system, you don't go, "Okay, there's no bacteria here." You have to clean it. There will be bacteria, it's in an environment. And I think I have that awareness as a developer, after that incident and several others, you know, like, that's always in the back of my mind, it's like, "Okay, somebody could be here, that shouldn't be, you know, what is my defense in depth here?" But I feel like the techniques are not caught up yet. And so it is like early 20th century food processing, where there's some bacterial problems, you know, like, there's areas where we don't see things, we go, "Okay, I'm securing the API and I trust it, but I have some connection to some microservice, you know, on the back end, what if it gets compromised or the communication channel gets, you know, compromised. You know, what are my mitigation strategies on that?" And I think that's an area that developers are still pretty soft on.

You know, when we secure systems, we tend to make the assumption that there is a wall that is impenetrable at some level. And once you get inside that wall, everything's completely safe. And that's not a true assumption, especially, you know, now with remote work, I think that's one of the things that is really getting some people's attention. Previously, you know, I worked at a company where, you know, they had a firewall, they had really restrictive rules and what goes in and out. Inside the system, everybody knew everybody else's passwords. And, you know, by the way, that's how security was done in the '90s, right? It was pretty horrendous. Just looking back on it, it's a wonder that we have a civilization. I mean, really like I think about stuff and...

Caroline: It's true. It's true. I mean, and, you know, it's not really as though things are so much better today. I mean, the first ransomware attack I think was in, what, 1989 or something, and here we are in 2022, and the big question is, you know, what's gonna be the next target for a ransomware attack. So, there are things that have not changed. And it makes sense. You know, I wonder, Will, if you'd...we've talked a little bit about some of the characteristics of developers, you know, kind of broadly speaking, you know, on this podcast, I've had opportunities to talk to tons of people in cybersecurity, and I'd say, generally speaking, these folks, they love technology, they love to play with stuff, they love to learn, they love to break things. You know, they love to be in an environment that's changing all the time, where every day presents new challenges. I wonder if you have a way that you think about or that you describe folks in the developer community. And I also wonder if that community from your perspective has changed, you know, over the years.

Will: Well, there's definitely a lot of crossover. You know, we always like to tinker. I mean, before we got on this call, you know, I was telling you, I'm about to mess with my recording stuff on Linux because I'm trying to get that working. You know, I've got a NAS here at the house, I've got my own network set up, I've got more stuff that I don't need in this room right now to play with, you know, these are my toys and I think that's a developer characteristic. I also think it's a characteristic of pretty much anybody that's in tech. I don't know that that necessarily draws people to tech. I think the lack of it just means that you don't stay long. That's sort of the way we are as a group.

I would say in the '90s and the, you know, 2000s and even in the 2010s, it felt like stuff was not changing as fast as it feels like it changes now. There's a security landscape that is obviously shifting all the time and there's, you know, platform changes. There's all the cloud stuff. We have, you know, large numbers of people now working remotely. So, you know, the old-fashioned, you know, like my firewall is my company's castle wall doesn't work anymore because there's Trojan Horses going in and out all day. You can't do things that way anymore. And it's, it's interesting watching people adjust. I think the part I like the most is the fact that there's always something new to learn, but that you can build on expertise. You know, if you know old systems, a lot of times they're underlying the new systems.

I run into stuff at work now that, I mean, I've had to troubleshoot some things at work that I learned how to deal with in probably the, you know, mid to late '90s, like when I was learning how to code, you know, low-level graphics API stuff. You know, then again, my best friend is messaging me right now about an angular problem that I don't have a clue about. I don't know why he's messaging me, but he is. And I like that mix, you know, we, we can all grow in it. And I really think that the security professionals and the devs, it's almost like the same people, but they're pointed at different objectives. And I think that's the source of most friction because the developer is like, okay, I gotta deliver this value and, you know, who's this guy over here? What is Burp Suite? What is this thing? You know, that's the main tool, it seems like that gets used against me. But, you know, that's what the developer perspective is. And then the security perspective is gonna be like, "Hey, these goobers are putting something out here on the open internet and it's gonna get breached. Like they're not looking at anything."

And those two perspectives can be across purposes, especially when you have weird organizational patterns that are going on that says, "Okay, we're gonna treat these two people like two different teams, versus they're integrated on one team, and, you know, the team is going together." You know, we learned this with QA and software development. You know, it used to be QA was a different department and, you know, they would beat you up on your code. They're just like, "Oh, you know, you're awful. And your stuff is breaking all the time." And, you know, there was some hostility there and the best teams I've been on, the QA has been integrated into the team. It's like, that's just part of it. You know, they're there to watch your back and you're there to watch theirs and you're working as a single unit. And I feel like from the security perspective, you kind of have the same thing going on there, if that makes sense.

Caroline: Yeah. I mean, gosh, there's just something so fundamental about when we feel like we're in a social situation, where we're working against someone else, versus when we're working together. I mean, it's just different. And maybe, you know, it's so interesting because certainly a lot of the security folks I know, certainly a lot of the dev folks I know, love technology. You know, and when it comes to security folks, dev folks working really effectively together, sometimes I wonder, you know, what makes the difference in some cases.

Because I'll talk to folks like yourself, right, and I'll hear folks say, there was this one time and this person was very difficult to work with, you know. And then I'll hear another, and then there was this other time and this person was such a pleasure to work with. And it's like, what's the difference, you know? And I wonder, I'll go ahead and say, "I think that for security people, sometimes there are soft skills that can make all the difference in terms of getting folks to partner and collaborate and work effectively with each other." You know, I wonder what that looks like from your perspective on the developer side. You know, is there an advantage to a developer honing their soft skills?

Will: I would say there is. Actually, I'm friends with John Sonmez, who actually wrote a book on software developer soft skills and his company actually published my second book on, "Remote work." And I've found that the developers that don't have soft skills, it doesn't matter how good they are at the code, there's a plateau that they hit in their career and they can't get past it. And that plateau is defined by what they're capable of doing by themselves, which is usually not enough, you know, these days. There are so many layers to applications and so many different disciplines involved, that if you don't have soft skills now, you can't make it. I mean, back in the day, you made a battleship gray, visual basic form, and it talked directly to a database and you knew about those two things. You didn't have to worry about the web, you could get by. Now, you really can't.

And I will say that, you know, you're saying some security professionals don't necessarily have soft skills, developers have a reputation and we are known for not having them. Because you got a lot of people, I think honestly, that got into the industry because they didn't like dealing with people, but they could deal with the machines. And you know, you get a certain distance in there and that absolutely works, but past that point, it doesn't. And when you talk to those people and you kind of make it clear, it's like, "Hey, you know, get some social skills, learn how to play office politics, or at least how to not get played by office politics," and let them have one or two victories on that, and they're sold on the soft skills. But when it sounds like marketing stuff, they don't wanna have anything to do with it.

I mean, I worked with one guy who's a great developer, but you know, it's not just soft skills, it's like overall presentation of how you're doing stuff. The guy was a really good developer. We finally just started taking over for him when stuff had to be shown to management because we realized, you know, he just wasn't there yet. Dude was an unbelievably fast coder, he could understand things in depth that, you know, very quickly that the rest of us couldn't get there as fast as he could, but he was very, very abrasive. He didn't wear deodorant and he was in a south facing office in the south.

Caroline: Oh boy.

Will: And he looked like the Burger King mascot and always wore heavy metal band t-shirts to work. And that didn't go so well with the suits. They still employed him because they liked what he could produce, but there was always a lot of friction in that interaction. And so there's a certain number of those kind of people anywhere, but most other people can learn how to interact. It takes a while and I think a lot of people don't understand that's a skill. Especially if you were a nerd in high school, I know, I was, you know, until probably senior year. I know for a fact I fit in lockers. But, you know, you thought about the popular people and you're like, "Oh, well, you know, they're just popular and that's just the way it is." It's like, no, that person worked on that. You know, at some point in their life, somebody sat them down and said, "You can't do these things this way or you make enemies." That's what the popular kids were then, and a lot of them were more attractive or whatever. But, you know, I think most of that was personality, you know. And looking at it and going, "Okay, they just were naturally, they had their stuff together." And it's like, no, nobody naturally has their stuff together. We come into the world screaming and naked. Like we all get here the same way. We're not naturally good at anything. We have to learn it.

Caroline: I totally agree. I totally agree. And I think that, you know, each of us, some things come a little more naturally to each of us than others, and others, you know, we have to decide to learn them, if we accept that they're valuable enough skills. And I guess, some folks don't believe, you know, that it's a valuable skill. And in some cases, that's gonna be okay. Sometimes we can partner with those folks and you can take the person who's very, very strong technically, and you can take the person who's very, very strong socially, and you can put them together, and together, they can make magic. And then there's other cases where you put those folks together and they just don't understand each other. It just doesn't click. You know, and this is what it's like to be human and to make technology.

Will: Well, and one other thing too I see security folks do, and I understand why they don't do this for developers, but when you find a security violation of some sort, I don't know, like probably not SQL injection anymore because you probably ought to smack them if they're at that level. But something that's a little bit more complex with, you know, cross-site request forgery or something like that. If the security professional just says, "Oh, this is a CSAF issue and you need to do blah, blah, blah." When you tell that the developers, that's a work item. If you go over there to them and you go, "Hey, I found this thing, take a look at this." And you let your nerd flag fly and you walk them through what you did, the developer is now on your side, right, because they saw your eyes light up, they heard the tone in your voice.

You know, because we're pretty attuned honestly, to other people who are very, very interested in something, even if it's not something that we like, because we recognize that feeling. Because that's why we're convinced to sit in a basement somewhere, looking at a screen all day. You know, that's the thing that brought us here and so we recognize that and when we see it in other people, it makes us more empathetic to where they're coming from on stuff. And I wish security professionals did that more often, which, you know, being integrated on team, they would do that probably because it's their peers versus somebody they're auditing. But that's something I've often thought would be really helpful. Like my QA team does that when they find bugs. They're real good about like getting me on screen and showing me exactly how they approached it, and that's super-duper helpful.

Caroline: Yes. Oh, couldn't agree more. Will, last question for you. I've gotta ask you what you think about remote work. I spent a bunch of my career in Silicon Valley. We've all been living the past couple of years in pandemic land. And I think for technologists, we're super fortunate that we have an opportunity to do remote work some of or all of the time. You know, your doctor buddy, if he was gonna be seeing patients in the clinic that is certainly not work that a person can do remote. Would love to hear thoughts that you have on remote work today.

Will: Well, there's several interesting things. The impetus for writing the book was that I was working at a company where someone did convince management to let them work remotely. And management, I really don't know what they were thinking because this person, they were not terribly effective in the office, but they let the guy work remote on a day when the board was meeting. And this is a company with, I think they had 15 people, at that point. And he's working from home, you know, I was on a call with him that morning and you could hear all kinds of racket in the background and his kids are in a fight, in the floor. The TV's blaring, his wife's yelling at the kids, dogs barking. I mean, it was absolute chaos. It was looking at somebody's life that was just really hard to see.

And I was like, "Okay, this is gonna be interesting when we have the board meeting later, but, you know, he doesn't report to me, I don't report to him so, you know, this ought to be entertaining at least." And we go in and we have the board meeting and we have, the older, owners of the company, or basically the board and some of these guys have flown in and kind of the entire company is sitting around, you know, the one conference table. And, you know, people are showing different stuff on screen to the board members. And I covered the story in the book, so it is a very silly story. But, you know, he gets on screen and he's on a 60 inch wide 4k TV. He's up there like Dr. Evil, about to explain what he's doing.

And our boss had said, "I really don't like the idea of remote work, especially with these kind of stakes," and he had to work remote that day, which he really didn't. And he completely screwed it up because right as everything gets calm and everybody's staring at the screen, waiting on him to start showing the software that he had been working on, his cat jumps up on the keyboard and puts its backside up the camera very, very close.

Caroline: Oh, my gosh.

Will: And I was sitting there going, you know, he really didn't sell that very well, you know.

Caroline: So, gross.

Will: And so that's why I wrote the book is because I was like, you know, this was not a technical problem, right? He came through clear in 4k. His audio was good. The video was crisp.

Caroline: All of it in 4k. My goodness.

Will: The video was extremely crisp. and you know, like they still joke about that situation. And that was the thing, I was like, you know, this guy he's failing, not because he's failing to sell the tech, but he isn't doing the soft skill stuff to make people feel like they can trust him, and he's not, you know, selling it in a less risky scenario to make sure his stuff actually works. And so that's what got me interested in remote work. My book actually I think came out...was it the week that COVID became a pandemic?

Caroline: Oh, wow. What incredible timing. I mean, that was just like...

Will: Well, if it had come out like a month earlier, it would've really done well, because it took it a little bit to get up in the ratings on Amazon. But it was, I wanna say it was, like, number three in one of the categories for like two days or something and then it, you know, fell back down, like they always do. But if that had hit right, that would've been amazing. But yeah, I like the remote work thing. There are always problems with stuff. I mean, one thing is, is you have managers who don't know how to manage unless they're looking at somebody and that person's pretending to work. You know, as an IT professional, you probably do not work eight hours a day, realistically, you know, like at least not full throttle, just because you burn out doing that.

I would also say that it's been kind of weird with COVID because a lot of people have worked remotely, who, you know, they either lacked the ability to really do it, or they didn't have the discipline, or the other skills that were necessary. You know, when you talk on a phone call, you have to throw your voice a little bit more than you would in a normal conversation with somebody. You know, and we know this as podcasters, right? You know, your questions go up more at the end.

Caroline: So true.

Will: Yeah. And, you know, I've had to learn that taking foreign language classes online too, because that throws off, you know, intonation and those kind of things, because I go into my podcaster mode and that's not what I need to do. And so, there's a lot of people that don't adjust to that. There's also organizations that don't adjust very well, because it got forced on them, which was unfortunate. I mean, I guess it was necessary, you know, for everybody to get home, but a lot of places were completely caught flat-footed.

The company I was working for, they were more than half-remote, I think it at that point, and so they just sent everybody home. Like the next day we were like, "Okay, you know, so, and so's got a slow internet connection. I think everybody else is good." You know, it was totally fine. We were completely set up for it and it was no problem whatsoever. You know, one of the companies I worked for before, the one where dub bro had the cat, they had a really hard time with that transition because, you know, like I think their router or they had some kind of like security VPN InPoint device, I'm not exactly sure what the thing was. It was a big gray box. It was rack-mounted and I stayed away from it because it wasn't my department. But I think that thing was not capable of actually handling the whole office remoting in. And nobody had headsets.

Because the other thing they did is they didn't like people that gamed too much and it's like, well, every gamer has a headset at home. Like if you're gonna get people for remote work, that's what you want because they spent $200 on a nice headset and you don't have to spend $30 on a crappy one. So, it varied there. One other thing I will say about remote work that I think that has emerged on this. I didn't think of it when I was writing the book or there would've been some things that would've been said in a smarter way, is that remote work is kind of like eating dirt in the sense like as a kid, obviously, like...hope you don't do that as an adult. Hopefully, I know doesn't yeah, but...

Caroline: I might have a dirt-eating story. Will save that for another time over beverages.

Will: Yeah. But, you know, it sort of builds your company's immune system, right? You now know that the, you know, internal network of your company, you know, it's got packets coming from somebody's house going over that, and you have to accept that and you have to, you know, work on your internal security in a way that acknowledges that that is a fact, even though it was probably a fact before then. And so that's been interesting just watching, you know, some of those things come out where they're like, "Okay, we are going to have the windows firewalls on, on all the machines, on the network, and we're gonna have proper security stuff, and we're not gonna be storing customer passwords in a text file and SharePoint," and, you know, just on and on and on, you know. I know of a company that was doing that years ago, and surely, they fixed that by now.

Caroline: I hope so. Surely, they have.

Will: Yeah. You know, again, I mean, I go back to the '90s, you know, like that scene...and I don't know if you're familiar with, "Lord of the Rings," the movies

Caroline: A little bit.

Will: Like the hobbits go to the minds of Moria and there's like a password on the door and they're like, "Oh, what's the word?" And you know, you have to say the word friend and the doors open.

Caroline: So gross.

Will: And just lets whoever in that happens to be hanging out there. Like that was password security in the '90s.

Caroline: Totally. You have good characterization. Oh, goodness.

Will: Yeah. And I think with remote work, you know, people are moving around, you know, sometimes people are at coffee shops. You know, we can't always assume that the person can get on the VPN, necessarily or that that's desirable. You know, we have to tell people, "Hey, you know, be careful about your workstation at home, you know." We have to set policies that say, "Hey, this machine, you know, locks after, you know, X number of minutes or whatever." Because, hey, dub bros at home with the cat and the kids, what happens when he's got sequel open with some massive delete statement that he's working on, and the kids get into a fight over the Flintstones and then one them runs in there and slams his hand down on the laptop and happens to hit F5 and runs that query on production. Right. Like there's all those kind of dynamics that companies are having to think about. They're having to think about what happens if a work laptop gets stolen. You know, like the physical security thing and they're having to accept that, I can't say that this thing is always gonna be in a locked area.

Caroline: Right. Yeah. It completely changes the attack surface, remote work. It's been a fascinating study, I think, both in terms of how do we adapt to changing situations. And also, you know, now we're just figuring out how to move forward, and keep having the fun, and also try and collaborate, you know, remotely. Super interesting times ahead, that's for sure.

Will: Yeah. And, you know, it's forced change, right? And when you have a forced change, you have growth.

Caroline: Yes, that's right.

Will: You know, like if you look at the evolution of tech as being a sequence of relative equilibrium, punctuated by a sudden change, you know, most of the most interesting things happened right after the change, right? Like, you know, you ended up with...I don't know if you remember like the late '90s, there was the, ILOVEYOU virus that went around on email.

Caroline: I remember.

Will: Yeah. I was working support, when that one happened.

Caroline: Oh, fun, fun, fun.

Will: Yeah. That was really, really awesome. Yeah. There was no overtime on that one. Right. But that changed because that got everybody's attention. They're like, "Hey, I can't believe something that just came in through email. I can't necessarily click on an attachment." And you had all these people that just, all of a sudden, that was part of their world. And so if you were developing software that was throwing stuff over the wire, in an email, all of a sudden now your clients are like, "I'm not doing that." And you know, a little bit later we had September 11th and well, we had Y2K which was always...it was I think to some degree overblown, although, you know, I do know of systems that had problems that were like ancient.

You know, it was honestly more of a surprise that the system lasted until Y2K, then that it had problems afterward. Oh, now I'm talking business basic for Xenex, like some old stuff that they had at the oil company that was, you know, that was an issue. But that was something where we go, "Okay, we have to be specific about dates. We can't be stupid for two bites again." You know, September 11th was another sea change. I would say...was it Enron or whichever one that introduced like the Sarbanes Oxley stuff, you know, there is some degree of security component in that.

Caroline: Definitely. Among security controls in there.

Will: Yeah. And, you know, that was a big thing. And then, you know, obviously, you know, coronavirus was a big one. The one that kinda makes me uncomfortable right now is we have a major land war going on in Europe.

Caroline: Yes, we do.

Will: And I could tell you the development community, you know, they're aware of the war, but they're not aware of the security implications. Because they're used to going, "Okay, you know, here's some hacking collective, that's gonna try to break into the system, okay, how do we stop them?" Well, you know, what, if it's the government of like Belarus or something trying to break in. You know, they have different motivations. You know, they get in there and they impersonate somebody, they're not likely after credit card information, they're after something else, or they want to use your platform to launch something else.

Caroline: Oh, yeah, software's vulnerable. And nation states have reasons to, you know, execute on cyber-attacks. That is reality today, for sure.

Will: Yeah. I mean, I had somebody tell me, they're like, "You know, having a computer is like having a genie, except only the first wish is yours."

Caroline: That's a good one.

Will: And it's just kind of like, the more you think about that, the more uncomfortable that makes you because you realize that there's three in there. And so, there's the horrible thing that you can probably envision and then there's something after that, you know, that you can't and yeah, it is liable to get very interesting.

Caroline: The unpredictable. Yeah. Well, Will, I wish that we could just keep going.

Will: I know, I do too.

Caroline: This has been so much fun. We should do this more often. Thank you...

Will: Definitely.

Caroline: ...so much for your time today for sharing your stories and your thoughts with us, we appreciate it, and I cannot wait to see what's next for you. We'll be keeping our eyes on you. Thank you so much, Will.

Will: All righty. Thank you.

Caroline: "Humans of Infosec" is brought to you by Cobalt, a Pentest as a Service company. You can find us on Twitter @humansofinfosec.