CCT 042: Security Testing and Compliance - CISSP Exam (Domain 6.2)

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. All right, let's get started, hey y'all, sean Gerber, with the CISSP Cyber Training. How's everybody doing today? I hope you all are having a wonderful day. Today is a beautiful day in which to talk Kansas. We have gorgeous sunny skies and around 80 some degrees, so it's very, very pleasant. And as the summer marches on, it is an awesome time, because what happens is is it gets very hot. When you go outside, you melt. That's out of nowhere you're at around the globe, but in Wichita it's actually quite pleasant for about two days out of the spring and about five days out of the fall, and then come the summer. You actually cook, and in the winter, winter is actually pretty pleasant, but the summers are quite warm. So we're getting into the summertime here in Wichita, kansas, and so it is amazing. Yeah, right, so, but things are good. Things are good. Here We're going to be talking about some great things that you're going to see as it relates to the CISSP, and we're going to be talking about today domain six, around security assessments and testing and the various fundamentals that are associated with it. Now, coming from my background as a red teamer from a previous life at the military, we did a lot of security assessments at four individual facilities as well as for specific locations, and the assessment aspect I thought was when I first did the red teaming, that was how you did security assessments. But then I'm getting into corporate America. I realized no, that's a little bit different, because corporate America does it a bit differently than you would do with from the military standpoint. So we're going to get into a lot of those aspects, talking from the military point of view as well as from the corporate point of view, and you'll be able to see the two differences between them, but they both work in the same manner. The ultimate goal is to determine what are some potential vulnerabilities that you may have within various systems and then provide mitigation, controls or potential fixes for those vulnerabilities. I mean, you're just basically testing the battle space, testing the areas in which bad guys could operate, with the hope that you can actually fix these problems before the bad guys see them and will then try to leverage them. So was beginning to security assessments. First thing we're going to talk about is a vulnerability assessment. So you're probably asking yourself what exactly is a vulnerability assessment? Well, these are the process of identifying and quantifying vulnerabilities in your actual information system or network infrastructure. So you have various tools that will help you to identify this. You can have scanners such as QALIS, there's Netspark or so on and so forth, depending upon if the vulnerabilities are within your business network or with they are outside and external to your organization. But the ultimate goal is that you want to identify what are the potential vulnerabilities in these systems so that you can go and impatch them. One thing you'll find from doing scanning is you may find a lot of vulnerabilities with certain systems, and there may or may not be things you can actually do to them. For an example, you may have a really old 2008 system that comes up that says, hey, there's all kinds of vulnerabilities with this. You then have to make the decision well, how do I update these 2008 devices? Do I turn around and just basically reinstall it? And some of you who are listening may be saying, well, heck yeah. Why wouldn't you do that? Why would you not just put a brand new operating system on these systems and get them up to speed? The corporate I mean the military would say, yes, you should do that at all costs, and the military in many cases has lots of money so that they can do that. When you get into corporate America, it isn't quite so simple, because the simple fact of it is these systems might be running various complex aspects of your business where you just can't go and replace them. So, for example, say, you have a 2008 server that is running a power generation system, and this power generation system is what runs your facility. Well, you're probably going. Well, why is it so old? Well, it costs money to do these things. You can't just go out and buy a new 2008 server. You have to buy the appropriate software that goes with it. And so this is why a lot of the bad guys are able to have so many targets of opportunity because companies just can't go out and start upgrading all of these old systems just at a whim. They just can't afford it. So this is why it's important for you as a security professional, and why risk is so important that you must understand the risk of your company. What is their risk tolerance? How much are they willing to accept risk? And then you have to understand the actual vulnerabilities of those systems so that you can give proper recommendations on what they should do. Now, that was a little bit of a long discussion, but I kind of want to set the context that, as we go through this, we're going to talk about various potential devices that may or may not be upgraded, and you might be asking why do we not just upgrade them everywhere? Now, there's times when you need to do that. You need to say I'm sorry, but this system has to be upgraded no matter what. But there are also times when you may have to accept the risk. So that's just something you're going to have to manage and have to work through. So when I do these vulnerability assessments, you're looking for something to identify the weaknesses. Now, these potential weaknesses are vulnerabilities in the systems. That might be the networks that are tied to It. Also could be the applications that are running on these various systems. So, like I mentioned before with the PowerGen, you might be able to upgrade, say, the server is one of those that I could upgrade it tomorrow, but the application itself is so old and you can't buy the new application because maybe the company went out of business And the only thing you have is this application And to go find something on the market. It goes from being a $100,000 project to a $1.2 million project. So that's a big factor you have to work through. So the other thing about when you identify these various weaknesses is it does allow you to be proactive when mitigating the risks. Now, if you're doing this in a correct manner, we talked about various systems that you can't update because they're so old. If you do vulnerability scanning or vulnerability identification, you may go. You know what? I had this 2008 server and my business is telling me I can't do it now, but we're stressing to them that it has to be done within the next year and a half to two years. So you say, okay, let's define what that is, let's work to fix that. Then you can get it on the system, on the leadership's understanding. You can get it in front of them immediately and say, okay, in the next two years we're going to plan on upgrading this. So we'll start a project so that you know in the next two years it's going to be upgraded, and that's where you're more proactive with changing out these various devices that are old. So the important thing about doing these vulnerability assessments is to help plan for businesses, to help also plan for giving you upgraded options And then also just to understand the overall risk within your environment, because by knowing these various systems you can understand. Do I have a big hole? You may have these devices that are maybe within your process environment. So we talk about on the podcast a lot between the IT and the OT environment, where your IT is your business environment And that's where all of your people operate on a daily basis. Your OT, which is your operational technology space. That is where a lot of the manufacturing or device smaller devices operate. We call them PLCs, which is your programmable logic controllers, but this is where the robotic armworks is down there in your OT environment. Well, you may have a situation where there's old servers that you can't update or you're just not able to right now, but you can segregate them from your network, from your business network, within various networks inside your organization. So we talk about one of the aspects I recommend with the CISSP is that you have an understanding of network fundamentals, not that you have to be a really strong swimmer when it comes to IP or with IP addresses, subnets and so forth. But you need to understand the fundamentals around it, and one of the fundamentals is the fact of can you segregate these networks off? Can you put them what we call a virtual LAN or a VLAN? If you can do that, that is very helpful when you find these older systems, and that deals with the overall risk management of these devices as well. Now, compliance requirements there are many regulatory frameworks out there that do have standards on regular vulnerability assessments. So if you fall within one of these buckets where your organization has to have these vulnerabilities assessments, then you just have to do it. One example of that would be CMMC, which is your Cybersecurity Maturity Model Certification. Now, that's here in the United States and that's for anybody that is going to be operating with the Department of Defense or with the US government. And if you're a contractor or a subcontractor, you have to meet CMMC guidelines. Now, these guidelines will determine that there's might be times when you don't maybe have to do one vulnerability assessment, or maybe you just have to annotate that you are willing to do one, or that you do one via just looking at the devices. They have various different tiers to this, but the bottom line is they want you to do it. If you are meet another tier where it says you must do it every year, then that is something that you'd have to comply with. So security assessments are just a way for you to understand the potential vulnerabilities within your organization. Now, the next topic we're going to talk about is penetration testing. Now, penetration testing is something that I used to do when I was a red teamer, used to do pen test, and a pen test, or what they typically call ethical hacking. It involves simulating real world attacks on systems and networks, identifying the security risks that are associated, the risks and the weaknesses that are associated with these various devices and systems, as well as then what are some effective security controls you can enable to help with the situations. Now, when I was a red teamer, we would go out, we would potentially find a target. We would then do some reconnaissance. We would decide what is our target. We would then launch an attack against a target, from phishing to all kinds of aspects that you would do to try to gain access to this environment. By doing that, we would target specific individuals, specific organizations, and you would look for? what can you? what access can you get? Now, this is no different than what the foreign governments are doing at this moment. There's plenty of foreign governments that are constantly pen testing, and it's not really testing. It's more like they're just trying to gain access, but they're doing this all the time to US based or governmental systems. So I'm coming from the United States standpoint, but, depending on the country you're in, there are people that are continuously attacking networks, and a perfect example of this are the Iranians, and the North Koreans are always attacking networks, no matter if you're Chinese, you're Russian, you're Venezuelan, you're US, you're Mexican, doesn't matter. They're always going after it because that's, in many cases, a form of income for them. But these penetration tests are things that you will hire somebody to do this for you, and they will act like an ethical hacker. The point is that it's a the thing with with a pen test to consider is is it's like a surgical strike? It's looking for one specific weakness or a couple very specific weaknesses to gain long term access into your network. They don't scan for everything under the sun. They look for very specific and targeted areas on where they can exploit and then how they can gain deeper access within your organization. So if I would go after a web server, i would specifically go after vulnerabilities with that web server. Once I got into that web server, i would look how can I gain access deeper within the organization, to the point of I'm waiting for an administrator to log into that that web server, and then I would steal that person's credentials and then it would give me long-term access into that environment. Now it's not that simple. There's a lot of controls that are in place to help mitigate this issue, but the bottom line is that there are numerous ways to get into an organization, and so the pen tester is looking for one key the highest risk items that you may that may get leveraged against you. One example would be your AWS accounts that are sitting out there and that you have available to people. These AWS accounts are, in many cases, open, and so if you stand up AWS, your external network, and you don't properly secure these environments, bad guys or gals can go in there and gain access through these AWS environments. Another way that also folks can gain access is through API connections and these APIs application programmable interface these are great web methods for people to gain direct access to the data that might be within your organization. So there's multiple ways in, but a pen tester will look for those potential exploitable weaknesses and they go. This will go beyond a vulnerability assessment because they're trying to exploit them. They're not just trying to say, hey, you have a 2008 server, you need to go fix it. They actually go after that 2008 server and they try to exploit it to determine what they can gain from it. It's also designed to validate security controls that you may have within your organization. These security controls are there to decide or to help dissuade real world attacks, and so therefore, they're designed to determine if these real world attacks would become successful. It also helps you understand your incident response process and the preparation around that. So, for example, say I do a, i don't tell anybody. Well, you tell the right people so you don't get arrested, but you do a pen test. You hire somebody to do a pen test to your organization, you know they're going to do it, and then you wait for them to do it. Now, once they do the attack, you wait to see at what point do they do, the alarm bells go off, and then, if the alarm bells go off, then you determine okay, so the bells went off. The alarm was triggered. Now, run my incident response process, and if I run my incident response process, is it going to be successful? Where do I find the gaps in doing so? So that helps you with just really diving deep into that. Now there's various security testing methodologies, as we talk about, and these methodologies are basically just a structured approach into the frameworks for conducting a security assessment and testing. You want to follow these security methodologies, because the reason is that follows can, it gives you consistent best practices as far as how they should be completed, and it also will help you ensure that your coverage is the most broad it possibly can be. So if you don't as an example, let's say, you've never done security testing for your organization and you want to do that. Well, you have knowledge based on your organization and how they could potentially leverage a back. I could leverage against your organization. What you want to do, though, is you don't really know how to do it. Well, if you just go and try it, your methodology will be probably a bit biased, so you want to be able to follow something that is very planned out, very programmatic, and therefore it forces you to follow a set of rules follows you to go down a certain path. That is what you want. These various methodologies will help you stay down that specific path. So, again, it's important that you do follow those when you're doing a test on your own, especially Now, security control testing. Now there's different types of testing that can happen. You use a manual test and then there's an automated test. Now, automated tests do involve the use of software tools to perform perform the security assessments that they test the automatically by. Maybe the specific situation where you want to do a ping sweep. It'll do go out and ping devices. You want to have something that will maybe potentially connect to them through. We talked about the TCP stack with your OSI model. If it is a sin, you want them to see. If it'll actually connect to the device itself, will build, will it do a SINAC, will it actually connect them specifically these tool for you to manually go out and do that against all these various system. It will take forever and you won't do it. So the point is you want an automated solution to help you do that. Now there's other tools out there as well that will scan and look for all open ports, and these are we call vulnerability scanners. You have Nessus, open boss, qalus. You have various systems that are there that will be scanners that are designed specifically for scanning networks for vulnerabilities. You also then have what we call a web application scanner. Now, these are looking for the web applications that are out there facing the internet, and this is something you really want to do. If you have any internet facing activities, you want to ensure that there are some level of scanners that are out there. You're looking for common security flaws and vulnerabilities with these systems, and there's Burp Suite, accux, aosp. They have a ZAP tool, which I think is a free tool, so there's various web application scanners that you can use right now that will be able to be helpful in allowing you to determine what's within your environment. There's also code review tools. These tools are designed to look through your code review for potential security vulnerabilities. Now, within the CI CD pipeline, which is your continuous integration, continuous deployment pipeline And what you'll hear about that more when we get into the DevOps aspects of your CISSP, the main point around that is that it will automatically go and look at your code for any known security vulnerabilities that might be out there. Now you may have this is there's products that are you can purchase that will do this, or there's enough products out there that you can actually build this product on your own. You don't have to have a specific tool to do this. If you're really good with your your coding skills and you're good with integrating various systems, specifically like within what's in AWS, you have the ability to give yourself that capability without having to go out and buy expensive code review tools. Now the downside is is, if you don't have those skills, then there are tools out there that you can purchase that will do this automatically for you. Now we talk about in the CISSP a lot And on the our my website up CISSP cyber training a lot around the talent and what, how hard it is to find security talent. Well, having tools that are automated is an important part of all of that. So, again, you want to make sure that you have a good plan as it relates to code, code and code reviews if you're doing development work within your organization. The other part is is there's there's configuration compliance tools. Now these are security content automation protocols. Okay, these are different scanners to ensure that you have your devices meet a compliance requirement. So, for example, if you have a, let's say, a requirement with the government that you have to meet a certain certification, then there might be. You might have to use these scanning tools to help you ensure that you meet those baselines or standards. It's just a configuration issue, and so, therefore, those that you might have different vulnerability scanners available to you depending upon the situation that you may have to get into. One aspect I know with a product that you're dealing in websites is around the what is the name of it? It's it's for the American Disabilities Act. Yeah, ada. The American Disabilities Act requires that your websites have the ability for people to go and switch between various capabilities. So let's go for an example. If I have a web page and I am visually impaired and I can't see the web pages, there's a little tiny font. Well, actually, i am visually impaired because I'm an old guy, but, beyond being old and now needing glasses, say, i can't see really well. Well, there's a product. If you look down the lower left or right of the web page, in many cases you'll see this this person is a. It's a pictorial of a person with his arm stretched out And you click on that And what it'll do is it'll allow you to make changes to the website as you're viewing it. It'll blow up the font. It will actually talk to you. It does different aspects to that. Well, this is based on the ADA and this is where you're from. Around the world, you may have something very different, but it's then the ADA. But the the American Disabilities Act is a design specifically for people that have disabilities, that they can go and click on sites, and so that's a compliance requirement within the United States that you have this enabled on your site. Now, not everybody has to have it enabled, but many large companies will do this as a benefit to people, and there is some requirements around doing this for these organizations. So that's what I mean by compliance tools. Now, when you're dealing with manual testing, the manual testing involves a human tester actively testing these systems. Now, this means this will start, like we talked about, with code reviews, as is someone manually going through and looking for coding errors and best practices. Now, the interesting part is now that we've brought into the world these machine learning models that you're dealing with chat, gpt and so forth This is actually going to help dramatically around some of the coding errors that you're going to run into, because it's going to provide better code. The downside is that coders are going to become potentially could become laxadaisical and not really understand their code, and you let chat do that for them, and because chat will provide you the code. The problem is is that when you start integrating the various code streams that your chat, gpt or whatever version will provide, you could end up still having vulnerabilities, which you will, and what ends up happening is the developers do not know how to fully rectify the problem. So, code review in a manual process I don't recommend it unless you have very small amounts of code, because humans are going to make mistakes. They just are manual configuration reviews, like we talked about with the automated tools. Having an automated tool that does it for you, you can manually go out and can and check the configuration of your systems. Now, this is not a bad thing. You should probably understand how your systems work, but it will. It's individually you're going to look at. If you're looking at only a few systems, you know what that'll probably work out well for you. If you're looking at a lot of systems, the manual part is just not going to work. It's going to be really challenging. The other part of manual testing is penetration testing. That's a very manual hands on type of activity You won't. You can't I mean you can do aspects of penetration testing that are automated. However, you want to avoid that because if you do an automated tool when you're doing a pen test, your ultimate goal on a pen test is to stay low and slow. You do not want people seeing what you're doing. So if you don't want people seeing what you're doing, then you're going to have to actually do it by hand. But an automated tester may make mistakes and therefore highlight your activity. So in most cases during a pen test, you do not want to run an automated scan by any really stretch of the imagination. Social engineering is another manual type of testing where you're actually attempting to manipulate individuals by disclosing sensitive information. Did this all a long time ago when I was on a red team. My name was Jennifer, i was very attractive and I've mentioned that in the podcast before. I prided myself on my attractiveness and it was very good. It would get a lot of young men that would decide they hey that they want to talk to me. And when they wanted to talk to me, guess what? they gave me information. So that is social engineering and you can do that. I don't recommend you do that unless again, i'm caveatting all of this you have proper get out of jail free card type of activities. You've been sanctioned to do so by your organization. Do not do this on your own without being sanctioned by your organization. If you do that, you will go and break big rocks into little rocks and you will go to prison. So don't do that. Bad idea, just bad idea. Use your powers for good, not evil. If you use them for evil and you get caught, your goods not good. So that's the problem with being in this space. It'll be very lucrative for you to want to do your skills for evil. Do not recommend it. Lots of downsides, not many upsides. Security architecture review Again, this is another part where you will look manually. You'll look through here to determine if there's any design flaws, weaknesses or potential gaps in security controls, and this is all done from a manual type of basis. Now there's various documentation that will be required when doing security testing. You're dealing with a test plan. This outlines objectives, your scope, your methodologies, your timelines, how are you going to do things? You'll want to have that documented because if you're going to do these testing, you're going to need senior leadership buy-in. You're also going to want to have the results plan. How are you going to get, provide these detailed results for the findings and what you see, the vulnerabilities, the weaknesses, all of these aspects. Now I will tell you that, whatever the results are, your testing plan, i don't think, needs to be necessarily secured, but your results from your testing plan, they should be properly secured because once you're done with this, you are now leaving a roadmap to somebody on saying, oh look, their web server is vulnerable, that's not a problem, let me go in and abuse it. So they will do that. I had that. That was a really poor, i don't know what I was trying to say there. That's the mini me I guess, version. But the bottom line is to hide your results, but don't hide them to the point where you don't do anything with them and stick them off on a SharePoint site somewhere. You actually need to do something with them. You also your test procedures. You need to have those defined in a step-by-step documentation, especially if you are doing this yourself. Now, your test procedures may be, you may understand what they are, but you need to really define how do you want to do your testing Once you better understand what you're trying to accomplish. And then two, we make mistakes. So if you have them defined and the procedures are written out, it's less likely that you're going to make a mistake. And if you do make a mistake, you're going to have to do that, or something bad happens, at least you know, or someone's going to ask you hey, i followed these procedures, this is what I did versus. I just kind of made it up as I went. Not a good idea, okay, not that, especially when you're dealing with scanners. Just so you know, if you run a scanner against a foreign entity, it can be considered an attack and it has downsides. There are some bad ramifications that can occur. So you want to avoid attacking a foreign entity with a scanner. Don't do it. So make sure your IP space is square. Do not scan IP spaces that you are not fully 100% confirmed that that's what you want to scan. And then your test reports. These are a provide an overview of your testing process, your methodologies as well as everything you're else doing. So these are pretty good. Now, when you're dealing with considerations, like I just mentioned, there's some things you have to consider. One is your legal and ethical considerations. You need to comply with all laws and regulations. You can really get yourself in trouble if you don't, and you also need to consider the ethical situation around. This is is it must, you must conduct these activities in with ethical boundaries. It's like I said, mentioned before. You can go evil on this real quick and it can get really ugly, really bad, and you start scanning some places you shouldn't scan. You could be in a world of trouble that you really can't get yourself out of. So you need to make sure that you have this in place. If you're running a company that does this say, you decide, hey, i'm going to go out and start creating a company that goes and scans networks. You better make sure that your T's and C's are good, your terms and conditions and you've had legal counsel on how to do this. It can go ugly really quick. You also know there's some compliance with laws and regulations as it relates to compliance requirements around, maybe through GDPR you have. You must have your security control practices in place with these various compliance requirements. We kind of talked about this before PCI DSS, which is the payment card industry data security standards. You must have some level of this being done. You must, you must be able to demonstrate that. You must also have knowledge of the governing security testing activities within your jurisdiction, depending upon where you're located one in the country, but to the state what you're allowed to do. So in the United States, we have states that we live in, so the US government has their requirements. Well, the state of Kansas, where I'm in, has its requirements. Those two can be in conflict and you potentially could be in trouble with both of them. So you want to ensure that you don't do that. Okay, you want to make sure you be careful around that. Last thing is you also want to get into your reporting this out to senior leaders. You want to be clear and concise. So, once you go through this process, you want to understand what's happened. You want to be tell them how this has occurred. You want to have documentation for them and you want to give them an impact assessment of how could your business be affected by these vulnerabilities And by doing an impact assessment of how this could impact your organization, it can provide them guidance around what they need to do, but it also gives them a document to hold people accountable for And it helps provide them an understanding of what they actually see. You've got to understand that, just like I'm. I went to school to be an airline pilot, so I can talk to you about coefficient of lift and how that works and how thrust works and various aspects of the landing process. However, when it comes to dealing with finances, i don't really understand financial aspects. So if I talk to a senior leader about coefficient of lift and they understand financial aspects, we're going to we're not going to get to understanding. So you need to provide this in a clear and concise report that is, in the terms that they understand, and you need to provide mitigation strategies for them. Don't just tell them that the baby is really ugly. You know they just had a baby and your baby is terribly ugly. Well, okay, that doesn't solve the problem. You want to tell them how to make their baby pretty. How do they give their baby hair? How do they tell put lipstick on their baby? That's really sick actually to put lipstick on a baby, but you could do that. The bottom line is you want to have the ability to tell them that how to fix their environment and how to make it better. Okay, the last thing we're going to talk about is security, testing, best practices and what you should do around those topics. So now, when you're dealing with this, this is going to be how, why would you do a security testing So one? you would need to create an isolated and controlled test environment. Now, what that means is you may be testing your production systems, but you want to have a controlled process. You don't want to go out and scan your entire subnet. You may want to just pick very specific areas within your subnet to scan or to work through. So you want to have a controlled process. Now, depending on the size of your organization, you might want to do the whole thing. I don't know, but you need to have this defined and documented. But you want to understand it because these scanning situations can impact your production. So, as an example, if you scan down within your process environment, those devices don't typically like scanners because they're older, and if you do a SIN or a SIN Act to some of these devices, it can cause them to tip over or basically stop working or reboot, and if it does that, that could cause an impact to your production of your company. So you want to have a really good plan on how you do that. You also want to test real-world scenarios. Don't just make up stuff. You want to understand what is the threat doing right now and how can I go and emulate how the threat is attacking these devices? Because if you don't use real-world type scenarios against these systems, you're kind of just going hypothetical. Or maybe you're using really old attacks against brand new type systems. Well, they're not going to be effective. So you need to make sure that it does match what the world is doing. Now, if you have really old systems, you want to make sure that you run older type scans against those, because that's what could potentially cause them challenges. If you run new scans against them, they may not understand it and it may not work. So you need to make sure you do have an understanding of your environment and what kind of scans you're going to do towards it. You also want to have various experiments that you want to put in place. These experiments will enable the testers to manipulate the variables and determine the best outcome for the systems themselves. So there's kind of some of the key benefits. Now, again, we talked about production environments. You want to be very careful which ones you do, and then you want to make sure that everybody's aligned, from leadership all the way down. What is your target market? Where's your target that you're going after? You want everybody and you want to communicate and over communicate this problem. Now here's the other part about having a very defined or not a problem. But there's another reason you want to have a very defined process is because, say, for instance, you decide you want to do a testing on Monday, tuesday, wednesday and then all of a sudden on Monday, all kinds of things start happening within your environment. If you haven't defined what you're testing and all of a sudden things start happening, you're going to get blamed for it. Now, i'm not talking about blame in the fact that, well, you don't want to get blamed for stuff, but if you don't have a defined scanning environment and say you're not even scanning those areas, you will be held accountable for things that are not your problem, not your fault. It will be a bigger problem with something else. By having a defined target. When things do happen, you can say no, i am actually working specifically in this space, it's not me, it's not me doing it, it's something else. That's why it's really important that you have that approach. you have alignment and you have a good approach by which you're providing, going forward. We talked about securing the test data. It's really important that you have that in place, that you ensure that you protect it from the system, because it is a way for somebody to gain access to your environment. One thing you might want to consider with the test data which I don't necessarily agree with, but I've heard people talk about this is anonymizing and masking of the data. The problem when you do that is it loses some value and then it makes it really hard to help manipulate the system. Now, if you're dealing with a highly classified environment, you may want to do that, but it isn't something I would plan to do with your normal type of run-of-the-mill scanning on most companies, unless you're in a government where you're highly classified and you have to. It's highly important that you do that, but anonymizing and masking, i think, just kind of gives you some. It's not the best in my mind. You want to make sure you meet your data privacy regulations as it relates to people. If you're scanning for individual keywords or individual data, are you accidentally sucking up information? that is specifically realm privacy? You want to avoid that. And then you want to talk about when are you going to go back and do retesting. So are you going to do this on an annual basis, semi-annual or once every two years. So you want to plan that out and then you want to ensure that everybody's aligned with that. But you want to do this based on emerging threats that you're seeing, and if these threats are contrary or much different than what you've tested in the past, you want to make sure that you adjust your testing plan to meet the upcoming threats that you're dealing with. Okay, that is all I have for today. I wanted to let you know this is you'll get all of this. Access is for you at CISSPcybertrainingcom. You can go out there, you can grab it and you can look at it, and the videos will be available on YouTube at some point here, but you can get them immediately within a very short period of time on my site at CISSPcybertraining and you can get all the information you need. This is I want you all to pass your CISSP, get this thing done, and the content I gave you here is a great way for it to help you get a better understanding of the content so that you can pass the CISSP the first time or the second time, depending upon your situation. All right, have a wonderful day and we'll catch you on the flip side, see ya.