← All talks

Switching Sides: The Practical Benefits of Switching from Red to Blue to Purple

BSides Charleston · 201956:30585 viewsPublished 2019-11Watch on YouTube ↗
Speakers
Tags
About this talk
Security BSides 2019 College of Charleston, SC November 9, 2019 @BSidesCHS Title: "Switching Sides: The Practical Benefits of Switching from Red to Blue to Purple" Speaker: Maddie Stone (@maddiestone)
Show transcript [en]

welcome to Maddy stove [Applause]

let's see if I can figure out how to turn a microphone on there it goes so hi thank y'all all for showing up early morning on a Saturday a little chilly and thank you to Paul and the rest of the besides Charleston crew for having me here I'm really excited and it's my first time in Charleston and walking around yesterday it's gorgeous and so much good food so thanks for having me but this morning I want to talk about switching sides and sharing the practical benefits that I've seen in switching from red to blue to purple so first Who am I my name is Maddie stone my pronouns are she and her and as Paul said I am a security researcher on

Google's project zero team and have been in the InfoSec community for about seven years now which has predominantly been all reverse engineering but on a lot of different sides which is sort of what I want to talk about today I also like to speak at things and do some other stuff my twitter handle is Maddie stone really great at OPSEC you know and everything like that but that tends to be the easiest way to get in touch with me and I'd love to continue talking and chatting with y'all after even today in this conference but getting into this what is my goal for this talk what am i hoping to take advantage of this chance

but y'all are giving me you know an hour of your time which you know Wow thank you um is I want to encourage all of us to continue to consider switching between both the offensive and the defensive security roles be willing to try the other side even if we feel really proud and really tied to the current side we've been working on and also talk about how together not just as individuals I do believe it benefits all of us to become more purple instead of just starkly red or is blue but first I'm gonna share this in my points of view from my experiences I can't really speak to each and everyone else's so I want to share why I

believe it's important to switch from red to blue why I think it can benefit you from my experiences doing it and really getting into sort of the tactical practical benefits but sort of surprised me and that I saw so yeah disclaimer my opinions so just to level set what do we mean by red and blue and purple what are these different sides if you go ahead and try to start googling looking for an exact definition of what does it mean to be red security what does it mean to be blue you're gonna find a lot of different opinions so before we get into the rest of this I just wanted to talk to you about where I'm coming from and

what I mean when I say those two so we can sort of level-set so first red so to me the red side of InfoSec is where you're adopting the adversaries TTP's meaning techniques tactics and procedures as well as their point of view in how to test an organization so you're still doing this to make things more secure but you're doing it from the offensive point of view and you're really trying to emulate and push that device that enterprise that organization in showing this is what the bad folks are the bad actors could do to us so how do we get better and securing against that and here are some of the roles or actions that to me clearly into red

and it's obviously not comprehensive but first we have penetration testing which is sort of the most broad you are trying to break something that could be in the hole into an organization it could be trying to bring one specific piece of software could be trying to get into and steal information from a device but you are trying to penetrate the security boundaries as an attacker would the next one instead of focusing more on this a lot of the technical control maybe physical controls you're focusing on the human element of security so that's social engineering and so those might be included in pen tests in terms of you know fishing exercises where you're trying to craft fishing emails to

see how many people in our organization is still didn't respond or fall for it as well as trying to solicit people information from the different organization the next one getting more into less of the human Enterprise section more into just the technical aspects is vulnerability research and so that is where software device you are looking for specific vulnerabilities but then often through coordinated disclosure or other things you are trying to get patched and fixed so that is the more targeted let's find that vulnerability and get it fixed adversary simulation being a sort of type of penetration test in a lot of ways but in an adversary simulation you are specifically trying to use the exact

sort of modeling your behavior and actions after a specific adversary so sometimes that is for you know the state-sponsored actors of they want to do a really intensive penetration test knowing this state-sponsored actor usually has access to this type of scientific equipment they usually have this much skill this much money and so we are going to do that much more sophisticated or it could be our threat is script kitties so we want to do an adversary simulation of how far can someone get by just using what you can generally find on github or things like that and then another form of read is exploit development so you are maybe doing vulnerability research maybe you are trying to craft a patch so not just

using a zero-day but an IND a meaning it should have been patched a few weeks a few months a few years ago you go ahead and weaponize it into an exploit to then test against what your network or your device or your corporation and so these for me are all examples of what read so it's a lot bigger than just when we talk about a red team in an exercise or a red cell within a security team it's much more broad in all of these actions that is doing security are trying to do offense for the sake of defense and on the other side of the coin we have blue so the blue team's are

trying to protect though and organization's infrastructures and devices from the attack and so they're also the ones building and maintaining all of the defense's a.k doing the defense for the sake of defense rather than offense and just like red there are a lot more than just the blue team on an exercise or the blue cell they're doing a whole lot of defensive defensive actions I'm often using the same technical techniques as the red side but for a different purpose so security ops centers socks and all everything that goes along with that of monitoring trying to understand when there might have been an intrusion responding deciding of it's false positive things like that is obviously in the blue side

malware analysis so on red you may be using reverse engineering skills for vulnerability research exploit development where you can use those exact same skills for blue in terms of malware analysis and making that decision one is the sample good or bad to how it is it work why might it be successful how much priority do we need assess and learn and what type of defenses do we need to build threat intelligence is getting to behind that malware analysis meaning who are the actors how is this being used and the larger context Incident Response is another category of blue meaning we need to respond immediately figure out what's going who do we need to pull in and finally

digital forensics looking backwards to decide what did happen versus what is happening now what can we learn from it how do we need to change our actions and so this is a very broad but quick overview of some of the types of roles and actions that fall into red and blue for me and while this might have been a basics or a refresher for some of you I wanted to make sure we're all on the same page as we talk forward and if oh okay I need an update Chrome

so if you did not see your role listed here you know whether you're likely doing security work or you are helping security through offensive defensive and it doesn't mean it's any less but so let's just get a feel of who else is in this room for us I'm going to ask you to raise your hand if you identify more as red if you identify more as blue or the third option is none of the above all of the above somewhere in the between so first if you identify more on the side of red security raise your hand okay we got a sprinklin in here what about blue sweet we got a lot of blue teamers and a

lot of pride associated with that too and none of the above all of the above something cool that's great so I'm glad to see some one of y'all in the middle too and I want to encourage you to continue chatting with each other finding someone who might work in a different area than you do as we go through today because sometimes these events and conferences the talks are great and I'm glad I'm not talking to an empty room but the networking is really one of those aspects and learning about other people's experiences and jobs is what we can really get out of these types of things so based on that why did I think this talk might be interesting important

worthy spending an hour on and it's largely because in the many years that I've been in InfoSec including myself you know looking at myself too is that I've noticed there's a lot of I didn't tea associated with whether you fall on the red or the blue side of the spectrum and there's a lot of pride with that and having pride in our jobs is great but not when it's to the detriment of seeing this really start strong red vs. blue paradigm that were not able to break out of and so when I was thinking about this I first in figuring out how did I want this talk to go I decided to post a tweet asking just what is it that draws

you to either the red or the blue side of InfoSec what are the things that you're interested in and just seeing what the responses may be and it was pretty maybe it was confirmation bias but it was a pretty interesting and so the tweet is also linked down at the bottom when I'll share but the first one I'm gonna go through some of the sample responses so one is red is nice because you get more tangible wins but sometimes feels like just playing a game I find blue feels more real and growing up of course both sides matters though there's a serious Russian gaining access to a system designed to keep you out is there a thrill in blue I prefer red

because I can't cope with being blue and waiting for something to happen instead of actively working on preventing it before somebody else has the idea of doing something stupid red sounds insanely boring we all know everything is vulnerable and given enough time you will always find a way in potentially by doing the same thing over and over again blue solves problems and hopefully classes the problems instead of just pointing at them red team is just in me I'm also bad at building things and quite good in the breaking department sorry straightforward blue is where I have the highest leverage value for the business I can work to eliminate entire classes of blog bugs as blue wear red tends to

be constrained to finding one red also usually lacks the authority and positioning to drive fixes handing off yet another report full of fun that will be accepted without oh okay what are what are they accepted without oh no sorry I tried to get all cool with the graphic said bring forward oh computers man there it is accepted without context isn't useful the Statue of David could only have been created by a handful of artists any three-year-old with a hammer can destroy it I like creating over destroyed so obviously what I thought might be a somewhat benign question evokes a lot of feelings and a lot of opinions over one side is right one side is wrong the other side's

boring I'm always this other side and so to me I thought this was worth chatting about because it did go along with a lot of my experiences in InfoSec and even sometimes my personal views of red versus blue too and so I think that maybe we don't need to have such strong ties to the red or the blue side and I don't know that it serves us to have this much pride this much fundamental dislike for wanting to work on the other side of the coin and because what these tweets were to show me is that there was this fundamental cyclic simplification of the other side an example is that tweet that said blue just has to sit and

wait for things to that happen because a lot of the blue teams I've seen they're actually quite proactive and of course they have to be reactive when something happens I mean that's their job but they're not just sitting around waiting and what I've seen in terms of red is red is often a very nuanced approach to breaking and choosing what to break and how to present those findings to hopefully evoke change and so it's not just that they like to break things they'd just like to sit and wait there's so much more nuance to that and we don't necessarily have to have this forced dichotomy of my sides better my sides more fun my sides has

more impact because when it comes down to it we're all in this for the same goal we want to create a more secure internet more secure enterprises so all of our society that is using this crazy amount of technology that is sort of awesome but also being forced upon us does not mean that we are in harm's way and so I think by merging the red and the blue a little bit more in understanding each other and walking in each other's shoes we can only push forward this goal of securing everyone more easily and thankfully there seems to be some people on the thread who also had this point of view and they shared that they either worked on both sides

they had a lot of respect and liked both sides and things like that so for example protecting this person said they liked both sides blue because they get to protect people there's a mission associated they don't like to kick bad people's butts the red side there's this curiosity anarchist tendencies and a thrill of ponen another one said yes they're more drawn to blue because the results are more durable but they acknowledge there's not really any quick wins but they also know that none of their work would happen without the great minds on red who demonstrate to them how something's broken and so that they can fix it and there were a couple people who on their own came up and

mentioned they see themselves as more purple as well I prefer to dabble in both sides of the force and then some people also get the opportunity to split between about 80% blue work 20% red and it sounds like based on the raise of hands some of y'all in this room are lucky enough to do that as well and then this one really seemed to evoke to me what I felt as well of red is exciting because you're looking at us I'm trying to understand how it works it's like a Rubik's Cube for the first time it's fascinating it's exciting is frustrating because you never really know if you're close to being done or not and blue is interesting because you

get to come up with ways to address security gaps while balancing business and usability needs but it's challenging because it requires dealing with push vests and s escalations but finally they acknowledge both sides of pros and cons and it's just unfortunate that some folks claim one is better than the other so I'm gonna take off through now hopefully I have convinced you that I think our community could use a little more purple in their lives rather than just red and blue and I want to show you why I started out being very clearly on one side of the bar but then I've seen very practical benefits that I didn't expect from switching back and forth

that kind of surprised me and have made me a believer and the color purple too so story time I was really lucky when I was in undergraduate degree and CS that I did get an offer right out of school and it was to become a penetration tester at a government research lab write-up epic right up the coast at Johns Hopkins Applied Physics lab and so my first day on the job they gave me a box and said we want you to see how you can break this looking back it probably should have had a little more structure but it all turned out for the best and I went started going through a lot of blog

posts of people I'm lucky enough to call friends and somehow found my way to a root shell funny story I didn't actually realize that was the goal of doing the penetration test and so I went to the more senior engineer who was like my point of contact at the time and I go okay so I've done this thing I have a linux shell what do I do next he goes you have a little shell it was like yeah you know this was a radio device and she was like what user are you and I was like he was like type the who at my command because I didn't even know that much and so I was like Who am I

and it was like route he dose you're done I was like oh did I do something wrong no you owed the box it was like oh and he's like no you gotta write it up and explain how you did it what you did and what people can do better and that was really hard but because I had found a way to break the box but now I had to see what comes of this how do we make it better so I did about six months as a pen tester and then they gave me asked me if I was interested in taking part in an adversary simulation where they really needed me to be a reverse

engineer and I had never done a reverse engineering before I didn't really know what it was but they were like on your resume you have all this computer architecture experience I've been the TA had helped everyone my favorite language was assembly and so they were like putting some pieces together here and so in that case we were trying to emulate a state-sponsored adversary spend six months on this device to see if this fault fell off the back of the truck what could we learn from it and so we spent all this time you know basically reverse engineering every line a firmware just seeing what can we find what can we learn about this device how

could we attack it what information would be lost and things like that and then I also for the following four years after that I was basically all reverse engineering all the time because I really do just love assembly but it also got some offensive security research and they're doing vulnerability research as well as exploit dev and so at this time in my life I was very solidly read I was that person that was like read is fun blue is boring you sit and wait and after four and a half years of doing this work Google called and I they offered me a job to be a reverse engineer on the Google Play protect team which is doing the hunting malware on

all Android devices and I wasn't really sure but also it was Google and I figured I'd been doing the same thing for four and a half years I was comfortable I knew I knew like could figure things out in this little niche space I was working in so why not try something else so I packed everything up moved to the west coast and for two years was working as a malware analyst for Android security dominantly in the off market and the pre-installed spaces so that's where the device and code auditor comes in because I was going through all of the Android OS devices prior to them shipping with my team trying to see is there a security vulnerability here is

our week going to is there malware is there's some sort of issue that we need to prevent before it launches to users and in the off-market space we that means everything that's not on Google Play so in the u.s. North America in Western Europe Google Play is how most people on Android devices do get their apps but for the rest of the world where there's billions and billions of users of Android devices they predominantly do third-party app stores peer-to-peer sideloading where you download it off of a computer and then often use a USB to load it onto your phone and so this was a huge space of applications that we were also trying to vet and find

anything that could harm users in and so suddenly my reverse engineering skills had to change drastically because I went from reverse engineering one person piece of firmware for six months to needing to get through a hundred apps in a day when I was on a queue and so at first and to be quite honest I had thought I would find moving to a malware analysis position kind of boring I was coming from this background of doing hardware and firmware exploitation which I thought was cool because you see all these things the world - moving up to Java apps and in my you know sort of one-track mind brain I just didn't get how I would find

the challenge and fun but then I started tackling large-scale investigations working to protect users and there was this day earlier in February where I was leading an investigation in what we named the chinois botnet which I've talked about elsewhere before which at one point infected 20 million users around the world and was growing really really quickly we saw droppers trying to get to hundreds of millions of devices and so I guess February 28th 2019 I put in a solution that was going to protect and block on all 20 million devices where it currently was but also prevent it from being able to affect other users and suddenly that high that you get from ponying a box didn't even compare to

that feeling of knowing within 72 hours 2.5 billion devices we're going to check in and get that protection so my mind started to change a little bit then in July of this year after about two years I switch teams within Google to Google Project zero if you don't know what the project's your team is it's we're about 15 security researchers who are our goal is to make zero-day hard a zero-day is a vulnerability that defenders don't know about so really only attackers have found this vulnerability and are trying to exploit it and these zero day exploits that use zero day vulnerabilities are especially difficult to prevent and detect and fight against because the defenders don't know about

them you don't know you need a patch you don't know this hole exists and so our team sort of mo for the last five years has been to hire security researchers to try and find zero-day vulnerabilities in the same client devices that the bad actors are so I phones Android windows things like that and the goal is to have bug collisions which means we're finding the same bugs as the bad actors are but we reach out to the vendor behind the device to get it patched within 90 days and delivered to users but when I enjoin project zero I was joining to start a new role for them whereas the conventional project zero work has been pretty read in

general you know it's that Volant pretty pure vulnerability research I was going to be doing a hybrid vulnerability research and threat Intel and so now I'm in this new more purple position because some of the goals of this hybrid is that I'm going I am studying zero-day exploits use in the wild in order to glean how can we better find other zero-days make it harder for them to use new zero-days in a while and things like that so an example of that is is when a zero-day exploit is used in the wild do the root cause analysis not just the basic okay we think it's this bug is should say use after three probably in

this driver and it's going to get patched really go down into how exactly did this bug work and how can we what can we learn from how they likely found it and things like that and so that's a very blue action because it's sort of like malware analysis where you're looking and then looking back at what attackers did but then using that in terms of red team to inform where should I go in hunt for bugs so for example when you are a vulnerability researcher you often find more than one bug at a time because the developers are usually using a pattern that they have written more than once at a time but when you

know bad actors find that bug or find those bugs they only need to use one in their exploit so our goal is to or Michael is after I've done that root cause analysis do you then use that to inform variant analysis and hopefully burn the rest of the bugs that those attackers have in their cache and so that's sort of an example of purple of now using these reverse engineering analysis skills in both the offensive and defensive ways to hopefully make zero-day hard so I've switched a couple different times I told you I didn't really want to switch necessarily all the time wasn't feeling drawn to it but I've seen some really exact and somewhat

surprising benefits to myself my career my team that hopefully might help you as well so how did red experience help me be a better blue team err so while I was on the Google Play for tech team I said we worked on queues and this was in our pre-installed apps queues so Android has about eleven hundred different OEMs so om meaning like Samsung Google wall way bebe cool cool mobile you know all these different OEMs that predominantly are selling phones and regions other than us and so that means we have a lot of apps to get through and bet when the automated systems say hey this needs a human review because I can't decide if

it's good or bad and oh yeah there's also a 24 hour time limit on this for us to give back our feedback and so this app came into my cue it looks like your run-of-the-mill Diagnostics application yet I couldn't let it go to me I just kept saying I think something is wrong with this my gut is telling me there's an issue here and I couldn't put it back to work and my teammates as well as my manager kept saying mani it's a Diagnostics app we we don't have to like them but it's not it doesn't break any of the exact rules because we see at the top this application was connecting to a socket and it was receiving information

and it was writing it to a log and so we're usually only supposed to spend about five to ten minutes on an app yet I could didn't feel that I could fly this as a false positive something still felt off even if I could not burp verbalize consciously what it was about it so after looking way way too long and not listening to my manager in my teammates I found this method that was called proc GM string and what it was doing is it was taking all the commands that it received from the remote socket and writing them to a file a file that is in the apps private directory under the cache and that

seemed weird because I didn't really see other things within this app that was using that information so why would they just be writing commands to a file and not be doing anything so at this point I'd spent most of the day on it and my manager was like you still haven't got anything you need to let this go and move on to the next app so instead I stayed up all night because I still couldn't tell them why but something just felt so wrong and finally I think it was like midnight or something I found the first time I found this daemon number 1 which is a binary running on the firmware image of the phone that was

reading and monitoring that text file in the apps private cache directory and this was interesting and res raised red flags because files that are in an Apps private directory are supposed to be sandbox there it's not usual for them to be read written modified by outside components within the device and so this was a little flag I needed to keep going drink more coffee stamp and keep figuring this out because I've gotten another hint and then I what I found is that I put together all the pieces of this arbitrary remote code execution backdoor and so the way the backdoor worked is that we had this pre-installed app that communicated with the remote socket it would write to that text file

any of the commands that remiel received from the room socket daemon number one would then read all the commands from the text file in the app directory and write them to a kernel character device that kernel character in device was then monitored by a second binary daemon on the device which looked for any commands that were between the tags exs H if that command was whatever text was in between those two tags it would pass directly to system system is a Linux call which means execute this directly and so then you have an arbitrary remote code execution back door where a remote entity can cause any commands they want to be run on this device and to add

insult to injury they had modified the SELinux policy that was running on the device to give daemon number two extra privileges so it basically was as close as to route as you can get on Android so looking back we all sort of wondered what was it that made me not let this go and not be willing to say okay I've looked I can't find anything just go and I think it's easy at least for me a lot of the times to say oh it was just my intuition it was just my gut I was lucky but what it turns out is funny situation the more work I did the luckier I got and when we tried to dive into this even

more of why did I find this when the rest of our malware analysis team looked at it as at the same time I was in saying no it's fine is just a diagnostic app and then we finally got down to it thanks to a senior mentor who kept pushing me and pushing me to say more than it's my gut is that I've written backdoors before in terms of adversary simulation exercises and the way I had actually done it twice was put it in administrative code and in nine gnostics code and I had also broken it up into different chunks never putting all of the code to gather in one place and so even if I

consciously was not able to say oh yeah this looks like a back door that I would have written your intuition your gut grows from all of those different experiences and so it can tell you that something looks off even before you consciously say this is exactly the red flag and why I think we need to do more work here and so by doing a diversity a diverse type of work that I'm gaining in diverse type of experiences we teach our gut we teach our intuition to find more of what helps us recognize the bad in a sea of false positives and when you're on the loo team and have so many samples so many signals so many different things

that you're trying to filter out and sort that can come in extremely handy the other thing I found that really really helped me in terms of blue team is that by starting in red where I'm used to reverse engineering things for long periods of time used to having a lot of failed bugs that turned out to not be exploitable looking for vulnerabilities or bugs that did not actually exist it grows a different type of persistence than pure blue team does because you're used to the failure after failure after failure of not finding the way in and continuing to stay until you find it or find a way in that I think helps inform that blue of even though I

were supposed to stop working after five minutes of looking at the app I just knew it had to be there and so I kept with it for much longer so that's just to practical examples of how I've seen red experience help me be a better malware analysis Blue team err but then I I definitely found some skills through blue side work that have that I wished I would have had in red and have already helped me in this new purple role on the red sides of that so first you have to be so efficient to be to work well on blue because as we say there is so much you're trying to sort through to find those few nuggets of

badness to block that you don't have enough people most of the time and so you have to prioritize and in particular my scripting and tooling capabilities got so much better when I was working as a malware analyst versus as a vulnerability researcher and the reason because I saw a lot of samples that were packed for example meaning they were obfuscated you couldn't clearly see what the code was doing and so you have to make that decision of how do I quickly get this unpacked so that I can decide whether or not this sample is bad and whereas previous to joining blue my goal was always to understand how that packing mechanism our obfuscation mechanism work that I'm reverse

engineering to understand and then I can write my tooling solution what I found in malware analysis is that I don't actually have to always understand how the Packer works how the obfuscator works I just need a solution to one packet and so what that meant in terms of scripting which I often did I had a Python scripting where Ida Pro is the most commonly used is assembler for reverse engineering is I did translation rather than understanding and writing a new solution so I would just translate their code where their D obfuscating around packing into a tool that I was going to run on the sample so that I didn't have to understand what the algorithm was were they using this

version of encryption I just needed to get something else to run it on there and so I've now even seen that in my bug hunting work for a project zero of really taking that deliberate choice of do I need to understand all this code or do I just need something to accomplish the goal and I've also found that I'm a much quicker at setting up environment for tooling because I'm not setting it up necessarily for a long-term engagement or exercise I just need something that will solve the problem now another example is attack surface selection so I think this might be one of the most obvious benefits you could see from blue to red I think everyone in this room

would guess that when you switch between blue or red if you're going from blue to red it's helpful because you learn how people are trying to attack whatever you're defending so you get better at defending against those attacks and the opposite is true too if you know how defenders are defending it gets easier to attack but at a more specific level when I was working in blue for the Android security team I got a much larger and broader knowledge about the whole attack surface because I was not no longer just trying to attack this one driver for example running on the phone I was responsible for defending the whole device so I had to understand then

how does that driver interact with the SELinux policies what dak isn't running under and things like that and so that helped me then understand at a larger scale where our holes I might not have concern previously because I was focused on attacking this one piece but it also helps in terms of understanding priorities so if you are a red team or if you are in a penetration test or an exercise and you're a red team you need to make decisions on what goals are you trying to help accomplish and so understanding the choices that the blue team has to make especially in terms of priorities where are we prioritizing our defenses that can help you make your

choices of what to attack because in some cases you may choose I want to attack the same thing that blue team is choosing to prioritize in terms of Pence's because then I'm really testing what they believe is most important and they're putting all their resources into but at the same time you might choose the exact opposite choice as well because you may say I disagree with your choice to put all your resources into this one section to defend against I don't think you are prioritizing correctly and I'm gonna show you why with practical results but then you can take up to these X in order to get more resources for so there were two cases

that already on project zero I've seen a tech surface understanding to help me his first we did a bunk bash against an a specific Android device and we were doing this super quick about 48 hours of work to see what as a team could be fined and I chose to focus all of my analysis work in my bug bashing against the areas that I knew had been so tough to defend against on the other side as a malware analyst where I was like these gaps exists and fundamentally there's not a good way to close them right now and so that was super helpful in helping me quickly dive into this 48-hour bug bash to start trying to find things on

this device I hadn't looked at before and another example was I recently released the public bug in Android binder driver that was a zero-day being used in the wild and what it was doing is in the binder driver which is a pretty integral component to binder does the inter-process communication there was a a wait queue object for polling was not tied to the lifetime of the file that it was monitoring and this allowed for a use after free which then could be was able to be used for a kernel privilege escalation and we found it in this one place the attackers who are using the zero day in the wild also found it in that place and I wanted to

do variant analysis because this seemed like a pretty easy to do mistake in terms of a develop of not tying the wait queue for pulling along with the file handler and so I went through the Linux kernel and I wanted to find every place that they used pole weight function turns out that was two hundred and thirty six different places that they had pull weight and I needed to figure out how do I filter and vet these because that is a lot of tedious work time whether you're on red blue or purple is usually the most important resource you have and so what I did was that I focused and tried to do it in the same way that I looked for

malware variants what is the piece that matters that was the pole way and then how what type of signals would make this more likely to be occurring as a actual bug verse is the benign not a bug usage of it and so that came down to looking at who had submitted the change for the original bug and finder did that person submit any of these other changes what type of drivers were these pol Lisa were they similar to binder where they have their pretty privileged not super sandbox or were they a very specific use case that maybe one device in the world used and so this really helped me use those malware analysis skills of you

have so many examples how do you filter down the sample size to this red skill set of looking for vulnerabilities the last two that I have seen drastic improvements from in terms of blue side of being red and learning from blue was communication and this was kind of surprising to me because I thought of myself as a good communicator while I was on ret to but in terms of red I often just had to stick to the technical how do I explain to you what I did and then you off they then the blue team with the one who has any choices defenses stuff like that based on the information I gave them on blew my

timelines were often shrunk much quicker than the report writing and communication skills in red and I also needed to persuade execs who have a lot of other concerns besides just security to make the choices I wanted so my communication skills something I had to portray these technical details to a non-technical audience while persuading them that this is important and I want you to take this action and so I found that I became much more concise much more quicker in my writing and really focusing on the important parts for that in also in interpersonal communication a lot of the people you're working with in the middle of an incident or an intrusion they have a lot of other things going on too so

how in those oral communication can you communicate what they need to know and decide what they need to know quickly and effectively and lastly is teamwork I didn't realize it at the time but looking back now it was obvious is that read is often a very solo activity even when you're working as a team you're often working on one specific part yourself and then maybe you're the reverse engineer looking at this driver they're looking at network you have someone else looking at social engineering so yes you're on a team but you're often one-to-one on the computer by yourself whereas blue you're often having to coordinate with so many other people you're trying to coordinate with your

direct team members who might be doing the same role to prioritize slice up share delegate that whole sample size you're trying to vet you're trying to interact with program managers project managers execs who need to to understand your technical expertise to make choices you're needing to work with for example incident commanders or the software engineers who are building those defenses that you believe should happen and so my team work skills delegation things like that have deaf grown from being on blue as well and what was cool is I also saw this reflected in the Twitter thread that I mentioned earlier of some people really like blue because of the teamwork aspects that they've noticed in

comparison to red and so I think that's just a really cool hopeful vibe as well but overarching what I learned from blue was tactically I learned how to work smarter not harder you're never going to be able to find every single hole that exists in blue every single way to get in there whereas red you're often only having to look for one to get in and so you have to become that much more efficient smarter work with other people to collaborate and so I think that's the biggest thing I have brought in now into my purple red actions is how to works intelligently so I've shared some reasons and the benefits for me that I

have seen from switching it up but I think it'll smell it comes down to is whatever side of security you want to work on and I think it's totally fine to have a side you're drawn to more I mean I still do I think it makes us all better and when each of us as individuals are better at whatever security we do that makes all of our teams and our whole infrastructure as you know technologists working to help secure people it makes it stronger more secure and things like that but now what hopefully if somewhat commenced you who those of you who felt pretty strongly on one side of the other that you should switch it up but how might you do that

so first from an individual level it's hard I wouldn't recommend necessarily any of us quit our jobs and say I'm looking for a job on the other side but I think that we can still find opportunities to work on the other side whatever you may consider that for you so whether that's partnering up or if you are trying or partnering up with a team that maybe they have a rotation opportunity or an opportunity for you to jump in on a single project or if you are you know looking for a job being willing to consider those on say the blue side if you've always been red or on the red if you have always been

blue even if that's not what you think you're especially good at or have the experience and yet I also think it's important to regularly meet and have lunch with or chat with folks on that work on the other side of you and I think one of the biggest things I get out of these chats is asking them what their challenges are in understanding why what they do is hard and that helps give us a little more empathy and understanding for the other side as well but I also love to ask what are you doing that you think it's cool because that really can show you these cool things that it's not just blue it's not

just red there are these other nuances and challenges that they have to put into their work and the choices that they make and I think all of our goal can be just to become a little more purple in general than our work in our considerations of how we go about whatever our roles are but at the individual level that's fine but there are some industry blockers that make this hard for each of us to make those switches I mean as much as they say that there is these this huge amount of open roles in InfoSec you only have to go on Twitter for a few minutes to realize that people are really struggling though to find all these so-called open roles

and that there is a lot of gatekeeping there are a lot of experience requirements that make it hard to make those changes or try something new so I think one thing we can push is to do more rotation programs in our industries whether it's a few months six months a year to allow people to try something new where they always have the option to go back that was one of the things for me about trying the blued role with Google is that I knew I can always go back to my job I had this safety net at JHU APL and that I could have found more work in exploit davin firmware and embedded devices if I really didn't like what I

was doing so let's build that out for everyone have that opportunity we also need to change experience requirements I understand that I have had very privileged experience in terms of the job hunting market is that I've had a lot of people take chances on me when I hadn't proven myself an experience but I don't think that should be just me because I think if someone has the basic technical skills so for example in my case that was reverse engineering it's not that hard of a switch to go from doing it for vulnerability research to malware analysis I didn't there was no way for me to get malware analysis experience unless someone gave me that opportunity

and took that chance and I think that should be the case for everyone if someone has the basic technical expertise then trust that they're probably confident enough to make the switch between red and blue and apply it in a new way I think we also need to be assuming training and ramp up period in each of our jobs why would we assume that someone can come in and do your exact work on your tool set with no ramp up period so that allows us to be more flexible in our our experience in training and also gives makes likely a better workforce because you're giving them the option opportunity to experience to experiment to fail and to

gain broader experiences I am a specialist like I will acknowledge that I just do reverse engineering all the time but I think it's good to push ourselves to be more generalist and even those niche fields like trying malware analysis vulnerability research bug hunting threat Intel across and again I just say more purple and Industry changes are hard I know I can sometimes fall into the trap of being like but I'm not the CEO I'm not even a manager anymore what can I do but I think we sometimes discount the amount of power that we each have as individual contributors on a team - you know if you look around in your leg I might not have the title but I know

they all respect my technical expertise what I bring to this team and by doing that and taking advantage we can then push our managers our leaders or even just do it ourselves and say hey I'm gonna take on this mentee for you know that this next quarter they're gonna work with me on a project depending on where you work they may say no if you have like you know tight requirements in terms of info sharing but I think most of the people I know in most the place they work are like cool okay don't let it disrupt your current workload but that now allows you to help share information with others and help make these industry changes and also if you

are even you know a lower lip level middle manager then you can also set what the requirements are for the people you hire on your team and be willing to take a little more risks because often people show up do the work and will surprise you and with that thank you I appreciate y'all y'all come sitting here for 60 minutes early on a Saturday morning and thank you again the V sites Charleston crew for having me and I think we have like one minute for questions if there are any oh no questions I'll be walking around so come fine thank y'all [Applause]