CCT 130: Securing the Digital Frontier - Mastering Vulnerability Assessments and Network Scanning (D6.2.1)

Join me, Shon Gerber, on a journey that cuts through the complex undergrowth of cybersecurity's vulnerability assessments. This week's episode is a treasure trove for CISSP exam candidates and professionals alike, as we unpack the intricate details of CVEs, CVSS scores, and the acronyms that are the bread and butter of our industry. Discover how the technical handshake of a TCP connection can reveal your system's soft spots and why a recent ransomware attack in Missouri is a stark reminder of our critical role in safeguarding municipalities. 

Strap in as we navigate the four crucial stages of vulnerability assessment. I lay out the roadmap from planning to remediation, highlighting the necessity of both automated and manual techniques to unearth security gaps. It's a game of cat and mouse where patches and updates are your best defenses, and I'll shed light on how an iterative approach to reassessing vulnerabilities keeps your security posture robust. We'll also tackle the CVSS and its role in painting a clear picture of vulnerability severity – knowledge that's invaluable when making those tough calls between business needs and risk management.

Finally, for those gearing up for the CISSP exam, I've got your back. Hear how my own hurdles turned into a blueprint for success and how you can leverage my structured approach to not just pass, but excel. I'm dishing out the comprehensive resources and step-by-step guidance that you'll need in your arsenal to conquer the CISSP with confidence. So, tune in, absorb, and arm yourself with the strategies that will elevate your cybersecurity expertise to new heights.

TRANSCRIPT

Speaker 1: 0:00 

Welcome to the CISSP Cyber Training Podcast, where we provide you the training and tools you need to pass the CISSP exam the first time. Hi, my name is Sean Gerber and I'm your host for this action-packed, informative podcast. Join me each week as I provide the information you need to pass the CISSP exam and grow your cybersecurity knowledge. Alright, let's get started. Let's go. Cybersecurity knowledge.

Speaker 2: 0:24 

All right, let's get started. Good morning it's Sean Gerber with CISSP Cyber Training and hope you guys are all having a beautiful day today. Today is a wonderful day. We're going to be getting to talk about some awesome aspects related to vulnerability assessments. So as if you're aware of the CISSP Cyber Training and how this works is we have a podcast that occurs on Mondays and we have a podcast that occurs on Thursdays. Mondays is designed specifically to go over a topic and then Thursdays is to cover the questions as it relates to the CISSP. And so today we're going to be talking about vulnerability assessments, but of those, this is off domain 6.2.1.

Speaker 2: 1:02 

We're going to get into the vulnerability assessments, kind of just an overall about them. Then we're going to get into CVEs, cvss scores. We're going to get into the overall metrics around those. Then we're going to get into CCE, cpe and the extensible configuration checklist description format, or XCDF. We'll get into that a little bit. And then the last thing is we're going to get into OVAL. We're going to kind of talk about how the CVEs work and then also a little bit about the TCP handshake and scanning as it relates to a vulnerability assessment. So the ultimate goal is we're going to get into these different aspects related to what you might do within a vulnerability assessment and some of the key terms that you may be connected to doing those, as well as understanding that, for the CISSP, what you need to know in relation to those acronyms and many other aspects around vulnerability assessments, because you know, some of you may or may not have done those and if you haven't done those, a lot of times these terms seem very unique and very different. So we want to cover all of that to just kind of set a baseline for everybody. Okay, so let us get into the. Okay, but before we do, we're going to go over just a couple.

Speaker 2: 2:12 

I saw a couple articles today that I thought were interesting, that you guys may or may not be interested in. I was kind of interested in them, so they thought, well, let's just talk about them a little bit. So the first one that I saw that kind of stuck out and this is something we've been talking on, cissp Cyber Training is the aspect around these ransomware attacks that are hitting municipalities. So there was an article about a Missouri county that's in the United States. It's a state called Missouri and Missouri County declares a specific state of emergency amid a ransomware attack. Of emergency amid a ransomware attack. Now, the main thing around this this is actually part of since I did Kansas City because I'm in Kansas one of the big things that came out of this was that they were getting ready to hold a special election for adding in a major league baseball field and making changes to this field. Well, the ransomware attack hit basically at about that same time and caused a massive effect within that county. Now this county is part of Jackson County, missouri, where there's approximately about 650 million or 650 million Wow, that'd be a big city. No, it's about 650,000 people. So my friends in China are going oh, that's not even a village, but there's about 650,000 people in the Jackson County area as well. Now the Jackson County executive that basically is in charge of that overall county itself issued what they call an executive order declaring a state of emergency because of this ransomware attack, and it's now in a position where the amount of money that's being requested is substantial to the point where they don't know if they have enough money within their money that they set aside to deal with this situation. So the bottom line is is there's right now from it comes from a standpoint of different municipalities being attacked this one here. There's about 28 county, municipal and tribal governments in the United States have been hit since the first of the year. Last year, there were about 95. And then, according to the Ars Technica, there's about 106 in 2022.

Speaker 2: 4:11 

The point I'm trying to make with all of this is that one, like we said before, you all are security professionals or IT professionals, and you're listening to this podcast because you like cybersecurity. Whether you are one at this point, you're trying to learn, or you are one right now, one of the things you want to do is I'd highly recommend reaching out to your municipal governments. I have done that. I will also just be very transparent. It has been, with some limited success, that the fact that people are they go, yeah, yeah, yeah, let's talk about it, but then nobody ever wants to talk about it, and then, plus, most of the time, they have other technical challenges just because they don't have the right people in place to help fix some of these problems. So it really comes down to you as being the part of ones that are going to have to help this process, and I challenge you all to that because, when it really boils down to it. You all are some of the front lines of these types of offense that are occurring, and people are going to rely upon you to help them in this situation.

Speaker 2: 5:12 

Okay, so this next article is about how good is AI-assisted code generation? Now, I ran into this when I first began teaching at well, actually, my end of my tenure at Wichita State University and I was teaching cybersecurity, risk and cybersecurity, iot, slash, automobile security and so on and so forth. One of the things that came out of that was learning how to use AWS, and then you heard, learning how to use scripting. From a Python standpoint, I created a Python script for a product we were using, and when we were using this Python script, when I originally started I'm not a developer, right, I've had developers work for me, but I've never really had to do much of it I understood how it worked, but I I didn't know how to do it bottom line. So what ended up happening is I created a script and it took me about three weeks of poking and prodding when we first started to create this script.

Speaker 2: 6:04 

Well, my students started up and they go well, okay, can we use AI? This is when AI was released shortly thereafter, and so I made a comment to them. I said, well, heck, yeah, give it a try, see what happens. Well, they made the script. That took me three weeks and, again, I'm a noob, so I didn't know what I was doing. They were able to create that script in like milliseconds and it was way better than the script that I created. So I tried it myself and, sure enough, I was able to do it just by telling it what I wanted it to do, and that was through using the large language models, or LLMs, and I think it's really cool that this is available for people, especially developers, that are out there wanting to use this.

Speaker 2: 6:41 

Now, the one thing that people worry about is is this going to take away from what they do for a living? And some people it may, but where it is going to be a situation where it's going to be very helpful, in my small opinion, is the fact that if you are a professional developer that wants to expand and look at different ways to create better content and better code, you would use AI to help you with the basics and then you can help build upon that. It does help reduce dramatically the amount of code generation you have to do over and over again. So bottom line is that they had said, by 27, 70% of professional developers will be using some level of AI code generation, just because it's going to be a useful factor, and I've seen it myself before I quit my job working at the Coke Industries company. One of the things that I saw was our developers were using it it and they were able to save at least 50% of their time by using AI code generation through GitHub's products. They were able to dramatically reduce the amount of code that they had to generate.

Speaker 2: 7:49 

I also know that Microsoft's Copilot is useful in that Copilot. I love Copilot, by the way. It's a really great product and I think that as time goes on and these get better, more and more code development is going to occur. Now the question that's going to have to happen is is you, as cybersecurity professionals, whether you're in the development space or not, are going to need to be involved to help them ensure that they are creating good content and good, secure code?

Speaker 2: 8:15 

Many of them will rely on the code that's created by the product and they're going to walk away and they're not going to potentially do the same level of testing that they would with code that they generated, so I see that as a possible challenge you all are going to have to work through One of the points they brought up in here. You know, obviously, some of the big places you can get this code generation done is Amazon, codewhisperer, microsoft 365, copilot, divi, ai I've seen that Codium and then Google Barter. There's many, many more, but those are just a couple of the few ones that are out there. They had mentioned that AWS they're using CodeWhisperer, able to get their tasks done about 28% faster. I've seen the statistics anywhere from 30% to as much as 50% increase in capability in the amount of time that you're needed.

Speaker 2: 9:04 

It definitely works well when you're dealing with IoT core, when you're dealing with the overall aspect. Again, it's just to try to bring up the fact that if you are interested in AI development code, I think it's a great place for you to be development code. I think it's a great place for you to be as a security professional. I also think that just because they have the code development doesn't mean they're not going to need security professionals. If anything, you're going to have to be even more engaged and I highly recommend that you kind of put that good foot forward to try to be part of that discussion, especially if your company is going to be putting that in place. So again, great article. Again it's on Computer World. It's about how good is AI-assisted code generation and you can check it out. I think that's again another good article for you to look at if you're looking to get into this space and if anything it allows you. I highly recommend, if you're a security professional, you read articles like this. It makes you a much better person for one. Two, it also helps you understand the different technical challenges that are out there and available and then, as when people come to you with these ideas, you are already schooled and already understand at least the conversational aspects around the topics, versus not being having any idea at all to deal with them.

Speaker 2: 10:14 

Okay, so let's get started in today's podcast. So we're going to talk about vulnerability assessments and just some of the key components around the CVEs and the different pieces below into the overall vulnerability assessments and then we're going to get into some network scanning pieces of this. So we're going to focus on domain 6.2.1 as it relates to the CISSP manual, and this would be the one that's provided by ISC squared, it's official study manual and that's kind of lined up to what 6.2.1 is. And the overall goal, like we've mentioned before, is to go over each of these different domains and subsections of them within the podcast so that you have something to use for when you're studying for the test. So if you're looking to study the book, you read the book, you go through the is the cissp cyber training podcast. You go through my blueprint, you go through various aspects of this. The goal is to help you pass the CISSP the first time. That's the ultimate goal.

Speaker 2: 11:07 

So vulnerability assessments what they basically are is they're a review of a security weaknesses on the various information systems that are within an organization, and they can be done in many different ways. I actually was doing an assessment on some startups that are doing this from an automated point of view, and so they can do various pieces of this can be done either from an individual's going in and doing this and using a computer and doing the scan, or, in some cases, like I mentioned, potentially someone doing this in an automated form. They're crucial. They really are an important part as far as preventing breaches and identifying and addressing vulnerabilities before they get exploited. And that it's an important factor because if you don't do these vulnerability assessments, you really don't know what problems you have. And as you deal with computer systems, you all know they're very complex and they have a lot of moving pieces and parts with them and, as such, anything can be out of date, right. So, like in the case of my computer, it pinged me last night saying hey, you need to do an update, we'll do it tonight while you're sleeping If these things are not updated and patched. And that includes both. The operating system, includes the applications themselves, it also includes the firmware, the hardware, so there's all kinds of aspects in here that need to be updated to ensure that there's not a vulnerability within these systems.

Speaker 2: 12:24 

When they first came out, they were very small, they were very basic, they were simple and you didn't need as much hands-on work with them as you do today, and so a vulnerability assessment is an important process. Now there's typically various stages of a vulnerability assessment, which includes planning, scanning, analysis, remediation. Those are the various stages which we do go through in the podcast. We've been through multiple of those. You also can go to CISSP, cyber Training and you can check out some of the other content that I have there for free. And then, if you sign up, you as well as far as with one of my different packages, you can get out some more aspects around vulnerability scanning to include some of the more intricate details around the scans. Now there's an iterative nature of this process which requires an ongoing reassessment again to maintain that security posture. Now, if the automated piece of this is great, there's also various tools out there within the, within companies, and you can get you could buy these almost any time is to be able to get a to do these types of scans for you. They they may actually do this while from an automated standpoint internally, you also can get them from external entities that'll do that for you as well.

Speaker 2: 13:33 

So the bottom line is vulnerability scanning, or vulnerability assessments, are an important part of your overall plan to secure your organization, and they should constantly be used when you're dealing with your company. And so, as you go forward, you're going okay. Well, how do they work? Well, we're going to get into what are some of the key concepts around them and the key terms that you may see. So the first one is what we call a common vulnerability and exposures, or CVE, and you may see this term used around a lot.

Speaker 2: 14:05 

Now, if you've been in sort of IT for a while, you understand what a CVE is, but if you're just getting started, you may not quite understand. Or if you've really been in for a while you never dealt with security you may not really even know what a CVE is, but it's a registry that provides a unique identifier for each publicly known cybersecurity vulnerability, and this is defined by what it can do. So they'll see an issue, they'll have a problem that'll be brought to their attention. Then the governing bodies will then turn around, and this is done by CISA. They'll say, okay, hey, we're going to go and create a CVE based on this vulnerability that we have found and it's a way that they'll help standardize the information around the vulnerabilities that are shared and understood across various platforms and systems. So, as an example, if you have a system that is doing scanning through your environment and it knows that in this potential vulnerability it is supposed to look for X whatever X is Well, it's also that that vulnerability is tied to a CVE. So when it scans their system and it says, oh, I found this vulnerability, it will then tell you hey, I found the vulnerability and it's tied to this CVE.

Speaker 2: 15:15 

Now, the purpose behind this in many cases is for you then, to you as a security professional, to dig deeper and realize okay, is this CVE, is this vulnerability something that I should be worried about? Now, if you're in a large company, it doesn't really matter even a small company. You need to look at all of these CVEs that come in and determine whether or not it's appropriate for you to actually do something to it, because in some cases, these vulnerabilities will come in and you'll say, okay, well, for me to do this, I'm going to have to shut down this manufacturing unit, and I'm just using manufacturing as an example. I have certain windows in which I can shut down this manufacturing unit to make this change, well, you may have to live with that risk for a period of time without having to do it. Or if you work potentially in another type of business where you have the ability to make changes but they can only be done on the weekends, because during the week you have production. You can't mess with it unless it's an absolute critical issue. So then you could actually take it down over the weekend and make those changes and those fixes. So it depends upon the company and what the company will allow you to do. But you need to look at all of those because, again, from a risk-based decision, you need to decide is it important for me to make this change or is it not important for me to make this change?

Speaker 2: 16:30 

Another common term you'll see is a CVSS or the Common Vulnerability Scoring System. Now, the CVSS, it's a free and open industry standard for assessing the severity of these vulnerabilities. So we talk about the vulnerability there's an issue? Well, the CVSS will tell you how bad is the potential issue and the score will provide you a way to capture the characteristics of the vulnerability and produce a numerical score, or numbered score more, reflecting the severity. So now you'll see, in situations where the CVE will come up, the CVSS is there as well, and if the CVSS is ranked from a 1 to a 10, and it may be a 9.5, might be a 9.2, could be a 2.3, you will see the severity of these systems and you'll go well, should I fix it, should I not fix it?

Speaker 2: 17:19 

Now, as you're looking through all of the different things that are coming in as it relates to the vulnerabilities within your organization, if you see something that is maybe a four or five and you're like I'm not going to worry about it, you may want to consider the fact that if it's easy to fix, you may want to do it, and the reason I say that is because the four of the five could lead somebody to a much more critical type of environment that you may not be aware of. So, as a hacker by trade in the past, if I found something that would be a vulnerability that was relatively benign but it led me to a more critical vulnerability, I would take that path Because, again, we're all lazy, and so if I can find a way that makes my life easier, I would take that path Because, again, we're all lazy, and so if I can find a way that makes my life easier, I will do that. So what I'm saying is that if you find a vulnerability that might be lower, you need to also evaluate those and consider the fact that maybe you should update those, especially if they're a simple fix. Update those and get those out of the way, because the more vulnerabilities you have in your environment, it could go also go from a 5 to a 10 because of something. We don't know what that could be, but it potentially could do that, and if it does that, you want to make sure that you are properly prepared and you've updated those systems appropriately.

Speaker 2: 18:33 

Now, as you're dealing with the different components of a CVSS, again, there's it's broken into three different metrics. There's a base, a temporal, a temporal. Temporal See, I can't speak. I got my third grade. Education is just coming out, it's coming out like gangbusters. And then you have environmental metrics. So your base metrics these represent the intrinsic qualities of the vulnerability that are constant over time and across various user environments. The base score is determined by analyzing the exploitability and the impact. That's a key factor of the vulnerability, considering again how complex it is, all of those pieces that roll into confidentiality, integrity and availability. So they're going to come into complexity, need of the user interaction, how the scope is going to be set up and then also various other aspects related to can it be exploited.

Speaker 2: 19:24 

So the temporal metrics these reflect the characteristics of a vulnerability that may change over time but not across user environments. The temporal metrics are you will include the current exploit code maturity, basically, how easy is it toward the code to be exploited against the vulnerability? The remediation level are there available fixes for it? And then the report confidence. Obviously, do they feel confident in the overall report itself? Is it something that is something positive, right? Do they understand that it's actually an issue or not? Those are the different metrics that will roll into the temporal aspects. Not those are the different metrics that will roll into the temporal aspects. Then the environmental metrics these capture the characteristics of the vulnerability that are unique to that particular user's environment. So it could be where that this system, it can only happen in a environment that has SAP or a like type of vulnerability system running in their environment. So that would change the CVSS score. But if it was substantially across all different types of companies, then that environmental metrics would actually go up. So it allows you to understand adjustments of the base and the temporal scores to help you understand the securities posture there. And again, they want to understand the potential loss if it was a successful exploit. So those overall pieces are key factors when you're looking at the CVSS score. And how does it create it? Because that I would say the CVE is important, but one of the more important ones that I look at is the overall CVSS score.

Speaker 2: 20:56 

Now, another term you may hear is the CCE, or common configuration enumeration. Now, I haven't heard a lot about this, but you may see it and it may be a part of a question that you have on the CISSP. The CCE is a list of system security configuration issues that can potentially lead to vulnerabilities and this CCE provides a really unique identifier for these configuration issues to help you fix them and accurately correlate them in a much faster manner. Honestly, I haven't seen many of this. I think I've seen this tangentially in a couple spots, but it may be something that you're connected to with the exam, so I just wanted to kind of throw it in there for you.

Speaker 2: 21:34 

Common platform enumeration this is something I have seen and this is where it's a naming schema that's been created and it's for IT type systems, software and packages and it's a way they can identify the classes of applications, operating systems and the hardware that's associated with them. Now, if you can see my screen which, again, it was going to be available at CISP Cyber Training, you can watch the video there. It'll be up to you there. It'll also be at YouTube. You'll be able to check it out there. It might be a few weeks, probably about a month, before this one actually hits it, but the ultimate goal is, if you go to CISSP Cyber Training, you'll actually see all these videos. All of my podcasts are in the video formats, are all there specifically waiting for you to come view, so you can go to CISSP Cyber Training and check those out. But the example is that with a CPE for, let's say, a Microsoft Windows 10 environment, you can see that it would be kind of an abbreviated format. That's there and it basically goes out that this is Microsoft, it's a Windows, it's a Windows 10, and then the version, which would be 1903. Now, as you all know, the versions of these various operating systems are available and with those operating systems, as they all know, the versions of these various operating systems are available and with those operating systems, as they get updates and patches, they get a number, a numerical number, associated with them. This identifies which operating system it is and also the version in which it's being updated. So these CPEs are important. Just because the CPE is important, because you can help you understand is this risk against Windows 95 systems? Well, no, it wouldn't be, because it would be tied to this Windows 10 system, so you wouldn't have to worry about it. You have other things to worry about if you're using Windows 95, but that being set aside, that's how CPE is set up.

Speaker 2: 23:15 

Another one is extensible configuration checklist description format. I don't know if somebody was smoking some marijuana when they wrote that, because it's like really painful, or they're a geek IT geek that just said, hey, let's just get a really long word and then make an abbreviation for it, or a really long set of words, not one word, but a set of words and make an abbreviation. So XCCDF is a specific language for writing security checklists, benchmarks and related documents. Is a specific language for writing security checklists, benchmarks and related documents. It does allow for the creation and maintenance and dissemination of security information. That's consistent with a machine-readable format. Again, that's the key factor. It's machine-readable. It allows it to be basically ingested and used in that format. I've never dealt with it myself personally, but Salt was on the CISSP book was recommending it and so therefore I thought, well, we better put it out there, because I was not really connected with it prior to actually this podcast I'd heard of I shouldn't say I've heard of something like it, but it's new. So it's not new, but it's probably been out there for a while. It's new to me. But it's XCCDF, which is Extensible Configuration Checklist Description Format. They talk about checklists under FISMA that you may use and then also it basically helps you upload something to demonstrate you've made compliance with, specifically, security requirements. So if you're in the government space, maybe you have dealt with these types of XCCDF formats, but again, it's machine readable. That's the key factor on that piece.

Speaker 2: 24:43 

Next one is open vulnerability assessment language, or otherwise known as OVL, and it's an. Ovl is a community standard to promote open and public available security content and the standard way for transfer is information across the entire spectrum of security tools and services. It's obviously written in XML, which I understand XML better than XCDF formats? Yeah, I don't know that and it's using various tools to automate the vulnerability assessment process. Overall. It's part of a broader set of standards that help in automating the overall vulnerability management lifecycle and it's an important factor when you're dealing with creating security policies. So, again, ovl, it's a community standard to promote open and public available security content. I've seen it. I haven't really done much with it, but it's something else that you may get exposed to on the CISSP exam.

Speaker 2: 25:34 

So one thing I want to bring up is we talked about CVEs and we talked about whether they're brought up. How does all that work? So I want to kind of break down how are the CVEs determined? Because you need to kind of understand that whole concept. And when you're dealing with CVEs, there's the discovery right. We talked about how it's either discovered by an individual or researcher or a company, or potentially even an automated system that will find the CVE. Now, companies obviously Microsoft and so forth they're constantly looking for updates, but you also have individuals that could be a researcher that's looking at a potential risk. You could have someone that just stumbles across it. They are then discovered. Now you'll also have it where the reasonable disclosure piece of this is that a researcher will see this problem, say, hypothetically, they will then go to Microsoft and say, hey, we're not going to release this to the public, but you need to get it fixed. But you have a period of time to get it fixed and they'll work with the company Microsoft is an example in this situation to come up with a fix for that product. And that's what they call the reasonable disclosure piece of this. Now, sometimes the software companies don't get it fixed in time and so I've seen researchers go well, hey, you know what, we gave it to you, you did nothing with it, we're releasing it to the public. And then it forces their hand to get it done. So that's something that you may hear about or read about, that you'll see happen and go wonder why they did that.

Speaker 2: 26:55 

So reporting, reporting how this is all set up from a reporting standpoint is that once a discovery is made, then at that point in time a CVE numbering authority is going to assign a CVD ID. Now, this organization has authorized to do that. Now, for an example we'll give you Microsoft is a CNA and they can assign CVEs specifically for vulnerabilities found in products Other companies may not have a CNA and so they would force that up with, potentially with CISA, to help them in this overall process. But then they would say, hey, this is the problem, we're going to give it a CVE number and then they will put that out to the community. The CNA will analyze the report, confirm its vulnerability. They will then assess the impact and the affected components and whether it's a new issue or the issue is related to an existing CVE. Once it's confirmed, then the CNA will create a unique CVE ID. I know there's acronyms everywhere, sorry, but basically the CNA will create a new CVE. If you say, hey, it's not new, it is new, it's not a used one, they will then create this new number, and this new number would be, in this case, cve 2021, 345678910, whatever that number is or 2020, in this case it would be CVE 2024 dash, blankety, blankety, blankety, blank. So they give it a number and they put it to a date. Once it's done, then they will then put it in a national vulnerability database, which is also called NVD, a National Vulnerability Database, or November Victor Delta, and this includes a description of the vulnerability parties that are affected and then any sort of references and advisories that go along with it. The common scoring obviously the CVSS, which we talked about earlier will be then also applied to it to understand the overall exposure that you may be dealing with. So, again, the overall CVE and CVSS process are an important factor, and the National Vulnerability Database does house all this information, and I highly recommend that you become aware of this location, if you haven't been already, because it's a great place to go check out CVEs and if they will potentially affect you.

Speaker 2: 29:00 

Okay, so, real quickly, we're going to go over the TCP handshake and some key things you need to be aware of. And why am I doing that? Well, the main reason is that, as we get into this next part of network scanning, there are some various scans that are going to take place and you're going to need to be aware of the overall TCP process. Now I know many of you already are. You've probably been studying for your CISSP, you got it, so I'm just real quickly going to go through these. But if you go to CISSP, cyber Training, you can actually see the content as well. I'm in the process of uploading some of the documents in there as well. I haven't got to all of that yet, but, as you'll see the documents for each of the podcasts, you can actually look at the content there as well. So the TCP Handshake is set up to help go through this overall process.

Speaker 2: 29:42 

Right, so we talk about the TCP and that's the TCP. Ip is your overall connection that you have with another server, another computer, whatever that might be, that initiates this connection. Well, it's broken down into some various pieces and we're going to go over those very quickly. You have SYN, which is basically initiates the content using a SYN packet. It'll send a picture, a SYN packet, to a server. It begins the conversation and this includes various sequence numbers and so on and so forth, but the bottom line is it's to start the conversation. Then you have a SYN ACK. Okay, that's ACK, and this is what happens when the server is willing to establish the connection with you. So you go hi, I'm here. The server goes okay, yeah, I'll talk to. And it sends you back a SYN ACK and that has its own sequence number to basically be able to track the conversation of the communication connection. Then the client will send back with an ACK. Oh, yeah, okay, so cool, you want to talk to me. So now I'm going to go. Okay, I'm going to talk to you too. And it sends back a SYNAC, this ACK packet, and this has again another sequence number, again more information's in there, but it basically completes what they call the three-way handshake establishing the overall connection. So that is the basics of a TCP IP connection. Now there are other I can't remember the name, they call them triggers, but there's like flags. I'm missing it. I think there's a different term for it and I'm just having a total brain fart right now.

Speaker 2: 31:09 

But there's other parts to the TCP handshake. You have reset, you have FIN, you have FINAC. So those are some other ones. Now there's a couple in there that's like urgent, there's post. But the next ones that you'll deal with the overall TCP connection is reset, fin and FINAC, and the same process by which you did the three-way handshake that began the connection. You're going to do something very similar when you're tearing it down and you send the reset, the reset at any point. This reset will receive a packet. It's unexpected or out of the current state. It may respond with a reset packet and it basically terminates the connection or attempts to terminate the connection that's in place, saying hey, there's a problem and so we need to fix it. The FIN is when the device wants the end establishment to end the connection completely. It'll send the FIN packet and the receiving device will respond with an ACK and send its own FIN packet and then, once that is done, they'll respond with a FIN ACK, basically gracefully terminating the connection between the two. So the ultimate point of this is that you have this breakdown Again, like we talked about SIN, sinac and ACK.

Speaker 2: 32:13 

You're going to have your FIN and your FINAC are going to be when you want to shut down the process altogether, and that's an important factor. So all of those are terms you need to be aware of as you're dealing with network scanning, because when you're dealing with a network scan, there are various pieces that come into play. So I'm going to go over a couple of very quick network scans that you may deal with. One is a SIN scan. Now, a SIN scan is known as a half-open scan and it's basically a network probing type technique. Now I will tell you that if bad guys are doing SIN scans they can come with depending on how broad they do it. They can be under the wire with a SIN scan, but if they are going in there with like blasting the network, then these will trigger a lot of alarms. A SIN scan will.

Speaker 2: 32:59 

But they're looking for if the target's going to respond. You know they're doing this TCP handshake. They're looking for someone who's going to respond with a SYN act and it basically means that the port is listening or it's open. So it's like you send out a SYN going hey, is anybody there? And it sends back oh, hey, I'm here, come talk to me. Then at that point in time the scanner will send a reset to basically close the connection before the handshake is overall completed. But they're enumerating, trying all completed, but they're enumerating, trying to determine what is out there and what potentially could they go after.

Speaker 2: 33:29 

Now, this method is a stealthy method, but it doesn't because it doesn't establish a full TCP connection. And again, if you're doing a very narrow band with a very small target subset, it can go unnoticed right, because there's always there's SYN communications that are going on everywhere. But the problem is is if it goes to be too large it would be. It gets into the position like a SYN flood where you're just filling it up with SYN communications on the wire. Then obviously you'd be discovered very quickly. But it's one of those pieces where your network scanning tool. If you're using SYN for enumeration, you want to keep it in very small subnets, very small areas, because you wouldn't want to broadcast it to a lot of different people, and hence that's part of the SYN scan.

Speaker 2: 34:11 

Now your TCP connect scanning. This works as a more straightforward method where a full TCP connection is established and attempts to do this three-way handshake by sending the various SYN and SYN-ACK packets and obviously ending that with an ACK. If it is established the port is open, then hey, they're great. They then, at that point in time, can potentially scan the system with that connection. Now, depending upon what is on that device, for some level of security systems a TCP connection to it from an unknown IP address could cause an alarm. So the full TCP connection, depending upon your environment, may or may not be the best option, depending upon if you're internal or if you're external and so forth. So those are just various aspects, but that is the TCP connect scanning.

Speaker 2: 35:00 

Then there's the TCP act scanning. Now this is used to map out firewall rules regarding filtered and unfiltered states. Now the scanner will send out an ACK packet to a target port and it looks for the response. If the port is unfiltered, it will receive a reset response. If it is filtered, there will be no response. So basically, if it's open, it'll send a reset to you. Now, this is not used to find open ports, but rather to understand the rules that are associated with these ports, and it can help the type also determine what type of firewall you're dealing with. And and one of the aspects you run into is, if you're trying to work your way through a firewall, you would want to. One of the key aspects is knowing who, what are the types of equipment that you're going against. You want to be able to fingerprint the different devices, both from a hardware standpoint and from a software standpoint, because then it can help you understand what kind of vulnerabilities may be associated with that potential system. So that's TCP act scanning.

Speaker 2: 35:55 

Udp scanning is used to identify open UDP ports and since UDP is connectionless, this scan sends out UDP packets to the target port. Now if it does that, if an ICMP port is reached, an unreachable error is returned. Okay, so basically, your ping right, your ping is your ICMP. If it's returned, then that port is closed. If there's no response, the port is presumed open or potentially filtered. And again, udp scanning I've never done it much myself, honestly, and because, mainly, it's not very reliable from what I understand, and so it's something to consider and plus, it creates a lot of noise.

Speaker 2: 36:34 

So, okay, xmas or Christmas scanning the Christmas scanning is named for as it would light up the various packet flag, as it sends a fin, a push and an urgent flags and it basically causes it to come light up like a Christmas tree. It sends a TCP packet with these flags to the target port, so the flags are set already on the TCP packet. If a reset is sent, is received, then the port is considered closed. If there's no response, the port is considered open, and they're used to infer a state basically of how the port is, whether it's a lack of response or how the port is open or not open, and they're used to infer a state basically of how the port is, whether it's a lack of response or how the port is open or not open. Like SYN scans, they're less likely to be logged but can easily be detected by modern IDS type systems. That is what they call a Christmas scam.

Speaker 2: 37:20 

So that's all I have for you today and again, the bottom line here is that we are here at CISSP Cyber Training and want to provide you with the tools you need to be successful to pass the CISSP the first time, and so I recommend, highly recommend if you are interested in passing the CISSP or taking the test you want to be able to go to CISSP Cyber Training. Go to the website. Look at all my free content that I have out there available for you. There's various things out there that you can use. You don't have to buy my product, that's fine, don't mind. I mean, obviously I'd like you to, but if you don't, that's good, that's no problem. You can get a lot of the free stuff that's there.

Speaker 2: 37:53 

It will help you walk you through what you need to know. If you do your own self-study with the book, it will walk you through those steps as well. If you are signed up for my email, you'll be able to get 360 free cissp questions available to you. That's just by signing up for my email list. You'll get that, and that is a great first step in helping you get ready for the cissp exam.

Speaker 2: 38:16 

If you're interested in taking a little bit step further, you can get one of my package deals and it will give you all of this information available to you. Uh, depending on which package you purchase to include my my blueprint, which walks you through step-by-step, the one problem I had with the CISSP I didn't know how to study for this test. I just didn't, and so I struggled and I failed the first time. So I'd highly recommend that you go and you look at it, consider the blueprint, consider one of the packages, and then what you can do is go through step-by by step. As long as you're methodical with your plan and you follow the blueprint, you will pass the CISSP. The part where this falls down is is that when you get busy with life and you decide you don't really want to study it because it's too hard, then you may not pass the CISSP, just to be honest. All right, so we're just letting you know. Have a wonderful day. No-transcript.

OUTLINE

Introduction to Vulnerability Assessments

• Purpose and Importance:
• Vulnerability assessments are systematic reviews of security weaknesses in information systems.
• They are crucial for preventing breaches by identifying and addressing vulnerabilities before they can be exploited.
• Process Overview:
• Typical stages of a vulnerability assessment, including planning, scanning, analysis, and remediation.
• Iterative nature of the process, which requires ongoing reassessment to maintain security posture.

2. Common Vulnerabilities and Exposures (CVE)

• Definition and Role:
• CVE as a registry that provides a unique identifier for each publicly known cybersecurity vulnerability.
• CVEs help standardize the way information about vulnerabilities is shared and understood across different platforms and systems.
• Example and Impact:
• CVE, such as CVE-2021-34527, detailing the nature of the vulnerability, affected systems, and potential impacts if left unaddressed.

3. Common Vulnerability Scoring System (CVSS)

• Scoring System Explanation:
• CVSS as a free and open industry standard for assessing the severity of computer system security vulnerabilities.
• CVSS scores provide a way to capture the principal characteristics of a vulnerability and produce a numerical score reflecting its severity.
• Components:
• CVSS score into Base, Temporal, and Environmental metrics
• Base Metrics:
• These represent the intrinsic qualities of a vulnerability that are constant over time and across user environments.
• The Base score is determined by analyzing the exploitability and impact of the vulnerability, considering factors such as the complexity of the attack, the need for user interaction, and the scope of the impact on confidentiality, integrity, and availability.
• Temporal Metrics:
• These reflect the characteristics of a vulnerability that may change over time but not across user environments.
• Temporal metrics include the current exploit code maturity (how easy it is to exploit the vulnerability), remediation level (availability of fixes), and report confidence (reliability of the vulnerability report).
• Environmental Metrics:
• These capture the characteristics of a vulnerability that are unique to a particular user’s environment.
• Environmental metrics allow the adjustment of the Base and Temporal scores to account for the security posture of a particular environment, such as the presence of mitigating controls, the importance of the affected system, and the potential loss due to a successful exploit.

4. Common Configuration Enumeration (CCE)

• Definition and Usage:
• CCE as a list of system security configuration issues that can lead to vulnerabilities.
• CCEs provide unique identifiers to system configuration issues to facilitate fast and accurate correlation of configuration data across multiple information sources.

5. Common Platform Enumeration (CPE)

• Naming Scheme Overview:
• CPE as a structured naming scheme for information technology systems, software, and packages.
• CPEs provide a standard method for identifying classes of applications, operating systems, and hardware devices within an organization.
• Example:
• CPE:2.3:o:microsoft:windows_10:1903
• Uniquely identifies the Microsoft Windows 10 operating system, version 1903

6. Extensible Configuration Checklist Description Format (XCCDF)

• Language and Application:
• XCCDF as a specification language for writing security checklists, benchmarks, and related documents.
• XCCDF allows for the creation, maintenance, and dissemination of security configuration information in a consistent and machine-readable format.
• Example and Use Case:
• Checklist for federal information systems under FISMA,
• It is used to assess and demonstrate compliance with specified security requirements.

7. Open Vulnerability and Assessment Language (OVAL)

• Language Definition and Functionality:
• OVAL as a community standard to promote open and publicly available security content, and to standardize the transfer of this information across the entire spectrum of security tools and services.
• OVAL definitions are written in XML and are used by various security tools to automate the vulnerability assessment process, ensuring that systems are compliant with security policies and are not susceptible to known vulnerabilities. 
• They are part of a broader set of standards that help in automating the vulnerability management lifecycle

How is a CVE Determined

• Discovery: A vulnerability is discovered either by an individual researcher, a company, or an automated system. The discoverer analyzes the issue to understand its impact.
• Reporting: The discoverer reports the vulnerability to the organization responsible for the affected product, or to a CVE Numbering Authority (CNA), which is an organization authorized to assign CVE IDs. For example, Microsoft is a CNA and can assign CVE IDs for vulnerabilities found in its products.
• Analysis: The CNA analyzes the report to confirm the vulnerability. They assess the impact, the affected components, and whether it’s a new issue or related to an existing CVE.
• Assignment:
  • Once confirmed, the CNA assigns a unique CVE ID to the vulnerability.
  • The format includes the CVE prefix, the year of discovery or public announcement, and a unique number (e.g., CVE-2021-34527).
• Publication: The details of the vulnerability, along with the CVE ID, are published in a publicly accessible database like the National Vulnerability Database (NVD). This includes a description of the vulnerability, affected products, and references to advisories or patches.
• Scoring: The vulnerability is scored using the Common Vulnerability Scoring System (CVSS) to determine its severity based on factors like complexity, impact, and exploitability.

TCP Handshake Overview

1.  SYN (Synchronize)

• The initiating client sends a SYN packet to the server to start the connection process.
• This packet contains a sequence number, which is used to synchronize the sequence numbers between the client and server.

2. SYN-ACK (Synchronize-Acknowledgment)

• Upon receiving the SYN packet, if the server is willing and able to establish a connection, it responds with a SYN-ACK packet.
• This packet contains the server’s own sequence number and an acknowledgment number that is one more than the received sequence number from the client.

3. ACK (Acknowledgment)

• The client responds to the SYN-ACK with an ACK packet.
• This packet contains the next sequence number, which is one more than the received acknowledgment number from the server, completing the three-way handshake and establishing the connection.

4. RST (Reset)

• At any point, if a device receives a packet that is unexpected or out of the current state, it may respond with an RST packet.
• This effectively terminates the connection attempt or existing connection, signaling that an error has occurred.

5. FIN (Finish)

• When a device wants to end an established connection, it sends a FIN packet.
• The receiving device responds with an ACK, and then it sends its own FIN packet, to which the original sender responds with a final ACK, completing the graceful termination of the connection.

6. FIN-ACK

• This is a combination of FIN and ACK used in the termination process.
• The device ending the connection sends a FIN to indicate it has finished sending data, and the ACK is to acknowledge any remaining packets received.

Network Scanning

TCP SYN Scans (SYN Scanning)

• Explanation:
• A SYN scan, also known as a half-open scan, is a type of network probing technique that is used to identify open ports on a networked device.
• It takes advantage of the TCP handshake process by sending a SYN packet to initiate a connection with a target port.
• If the target port responds with a SYN-ACK, it indicates the port is listening (open); the scanner then sends an RST to close the connection before the handshake is completed.
• Usage:
• This method is stealthy as it does not establish a full TCP connection, making it less likely to be logged by the target system.
• It’s commonly used for reconnaissance by both network administrators and attackers.

2. TCP Connect Scanning

• Explanation:
• TCP connect scanning is a more straightforward method where a full TCP connection is established.
• The scanner attempts to complete the TCP three-way handshake by sending a SYN packet, receiving a SYN-ACK, and responding with an ACK.
• If the connection is established, the port is open.
• Usage:
• This type of scan is easier to detect because it completes the connection, and the activity can be logged by the target system.
• It’s a reliable way to determine port status but is more intrusive than SYN scanning.

3. TCP ACK Scanning

• Explanation:
• TCP ACK scanning is used to map out firewall rules regarding filtered and unfiltered states.
• A scanner sends an ACK packet to the target port and analyzes the response.
• If the port is unfiltered, it will receive a RST response; if it’s filtered, there will be no response.
• Usage:
• This scan type is not used to find open ports but rather to understand the firewall rules applied to the ports.
• It can help in identifying the type of firewall and its rules.

4. UDP Scanning

• Explanation:
• UDP scanning is used to identify open UDP ports. Since UDP is a connectionless protocol, this scan sends a UDP packet to the target port.
• If an ICMP port unreachable error is returned, the port is closed; if there is no response, the port is presumed open or filtered.
• Usage:
• UDP scans are typically slower and less reliable than TCP scans because the lack of response can be due to packet filtering, rate limiting, or the port being open.

5. Xmas Scanning

• Explanation:
• Xmas scan is named for the “lit up” state of the packet flags, as it sets the FIN, PSH (Push – Immediate), and URG (Urgent - Immediate) flags, lighting the packet up like a Christmas tree.
• This type of scan sends a TCP packet with these flags to the target port.
• If a RST response is received, the port is considered closed; if there is no response, the port is considered open or filtered.
• Usage:
• Xmas scans are used to infer the state of a port based on the response or lack thereof.
• Like SYN scans, they are less likely to be logged but can be easily detected by modern intrusion detection systems.