Maril Vernon -- You Get What You Inspect, Not What You Expect

0:00Chris RomeoMeryl Vernon is a senior application security architect and Purple Team program manager. Meryl is also co-host and co-founder of the Cyber Queens podcast, an all-female-led podcast aimed at increasing female and LGBTQ diversity in cybersecurity. Meryl has been named one of the Epic Women in Cyber 2023, Cybersecurity Top 10 Women in Cyber 2023, Women's Cyberjitsu Pen Test Ninja Award winner, and is a finalist for Cybersecurity Woman of the Year, Hacker of the Year and Cybersecurity Woman of the World 2023. Meryl joins us to discuss collaborative methods of AppSec, purple teaming, and the intersections of penetration testing and both of these other topics. We hope you enjoy this conversation with Meryl Vernon.

0:49Maril VernonCoding more securely from the start saves your organization time and money while protecting yours and your customers' data. Security Journey provides hands-on secure coding training in an application sandbox that allows developers to identify, break, and fix common security vulnerabilities. Give your developers the opportunity to recognize and prevent common and emerging security issues before they become a problem. Visit securityjourney.com to try our training today.

1:17Robert HurlbutHey folks, welcome to another episode of the Application Security Podcast. I'm Robert Hurlbut. I'm a principal application security architect at Acquia, and I'm joined by my good friend Chris Romeo. Hey Chris.

1:42Chris RomeoHey Robert, Chris Romeo, CEO of Curve Ventures, and I like threat modeling. I'm trying to say something different. I feel like I always say the same thing. What else can I say? The sky is blue, the sun's shining. I don't know, kind of a weather update from Raleigh, North Carolina. It's probably not that interesting to the people that are listening to this podcast right now. But, um, who are we talking to today?

2:05Robert HurlbutWell, we are talking to my good friend as well, Meryl Vernon, whom I've also been working with, uh, recently at, uh, the same company. So, Meryl, welcome.

2:16Maril VernonThank you. Thank you so much for having me here, both of you. Um, my name is Meryl Vernon. I am a red team operator by trade, um, who has now moved into the application security and threat modeling space.

2:29Robert HurlbutExcellent.

2:30Chris RomeoVery cool.

2:30Robert HurlbutYeah, I'm very, very glad to have you here. And as we typically do when we're talking with folks on the podcast, we like to start with a security origin story. So, if you would, Meryl, how did you get into this wonderful, crazy world of security?

2:46Maril VernonYeah. So, when I first discovered cyber as an industry, I— because I, you know, always knew computers and IT were an industry, but I didn't know cyber was a completely different function. I was working in marketing at the time. Actually for Caesars Entertainment. So I was a copy editor and social media manager, and I was just kind of growing bored with that, plateauing. And I still love the work, but there was nowhere to go skills-wise. And I said, I'm gonna pick the most difficult, mysterious, mercurial-sounding thing I possibly can so that hopefully the challenges never end so that I never get to stop learning. And I just decided to try cyber until I hated it or I sucked at it. And luckily neither of those things happened. And so, you know, I knew it was difficult to get into as a field, so I decided to do something I did know, which was to enlist in the National Guard, get into a cyber unit within the Guard, and then I leveraged my Guard title and experience to get into my first private cyber position. So that is how I broke in.

3:41Chris RomeoDidn't you just win an award, I believe, in Las Vegas?

3:47Maril VernonI did. I did. I won the United Cybersecurity Alliance Cybersecurity Woman of the Year, Hacker of the Year 2023. Uh, in a long line of legendary women hackers. So I'm very, very grateful to be counted among them now. It's insane.

4:04Chris RomeoVery cool, very cool. Congratulations on that. That's so cool.

4:07Maril VernonThank you.

4:08Robert HurlbutYeah, definitely. Congratulations. What sparked your interest and what led you to specialize in purple teaming in particular?

4:18Maril VernonUh, yeah, so back when I first started pen testing, um, I worked for a Small to medium-sized business, and they—we didn't have a large cybersecurity department. And our IT operations department actually took care of pretty much everything from asset provisioning to remediation cadence to SOC investigations. A lot of duties were lumped into multiple departments. And as I was pen testing, I realized one day when I did a firewall assessment six months apart and didn't have to change anything on my report but the dates—that everything was persisting, and they didn't have time to get to any of my findings. And I felt real bad, and like I wasn't affecting any real change or. Helping to secure anything. So I said, you know what, if you don't have time, I was like, teach me, teach me your tools, teach me your ways, teach me your processes, and I will get in there and see what I can find and what I can recommend that you fix very quickly so it minimizes the impact on your time. And I kind of just started purple teaming by myself before there was really a word for it to save the blue team's time. And then I realized that there was a need for more cross-collaboration as I moved to bigger orgs, you know, more dedicated red teaming roles. I realized the same thing, you know, the blue team is suffering from morale defeat, right? They just feel like the red team's just coming in and winning every time and achieving our objectives every time, and it makes them feel horrible, which isn't our goal. Additionally, they were also inundated. You know, even at big orgs, the blue teams get inundated very quickly. And we realized that they asked us to take a break from ops for like 2 quarters so they could catch up on our past few operations. And we're like, oh, this is also horrible. We're also not helping. And we felt bad. So, I started to pull them in and take our red team operation, like repeatable TTPs, and just see if we could work with each other on educating them. Like, not only the what, not only the what do you see, but where did that come from? Why did we get here? How did we get here? What was I after? So that they can hopefully become, you know, better investigators. If they do have to do a manual investigation, it's more value added. And we also help them automate more. So my attraction to purple teaming simply came from just feeling like my role as a strictly offensive security person was very limited and not really helping my org. And then I wanted to help my coworkers because we're all on the same team.

6:30Chris RomeoSo, I think my understanding of purple teaming, I may not have the whole picture. So, let me ask a question here, and you can help me to perhaps understand it better because I've never thought about purple teaming from the AppSec perspective. But as a purple team person who's focused on kind of the AppSec side as well, Are you breaking and building both? Like, are you finding flaws, finding issues, security vulnerabilities in web applications, and then meeting with the developers and teaching them how to fix it, helping them fix it, advising them? Like, is that what you're doing?

7:13Maril VernonYeah. So, really, I've taken the stance lately that purple teaming shouldn't be a proper team, right? It doesn't have to just be SOC analysts getting together with pen testers. Really, what it is, is it's just collaborative security. It's a whole holistic, collaborative, proactive approach where we just sit multiple teams down together and say, how can we help each other learn, learn our jobs? How does that make me better at proactively testing the things that you build? How does that make you better at proactively building the things that I will test? And so, we do, in the application security world, it's not really probably a purple team. It's actually probably more of an orange team because we do take those builders, those developers, those UX/UI designers, software engineers, and the ISOs, And we put them together with someone like me who's red, and we say, you know, what can I learn from you? Like, and I would say, oh, have you thought of the fact that I as a red teamer would try to exploit this? This is a relevant threat against the system. And they'll say, oh, we didn't think about that before. That's a great point. You know, can we remediate around that? So, it is cross-education. It's building a better, you know, DevSecOps mindset, helping them to think about these things as they're building the products in the future. And then, if we have to, helping them to analyze their system from a whole to see, have I considered not just what I think are the threats, threat, says the builder, but what an offensive person sees as an opening from their perspective. So, it's really just about that cross-pollination.

8:31Chris RomeoThat's very helpful. That's— I don't know, somehow I never connected those dots. I don't know. Like, that's one of the things that I've learned in doing multiple podcasts and interviewing people. It's like, I don't really know that much. Like, I know some things, but there's a lot of things that I still need to learn. And like, you just connected 2 dots for me that somehow I never connected. But that's really, it's a powerful idea though, that you're breaking something and then you're advising on how to fix it with the developers themselves. I always thought purple team was red and blue. It's those, the folks in InfoSec that are off to the side that we in AppSec, we talk to, we're kind of, we know them, but we don't really spend a lot of time with them. Like, you're talking about this thing where everybody's all together. Like, that's such a cool concept.

9:17Maril VernonYeah, I love it personally because, you know, I think more cohesion between the teams is what's gonna make us better. Back when I first started pentesting, for anyone who knows my story, I talked myself into a pentesting position with no pentesting experience. I also talked my way into cyber with no cyber experience. So, when I first started pentesting things and learning these tools and learning these capabilities, I would just write as my remediation recommendation, you know, go fix all the places where this happens. And they wouldn't do it. And I'm like, I went to the developers, I walked down 2 floors, and I was like, hi, you may have seen this report, just realized none of these things are getting done. I just wanna understand why, where am I going wrong? They're like, oh, because that tiny little sentence you put there is like 30 hours of work for us to go through all the lines of code and find all the places that that happens, and there's no intelligent way to do it, and we're just not gonna do it from a realistic perspective. And I'm like, well, our attack surface is huge. So, I was like, how can I do that more intelligently? How can I write it in developer so that it makes sense for you? It's time-efficient, it's cost-efficient, it's effective. You know, if we can't find it everywhere, can we do something? And they were like, yeah, let us teach you how we would actually approach something like that, what makes more sense. And I learned how to write my remediations in dev so that they would actually get responded to. And I think that's a beautiful place where practical application security purple teaming today, you know, has kind of taken an evolution. All right, we gotta unpack that.

10:44Chris RomeoWriting your remediations in dev. I must understand... I know we're completely off the script, but I don't care. That's why we have this podcast. So, we don't have to follow the script. I wanna understand. So, what is— if you were to tell me a couple, like, 3 or 4 best practices for writing remediations in dev, which I'm assuming means dev speak that they understand they can do, what would be the 3 or 4 things you would advise me to do?

11:10Maril VernonSo, like, instead of just saying, like, you know, key management, this is ineffective, like, you should really be managing all the keys in a central place, you should, be blah, blah, blah, like, don't hardcode keys in code, da, da, da. Well, developers need that kind of thing, especially in development, to help them. So, I would just say, you know, stick it in a specific module, give it a special tag, give it a place where you could go through after, grep for all the instances of that thing, or hopefully most of the instances, find a place to replace it, eradicate it, rotate it. Also, that's gonna make it easier in the future for when you do need to rotate that service account key, that admin account key. Like, let's build these things in from the get-go. It's kind of like, Like labeling all of the stuff you put in your pantry, right? Like, this is rice, this is spaghetti, this is this. I'm not just like, go find all the grains and tell me what my options are for dinner. You know, you're tagging that on the front end so you can say, these are the 4 pastas we have, which one do you wanna work with? And I just learned to start saying things like module and saying things like that made sense to them. So I would, you know, I would obviously say, like, tag as many things individually as possible. It doesn't make it as easy to code, uniformly, because you have to keep in mind all the different variables that you define for yourself. But the more variables you have and the more you can keep track of those things, the difficult— the more difficult it will be for me as an adversary to find all of them and abuse them. Other things I would say is really, really strong input sanitization. Make sure that the user doesn't have as much creative license as they want to just put random things into input parameters and boxes and stuff like that. You know, try to control error messaging as much as possible. You'd be surprised just how far we can get learning that, like, oh, Oh, you put your username incorrectly. It should be firstname.lastname. I'm like, beautiful, love that for me. I'm just gonna go look up all the employees who work at this organization. So, I was just giving them really specific things they could go for, targeted, easily find, fix, and then hopefully not do that practice in the future also, rather than just say, code more securely, or stop doing this, or go find all the instances of that. Like, that doesn't work very well, I learned. Hmm.

13:13Chris RomeoSo, are you in the code as you're preparing your remediation? You're writing this guidance to the developer in a Jira ticket or a bug or whatever, or in the report. Do you have the code open? Are you giving them line numbers and things, like pinpointing where they need to go to fix it?

13:30Maril VernonIf I can, I'd love to do that. Like, if we are doing API testing or fuzz testing or source code analysis, great. I would say, here's an instance of this on these lines. Like, that's an instance of what I'm talking about. But we don't oftentimes have access to all of that. So instead, I would say, this was made possible. Can we look together at where this is and why that was possible? And then I can help you find an intelligent way to fix it. But I don't— I'm not always able to provide them the Splunk rule or provide them the exact syntax that they can grab or something like that. Unfortunately, it's just a limitation of the testing. But that's why I love purple team exercises, because maybe we found that thing in the red team operation, and then I would love to sit down after and go in depth with with them and find it and say, you know, okay, if we can't remove that completely, what can we put around it? Or what can we alert on? Or something like that. Like, an unintelligent remediation recommendation would be to like, don't let anyone use the clipboard because obviously we can copy and paste a lot of info and exfil, and that's bad. They're like, that's unpractical. Everyone's going to use clipboard. I'm like, but could you alert on people in like soft skill roles like sales and marketing using clipboard from the command line, which is not typical for their behavior?

14:39Chris RomeoYeah.

14:40Maril VernonRight? That would be something that's suspicious. So, you know, you just try to make it as tailored as you can.

14:45Robert HurlbutYeah. Let's talk about collaborative methods of AppSec. So, that's sort of a term that I know you've used in referring to threat modeling and purple teaming. So, can you talk about that concept, and also, how does that make AppSec collaborative?

15:08Maril VernonSo, like, talk about, like, what I think application security is?

15:15Robert HurlbutWell, or the roles of threat modeling and purple teaming in helping with collaboration in AppSec.

15:21Maril VernonYeah, I think application security is kind of like a mindset. It's a— in itself is not a methodology, right? It's a practice. And I think that there are multiple tools that enable us to implement AppSec. Effectively, right? Kind of like zero trust. Like, zero trust is a framework, but it's not something you can just, like, click a button and implement, and there it goes. And it's not like I zero trust tested this. That's not a thing. But it helps guide some of your actions to be more secure, and that's what application security to me is. So when you do things like threat modeling, you know, everyone says, like, is there a tool for this? Can I automate this in some way? Can't we just run a scan? And we're like, well, No, because when you use a human to systematically and strategically look at something as a whole, we're going to catch things that scanners would miss. Scanners are going to look for, you know, configuration items and known CVEs and stuff like that, but they're not going to catch a lot of CWEs, common weakness enumerations, things like a weak password policy. They wouldn't say you have a weak password policy and that's affecting most of your users. They would just say I was able to brute force that password. So brute force is a problem. But why is it a problem? Let's look at the source of why it's a problem and let's try to, from a policy, and people and technology perspective, change as many things as possible so it trickles down to the CVE level of stuff, the actual vulnerability level of stuff. So, we're working on the threats when we threat model. We're not working on the vulnerabilities, right? So, you can't just do it with a scan. You need humans to do it. And the people and humans who know the system the best are the ones who built it, or advised on building it, or gave the objectives for it being built. So, we have to get all those people together. Like, the ISOs are like, do I really need to be here? We're like, yes, we would love it if you were here to give input because it's crucial for all the points of view. And when it And then, when it comes to things like purple teaming, you know, again, it's a collaborative approach. I've seen so many benefits, not from even purple teaming, but just from getting lots and lots of engineers, and, like, offensive people, and the zero trust people, and the policy people on one call, and just hearing them talk about their work, or how the work they're doing affects the product. And they make so many lightbulb moments, and connections, and realizations, and realize, wow, we could work together on that, and then it would be easier for both of us. I'm like, yes, this is beautiful. This is how we build more secure applications. It's not just about the code. It's not just about the tech stack that we select. It's about how we, as humans, work together because we all have a different area of responsibility to securing that thing. And that's how things like threat modeling and purple teaming collaboration help to influence better secure design, in my opinion. Sorry, that was a long answer.

17:51Chris RomeoI think that's definitely— the collaborative method is a very powerful thing to bring different groups of people together that don't normally speak to each other and kind of open that door to have them work with each other and understand. And, you know, we've been talking a lot about empathy over the last couple of years. Like, empathy plays into that collaborative process as well, because now if I have a better appreciation as a security person for what the product manager does, for what the developers are doing, for what you're doing as a red teamer, for my network security, my InfoSec friends that are part of this equation too, it's just powerful to have a bit more understanding for each of these groups. groups.

18:38Maril VernonIt really is. And it helps because, you know, the builders and the defenders don't just see the end objective, right? They don't just see the tip of the iceberg where the red team won. Sometimes it's good for them to see us flounder and see our stuff not work and our payloads not go off and stuff not execute. And we're like, oh crap, guys, how do we get creative? And we're pivoting and we're like, if we can't figure this out, we're dead in the water. They're like, yes, dead in the water. But we somehow pull it together. Like, dang it. But, you know, it tells them that, like, we're humans too, and our job isn't as easy and flawless as we make it work. Look, nobody's is, you know? So, it makes you a human to them, and we're all humans on the same team.

19:18Chris RomeoCan you take us through a story of purple teaming? Like, is there an example that you can think of where— I'd love to get— have you take us through the story kind of, and you can anonymize it or whatever you got to do to protect the guilty or innocent, depends on how You look at the equation, but I'd love to kind of hear an end-to-end story about a test that you did, and then the collaborative process that you went through working with the different parties, and then how things got fixed. And I'd love to just, I'd love to have that end-to-end perspective on this.

19:52Maril VernonYeah, so, a lot of my purple teams follow the same formula. They're the same exercise. And what I basically like to do is I like to open up the call and say, you know, it's usually for one of my bigger orgs, it's usually following a red team operation. And for smaller orgs, I'll be given individual objectives like, you know, we want to evaluate a new solution or we're POCing a product. Can you tell us if this really is addressing gaps that we have or if it's just layering on top of something else? And what I like to do is say, these are the things we're going to be executing today. These are the things we're going to be repeating. And why? And then I start by saying, "Now listen, all you know is that we, you know, adversary in the middle captured credentials, right? You don't know how, and you don't know why we chose that method over another method. Here's why we chose this. We had all this menu list of things we could have done. We picked this one for this reason. We had the payload execute this way and tie it back to this thing for this reason because it made it easier for us to blah blah blah blah blah blah." And I'm walking them through and showing them my screen and executing. You know the exploit, having a hopping over to a user computer, going to the website, clicking the link, entering my credentials, whatever. And I'm showing them what's happening and what I'm getting from it, and why it's valuable to me, and how that's furthering me to the next objective. And I say, "Now I could have gone here or here or here. Choose your own adventure." But I went here because I knew if I got this, that would give me that, and then I would achieve my end objective. And I literally just start walking them through that, and I'm like, "Now I'm gonna do it. I'm gonna execute that thing. Go look at your logs. Go look at your alerting. Go look at your." You don't see it? Okay, dial it down. You know it's coming from my endpoint, my IP address, my hostname, my username. Look at those things. Okay, now you see it, but 2 levels up, you don't see it. Why don't we see it? And they're like, oh crap, why don't we see this activity? We should totally be alerting on this. And, you know, oh, the rule is broken. It's not specific enough. It's we didn't think of this syntax. We didn't think of this thing. And the guys are talking to each other. I don't have to tell them, why don't you try to alert on this? The detection engineers and the SOC analysts are starting to play off each other. And oh, bro, do you see that? I'm like, yeah, that looks great. Okay, we're going to We're going to try this. We're going to try this. Meryl, do it again. And I do it again. Meryl, do it again. And I do it again. And they're seeing it work in real time. And then they start seeing the logs come in and everybody kind of celebrates and it's kind of fun. And then, you know, we test it again, test to make sure the rule is working as intended. Try it from a different endpoint, try it from a different user, see if it's really working, you know, not just from one known signature, one known hostname, but like from different points of telemetry. See if you hadn't seen this alerting actively, could you have gone to the logs and seen when I did this, where I did it from, and who did it? You know, and I'm trying to fill in as many gaps for them as possible, but And I'm showing them all the places I would hide and all the places they should look. And they're figuring out amongst themselves from just that little seed of information how they can defend against it because they know their job the best, right? They know how their Splunk rules work the best, how their SIEM tool and SDLs work the best, and how all their logging works. And if logging is broken somewhere, I'm like, well, we should turn that on, see what happens. And then they just Slack somebody like, hey, can we turn on logging? It's going to cost this much money. Yeah, fine. We'll be catching all this stuff. Yeah, fine. Great. And, you know, at the end, we're able to say these are all the things that were created, this many new detections, this many new rules. goals. These buckets were created, this logging rule was enabled, this new service was turned on, we adjusted the configurations of this thing to catch 20% more of these likely scenarios than this one. And, um, we present all that at the end and say that's what came from simply drilling down on 12 TTPs that made the previous red team operation successful. Now, ideally, if the red team did that again, they would not be successful for exactly these 8 reasons. And I think that's pretty powerful. That's a very general aspect. I can't recall a specific story right now, but most of mine would typically run that way.

23:35Chris RomeoHow long is this process going? Is this a couple of days, a couple of weeks, a couple of months? Like, what's the duration of one of these exercises?

23:47Maril VernonIt depends on the number of TTPs that you're testing. One of the first Purple Team engagements—

23:54Chris RomeoRemind me what TTP is again. again?

23:56Maril VernonIt's a tactic, technique, and procedure. It comes from the MITRE ATT&CK framework. So a tactic is one of the phases of a kill chain. A technique is one of the ways you can execute that goal. So like initial entry, discovery, data collection. A technique is a sample of a way you can do that. Like brute forcing would be a method of credential capture, etc. And then the procedures are exact multiple ways you can affect that thing. But we also refer to them as TTP. So a brute force is kind of a TTP. A phish is a TTP. So, what we do, it depends on the number, but really what I try to have them do is they're very concentrated doses because I want to take, again, as little of the blue team's time as possible. So, what I'm saying is, give me all these people from all these teams for 3 straight days. Like, we log on to the Zoom call at 8, we log out at 3, I do some reporting, and we're done. And we do that for 3 days, sometimes 5 days, depending on the number. I always say dial down more than go for big. One of the first purple team engagements I ever executed. I did all of the known Mac TTPs in Atomic Red Team, all of them, like all 194. And that was a little beefy. I mean, we got through executing them. I was like, okay, another one. Okay, another one. Okay, another one. But it was kind of too much. It was like overload. And that's what we're trying to get out of with purple teaming, right? Those big, long 80-page reports with numerous findings that go to a backlog and die. So I started doing no more than like 20 at a time. Let's really focus on these 20, make sure we have these 20 from multiple points and call those good and then move on to the next batch. So ideally no more than like 3 business days and I can do all the reporting on the backend because I want to get in, take your time and get out. That's my goal.

25:35Robert HurlbutSo continuing on about purple teaming, what are some— you talked a little bit about some of the techniques that you've used, but what are some resources in order for anyone to learn more about about purple teaming and getting started and so forth? What are some things that you recommend?

25:57Maril VernonYeah, I've got numerous talks out there about, you know, how to build a purple team, who should be on it, methodologies. A great resource to start is the Purple Team Exercise Framework, which is put out by Cyph. And if you've never conducted an exercise, it's got a really great back-and-forth flow between the teams, like how a sample dialogue could go. And as you do them more, you'll get more comfortable with it. I've got talks on, like, if you have 2 people, how it could look, if you have 1 person, it could look if you have 8 people, how it could look, who could be involved, how you can play it. Um, there's different ways to do it. You know, you could have a red team ride along with the blue team and try and point them in the right direction. You could do catch me if you can and not let the 2 teams talk to each other at all. I think the best method is to let all the teams talk to each other and do it open book style. Um, and I was exposed to that at Cyber Shield. At Cyber Shield, our blue team couldn't keep up with us at all, so we ended up stopping the exercise day 2, opening our books up, and repeating everything from day 1 with them watching us. And that's where my favorite methodology came from. There's numerous great reporting tools out there, everything from SnapAttack to AttackIQ to SafeBreach to Plextrack to Scythe. They have a tool. Atomic Red Team is a great place to start if you're like not sure what to test for, but you want to kind of cast a really wide net at the MITRE ATT&CK framework and see— give yourself some baselines, some qualitative grades on where your defenses stand currently so you can focus on your gaps. I always throw my layers in ATT&CK Navigator. I'm a big fan. So, yeah, there are definitely a number of great tools out there. If those aren't a good starting place, someone DM me, and I'll give you more.

27:30Chris RomeoSo, from a vendor perspective, so you mentioned a couple of different vendor names I heard in that process. Do these vendors provide purple team-specific tooling? Or are these red team tooling? And do purple team tools exist that are called purple team tools, like things I could buy?

27:55Maril VernonThere are a number of things that call themselves purple team tools, like Plex, Track and Scythe do call themselves purple team tools. But you're going to have to keep in mind, because the purple is a combination of different disciplines, what that's really just going to do is like bring a little bit from each discipline. So, some of the tools have runbooks you can execute. You can throw manual campaigns that you've built, turn them into a runbook, throw them in the tool, So that the blue teams, as they build detections, can retest for themselves, like click a button and have it automatically script itself out. Then they can tie those mitigations to that campaign and say, you know, when first executed, 80% successful, 20% blocked, and now we're at 40% successful, 60%. They can tie it to specific operations or campaigns. You can also see the improvement of detections over time. So you've got a little bit of the red team exploit in there and you've got a little bit of the blue team reporting, the retesting hamster wheel built in in there. I always say It's best to get to get a tool. I can do it off open source, but not as effectively as if I have tools because I become a single point of failure. Right? I'm moving on to the next engagement, and they're like, "We need you to repeat that." We think we we built like we left the exercise with eight items pretty well covered for for work on this items, and we think we're done. Can can you do it again? I'm like, "I can't. I'm on the next thing." Also, we need a version of this report and this report and this report, and I become the single point of failure, and that's not effective. So eventually, your purple team will need to get a tool to start becoming effective. But your suite of tools might look different than someone else's ideal suite of purple team tools. A lot of the folks I know doing enterprise purple team for big, big enterprise, like FAANG size level, you know, like Meta, they have their own in-house tools. They have their own C2. They combine it with their own reporting capability. They have the ability to build and define their own TTPs and stuff like that. Because we have to keep in mind, MITRE is limited. It's limited to what we've actually seen in the wild. It's not everything that's possible. So you might be testing and defending against things that are relevant to your org, but MITRE hasn't published get, things like that. So, it's just important to try a product and see if it works for your tech stack, your people, and your environment, and make sure you pick the solution or combination of solutions that's best for you.

30:02Chris RomeoHow do the tools, the purple team commercial tools, stack up against somebody such as yourself that's got a lot of experience doing this? And I don't know if freestyling is the right word, but I can imagine you're doing some freestyling when you're doing a test and somebody points you at something, You have playbooks, you have ideas, but you may create something new in the process of that test. How does the tooling stack up against what Meryl has in her brain and how she can identify different scenarios and change on the fly, make adjustments to get to a successful test?

30:41Maril VernonI love that question because I get it all the time. The answer is it's the same as what automated tools do for pen testing. So, it really helps to have the things that you can have automated, automated, right? You don't need me to manually try and download known malicious tools that are signature-based. Let's have a tool do that and see if it's successful, and if so, where and why. You want me to be spending my time on that manual validation of the really critical issues, on that getting creative, on that building my own thing, like doing my own secret sauce. So, I like to use the tools to give myself, you know, some foundational items covered, maybe give myself a good starting point for my manual investigation. Automate as much as possible so you can spend, you know, that 20% of your precious manual time on the things that matter, the big impact items, the blast radius items. So, that's how the purple team tools really help you as a purple teamer as well. It's the same.

31:32Chris RomeoWhere do you see purple teaming going in the future? Like, is this something that it will eventually solve all the problems and then we'll move on and we won't need it anymore? Or where do you see this going?

31:46Maril VernonI love this question. I'm so happy you asked. I actually see purple teaming again as not being a dedicated team. Let's not just put the pen testers and the SOC analysts and the detection engineer on a team and call it the purple team. Let's instead move towards a collaborative security mindset. Let's let a lot of teams talk to each other all the time. Let's have them playing off each other's exercises and outputs all the time. You know, if the blue team creates a new process, I as a red teamer want to know that. I want to know what your investigative process is, because if I'm like, hey, if they see this over here, they're gonna drop everything they're doing, investigate that 10 layers deep, and waste all their time. So, we can inject over here, we can mess around over here, and they won't even know for hours. You know, that makes me a better tester, and then they'll develop a process to address that, and it makes us each be better. And I think that's the future of purple team. It's not gonna be a proper purple team, an orange team, a green team, a blue team. It's gonna be just all of us working together. And from a light spectrum perspective, that's, you know, white team. Yeah. Teaming, combination of all the colors. So, it's just like MITRE's implemented white teams for years now. I think 2 years they've had white team leads for the evaluations team. And white teaming is truly the combination and the embodiment of collaborative security from all the disciplines across the org. But I think eventually, you know, AI tools, we already see a good number of pen testing functions being on the way out because AI tools will, Again, really beef up that automated process. You can never get rid of humans completely. There are things red teamers can do that automated bots and AI and tools cannot. But a lot of purple teaming will be automated. And, you know, we will find better ways to feed each other information and get more visibility. And then purple teaming as a proper practice, dedicated purple teams won't be a necessity because you'll just have like total security solutions, cyber resilience departments and stuff like that. So that's where I see the future of it going in the next Let me read that back to you and just make sure I understood.

33:45Chris RomeoSo, from the tooling, so, the tooling, the purple team tooling is good to check things that you've already put your seal of approval on. So, like, if you leave and go somewhere else, the tool can replicate whatever the test was that you did if they want to test it every day for the next 2 weeks because they're trying to solve the problem.

34:04Maril VernonRight.

34:05Chris RomeoSo, the real benefit of the tooling is that the tooling will allow— make some of the parts repeatable. It doesn't have to be creative at that point because they just wanna see, did that log fire? It won't fire. We'll try it again tomorrow. We can't figure out why this log won't fire. They don't need you sitting there typing manually, right?

34:21Maril VernonCorrect. Yeah, you got it. Absolutely.

34:32Robert HurlbutAll right. Well, Meryl, we really appreciate you joining us today. We want to sort of finish out, and we've got a few questions that we'd like to ask you as kind of our lightning round. So, first one is controversial. What's your most controversial opinion on application security, and why do you hold this view?

34:52Maril VernonDevelopers and red teamers should be friends. We should be best friends. We're all on the same team, and I hold this view because I know that it's an us versus them, and we shouldn't give them a you know a local user account and assume breach. They didn't really do their jobs if they didn't get through the firewall. And let me tell you how ineffective that makes our security program as a whole. You don't want me toiling with your firewall for two straight weeks because eventually I'll get past it, and that was a waste of time. Let's test the defense in depth. Let's see if all of the micro segmentation and all of the user groups that we've defined and everything else is working as beautifully as we hope, because you get what you inspect, not what you expect. And I know we all think we do a beautiful job when we. Code something to perfection, but there's going to be something we miss because we're humans. We're humans, and it's really important to let us get in there and find the bad stuff and look under the rug before China tries it. So red teamers and developers should be best friends. If you're not best friends, become best friends.

35:43Chris RomeoLove it. I'm just writing down what you said: You get what you inspect, not what you expect.

35:48Maril VernonNot what you expect.

35:50Chris RomeoNow, is that an original line? Is that is that original Merrill line?

35:56Maril VernonUnfortunately not. It came from my very first CISO ever, the guy who gave me my first pen testing and InfoSec gig, Bertram Carroll. Genius of a man.

36:03Chris RomeoAnd make a great CISO.

36:07Maril VernonHe would say that to me. Yeah, he would say that to me all the time, all the time. It's ingrained in my brain.

36:13Robert HurlbutDefinitely. That's great. All right. So, here's another one. What would it say if you could display a single message on a billboard at the RSA or Black Hat conference?

36:26Maril VernonGive more non-traditional talent entry-level positions. Give more people entry-level jobs. So many orgs are afraid to trust their security program to newbies like I once was because they're like, ah, it's gonna crash and burn, you're gonna mess up, you're gonna take a table and prod down, you're gonna miss a false— like, you're gonna think a false positive is real, or worse, that a false negative isn't. And I'm like, let me tell you, you're already not doing a good job anyway, so why don't we just let the newbies come in here and try. Why don't we just get more people in there and give your oversubscribed, under-resourced departments a break so they can come in with better invigoration, better creativity, more clarity of thinking, get more diversity of thought in there? Because if no one had given me a chance 4 years ago, I wouldn't be here today. Security wouldn't be where it is today. Purple Team might not be where it is today. So, uh, give more newbies a damn chance, please.

37:14Robert HurlbutExcellent. And what's your top recommendation for those interested in security, and why do you find it valuable?

37:21Maril VernonOh, to get into security, for me, my most valuable book was the all-in-one book that I read for my first certification, Security+. I think it gave me a really good 360-degree view of that top, like, 10%, why we do things, where they come from. I think those are valuable. I think books that are specific to your vertical are really valuable, and there are a number of them. So, I liked The Pentester Blueprint. But if you're into secure coding, there's Secure Code. There's, you know, macOS books out there. But honestly, for career development, my 2 favorite books are The First 90 Days and Make Your Next Move. Because The First 90 Days talks about if you're in a new position, if you're in a new industry, or if you're in a promotion even at the same org, how do you prove value in your first 90 days? Because there's There's a value curve where you're sucking resources from the company as you learn and as you orient and not giving much back in value. And then you need way less input and stuff from the company as you give massive value back. And that's a way to reduce your break-even point on that curve and start providing value back, getting immediate wins in your position, demonstrating some change to prove that you're good at your job and that you can be trusted with the next job and more budget and more people. So, I think all InfoSec professionals professionals should read that book.

38:38Chris RomeoYeah, it sounds like a great book to check out. What would be your key takeaway or your call to action for our audience here? If you can give them homework, which you can, I don't know if they're gonna do it. I'm not gonna ask them. I'm not gonna check the homework. But, you know, what would be a key takeaway or a call to action for the audience?

38:57Maril VernonTo start getting on collab calls with each other. That's where it can start. Red teamers, please reach out to other people in the org, not just the technical departments, not just the devs, Not just your SOC, not just your detection, not just CTI. Reach out to the business departments, the finance people, the audit people, the operations people, and start making yourself a human and an ally to them because they will become your insiders, right? They will become that insider information you can CTI use to influence your operations and punctuate big problems for your org that aren't getting enough time and attention. And to everyone else, please reach out to us. You know, we're humans too. We want our paycheck to keep being signed to, we are either all gonna be breached together or not breached together. So, I just think that a lot more people should get on collab calls and just see what happens, see what products emerge as a result, see who starts collabing on stuff. Like, the most insane people, like, when you see compliance and devs collaborating, you're like, this is weird, but I love it. So, I would love to see more of that. So, I would just urge you all to reach out to each other, Slack each other, say, hello, I work on this team, I'm interested in what you do, this is what we do, can we collab? And just see what happens for your org. You'll be surprised.

40:05Robert HurlbutDefinitely all good advice. So thank you, Meryl, really appreciate it today. Really enjoyed talking with you and just learning some more about AppSec and purple teaming and intersection with threat modeling and many other things. So thank you again, really appreciate you joining Thank you so much for having me.

40:32Maril VernonAnd by the way, threat modeling and purple teaming are great tools to use to influence operations like pen testing and zero trust implementation. If that's what you're interested in, you should check them out.