Alyssa Miller — Experiences with DevOps + Automation and beyond

0:00Chris RomeoAlyssa Miller is a hacker, security evangelist, cybersecurity professional, and international public speaker with almost 15 years of experience in the security industry. A former developer, her background is application security, not only conducting technical assessments, but also helping develop complete security programs. Alyssa joins us to share her take on DevOps, automation, and beyond. She also shares a great story about how she got domain admin in 3 minutes through a web app. We hope you enjoy this conversation with Alyssa Miller. At Security Journey, we believe security is every developer's job. We work with our customers to help them build long-term, sustainable security culture amongst all their developers. Our approach is to provide security education that's conversational, quick, hands-on, and fun. We don't do lectures. Instead, we let the experts talk about what's important. Modules are quick, 10 to 20 minutes in length. We believe in hands-on experiments, builder and breaker style, that allow your developers to put what they learned into action. And lastly, fun. Training doesn't have to be boring. We make it engaging and fun for the developers. Visit www.securityjourney.com to sign up for a free trial of the Security Dojo.

1:14Robert HurlbutHello folks, and thanks for joining us. We're here with another episode of the Application Security Podcast. This is Robert Hurlbut. I'm a threat modeling architect, and I'm also joined by my co-host Chris. Hey, Chris.

1:37Chris RomeoHey, Robert, how are you doing today?

1:39Robert HurlbutI'm doing fantastic.

1:41Chris RomeoBecause we have to ask that question, it's in the Podcast 101 handbook. This is Chris Romeo, CEO of Security Journey and co-host of the Application Security Podcast.

1:49Robert HurlbutAnd today we have a guest with us, Alyssa Miller. Alyssa, welcome.

1:54Alyssa MillerHey, I appreciate it. Thanks, guys, for having me on. Uh, Sounds like everybody's doing great. I hope you are.

2:00Robert HurlbutAlyssa, you know, I have— we've sort of met. We haven't met directly yet, but I know you've been to a lot of conferences this past year. I've been to a few as well, and one of them was in BSides Las Vegas. I remember I was actually manning a booth there, and I was hoping that we might get to meet, but you were talking at the same time I was at the booth, and so I unfortunately missed you. But it's really a pleasure to have you here today. I'm really glad that we get to talk here on the podcast.

2:28Alyssa MillerYeah, I definitely appreciate it. I'm looking forward to it.

2:30Robert HurlbutExcellent. All right, well, as we'd like to start with our interviews, let's just dive in. And first thing we'd like to ask is, what is your security origin story? How did you get into this crazy field of security?

2:44Alyssa MillerSo let me— I'll take it back a little ways because it's a little goofy. You know, from a security perspective, if I want to really look at my roots, as you know, I kind of identify myself as a hacker, right? And that That's kind of a title I'm trying to reclaim, and I think a lot of us are from the media, but it really stems from about the time I was 12. I saved up and bought myself my first computer. And in bringing home a computer, I ended up having to teach myself a lot of things, how to install operating systems. I taught myself basic programming. And after buying a modem and connecting to this cool thing at the time— now here's where you're going to figure out how old I am.

3:24Robert HurlbutOkay.

3:25Alyssa Millerconnecting to Prodigy, started to teach myself all about asynchronous modem communications and so forth. But I never really thought of it as a career. I actually went to college, I started as a pre-med major. I had every intention of being a doctor. 3 semesters of college-level chemistry taught me that that was probably not the space I wanted to be in. I just was in a mode where I just needed to figure out a new major. Literally went through the course catalog, the college catalog at Marquette University and looked and noticed they had a computer science degree. I figured, okay, I know computers, I've been programming, I'll jump into that, it should be really easy. I got lucky that this was still around the time of the dot-com boom. While I was still in school, I also managed to get a job, my first full-time salary job as a programmer for a large fintech company. I was a programmer for them for a number of years while still going to school, ultimately graduated. After about 9 years, I had someone from our information security team approach me and ask me if I wanted to join what they called their security test team. And that was just the team that was responsible for all the pen testing, vulnerability scanning, vulnerability management, the whole 9 yards. And it sounded cool. And I asked her though, I don't have any experience doing this. I don't know anything about pen testing. And her answer to me was so funny. It was so short and simple. It was just, you'll figure it out. I trust you. Okay. And figure it out, I guess I did, because here I sit. Uh, you know, that turned into 6 years working in that organization. I ended up taking over as the manager of that group. And after 15 years with that company, decided I want to see what the rest of the world was doing. And so I got into consulting. And, you know, all along, being a former developer, while I've done pen testing on both sides, I've done a lot of different things. AppSec has always been my focus, or at least my specialty. It makes sense. Programmer for years and years and years, what are you going to be best at? Hacking applications. That's really been my focus, at least up until recently with my most current role where it's a little more generally focused on security programs overall. But over the course of that career, definitely, elevated my conversations from pen testing to more of the proactive work within the SDLC to working at a program level, trying to help organizations build their application security program. Rather than really technically, how do we assess this app or that app, get to that much larger level of how do we make sure these 900 apps we have in our environment are all secure? with that has come interactions with a lot of interesting audiences because I still see the day-to-day developers, I still talk with security specialists and so forth, but I'm also having conversations with CISOs and CEOs and CIOs about these same topics and doing a lot of that translation between the two. Kind of a long answer, but that's That's my weird story of how I ended up where I'm at right now.

7:06Robert HurlbutVery cool. You mentioned that application security was something that you were always interested in, and then certainly over the years you've been more and more involved. What is it about application security, especially in working with developers and other teams, that attracted you most?

7:25Alyssa MillerI guess it's a lot of things. Obviously, being a former developer, there was just that skill set was there. It made a lot of sense to me. I could look at at the time, it was web apps more than mobile apps. Now, it's more mobile apps than web apps. But I could look at a web app, I could see something and sniff out the vulnerability because I could just tell what the developer was thinking because I'd been there.

7:47Robert HurlbutRight.

7:47Alyssa MillerI'd written this stuff myself. Just seeing some of those fingerprints of things or those little techniques or where there was a mistake made and you're like, I bet they're doing this or that, or I bet they blacklisted this and I can I can get around that blacklist with some evasion techniques or things like that. So just being able to think like a developer, I think, pays dividends when we're talking about getting into application security and how to interact with those folks.

8:19Robert HurlbutYeah, I agree. My years of being a developer and now mostly as application security person certainly has paid off that I do understand maybe a lot more things or I know what questions to ask, it seems because of that experience. I agree with that. Absolutely. One other thing I know you mentioned is that you have done a lot of penetration testing and other hacker type of security testing. Do you have any interesting stories? Very curious about that.

8:48Alyssa MillerI've got a bunch of war stories. From an AppSec perspective, I think my favorite one, the one that people always seem to ask me about is I toss out there, ask me how I got admin access in 3 minutes through a web app. It's funny because when you think about web app testing versus more of the system-level pen testing, you don't normally think about getting Windows administrator or Windows domain admin through a web app. You're looking for things, you're finding SQL injection, you're finding things like XXE or SSRF or all these cool things that let you do stuff, but you don't really ever think of, oh, I got Domain Admin console access. So people always, when I throw that out there, they're like, wait, what do you mean? 3 minutes in a web app? I was testing this application and it was essentially what they call a web project control application. Basically, it was a project management application that let customers, when the organization was doing a custom development project for a customer, allowed the customers to be a part of the project management lifecycle. So they could go in, they could view requirements and status and all those things. As many apps do, it included upload utility and so forth. Long story short, I ended up being able to determine that the filters on the upload utility were pretty easily bypassed as far as what types of files it let you upload. I was able to couple that with a directory traversal attack that let me drop files wherever I wanted to, and through all of that, was able to drop an ASP.NET shell. Basically, a command line emulator based in ASP.NET, was able to drop that into the application and access it. The real head-scratcher, the one that makes you want to bang your head against the wall, I get in there, I do a whoami at the command line, and what does it come back with? The domain administrator account.

10:59Robert HurlbutOkay.

11:01Alyssa MillerSo they literally had this thing running under a domain admin account. We're talking, this was a production test. This isn't a development environment we're testing, this is production. So literally in the course of 3 minutes from the time I just started walking through the app, Obviously, you see a file upload that just screams, come get me. Yeah, it was about 3 minutes and I had domain-level full access to the operating system and was already pivoting to other servers in the environment. You don't see that every day in an application security test, so that was probably one of my more favorite stories.

11:43Robert HurlbutI like that. Actually, I can remember in developing different applications that uploading anything or just giving that ability to upload was one of the most potentially insecure things you could do, and you really had to be careful about it. So I can absolutely believe it on the one hand, and other hand, well, wow. Right.

12:08Alyssa MillerI mean, they tried, right? They tried. They put it in an isolated directory. They had the ideas there, But yeah, having a directory traversal and then they had filters, but simple evasion techniques, I was able to get around their blacklist of they wouldn't let you upload ASPX or EXE or a few others. But okay, a little bit of encoding got me around that and sure enough, yeah, they tried but they didn't quite have it all together yet.

12:39Robert HurlbutShifting a little bit into our main topic today, we're going to be talking about DevOps, and I know that's a big topic for us. We've talked that quite a bit on this podcast, but we're always open to others telling us about their experiences with DevOps. I know our listeners are always interested as well because again, it's a hot topic these days and how do I get started and what do I do, especially how do I apply security? Just to begin with, everybody has their own ideas about what DevOps is, but what has been your experience or your thoughts on DevOps?

13:13Alyssa MillerWhat is DevOps? Yeah. I'm glad you asked because, yeah, I think the first thing everybody learns about DevOps is there really is no definition of what is DevOps. Everybody seems to have their own impression. For some people, it's just development without barriers or restriction. We can just do whatever we want. We've got full control of the environment. We can do whatever we want. For others, it's a little more refined than that. the bringing together of the development team and the operational team. I guess that latter example is more the way I look at it. I look at DevOps as not really the development paradigm, so to speak, it's more of a structure around the development. A lot of people would equate Agile, CI/CD, and DevOps as being 3 types of different but peer-level development paradigms. That's not the way I look at it. The way I look at DevOps is it's the overarching organization around your Agile development or around your CI/CD development, and it really goes to that unification of the development team with the operational team. Then when we start talking DevSecOps, that's just bringing the security focus into it as well, where now you can think about it in terms of organizational structure, sometimes it manifests itself that way. You may have operations people, development people, and security people who all fall under the same reporting structure because they're now arranged with their responsibility to say an application or to a particular business line or something like that, rather than having all these silos of, here's our development shop and then they throw it over the wall to the QA and they throw it over the wall to the Ops team, and here's security off on the side trying to watch all of it. That's the way I look at DevOps, is that it's not about being able to develop fast or do this or that, it's about bringing all of those separate focuses together under one roof.

15:21Robert HurlbutMakes sense. You mentioned that term DevSecOps. Is that your preferred term or do you have some others or just security with DevOps or anything like that? Do you have any preferred term that you typically use?

15:35Alyssa MillerI typically use DevSecOps just for convenience. It's the easiest way to say, yeah, we're actually considering security as part of our DevOps approach. Security is included in it rather than try to make security an oversight group or something of that nature. Security is part and parcel to our development cycle. That's the way I look at DevSecOps and it's just I think I use that term just out of convenience more than anything else.

16:03Robert HurlbutMakes sense. I know that you gave a talk this year and I was really intrigued by this because, one, I'm a guy that really enjoys threat modeling and so I'm always looking for who's talking about threat modeling and what are they saying. I did see that you gave a talk on threat modeling in a DevOps environment. I know for myself that's something that I've been really interested in, I hear people say, well, we are moving too fast, we can't do threat modeling, we don't have time for that, or things like that. But I'm really curious about if you could maybe tell our listeners some of your perspectives on that threat modeling in DevOps.

16:43Alyssa MillerSure. Yeah. First of all, you hit on the big problem with it. People look at threat modeling and they look at it as this really heavy lifting, time-consuming thing that just is incompatible with a fast and dynamic development cycle. What actually inspired that talk was about a year and a half ago, I was working with a company who had a really good, their own custom but really good methodology for how they did threat modeling and design review. I just remember having a conversation with a development team at one point, One of the developers telling me how they were moving to a DevOps approach and how they were going more down the road of CI/CD and he couldn't wait because then they wouldn't have to do this threat modeling thing anymore. It just struck me like, wait, wait, wait. I get that this is tough and this is heavy, but you lose a lot when you lose that, and especially when you're going into an environment where you're going to be trying to speed up your development. Threat modeling helps enable that when you do it. I got to really thinking, how do I get this out there? How do I put this out there differently? Now, anyone who's in threat modeling certainly has probably read Adam Szostak's book, and I love the hell out of it. Don't get me wrong. Adam, I promise I'm not criticizing you. No, quite the opposite. I mean, it is the gold standard as far as what anyone follows with threat modeling. But let's face it, it's been out there a number of years and people have thrown new things at the wall, but I haven't really seen a solid approach to how do we speed this thing up. Even in his book, he talks about things like data flow diagrams and stride and all these things. When you look at it, one, it's a lot of work to do, two, it's very technical-focused. The talk that I give is breaking it down. If you really look at what threat modeling is, it's asking what could possibly go wrong. The reason you're asking that is so that you can inform the design of security controls as part of the development process. Getting threat modeling done early in the cycle allows your developers now to understand, okay, these are the threats I have to worry about, I need to design security controls for this as I'm developing, Now, you don't have as much of an issue where they implement something, they throw it out there, and now you have some type of development gate that kicks it back to them because it's got a bunch of security bugs that they have to fix, or you've got to play that game of, do I fix it or not? Is it high enough risk or do I have to get to production kind of thing? We know who wins there. So what I always tell people is take it back a level. What do you really need to understand? You don't need to understand that there's a spoofing threat here. You don't need to understand that there's denial of service. Take it back to a business level and start to ask yourself, okay, what really matters here? What is the actual threat? If we're collecting a bunch of consumer data here, is there private data? Okay, then the threat there is the compromise of that private data. I don't care if they do it through a spoofing attack. I don't care how they do it. That's the threat, and that's what I need to design my controls around. When you bring it to that level, now couple that with what's the farthest left you can move in, say, take an Agile DevOps approach where you've got a backlog and you've got the user stories and you've got developers pulling things from the backlog and you're doing your sprints and all of this. Well, the farthest left you can move in that is the user story. The fact of the matter is, if we look at threat modeling from the business perspective of what can go wrong, what could go wrong with this user story, and now we analyze the user story in that context and we say, what are the actual threats to this data that we're collecting, or what are the actual threats to our business because we're implementing this new functionality, and build that threat model right in with your user story. Now you don't slow down the process, you also put the threat modeling into the hands of your business people who actually understand from a business context what is going to be the most risky to the organization. That's what you care about. Because at the end of the day, we know that we're not going to get everything. We know that we're just trying to get incrementally better one day after the next. That whole talk really centers around How do we bring threat modeling into a realm where it includes the developers, the business analysts, anybody who's on that front end of developing those user stories and getting them into the backlog? If you build your threat model as part of documenting your user story before it goes into the backlog, now you don't have to worry about slowing down the development cycle anymore. In fact, now you've enabled those developers with the knowledge that they need to develop security controls to address the threats that you've identified. So you've actually sped up that development cycle, you've enabled them to do it faster because now they know exactly what they need to address. So that's it in a nutshell. Obviously, I get into more detail in the talks and whatnot, and I'm actually putting together a little bit more of a formal framework around this, but When you look at it at the end of the day, that's the easiest way to really speed this thing up and not impact these more dynamic— it's compatible with Agile, it's compatible with CI/CD because you're now at that very front end is where you put all that heavy lifting.

22:41Robert HurlbutOkay, makes sense. How would you ask, let's say you're in that situation with a user story and you've got all those folks in the room, and I agree with you, you absolutely need to have— it's a team effort. It can't be just one person trying to build a threat model and say, here it is. It really is a team effort. But how do you communicate that here's what we're doing as part of this user story? Do you tell them we're doing threat modeling now, or do you just simply say, hey, what could go wrong? I mean, how would you approach just communicating that this is a part of building a user story?

23:15Alyssa MillerInitially, you can actually just simplify it literally to a couple of simple questions about what critical data Is there any critical data being collected as a part of this? Is there critical functionality? You can put those in words, whatever is most meaningful to the organization, but those are the things that those business folks are going to understand. They're going to be able to look at this and say, hey, we're working in financial services. We know if we collect credit card data, that's a big red flag for us, so I know that that's critical data we got to protect. Or I'm in healthcare and I know if I collect any data that's related to health information, that's critical data that I have to protect, or I'm proposing this new user story that's going to allow people to update specific information or information that affects how this system is going to communicate with them or so forth. Those are critical functions that we want to protect. Your business people can understand that context. So you put that out there, then it's really from a developer perspective, their job to translate that into the technical. The same thing they're doing with all the other requirements. It's basically just another form of requirement in that now you're having this person on the front end who builds that user story do that extra analysis. So communicating it out just becomes, hey, here's a couple of the things that are required as a part of inserting your user story, whether it's into Jira or wherever you manage your backlog. These are just other required fields essentially, if you really want to get to the nuts and bolts of it. That's honestly how I've seen it implemented a couple of times is, hey, we just added these couple of fields to our Jira backlog, and each time someone enters a user story, they're asked these couple of questions that they have to answer. Again, you're not going to capture everything, but what it does do is it enables that incremental improvement or to borrow the term, continuous improvement of each time we're putting a user story in there, we're at least doing this thought process and it gets people thinking in those terms. Now, if you really want to get nuts with it, or as we get more mature, you start actually training those people at the front lines on how to do some of that threat modeling in a lightweight sense. You get them really thinking in terms of what threats are and being very proactive about how they think about the functionality and so forth. But day one, you can take this to most of those business people and just ask them those simple questions and they get it.

25:46Robert HurlbutYeah, I agree with you. Another aspect of integrating security with DevOps, I think, is automating stuff. We have all these things we're doing, is there any way to automate it? But do you have some ideas on that and maybe even beyond automation?

26:02Alyssa MillerYeah, there's a lot of ideas. We're seeing vendors in that space. From a solutions perspective, there's a lot of vendors that have jumped into that space. We've got different tools that are integrating with the build tools. You can set up Jenkins to kick off code scans and things like that. All that stuff is out there. Where I'm seeing the biggest issues with that right now is that's a lot of heavy lifting. It's the same problem we have every time in security, when we start talking automation. That is, okay, I've got to find a product that's capable of this automation. I got to set it up, I got to configure it, I have to constantly keep tuning it. That's the part where I think it all falls apart. Everybody's looking for that solution that I can just spin it up today, it'll work 100% tomorrow, and I never have to think about it again. The fact of the matter is that's never going to happen. We know that. We see that I can go back to the days when we were first implementing web application firewalls and people thought, oh, I just buy a WAF and I plug it into my network and go. Well, we all know that didn't work. Either blew up the application or it didn't stop anything. Those were the two options. If you weren't building in time to configure and to constantly revise and refine your rules, you were kidding yourself. I think from an automation perspective, That is a piece that really, if you're going down this path and you really are serious about doing CI/CD, CI/CD has to apply to more than the end product. It has to apply to your entire process. You have to continuously be trying to improve your processes, continuously deploying updates to that process that introduce those improvements so that not only is your end product getting better, but the way that you're developing it is getting better, which of course then feeds into the end product getting better. So you get that cycle going. But the other thing where I see within DevOps or really any development environment is, how can we enable developers early? When we talk about that, it seems like we always focus on education. How do we educate developers? The one thing I've seen that doesn't get as much traction, again, because it requires some commitment in terms of ongoing development and maintenance, is the idea of reference architecture. How do we start to enable developers with simple and very granular reference architecture to say, hey, if you're implementing auth, authentication, you need to do multi-factor, and here's our standard architecture for how that happens. So now what you can do with that reference architecture, not only does it kind of show them the way, it gives them some education. They can easily go, if they know that they're doing a certain thing, they can go search the reference architecture and say, okay, here's how I implement this role-based access control or whatever. You can build into that as well some of the threat modeling components that you need or the controls considerations. I have my reference architecture that implements, let's say, take your multi-factor solution of choice to implement authentication with multi-factor. You know off the top, okay, here's the things that aren't built into this reference architecture that you as a developer need to consider when you leverage this reference architecture. Here's the controls you need to be looking at and you need to build that don't exist as a part of this reference architecture itself. So that type of thing and getting more into the realm where the repeatable mundane things that developers can leverage, that's been a mantra in development forever, reusability. So giving them that and letting them focus their creative juices on the things that matter, in terms of functionality and so forth. Where they're creating something new and innovative, let's let them focus there. Let's give them the tools they need to do those repeatable processes and to implement them regardless of what code they're using or what environment they're working in.

30:35Robert HurlbutNo, I like that. I've seen that often as well, or at least more and more different teams are talking about reference architectures and proposing that as a good solution, especially for DevOps. If I have something as a developer that can help me understand, especially if I'm new to this, I'm trying to— there's so much I need to figure out. And if I have some examples, I think it certainly makes a difference.

30:59Alyssa MillerYeah, exactly. And it's a heck of a lot more effective than sitting a developer down in front of a bunch of videos about AppSec.

31:06Robert HurlbutRight. So here's a good question for you. Have you seen some challenges about or in regards to DevOps and security? How do we integrate it? How do we get started? Have you seen any challenges and how have you met some of those?

31:25Alyssa MillerYeah, definitely. I think I've mentioned a couple actually, because one of the big ones again is just that people view DevOps as this like, hey, I can remove all this structure and now I just go and I just develop all day and I can just deploy whenever I want and it's this great utopia where I have no controls and I can just do whatever. So they view that as exclusionary of security. The fact of the matter is that really isn't what DevOps is all about. In fact, quite honestly, a lot of times it's counterproductive to what you're trying to do when you do DevOps. DevOps, like I said before, in my book, is really bringing all those roles together with a common focus. and a common understanding and some common knowledge around the system that they're developing and securing and supporting. So I think that just that attitude alone is one of the big challenges where rather than looking at it as, how do I take all these things that I'm required to do today and say waterfall development paradigm and bring that into what I'm going to do in a CI/CD paradigm under DevOps, When they just expect to be able to shed all of that, it really doesn't enable any of the benefits of what you get out of moving to that type of environment. I think that's a big struggle. Then along with that goes the fact that then nobody is really committed to the effort that it takes to really convert to that type of environment. And understanding that we have to be continuously trying to improve our processes and make them better. And that it's not just a, we get rid of all the processes, so now we can just do whatever we want. It's a free-for-all. No, it's actually quite the opposite. It becomes very structured, but in a very different way. And if you're not building that structure around it and doing all the things around automation and all these different pieces that make your life easier, you're still going to run into the same issues, and that is you're going to be finding bugs in production that are going to be coming back to you. You're going to spend more time on bug fixes than you are doing the cool, innovative new functionality that you want to be working on in the first place.

33:41Robert HurlbutIn terms of time, do you propose— you have some proposals for when do you get started, when do you— and that sort of thing, or is it— well, yeah, I'm just opening it up for that. in terms of how do I get started in DevOps and security? Do you propose any timeframes on that?

34:00Alyssa MillerI mean, I guess the big thing is you have to be strategic about it. So we're not talking something you're going to implement in 6 months.

34:06Robert HurlbutRight.

34:06Alyssa MillerIt's got to be something carefully planned that you're looking at over— my recommendation honestly is planning it out over at least a 3-year period where you're taking it in bite-sized chunks. How do we start to build the functionality of a pipeline, and how do we start to do this? I know that saying 3 years, oh my God, everybody out there is thinking DevOps and CI/CD right now, it's like that's a lifetime. I'm not saying that you don't get to the point of doing that development, that it takes 3 years to get there, but it's a 3-year plan of we're going to start to roll this out and we're going to implement these different pieces of it. That's going to culminate in 3 years where we've got the full pipeline automated, we've got security built into it, we're doing all the things. We're building reference architectures and we've got that feedback loop where our reference architectures are being updated and we're doing threat modeling on the way in with the user stories, and that's feeding not only our development lifecycle, but it's also again informing the constant revision of those reference architectures and so forth. We've got those developer communities now that are formed around our processes so that we can share information between this DevOps team that's over here focused on this business line and this DevOps team over here that's focused on this business line. So we've enabled that crosstalk. These are all the things that need to be considered when you're going to DevOps that people don't really think about.

35:31Chris RomeoAnd so there's a lot, there's a bunch of people out there right now that are thinking like, 3 years, that sounds like an eternity. These are people that have never worked at a big company, right? So I worked at a big company with 25,000 developers and 3 years is certainly something that we're gonna aim for, but we're not gonna, I'm not gonna come in with a, organizationally culture-changing program that I'm going to commit to doing any faster than 3 years, because it's just going to take people a while to get behind it. And you're going to have to get some— it's going to take you 6 months just to get anything rolling, 12 months to get a little bit of momentum and get somebody, some team somewhere to say they're doing it. And then, like you said, a few other years to bring it all together.

36:12Alyssa MillerYeah, and that's exactly it. And you hit on the really important point, in my opinion, and that is to remember this is a culture change. The bigger your organization, we all know this, the bigger your organization, the harder it is to get that ship to turn. It could be a 5-year implementation path depending on where you're at. You have to be aware of it and you have to be realistic about it. It's not something you're just going to shed this overnight and do this startup style and suddenly now you can turn on a dime. These companies have large established brands that they're trying to protect. They have large established cultures that don't change easily, and you've got to win that support like you were saying.

36:55Robert HurlbutAlyssa, I really appreciate your time with us here today. Turning just slightly to another topic to wrap up here, I know this past year you've done a lot of speaking, as we said, you've helped out a lot of people with understanding about security and so forth. But one of the things that I've seen that you've done really, really well is giving a voice to those who are trying trying to get into this career that sometimes may be overlooked. They're not sure if they could do this or not. They're not sure, does anybody really want to give me a chance? So I wonder if you could talk a little bit about that and give us maybe some advice to those who are trying to get into this career and they're not sure where to get started and things like that. If you could maybe tell us about that and your experiences.

37:42Alyssa MillerYeah. So that's That is a common issue, and we're seeing a lot of it, and the causes stem from a lot of different things. For instance, you'll see me even just today tweeting about bad job descriptions where companies are throwing unrealistic job descriptions out there, weird things from like CISSP required for an entry-level job when we all know you can't even get a CISSP without multiple years of experience. Or the worst yet, I did actually see someone who wanted 10 years of AWS experience. Okay, so that would be Jeff Bezos. Literally, come on, these things aren't realistic. That's harming a lot of people. There's also just— there's a belief that you have to be this ultra-technical person to get into security. The reality is, if you talk to people in security, most of us that have been here for a while grew up in a world where there was no formal path. There weren't degree programs at universities for cybersecurity or anything like that. If you talk to people around the industry, everybody's got their own little goofy story about how they got here. You know, I shared mine earlier. Um, you know, I, I was going to be a doctor, for crying out loud, and I got into cybersecurity, right? Um, and so that's the first thing I try to help people understand is I don't care what your background is. If this is something you have a passion for and you really want to get into it, go after it. There are so many different paths into this space, but the one thing I stress to people is figure out where that passion lies. Find that thing that you're excited about and go after it. Um, you can always change your mind, right? There are so many things you can do in security. If you decide, I want to be a social engineer and I'm going to learn all about the human factor and I'm going to chase down social engineering, I'm going to learn everything, then you get into it in 5 months and you realize, oh my God, this is not where I want to be. Well, then you pivot. You can move. You can get into other areas, but that experience you gained in those 5 months of trying to learn social engineering will play into whatever it is that you decide to try next, and you have that ability. It's very unique how easy it is to pivot within security from one specialization to another over other parts of IT, for instance, or just other parts of the workforce in general. We have a really diverse set of skills that we need in security because at the end of the day, security touches everything. So, you know, that's probably the one thing I stress to people more than anything else. Know what you want to try. Doesn't mean it's what you're going to be doing for the rest of your life. But the very worst thing you can do is come to me if you're asking me for some mentorship and I ask you, well, what do you want to do? What are you interested in? And you say, well, I just want to learn cybersecurity. That's such a nebulous thing. Tell me what it is that you're passionate about, what gets you excited, what piques your interest, what are those things that make you want to dig in and learn more? Where are those aspects of this? Let's go try that. Let's try that together. Then if you figure out that it's not where you want to be, we'll pivot. We'll find something else that excites you and go there. But you got to just— that is the one thing you need is just that idea of where you want to go to start or what you want to try first.

41:27Robert HurlbutI love that advice. Try something, pivot. If it doesn't work, try something else. Absolutely fantastic because in my own experience, I've seen so many people that have, like you said, different backgrounds and they all can contribute. I think that's fantastic advice. Thank you. So as we wrap up here, I know that you've got a few things coming up for next year. You've got some— this coming year rather— some conferences. I think there's the BlueCon. Is that a new conference that's in Chicago, if I'm not mistaken? Yeah.

42:01Alyssa MillerSo we got Blue Team Con, which I'm proud to be an advisory board member for that conference. Brand new this year. Really neat in that, you know, one, it's focused on blue teaming. Those of us that work for organizations and we're responsible for protecting that organization, it's really focused on those types of roles. The other thing is just the culture around it and really what we've tried to do to take all the lessons learned from a million other conferences and do it right from the beginning. From code of conduct through making sure that speakers who or potential speakers who were declined get feedback if they want it, to making sure that we treat the speakers that are participating the best way we can. And so I'm really excited about what that conference is going to be.

42:57Robert HurlbutAnd yeah, I saw that. A couple other things in regards to getting feedback back and those goals. And so I think it's definitely worth checking out. So for our listeners, if you're interested, check out Alyssa on Twitter. She, she mentioned some of these things that she's talking about, different conferences and so forth. And if you also have a good chance, see her at a conference and her speaking, you'll, you'll definitely enjoy it. So again, thanks Alyssa for joining us today. Really appreciate it.

43:28Alyssa MillerYeah, I definitely appreciate it. Thanks for, again, for having me on.

43:35Chris RomeoThanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast or on the web at www.securityjourney.com/application-security-podcast. You can also find Chris on Twitter @edgeroute and Robert @RobertHurlbut. Remember, security is a journey, not a destination.