Security BSides Delaware 2020 - Day 1

I'm going to play the hero. Cause I got you like you got me. When the earth shakes, when the bombs scream until I last breath, every heart.

has been interesting for everybody with children. You know,

see that it's possible. So thank you, Jeff and Nikita you rock.

Without all the wonderful people, Jason and spam and Zach and everybody. Great dresser. Great practice. Great practice. Yeah, what? I wasn't live. I thought we were streaming. Danny was getting his stream. He's streaming like a splash page. We're streaming. Oh, okay. Well, let us know what we're actually live.

Danny, are you good? Oh, Josh, if you're home, I'll come downstairs. I'm home. All right. I'll see you downstairs in two seconds. Bye.

now.

Stand by. We are getting set up.

We'll get started in just a moment.

Hello and welcome to B-Sides Delaware 2020. In true 2020 fashion, we've had some technical difficulties and we're getting started a little bit late, but we are excited to have everybody. Thank you all for coming this year. Thank you all for coming the last 10 years. And thank you all to the speakers, staff, volunteers, and past sponsors, since we don't have any official sponsors this year.

Without you, we would not have continued this long. And without all your creativity, we wouldn't be what we are today. So thank you. I'm gonna turn it over to Josh. Thank you, honey. We started this conference many, many, many years ago in order to build a really wonderful place for our children to play at. And of course, that means that this year I dropped off our kid at my in-laws. because it's not really a conference for kids this year, for little, little tiny ones, for bigger kids, yes, like me. This is an amazing conference. Every year we've shown that, every year we've done it better and better and better. And this year we're going virtual, so we're gonna do better in

a different realm. And I wanna thank all of you, volunteers, staff, sponsors, crew, board, people who we cry on their shoulders, because we do. You're amazing.

Without you, this would not have happened. Without Zach and Spam and Jason, without Patrick and his incredibly dry sense of humor. Terrifyingly dry sometimes. And carb breakfast sandwiches. Oh, oh, oh, oh. Dude, next year when we were back in person, please God, you must check out Patrick's breakfast sandwiches. He makes the most disgusting, awesome concoctions known to mankind. We have speakers coming in from India. We have speakers coming in from all over the world. We've... participants from all over the world. We welcome you. We hope you have a great time and enjoy everything that this venue has to offer, including the chance to have some very strange friends to make. It's wonderful. Just to give you a little idea of the demographics without personally identifying anybody,

I know that we have people from at least three different time zones. So when you go outside at lunchtime today, it may not be their lunch. But... everybody can find something common ground to talk about. And that's really exciting. And we have a wireless CTF. We have a spawn camp. We have a dead pixel sec has sponsored a chill out space. We're going to have some fun. Let's just enjoy ourselves. 2020 may have been a very, very strange year, but there's a light at the end of the tunnel. Things are going to get better. I promise. And to... Talk to you a little bit about 2020 and risk and communication. We have Spam as our keynote speaker.

So we're going to clear out of here and let Spam get to work.

All right, should be ready to go. We are not live already, Rando. Totally ready to go.

Okay, sorry. All right. Hi everybody, I'm Spam. This is how InfoSec skills can help you survive a pandemic. Thank you so much, Josh and Janice for the introduction. And gonna talk a little bit about, I guess, InfoSec and hacker culture and how you can use the skills you already have to go ahead, survive and thrive in a pandemic. Some of this stuff is going to be a little bit stream of consciousness, a little bit off the cuff. You know, bear with me a little bit with regards to that. But I think that there's a lot that hackers can bring to the table, a lot of skills, a lot of mindset that can be really, really applicable for reacting to a pandemic.

So some of this talk came about from conversations I had before the pandemic, just discussing how for a lot of individuals in the hacker community, there's a lot of commonalities that we see that are totally outside of InfoSec strictly. So obviously a lot of folks know a lot of, you know, culture, media, whatever, movies, music, TV shows, stuff like that, a lot of similarities. But there's also a lot of hobbies that I think you see folks getting interested in for similar reasons that they're interested in hacking. So one thing that I find particularly interesting in terms of a hobby is a lot of folks who are into hacking were into magic when they were younger. And I think the reason that folks were

into magic tricks, maybe when they're younger and for a lot of folks also today is for the almost exact same reasons. They are, you see something that is interesting, astounding, you don't quite understand it, but it's really, really cool. So you want to be able to do that yourself and you want to be able to tear it apart and understand how it works, see how you could innovate on it, see what else you can do. But that mindset, that thinking is something that is intriguing to folks in the hacker community. And the mindset is one of the things that's hardest to kind of teach people. And I think that mindset can be applied for reacting to a pandemic and make

things, you know, way, way better for everybody. So a lot of what we see in reaction to the pandemic is stuff like this. American catastrophe. How do we get here? Oh, there's here's the news. The news is going to give me the answer to. all of my, you know, what I'm looking for. We know that this is not true. And unfortunately, in a lot of cases, there's a lot of fun out there. A lot of what we're seeing is just breeding fear, uncertainty and doubt. And I think we want to, A, cut through it and also see how we can bring a little bit of, well, certainty, a little bit of control, but also see where there's possibilities for innovation. But with that being said, one disclaimer,

no one knows what they're doing. So I don't know what I'm doing. Most people alive today have never lived through a pandemic. So everybody's trying new things. So things aren't going to be perfect. But that's fine. You know, this is this is absolutely I think where hackers thrive. We know that we're not going to understand all of what we're doing. We're going to figure it out as we go. We'll get some stuff right. We'll get some stuff wrong, but we will figure it out. And we shouldn't get discouraged if some aspect of what we're looking at is potentially failing along the way. We just go ahead and keep at it and make sure that we're

going to go ahead and learn from the experience. So, With that, the thing that I see overwhelmingly in people's approach outside of the hacker community to the pandemic that I think could use improvement is threat modeling. Basic threat modeling. If you look at how folks were preparing for the pandemic and how folks have approached their responses to dealing with the pandemic where it was... just critically obvious that folks were not taking the right things into account is threat modeling. Individuals' threat modeling skills are way off. And even if I thought that they were not necessarily where they should be, the pandemic has proven without a shadow of a doubt that the average person is not great at threat modeling. But hey, as InfoSec

professionals, as hackers, you can go ahead and do this. And actually, as I was...

preparing my slides yesterday, I came across this tweet from Lee Honeywell on Twitter, which really summarizes a lot of what I've been thinking about and people's approach to risk management and threat modeling as it relates to the pandemic. So this is in response to tweets, somebody talking about, hey, there's going to be people need to prepare for another round of shelter in place orders in different states and different countries. It says something that basically none of my professional peers in security, people whose job it is to manage risk, ever stopped sheltering in place. We have the advantage of being able to work from home and most jobs require it, but the risk has yet to

drop enough to stop sheltering. There's And it's right there. It summarizes so much of what I think I want to talk about here, where you go ahead and being able to step back and not just take a look at what's the foot that's out there, but taking a real look based on the evidence that's out there, the actual guidelines and saying, OK, here is what I do. Here is where my exposure is. Here's my personal things, whether you're immunocompromised or have other things that put you potentially at risk, and you act accordingly. Some folks have not necessarily done that early on in the pandemic, and maybe they've relaxed over time. But if you are looking at things in a reasonable and responsible

way, I think you're more likely to have gone ahead and done your risk analysis and realize, that the risk has been fairly consistent. And so your approach has been fairly consistent. I know some friends of mine have actually said, friends who are not in InfoSec have said like, hey, you know, like we, oh, we're all doing this stuff and you're not, you're doing the exact same thing you were months ago. I'm like, well, yeah, I have my, I have my approach. I have my lines. I look at it and I'm not afraid of reevaluating it. But the overall approach risk has not changed. So my approach isn't necessarily going to change unless there's some other

factor that's coming into play. And with some of this, I know folks can get bound up. There's a lot of, you know, emotional attachment to certain things. And sometimes it can be difficult to separate, you know, to bring in aspects of personal to business, business to personal, with respect to this, but I think we'll all be better off if we can, I guess, detach a tiny bit to do an actual analysis of the risk if you're not already doing that and make sure that your approach incorporates that when you're going ahead and figuring out how you're going to deal with something during a pandemic. And in terms of what we're doing in a response, fundamentals. Fundamentals are key, whether it's an InfoSec, or in how

we're dealing with the pandemic. So many corporations get compromised, not from somebody dropping Oday on them. Most folks are not looking at, their threat model doesn't include a nation state where they're going to be dropping Oday on them and the latest CVE, whatever, to go ahead and compromise them. It's the fundamentals where they fail and they get compromised. And this is absolutely the same when it comes to approaches to a pandemic. Pretty early on, folks were saying in the medical community that if people did things like washing their hands, making sure they didn't touch their face, which admittedly, I won't say that, well, it may be fundamental. It's very difficult to train yourself not to do. And wear masks and social distance,

we can go ahead and absolutely kneecap this virus, not in that we'll eliminate it, but that we will completely contain the spread for that time. And early on, folks were talking about it as a way to give the hospitals time to react. But it also, now what we're facing, people call a second or a third wave, it can give a bit of a reset and allow us to ease restrictions. Now they may come back, but It is absolutely key to doing that. And if you look at how people approach the fundamentals early on, people weren't focusing on that stuff. They were focusing on bright and shiny objects. What's a new medical treatment? What's a new way to sanitize and other things? You would

go to a store and you'd see folks who had a, they were doing runs on toilet paper or runs on, you know, runs on hand sanitizer. The runs on toilet paper, I don't know what people were thinking. Maybe they're thinking they could eat the toilet paper because the way people stocked up and continue to stock up, it's just, it's crazy. But on the hand sanitizer, people were looking at like, I think the labels on hand sanitizer, like, oh, it's 99.99% effective. I better get this stuff because it's going to kill all the things. I spray it on stuff and it's going to be, you know, it's going to be magical. Well, it's not magical. You know, in, I think in a lot of cases, they found that

hand washing with soap for 20 to 30 seconds can be even more effective. Hand sanitizer is a tool for when you don't have access to the other thing. But people were focused on the hand sanitizer and not getting soap. I know when I went, I would go to like a drugstore and I'd see people frantically searching for hand sanitizer. And then like in desperation, they'll go and they'll buy an antibacterial soap. Yet the shelves were stocked. with regular soap and folks were just passing it by like, no, no, no, no, I don't need that. I need this other stuff because this is gonna be more effective when they weren't actually stopping and realizing, no, what's

the fundamentals? Yes, there is a certain level of efficacy that you may get with a hand sanitizer or an antibacterial soap, but the fundamentals of those basics are what's going to be key. The fundamentals aren't necessarily always the most enjoyable thing and

it's difficult to maintain that long-term for a lot of folks, but they are absolutely key. So, you know, I hope we can all keep that in mind as we go through this stuff. And the game has changed with regards to that, but it really hasn't. I'm gonna flip the script here a little bit in that I think this is something that InfoSec has seen to a certain degree with companies' reactions to the pandemic. So if you used to go into an office every day rather than working from home, suddenly you need to be able to work remotely all the time. So companies that were prepared for it and had formal ways for all of their employees to work remotely, they may, if they were actually well-prepared, they will

have gone and said, okay, go home, make sure your internet connection's okay, make sure you know how to access anything that may have been on-prem that you need, and we'll be good to go. Companies that didn't have a way to deal with that and didn't have a way to scale were frantically going ahead and potentially setting themselves up for compromise by just opening everything up to the world. You know, like, open up RDP to the world because I gotta access this box that's only accessible on-prem and we don't have a secure way to do it, but the business is gonna die If we don't do this. And in some cases, they may have decided that the risk was justified in those cases. But I think they haven't necessarily

made the proper preparations. What we are seeing today, this isn't the 90s. You know, we have seen the need for this growing steadily over the past decade. And now we're seeing that come to a head. Everything that we've seen up until now is just getting intensified and sped up by the pandemic. But it really hasn't changed the overall approach that we should have. It may change the rollout. We may need to scale in a different way. But it's really the same as what we've been dealing with for quite a while now. And on that, I think... Big thing is being prepared. We can all be good Boy Scouts and make sure that we're properly prepared for what's going on. But as

InfoSec professionals or hackers, we want to hope for the best, but plan for the worst. If we go ahead and plan for the worst and we don't need to go ahead and use it, great. But having that in our back pocket is fantastic. I know when the pandemic started for myself, I went ahead and I, a couple of days into me being at home and working remotely, I took my EDC and I kind of like splayed it all out on a table. And I started looking, okay, what was in my EDC because it was a decent tool to be used on occasion on the go. What am I, you know, certainly took out all the battery packs and everything else I needed only if I wasn't,

you know, somewhere near an outlet. Thankfully, plenty of outlets at home separate out. Okay. This is going to be useful. Some stuff I'm going to need to replace. And it may have been something as simple as just getting a decent microphone, which I only kept at home a, you know, kind of a cheapo headset, getting a decent microphone and revisiting some skills that I hadn't touched in a while in terms of dealing with audio and video. But it can be lots of other stuff as well. On the pandemic side, strictly, I started taking a look and doing an inventory of what I had that would help me respond should I need to self-isolate.

And I said, okay, what are the recommendations? What do I need? So immediately ordered a pulse oximeter, made sure I had some sort of temperature sensing equipment. I don't have a child at home, so I don't necessarily have a bunch of thermometers and whatnot. And I actually realized that the best thermometer I had was a meat probe thermometer that I use in my oven. So hacker in me was like, okay, well, let's see how accurate this is. And if it would work in a pinch, it turns out the accuracy of my meat thermometer was enough. Uh, but it's not something I want to rely on. Okay. So I ordered that stuff and then I went out and I also stocked up on, um, just

basic medical supplies. Um, I get, these are not the most exciting things to do. Go out and buy, um, you know, uh, antihistamines and just stuff like, I don't know, Tylenol, Advil, ibuprofen, stuff like that. Making sure based on medical recommendations that they said, hey, if you think you have COVID, at least early on, they weren't recommending that you go out to get testing. They were saying, hey, be in touch with a medical professional and you should be prepared to have some basic medications at home and track your temperature. And if conditions worsen, then you might need to go to a hospital. So having those on hand would allow me to react appropriately. It turned out that

I guess fates were aligned. I needed to take advantage of that stuff within a few hours. Cause actually only a couple of hours from when I got home from going out to shop for different things. I got a call that let me know that a friend of mine who was one of the early cases in New Jersey, I had been exposed to him about half a week beforehand. And so based on the fact that I was in the same space as that person within about 10 feet of them for about an hour, I now needed to shelter in place for another week and a half since it had been half a week since I was exposed. And if I hadn't had my two weeks of food and

everything else, you know, there would have been, I would have freaked out then. But at that point, I'm like, hey, I'm happy I went out. The last thing I had to get were those, you know, basic drugs. But I had that in place. And so the anxiety over needing to collect these supplies was, you know, much lower because of that. So, you know, proper preparations, whether it's a, you know, formal runbook or just going out and getting these basic supplies, the same things we want in InfoSec is ways that you can help address your needs during a pandemic. And along the way, hopefully you pick up a few new skills. I know, like I said, I've revisited some audiovisual skills. I did like college radio and did some

video production work when I was younger. I've revisited a bunch of that stuff. It has turned into kind of its own little hobby, helping friends and family members with some stuff. And it is, maybe, you know, I think hackers love picking up new skills. And while these skills may not be as directly relatable to hacking as something like lockpicking or I don't know, anything else like that, I think they're still useful skills. And the great thing about hackers is that we are constantly looking to pick up new skills and test those new skills. So, you know, don't be afraid of that. I embrace it. As we go ahead and react, and we're going ahead and forming how we're going to respond to things, we want

to make sure that we understand that what we're really doing here is we're looking to reduce risk. By its very nature, we're not going to be able to eliminate risk entirely. That's true in InfoSec, and it's true in regards to how we're dealing with the pandemic. I know for myself, I'm certainly not a medical professional, and I've been learning a lot about how they're saying, hey, We don't know the exact effectiveness rates of these particular precautions, but we know that taking certain precautions basics when you're dealing with stuff in the pandemic, it reduces the overall likelihood and we can reduce the risk to an acceptable level. Now, that acceptable level is going to be different for everyone. For some folks, They

may only be comfortable outside more than six feet apart from everybody. Other folks may be able to say, listen, I don't have any immunocompromise issues, don't have family members who are at higher risk either, so maybe I'll be willing to go indoors. There's a lot of stuff that's going on with restaurants taking different approaches. You have to reduce risk to a level that's acceptable to you, but also understand that you're not going to eliminate risk entirely. Excuse me. And anyone who's coming along and saying that they're going to be able to eliminate the risk entirely is probably lying to you. And just like if a vendor comes in and says, you know, 100 percent effective against all hackers and the APTs, you

know, it's not it's not real. And understanding that reality and to take something from the military, in a certain sense, embracing the suck a little bit, understanding that this is going to be with us for a little while is important as well. But as we're going through this, we need to make sure that we maintain balance. To quote Thanos, what we are looking for is perfectly balanced, as all things should be. And as we're going ahead and crafting how we're going to approach a pandemic, we need to make sure that we maintain usability because usability matters. What we're in here for is an extended period. I think a lot of folks early on in the pandemic did not view this as, let's say, a new normal,

viewed it as something where, hey, we could be through this in the next month or two, through the worst of it and then things will ease. So I'm going to act as if that's the amount of time that I need to take on these precautions for. So let me structure it that way. Well, as hackers, as InfoSec professionals, we know that that's not really the way threats work. Threats do not go away instantaneously. They may lessen over time, but It's going to potentially take a while, and we need to make sure that we are prepared to maintain that for a long time. And we need to make sure that we have that usability so that we can fight burnout. This is a marathon, not a sprint. I

think some folks thought that, hey, maybe it might not be over in a month or so, but six months, seven months in, we'd probably be in a place where we had reached a call it a new normal, call it an acceptable level of risk or extra precautions. But it turns out that we haven't. And I think if you had taken on extra restrictions for yourself or others that were a little too tight, you may find yourself sliding to a place where you almost just give up. And we see this in InfoSec all the time. If you go ahead and put too tight restrictions on folks, In an enterprise environment, a corporate environment, you're going to see folks react negatively to it and figure

out ways around it. So in some cities where they've put heavily restrictive impositions on folks, they have reacted strongly and gone ahead and said, hey, I'm not doing this. And they may be hiding it from people. the public, but they're going ahead and working around the restrictions. So having something that is going to work for you, that's going to work for the long term, it's, you know, it's really something we need to keep in mind. And it is in the same way that it's going to be different for each individual, but we also need to be proactive and make sure that it's working for the folks, you know, in our direct orbit. Um, And that starts bringing me

to, I think, some of the more proactive measures. We want to be proactive rather than reactive. So in a network environment, we might have network segmentation. Well, that works. That's perfectly applicable to what we're dealing with in a pandemic. On a basic level, what a lot of medical professionals are proposing with social distancing, well, that's complete network segmentation. Every individual node is completely segmented from one another. So it's highly unlikely that somebody is gonna be able to pivot from one system to another. And that's great. But as time has gone on, well, there's a balance that has needed to be struck that's not full on network segmentation. So what have we seen? Well, hey, maybe you need particular machines to be able to talk to

one another on a network, but you don't want all machines to talk to each other. If you take a look at what some schools and other places have done, they've used what they're calling pods. So what's a school's approach with a pod? Well, we want to have students be able to return to in-person learning, but there's a problem. Unacceptable level of risk if every individual student is allowed to interact as they would normally with one another. So by creating pods of individual classes of students and keeping them together so they have, they try to maintain social distancing as much as possible, but they're going to have, ultimately, we know there's going to be closer interactions between those groups of students. But an individual class

is not interacting with another class. They're only interacting with their own class. So if there is an outbreak, it is more likely to be able to be contained to that class. And the whole school does not need to shut down. Perhaps an individual class may need to shut down, but the whole school doesn't. This is, I mean, to me, it's clear as day. It's exactly the same as what we would try to do in network segmentation. And so let's look at other proactive measures that are, I guess, kind of similar. Well, vaccines. I think there is, when it comes to vaccines, when it comes to vaccines, you know, we really should look at it as patch

management for humans. You know, there's a patch. It took some time, took a couple months for different drug companies to develop and test vaccines. their patch for humans to give us a sufficient antibodies to fight this, to fight this disease. But now we're hearing that, Hey, there's some vaccines that are in development, but the vaccines are not perfectly efficient. You know, they're not going to give us a hundred percent effectiveness. I think before the pandemic, I, I pretty much would have just assumed that, hey, they've tested it and maybe it's not 100% effective, but it's 99.99%. But we're learning that this Pfizer vaccine is potentially one of the most effective vaccines that folks have seen because it's going to be 90% effective. Well, that means one out of

10 people, it's not going to be effective for. Well, that's where that network segmentation comes into play. Because if we go ahead and and we apply the patches to the folks that we can, and we have that network segmentation, that's what's gonna hopefully get us to reduce the overall risk. And like patch management, in an InfoSec situation, where we're applying the patches, how we're applying the patches, and what priority we apply the patches are all gonna become vitally important. I think it's going to be interesting over the next few months to see how the vaccine is rolled out. And listen, you may need to do, it may not sound like the most comfortable thing of the world, but you're on inventory management

to understand this. Who am I going to interact with? Let's say I get the vaccine, but my friends and family have not. Am I going to go ahead and keep an inventory of who has it and who doesn't? And what's my overall risk? And am I going to be willing to accept that risk? But assuming that we have vaccines and we can layer some network segmentation on top of that, well, now we've gotten to what they call herd immunity. But in a certain sense, I think it's defense in depth. And I see somebody in chat saying, yeah, the side effects. There are definitely going to be side effects. And I think that's going to delay the rollout as well. We're going to see... That's why herd immunity

is accomplished by defense in depth because you're not going to be able to patch every system. You're not going to, you need certain availability on certain systems. So you need to be able to have different approaches depending on the what we're dealing with. So by layering these different things, we can have that defense in depth and develop a situation, even with straight vaccination, if you have 90% effectiveness, I think they say overall, you need to get about 80% of a population with somewhere about 75% effectiveness of a vaccine in order to get to herd immunity. So there's different ways that we can go ahead and do this. So in the case of, you know, tying it back to defense and depth and patch management, you may not, you'll

patch certain systems, but you may turn off services on other systems because you can't patch it, or there is no patch for a particular system, but it's still vulnerable. So there may be some folks who there is a 20% chance of an adverse medical effect, so they'll continue social distancing, mask wearing, and other things until a point where everybody has reached herd immunity because they cannot be patched yet, or maybe they'll never be able to be patched. If you look at traditionally away herd immunity, is relied upon, there's always some folks who are gonna be unable to be vaccinated and some folks who the vaccine will never be able to have an effect on. So, it is direct parallels between the two there.

And to that end, I think education is really key. I think some of what we've seen in response to the pandemic, education in some cases has been lacking. And listen, we see that in InfoSec a lot, security awareness training and continuing education for users. Users are the first line of defense. And it comes down to them to ultimately work with us or work against us to accomplish what we need to do. going back earlier to the general concept for medical professionals, we go ahead and we say, hey, if everybody wears their masks and just does these basic precautions, we can kneecap this virus, take it out. But end users were unwilling to accept that. I think part of it comes down to education. And if there is

a better education, it can go ahead and make the effect better. I'd like to suggest that we should all take on some of this education. Different communication methods are going to work better for different folks. So please speak with your friends and family and see, hey, are they understanding this? Are they doing their own threat modeling? But also, do they understand what's going on with the vaccination? If somebody is nervous about a vaccine, like, hey, maybe I can point you towards some real information about whether this is the correct approach for you or not.

When it comes to this, the unfortunate side effect in the real world is that we also have to combat misinformation. And to me, that means education isn't the end, it's the beginning. It's exactly the same way in InfoSec. Just because somebody attends security awareness training doesn't mean that they're now aware and they never need to revisit it. The threats are constantly evolving, our approach needs to be constantly evolving, and it needs to go on over time. Combating misinformation and combating just incorrect interpretations of information is going to be key. So please speak with your friends and loved ones and help them understand, point them towards resources that they can use and maybe offer to help walk them through that if you're comfortable with it,

saying, hey, here's what we know, here's what we understand, here's what we know. and let's go ahead and figure out an approach that works for you. And if it's I, you're a family member and hey, maybe we wanna be able to interact more, maybe we wanna form, maybe it's just a friend and hey, we wanna form a little pod and we wanna know that our overall risk level is gonna be acceptable. Let's make sure we're all on the same page. Let's make sure that we all understand the actual risks that we're dealing with. And this is where I think hackers also just by necessity,

have to reevaluate and constantly incorporate new information. And research skills, being able to learn new things is vitally important. And this is something that the general public has sometimes struggled with. When early on in the pandemic, there's certain advice that's come out from medical professionals. And then later on, they say, well, hey, we've changed our advice, and you should do things a little bit differently now. Well, some folks would look at it and be like, see, the medical people know nothing. Well, hey, we know they knew certain things at the time and additional research has revealed different approaches and different...

May I see the last results of your vulnerability assessment before I allow you on prem? Yeah, it's, there's, you know, new things have come to light, man.

There's a lot of new information always coming out at the time. And just because... current information is contradicting something in the past doesn't mean that it's untrue. It's fine to be skeptical of it, but we should have a way to verify the information and incorporate new information and have, you know, trusted news sources and trusted folks that we can consult to be able to get at the real information and differentiate what's going to be potentially misinformation from, you know, true information. Right after Pfizer announced the efficacy of their vaccine, all of a sudden Russia was announcing, well, our vaccines like was a 92, 93 percent effectiveness. See, more effective than the U.S. vaccine. I don't know. Maybe it's true. Maybe it's not. But for me,

from the sources that I trust, I don't see any way of being able to verify that that vaccine is is as effective as what they're saying. And certainly no information on verifying if it's anywhere near as safe. as what Pfizer has developed. So incorporate new information, but make sure that you're doing it in a way that is intelligent and takes into account all of your knowledge as an InfoSec professional. And let's see if we can incorporate least privilege. You wanna concept the least privilege, limiting your exposure by limiting who has access? Well, hey, that's directly applicable here. In a corporate environment, you see a lot of folks talk about least privilege as an approach that's going to be not something you're

going to turn on immediately. It's a least privilege journey. And it may just be, you know, that's the sort of thing that sounds nice, but that least privilege journey is real. You want to go ahead and take a look. Hey, here's the access I have. Is there another way I could do it that's potentially more secure? Or is this something that I don't really explicitly need. Obviously we need to have that balance, but that balance may be different. Hey, maybe this is the general guidelines, but because of my own approach to things, I can be more restrictive for myself. You know, I love going to movies, but I'm not going to movies during the pandemic. Because while the risk of infection at a movie theater is

probably fairly low as long as there's social distancing and everything else, it's not a risk that I need to take. I can sit at home and watch a movie on TV, and that's perfectly acceptable to me for the foreseeable future. I'd love to see Tenet, but I'm not going to be able to see it. And, you know, that sucks. But, hey, this is something I'm willing to live with. It may be that, hey, I'm... I'm unwilling to fans of going to, you know, live theater. Hey, I'm not willing to give that up, but maybe I'm not willing to give that up because I can find a way to do that safely. Can't do an indoor theater, but now there are theater companies that are conducting

outdoors. So, hey, I can substitute that where I have a less risky alternative. So please try to apply the concept of least privilege and don't be afraid of, hey, I've pared back and I'm saying I'm not doing this stuff, then making a little more exception. It's not going to always be perfect. This is going to be a learning situation. You're going to adjust and adapt over time. If we, you know, we can be super, super, restrictive, you can go and live in your basement with some canned food and a bucket in the corner and never interact with another human being for the next year. Theoretically you can, but what's that going to do to your mental health? And are you really prepared to do that? Probably not.

There's always going to be gradations of what we're willing to do, what we're willing to accept. So even if you're going ahead and staying at home and only getting deliveries, there is a certain amount of risk to doing that. And in certain situations, it may be less risky for you to go out and go grocery shopping once every two weeks than get delivery every day. Take a hard look at it and don't be afraid to revisit it. And, you know, make sure you understand what your own risk tolerance is as you're going ahead and taking a look at this stuff. Last thing I want to bring up is tabletops.

Proper preparation prevents poor performance. That's why we do tabletops. But I think when it comes to the pandemic, we can use tabletops

to take a look at what we're likely to encounter. Now, I don't expect everybody to have a COVID response IR playbook, but if you can go ahead and tabletop different scenarios that you're likely to encounter, I think you're more likely to have less anxiety about decision-making in the moment, and you're more likely to go ahead and actually act in situations where, hey, you might have wished you reacted differently after the fact. Tabletop a scenario if you're Just simple, something that everybody pretty much is doing, going to the grocery store occasionally. If I'm in line at the grocery store checking out and somebody is encroaching on the six feet between people, is that a level of risk I'm willing to accept if that person

is wearing a mask versus not wearing a mask? What is the level where, hey, this is an increased level of risk. but I'm okay with it versus this is an increased level of risk and I'm gonna walk away. Know what your limit is ahead of time. And if you walk into a grocery store and you see everybody's not wearing masks and you're not okay with that, okay, that's the point where I'm gonna put the basket down and I'm gonna walk out and hopefully not have anxiety over it because I've gamed it out ahead of time. When we go ahead and also think through conversations you're going to have with Thanksgiving and other holidays coming up. A lot of folks are going to have what unfortunately

I think are some uncomfortable conversations with friends and family members. If a family member says, hey, I haven't seen you in so long, you know, please come come for Thanksgiving. Want to go ahead and see you. Think through that ahead of time. Everybody has their own threat model. Everybody has their own risks that they're willing to accept. So understanding ahead of time, if you go ahead and know that, hey, okay, I'm willing to go ahead and go to this family member's home, but I'm not willing to eat inside. Well, hey, I live in New Jersey. It's getting pretty cold outside. The likelihood that we're going to be able to eat outside based on how cold it is, it's pretty unlikely. If you live out in sunny Southern California,

yeah, that may work. And that may work for you, but think through it ahead of time because in the moment, there's going to be all sorts of stuff flowing through your head. So, you know, please think about it. Make sure you understand how you're going to react. why you're gonna react. And there's gonna be scenarios that you're not gonna think through, but think through as many of them as you can. And I think tabletops also bring into play all of the different skills that I've been bringing up throughout this. Whether it be threat modeling, risk analysis, how you're gonna deal with network segmentation and all the rest, it kind of ties everything together. And I think the more aspects of life that we

can go ahead and take that hacker mindset and apply it to, we'll be better off for it and we won't just survive, we'll thrive. And so with that, that is the presentation. Thank you so, so much. for having me speak here. It's great to be back at B-Sides Delaware. Always enjoy my time at B-Sides Delaware. Really looking forward to the conference as a whole. Thank you everybody for working so hard to play this out. Really super excited to see things succeed, see things fail, learn and innovate from it. So I'm Spam. If you want to reach me online, that's my contact info. Have a great con, everybody.

Alright, good morning, Delaware, and good evening, or good early morning, India, and everyone else joining us from multiple time zones. Thank you for attending so early on a Friday morning, I know some of you are working. My name is Michael Mastroianni, and this is a soft skills presentation, so just be warned going into that. I am a project manager, mostly working on the information technology and information security side of new medical apps and processes often related to at this point COVID infection prevention and tracing protocols at some of your neighborhood hospitals especially if you were in Maryland Delaware or the District of Columbia also briefly going into some interesting ballot security stuff that came up

this year of course during the election as well as where that led us as information security specialists. As you'll probably see from the slide here, this was originally developed more for the dev and IT crowd in corporate settings, but at the urging of the incomparable Janice Paulson, I started thinking more about InfoSec this year and also wanted to bring this presentation to more of an InfoSec crowd. So this is sort of its first time out. What does emergency communication mean, especially, and also what does decision maker mean here? Well, when I'm talking about emergency, there are two different kinds that you're probably going to run into as any kind of information technology professional. First is where chaos reigns, which is

usually a big crisis or an organizational crisis when something has gone terribly wrong or is about to go terribly wrong. In some cases, you might be the infosec advocate. that recognizes that and no one else does. And also a smaller emergency usually is when there is no help, which is more of a team emergency or a project emergency. Usually when someone coordinating your work with others, other vital members of the team isn't available. So when you're going into either kind of emergency before you start, the first thing you should be doing as an InfoSec advocate is know the other ones on your project team or in your organization. Unfortunately, in some cases, and this is also what I determined working

with Compass early on, it might just be you. And this does give you a lot of opportunities, but it also opens up a lot of risks. And that is more what we are going into today. So let's start with the big emergencies that you often encounter. That is where chaos reigns. What do I define chaos as? Well, it's really hard to define, but in this particular case, Let's take it as it is, especially from a hacker perspective. A project or an organization has or may be imminently compromised by an attack, a breach, a flaw that you've discovered, an internal element that could be human or signal, or an unscheduled test. Because if a project or organization breaks down during one, then there's probably something seriously

wrong. usually prescribe CPR for these cases, that's communication, preparation, and reaction. Communication is usually determining who you can communicate to resolve issues that you see coming or that are already happening. Preparation is doing what you can alone and with those people. It's important to cooperate when you can, but also be ready to do the work when you can't and also reaction, which is running the plan you're coming up with and being prepared to deal with the unpredicted. Something that's been coming a lot up in the human resource and corporate world after spent a lot of time in psychology and sociology is the risk and resilience model, which originally was designed to determine personality resistance through trauma, but also has been used to track a lot of community

and corporate factors. As it applies to a lot of the communications we're going to be talking about, it goes from detecting or identifying an anomaly, which in a more psychological model might be a stressor. An anomaly is anything that's going wrong at this particular juncture. And then sorting out the risk factors that it opens up a project or organization to. Usually in this term, you're seeing the bullseye on the left or two from the left to show Risk factors are usually sorted from closest or in a psychological environment, more intimate to more remote. So the ones that are more of an acute risk to a project or org are at the center. And then you

have protected factors. So these are usually just the positives to the negative, but they're grouped in different ways because protective factors for a person just like an organization or a project are always interrelate or interact somehow. And that's usually what makes protective factors smaller. Just to go off of what we were hearing in the keynote about the importance of preventative measures in the pandemic, we're talking about protective factors being masks, hand washing, limiting your distance to friends, the possibility of contact tracing in the case that you fail to prevent infection. These are all the protective factors that work together and strengthen each other because none of them are 100% effective on their own. It's usually the same case for corporate resilience as well as InfoSec resilience when you're

coming back from some sort of attack, breach, or flaw. And then usually if you are doing a post-mortem, you're sorting outcomes by both positive and negative to try to strengthen the your organization's response in the future. So what does this mean for the InfoSec professional? There's a lot on these slides, but there's also a lot that we're covering in a short period of time here. So from the macro perspective, it's often important for InfoSec professionals, especially if they feel like they're the only advocates in the field, to cultivate a culture of information security and good governance. These are both very important sort of twin aspects that work in organizations And organizations usually pay when they fail to recognize one or both of them. So InfoSec, in this

particular case, cultivating a culture of security would be having more people become InfoSec advocates. You're doing a lot of recruiting here. There are usually more IT professionals related to what you're doing than might even be on your team. When it comes to using the resilience model, It's often your job to translate that for information security. So we're talking about reducing the risk, identifying risk factors that you can reduce and identifying protective factors that you can increase. You also often need to identify the ones you can't do anything about just to be aware of them in an environment because we're usually doing our best work when we understand more about the context we're working in. So what does this look like

when you bring it to the rubber meets the road for the organization? Well, a lot of the time it's one-on-one time with the people who can make those decisions, like the chief information officers, VPs of technology in particular organizations, and understanding how they have the rationale to make decisions. This usually involves case studies. numbers, especially when it comes to medical care executives, both in the nonprofit realm and for-profit technology development. And this is what we're going to spend a lot of our time working on is how to use these to your advantage as an InfoSec advocate. Other ways of trying to make a difference at the macro level are creating an office of InfoSec czar or a task force.

A task force often best involve a teams from a lot of different disciplines like finance or elsewhere in the tech world in an organization like dev because and also detractors. This is an important place to bring people who are not particularly prioritizing InfoSec or might not particularly believe in your mission here because they're the ones who diversify our thinking and also give us a lot of information on how to promote InfoSec in an environment. And also if you come up with solutions like new third-party apps or work that IT can do, protocols that we watch a lot of prospective apps and programs through, which is something I do a lot of, it's important to get the staff by it because everything is going to be easier

and it's also going to be easier to track your performance and see if what you're doing is actually working. On a micro level, there are a lot of things where a more technical approach view would probably be helpful here, but economizing code. So forensic investigation would not take as long. So forensic investigation would not be necessary in the first place. This is something where more of a technical aspect would probably be answering those questions. When it comes to third-party applications or things where you might be called into consult, We often try to figure out how do these work with other parts of the system? Can we confirm that they're interoperable? Can we streamline that interoperability in any way to

reduce any risk that data that travels through it might encounter? Scheduling user tests to make sure that users are able to navigate all of these issues. And also we're getting into user experience a little bit later, as well as stress tests, which might be something that only you are responsible for even conceiving, let alone planning. And it also comes down to more of an infosec presence in decision-making meetings beyond the conversations that you have specifically about information security with the professionals around you. And as we mentioned, case studies and numbers, this is just the number one way of getting your message to people who are not information security professionals or technical professionals in a lot of ways. When it came to the task force that we just

came off of, Election Systems and Software, which is a company that produces more than 90% of the voter tabulation technology used in the United States, actually denied the possibility that there could have been third-party access to their machines. Then, after an investigation, they provided a letter to a senator, Senator Wyden, also known as the Wyden Letter, several years later in which they admitted that PC Anywhere, which was a software system that had a critical security flaw was installed on several machines. So this brought up a lot of different issues that InfoSec advocates have been knowledgeable about for years, but really never were never made priorities by the right people. One of which was the importance of user education and, uh, you know, two factor

authentication. Well, multi-factor authentication is the subject of our, of our next, uh, track one talk here. I'm sure that that is going to get a more, uh, investigation, but just thinking about the weakness of third-party vendors especially, the weakness of third-party products when they're connected together without good governance. The smallest weakness thriving without that governance. The fact that 90% of voter tabulation technology was possibly upended by this weakness. And also the mystery, which is the real problem here, that from a hacker perspective, it's probably easy to overlook a lot of these faults, But the issue that ES&S originally lied about it and that the investigation was almost impossible because that admission came years after the original suspicions,

a lot of states had to create their own security commissions to investigate this at their taxpayer expense. So if there had been more of a unified governance in investigating this technology, a lot of this response later would not have been necessary. But we're trying to move on here a little bit more into medical technology, which is something that I try to use as an example for good information security governance. Because as I mentioned before, I've often found myself the only infosec advocate on a team or sometimes in an organization. So a few of the case studies that really resonate with the decision makers of healthcare are the ones that are also probably famous in the

information security world. Anthem is the granddaddy hacks began as a phishing scam and culminated in a seven-week window of access for multiple hackers in 2014-2015 to access the names, healthcare ID numbers, and a whole lot of personal information for nearly 80 million customers and resulted in hundreds of millions of dollars in punitive fines. A state actor was postulated in an investigation in 2018, which was confirmed in 2020, but this was so massive that it made the numbers do this. The spike you're looking at is the year of 2015 when at the top left you're seeing individuals affected by healthcare data breaches, at the right you're seeing the size of average data breaches, and at the bottom you're seeing the number of records

exposed in hacking or IT incidents. 2015 that spike is almost entirely Anthem. But of course you might be thinking, numbers aren't helping me sell the importance of increased InvoSec advocacy and care. Well, these numbers do because what happened was the hacks didn't disappear. They just went, they just decentralized. Median data breach size is at an all-time high, or at least it was with the last complete year of record keeping, as well as the number of healthcare data breaches that affected more than 500 records and also the overall number of hacking or IT incidents reported by healthcare networks and their third-party vendors. And if this isn't enough to motivate decision makers, the fines aren't going anywhere. Although they have dropped in some cases, the

penalties that companies pay for violating HIPAA, the Health Insurance Portability and Accountability Act, which keeps healthcare providers accountable for what they do with these records and who they might expose them to, end up paying just like Anthem, usually on a smaller scale. A couple other case studies that are related to this that came up a lot in decision making about more attention to InfoSec are AMCA, the American Medical Collection Agency, which as a third-party payment portal, allow an unauthorized user to gain access to Quest Diagnostic records and several other companies that used it as a third party. Same deal, hackers access names and personal information for up to 70 million customers, at least 26 million confirmed so far. And it had repercussions for everyone

involved. The product was immediately disabled, which involved a loss of trust in business for a lot of those big vendors, including Quest. AMCA operations were immediately suspended, and recently the whole company filed for bankruptcy. One of the big lessons from this particular hack was... the importance of vetting third-party vendors, that this payment portal had a lot of security issues that fell through a pretty poor governance system in the company that developed it and the company that ordered it. Next is SAIC, the Science Application International Corporation. This is famous for being a sheer bonehead move of data loss, an unencrypted backup including almost 5 million records patients at TRICARE, which is the US Army, Navy, Marine Corps health insurance system,

was stolen from a car while in transit. So this brings up a whole lot of issues. I've cited this so many times I've been accused of calling it the World War II of hacks just because encryption, encryption, encryption is something that even in internal records is often overlooked, especially in internal records, because there's some sort of buyout from dealing with it. But this in cases like it show that between internal problems that can't that simply can't be predicted and also the sheer bonehead move of not encrypting vital data from beginning to end is something that executives have to look closer into. And the roles of the InfoSec professional when it comes to these big emergencies, just to wrap up the when chaos reigns section here, is to understand

the risk profiles that a project or organization is undergoing. This, especially in medical care, is a highly diverse and changing set of scenarios, especially with IoT devices bringing up a whole lot of security concerns when they are brought into patients' rooms or interact with patients' other technologies. The legal and regulatory environment, HIPAA, for example, is something that we all operate in when we're dealing with medical records as any sort of professional. And that's something that InfoSec and IT professionals need to be highly aware of is the regulatory environment that they're working in, especially when it comes to medicine or politics. And also considering the human and technological resources involved. This is less of an issue for people who work in big organizations, as people

who work in big organizations can tell you. It's more important to have the work done than necessarily keep it under budget. But smaller projects and organizations might try to nickel and dime out from security concerns that could cost them big later on. So it's important for InfoSec advocates to consider what they have to fight from beginning to end. And also, some of the easiest moves are the ones that are most effective. Making lists of required data and unnecessary data. especially when you're holding your project or organization's ability to keep data safe in any kind of suspicion. It's important to eliminate unnecessary data from the chain wherever you can. That way, people simply aren't responsible for it. Systems simply aren't responsible for it. And then recommending work that

can be done to execute your plans, creating guidelines for the organization or the team or advocates for the user to consider. This is often more... Corrective than preventative. We often say in healthcare, we love our patients, but we don't trust them. So we often create protocols that simply edit out any possibility for the user to make themselves or the system vulnerable. And creating an incident response plan, because the next thing you'll have to do probably is respond to something. So corrective action, which organizations are often calling resilient action, the ability to get over something bad that's happened, is you're going to have to activate that plan. You might be the one to execute it. You might be the one to communicate it. You might be

part of the team that runs it, but it's important to get it started as soon as possible. And also leadership will want to know what contributed to the attack. And it's important in a lot of ways to know what sort of executives you are dealing with at this point, because do you need to use plain language? Do you need to use technical language? What's the likelihood that you're going to get the decision that's going to help you as an InfoSec professional, make the calls that protect the data or respond to the loss of data. And also be immediately ready to advise future preventative measures because the only real time that big organizations get anything done

worth doing is when they absolutely have to. So this big emergency may also prove to be an opportunity in the classic sense of the word. And now a little bit that might seem obvious to people who worked in any sort of corporate or creative environment, but where there is no help, we're going to go through a lot of the roles that you may communicate with when the person that you generally communicate with, who's often a project manager of some kind, is missing, distracted, incompetent, lost in a war zone, unavailable, been fired, etc. So instead of CPR, we've got ICR, that's Identify, Communicate, Resolve. partially because you have to identify who you need information from or who you need to give information to when

the person who's generally going to do that sort of thing isn't there. You need to communicate it, get it back and forth, and then you need to make sure that whatever you just did resolved the problem because that's often also the job of who's missing in that situation. So when it comes to medical technology development, here's a brief outline of the creative or technical staff that are often involved. And At the top, we're going to go through a lot of these roles, information architects, user experience researchers and designers, user interface designers, and then content, all often reporting to some sort of project manager who may pass on products or information to an account manager, and then eventually the executives who's ultimately responsible for the organization's

work. Information security is kind of nebulous here because you don't really think of that as part of an agency setting. especially when you're producing communication and not necessarily technology. But it's always important when you're working with any sort of system that will later handle records or collect data, transmit it in any way. And at this point in most healthcare settings, that's pretty much all technology. So going through these roles just to figure out what they might need from information security or technology in general,

The UX staff, these are the people who create a lot of these products from the ground up. They analyze the need. They often reverse engineer results off of competitive analysis, looking at other developments that were similar or equivalent at some earlier point, and then try to provide some sort of framework on the client or the user's needs. This is usually a briefing for the UX designer. If they need to talk to information technology or information security, they often want to know what they can do. And this is also what you want them to know. They often make the decisions that help prevent unnecessary data or unnecessary interactions from occurring in the first place. And this is also in line with user interface, which is our next move here. Briefly

talking about designers, they're the ones who translate a lot of the research into concrete plans. And they're the ones who either create or have to communicate the specifications. So this often relates to the ability to interoperate third-party information security apps or technology. They're the ones who are going to need to know how that might affect their project or other parts of it that they're juggling. Moving on to user interface, HCI issues is the number one thing that any IT people need to know about UI, is that They are the ones who are going to try to resolve all the user trust issues. They're the ones who are going to try to resolve the need for IoT devices or how they operate with data

gathering mechanisms or systems. So this is also a big part where information security can give and get a lot of advice on how to work best in the organization. Because although a lot of what they create is then later moderated by UX and PM or also other design elements, often also the ones who can best communicate how to prevent unnecessary data from entering the system or prevent any sort of loss mechanism which doesn't have to exist in the first place. Information architects or the librarians, I was often an information architect and making data logical is often, as it refers to InfoSec, more of an issue of preventing those unnecessary or preventing any sort of unnecessary search

by giving people what they want as fast as they need it. And content producers, this is less of an interaction with, especially InfoSec, but IT in general, they're often, if they need anything or if they need to give anything, it's regarding specifications of a project or a product. And then we get to PMs and we're wrapping up here. So talking about all the team members working towards their goals. So they're often the coordinators of all of this work. When it comes to Dev, Tech, InfoSec, they're often reacting to a project within an organization through the PM. The PM is also responsible for the deadlines and specifications. So when it comes to PMs talking about Dev, InfoSec, all of that in general, they often

just want to be able to give the specs and get back what they need to contribute to the product or secure the product. So what to consider when you're working with PMs is sticking to the brief. A project brief for a specialty medical devices is the Bible. It's a starting point, but it's always the thing that defines what you're able to accomplish. So if the brief has any sort of language about securing medical data or considering medical data security, that is often the basis for your work on a project. even if you are not officially part of a project plan it often helps to know the context what's the project what's the product supposed to do what are the what's the technology that interacts with what's on

the back end do all the parts of an app especially if it's related to excuse me especially if it is related to a medical device or data collection unit how do they work together and what are all the specifications that are related and And then finally, as we finally run out of time, how executives often see a project or a product? Well, they're usually responsible for mitigating risk ultimately. And that is what we've been talking about a lot this morning so far is assessing and mitigating risk. So the results of their work has to be the reputation of the company, which is often what drives future business. So they need to consider information security as an investment, as well as a marathon, not

a sprint. So it's often an InfoSec advocate's job to express how things can be saved or projected into the future in a way that helps them do their job now. So what can be expressed in numbers when it comes to options for third-party vendors that are verified? What are the options when it comes to doing that work internally to keep a sort of chain of evidence over any sort of systems that deal with personal data? How do you reduce these risks and how much protection will it buy to invest in them? And also from a going back to the macro perspective, how do you get buy in for a good information security culture? Who are the most likely advocates to join you

in positions of power who can really make a difference for an organization and multiple projects? And then how do you prioritize these potential and real threats, which is often which is also something that spam brought up in the in the keynote is Threat assessment has to be one of the number one things, one of the real products that InfoSec advocates bring to the system. Consultation is often less of a product in itself, but those sort of protocols, that sort of ability to assess a threat and then allow others, including yourself, to prepare for it is the number one thing that you can bring to, and also the number one thing you could recommend you bring in the

future. to these environments that are producing new products and projects. And with that, I guess I timed it almost perfectly, although I will now go back on Discord to answer any questions or help with any references. If you're interested in more of these case studies or any specific examples of communication, you are also welcome to email me. I'm also happy to provide the references that are directly referred to what we've been talking about today. So thank you very much and please enjoy the rest of B-Sides.

Good morning, good evening, or good afternoon. I am Michelle Khan, and today I'll be talking about breaking MFA. A little bit about myself before I get started. I wear many hats. I'm kind of a jack-of-all-trades and master of view. I'm the cybersecurity practice lead at a company as well as a virtual CISO. I'm a I'm an ethical hacker. I've been doing pen testing for a while. CCIE, Certified Social Engineer. I do OSIN investigations on the side. Privacy advisor kind of goes hand in hand. Have a lot of multinational experience from small to large organizations, education, hospitality, you name it. Pretty much every sector needs it. But today, I'll be going over Some of the myths

around MFA, what is MFA, some of the important hacks that have happened around this technology, two-factor authentication, multi-factor, some mitigation steps I'll be going over, some of the options that are there around vendor technology. I'll demo some of those things. Some things you should consider as an individual and as an organization when you adopt multi-factor authentication as a technology and some best practices and obviously costs related to it as well. But by and large, I'm going to be showing you some really cool demos. Now we start this conversation with the firewall itself. I consult a lot of organizations and their first answer to security is, hey, we have a firewall, we're secure. My answer is

always, Look at all these threats that are out there. A firewall does not see these things, stuff like phishing, malware, unless your firewall has advanced malware protection and stuff like that. But ransomware communicates outside to its command and control, account compromised, someone has your username, password, doesn't matter what firewalls you have or what defenses you have within your organization. Social engineering is probably the top way people get in, phishing, wishing, impersonations. It could be human error with default ports or credentials or unpatched vulnerabilities, or we've seen in the past, breaches happen because of insecure cloud configurations, AWS buckets open. So there's a whole bunch of things that happen within security. We need to protect ourselves by taking a layered approach to this. The more layers we have,

the more secure we are, and the harder it is for the bad guys to breach us. One of these layers, which we'll be talking about today, and a very important layer, is multi-factor authentication. Why MFA? Passwords are broken. They're not good enough. It's a couple of decades-old technology. When you have MFA enabled, It requires more effort to be breached. It's not impossible. I'll show you that today, a couple of examples. But it's also very easy to implement. There's no excuse not to have MFA if the option is there. And you're getting instant results. It's not like a firewall configuration or some email filtering, spam filter setup. Those take days. Those take weeks sometimes to set up, expertise, dollar amount.

But with MFA, it's so easy, it's almost a no-brainer. Here's an example of when MFA could have been useful. The Twitter accounts of a lot of these NFL teams were hacked. And it was so easy to hack that some say it was primarily because of MFA. We don't know the exact details. But if MFA was enabled on these accounts, it would have made this hack so much more difficult. So let's listen to that. I want to show you some demos. Let's clear out the concept between 2FA versus MFA before we go any deeper, just to set the stage. So the multiple factors, so the first factor is your password. That's 1FA, call it, or sometimes that's your

pin or a certain security question you get in. primarily 99.9% of the time, your password is your first factor. Your second factor is usually that token that comes on your phone or that SMS that's there, or some providers will send you an email with that code, a YubiKey, a hardware token, badge, all those things. That's your second factor. So something you know, your password versus something you physically possess makes it harder for anyone else to breach both. add to this, you can add a third factor, something that's inherent to you, like your fingerprint, your facial recognition, your iris, those type of things. So a practical example of 3FA or MFA is you log in with your password.

You get an SMS on your phone. But to view that SMS, you need to unlock your phone using your fingerprint or facial recognition, whatever your phone supports. So now you're using all three and that's multi-factor authentication. These terms are interchanged every now and then. I may use them back and forth as well, but officially these are the definitions. Now there's many types of MFA. So before we break into something, we've got to know what options there are. And I've listed some of the common types. of multi-factor authentication here in order of least secure to most secure. Least secure SMSs, why? Because there's SIM swapping attacks out there. Emails, your email can get breached as well or be diverted.

Then more stronger options are hardware tokens or apps or something that plugs into a USB. The strongest one is biometrics because you possess those. saying none of these can be breached. All of these can be breached, but why make it easier? Use the strongest methods at your disposal. Some of the key facts and myths. You know, we talk about MFA. It's very secure. Yes, everyone should be implementing it. It's a no-brainer. Just do it. But know that almost half of the cybersecurity breaches are not preventable by strong MFA. These are by know before, and the next slide shows you why. So here are some of the common methods that you can bypass multi-factor authentication through social engineering, asking the person

for the code. It may seem simple, but I'll demo it in a bit. If you have physical access to their devices, to their phones, then game over. Phishing websites do that. They fish for credentials. I'm going to show you how I can fish for more than just credentials. SIM swapping, we've heard about that on the phone a lot where somebody calls your ISP, pretends it's you, gives them your details and says, hey, I bought a new phone. Here's the IMEI number of that new device. Could you swap over previous number to this new device and now you own that number through social engineering and now you reset the password you get the sms code instead of the original person that's sim

swapping trojans or malware installed can bypass that as well but today i'm gonna show you session tokens in fact session cookies is what i'll be stealing today one of the more advanced techniques yet it's simple to perform when you see it. Account recovery SMSs sometimes can be, when configured wrong, you can bypass those as well. There's a bunch of other ways, but let's get into the simpler ones first. So hacking RSA tokens. What's an RSA token? Let's look at an example of that. So Google will show you This is what an RSA token is. This was pretty popular back in the days. It's not so common anymore. It's a six-digit rolling code on this device. This is that second factor, something you possess. So the whole point

of an RSA token or an RSA key is that one person possesses this at any given time, and you obviously can't share this. Well, not when you're dealing with... you can bypass this. So this was taken from Shodan, I believe, a picture of a live webcam stream showing the six digit rolling codes required for 2FA. You can read some of the codes on the bottom one. This is when you want to share it amongst people. So sometimes you got to think outside the box. And if you get a lot of information, to the stream, which in this case was open, you have access to those rolling codes or that second factor. So this is the first hacking technique. You must be saying, this is not hacking. This is

OSINT or just thinking outside the box. But before I show you the very next demo, let me show you the difference of the two different types of codes that you can receive. TOTP, that's the time-based one-time password versus push notifications. So let me give you a live example of what these are. Let me just refresh the space. So if you go to demo.duo.com, Duo is a popular vendor for multi-factor authentication. On this demo, you can see, let me try to make this a little bigger. So you log in with your email and password. That's your first factor. You click sign in and you get the option. Where do you want that second code? Let's do passcode. The most common option, this could be Google Authenticator.

You bring up your phone here on the right. You unlock it, click on it and you get that six digit code that changes every 30 seconds or so. You take that code, you put it in here and you press login. That's the most common way of doing Now, there's something called push notifications as well. And let's demo our first hacking technique, social engineering. So let's start with one assumption here. I have your password. How? I got it by a phishing attack or because you use the same password everywhere. I got it from a data breach. Getting your password is not a good thing. It's not difficult nowadays, but getting that second factor is. So next, I spoof my phone number to

let's say your IT department and place a call. Now, I set this up in the back end. So I know your username and password. So I enter your username and password in the field. And before pressing sign in, I call you. And the phone call can go something like this. This is Joe from Helpdesk. We reset your multi-factor authentication token to enable 256-bit encryption for better security. Can you please confirm it still works by clicking on the prompt on your phone right about now? They get this prompt. They're like, okay, they click on it and it says approve or deny. They press approve and you're in. Thank you for safe and have a great day. And I

put the phone down. So social engineering is extremely easy if done right. Right circumstances, right pretext, the right amount of OSINT, and then you place a call like this. I made it sound easy. It actually is easy. I've done this to a few companies. All you need is one hit. Don't forget, you may fail a few times, but when you have a company of a couple of hundred or thousand people, All you need is one person to fall for this. And this is a very powerful technique. The second technique requires a little bit of setup, a back-end setup. So this involves phishing, and then a man in the middle attack, which is a proxy server, and then

stealing session cookies. All of this may sound a little complicated, but let me show you in real time how I would do this. So I've set all this up. Let me go to my Kali box. And let me just sign in here. Wrong password. All right. So I'm in my Kali Linux machine here. I have Google Cloud running. I have a server running here called Evil Gen X2. And let me show you what that is. So there's a tool out there called or at least that's how I believe it's pronounced. It's on GitHub. This is the proxy server and the entire tutorial is here if you wanna know how to set that up. So this is my proxy server. My phishing framework is go fish.

And here is my email that I'm logged into. This is a sock puppet account, an alias account. which I'm going to be using for this demo. So I just got this email. It says, and this is the phishing email. So it starts with phishing. Here's an email that, so let's look at the from address. It says Microsoft at verification.com. That verification has a spelling mistake in it. There's no I towards the end. So this is the phishing attack that I've sent. It says, we've removed access to your OneDrive temporarily. to OneDrive here. So typical asking you for to take an action to click on something. When I hover over this link, it's tiny on the lower left side. You

can see that the link goes to some other website. Kind of looks legit, but it's not legit. But before I click on this, let's go back to the back end. So this is what the hacker sees. I've purposely kept these two things separate and not on the same operating system. So you see that they're completely segregated. So I'm running this server on Google Cloud. Here's that server. Let me reconnect the session timed out. So this server is running evilgenx. And this is the hacker's machine here. The hacker's machine has internet access and everything. So I'm kind of set up here trying to see to log into that guy's device. So let this backend server refresh. Give it a

few seconds connecting. And there we go. So this is that server running. Let's go back and restart this. So now Evil Gen X is running and it took a couple of hours to set this up. Now that I'm set up, Now I sit here and wait for someone to click. So let's click and see what happens. So I click on this link here. It opens in another window and it asks me to sign in. Now you see the URL bar there. That's not really Microsoft. That's e-authenticate.com. That's a domain that I own, but hopefully most people won't notice this. Now I'm going to log in here. So I have the credentials of this person sitting right here.

Put that in and then password. So I'm using Bitwarden as the password manager. And I have a really long password here. I sign in and now it should ask me for the second factor, the code. Let's go back and see what the hacker sees. So the hacker is seeing down here, my password, really long password here. see the username was input. So I got both of those things, but I won't be able to get in with just this because MFA is enabled. Now let's enter this code. The code is this rolling code here, 17 seconds left. So let me copy this code, put the code in here and don't want to remember this device, but let's

verify. And I, as the user have logged in to my OneDrive. Let's go back to the hacker, the more interesting part. On the hacker side, it says authorization tokens intercepted and my job is done. So let's look at what I really got. What did I capture besides the username and password? So I go under sessions and I see this is what I got. So for those of you curious to know what a cookie looks like, this is what a cookie looks like. I stole the session cookie. So let's copy this cookie. Now, how do I log in? If I use the username and password to log in, I'm not going anywhere. I don't have that rolling

code. So let's go here. Let's sign into Outlook on the hacker side. Outlook.live.com and I'm asked to sign in. I'm not going to sign in. I have something better here. I have the cookie. So let me first remove all the spaces from the cookie. It's going to give me an error. So I have this tool here. I paste in the cookie. It removes all the white spaces. And let me copy that cookie. Okay, going back to this screen here. I can't log in. I refresh. It asked me for username and password. I have a plugin here called edit this cookie. I import the cookie that I just captured. Here's that cookie and I press OK, import. Now, same screen

here, nothing has changed. I go back to outlook.live.com, press enter and fingers crossed. I am in, I'm in that user's account. I did not need his username or password. Just to see if I'm really in, I'll go through some of the emails. Yep, that was the email that the user clicked on, still loading. This is that email, the phishing email, so I'm in. From a user's perspective, the user's still also in. They don't know anything has happened, simple as that. Sure, it required a couple of hours of setup, but you see how dangerous this technique is with just stealing a cookie. And this session, I can keep refreshing the page and the user would never know that I'm in their account. An advanced technique, but

if you know how to make it work, it works.

Mitigation. How do I stop myself from doing something like this or a hacker from getting in? Well, firewall is not the answer to that, but some of these MFA techniques have AI based or anomaly based solutions, which means if something's fishy. So for example, right now, if I look at my activity in my Outlook account, it'll show two people have logged in. So if the MFA provider like Duo in this case, they have something on an anomaly based solutions, where they can tell that, hey, you've logged in from a different state, a different IP address, different country, I'm not gonna let you go through. So you can block, geo block different countries and say, hey, if a login attempt comes from China,

yeah, Hotmail is gonna let the username and password go through, but the MFA is not. You'll never get that second factor because it's being originated from a banned country within your dashboard. There are single sign-on solutions out there which make life a little bit easier. Enterprise-grade solutions. Test it, pen test your solutions. If you think you've hardened your security well enough, hire a pen tester and make sure there's no holes left there and they'll discover a few then patch them. User awareness training is probably number one here, it should be. If a user is aware of these techniques, are less likely to fall for them privacy is the other thing if i didn't have the username

to phish or the phone number to wish this attack would not have gone much further people advertise their phone numbers their personal cell numbers on their email signatures don't do that only advertise the corporate phone number and let it forward to your personal you know some things you can't hide but the things that you can Try to be a little bit more private, try to be harder to find from a personal perspective, and you will thwart some of these attacks. Zero trust, that's a buzzword. I don't know how that got in this slide. Sorry about that. Culture. If you create that security culture in your environment, again, you are less likely to fall for these type of scams. If a

phone call like that came to your organization and you have that security culture in place through training and through tools and stuff, you're likely to say, okay, let me call you back before I take any action. Let me call my IT department and put the phone down and you call back. These things come from awareness and culture. But how effective is MFA? This is a chart from Google.

And just look at the yellow pieces here. Let's look at SMS codes. So the yellow bars here are the targeted attacks. If you were a target of an attack like this and you used SMS as your code, the account takeover prevention rates are 76%, device from 90%. If you're using a security key, 100% protection according to this survey. And I'll show you why this works. But the least efficient are location-based because a hacker can use VPNs, change their originating IP address. Phone numbers, you have a 50-50 chance of getting breached if you use a phone number as your second authentication. So some are weak based on stats, some are strong. That's the only point here. There's plenty of

options on the table. All these vendors exist. There's many more. This is just the tip of the iceberg. Which ones to choose? There's plenty of differences between all of these. Some are free, some are paid solutions, some have basic features, others advanced. Let's look at some of the basic technology. By no means am I gonna describe what this technology is. I probably don't know half of the inner functions of how these work. But the most popular ones are the one time passwords that I showed you, or actually the time-based one time password, which was this thing here. It's a rolling code. This can be on your phone, on your desktop. This is by far the most popular method on your phone, if that's your second factor.

So that's based on time. It can be based on other factors, hashes and stuff. But make sure you're using the latest technology like FIDO, FIDO2 or web authentication. Those things really help. And a demo on this, so hardware tokens, this was the most powerful method. And this is one way that you could have thwarted the attack I did before, the proxy attack. And I'll show you how.

So let's go back to Let me show you a live example. Let me log into my Treasurer. It has two-factor authentication and I'm gonna use a YubiKey to get in. And a YubiKey is this device. So I have one of these devices, a USB-C device that I'm gonna use to log in. And I wanna show you how quick and easy it is. So I log in using my password manager and it auto populates my 70 character password here. Press Login, and it asks me, a little pop-up comes, but basically it wants me to touch my YubiKey. There's a little metal stripe on it. Let me go ahead and touch it. There, I touched it, and I've logged in. That's how simple and

quick it was. So Google Captcha, probably because I'm on a VPN. So I basically logged in with just a touch of a button. I don't know why I'm doing this, but yeah. So that's how quick and easy hardware tokens are. Things to look for when you're looking for the right vendor. There's many considerations here. Push notifications. Not everyone has those. The basic Google Authenticator, it's just rolling codes. You got to manually put those in or copy paste those in. But other vendors like Duo or Microsoft or bunch of others you saw on that list have something called push notifications literally accept or deny it makes the user adoption much easier make sure you have backup goals or means to back up that entire two-factor authentication system

do you have online access or is does that mfa only work when you're connected online i've had this issue with customers where they're like hey we're in a secure or whatever, or underground where there's no wifi or there's no LTE signal and we need MFA there, well, hardware tokens, YubiKeys are the way to go there. Open source, is the tool open source or is it proprietary? Has it been audited? Is it being checked for feature updates and bugs, all those kinds of things? That's important to know as well. Features like geolocation would block some of those attacks. How easy is it for the user to enroll themselves? Or does the admin have to enroll thousands of users? It kind of gets in

the way. Endpoint security, some of these features are embedded. Like with the Duo app, if my device is not updated to the latest iOS, it'll be like, hey, guess what? You're not allowed to log in. that second factor until you upgrade your iPhone or Android or whatever, because the admin has set this policy. So there's endpoint security built in there as well. There's integration with multiple apps that can help. There's different prices all over the board from free to expensive. And we'll get to that in a bit. There's device health and multi-device syncing and stuff like that. So all these are good considerations to think about when choosing a vendor for your organization because you can't hop around. You've got to make that

decision once and kind of stick with it. So adoption is key. We talk about all this technology. If no one's implementing it, then what's the use? So 80% of breaches are still linked to passwords. So we got to still protect those things. And a multi-pronged approach here is your best defense. Single sign-on, MFA, password manager. You saw how I logged into Twitter. That's the route most people should take. Password managers, you shouldn't be remembering your passwords. My password for Twitter was 70 characters, and that's the average I get for most websites. Whatever their max is, I try to max it out.

you got to protect yourself in many ways. Otherwise, you're not going to adopt technology. These are stats from one of the most popular password managers out there, LastPass. And before we get into the stats, realize that these are users that are security conscious. They're aware of password managers to the point they use a password manager for pretty much everything. And from those where users, security conscious users, only 57% had adopted MFA. So think about all the other half that don't have MFA and don't have password managers. So there's a big gap there. And even from the ones who did MFA, they went with the basic mobile app route, which is fine. But hardware solutions like YubiKeys, like I use, very few use them,

biometrics even less. People think it comes in the way. Why do I have to put my thumbprint or whatever on the phone to unlock it? They keep weak passwords on their phones. So it's a layered approach. Try to get in a few of those layers in so that you're a little bit more secure than the rest.

So these are some of the hurdles I see. So I talk to a lot of clients, try to convince them on MFA. And the objections I get are, oh, it's inconvenient. You saw how quickly I logged into my Twitter account with a YubiKey. It's not inconvenient. Oh, it's disruptive. So are seat belts. But we still wear them. Lack of interest. If you don't have interest in the corporate security or securing yourself, then don't complain when you get hacked. Or the cost. The cost, I guarantee you, is less than your Netflix subscription. So you got to weigh the options there. But some of my more diplomatic answers would look like this. Acceptable level of risk that you're willing to take. What is that? Do you have insurance? So if

you get hacked and you still have backups and insurance policy and plan that you're willing to spend money on, you're fine there. Education and training. Are you doing any of those things? That's going to the users accept this technology better because now they know what the dangers are they're going to be more comfortable adopting MFA. Overall it's increasing your security posture. You ask any CISO or CTO or CIO what's your goal? Is it to increase your security posture, become more secure? They're like yes it is and MFA is one of those any controls that you can put in place to increase your security posture. So they should all be on board. Leverage partners if it's complicated. You don't have

to implement it yourself. There's tons and tons of partner organizations out there that will do it for you. Go with demos and proof of concepts if you're not convinced yet. And I talk about large organizations, not on an individual basis. You and I can simply go on our phones and enable it on our personal accounts. This is more on the corporate side, the corporate breaches, and that requires a little bit of thought process. But the best practices on implementing this. So there's a wrong way to do it. then there's a right way to do it. I just broke MFA in a number of ways, social engineering and cookie session stealing attacks, and there's a whole bunch of others.

But there's some best practices around this. So first and foremost, use better technology. Don't use SMSs. Don't use emails as your 2FA. If you have to, that's fine. If there's no other option, that's fine. But as long as there's a better option, use that better option. fine tune those things. If there's a geo blocking option, some of the bigger vendors have that, use it. There's a lockout policy option, enable some of those things. Vendor vetting, when you're choosing for a vendor, make sure they have a secure development, software development lifecycle in place. Are they constantly patching and updating their systems? Don't go for a vendor that has not updated their software for years. It's gonna be buggy.

Do they have support when you need help? Do they audit their own systems? You can't trust a company that doesn't audit themselves. Backup codes, always keep those in case you lose your YubiKey or your phone or your second factor device. You must have those backup codes. I save my backup codes on my password manager under the notes section. Privacy, hide information as much as you can. I do a lot of OSINT. of open source intelligence and I constantly see personal emails, phone numbers, their social media gives their date of births. A lot of information is out there for password resets, for breaches, for phishing attacks. Suddenly all the options open up to a hacker if you're not private. But if

you are, you lead a much more private life, then the options are very limited and then you can better protect yourself with those limited things. that you expose to a hacker. Security awareness training is a must in organizations. I considered this session today and all the other sessions today before and after me as security awareness sessions for all of us. The more we know how stuff works and how it breaks, the better prepared we are to protect ourselves. I come from a very strong pen testing background, so I always say, you're not testing your technology, your solutions, then it probably doesn't work. The only way to be sure is pen test it. Hire a good pen tester and try to break it.

It's not foolproof. A pen tester may or may not succeed, but it'll give you some good results. It gives you a better chance of survival against a hack. And then there's all these other complementary technologies like some use password managers. There's that would have avoided me clicking on that phishing link in the first place. If I had the right content filter in place, it would have identified that URL as a known phishing URL or something else that was phishing, and it just would not have gone through. Device posture, make sure devices are healthy, there's no malware in them, and stuff like anomaly detection. All of this helps back and forth. One thing I did, miss out pointing here was,

so for the YubiKey piece, so you see here when I was logged into my account, my Hotmail account, the URL bar above said outlook.live.com. That's fine. But when I logged into this proxy server by clicking on this phishing link, my URL bar kind of went in a different direction. It was, Let's click on that again. Let's open it in a new container. So when I clicked on that, it went to login.mailbox.office.live.com.genx-e-authenticate.com. So it's not Microsoft. So here, if I had used a YubiKey instead of those three digit codes, what a YubiKey does, that hardware token, when I did that earlier, you saw a little pop-up that came up here and asked me to touch the

YubiKey. That pop-up actually looks at the URL bar first. It sees that that YubiKey is registered for this account under that certain URL and that URL should have been outlook.com. So if I had used this technique there, it would have failed because my YubiKey would have said, hey, this is not outlook.com. Let me fail that session right now. So it would have failed. But with SMS codes or the, or, six digit rolling codes, it has no idea which site I'm browsing right now. And that's why using a proxy attack technique like this, a YubiKey is the only form of defensor.

So I want to end with the cost because cost is a big concern. A lot of people mention, oh, that's too expensive. Like I said, it's less than your Netflix cost. On the corporate side, on the private side, there's three options. So here's my cipher message for the cost. This is how much it costs. It literally costs a cup of coffee per user per month. So if you don't believe me, here's some of the published costs from Duo, one of the big vendors out there. you can go to duo.com slash pricing and actually look at their pricing model here. They have a free tier version. They have an introductory version here, but their most popular version is $6 per user

per month, which gives you all those features that I talked about, not just MFA, but a whole bunch of other good stuff. But not just Cisco Duo. Microsoft has similar options, similar pricing, Okta has very similar price structure and Ping Identity. A lot of the others are around the same price point. So the bottom line is if you can afford to feed your employees coffee once a month, you can definitely afford MFA. There's cost, should not and cannot be an excuse here. So how do you get started with MFA? MFA, do a self-assessment or have somebody else assess your infrastructure, make the right technology decisions, review the vendor options, do some case studies with a proof of concept, and then adopt

the right strategy. There's many things to consider here, but this is the methodology you should be taking to adopt it, and it's not hard. Once done, you are much more secure than you started off with. Thank you for having the patience to go through this. And if there's any Q&A, I'll take that right now.

Check the chat.

So there's one question on YubiKey. I just saw it. If using a YubiKey, how does one as an individual user recover from a lost damaged token? Great question. I have two YubiKeys. So when you buy a YubiKey, you always buy them in pairs. And you register both with your account. I've noticed some problems that some services won't allow you to register two YubiKeys. Google allows you to register multiple YubiKeys, more than two, but then there are others that don't. You can only register one. In that case, if you lose that one YubiKey, yeah, it's not going to work. But then this is why you have backup codes. Have those one-time backup codes saved. Every time you register

YubiKey, they give you backup codes, either one backup code or 10 backup codes. Save them because that's what's going to save you when you lose that hardware token.

all I see. Alright, thank you very much.

with me like a haunting melody what do spirits say

John Lucinius. I've been doing forensics probably since the early 90s. I've been programming computers since the late 70s in high school. But this talk is about forensics, and it's particularly about lockpicking forensics. So what we're going to do is we're going to basically start from scratch here. We're going to say, if I need to do forensics on a lock, what do I need to do? Well, first, you're going to need to understand how forensics is, and then what a lock is, how it works, how to pick a lock, and what it looks like forensically afterwards. So at the end of this presentation, we should just rip apart a lock and put it under a microscope and see what we

see. That's the end game here. But to get there, let's talk about forensics real quick. I do have some slides. The PowerPoint and discard aren't working together right now. So oh well. Let me know if you will. Hopefully we'll get the screen up with the microscope here at the end of the show. So forensics. The main principle in forensics, no matter if you're looking at a crime scene, a murder scene, looking at a hard drive, looking at a lock, is you can't enter someplace without leaving something behind. You can't leave someplace without taking something with you. That's the principle of forensics. You're going to leave something behind. and there should be evidence that you take out with you. It's a little bit harder digitally when you

hit a web server. I understand that, but the same principles still apply, especially in lockpicking, right? We're talking about physical locks here. At least with traditional forensics on, say, a hard drive, I can clone a hard drive. I can clone a VM of a server and look at that. I can use a write blocker and not alter the evidence. With a lock, you got one shot at it, right? It's probably going to be... of the door or let somebody cut it out for you. Or you have to, you can't make a copy of the lock and then work on a pristine copy and not worry about the original evidence. Whatever you do that lock, you're going to destroy the original evidence. So it's important how to know how

to know how a lock works before you even look at it. It's important to know how lock picking works. So you don't do the same thing the lock pickers, potential lock pickers did to lock their evidence and then you have to know how to take it apart in such a way where you can prove later what you did. So that's what we're going to look at here. But first, how does a lock work? I really would like to share a screen here or something, but you know what? Why don't we just look at a lock? How far can we zoom in on this with the eyesight camera? This is a regular door pin lock. You

would find the lock. It's probably more fun looking at a diagram anyway there how's that how's that coming rando okay so this is a lock as you see yeah you've seen them every day on doors and things like that wherever you go in you put the key in how's the lock work you put the key in you lift the pins and then the lock turns so there's things inside that make that happen right things generally look like that. Let me turn my light up to see if you can get some more light on this. There we go. So we have those shafts there are where the pins go up and down. There are springs on the top that

keeps the thing spring loaded. And there's pins on the bottom. There's two sets of pins. The driver pins are on top near the springs. They're up here. Let me see. They're up here. And And the key pins are down here with the keys. Let me get a different lock here so you can see a little bit more what I'm talking about. It's not open yet, but up here are your springs and driver pins. Down here are your key pins because they touch the key. This thing up here is called the outer cylinder. The thing in the middle is called the plug. This obviously is the key. It's important to know what a key does when it goes into

a lock and what it doesn't. The key doesn't have any choices. It has to go in straight and stay straight because of the way the key is made and because of the size of the keyway. It will prevent the key from going side to side and up and down. Also, when you use the key, it's important to know that the key goes in, the pins lift vertically, usually without much friction against the walls, and then the lock turns easily.

In lockpicking, it's rather the opposite. Here's a practice lock from Tool. Here's one of the more modern lockpick sets. Comes with its own wrench.

Comes with an assortment of tools. to like the half round

or the hook, the small hook. But either way, yeah. Okay. The...

The slides are basically text what I'm talking about. There's really not a whole lot more information on there than what I'm talking about here.

So if you wanna put them up, you can. We can maybe share them afterwards. Here, let me go ahead. I can do that real quick. Give me about 30 seconds here, share a slide with our Discord folks. We drop and drag these things on.

They're small. I just got to get these two on the same screen. That's all. Where's our Discord at? There we go.

Upload failed. Yeah, let's do it later, man. I don't want to waste the time here. Okay, so this is generally what a lockpick looks like. It's a straight piece of metal. It's got something on the end. There's various lock picks. There's wavy ones. There's hook ones. There's diamond ones. Pretty popular. All designed to lift up the lock, lift up the pins, and then turn the lock. Note that's the different order than the regular key. You put the key in, and then you turn. There's no friction. There's no tension. The key also will hit the pins the same way every time. By very nature, put this when I put this lock this pick in sorry it wasn't it was off video there

by every nature when I put this in I'm feeling around for the for the pins I have to know how many pins are in the lock I have to know which direction it turns I have to I have to know how much tension I need going in I have to know if there's pick pins I have to assess all that when I'm picking a lock unless I've done the same lock many times before the um

all that's going to leave marks. Also, notice how long the pick is versus how long the lock is. Even in a full-size lock that we're going to take apart later, you know, off an actual door, this pick is much longer than the lock. I'll put it over here so maybe the background is a little better. The pick is much longer than the lock. It's going to hit the back of the cylinder. A key will never hit the back of the cylinder. A key will never hit the sides of the cylinder, the top of the cylinder, the sides of the pin. It'll always hit the pins in the same way. In fact, over time, it'll They

come out of the factory very shiny and with tool marks on them. The key is going to basically burnish those marks off. If you Google lockpicking forensics, you're going to come across the paper by Datagram.

He did a presentation at DEFCON in 2015.

It's called Datagram Lockpicking Forensics. That's a lot of what it's based on. There's another guy called French Key, Alexander Trafal. He also has an excellent paper on this lockpicking forensics. And if you go to lockpickingforensics.com or org, let me see which one it is, .com, that is Datagram's site. It is also on lockpicking forensics.

you'll see the effects that a key has. But think about when you put the key in the same key in the same lock over and over again, right? It's gonna wear the pins in the same way. It's gonna do the same thing. If you find in a one mark that's not in the right place, that's a sign somebody put something inside the lock to try to manipulate it. And that sometimes could be enough. Normally, in most cases, because, well, look, right? These locks are made out of brass. locks, quick sets and stuff like that, or made out of brass. This is a quick set. This one's an error. It's all made out of brass or bronze or something soft. These picks, because you

want them to last, are made out of steel. Most picks are made out of steel. So they're going to leave marks every time you go up against the pins. You have to put a force on them. Also, in lock picking, you don't

this does, lift and turn, you simply, first you turn, then you lift, and then you keep turning and keep lifting until you open the lock, basically. You also need two tools, for the most part, unless you're up against a one-pin lock, which is called a latch, by the way. You put the pin in like this, you have to feel, you have to get the thing up the shaft, up the keyway, up to where the pins are, And eventually, if you do this right, and of course, this will never work in a live show. Should have taken most of the pins out here.

Which lock is this? Yeah. And eventually, it'll open like that. If you put the pins in the right position. Now, what is that right position? I have diagrams of this, but apparently, those aren't being shown right now. Can't be shown right now, so we'll just look at this. The inner cylinder, and we'll take this lock apart and look at it closer. When the pins on the inner cylinder line up with what's called the shear line between the plug or the inner cylinder and the outer cylinder, the lock is going to turn. The key, obviously, is designed to have the, with the height, with the different cutouts here.

Here, here, here, here, here is a five pin lock. One, two, three, four, five. So you can see where the pins are at different heights. Those pins, those key pins will form a straight line when the proper key is inserted. And that's what's going to turn against the outer cylinder, cause a plug to turn against the outer cylinder. In lock picking, you don't know which pin is which length. So you have to put pressure against the lock, turn the lock with a wrench, put pressure against it, lift the pins up, the time, find out which pin's binding, and continue down the line until the lock opens. It's a lot of work. Especially if you haven't

seen the lock before, you have to do a lot of testing and investigation. I love in the movies when they just take two of these, put them at the same time, click, click, and the lock on the seven-pin slage lock with four pickpins automatically opens. It's sometimes a little more difficult than that. I just said the word pickpins. What does that mean? So most pins in locks are really smooth. Gosh, I hope we can get the microscope going because holding up a pin, an actual pin from a lock, it's probably not going to cut it. Obviously, they're quite small. This is not going to work. The presentation had it on there. if I can get the microscope going there, Mr.

Rando. You were? Okay. Is it? Okay. I guess my video is pretty small, so I'm not 100% sure, but let's put the... I do have a microscope here, a handheld 10 to 100 power microscope with the light and everything else. We'll take a look at that in a minute. So basically, you have to know how a lock works, what a lock pick is going to do to it, how this goes in, and what the pins look like before this hits it. It could be a new lock. It could be something that's been opened with the key and what the differences are. So we've seen locks. We've seen – I'm sure you know what a spring looks

like. Let me see here.

going to work doing it that way. Hang on. Let me get this going. Brando, where does it look best here? Okay. Let me show the other side, actually. That is what a pin looks like. As somebody described it, it looks like a small bullet. That's the key pin. Notice the end is round, right? The lock, the key doesn't really care what shape the pin is in, right? It could be pointed, it could be round, it could be squared off. The key goes in straight. The pin, the key pin, the driver pin go up straight against the spring and it turns if everything's in the right position. For lock picking, you really care. the shape of that bottom part of that pin. This one happens to be round. Some are

pointed, some are thinner than others. So if you have your thin pick, which we just saw, right, coming up against this pin, you see how thin the picks are. You see how thin the locks are. You see how thin the picks are, and you see how thin the pins are. These two have to marry up right as you're picking it. So what's going to happen is this pick is going to hit the pin pick is going to hit the pins and it's going to slide back and forth, right? You're not going to get it right the first time. It's not going to go in straight the first time because you're feeling around trying to figure

out which pin is binding first. So all that leaves marks. That's the point. These pins came out of an American lock model 1101, in case you're interested. I was in a lock picking contest. This is the only lock I couldn't open. Actually, I did open it. I just didn't know I had it open. So locks, when they're in a door, when the lock's sitting here like this, right, it doesn't require much force to open it, right? As soon as the pins are at the right level, it turns. When a lock like this is in a door, it has a mechanism on the back that you have to leverage to get the components of the rest

of the components of the lock to turn. That takes effort. So if somebody's picking a lock in the real world, a little bit more effort than it does turning it wise than if it's simply something you're holding in their hand in the real world you should be able to find evidence of the lock being turned in such a way where the key would never turn it the um in the case of the uh the american 101 lock it's a padlock but this is the cylinder from the padlock okay what the hardware looks like around it, no matter how complicated they make or protective they make the hardened steel around it, the past, whatever, at the

end of the day, you're just picking in one of these things again, right? Unless it's a wafer lock like on your car or something like that, and those are different stories. At the end of the day, you're still picking this. If you open up a master lock, usually it looks like this inside. It may or may not have this big top part holding the keys, but it has to have something holding it. the pins up here, it has something holding the pins in the springs.

And looks in the door lock without that big piece will have to look something like that to hold the springs. So you're gonna do some, if not damage the lock, you're gonna do at least some marking up when you put your tools in there. Randall, do we have any questions?

I mentioned pick pins before. The American lock that was having trouble first picking and then opening because it required so much pressure. Turns out it had, I don't know if you can see that clearly or not, but there's serrated edges. There's serrated edges on that. There's one near the, closer to my head, I guess. The opposite of the bottom part of the pin. Those get stuck when you're trying to turn the plug versus the cylinder, and those are called pickpins. Those will make the lock feel like it's opening, and then it just locks up, and that's that. You can't turn it anymore. You have to start from scratch. This lock had five of those. Not only were the

bottom pins all pickpins of different varieties.

I really want to see if we can get this microscope going so I can show these guys up close, but that's one of the pins there.

from the lock that I took out. You see the little restoration on the right side there. And then the driver pins on top of these, which I thought was kind of extreme, had these spool pins. Looks like a spool thread. It's what I call spool pins. These are troublesome. You have to lift them straight up if you're going to open the lock. Now, if you're going against a spool pin like this, whether it's in the driver pin or the key pin, when you first start turning it, it will turn easily, then lock up. If you let off the tension and keep lifting, it will generally keep picking. But you have to know you're up against one of these first. So that requires exploration. You can test

it out and stuff like that because it'll have different characteristics when you're trying to open the lock. But this lock had five pick pins. Each key pin and driver pin was a different type of pick pin. That's what made the lock openable, though. None of the pins would bind normally. So as long as you kept putting pressure on it and you got to the end, it would open almost every time it turns out at the end. The problem was once you opened the lock and got everything in position, the way the lock was made, it took so much pressure to turn it. You can never turn it. I lost the wrench. turn it with this enough to

get the lock open. That's why we didn't think we opened the lock. But once I had the key and I realized how hard I had to turn it, then I realized, ah, the lock was open. So all that being said, let's do some forensics, okay? Some actual forensics. So we're going to pick this guy as our example. So somebody says, hey, this is the lock off my door. Can you tell me if somebody picked their way open because my stereo is missing, right?

by the way, if this is the only thing between you, between the bad guys and something valuable, you're probably lost already, right? This is lock sport we're talking about here. The thing of anybody there. This is, I think, mainly these days an intellectual exercise. The thing of somebody picked open this lock to get inside because criminals have better ways of doing it. There's better ways of doing surveillance if you're thinking that way. There's just a million different ways around a lock, right? And by the way, ever been in a situation where you had to pick a lock to get into a room and then get back out, in an actual door, it's much harder to pick the lock closed on the way out when you're

usually in a hurry than on the way in. Just saying, okay? If somebody breaks into your house and picks a lock, they're hardly ever going to bother to pick the lock closed on the way out. Okay? So this is a – I just want to emphasize that this is an intellectual exercise. And also, as, you know, Tool would say, pick locks that aren't your own, that you're not authorized to, and you never, ever pick a lock you depend on. Because eventually you're going to break the pins, you're going to screw up the springs, and it's just not going to work. That's how you can tell a lock's been overpicked, because even the key won't work

after a while. But anyway, let's take this apart and look at, take it apart, look at the pins, see what they look like and stuff, see what's inside of it. So in taking this apart, before you take it apart,

start taking pictures, right? Take pictures under different lights, take pictures at different zoom levels, make an exact copy of this as you possibly can without, you know, your material replicator, which doesn't exist. So take, take, get as much information off the lock before you actually touch it with any of your tools. You can find fingerprints, you can find maybe traces of acid, whatever, whatever was used again, whatever use against this lock. You're looking for tool marks. How did they get the lock open in the first place? If they did it, how did they do it? What you don't want to do in lock picking forensics is ever open the lock with the key. You probably won't have the key in the

first place, but if you do, don't open the lock with the key and don't pick it open because that's the very thing you're trying to find. You're trying to distinguish between key versus picking. If you open it with a key or pick, then just destroyed all the evidence you're probably looking for. Because you have to assume that whoever picked this before you, you're looking at, knows a lot more about it than you do.

In here, well, here's the one that has been opened before. Obviously, somebody, let me try this hand. Obviously, somebody took a nice tool there and opened this up just to show you how a lock works. If you turn it around this way, at the very top, you can see initially where somebody took some type of Dremel or whatever and opened that top part up to get the ball rolling here. Because without that, you couldn't really do the rest. But that was probably how it was initially opened. A lot of locks have screws on the back where you can open the locks. Generally, those aren't available to a lock that's in an actual door. You only see those in lock sports. Anyway, let's go

ahead and take this lock apart. If you've never taken a lock apart before, they are spring loaded. Some of them have really, really powerful springs, some not so much. But anyway, with this one, after we've taken the requisite number of photographs and things like that and documented and dusted for fingerprints and all that kind of good stuff, now we can start pulling things apart. I'm just going to take the pliers and pull this thing that was in red off. that. So I'm opening up the lock, but I'm not touching the front. I'm not touching the pins. I'm just going to pull this off. And this lock does not have powerful springs. And yes, it's been opened before. So I know it. So I pretty

much know what's coming. So let's, if you are going to take apart a lock, I recommend you get something like this to put the pieces in. Or better yet this because they came in they came as a set get something like this where you can put the driver pin the key pins the springs and it holds six rows of each so you can keep everything really organized these things are invaluable when trying to open a lock the um also before we before we look at this on most locks in the back there is a kind of hard to see on i have this tape because I've already done some work on this lock. If I took the tape off, these pins would come flying

out. There's a cotter pin back here. You slide the cotter pin out, and then the inner cylinder plug can come in and out freely. If you do that, and you don't have a following, if it's a full-size lock with full-size springs, and you do that, and you pull the plug out, the springs are going to shoot your driver pins down a very hard time putting the lock back together. That's if you're rekeying the lock. And forensics doesn't matter. The forensics, your goal is not to put the lock back. Your forensics is to figure out what happened. What you don't want to do, and this is on Datagram's site as well. Let me pick one of these. Is you don't want to cut the lock halfway and cut through

all the pins. If you're going to cut into the lock, cut it above just maybe just a little bit below this line right here. you can not disturb the pins as little as possible, but I wouldn't recommend cutting into lock. That's pretty desperate. Normally you can open it up somehow like this. Like these look sealed, but you know, with the Dremel or whatever, hacksaw, fine tooth hacksaw, whatever, you can eventually get to these pins. And remember, you're not worried about putting it back together for the most part. So on here,

has I'm just using

it's forum this one never came out and if you've been picking a lock for a while you take it apart you can probably discover why why it doesn't pick very nicely or why it did pick nicely either way the but so that's it's out it's empty everything sitting here on my on my laptop and pieces I got work five pins and four or five springs. These are smooth. I'll put it in a microscope here for a second, but with the naked eye, these are very smooth. And these are very, they're not pickpins is what I'm trying to say. These are regular old pins. This lock was quite easy to pick. The key pins are all different lengths as they should be. That'll

match the key. And this lock, the Driver pins are all the same length. Driver pins are not always the same length. Sometimes you'll get driver pins where they appear to be cut. So there's three sets of pins. There's a key pin and the driver pin is cut in half. That's because there's a master key. That's how a master key works. So if you're looking at lockpicking forensics and you see the driver pins cut in pieces into a certain pattern, then you know the pattern of the master key you're looking for. claim there's no master key. They might know there's a master key, but that's one way to prove the existence of the master key. That can be important sometimes. And, oh, look at this. I said no

pick pins, but apparently I was wrong. That's a spool pin. That's a spool pin and the driver pin, so that will lock up every time you try to pick it. That explains why I was having some trouble initially with that lock. And it makes a big difference whether this pin this bullpen is in the front of the lock or the back. Whether or not the lock ticks from front to back or back to front. But why would a lock tick front to back or back to front in the first place? Because every time you see a diagram of a lock, everything lines up perfectly. Let's put this key back in this lock.

See, now it won't have been turned with the key. Oh, there it goes. when you do this too much to do the same lock. So there's what a real lock looks like, not a diagram. The holes are, you can see that very well, but the holes are very messy. The holes in the bottom are much, much bigger than the ones on top, by the way. That's what probably can get their drills and tools in because this is one solid piece. The drill's just all the way up into the housing up there, the upper housing. same holes are drilled through the plug. And this is mass produced. Let's see if I can get this open real quick and we'll take a look at

this one as well since this one has all little pieces. And then we'll, how much time we got left? There's enough time to break out the microscope and

see if I can share that. There's a tool they make to and if I put the key in, life will become a lot easier trying to open this up. Let me see if I can get this open real quick. I think this is worth looking at. Rando, any questions

from the audience?

Okay. So I just...

Okay, good. So I just picked this. So I just took the cotter pin out.

And now I'm just going to pull this. So that's one pin that just came out of my hand. That's one pin that just came out. And like all the others in the lock, it's serrated. Every single pin in this lock has some type of serration to it.

observe it might be saying hey you picked that lock earlier it has all these pick pins in it yeah well it only had one pin so but that's why it was so hard to use the key because i was trying to turn it and i was trying to turn it and put the key in at the same time because the pick pins i had to put the key in straight make sure it was lifted and then turn it even more so with the pin with the lock pick which is why it took a little bit of effort even the one pin lock

ring and here's the driver pin for that same set of key driver pin combination. This one's not focusing, I can tell. That one is completely serrated. It's called a serrated pin for that reason. It's like a whole bunch of spools all together. That makes it very hard to pick. Normally, if there's one, if all like this, like I said, you can just jiggle a lock all the way open. It's like putting all your... It's like putting security appliance after security appliance inside your infrastructure. Eventually, you're going to... It's like Aruba's Cube. You're not going to be able to put everything together properly. You're better off with one really good thing rather than just layering on a bunch of things, hoping things work. But that's a different topic.

So this is what the plug looks like. That was what we saw on the outside. Those are the holes on the inside. I'm trying to zoom in here so you can see how messy they really are. They're not in the line. They're not smooth. They look like they've been mass produced because they have. You see how they're crooked. what makes a lock pickable. If these pins were, if these holes were perfectly aligned down the line on the cylinder, you couldn't pick the lock because there wouldn't be any difference in pressure. It's turning this inner, turning the plug against this with the pins in the way causing different pressures because the alignment that makes a lock pickable, makes all locks pickable. Now you may think the precisely it's machine the

harder it is to pick when actually the opposite is the case the more precisely this machine and the lower the tolerances the more precisely you can feel the mechanism easier it is to pick at least in my at least in my opinion and that this is what the outer cylinder looks like once you once you pull it apart you see the holes that you can see the holes there that we saw before and there's the smaller ones on the inside. I guess you can probably see something there. Again, they're not lined up very well at a detail level. They're not completely round.

That's what makes a lock like this pickable. They're mass-produced. That's basically it.

Let's see if we can get this rolling somehow.

If you do buy a USB camera and wondering how to get the image to come up on your Mac, Photo Booth is the answer to your problems, believe it or not. Can you guys see that? Looks like you can. problems we have a PowerPoint and this thing comes on automatically

fantastic okay good so let's see here let me leave it there for just a second that's the cord by the way you're looking at I want to clear off a space here I have Pete lock pieces all across my laptop trackpad which I don't need the trackpad but I do need the space and then we'll at some of these and see if we can't do the complete the forensic task here saying hey did somebody pick this lock and lord i hope so we can tell that because that's we just i've been picking that lock forever let me put some of the key the pins and stuff back on here

give me 30 seconds rando if you have any drum roll music now would be an appropriate time finally going to see all the pins and stuff we've been talking about. Also take a closer look at the shaft and the key. Okay. I believe. Okay. Good enough for me. Okay. I had something planned where I can have this on a stand. That didn't work out. Give me just a second here to get this thing focused. I want to focus it from a distance first, then we'll work on it and I do apologize for this portion of the focusing okay let's see here I had something earlier that worked

let's focus on that's a spring

That's what one of the pins look like. Let me focus in here real quick.

That's a key pin. Next to it, we have a driver pin.

So let's look at the key pin a little closer to see if we can tell what's been done to it. Before we do that, Rando, I need about 30 seconds to get something to hold this microstroke skill. That kind of missed the plans there. One second.

yesterday and it worked pretty well. I was trying to come up with something better overnight, but you know, life happened. Work, forensics, all that kind of good thing. So let's see here.

solve with Velcro and duct tape.

One more. This microscope has different light modes.

they look nice. They didn't warn you. They're just faking it, especially the blue light. So that's the blue light on the blue cloth. There's the actual light. Okay. Now we can center it on this little unique thing. Now I can do this.

So we should be good to roll.

Good to roll here.

Okay. That's the working end of a key pin. So let me see if I can find a little pointier pointer.

These vertical lines here, those are all from picking the lock. Let's see here. Let me... I'll turn this thing on its end so we can see down the line, but just on the shaft here, see the right here all the damage that picking this lock has been doing because you're testing the lock you're pushing your steel picks against the brass lock those are all signs this lock has been picked and obviously more than once but if you ever see things that are going up the shaft at all on a pin for a lock it's been picked it's been attempted to some degree Looking at a new lock that's been picked once, you're looking for very slight variations.

Hang on. Let me get a different

one there.

the focus that's when we're losing this you

need just to focus and get it back

things get when

the end that pushes the driver pin, the top pin. This is the working end where the key hits the lock. Just took it away. Visually, I can't tell the difference hardly between the two ends. As soon as you put it under the microscope, it becomes very apparent. Because the key is going to do work against the pins as well. You look at Datagram's presentation, it shows you what a pin looks like after it's been used, you know, with a regular key usage after five, 100,000, 5,000 times. And it just gets smoother and smoother over time because key's hitting in the exact same way.

that lock it's focused enough you can see the

the many scratches the many scratches coming up and the effect of the key is those circular ones as the pin rotates as you're putting the key in and out but everything else on that lock on this pin is from the picks let's look at a different one I got one from the six pin lock that I, the five pin lock from before.

And I'm gonna keep it inside. Get rid of this cloth. It's part of the problem is this cloth that obviously isn't very stable. Let me put it inside something else that's a little more stable. I know somebody in the back of their head is thinking, microscope stand and a cane with one and I can't find it. But this should work.

This came off. I can adjust the light a little bit here too.

One second, let me get the focus back, then we'll get the...

The circular ones are the key. Anything that's not circular going around that lock is picking. So

on the top part of the lock, you can see that vertical line. That's a sign that's been picked. Toward the center, there's one that's going pretty much horizontally. the circular stuff, that's also been a sign of picking. On the bottom portion of the lock around 5 o'clock, there's a harsh mark there. That's a pick that was rammed against it probably, trying to figure out which pin was the loosest in the picking process. Even at the 9 o'clock position, you can see a horizontal line going out. A key would never do that. A key... relatively new lock too, which is why those concentric lines, those are machining. That's not all key. Those are machining. The key is

going to smooth those out over time. But you can see how the lock picking goes completely against the machining and the key work.

So that's what a pin looks like that's been picked. And not a whole lot of times. I haven't done a whole lot of picking on this particular lock.

You can see even the mark or two. The driver pins aren't going to have as many marks. Let's look at a... This is obviously a key pin. Even here, on the top of that lock, on the flat part, the cylinder part, not the bevel part, you can see that mark there. That's a sign that that pin was manipulated with a lockpick, but the key would never go into that position. That's what we're looking for in forensics, right? Things that could not happen normally under normal wear and tear. You understand how a lock normally works. You know that mark is basically impossible to do with a key. So somebody's been inside that lock doing something with

something. And earlier I was saying about the serrated part. of the lock. That's the bottom two things down there. And yeah, it looks like a little bullet.

You're going to find also, as you look at these, that the pins closer to the front generally receive more force from the key. So those will be smoother than the ones in the back. So you can almost tell which ones go in the back and which ones go in the front. The one I took out last,

that's what a serratapin looks like. You can imagine as you're picking that with the two cylinders going back and forth how much friction that creates. Or in the case of this lock, too much friction that's constant and you can kind of force the lock open that way.

There's also, I mean, there's more to locks than just this, right?

the key. That one presentation I mentioned earlier by French key, he goes into the key marks and if you can tell if a key has been duplicated, if a key has been impressioned, if a key has been used in a manner than otherwise prescribed basically. That's pretty much what I wanted to share on the lockpicking and forensics. It's basically good forensic practice applied to locks. Knowing how locks work, knowing how lockpicking works is all very valuable. And knowing what is normal and what is not is the most critical part of lockpicking.

So thank you very much.

says share my screen. I'm not even sharing the screen. It's just the video. Okay. That's pretty much what I have to share. Are there any questions?

Okay. I mean, it's pretty simple stuff. I mean, if you want to know what lock's been picked, you look for marks that the key can't make. That's a sign that something happened. Now, what's not clear at this level which pick, which picked, which lock, right? So different picks will leave deposits on those lock microscopically, and those can be analyzed. On a certain pick set, those picks will take parts of the lock with it. So you can analyze the picks also metallurgically to figure out which lock it picked. People have postulated using, have come up with carbon fiber picks, Don't do any damage to the locks when you're picking it for anti-forensics. But it turns out that they

pick up more from the lock you picked rather than leaving it. So you can tell exactly what lock they picked if you had the right tools and instruments and determination. So that's what I wanted to share.

We are here and we are going to be doing Securium pen testing, the great spaghetti monster as I like to call it, or Kubernetes. There's all my contact info. Thanks first to the B-Sides Delaware team for putting this all together so quickly. Don't know how they did it, but it seems to be going quite well. Let's get started. Just a quick who am I? I asked run besides Chicago. We didn't do it this year because it would have been the 10th anniversary and it would have been kind of sucky trying to do the 10th anniversary virtually. There's other info about me. I'm based in beautiful Kirkland. As you can see, if you're looking out, there's the beautiful Pacific Northwest. You

will typically find me sipping Grand Mayan Extra Añejos or Casa Noble. I don't have any today. I'm stuck with a Red Bull. But We will get going. I love dancing flamingos as well as honeypots and refrigerators. And I must introduce you to Sasha, the dancing flamingo, because she helps me with all my troubles. Oh, got her head spinning around. So that is Sasha. You have now met the dancing flamingo that I always talk about. Also, I love to cook. And the only reason I put that up there is Yesterday I got bored and I put this spice rack up in my kitchen. So I thought I'd share a picture of it. Hey, you should all be laughing now. Hopefully you are.

Let's get started with some real stuff. First of all, here's my typical disclaimer. Everyone has these, but the views and opinions here are going to be mine. No past or present employers. And that's the important part. And anything I show you, if you decide to utilize it in ways outside of my control, well, that's up to you. Those of you with an overwhelming fear of the unknown will be happy to learn that there is no hidden message if you read this disclaimer backwards. All right, now to some seriousness. Why are we not here? Well, I'm not going to solve all your Kubernetes security woes. Can't do it. It's not going to happen today. We'll solve some of them, maybe. So let's see how that's going

to happen. Neither will a person, I don't know about sitting next to you, but neither will a person next to you, whether it's on video, there's someone there, who knows. Why? Because it's kind of complex, but something to remember. Common sense went out the window decades ago. Keep that in mind. Why are we here? Well, Kubernetes is still new for the most part. Are everybody using it? No. Are a lot of people moving to it? Yes. It's very fun. It's kind of crazy and fun. Oh, did I say fun twice? I might have. You can't see it and I can't pick it up because the cables aren't long enough. I have a Kubernetes cluster right behind me in little Raspberry Pis. I've got four

of them stacked. We'll talk about that in a little bit. Containers are not new, but the problem is people seem to have forgotten that containers are still very important. Security is for everyone, not just system administrators and security engineers and so on. So we're going to talk about that in detail. And common sense is required, so please disregard the previous slide. All right. First of all, it helps to understand what is a breach. Why? Because I'm going to talk about this as we look at the security of Kubernetes. Most breaches are not zero day. They're not fancy. You don't read about breaches that are caused by somebody getting in, doing something fancy and all of this. It's typically a screw up. Most breaches are are not coming from

vulnerability scanners. What do they come from? Configuration issues. Typically, I've seen this numerous times where people put credentials into configuration files and then put them out on GitHub and then they use that to store their configurations. They launch it and they wonder why whatever they launched got broken into because the credentials were compromised. Also, well,

which come out of the configuration issues. And finally, trailing in a third place are overprivileged users or overprivileged accounts, tokens, etc. We're going to talk about that, how it affects Kubernetes. Why? Because Kubernetes has all three of these things that we have to worry about. Now, think about some of the breaches that have occurred. If you don't know of all the details, go take a look at it. But honestly, it started with compromised credentials, gaining access to an S3 bucket, which had more information in it, which then dumped it out. And it just went on and on. Equifax was broken into via a vulnerability, which should have been patched. But one of the big problems was they couldn't detect, once they got in, lateral

movement. Tesla resources are constantly being hacked. I've worked in environments where we had internal threats, launching all sorts of things. The point is, people are forgetting about the security of the container and the security of Kubernetes. That's what we're going to talk about here. So let's go into containers. We're going to have a quick review. Containers are not secure by default. Everyone wants to say, oh, it's a container. It's that thing that is a container is secure. It must be because it's wrapped in, I don't know, steel or something, but it's not. It's a grouping of stuff, and that stuff are resources. Resources are grouped into what we call namespaces. When you look at a namespace,

it's going to contain processes, networks, users, ports, IPC points. within a namespace can be exploited. CPUs, memory, so on. Think about all of these things. We're going to use a construct known as a C group or a control group, and we're gonna use those to limit the resources. I've had numerous times where I've done a security review for an application at one of my companies or at a company that I've worked at, I would get into the application and then elevate privilege. Why? Because, well, they didn't quite do the security correctly. When I elevate privilege, I'm able to take over the container. And because they didn't have namespace controls or C group controls of CPU and memory, I took over the entire node that the container was

running on. That node could be very, very large, and yet you can take over the entire system. This kind of an image is worth a thousand words here. When you look at a container, think of it this way. Think of a container as a file system snapshot. Who decides what that snapshot is going to contain? Well, you do. Or the developer might. going to be stripped down. You don't need the entire Ubuntu image inside a container with everything in it. I've seen people create a container that actually has Nmap and Netcat installed in the container because that was the image they built it on. And I just kind of scratched my head and went, why are you

doing this? Also, are containers really isolated? Maybe not. And we're going to see that in just a minute. But when you look at the overall picture here, you see your applications. There's your namespaces and your C groups, possibly true rooted, maybe not, depending on how they set it up. You have a Docker registry. A Docker registry is where the container or the image is going to come from. to load your images directly from the internet. You should have your own lockdown and secure Docker registry for all of your images. And in fact, these images should be hardened using CIS benchmarks, something we'll talk about in a second. There is a host OS and there is

hardware. The important part to remember here is this isn't like virtualization. This isn't like running on a hypervisor, meaning which is more secure? Well, let's actually talk about, we'll talk about in just a second. I forgot about my best practices slide. So these are the tips you want to think about for working with containers. I already mentioned your base image. Your base image should be stripped down. It should be hardened using CIS benchmarks. If you don't want what they are, cissecurity.org. You can go there, check it out, get a membership for your company. If you don't already have one, it's going to be, it's going to help you in a lot of ways. Okay. Don't run your containers as root. It

still tends to be happening by people. Also, we need visibility. We need monitoring within the containers. I'm going to talk about that in just a second. Things about the domino effect. What do I mean by that? If one container falls, I guarantee you the rest of them are going to fall within a workspace, okay? We also don't want to allow new privileges. It's very easy to set no elevated privileges or elevated privileges set to be false. So if an account compromised, it won't be able to elevate privileges. This is important. Secrets management. As I mentioned earlier, please don't put credentials in the configuration files. Yesterday, I was going through some old files that I had from

some previous work I had done in another environment, and I found all these examples of programs and these were not things I had done. And in those programs and the configurations, these were YAML files, there were all the credentials. I had AWS tokens, private tokens, I had keys, I had all sorts of things. And the worst part is even though these were three years old, they were still valid. I tested a couple. I didn't notify the people because, well, I believe in that. But honestly, It's still happening. I can't say it enough. And stop allowing SSH. When you build a Kubernetes environment, you have a master node and then you're going to have worker nodes. not allow SSH

into those worker nodes. I still see people allowing that. You get in via SSH, you're underneath the radar of Kubernetes. Kubernetes can't see you if that's happening. So keep that in mind. All right. Namespace limits. I can't say it enough. Look it up. Look up the C groups because you really want to get into locking things down. When you do it, here's an actual very useful tool. It's called Docker Slim. Docker Slim will take your image. Let's say your application runs under Ubuntu. So you're building an application. You've got your Docker registry is configured. You have it somewhat locked down. But when you go to launch the image, it's still, let's say, 300 megabytes.

it through Docker Slim and what you end up with is a base container image that might be 30 meg and will have kind of some security best practices locked into it. By the way, I will make my slides available after the talk so you don't have to memorize all these links that will be in the talks coming up. Also, apply SE Linux and or AppArmor. This should go without saying. It's not difficult. You turn it on. There are some things you have to configure. Docker Slim helps you with that. But so will things like a few of the other tools we're about to talk about, Kube Audit, Kubebench, and so on. And remember, think about it this way. When you're thinking about

containers and Kubernetes, think about it as an infrastructure. Remember your old... golden times, if you will, of working with large, you know, server metal that we're putting an operating system on and we put another application on another operating system. But we lock down the network. We lock down the infrastructure. Each one of the systems and monitoring and so on. Think about these best practices that you used then and put them into practice in both your containers and Kubernetes. So I mentioned I would talk about the difference between a VM versus a container. So here's another picture worth a thousand words here. We see an old environment where we have the hardware, the operating system, and then we have applications running on top

of it. Everybody's used to that. we go into the virtual system, hardware operating system. We have a hypervisor, but that hypervisor is virtualizing hardware. That's the thing you want to think about. So we end up with virtual machines. They're very isolated from the other virtual machines. Why? Because the hypervisor has split up the hardware. And in a way, it's taking care of those C group limits and various other controls. mechanisms that are in there. But when we get to containers, we have the hardware, the operating system, there is a container runtime library, but then we run these containers within the infrastructure of that environment. It's more software virtualization. And if it's software virtualization, yes, you can screw it up. You can

screw up a hypervisor environment too, but it's It's much easier to screw up the security of a container when you're working in a software environment. I do love Kubernetes, but it's also always being updated. Is this a great defense? Well, first we inundate them with quarterly Kubernetes releases. I just got an update this morning of a new Kubernetes release, and there'll be another one coming in about two weeks. Who knows? But that's why you need to keep your environment very flexible because you need to be able to roll your upgrades in. We'll show that in just a second. So here's Kubernetes 101. I can't do all of it because this is only a 45, 50-minute session. So here we go. We have a master node. That node pretty

much manages everything in the environment. It's going to deploy your pods out on the other nodes. EMPLOYS PODs within worker nodes. Now, here's something important, an important concept. A pod is a unit of deployment and addressability. In other words, think of a pod which can have more than one container, but think of a pod as a system, that VM, if you will. Put individual applications within the pods. that can run within that pod, within the environment and be kind of locked down. Think of it like a subnet or a VLAN. You know, you want to be able to group the applications in your pods with security in mind. And This is something that people forget about.

They just kind of start deploying containers and they all go into the same default pod and suddenly one container is compromised and everything gets compromised. So keep that in mind. I almost want to star pods because these are so important when it comes to planning how you're going to lay out your environment. Services are there, a service is a type of proxy in a way. It allows for connections and requests to go within the Kubernetes cluster. And then we kind of have our main components as we see here. We have an API server. Number one thing we want to protect. The next thing we want to protect is the etcd environment. We'll talk about that in a second. And then we

have these things called kubelets and we'll get to that in just a minute. there are two concepts that we want to think about that infrastructure, basic security requirements, where we firewall things, where we isolate them. If the XCD database is the configuration of my entire Kubernetes cluster, doesn't it make sense to lock that down and make sure it's not exposed to the internet, it's not exposed to internal threats and very, very locked down. Yes, it does. So let's look at again, another picture. Here's the Kubernetes architecture in a picture. Here is our API server so we can lock that down. That's within our master node. We have the etcd data if you will, that can also be isolated with firewalling, IP tables, firewall D,

whatever you happen to be using. And then these worker nodes, which contain the kubelets. And here are our pods. And remember, pods control or, sorry, contain multiple containers based on how you lay things out. The only thing that should be isolated deployed or exposed to the Internet are the Kube proxies. The Kube proxies are what are going to expose your application. Everything else should be firewalled off, extremely locked down and monitored for security access. OK, remember, Kubernetes is not perfect. There have been breaches not breaches, there have been incidents. Yes, there have been some breaches and I want to talk about all of those. I give you some links to go and read them on your own. The point here is it's still an application environment that is

designed by humans. We make mistakes. Oh, well, it's something to move on and just keep making sure you get better. Okay. So, um,

Common sense is going to win. We're going to threat model our Kubernetes cluster and our environment. First of all, TLS encryption should be everywhere. If we run, and I didn't have time to put it in here, but I'm going to mention it. If we run something like a service mesh, like Istio or any of the other servers, half a dozen service mesh applications out there, they will make sure that TLS is everywhere. A service mesh, think of it as a proxy that runs in kind of alongside the individual pieces of Kubernetes. So when it makes the connections, it's doing all of the TLS handling, it makes sure that there are access controls involved and so on. I don't have time to

go into that. That would be an entire couple of hours or at least an hour of a session just on service mesh technology. But look into Istio and start there and start understanding how the service mesh works. We want to harden the infrastructure. So many times I've seen Kubernetes deployed out on either Ascent OS, Red Hat, Ubuntu, something like that, and they forget the basics. They don't bother to harden the infrastructure of the operating system that the thing is running on. So people log in to default root accounts because it still has Tor as the password. Think about common hardening of the infrastructure. We need to enable RBAC. I would love to do an entire one hour session on nothing but RBAC. RBAC

with least privilege. We want to disable ABAC. RBAC is exactly what everyone knows it is, role-based access controls. ABAC is based on assets. It's like asset-based access controls. And it can be more secure sometimes, but it is a nightmare to try to maintain. It's a maintenance crate.

that I personally think makes things insecure because you have to spend too much time with it. Also, we need to monitor all of our logs. I give you an example of a tool I love called Wazzah, W-A-Z-U-H. Check it out. But there's a blog out there that they wrote about auditing Kubernetes with Wazzah. Take a look at that, read through it. You can actually implement this in maybe 20 minutes in a Kubernetes environment and you're off and running, okay, it might take you 30 minutes, but they give you all the commands inside of that particular blog. We have kubectl, get role binding, and we do all the namespaces. Every time we deploy a new cluster, we want to make sure that everything is

locked down, all the roles are set, our back is configured properly, and we check all the namespaces. We use a third party for auth. In other words, I love Vault. HashiCorp's Vault is a great tool. There are others, but it's my favorite. Take a look at it. And then I've already mentioned it several times, separate and firewall your XED cluster. That is the guts of the configuration of this system. If that gets compromised, they take over the entire system. Well, they're going to take over the system as well or the cluster. But to me, etcd is usually the one that gets exposed and that's where we have problems. Use se Linux, as I mentioned, or AppArmor. One of those is very easy to configure. There

are some simple defaults. Now let's look at risk. Checking.

Get secrets. That's going to look for any secrets within the namespaces that you have out there. Well, there's a nifty little tool called Kubernetes RBAC audit that was done by CyberArk. It will actually go out and double check all of your RBAC rules, making sure that you don't have anything exposed or too much privilege for particular reasons. service accounts or anything like that. There's another one called KubiScan. KubiScan is a great tool that will also go through and take a look at all of your RBAC settings. So take a look at those. If you're using GitHub or GitLab, oops, go backward. If you're using either GitHub or GitLab, that is incredibly important. I've worked with

developers where they constantly expose code and configuration files that have security keys in those files. You should have something set up so you're monitoring your repos for exposed AWS keys, GCP keys, whatever cloud environment you're running in or even a private environment. Make sure your keys aren't getting exposed. Make sure your images are locked down. Don't forget there are libraries involved. The applications themselves. You still have developers that create an application. It may be that it's going to run in a container, but if they still forget about doing security for that application, In other words, the application is vulnerable to a SQL injection or cross-site scripting or something like that, you still have a security problem.

So keep those applications secure. Also, when you're creating your pods and when you're setting those up, think about what does it make sense to group together in which containers need to talk to other containers and which ones do I want to isolate? Do I maybe want to have a database pod and then have some security within another pod that has the actual applications that then talk to that pod via something like Istio or a service mesh? Also, remember Showdown. If you've never played with Showdown, is a tool that can help you to expose Kubernetes clusters, things like API servers, etcd clusters, and so on by doing searches within Showdown. I'm not going to give you all the commands

here. There are too many, but you can actually go do some Googling and you'll find searches for how can I find API server endpoints? What is this useful for? To verify whether your own Kubernetes clusters are actually exposed. You want to double check that. Now let's talk about the configurations. Remember, I said this at the beginning, most breaches come from config issues. We want to harden our environment. Well, I mentioned CIS, Center for Internet Security, earlier. Here are the links to go and download the Docker benchmarks and the Kubernetes benchmarks. These are common sense steps that take to harden your containers and harden your Kubernetes clusters. The whole point is you get the idea. But how do we test that? How do we actually do an audit? How

do we put in some automation so we're not doing it all by hand? Well, many of us use things like Jenkins. Well, there's a great tool called Anchor. It actually goes out and will scan your container looking for common vulnerabilities. Remember I said the application itself should be checked for common SQL injection and so on. Well, this is a great tool that will actually go through and do it. And it's a plugin for Jenkins. Put this in place in the beginning, they come along, build a new application, it runs through, Anchor goes, blah, blah, SQL injection, buffer overflow, remote code executions, something like that. And it kicks it back out and says, nope, not going to build it, not going to let you through. So these

are things that we can build automation into. Here are some other tools I'm going to show you. I don't have time to show all of them in detail, but it's going to give you an idea of what you can start working with. Kubebench is an excellent tool. tool from Aqua Security. This runs against the CIS benchmarks and it spits out, here's what you did wrong. Here's what you need to fix. Run it against the master and or all of your nodes. It should be run against everything. I've seen people where they only run it against the master node. Incorrect. You need to run it against all the nodes. And there's instructions on how to do that. It gives you a little bit more granularity.

Kubebench is good for presenting to teams saying, hey, you know, here's a quick run. It shows you how, whether CIS benchmarks are followed and so on. Running Kubeaudit is great for your DevOps team or your DevSecOps team in order to fix the things that are within it. Here's an example of what Kubeaudit shows you. There's a lot of information here, but notice like the second one, allow privilege escalation is not set. What that means is by default, privilege escalation is going to be allowed within that container. We don't want that. There's read only root file system is not set, which means the root file system is writable. So if someone gets in, oops. There's a lot of these. AppArmor is

missing. SecComp, which is a security profile, is not set. There's a lot of the allow privileges. Why? Because there's multiple service accounts being used. Run is not root. Oh, my God. This allows... someone to misconfigure something and accidentally launch a container run as root. We don't want to do that. You get the idea. This is a very simple run. It shows it's either an absolute error or it's a warning. You know, there are issues that we have to take care of. This is how easy it is to work with Kubernetes and containers. If you deploy the tools correctly, it can save you a lot of time. CLAR is great. It's a static analysis for the applications within the containers. CLAR

will actually integrate CLAR into your Docker registry. So when it pulls out an image from the registry that you've created, you can set it up with plugins and links so it actually helps you to create a new As the build goes, it looks at the application and the configuration and says, aha, there's a problem, or no, there isn't. Falco is absolutely one of my favorite images or applications. It does behavioral monitoring. It looks for weird things. In other words, suddenly you see a command being run inside of a container that says cat, and cat with a C, I'm cat with a K, so never mind. But cat, it's a password. Why would that be run in a container? Well, Falco

would go, whoa, somebody's doing something. They shouldn't be looking into this. In other words, it figures out what is normal and what is abnormal. Take a look at this tool. KubeHunter, if you're going to do any kind of pen testing of a Kubernetes environment, you'd You need to use KubeHunter. This is a red team tool.

You can run it free on certain Kubernetes clusters within your company, but you only get to run it on a couple. It is worth the money if you want to pay for it, but it is a great tool. So take a look at that one. Now, let's talk about threat vectors. These are an example of a whole bunch of ports run within Kubernetes. Most of them are what you already know about. You see things like 443. Even 8080 is something we've seen a lot. Why? Because it's typically a proxy port. But here, it's the Kube API server. Here, it's the Kube API server, but actually, hopefully encrypted. So these are a lot of ports. 6666. CD. I mean,

this is a good way if you want to run maybe some NMAP scans or do some checking and make sure these ports are not all exposed to the internet within your Kubernetes cluster. It's always a good place to start and to make sure that encryption is running on everything. So IR a hacker, see me hack. Here what I'm going to do if somebody says, please pen test our containers within our Kubernetes environment. First thing I'm going to do, check the access of the API server. Can I get to it? Can I somehow, and here's something that people don't think about. You lock down the API server internally. You have an exposed old-fashioned web server sitting on the outside, sitting on

some old version of either Ubuntu or CentOS or whatever. Somebody breaks into that server, which gets them on the inside of your environment. Now they find a way to attack your API server because it's exposed internally. So keep in mind that that API server needs to be protected from insider threats as well as external. Say, Same thing for etcd. I'm going to be looking for any kind of access to etcd. I'm looking for the kubelet ports. These should be set to read only and the kubaudit will find that. I want to look for container vulnerabilities. Why? Because people put applications into containers that are vulnerable to common attacks. And if I can get into that container

via a vulnerable application, I'm looking for sensitive files and all of these other things. This is why Falco needs to be running within your environment because it detects if somebody gets inside and starts running individual commands. Don't forget about kernel exploits. In other words, I get in and I elevate privilege somehow. Well, that's why the Kubot was calling out that the privilege escalation was not set, meaning it was false by default. And therefore, once I get in, if there is some sort of kernel exploit or any other vulnerability that allows me to escalate privilege, I can take over the entire pod, possibly the entire node. And remember your apps. Always check those. Developers make mistakes.

We wouldn't still be finding SQL injection attacks all over the internet if this wasn't happening. So here is your final threat model. Think of your entire CI CD pipeline. You have a workload. That workload is what we call the pod. Think of your workload security. Group your pods into into a secure environment that makes sense and reduces threat. Think of your container security. Obviously, that's going to be critical. File storage security. In most cases, the storage that you're using within a Kubernetes cluster is ephemeral. It's going to disappear when the container goes away. Therefore, you have developers or the DevOps people that are setting up permanent file storage so containers can store data and when they start up again in another pod, perhaps,

they gain access to the data and they continue where they left off. The problem is people make mistakes and that permanent file storage is actually exposed and therefore the data from the application is exposed. network security, both external and internal. Internal threats are just as much of a problem. In fact, maybe more so because if the bad actors get in in another unsecured server way, then they now become an internal threat. I always like to use Equifax as an example why they got in from the outside, they compromised some credentials, then they just started moving all over the place until they got all the data they wanted and nobody detected the compromised credentials. Problems. Application

security, I've said it enough, make sure your applications are indeed secure. So remember, breaches are not zero day. They're not fancy and you don't find them typically by vulnerability scanners. The breaches are going to come from mistakes that humans make in configuration issues. I'll give you one example of this again. I had an engineer in a previous company where they made a simple mistake. They wanted to share their project with all of the people in the group so they could work on it more readily. And they thought, I'll put it in a GitHub repo. They created the repo and then he uploaded a folder off of his Unix system. The problem is he forgot to

check that in that folder, there were a lot of .files and there was a .gcp file that contained Google Cloud Platform credentials. in the file. It got uploaded to GitHub. Within five minutes of that credential being uploaded to GitHub, the robots found it and immediately saw 49 instances spun up under GCP doing Bitcoin mining in five minutes. long it took. And that was because one, they didn't set the GitHub repo to private for just the team. And two, he made the mistake of, oh, I'll just upload my folder. Well, what's in the folder? All these hidden files that you forgot about that were still there. Things that are common configuration issues. Compromised credentials can't say it enough, but

overprivileged accounts, especially service accounts, and that's why we need to make sure that you can't elevate privilege inside of containers. So make sure you use the tools to audit the containers as well as auditing Kubernetes itself. That's how we secure Kubernetes. That's how we maintain the security of it. And that's how we maintain the security of the containers, which are all part of everything. Here are your key takeaways. Common sense for the win. Remember basic security. Stop overthinking it and stop being fancy. The basics of security are what we still need to go back to. You know, locking things down with firewall and with access controls, with make sure our back rules are set appropriately. Basics are going to be what get us through the

fancy crap. Just I hate it. I'm sorry, but I absolutely hate all the fancy tools that are out there because get me back to the basics. And that's when I get a secure environment. If I follow CIS benchmarks, it is going to give you one of the most secure environments, whether it's the container, the Kubernetes cluster, the operating system, whatever it happens to be. Follow those settings, you're going to have a secure environment. Don't forget there are CIS benchmarks for RBAC, for the infrastructure, for the pods, for the containers, for the network, for everything. We need to secure that environment. That's what we're looking to do. Threat model your environment. When you think about threat modeling, you

take your assets, you take the access methods, and you take the potential attackers. And then you look at how all of that combines. So don't forget, threat modeling, it doesn't have to be rocket science. If you think about it using common sense, you can probably threat model your environment. Don't your access controls. Did I mention RBAC? I think I've said that a few times. I'm going to say it one more time. Don't forget to patch your environment. I still find Kubernetes clusters that are deployed on Ubuntu 14, end of life, hello. Ubuntu 16, about to be end of life. Let's make sure we patch things and or upgrade in an environment so we're not running on old software. Logging,

auditing, monitoring. You can't just deploy this stuff and leave it to not being able to watch it. Remember the tool I mentioned, which is Waza. Take a look at it. It's open source. I think it's one of the best for really getting down to the nitty gritty of monitoring every possible thing you can and weaving out all the noise. That's what we have to do because if you don't weed out the noise, then you're wasting your time trying to work on the environment. So there we go. In a nutshell, in 45 minutes, exactly. That is how you're going to start to secure your Kubernetes environment. And I hope that you all remember that containers are critical. overthinking and securing just

Kubernetes, you need to secure the containers as well. Do the two together, build in a nice service mesh to make sure everything is running encryption around it, and you're going to sleep much better. Thank you all very much. There's my contact info. I will post these slides sometime today. Watch my Twitter account for my GitHub. My GitHub is the same. It's Rainbow Cat. But yeah, I'll post this new one because I made some changes to it. There's an old one out there right now. So watch my Twitter and that's it. Thank you very much. Are there any questions or how do we work this? I don't know how we're working. Okay, cool. I

head over to the track chat. Oh, there it is. Track one chat. I'm in there now. I will hang out in there and answer questions as I can. So I thank you all very much. And once again, thanks to the Besides Delaware team for doing such an amazing job pulling this all together.

Good to be talking to all of you in some weird way that I get no feedback and the usual laughter. So I'll assume you're all finding me amusing or something. This is a talk I've been wanting to give for a while since a lot of my work is now in the help two companies make a merge together, kind of like a version of agar.io that doesn't freeze as much and there's money involved. So this is what I've been doing for the last couple of months. Help if I could twitch through. Okay, who am I? I'm sure you've all seen the slide before. I am now the mergers and acquisition practice lead for my employer, Leviathan Security.

I also do a lot of GRC and strategy work outside of that. I'm also a lawyer. I've got a new disclaimer now. not investment nor tax advice. It's not legal advice. And I don't get to see a lot outside of my bento box. So don't ask me for like, is this a good idea to invest my money? Because I still hold pets.com stock. Still to this day, I mean, because they're eventually going to turn it around. So an overview of why do we have mergers and acquisitions? You're imagine a startup, you're 35 people, you've got a good idea, and it's not as good as you thought it was. Sometimes selling out is better than remaining

independent. You aren't growing, you aren't getting the traction you wanted in the market, or your big new product is just taking longer and costing more money to finally get it ready. you need more runway, you need more money to finally go and take on the market, and you're just not getting it. Your existing investors aren't interested. And from the buyer side, sometimes there are assets within a company that are more valuable not in that company. A customer list, a brand, a code base, a product. of times you'll see these smaller startups where they'll start with like, we're going to go revolutionize this industry and it gets narrower and narrower and narrower until you go, that's a really good

tool for an edge case. And someone who's in the business similar to yours, it's much larger may say, that's a great tool within our suite of products. So you may get an offer from them saying, we would like to buy your company because that tool would be really cool to have. Sometimes it's an acquihire. You a talented team of people that you want to buy. You want to acquire the whole team and say you could do great things. So that's why there's a market. It's not just people going out of business. It might be existing companies that are someone says, hey, you would be more valuable as a part of us. So valuation, this is where you're finally coming to the idea of I would like to

buy your company or we would like to sell our company. value? What's the price? And that's a little bit outside of the work I do since my thin niche of that is basically saying here's where your baby's ugly. Here's where the price is a little too high. I think of myself as like a housing inspector. You may love the house. It's great. It's got great light. It's got great bones, whatever that means. The school district isn't voted most dangerous in the county for five years in a row. My job is to come in and go, well, the foundation's also damaged. Well, you probably want to replace the electrical system because the existing stuff is dangerous. So let's take some

money off the table to remediate those problems. So due diligence. teams come in looking at the deal and say, let's ask questions about the company to find out what the buyer is actually getting. There are financial ones. They're going to go look over the books. There are teams of accountants who are going to make sure that every time you say you've made a sale, you actually made that sale. There'll be people who go over your assets. You have real estate. You have patent rights, you have copyrights. Is that worth what you say it is? Is that worth that much to us? Can you actually say you own that thing? So they crawl over that. And then a part of due diligence

is this undiscovered or undisclosed risks. Are there problems with your company that don't appear on the balance sheet? This is the category of where I live.

Some examples. Litigation risks, right? your product may have infringed on somebody else's patent. Your customers, some of them may love you. Some of them may hate you so much they've sued you. Or you may have done something stupid and thus justified some kind of litigation. Your products actually kill some people. Well, that's bad. More importantly to us in cybersecurity is breach and privacy risks. Is there a, unknown breach risk. Consider when Verizon bought Yahoo and Yahoo failed to disclose some fairly large breaches along the way. Well, that's something nice to know. If you're the buying company to go, I'm getting these things. Am I also getting something that has negative value like an undiscovered breach? Are privacy where there are privacy

risks. Have you gathered too much information unlawfully that is going to make you look like a schmuck a couple of years from now once it gets out, right? Your company has a certain amount of value. If it appears on Krebs, amazingly enough, it's worth less. I wonder why. So product risks. These are the if you're thinking of like a software company, a SaaS company or platform company, you've got the stuff you're buying isn't just the trademark. It's this actual massive code that makes it run. Is that code worse than you expected? Is it is it vulnerable? Is it crufty? Is it a bunch of tech debt in a box that you're going to have to clean up once

you buy it if you want to continue operating stuff? are missing controls in your infrastructure that you're worried about, right? Are there things that you're expected to have that you don't, like a SIM, like maybe vulnerability management? Maybe your infra is not up to snuff. And is it going to be really hard to fix all this stuff, therefore expensive? Therefore, does that take some money off the valuation when you actually go to sign a deal?

debt. I like to think of it as remember that temporary workaround that's eight years old. Now you rely on it. There are people who actually are writing code that uses that because it works better now. That workaround you've clutched in there is now a part of your life. And if you fix anything, you're going to break their stuff. Everyone has deferred maintenance, right? Out of support hardware are operating systems in your production environment. That happens. It's when your entire production infrastructure is running on obsolete operating systems. And when you go, why don't you patch these and bring them up? It's like, well, that breaks the application. Oh, so you've got to rip out a bunch

of stuff. A lot of times I see this where it's not patched, not only because you didn't have the time, it's that you don't even have the orchestration to do it. of clients I've seen where how do you do patches and it's when I have time I run patch I you know I click through software update like no orchestration no push out a patch test run nah if I have time I do it um so I like to think of those guys as we patch once a year whether we need to or not missing parts you know uh I think of a particular client of ours who uh I asked about a SIM, they explained that they had a budget for that SIM. And

that was like, well, when was that? Well, that was two years ago. It's like, well, what happened? And instead they bought something for trade shows. And that is not actually a picture of it. I could not get a picture of it because that would disclose who the client was. But all I can describe it was a large SUV with a bump in stereo. And the return of investment for a bump in stereo on a cool ride, that's instant. The SIM does not pay off as well until you needed it.

So on the buy side, you are the people buying another company. You want to know what you're getting. So you're looking for discounts and deal stoppers. You're just looking for, is there something that we're going to have to fix to make this operational that we take off the sale because we're going to have to use that money to instead fix that problem? Stuff you have to put in place to meet some minimal standards for that industry. Are you going to have to hire people because you don't have anyone doing that work? Do you have to go through your existing code base and refactor it because you're using... longer supported languages, are no longer supported operating systems, or something like that, where you

just have to fix the old stuff. Do you have existing breach or liability offsets that you have to pay for, right? You've got a litigation risk and you know you're going to get sued. Your lawyers say it's going to be between a six and an $8 million payoff. Well, you take that off the sale price. Integration costs. If this is a purchase that you hope to merge with your existing company because you want what they've got, well, if they're a pile of kludge, it's going to be really hard to integrate that with your hopefully better stuff. So that just is a discount, right? You've gone to the car dealership and you've said, I want that car. Kelly Blue Book puts it at $11,000, but I need new tires

and I need this, so I'll pay you $10,000. the deal's still going to happen. You're just paying a little less. Then you've got deal stoppers where the people on the buy side want to say, wait a minute, we need to reconsider even making this transaction. Examples I've seen in this space are code, our core capabilities, they're vaporware. The capabilities that are in your marketing materials don't actually work. No one has ever seen that before in this space. Or you have significant liabilities that you haven't disclosed or haven't even found. So how do we find this stuff? Testing. The number of times we've just sent a couple of pen testers at their info to go find things. What's wrong there? Right? Take the code base and shove

it through some static review tool. Do a pen test from the outside if we've got time. say something nice about a competitor, but NCC Scout Suite is a brilliant tool for finding out what did you do wrong in your cloud infra. And I'm not recommending these as gotchas. I'm recommending if you run a tool against your code base or your public facing infrastructure or your cloud infra, and you're finding repeated problems, that gives us ideas about other things. I like to use is you go to a restaurant and the bathroom's dirty. Well, I can't go into the kitchen, but if I say that you're not keeping the bathroom clean, there probably are bigger problems. And since

I only have a week to look at this stuff, I want to look where I can find dirt and extrapolate that if you didn't fix this and I can find it, there's other stuff hidden. So what else am I doing? team's doing. You're doing documentation reviews. I want to see what your architecture looks like. What's your bug backlog look like? How quickly do you clear it? How quickly do you identify problems? Right? If you've got a small backlog, but we found bugs means that your ability to find stuff is broken or lacking. And I would like to question why. Look at existing incidents. Did you learn anything from that past incident? Right? You got popped three years ago. Did you learn from that? Did you update your incident

response? You put some defenses in place. What are you doing? And that gets us a holistic idea of what you are as a company. And then the final bit is we play being the Bobs from Office Space. I talk to your infra people. I talk to your devs. I talk to your compliance people. I talk to your salespeople. about your market, I learn about how you produce the goods and services, I learn how you do things. And I find out if you have the ability to find new risks in your environment. Maybe you don't.

And I get a sense of also your management team. Do these people know what they're doing? And sometimes those are recommendations back to the buyers to say, when we're done, this is what you're gonna get. If that's still something you're interested in,

We're signing off on what we found. This is what it's going to cost to fix. And we have some impressions. So what do we find? If the target company is as mature and well together as we'd expect, nobody's close to perfect and that's OK. I don't expect to find really, really mature aspects in a 50 person company that's three years old. There are going to things you're missing. That's expected. I might still recommend that they fix that and that offsets your cost, but I'm not horrified. If you're a 5,000 person shop in a regulated environment and you're missing core things, that's another category. But I'm really curious about, does this make sense? Did you know what you were doing? If there's a problem, sometimes I've walked into

places and I see things you should have aren't that makes us dig further because why didn't you think of doing that where's why don't why don't you have a sim why can't you do alerting sometimes i've seen tons of tech debt there is nothing like finding out your core application runs in cold fusion and i think wow you know you you'd hire more devs but they're all dead um potential breaches is there something that says so incapable of finding an event that someone could have popped you, taken what they wanted, and left and just gone, right? Are they still there? But you have no ability to detect it unless something goes down or until Visa calls you up and says, we're seeing a lot of

fraud by people who used your store. there's really big problems that that want us to make you question the deal entirely you know the that you only move the headstones you didn't move the bodies

so arguing over findings that's the next step once we find everything we want to go and identify to to write them up in a coherent

and go back to everyone involved and say, this is what we found. This is what we think you should do. This is what it's going to cost to fix. Handle appropriately, right? How much is it going to cost to fix? What's the impact if you don't? How would we order them? How would we prioritize these things? Because we know that you're probably not going to immediately fix everything. You're going to fix what you have to do and continue on in the business. Discussing with the deal team, right? to answer questions so they understand what it is is wrong with the company we're buying or they're buying really. And then post-sale, usually afterwards the purchase occurs and the new acquisition is saying,

how do we fix the problems you identified? And we'll try to give them some useful advice and keep on going. So I realized that none of this ever makes sense unless you do it as hypotheticals. We have a client, the target is an online lifestyle fashion seller. So they sell jewelry, accessories, clothing, high-end, hippie-esque, expensive. They've got a very strong social media presence. They're on the gram, they've got influencers, lots of really lush pictures of people enjoying themselves outside, very political, social bent. They're pushing a lifestyle. Good for them. They've got a very premium sales model, high touch, high margin. They know your name when you call. They would really like you to remain a customer of theirs. That's the company.

We go and take a look at them and their sales organization's great. Infra is a mess. It's amateur hour. They're doing everything wrong with PCI. Everything's in one database that's world accessible, or at least not all the rules you're expecting to see out of the PCI SACD. They're holding credit card numbers in plain text, like all the things that make everyone in our industry cringe. there is what I like to think of as a high delta between the truth and reality here. They're doing a lot of things wrong, but all the documentation they're kicking to their credit card processors is everything's fine, please go away. So what do we do? What could they have done better before we showed up? Because we took a fair

amount of money off the table for that sale. look around, do a pre-audit audit, hire somebody, bring somebody in who isn't you just to say, what would you fix here? That's usually a cheap consulting engagement, less than $10,000.

If you have documentation you needed, do it now before you're really in the market, because there's nothing like seeing documentation that was done literally the night before. knows that the time to do homework is on the bus on the way to school, not here. Do the cheap stuff. Run your patch. Just make sure your systems are up to date. Make sure basic scans are fine stuff. Run Nmap against your external network.

Stuff your code through a static analyzer and fix something. everything we can ding you on is price taken off and we're going to bump up that cost because we're trying to find as much money to take off the table to justify our existence. Show improvement, show that you as an organization can find and fix your own things and that it doesn't take the fear of an audit or an assessment or a due diligence to force you to clean these things up. Right? So in a backlog and then show that you're cleaning up the backlog. Make it seem like you're more of an adult than you actually are. So second hypothetical is an actual deal stopper. Target companies and advertising technology.

They're a small Eastern European shop that does some kind of, we do better big data against against the cookies we've sucked off of your browser, some magic, some hand-waving. But they claim that they can more effectively go from view to add to purchase than anyone else can. The buyer is very interested in this capability. in marketing since direct mail. They're still in direct mail, but they also have an effect of online. They've already got a bunch of data scientists doing this work, but they really like this little company's technology. Most of their clients are in the EU or Japan or Canada where we actually care about privacy. So that's for the asterisk around their concerns. Is this other little company doing anything that's

scary? And well, yes, every question we give them means more questions. They're based in Eastern Europe, but their internal policies are all in English, which is a clear red flag. Like no one puts your internal notes in a language you don't speak. Nothing they describe actually happens. They handed us a hardening guidelines for windows as they're hardening, hardening proof that they harden systems. And we and they had no Windows systems. So you have documentation that has nothing to do with you. It's like if you went through for, I need proof that you own things and you went through all the old manuals in the back of your filing cabinet for like old pieces of technology that you bought, you've not thrown away and handed it to people like,

huh, I didn't realize you still had this stove. Oh, that's two stoves ago. So it's everything about them felt wrong. And then we asked some more questions and find out that they're storing everything they get. They are violating GDPR, they're violating Canadian Privacy Act.

This is a risk back to our buyer. And we realized like, look, if you buy them under the GDPR,

It's now 2% of your revenue, not theirs. So you have a problem. And we then talking to them when they said, well, we're really not interested in their existing customers. What we are interested in is just this technology. And we came up with an idea of like, don't buy them. Just license the technology. Buy the license to the stuff that they're doing. Hire some devs away and make it very clear that you're doing that so you're paying that company enough money that they don't come around and and do anything about it and that way you get what you actually wanted out of this you didn't want the company you wanted the magic so they got that and we were able to help that client not have to take

on all this tech debt because these guys are doing everything wrong but this like algorithm this big data magic they had was actually valuable to them. That's all they wanted. So that's what I got. Any questions?

Well, I'll just drop off and oh. Oh.

Sure. So.

I'll answer the second one first, which is PumpCon isn't finally canceled just this year because God knows PumpCon isn't PumpCon unless it smells that way.

And now everyone's. Yeah. So, Brendan, no, most of the time, if you've gone through that much bother, they stick around. It's just discounting off the price because you've already then decided you're that interested. For anybody who didn't see that since that question came from our Zoom chat that we had to use, he asked, do buyers walk away routinely or do they just discount the acquisition cost in a case of true Delta? In case anybody was wondering what that was.

Anybody else? All right. Very good. Thank you, Alex. Thanks so much, everybody.

forever.

I wake up when I die and it is too late to climb any mountains.

and I hope you're having a great B-Sides Delaware. I know a number of people who are really getting sick and tired of virtual conferences, but it enables this, right? I get to present to you guys from my home here on a Friday afternoon, Friday evening, I guess. So why are you here and who am I? We'll just get right on into it. Hi, I'm Nate. I am the founder of the IronSysAdmin podcast and a set channel that we'll get into later that sort of started around the same time. I'm a technical account manager at Red Hat, and I've got like 20-something years, 22, I think, years in IT, and that doesn't even account the time

when it was a hobby before I actually got into the industry. I've got a couple certifications, mainly from Red Hat since I worked there, RHCE, RHCSA, and I'm one of the admins and founders of the DEF CON 610 group here in Eastern, well, in Easton, Pennsylvania. If you ever need anything to do on the first Wednesday of your month, you should check out DEF CON 610. We're meeting virtually now, of course, but once we get back to in person, it is a great time. So you're not here to find out who I am. You're here to learn how to start a podcast and a little bit of qualification as to why I'm here to tell

you that. We've been on the Iron System in podcast for about four years now. In fact, we just celebrated four years last night on 91st episode. It was a little bit of a bumpy road to get the show started four years ago, and I thought it was a little less intuitive than you might think. Things have changed now. If you're feeling a bit of deja vu and you're a B-Sides regular, you might know I've done this talk before here, but things have changed enough that I thought it was worth doing again. So again, Iron Sissamine Podcast, and I also run a YouTube channel for Another hobby, which is jeeping. I build stuff for jeeps, I

modify jeeps, I off-road, it's fun stuff. And I recommend it to anyone who wants to get away from the keyboard now and now and again. But the reason I included in this is because running a YouTube channel is very similar to running a podcast, but there are some differences between video and not video, streaming versus recorded content and whatnot. So here it is. what I intend to cover today. Basically some background on what you're going to want to figure out before you start recording your show, how to start recording your show without spending a whole bunch of money, how to host your show. And I don't mean host like be speaking to you host. I mean like hosting. How do

you make your show available to people? And then of course iterating and improving, right? So you're going to start at level and then as you identify things that need improvement, you know, how to go ahead and move forward with that. And then of course improving hosting could come and how do you make money doing this stuff and a few other miscellaneous things that I throw in at the end. Just, you know, basic stuff that could be useful for you in your new podcasting career, right? So where do we start? First thing you need to do is obviously pick a completely unique topic that one's ever done a show on before. Of course, I'm lying. That's not what I mean. You need to, it doesn't matter so much if no

one's ever done a show like yours before, or at least on the same topic as what you're intending to do your show on. When we started IronSysAdmin, I started it because I thought there were not a lot of ops-focused systems administration podcasts. There were a lot in the security world. There in IT, but not quite ops focused, like tech style podcasts. And I thought we were filling a void that, that didn't have a lot of shows in it. Uh, there were one or two others at the same time, but there just weren't a lot of them. Um, but you don't have to do it that way. You can certainly start a show on something that

a hundred other people have done, have done the same topic. Uh, but just bring your own flair to it, bring you to it. Nobody is you. You've probably heard that before. If you've ever looked at anything, you know, about content creation, uh, your personality and your viewpoint on things is what makes it your show, right? So that's what you bring to a space that may already be crowded with other podcasts.

You need to figure out what sort of format you want your show to follow, right? And by format, I mean, do you want to run an interview show? Do you want to run a commentary show? Do you want to run a live stream? Do you want to run just pretty much, there's a d