 All right, so let's take a peek at why vulnerability assessment. Module 1, over you here, we're going to be looking into what is a vulnerability assessment. We'll then hop into compliance and project scoping, see what's involved there. See also how we can assess our current network concerns. Again, keep in mind when we're talking about network equipment, this could also be vulnerable to different types of attacks. So we need to check some of those out. We'll look at some network vulnerability assessment methodologies that we can use. And we'll look at what we call the policy review, also known as the top-down methodology and the technical, also known as the bottom-up methodology. So when we look into what is a vulnerability assessment, simple definition is this is a vulnerability assessment is the process of identifying, quantifying, and prioritizing, also known as ranking, the vulnerabilities in a system. The basic process involves a diligent analysis of the target system for any weaknesses, technical flaws, or vulnerabilities. And the vulnerability from a perspective of disaster management means assessing the threats from potential hazards into the population and infrastructure. It may be conducted in a political, social, economic, or even environmental fields. You can also check out full definition at the wikipedia slash wiki slash vulnerability underscore assessment. Now here we look at the vulnerability assessment. It's the systematic examination of a system to identify those critical infrastructures or related components that they may be at risk from an attack and the determination of appropriate procedures that can't be implemented to reduce that risk. The systematic examination of an information system or product to determine the adequacy of security measures, identify security deficiencies, provide data from which to predict the effectiveness of proposed security measures, and confirm the adequacy of such measures after implementation. And this is taken from the Infosec dash 99. Now when we look at the benefits of a vulnerability assessment, well, first of all, for us to figure out what we have, once we run that vulnerability assessment, we're able to then figure out what we're actually vulnerable to. So with that, we can intelligently manage our vulnerabilities. Now keep in mind some of these vulnerabilities are not going to be critical, meaning that let's say you have internal applications and so forth that you're running off of in your environment. And it requires you to have a certain version of Java to be able to run properly. So it has to maybe be an older version. So keeping in mind that as long as you know that there are vulnerabilities for that Java, you can set countermeasures in place to prevent them from being compromised once a user actually connects to the internet using that browser or something to that effect. So we're able to more intelligently manage those vulnerabilities, again, because sometimes we're stuck with those. We can't really do much about it. We actually have the ability just to do nothing. We'll also avoid cost of network downtime. Again, if you have devices that are on the network and you don't have to take them down, due to you intelligently managing your vulnerabilities, that might be a good thing. So you're avoiding the cost of network downtime after an attack has been occurring. So because you have maybe some vulnerabilities, you have gotten attacked. Again, it all kind of works hand in hand, doesn't it? Now pre-check to see whether you meet regulatory requirements and avoid fines. Again, this depends upon your regulatory requirement. If you're either SOX, HIPAA, or whatnot, PCI compliant, all those types of things kind of come into play and you can actually use vulnerability assessment to see if you have like a regulatory requirement that you may be missing. You can also preserve the corporate image and customer loyalty. Justify security investments. Again, this might be a good day to go back and say, hey, we need another $150,000 for this piece of equipment and such. So we'll talk about more about some of those things later and how we can calculate some of those things as well. And also satisfy prerequisites for cybersecurity insurance and then conduct penetration tests if then needed. So when we look at what are the vulnerabilities, well, keep in mind the vulnerabilities here are undocumented problems or errors that can be used maliciously to make the system perform in a way that was unintended. We have also undocumented vulnerabilities in all systems. Now trying to test for unknown will be a challenge. Now a technical NVA, here referring to the network vulnerability assessor, will only look for those holes that have been published. Now the main purpose of vulnerability assessment is to find out what systems have the flaws and then take the actions to mitigate the risk. Again, this will happen the majority of the time. However, if you're running those and you're trying to test for the unknown, then you're going to have to find out what the vulnerability assessment is. However, if you're running those internal apps, you may not have another option to mitigate those risks. So for that, you have to put other countermeasures in place, such as maybe using other browsers to browse for the internet, using probably a user that has limited privileges on the system and so forth might be some of those countermeasures that you can use or just not have them connect to the internet and then have them use a general purpose machine or a kiosk or something to that effect to then connect to the internet with and so forth. So there are definitely some ways to do it. Just keep in mind that at least from my, when I've seen out there is the companies that do get compromised are the ones that have their users be local admins on the machines, which means they can install anything on those machines and then they use the same browser that they use for the internal network, also for the external network, which could cause some issues, especially if they're using outdated versions of Java or something to that effect. Now we look at the security vulnerability lifecycle, we can see here that the product ends up getting shipped once it's been completed, hopefully. Then what happens, vulnerabilities generally will get discovered. Now the vulnerabilities would just get discovered by the users of the products a lot of times. And now of course the continued development of the product itself will also hopefully expose some vulnerabilities that the vendor can then put together. Once those are found and discovered, the components are then modified. And then with that, a patch is released. And then of course, the patch is then deployed at the customer site. Now compliance and project scoping, regards to here, here we're developing the scope of a project as an early work where we decide what boundaries we will set to limit the work of the project. Now these boundaries and a network vulnerability assessment projects are gonna be defined by what physical limits will exist there. What parts of the organization will be included? How much, if not all of the network will be reviewed? How many people will be consulted? And how many people will be working on the project? These are all good questions to ask. Most failed projects come to grief because the scope of the project was poorly defined to begin with. Or because the scope was not managed well and was allowed to creep until it was out of control. Now if we're going to manage the project well, then setting the scope for the project is gonna be key to success. Now setting the scope for the network vulnerability assessment project means that we need to start with a project overview statement and then develop the project scope document. Now the project scope document consists of elements of the project overview statement, a task list, and the documents that set limits on the task list. Now the task list and the documents are then set limits on the tasks, which form the basis of our project plan for the network vulnerability assessment. So when we look at the project overview statement, it should be generally one page, simple end statements, clear net objectives, and should contain things like the project definition, which generally is just gonna be a short description of the purpose of the project that must contain statements of the benefit that doing the project will bring. It should have a project goal, which basically has one or two sentences that states what problem or weaknesses the project will address. We have objectives. There should be a short list of objectives that have to be met to reach the project goal. Some type of success factors, such as quantification of the benefits of doing the projects. Now for your network vulnerability assessment, the success factor can be detailed knowledge of the weaknesses within the organization's network, such as the knowledge here is gonna be the benefit. And some type of assumptions, such as details of the strengths, weaknesses, opportunities, and threats involved in the project, but simplicity gonna be here, a big key. So here we can see a project overview statement. Again, here the most failed project come to grief because the scope of the project was poorly defined to begin with or because the scope was not managed well. So here you can kind of see what we have. We take this down, again, one pager, we have the objectives, success factors, with the strengths and weaknesses, opportunity, and threats, all within. Of course, we're bringing it down to project manager, title, name, and so forth. Everything should be defined, again, to assist in that overall process of bringing that scope together. Now assessing the current network concerns. Here we need to take a look at different types of vulnerabilities that we have. Specifically here, vulnerabilities in the service. And here we're mentioning that the web services are notorious, but keep in mind, a service can be anything like your SMTP service, for instance, or your HTTP service for your web servers. We have NTP for your network time protocol service. We have Telnet service. So we have different important numbers and such that we can use that will tell us what services are running and depending on those services, they could have different vulnerabilities. We also have vulnerabilities in the hosts OSs. This is gonna be the host operating systems, your windows, your Unix, your Linux, and so forth. So the operating system itself could definitely be, especially on the server side, in this case too, could be vulnerable. So we made to make sure that we have latest updates and security patches and so forth installed. However, this may not always work. However, this might not always work because we may not be able to update our updates because if we do, it may cause something else to break on the operating system, or at least how it communicates with other clients and so forth. Then we have, of course, vulnerabilities within the protocols that are being used. So depending on the type of protocols used, they could again have its own vulnerabilities. Now if we're using IPv4, most likely we are, then we have some vulnerabilities there that a lot of times when we're transferring traffic, you know, when we're trying to access another location, another server, and so forth, that a lot of times the data is transferred in clear text, right, so some of the things we need to look into. Also, vulnerabilities in the clients themselves. And again, we're talking about here the database servers, the mail servers, and so forth. We're talking about the workstations that are being used and the applications that are on top of those and so forth. So these would be the vulnerabilities in the intermediate systems and such. Again, there's lots of different levels that we really need to look into rather than just saying, hey, I have my operating system up to date and I have a firewall and Ivar's product, I'm protected. But it's a lot more than that, right? You always have to look at security and layers, right, as what we refer to as the defense in depth, where it goes not just in the operating system itself, but also the applications that are on top of the operating system. Also, how the data is being secured on the hard drive, you know, is it being encrypted? Are we setting permissions on the NTFS permissions, for example? You know, little things like that. So again, just know that it is multiple things could, of course, be the hardware itself, the firmware and things like that, that could also be vulnerable to attacks. We just need to be able to have a bird's-eye view of different items that could be going on there. So when we're looking at vulnerability in networks, here we have some of our network equipment that we may be using, such as our hubs. And the simple thing with the hubs is the hubs will generally allow any traffic through. So any kind of broadcast traffic, anything, anything. And it is easily sniffable, and hopefully you're not using any hubs anymore. Now, we also have switches out there that we'll be using most likely, and they do have vulnerabilities. Now, they will not broadcast the traffic through all the ports and such that it has. However, if your switch is vulnerable to an attack where we can over flood what's called the CAM table, your contact address from a memory table. It means that we can then make this switch act like a hub, which then means we can capture all the traffic that is on the switch network and so forth. And we do this through what's called a MAC flood attack. And we'll talk about it more a little bit later as well. But with the switch vulnerability, we can basically do what's called a MAC flood attack and we can just make it act like a hub and cause it not to work properly as a switch. We also have router vulnerabilities and firewall vulnerabilities and such. A lot of these are generally done because of the firmware, the firmware is not up the date and things like that, or it might be incorrect configuration done on the router or the firewall. So it's always good to verify your rules on your firewalls and so forth and then on your routers as well, making sure that all the firmware is up to date and so forth to prevent different types of attacks happening there. On the routers, we can of course do some type of brute forcing on it depending on the type of router it is. And then on the firewall, we can also identify what firewall rules are running by using a tool called FireWalk, which allows us to do just that FireWalking, which is basically grabbing and figuring out the rules of a particular firewall that you may come across and such. Always having good policy rules and so forth within those would also assist in keeping those secure. And of course, as I mentioned, making sure that you have the latest firmware would also be very, very helpful. Other concerns that you may have? Of course, we have everything from email mistakes. Here, we're talking everything from mail relay servers being set up to client email is coming in using some type of phishing attacks and so forth where you click on a link and it takes you to a website type of thing. We have denial service types of attacks or DOS. The denial service or even the distributed denial service attacks. This is where we can actually get in and have what we call bot nets and such that will have literally 100,000s of machines working together to go against one target. We also have industrial spying that could go on. We have computer viruses that's nothing new. Computer hackers that hopefully shouldn't have been very new either. Now, DOS are also known as the insiders and these are actually the top threat. They're actually more of a threat than the computer hacker. Because keep in mind, our DOS is already inside the network and may already have internal knowledge of certain usernames and passwords for servers and whatever else that they may have access to and thus make them more dangerous. So make sure you keep your employees happy. So when we look at network vulnerability assessment methodology, key terms here used within the network vulnerability assessment include risk. This is the probability that a threat will exploit a vulnerability to adversely affect an information asset. We have a threat. Now the threat is an event, the occurrence of which could have an undesired impart. We have the threat impact. This is a measure of the magnitude of loss of harm on the value of an asset. We have the threat probability, which is the chance that an event will occur or that a specific loss value may be attained should the event occur. A safeguard, this is a risk reducing measure that acts to detect, prevent or minimize loss associated with the occurrence of a specified threat or category of threats. And we have vulnerability. This is gonna be the absence or weakness of a risk reducing safeguard. So with our network vulnerability assessment methodology it outlines the steps that security professionals should follow when performing your network vulnerability assessment. This methodology demonstrates a commitment to the requirement of the internal standards for information security, which is your ISO 17799 and the CISP or your certified information system security professional common body of knowledge as criteria for security assessments. Now the next section provides details on phases and subtasks involved in performing your network vulnerability assessment. It also discusses the essential task in each phase and how to do each of the tasks in the subtasks. So within phase one, this is where we have the data collection. Now here we have our review, which is applicable state and federal laws which affect this particular client. So we wanna look at, so during this phase one data collection we wanna review applicable state and federal laws affecting the particular client. We wanna be able to review available documentation and then note those areas of concern. And then draw up a list of known bugs and security vulnerabilities to then test for in the client environment. Now in phase two we have interviews, the information reviews and hands-on investigation. Now steps that the NEA team should perform during this phase of the process include several things. I see the NEA team defines roles or functions about which it wants to gather information about. The team lead and the point of contact develop an interview schedule. The client point of contact arranges interviews with appropriate client staff members and provides office space for the NBA team. All right, the appropriate members of the NBA team interviewed identify appropriate staff members and other identified professionals. Then the appropriate members of the NBA team interview identified appropriate staff members and other identified personnel. Now the NBA team usually requests additional documents that were not provided within phase one. Now the NBA team also may request additional interviews as needed and the team lead requests facility and network clearance and password for team members from the client point of contact as required. The NBA team tours computing facilities, conducts tests, operating systems, hardware, network devices and the software. And the NBA team tours the facilities performs physical plant inspections as well. So keep in mind it goes into interviewing and hands-on investigation by going in, touring the facilities, conducting the tests and such. Phase three would be the analysis. Now this generally entails risk analysis, security policies and threat analysis. Now the process of analysis actually begins with the acquisition of the first document and only ends in the generation of the draft report during phase four. Now the analysis spans most of the NBA process and generates the majority of the content within the report. To be successful, the NBA team will have to identify what network security concerns have the highest priority. This will allow the team to focus on those threats and risks that can cause the enterprise the most damage. Now understanding that the security concerns include personal and physical as well as technical issues, this will ensure that the most comprehensive assessment prospect. Also the use of all resources available to plot what threats will be addressed. Do your research to gather significant issues and then prioritize these risks based on the probability of occurrence and impact to the enterprise or network. You wanna then concentrate on those issues that will bring the biggest impact of your organization. Use your team to identify additional items and then measure specific impact. Development and Checklist will also assist the NBA team in ensuring that basic security controls are examined. So do not just use the checklist, listen and ask questions and be ready to include additional information within the examination process. So let's take a peek here at risk management. Now keep in mind risk management is reducing the risk to an acceptable level, right? The risk cannot be eliminated, but it must be managed. Now with the risk analysis, we need to an assessment to basically identify what are the company's assets. And again, these company assets may be physical computers, physical equipment, maybe people, processes, whatever the case, we need to identify those. What are the company's assets? We need to then assign values to those assets. And we're talking about dollar values, right? We need to identify the asset vulnerabilities and threats. So what are the specific vulnerabilities and threats for a specific asset? And then we need to calculate their associated risks, estimate potential loss and damages, and then provide some possible solution. So why is it, however, so difficult with risk management? Well, keep in mind, it's gonna be pretty hard to predict the future, right? Incredible number of variables also need to be identified and such. Again, this may be different depending on your asset. Summizing all possible threats and providing solutions to them is difficult. Gathering data from any sources, again. We have dealing also with many unknowns and then quantifying qualitative items is also going to be a little bit more difficult. So let's take a peek in some of that. So when we're looking at the risk analysis objectives here, the purpose of the risk analysis, it basically provides us a tool to be used in risk management, right? It helps ensure that the company's security program is gonna be very cost-effective, relevant, and also appropriate for the real threats to the company, whichever those might be. All right, putting it together in team components, we have the risk analysis team should represent different departments of a company. Management also decide upon the team members. Now the tools of the trade, a lot of times we use automated tools, which also require less repetitive data input. We can also run the same data through several scenarios and analysis is also, keep in mind, gonna be time-consuming tasks to be done as well. So we'll take a look at some of those tools here in a little bit as well. So how do we determine the value of the asset? All right, this is by looking at the cost of the acquisition of the asset. How much did it cost for us to acquire this thing? All right, the replacement cost. Looking at the cost of developing the asset. Just keep in mind, you might have just bought a web server, but then had programmers going in, setting up your website side of it with your eBay-type scenario or something like that, which requires a lot of programming, which requires a lot of tweaking and whatnot. And now your asset, even though you purchased it for $10,000, is now worth a lot more for the replacement cost, because now you've added in all those man hours and so forth as well. So keep in mind, those are some of the things you need to look into. Role of the asset to the company. Is this our main breadwinner? Is this web server, is where we make our money with with the company? Or is it something else? Is it perhaps a Unix server on the network or something to that effect? The amount of adversaries are willing to pay for the asset. Cost of maintaining and protecting the asset. Looking at production and productivity losses resulting from compromise of an asset and the liability if the asset is not properly protected. Here's some examples of some vulnerabilities that are not always obvious, such as lack of security understanding. Keep in mind here, security requires real knowledge and the technical to the C level within the companies. So sometimes there's a loss in communication between the technical side and the C level side, your corporate level. So your CIOs, CEOs and so on. So we need to make sure that we somehow have things in place that will allow us to have some good understanding of that between the two. Misuse of access by authorized users. This goes back to what I was mentioning earlier. A lot of companies will have full admin rights for their local users. That means they can do pretty much anything. And possibly with that, we can have what's called authorization creep. Authorization creep is a lot of times also referenced in a domain environment when for instance, let's say the receptionist who has access to certain resources that only she should have access to then gets promoted to the marketing department and then perhaps promoted to another department altogether. However, in each of those roles that she was playing in, she never was removed from the previous roles, group memberships and so forth. So now she has the same group memberships as she had when she was a receptionist, even though she's now moved on to other roles. And that is called authorization creep. That can also be a criminal offense according to specific laws. So keep in mind you may want to manage those accounts and service those accounts to make sure that the users are only able to access what they need to and not more. Concentration of responsibilities, as I hear separation of duties, not being able to react quickly because there's no response team or procedures in place, lack of communication structures, possibly lack of weight as tech fraud such as maybe doing rotation of duties and so forth, technologies and processes possibly within there as well. Now with that in mind also, I worked in the banking industry for a few years and they actually had me take a two week mandatory vacation and they were basically trying to make sure that I wasn't doing any money laundering or anything like that. And again, some companies may still do this to help prevent fraud and so forth from happening. So they give you rotation of duties to assist with that process of detection. Now when we categorize our risks, first we need to look at risks. What is the potential loss? The ramifications of exposure. It could be delayed loss, which would be secondary ramification of exposure, which would be much harder to identify and calculate. So we're gonna list some examples of potential losses and delayed losses. For potential losses, this would be loss in production and productivity, the cost of consultants or expert services, loss in revenue or even the loss of customers. Now our delayed losses would be something like loss in reputation, the loss of potential customers, late fees or penalty fees or even loss in market share as part of your delayed losses. Now different approaches to analysis, we can take what's called the quantitative, which basically means we're assigning American monetary values. The management usually requires results in monetary values, so we have lots of dollars, euros, yang, whatever, and may also start out with a qualitative approach. Now our qualitative approach is always gonna be like a scenario-based, opinion-based and it's basically the use of a rating system that we would use from that. And then we derive the quantitative a lot of times through the qualitative. So who uses what? Well, keep in mind most situations here, companies usually use quantitative. These would be your profit-based organizations and so forth. Now government agencies generally use qualitative, such as your DOD, DOE, the military units, NSA and so forth, which have to provide protection no matter what. So here, a lot of times again, they're gonna be using the qualitative means. So steps to the qualitative analysis. Here, we want to gather companies' experts. We want to present risk scenarios, rank seriousness of the threats and then rank the countermeasures. And we generally would do those with, again, using numbers. So rank one to five, one to six, something to that effect. So we also have what's called the Delphi method, which basically allows us to have anonymous input. With that, we generally will get more honest data collected and also helps ensure that there's no intimidation going on and such as well. So again, it's known as the Delphi method. So let's take a peek at some quantitative analysis. Now here we have the asset value that we're gonna times the exposure factor, which would then give us what's called the single loss expectancy, also known as the SLE. So the exposure factor here equals the percentage of loss that could be experienced. Then we take our SLE, your single loss expectancy, we times that, times our annualized rate of occurrence or your ARO, which is the frequency of threat taking place, which gives us our annualized loss expectancy. So what is the ALE value then used for? The ALE values, annual loss expectancy, helps categorize the risks. The more damaging risk needs to be addressed first, obviously, with that. It helps determine the amount to spend on the countermeasure. It also helps determine the amount to spend on the countermeasure. The countermeasure should not cost more than the annual loss expectancy value. It also helps create a security budget, which helps management know the amount that needs to be budgeted to protect those assets. Let's give you guys an ALE example. So if an e-commerce site is attacked, which is valued at $300,000, it is estimated to cost 40% of damages to the companies based on the liability costs, the confidential data being corrupted, the loss in revenue, and the, basically would be considered the asset value, in this case, our 300,000s, times our exposure factor, in this case, 0.4, since it's 40%, which gives us then the SLE, our single loss expectancy of 120,000. Now, based on current safeguards, this threat is estimated to happen once in 12 months. So here we take our single loss expectancy times our annual rate of occurrence, which then gives us our ALE. So here we would be 120,000 times one, which equals 120,000, how about that? Now, management should not spend over this amount to protect this asset. Let's do another one. So let's say our annual rate of occurrence values and their meanings. So one time in a 12 month period would have an arrow of 1.0. If it's once in 10 years, it would be an arrow value of 0.1. Once in 100 years, 0.01, and so forth. So here we need to calculate the correct annual loss expectancy value if the facility is worth $650,000 and a tornado is expected once every 10 years that will damage 35% of the facility. I'd recommend you pause the video for just a moment, see if you can calculate it and then continue to the next slide. So hopefully you had the idea and was able to figure this out at least somewhat. So here the ALE calculation would go as such. We have the SLE, your single loss expectancy would be 227,500. And basically what we did is we took the 650,000 times our 35%, our 0.35, that gave us our 227,500. So then our ALE, as we mentioned, happens once in 10 years. So here we times that of our 0.1, which gives us a 22,750 value. So what does the company do with this value? Well, they then use this to justify the cost of putting money into a particular asset and so forth for a particular safeguard, possibly for that as well. So they would not spend more than 22,750. So the question then becomes, can a purely quantitative analysis be accomplished? And the answer is simply no, it cannot. A quantitative analysis requires quantifying many qualitative items. Now how do you assign a value, for instance, for reputation, right? How can you know the potential customers that you will be lost? How can you properly predict market share losses? And all these questions are difficult but are required in a quantitative analysis. So again, you can't have one without the other. Comparing the cost and benefits, here we're looking at the cost-benefit analysis. Now the annualized cost of countermeasures should not be more than the potential losses. So for instance, if a server's worth 3,000 and a countermeasure that costs 4,000 should generally not be used. Now it's not cut as dry as it may seem, so how would you determine, for instance, the cost of the countermeasure? So when we look at countermeasure criteria, countermeasures should mitigate the identified risk, and hopefully with that also be cost-effective. Now if we look at our ALE before implementing the countermeasure, minus the ALE after implementing the countermeasure, minus the annual cost of the countermeasure will then equal our value of the countermeasure to the company. So let's take a look at our annual loss expectancy for a specific asset that is $78,000. And after implementation of the control, the new ALE is $20,000. And the annual cost of the control is $60,000. What is the value of the control to the company? OK, let's take a peek. That's $78,000 minus $20,000 for the new ALE, which gives us $58,000. And the new control is $60,000. In this case, it would bring us from $58,000 minus $60,000 to minus $2,000. So the company should not implement this control because it is not cost-beneficial. Not to say that companies will not do it anyways, because some companies will. But this is, again, how we would calculate it. So when we look at the cost of countermeasures, some of the items can go into the calculation. Of course, as we have the purchase amount, the maintenance amount that's required, the negative effects on production environments, such as downtime and so forth. And of course, the man hours to maintain. IDS could be an expensive countermeasure in this respect, however. But keep in mind, there's different things we need to look into when we're looking at what is it all involved there when it comes to that cost in the countermeasure. Now, can you get rid of all the risk? Looking at total risk versus residual risk. Now, the amount of risk that exists before a safeguard is put into place is called total risk. After the safeguard is implemented, the remaining risk is called residual risk. So here, we take a look at our threats times our vulnerabilities, times our asset value, times our control gap equals the residual risk. And the control gap is what the control cannot protect against. So analysis team then needs to determine if the residual risk is within the acceptable risk level of the company. And then, voila, have yourself a nice day. Now, the management's response identified risks right here looking at mitigating the risk. The team presents the analysis results to the management. The management then makes the decision about the next steps. Then the management has several choices when dealing with the risk. First is they can transfer the risk. And sometimes they do this, right? They take it off to third-party involvement, purchase insurance, for instance, and such. Or they can reduce the risk by deploying a control. Or they can accept the risk. And with this, do an informed decision as in take no action. Or they can reject the risk where they do an uninformed decision, which they could also take no action. So what are the liability issues between three and four? Well, again, just depends. How valuable is it? Is this something that your company could go down and never come back up with? It's just all the pins. Sometimes you go one way, sometimes you go the other. But most likely, I've seen with a lot of companies out there, they will generally transfer the risk over to a third party. Now, when we accept the risk here, we need to carry out due diligence. We have to make an informed business decision with that. Then we have a better chance of not being found negligent. If we reject the risk, then most likely did not practice due diligence by carrying out a risk analysis. Maybe it made decisions based on ignorance of the issue, possibly. And most likely, we'll be found negligent, which means we could possibly face some jail time if found guilty. Now, we look at the policy review here. Again, this is going to be the top-down methodology. So as with assessment process, it's important to ensure that policy is established. The direction management wants to go with regard to the security. The top-down portion of the network vulnerability assessment looks at the policies requested in the pre-NBA checklist. The top-down review will assess policies in two ways. One is, do they exist? And secondly, if so, how good is the content? So here we get some definitions. We have what's called a policy. Now, policy here is just a high-level statement of enterprise beliefs, goals, and objectives, and the general means of their attainment for the specified subject area. Now, policy should be brief, which is highly recommended, and set at a high level. We have our general program policy. This sets the strategic directions of the enterprise for global behavior and assigns resources to its implementations. Now, this includes topics such as information management, conflict of interest, employee standards of conduct, and general security measures. We have also topic-specific policies, which you may be more familiar with. These address specific issues of concern to the organization. Topic-specific policies might include email usage, your internet usage, phone usage, phone security, physical security, application development, system maintenance, and network security, just to name a few. We also have system or application-specific policies. Now, these focus on decisions taken by management to protect a particular application or system. It might include controls established for the financial management system, accounts payable, business expense forms, employee appraisal, and order inventory. Different policy types that we have. We have the organizational policies, which are our management's directives of the roles of security within the company. The organizational policies is created to address business needs, laws, regulations, standards of due care, and such. We have issue-specific policies. These could be your one-off policies, your email use, your internet use policies, and so forth. And, of course, your system-specific policies. These constitute directly on the use of maintenance of computers and devices. And we also have policies with different goals. We have our regulatory. This ensures companies have fallen standards set by the regulations and the laws. There are more detail than nature and also specific to the type of industry. We have the adversary. These outlines expected behaviors in the company and the ramifications of not meeting these expectations. And we have informative, which is a tool to teach employees about specific issues, and generally, these are gonna be non-enforceable. When we look at industry best practices standards, we have the BS ISO 7799 and the 17799. This is a comprehensive guidelines on range of controls for implementing security. Companies can be certified against this standard as well. They're divided generally into 10 sections. We have security policy, security organization, assets classifications and control, personnel security, physical and environmental security, computer and network management, system development and maintenance, business continuity planning and compliance. When we look at the components that support the security policy, again, we have our standards. These are gonna be compulsory rules, employee behavior, computer and device use, for instance. We have baselines, which is minimum level of security that's gonna be required. We have our guidelines, which are recommendations on actions in different situations and the operational guides where the standards do not apply. And we have our procedures. These are gonna be detail activities to be taken to achieve a specific task. And again, these are gonna be generally step-by-step instructions on what to do. Policy contents, we have our general or global policies. These are high level policy statements that define the intent of a specific topic and scope within the organization. Now your topic specific policies were unlike the general global policies, the topic specific policies narrow the focus to one issue at a time. And the system and application specific policies, these policies focus on one specific system or application. Now the ISO 17799 has established a set of guidelines for policy content. The NBA top-down policy reviewers should be familiar with these guidelines, as well as those discussed in the NIST special publications 800-12, an introduction to computer security. When critiquing the policy, remember to look for the four key components. In this case, it would be the topic, the scope, the responsibilities, and the compliance. So when we look at the bottom-up technical methodology, the goal of the six-step process is to maximize the time spent during the technical phases in a network vulnerability assessment. Obviously, step one, site survey. So make sure you get a nice site survey. Walk around, see what's going on. Develop a test plan. Once you do that, build the toolkit. Then you wanna go ahead and conduct the assessment. Once you conduct the assessment, do the analysis, and then of course, don't forget to document everything. And this kind of takes us through the initial, what is a vulnerability assessment? We'll look at compliance and project scoping, look at assessing current network concerns, look at network vulnerability assessment methodologies, and look at policy review as in our top-down methodology, we just finished up our technical bottom-up methodology. All right, let's get into some more exciting topics in this next module.