Skip to content

VIDEO

Hack to the Future: Going Back to Basics

Series: On-Demand Webinars & Highlights

Category: Pentesting, Red Teaming, Thought Leadership

   BACK TO VIDEOS

Transcript

Hello and welcome to today’s remote session. This is Tom Beckhold, your host, of course, for today’s program with secure World Digital. I want to say thank you to the folks over at PlexTrac for making today’s talk possible. We’re talking about hack to the future, going back to the basics. So, of course, I’m sitting here thinking about Marty McFly and the doc and all that kind of good stuff, and I’m like, what are we going to get into today? Right? So obviously I met with Nick before we did all this stuff and I got kind of the cheat sheet, if you will, rattle around up in there. But I wanted to just kind of just talk briefly. Hackers are out there doing their thing, right? Not all of them are bad people, as I’ve come to learn.

Case in point, our guest today, he’s actually a hacker, but he’s actually one of the good ones. He’s actually tearing stuff apart to make it better for us. So I appreciate those kinds of hackers, but no, the ones that I’m talking about, they’re wearing the hoodies and their mom’s basement, drinking Mountain Dew and all that kind of stuff. The myth that we have for hackers or whatever, they’re out there doing bad stuff and we’ve got to get our arms around this. I say this all the time. We’ve got to create more awareness amongst each other and start sharing a lot of this information because collaboration to me, I feel is going to be the closest thing to a silver bullet that we’re ever going to really get. So sharing information and collaborating on these topics, I think that’s the way we need to do it.

And I really appreciate everybody taking their time to come today. We’re going to address the audience a few different times probably, so if there’s stuff that you guys want to know, let us know. Throw it in the Q and A. Nick. I’ve talked to Nick about it, too. He may ask you questions, so put something in the Q and A. Please respond if he’s asking questions because we want to make this as interactive as possible and not just rely on poll questions and stuff, because those are fine, but sometimes it’s nice to just get a quick answer.

So let’s try that anyway. The Q and A thing there, down there, you can type in there anytime you want, and it mainly is just for the presenters and you and I to see. So it’s not like a group chat, so don’t feel like you have a silly question that everybody’s going to see in my videos. It’s fine. That being said, who are we talking to today? Right? So it is Nick Popovich and he is the hacker in residence over at PlexTrac. And what does that really mean? Nick’s passion, like I said, is learning and exploring new technology ecosystems and trying to find ways to utilize the systems in an unexpected way, he’s basically focused a lot of his career on adversarial threat simulation, offensive and defensive security, and advanced technical security assessment. So he’s pen tested stuff physically and on the networks and things, so he knows what he’s talking about when it’s coming from the hacking perspective.

Right. So just want to kind of set the stage there. But before I let Nick go, I’ve got to just kind of call us all off real quick here. We got a housekeeping slide I totally forgot. So if you’re new to the program, we’ve got URLs, the slides that we’re going through today. Some great stuff actually, from the folks of our clicks track in there from the resource tab. Go ahead and check those out.

Some links in there to take you off to download some other stuff, but like I said, questions. Throw those in the Q and A for us. You will get a certificate of attendance for CPE credit after about 50 minutes. It’s a pop up. It’s down there on that menu bar down at the bottom of the screen, but you’ll be able to access that if you forget, you’ll get an email later today. That actually is proof as well. But I know a lot of folks like to have the CPE certificate.

It is being recorded. So if you see this, and like I said, collaboration is kind of key, share this. If you like what you heard, share it with a colleague. You can use that same link that you use to join us today. Share that with a colleague. They have to register, but it’s good information. So that being said, nick Hopovic, how are you? I’m tired of talking.

How’s your day? Good day, yeah. Thanks for the kind intro. I’m excited to get an opportunity to introduce folks within this forum to some of the thoughts that I have. And I definitely want this to be a scenario where I’m not just jammer and on it folks, if there are thoughts or ideas you have, I might drop questions or if you want me to expand on some topics, let’s do that. So I am the hacker in residence and the intro was pretty stellar. I don’t have too much to add. I’ll put a little bit of pepper and salt in there to give it some seasoning.

Basically, with Plex Trek, I’m supposed to provide the hackers mindset, the hacker’s view, because when it comes down to it, there are folks that can read about it. And it’s important to get theory, which we’re going to talk about kind of the foundations and basics and how you evolve to go forward by somewhat taking a step back and taking a look back. But that hackers perspective, I bring that in every facet of my personal and professional life. It’s what I’ve been doing since about 2009 as a professional penetration tester and hacker, I did spend a number of years on an Enterprise Red Team Fortune 200 and moved in various roles, consultative and leadership. All that to come in to say that I want to put that hacker perspective first when framing up conversations about various topics. And so what are the topics we’re going to be talking about today? And what is Hack to the Future going back to the Basics all about? We’re going to be talking about how to efficiently and effectively transition thoughts and ideas into actionable steps that can help elevate either your internal practice for security assessment and testing endeavors or your internal security team or even a consultative team to more accurately and effectively be able to perform offensive security assessment and testing services. What do I mean by that? This really is focused on penetration testing, red teaming, security assessment, vulnerability assessment, those types of deals.

But it’s not just from that perspective of a provider of those services. And when I say provider, I mean whether it’s a consultative or service provider giving those offering those services or it’s an internal team that business units within the organization are receiving those tests and the output of assessment activity, maybe it’s collaborative purple teaming between Threat Hunters and Blue Teamers and Red Teamers all coming together because collaboration really is the key. So we’re going to talk about this collaboration and how to evolve and move into more advanced assessment and testing paradigms. We have kind of tiered approaches. I think the industry, some folks have different names and terminology for different types of assessment. But I think a good number of folks have a very similar set of ideas when it comes to the types of tests, the goals and outcomes of those tests. And then once you master, so to speak, those types of assessments and perhaps your organization is able to deal with the data provided by those assessments, you’re ready to, excuse me, begin engaging in more advanced assessment.

And whether you’re the one providing it or the one trying to receive or consume these advanced assessments, talk about how to more expertly align those. And then from a collaborative and consultative standpoint. And again, when I say consultative, even internal teams, especially internal teams, are acting as consultative resources many times to other business units. So when I say consultative, it’s not just talking to consultancies, it’s talking to human beings that are in the cybersecurity or information security realm that need to articulate and provide services and articulate risk to others in the business. Everybody ends up being a consultant at one point or the other. So let’s start talking about going back to the Basics. I think if you spend time researching or reading on blogs and different feeds, you’ll end up finding maybe LinkedIn, maybe somewhere where you get your information.

You’re going to end up finding this topic and it just won’t go away. And I think some folks may roll their eyes and say another back to the basics. But I think it’s still relevant because so often when we look out at the landscape of technology ecosystems and all the interconnections that those have, folks tend to get distracted easily. They get distracted by new blinky boxes, they get distracted by development strategies and new technologies offered in new data centers. And is it my data center or is it your data center? The cloud, the not the up, the down. I think when we start talking about distraction, then at the micro level, not at a macro level, but at a micro level, when we’re talking about providing security assessment and testing services, folks can become distracted by the latest and greatest trends in emerging threats and zero days. And there’s a lot of value in understanding the risks that they present.

Don’t hear me wrong, don’t say that you need to put your head in the sand and just focus on making sure that your users have a good password and thumbs up. Everything’s going to be good. You need to have balance in all things. Balance. Just because I’m wearing a purple shirt doesn’t mean I support thanos. But the concept of balance is sound in that if you spend too much of your time focusing on the newest and the most bleeding edge, you’re going to fall down, especially in security assessment and testing, in penetration testing, in offensive security endeavors.

So when I talk about this formula that I have on the slide here, taking the experience, combining it with the people that you have or that you will have by hiring initiatives and ensuring they’re supported by the right tooling, by the right technology, stack really becomes this recipe for success when it comes to offensive security. Testing and thinking through experience is something that becomes difficult to manufacture, but I don’t think it’s impossible. Again, if you start researching or reading a lot of blogs or LinkedIn articles or Medium articles or whatever the case may be, you’ll end up finding people with very opinionated stances. Some who are very frustrated by the gatekeepers, they see them as gatekeepers. These are at times up and coming folks who are maybe newer to the industry. Either they’re newer chronologically or they’ve been in other industries and they’re focusing on moving into a more cyber security information, security centric role. And they feel like they’re being gatekeeped because they may not have an array of experience that some of the folks that their audience or that are responding to them, that they’re interacting with has.

And they’re saying, look, I am a sharp person. I have skills and I have perspective that I can add to these conversations.

Maybe I didn’t spend ten years as a software engineer. Maybe I didn’t spend ten years as a systems administrator or setting up Active Directory environments and migrating people to the cloud. I haven’t been a developer for this amount of time, and I’m coming into the security industry and I don’t have a lot of these skill sets that some folks demand that if you don’t write your own sauce, then your soup has got to get thrown out. So that’s one view is that folks are being gay kept. The other view is kind of the opposite of that. It’s that folks who are coming in and transitioning careers and are trying to get into a cyber security centric role, especially in an offensive security role, where they’re going to be performing penetration tests, adversary emulation, red teaming activity.

If there is not this deep depth of 15 years of experience as a sysadmin or developer, that they’re just useless and there’s no place for them. And the reality is there is no room, I think, to have this polarization.

Those who have vast amounts of experience, the onus is on them to facilitate what I like to call manufacturing comprehension. And so how do you do that? There’s a number of ways that you can do that. And I think finding what works for individuals is the key. So maybe for some it’s structured training and schooling. Maybe there is an opportunity and you learn foundational concepts of theory from academia and maybe some structured training or boot camp style that has maybe some practical application scenarios involved. The idea. Then there is you’re taking that experience and you’re trying to distill it down and you’re trying to deliver it in a way that makes sense for some folks.

Maybe they take those and they augment ad or don’t do those and they go in and it’s very experiential. They go through setting up their own labs, they go through blogs.

How does this work, how does this happen? You take a technology and you start experimenting with it, learning it, and then folks can create this marriage between those concepts. You get some theoretical foundation understanding. Maybe it’s reading, maybe it’s training, maybe it’s on the job training, and then you work through that, by working through that. The hands on imperative, that’s something that maybe you google the hackers ethos and hands on imperative. Learning about theory is valuable so that you have an understanding of the common body of knowledge and some of the terminology. But really there’s not too much that can take the place of experientially, putting your hands on and working towards a goal. But I think that we don’t have to have either or we can work so that folks can take advantage of those that have the experience to be able to facilitate introducing these concepts to folks who are transitioning into this field.

And so one of the reasons why this really comes to light and is thrown into something of a sharp relief in offensive security testing is that there’s so much to be done, there’s so much to be done, there’s so much to assess in the landscape, identify threats, identify flaws. There’s a lot of responsibility on those assessors. On Pen testers and Red teamers and risk assessors. And folks who are running scans and audits. Et cetera. Because if we’re not doing our jobs appropriately. If we’re not finding the right coverage in the balance of identifying the different assets and probing and responding and getting the data that we need.

If we’re not doing that efficiently and well. Organizations that are under our purview can get breached. And now they may still get breached. Because when you’re doing snapshot in time assessments or you’re doing your best not to say that the perfect pen test is going to cause you not to be breached, don’t hear me wrong. But the idea behind it would be ensuring that there’s this minimum set of coverage and ensuring that you identify all the flaws that you need to be able to give a general assurance that their risk posture equals X, Y, or Z. In offensive security, what you end up running into is there’s a lot of people who are engaged in this, who have entered in and they have a lot of experience in using perhaps automation and tooling. And now, don’t hear me wrong, I am not one that is anti tool.

I am not anti autumn. I’m not the type that says you got to sit there and form the IP packet and mail it in the letter and get it there by a carrier pigeon. Don’t hear me wrong. I am not anti tool. I’m not anti automation. I’m not about reinventing the wheel and saying, if you don’t know how to write your own tools, then you’re not the right type of assessor. What I’m saying is that there’s this introduction to concepts that then is facilitated by tooling, but the underlying concept isn’t mastered to the point of even, at least comprehending what it is you’re trying to do.

So that when you run tools, the ability to troubleshoot when it doesn’t work right, interpret the results appropriately, and also work through odd scenarios, you’re at a disadvantage because you don’t have this foundational experience that goes back to going back to the basics. So how can you progress and evolve if you’re treading water just getting things done without the core understanding that can allow you to progress? That’s why to evolve and move forward at times, we have to make sure that our foundation is well established. And I’m going to give some examples of that in a minute. And then shortly after I give some practical examples, I may broach the subject to you folks. What have you seen that have had success in your experiences? So examples of this might be if we think about, like, Miter attack framework, we have the TTPs, we think about what they represent.

How you do something would be considered like a tool, right? How you execute something is going to change. There’s going to be a new tool. There’s going to be a new technique, a new command, a new thing that you do. So the how can constantly be changing.

The what you’re doing is something that you need to be familiar with. What’s the outcome? What is it that you are actually trying to do? Are you trying to inspect a protocol to get information? Are you trying to query a service? What is it that you’re actually doing when you’re doing something? How is going to change every month, every week, the how you do something may change the what you’re doing. That’s where we need to focus on manufacturing comprehension and understanding what it is we’re actually trying to achieve. And then the why that is something that really the why and the what are things that we need to really be able to articulate? Well, when we’re engaging in this activity, especially we’re trying to hack things. We’re trying to hack web apps, hack networks, hack people with social engineering. How you do it is always going to evolve. But what and why? And so the why would be what are you trying to specifically get? Is it gathering information? Is it finding vulnerabilities? So tying those together when you come in and you’re utilizing a scanning tool or automation or even commands that you read and understood from a blog, if there’s not an understanding of the why, the what and the how, specifically the what and the why, you’re going to be at something of a disadvantage.

And it’s difficult to then graduate to newer techniques or to identify laws that could be more exotic or esoteric when the basics of what you’re working with you don’t have the right foundation so that you can’t troubleshoot. Because I’ll be in my opinion, it would be interesting to know if folks feel the same way. Just something as simple as network discovery, using tools like Nmap that is an art and a science. Every different network responds differently and there’s a lot of different nuances that is simply running a tool and a command against a network and you rely on that output just as is without inspecting the data. Without watching it in wireshark or TCP dump. Without seeing how the network responds to you. Getting a feel for the pulse of the network.

Just blindly copying a network Discovery command that you’ve always used and using that cart blanche across every single environment that’s going to yield results that are suspect.

Some people say, what are you expecting me to go through? And have a deep understanding of the TCP IP stack and how these protocols work. I feel like that there’s value in that. And before I move on, let me also say don’t be overwhelmed, especially if this is the genesis of your journey. You’re transitioning into a security centric role or your first job is coming up and it’s cyber security centric. I think there’s a point where folks just get really down and they say to themselves, there is no possible way I’ll ever be able to garner all this information and consume it and understand it. There’s just too much to learn. I hear it time and again.

I used to teach adjunct to the university and I had the opportunity when I was a practice director to have a lot of folks who are up and coming and the overwhelming nature of all the different techniques and hacks and technologies that are out there. You’re supposed to be an expert in all these technologies and how to hack them. It can be overwhelming. Let me just reassure you that the concept of the right foundation and going back to the basics will actually aid you in that. And what I mean by that is if you go and look at the core foundational technologies in use and some of those, I can’t list them all, there could be debate and what’s a core technology? But my point being, if you go and understand the intricacies, general intricacies of how different operating systems work and how databases work and how client server work, TCP IP, and how applications work, once you start to get the general gist of those core technologies, then it’s just an overlay of the latest and greatest. You take on memory management, or the latest and greatest way to thread and the new language and the new tech stack, those type of things. But you get to this point where you reach technology zen, I didn’t coin that term, I don’t know who did.

A buddy of mine told me, I don’t know if he coined it or not. But the idea is that once you have been hacking and cracking in technology landscape long enough, the new technology is going to be front and center. But it’s going to be so reminiscent of tech stack that you’ve observed before, programming languages, scripting languages and memory management, how things work. That foundational understanding allows you to rapidly consume new tech stacks so that do you have to be an expert in everything? No. But there comes a point where you become so accustomed to rapidly spinning up on tech stacks that you recognize from your earlier deep dive into the foundational aspects of technology that you can then more rapidly deal with this new tech stack. So here’s an example of exercises that I think are super valuable and I guess I won’t pause, but I’ll put the question out there what are folks’s thoughts on the idea of maybe some challenges that you or your organization has faced with security assessment and testing? And folks may be providing results that you thought were suspect or you felt like you weren’t driving the most value from maybe some anecdotal experience or what are your thoughts. Maybe not waxing on anecdotal experiences.

But what are some of the big things that when you’ve received assessment and testing either internally or from assessors that you’ve noticed that have caused you heartache. Maybe bring some of those concepts up and we can talk through how going back to the foundations may assuage those. Yes, throw those in the Q and A box there and we’d love to hear from you and we’ll chat about those in just a minute. Nick, I’ve actually got a question for you. You’re throwing around lots of terms and stuff and I’m not really a security guy per se, but could you just kind of unpack really quick while we’re waiting for some of those responses? Is this kind of a well, I’m going to back up, explain to me the difference between a risk assessment and pen testing. Sure, that’s close together to me. Yeah, that’s great.

There is a dichotomy there. There’s complementary aspects and then there’s areas that set them apart. So a lot of times when you talk about a penetration test that may take the results from a risk assessment or a vulnerability assessment, which are also two separate endeavors at times, and I will caveat this with this is my perspective. Some folks have different nomenclature and terminology, but generally speaking, a risk assessment is going to have a formulaic approach to come in and then quantify and qualify, but quantify the level of risk that something may entertain. And so a risk assessment may come in and say, based on the available tax surface that’s suspected, based on the criticality of the data and based on the position and what we understand about the system, this asset presents a high, medium or low risk. There’s usually scales measuring scale presenting risk and it’s usually trying to take a formulaic approach to contextualize and put into a framework the risk presented in a formulaic approach. So a penetration test can validate those assumptions.

They can come in. Penetration testing can also be that practical assessment and testing where risk assessment is somewhat, I’ll say, theoretical based on we have these controls, we assess based on this data and the information available at the time, maybe a risk assessment goes into saying, do you have a firewall, yes or no? And maybe a cursory look at the configuration and is it protecting these assets, yes or no? And these assets have critical data, but because they’re firewalled and segmented, we’re going to call this a medium, these assets are at a moderate risk because our risk assessment says these things. Then during a penetration test, the assumptions from that risk assessment may have to be adjusted because the penetration test demonstrates there are gaps in the firewall policy, it wasn’t applied as expected. And the penetration test is actively taking advantage of flaws, realizing the flaw as an attacker would in an attempt to demonstrate gaining unauthorized access to the systems or data, those types of things. So while a vulnerability assessment and or a risk assessment are identifying flaws and trying to quantitatively put risk ratings on them, a penetration test will further validate that and then also demonstrate impact. That can then be used in further risk assessment metrics. Because if during a penetration test I am able to take advantage of a certain network segment, so to speak, and pivot into other segments and demonstrate that I can access certain amounts of sensitive data.

Now the risk assessment can be data informed from practical assessment and testing activity that can better inform a risk assessment. So there’s a lot of harmony, there’s a lot of symbiosis between the different types of assessments. Many times one assessment strengthens or derives data from another to give that holistic picture of the genuine risk in an environment. Okay, I appreciate that. Thank you. That makes a lot more sense though. Awesome.

Let’s see one more. How often should you do these risk assessments? I think probably more often. But an actual full on Pen test, how often would you do that? That’s actually an area that’s up for debate. That’s a good question. There are moving in as automation and folks have gotten their workflows more tied up. There’s this idea of continuous assessment and testing. There’s this idea of attack surface identification and continuous assessment and testing.

So it’s kind of always on service oriented approach that monitors changes environment, is constantly trying to poke and prod. There’s also something to be said for the manual effort involved in either a snapshot in time or project based programmatic penetration test that’s not only leveraging automation, which I think is valuable, but I think from a penetration testing perspective, having an operator, a human who can contextualize, adapt, improvise and put that hacker mindset behind it, there’s value in it. And really that comes down to organizational needs, goals and desires. I know some organizations that will do a full manual pen test of applications. On every application major release. They have the budget and the time for an internal pen test team. Perhaps they do that or they enlist the services from a service provider.

A very common scenario because I believe it’s driven by maybe some compliance initiatives, perhaps PCI, but there are common quarterly scans and annual or biannual penetration tests. I think it ends up coming down to risk appetite for a penetration test because penetration testing in and of itself can introduce risk into your environment in that you want to test systems that maybe are development, but you also want to see how your live production systems operate. At times those can maybe undergo adverse impact from the test. So the risk appetite, the budget, I would say budget probably drives a lot of the questions of frequency of assessment and testing activity because depending on the provider, depending on the scope, perhaps you have a large network that you assess once a year and then subsets of that network or branch locations or business units are assessed at varying times and they’re staggered and stacked. I don’t think that there’s a right answer. I think it comes down to what’s your current threat landscape, what’s your risk appetite and how often do you want assessment and testing and how often can you afford it ends up becoming parts of the equipment and that’s why some teams end up deciding to try. And hire an internal team and then they still, while relying on that internal team to provide assessment and testing, there will be maybe third parties coming, get that fresh eye, get fresh view, see what folks who are too close to the environment maybe have missed.

Appreciate it. Thank you. We got some feedback from our audience members. Now. Todd was saying one never ending issue is when remediation isn’t prioritized or is totally ignored following a pen test. Man, fantastic point on that. It’s funny, that’s actually one of the reasons I got involved with PlexTrac.

The idea of being able to take the results of a penetration test or a security assessment. If those results just sit on a desk or those results just end up in a share and it’s a thumbs up and then those results are distilled down to a paragraph and a graph that goes up against a board meeting, but there’s nothing active upon it. That is, to me, bananas. It’s a waste of money, it’s a waste of resources. And you’re not doing what we as a security industry are meant to do. And that’s raised the security posture of organizations under our purview, whether we work there or they’ve enlisted our services. The end result is not that you can do some collapse.

That’s the fun part. But the reality is we’re supposed to be raising the security posture and it’s not happening. And there’s a lot of different reasons that that happens. And I think going down again to some of the foundational aspects. These are going to be some just quick fire from the hip thoughts, everybody’s. Organization is different. The reasons why things don’t get fixed are nuanced.

I understand that, I realize that. But generally speaking, having been doing this for about 1415 years and seeing hundreds of different organizations, there’s a lot of different buckets. One is the assessment organization isn’t prepared to be able to help you out. And this again goes to the assessment organization not having the fundamentals to be able to even assist in providing remediation guidance. If you get a steaming pile of report and it’s got all these flaws on it, as you dig into the flaws, you may say to yourself, how do I fix this? You’ve called this out and you have stock general recommendations. If the organization providing the service isn’t teed up to be able to provide you expert advice and opinion and guidance on how to fix the flaws, then there’s a problem there. And that could be because they have no idea.

They know how to find it. They don’t know how to fix it. In fact, I remember some of the hackers that I was mentoring growing up as they were coming up and they worked for me. They said, I know I had a hacket. I don’t know how it works. Right? And that was a real catalyst for me to say, listen, it makes sense that you say that but we really need to know how some of these technologies are used so we can guide folks to be able to fix them or provide at least guidance. Now that being said, on the flip side of that some folks are hearing this and saying well that’s fine but they’re not paying us to fix it.

It’s their job to fix it. Some organizations offer remediation services but some organizations the remediation is the onus is on the organization that received or consumed the assessment and test to fix it and so why doesn’t that get fixed? Again, they may not know. Then it comes down to inventory, asset inventory. We don’t know who owns that asset and who owns it in and around and it’s an embedded system. How do we get it fixed? When it all comes down to it though, the prioritization of remediation has to become a huge goal. I would almost say that when you’re enlisting security assessment services internally or service oriented, a goal should be demonstrable progress and that demonstrable progress is difficult to demonstrate if you don’t have a centralized system where findings are input, worked on, reported and remediated, right? If you’re dealing with a bunch of spreadsheets and you’re dealing with them cutting the spreadsheets up, sending a bunch of different teams and hoping they get and following through maybe they’re getting fixed, maybe they’re not. But then if the remediation isn’t in focus for the assessment and test, the pen testing team is going to come in, drop the report, pop smoke and be gone and the consumer of the service is left.

I hope we can fix it. We fixed it. They said they fixed it. How do we test if they fixed it? Well. I hope the report that we got has enough detail in it so that we can validate that this has been fixed but then if that person doesn’t know how to interpret the output of the tools it all comes back to the foundation and technology being able to feed your ability to ensure things have been fixed. Drive that things have been fixed and know and validate that things have been fixed. That’s a great point I think for many of the testers who may be on the call or for folks who have worked in this, how many times have you come back to an organization or a team or a business unit? You did their pen test last year and you do their pen test again and you find some of the same findings I have straight up found flaws in networks that led to full system compromise and complete domain administrative control access to sensitive data.

The next year I come in and the exact same flaw to a T is present and it just makes you scratch head like did you just want to cut checks last time and not actually fix anything? That’s bananas to me but I can’t get inside the folks head. But what I can do is help enable people to be able to be positioned from the receiving side of security services and a providing side, focusing on remediation and making sure that your collaborative paradigm is teed up. To be able to expertly assist or fix and or fix the flaws identified is a paramount concern.

Anybody that’s just writing checks can make them payable to Tom and I’ll come by and pick them up on Thursday. Seriously. I mean, it goes back to what you said. You’re kind of tongue in cheek about it, but it’s like not another back to the basics talk. Well, if people were doing the basics, we wouldn’t have to do them right? There’s truth to it. It’s not out there. No, there’s absolutely truth.

Yeah, go ahead. A few more comments from the audience. Bring it in. Let’s see here. Michael’s got one. Talk about strategies to protecting websites. Issuance of sessionid to a new session without being readable in initial packets.

That’s over my pay grade. I have no idea what Michael is talking about. Yeah, that’s a little session management broken. Session management. Dealing with session management is a quality topic. I think it’s a little in depth for this session. But what I will say is identifying paradigms that allow you to make sure that your sessions are protected.

I mean, it’s 2022 and what are we still doing in a significant amount of the web? While not web, but just the application ecosystem out there. We’re still a lot of cookies. Session management is still simple as a cookie. And now there’s some really great technologies that are out there like heuristics and identifying flaws. You just use this cookie and then you use it again from another country or another IP address. There are a lot of different heuristics out there. And I’m not to say I’m not the application expert that’s going to come up to solve that probably perfectly.

If I was, I’d have a company behind it and I’d be a trillionaire and it would be great. But I think those kinds of questions was it Michael? Those kinds of questions. Bringing those questions to the security teams. Bringing those questions as action items. Bringing those questions to governance boards to say. Listen. Whether you own the application or your consumer of the application.

Driving those and saying. For our organizations. We’re going to have apps that handle session tokens and authorization via whatever nonsense and server side barrier. Whatever types of authentication flows and things that you can add to maintain the fidelity of sessions. Probably text that I’m not even familiar with that can do great things for authorization, authentication during session management. It’s a big deal. And in 2022, you can still get hooped if a cookie is snarfed and reused.

So there’s definitely value there. That’s like a technical term. snarfed for sure. snarfed indeed. Technical term. I love that one. I’m going to use that one.

You got snarf.

All right. We’ve got a few more, but I know you’ve got some more stuff to tackle, so I’m going to save some of these for a little bit later. Yeah, that’s great.

Yeah, I think that’s fantastic. These are great. What’s beautiful about this dialogue is what I don’t want to have this dialogue doesn’t end here. This dialogue doesn’t end in this forum. These are the types of things that you get together with working groups, with your vendors, and if you’re a vendor, then you get together and you figure out ways to help solve these for the people that you’re providing services for. I understand that everything there are business models that need to be taken into account, but these kinds of conversations are absolutely paramount. So what do I have here? I have a little graphic that shows a couple of the different network models and the reason why I put this up.

A lot of people are groaning and being like, I took this for CISSP and for Network Plus and A Plus and a whole number of other certifications. Well, the reason why models like the TCP IP model or the OSI model or other models are useful is because it’s an abstract framework that lets us visualize and put into buckets technologies. It gets difficult to talk about the nuances and technologies tax.

One of the things that I have done in the past and continue to do when I’m mentoring folks or I’m working with folks and I want to help them go back to the basics. So they say, okay, Nick, that’s fine. Anecdotally you said go back to the basics. So practically, how do I go back to the basics and what are your suggestions? Because they have a little bit of analysis paralysis. They feel like they have to boil the ocean. There’s so much there. How are they going to go and boil the ocean? It’s just too much.

And so what I like to say is go back to the OSI model and find a technology or a group of technologies at each layer and understand it fundamentally, theoretically, get the theory behind it. But when you’re reading about Bitwise ending and subnetting and all that stuff, that can start to just over like you read the words. So then go and practically do take tech stacks. So examples being set up a database, set up a web server that then queries data from a database and do it following guides, but also experiment. How do you set up this? How do you set up that? Work through the fundamentals of establishing a system. Maybe set up as your active directory. Or set up an Active Directory, set up Linux boxes, join them to servers, join Windows and Linux boxes to a domain.

These are all three examples of taking tech stack and working through how to make them work. Setting up apps, setting up databases, and then taking the tools that you want of your trades, especially in offensive security, taking the tools and the techniques and scripts and things that you’re running and be able to understand what they’re doing, how are they interacting with the protocol, what are the types of data that it’s trying to extract? What are the types of data it’s sending? How is it working when you do this? Why does that when you run Nmap against a host that doesn’t have port 80, doesn’t have port 443, doesn’t have port 22 open, doesn’t respond to ICMP, and it’s not on your subnet, but it’s up and it’s got some exotic ports listening, but when you run Nmap against it, it doesn’t respond. Why answer those questions, run your tools and techniques. Don’t be so married to the tooling that you can’t function when you don’t have that tooling. If you understand how a technology works, generally speaking, you will find that there are eleven different ways to do something. Maybe it’s running an operating system command, maybe it’s another way to interact with that protocol using a system tool that is native to operating systems. But if you’re so wrapped around automation and processes that you don’t fully grasp, you’re not going to be able to answer those questions.

But eventually I hope that you can. So my suggestion and some practical use cases would be establish some tech stacks that you’re going to set up and understand every step of the way when you run a command. Y, when you do this, what is it doing? What is it doing under the hood? I’m not saying that you need to have a PhD dissertation and a thesis that bit by bit can explain every aspect of it. But generally speaking. For a tech stack and then try and marry a couple of tech stacks at each layer of the OSI model or of the TCP model. Or don’t use a model at all. But just take and be like I really am interested in seeing how directory services works and how does LDAP work and Kerberos and cloud stuff getting involved and realizing that if you’re not being able to interact with and snarf around with APIs.

You’re going to be at a disadvantage because of so much of the attack surface that’s introduced in Cloud first organizations and in SAS models and such. That if you get a cloud assessment and you sit there and say. Oh. I’m going to solve it by just running Nmap and hoping to use Metasploit. You’re going to have a bad time. Now, that being said, Metasploit, for example, has so many auxiliary modules in it, I still to this day use a ton of auxiliary modules. Now, are there other tools that maybe I’ve written myself because I wanted to learn how something worked that I used? Sure.

Are there tools that fit my specific use case? Sure, but why reinvent the wheel? If Metasploit has an auxiliary module for it, why am I not leveraging it already? Now that being said. There are plenty of times where I’ve gone out and written a Python script to do something that metasploit already does. That there’s already a dozen GitHub repos in. But I wanted to understand what it’s doing. And sometimes the best way to do that is to write it yourself so that you can. Okay. This is what it’s doing.

And this is how it’s doing it. Now, again, that being said, if you can’t write a line of Python and code, something is overwhelming to you, don’t feel like you’re lost. There’s still a lot of opportunity to learn through establishing a baseline of fundamentals of systems do. I personally think that getting familiar with some scripting languages and maybe an interpretive language or two is very valuable? I do because similar to how with text XS and as you get exposed to more and more new tech stacks, the old tech stack that you’re familiar with can feed your comprehension of the next the new. And you say, oh, it’s all a database, it’s all a file, it’s all registry entry. At the end of the day, there’s some immutable things that it’s like this, and you can have this ability to comprehend it much more rapidly. Same with programming languages and scripting languages.

Not only can it help you with your automation, which is important for doing things at scale, but it also allows you to be like, all right, just due to some syntactical difference in how memory is handled and how it handles threading and the language it’s based on, or what it excels at, understanding four loops and variables and those types of things. Going back to the basics, I don’t mean you have to be an expert in six different languages, but if you master one, you’ll be able to dabble in a significant number of languages.

Now, I’ve said it probably a dozen times.

Manufacturing comprehension. What does it all mean? Well, a couple of years ago, I actually had an epiphany and realized that I was quickly becoming a gatekeeper. And I punched myself in the face and said, stop it. You got to be better than that. Because I was under the impression. And when I was working with folks. That I kept suggesting to my students and suggesting to my peers and maybe to the parents of my colleagues and friends who are coming and had kids coming up in high school and they wanted to get into It security.

I was saying. You know. My suggestion is that they spend two to five years or at least a couple of years in It in some fashion to be exposed to technology. Be exposed to different varied experiences so that they can build off of that foundation that they learn there and move into security. That was my constant line. I realized that because that was the journey I took. I was an army signal.

Corps. I joined the army at 18, army Reserve, went to training. I was a 25 bravo. Information system security analyst, security operator analyst, I don’t know, whatever 25 Bravo is nowadays, they change those every five years. And so that in the military, if you’ve been in the military, you understand that everything having to do with electricity and telephony and networking and web and database, everything was in your face. And so I said, I spent a couple of years getting exposed to so much technology, and I’m super grateful for it. I wouldn’t change that for a bit.

But I just started realizing out of necessity, there is not time.

We have such a need as human beings and companies and organizations and agencies in the public and private sector. We have such a need for smart humans to be able to be the operators, the analysts, and the folks behind our blinking boxes, the folks behind our automation, the folks who are responsible with securing our data and infrastructure, et cetera, that we just don’t have the time, and that people don’t have to spend 510 years like I did in networking, in databases, in system administration.

There’s value in it, don’t hear me wrong. If you’ve got that experience and you want to move into information security and cyber stuff, absolute value. But here’s what I mean by manufacturing comprehension. When you have experiential knowledge, you can then create environments and simulations that can rapidly assist those who don’t. And you know what they get to do? They get to benefit from your experience. And guess who benefits from their benefit? The entire It ecosystem. All of our security postures raise because folks are going out there and we’re creating scenarios where maybe for me, it took me two years of sitting on a help desk hammering out, trying to googling errors and being like, PC load letter.

What does PC load letter mean? Drivers install, new drivers print. That ended up I learned how I needed to read logs, and I understood about compatibility issues. I learned how to troubleshoot. Well, you know what, I can create scenarios that lets people learn the lessons that I learned rapidly, practically, and in a couple of days versus spending two years for that. So manufacturing comprehension would be creating simulations and that are conducive to it. On the job training paramount. So as you’re working through, there’s something to be said for getting thrown into it and going ham on the job and then group exercises.

What this means is you can get siloed pretty quickly. And so I think there’s a lot of value in making sure that teams of any nature are able to cross train, get involved, and do group things, because everybody brings a neat, novel perspective. Everyone comes in and regardless of their experience, there’s not a team that I’ve ever gotten to engage with where I haven’t left. Well, sometimes I leave dumber than I got in. No, I’m just kidding. Everybody has unique perspective, and even being able to understand somebody’s perspective that has a different point of view than yours when it comes to tech stacks, you can at least begin to see where they’re coming from, understand their arguments and formulate rationale in your head as to why you do it differently, those types of things. So I think to evolve your services and evolve your teams really have to make sure that we’re going back and instilling these foundational aspects and manufacturing comprehension so that we can elevate and move beyond tooling.

We can elevate and move into just a more elevated state of existence.

That sounds weird, but I think you get the idea.

I’m coming up to wrapping up here. This is really kind of hitting some of the points I already did cross pollinating. So some of the most value is not being just siloed and saying this is what I do and this is what I’ve always done. But getting into everybody else’s business. How does that team operate? What are their risks, what are they doing? How do they do it? What are their concerns? First and foremost is a better appreciation for effort. Instead of dropping piles of reports on folks at desk and be like bye, good luck. You understand that the pen test that you just did is going to overwhelm the snot out of this team.

So you need to maybe prioritize and triage a little bit better, especially with your special knowledge that you have. Maybe because you’ve gotten into the business, you understand their pain points. You can appropriately match their budget and their staffing that they have. In fact, a mentor and friend of mine taught me some of this in the public sector just recently. He was speaking to this.

You’ve got the idea of you can security test and pen test to your heart’s content but if you’re not aligning with their capabilities, their staffing and their budget, you’re doing them a little bit of a disservice. Not to say you pull punches. The burden of knowledge is on you. You got to call it like you see it. But there can be some give and take. There’s a better appreciation for the level of effort and how you get recommendations. And then from this, as you get involved in everybody’s business, as you understand it, as you’re better understanding their levels of effort, there’s just this natural byproduct that is collaboration.

That team is going to work with you, you’re going to work with that team, that business unit, that client, that whatever. You’re going to have this give and take, this back and forth and it’s collaborative and the last thing I’ll go to, and while we have time, maybe we’ll wax a little bit on some more questions, but there really is value in ensuring that you have a collaborative paradigm. More than likely. Ideally a platform. Some sort of solution that will allow you to take the output from these efforts and internally make your efficient drive efficiencies. Allow you to track different data. Report on the data and make sure stuff is getting fixed.

Make sure it’s getting fixed. Being able to deal with the data. Being able to have oversight. And being able to administratively provide reporting and metrics. If you’re trying to do this and you’re not utilizing a platform that can enable you to recognize your flaws and vulnerabilities and data, is it impossible to get to a more secure posture? No, but it’s much harder.

So that’s about the depth and breadth of what I wanted to talk through. I hope you understand the idea of going back and establishing a foundation so that you can then evolve. And Tom, if we got any other questions or thoughts or ideas or thoughts that you have, we can start to bring it home. Yeah, totally. To me it seems like it’s almost like a mind shift or even a cultural shift for some places because they’re working in Silos right now. We’ve got to get them away from doing this stuff, getting people involved that aren’t necessarily part of security and having conversations that maybe not the strong suits for the folks that are having them. Right.

Because a lot of times people, at least when I was going to school back in the 90s, it guys, they weren’t the most personable guys, right. So they weren’t going to be selling stuff internally and they weren’t going to be trying to get other people to champion their causes. So I think it is a little bit different now. You almost have to have a marketing hat when you’re going through and doing some of this stuff. So more of an observation than anything else. But do you see? You hit it spot on. I really do.

I think you hit it spot on. That’s also a topic that’s got a lot of discussion. The idea of understanding that articulating, communicating and strategizing is also the job of cybersecurity professionals. There is a need to make sure, and I think there’s a lot of different research on soft skills. And you know what, there’s a reality of understanding strong points. Maybe some on the team don’t get the points across and can’t collaborate as well as others. But there needs to be that collaborative and communicative aspect.

And that’s why the cross pollination idea of making sure that folks are being involved in other business units so that they can sympathize and empathize, then you’re creating relationships. And so when the Red Team comes in, it’s not the Red Team is coming in calling the Blue Team’s network an ugly baby. The Red Team’s coming in to say, we’ve identified flaws and we want to help you fix them. And after you fix them, we want to run some tests to make sure. But that communication, you can have that communication and it can be appreciated and then reciprocated and that relationship can be raped. But the same data can be presented in a harsher term or in a flat term or in a way that isn’t communicated well, and that can breed contempt, that can breed animosity. And all of a sudden, folks may be on the same team company wise, but they’re at odds with each other.

So absolutely. Involving business units, involving folks, and realizing that the cybersecurity posture of an organization is everybody’s responsibility, it sounds smarmy. It sounds like a user awareness T shirt campaign, but there’s truth to it. It’s everyone’s responsibility, not just cyber security. It really is. I fully agree with it. I love that, though it does sound like a T shirt for October.

Great.

Here’s an observation and a question honestly from Bradley. Sadly, we have a shortfall of ethics and a shortfall of hackers, and even worse, shortage of Ethical Hackers. Any advice for Ethical Hackers on how to find their tribe? I snarkily sort of said secure world, obviously, but where are you? Because I don’t think there’s an association of Ethical Hackers out there yet. Right. There probably is. Probably not called that, but it might be called that for all I know. That raises a really good point.

I joke somewhat tongue in cheek, but someone not. And I say things like, I’m glad that I got into this business professionally. After a bit of time, I was married and had kids, and my moral compass was well established.

That could be a whole other topic on ethics and who defines ethics and what it means. But the idea is there ends up becoming I think it comes down to mentorship.

As someone who mentors, speaking to the folks who have an opportunity to mentor other folks, making sure that you’re establishing an understanding of why it is that folks want to get into cybersecurity. A perfect example. My son is 13 years old, and when you ask him what he wants to do, he says, I want to be a hacker like my dad. Now, maybe that’s true, but that’s also all he’s ever known that I’ve done. And the idea of it looks cool. He thinks it will be lucrative, it will be neat. He can hang out in his PJs and say that he’s a hacker, but does he really want to do that? Is it something that really is the grind of learning these things, something that strikes his mind and his imagination? And what’s his motivation for doing it? Is it because it’s an easy paycheck? Is it because he’s naturally curious? Does he want to help people? I think early on, we, our folks who are in the mentorship vein, can go through and encourage folks to really solert and recognize what is your goal? If your goal is to make an easy buck and have a super lucrative career, there are a lot of careers that can make that happen.

It doesn’t have to be being a hacker and really establishing kind of a moral code earlier on. And I think as far as how do you. Find like minded folks. That just means putting yourself out there and having a discerning schnazola smell it out. My favorite thing to do local meetups local user groups, local hacker groups. Some of the local hacker groups can be intimidating because you do find business professionals and the Mountain Dew hoodie people. But some of the Mountain Dew hoodie people are the nicest people, the most upright and kindest folks, and some of the business folks are too.

And everybody comes together. The reality is it’s just not going to happen. The onus is on you to find those people, to find those groups, put yourself out there and have a discerning palette and you can check out secure one good idea. I like that last part best.

Frank’s, got a good one here. How do you take into consideration the development of recommendations given the company’s maturity and or constraints in either staffing, budget, et cetera? That’s such a good question, such a good question. Therein not to be a broken record, but therein goes back to if you or your team has established a very solid understanding of technology, baselines and foundations and you get it, that can inform your ability to contextually, look at an organization and say based on their staffing, based on the resources that they have. Here’s my recommendation to you that’s going to be triaging. A lot of times organizations implement services approach because they just don’t have the skill set on staff and they don’t have the time or the skill set, but they have some coins. Your job is not just to give them data as is data they could run from a tool automatically. Your job is to contextualize it.

Your job is to come in and say, I understand. And the biggest hitting, I’m going to triage these flaws for you and understand them to you. I think, though that’s a big question, Frank, and I like it. It’s leveraging the experience, the understanding of the business, the understanding of capabilities and the understanding of the consumer of the security service and their maturity level and how you provide those. And I would say using common sense, saying these are the things that are going to give them the most value rapidly with the tools that they have at hand. Like an example, any organization, big or small, that’s not using multi factor authentication on all administrative endpoints outside the organization, right. That’s project One, get that going and that’s going to help limit your tax service significantly.

But yeah, good question, Frank.

What is this common sense that you speak of? That’s a whole nother loyalty.

That’s kind of the end of our time. Frank has another really great question. I’m going to send you that one and maybe you can respond offline because it could be a whole other webcast honestly. But thank you everybody. Submitting your questions and your concerns that we went through today. I appreciate that, but I think there’s one more slide here, I’m noticing, do you want to talk to this? And then also kind of just give us, if nothing else, what should our audience you and I have kind of said the same thing a few times now, but what’s one homework item? Or if nothing else, just what can they start doing now? It’s a good question. So, yeah, these resources.

Come take a look. Plextrack is kind of that platform where you can become a single pane of glass for the output of security, assessment and testing activity. The data can be consumed, collaborated, curated, dealt with, reports work on, and findings fixed. Come check it out. I could even give you a demo of it at some point. There’s a good chance that if you get a demo, it might be from me. Check out the YouTube.

They’ve got a lot of good videos. And I think one homework assignment is to go back and think about how you’re involved with your organizations, be It Consultative Enterprise Service Provider, whatever the case may be. How can you be an agent of change to make sure that foundational aspects aren’t being lost for the newest blinky box or the newest tech stack that’s out there? I like that one. Brad said, honestly, if you’re having trouble finding other ethical hackers, start your home association, man.

That’s a good deal. They all start somewhere. Issa started out almost 30 years ago with just a handful of people that kept meeting at the RSA conference and they were in La. So they decided, you know what? We can’t always make this. Let’s just do our own thing. And so they started at Issa. Can’t find it, build it.

I like it. That’s such a hacker mindset too. It is. It’s like, hey, I don’t want to have to go there all the time, so let’s just meet here. So it worked well. Excellent. Thank you so much, Nick.

I really appreciate your time and unpacking our topic today. And I had fun. It was a nice casual conversation. I hope people got into it and are really going to start thinking about. You do need the basics. The basics are there for a reason. And it is easy to forget, though I do it with a lot of stuff myself.

And then I think, you know what? Have I actually done the steps in order? Gosh read the instructions. Right? So anyway, hold on an hour and talking about it, following the instructions. Anyway, thank you, everybody, for joining us today. If you haven’t already, you can download your certificate of attendance down there on the menu bar. It’s a pop up. I know sometimes that gets blocked. If you have any problems getting that, shoot me an email tomb at securewell.

IO. I’ll get one of those and send it off to you as soon as I can. It usually takes me a few days, honestly. But if you can’t download it and you need one, let me know, we have a bunch more webcasts on the way. There’s one later this week and more next week, I believe. I’m skipping that slide just because we went over today, so that is not there. But the link is in the resource tab.

You can go ahead and register for any of the future stuff coming up. But that concludes our talk on Hack to the Future, going back to the basics with Mr. Nicholas Papovich. So thank you, Nick. And thanks to the folks over at PlexTrac for making it possible. We’ll everybody at the next row session.