Throughout our process, controls that are selected have to be assessed for what value contribution they will make, and we need to look at how we report this. Why did we choose one particular control over another? 

So, we will need to develop evidence about if the effectiveness of the controls, that is, we will have to measure them and insure that what we have is irrefutable proof that we have made the optimal selection. We need to be sure that these will provide us with a positive indicator of the quality of our risk management processes in terms of the effectiveness of the reductions, and information about the strengths and weaknesses of systems to make sure that the officials know that the controls that have been selected are meeting the stated goals and producing the promised reductions or something approaching them. Our effectiveness assessment methods should include technical and non-technical evaluations which would include things like but not limited to vulnerability assessment, penetration testing, application testing, and a host of other testing methods that actually examine the controls in detail and develop a profile of how they do their actual job, and how they actually reduce the risk, and the greater the clarity of this, and the greater the objectivity of the evidence, the more the support for this can be achieved amongst management, as they see that the program is in fact achieving its stated objectives. 

So, on vulnerability assessment, we have to look at this from the standpoint of discussion and agreement of our goals and concerns. In other words, what do we want to achieve? What do we suspect we're going to find? What will we do with this once we have the findings in hand? We begin with the selection of a profile perhaps. One could be general discovery, just to see what's out there. Another one could be on the basis of some regulatory requirement such as Gramm-Leach-Bliley, HIPAA, FINRA or FISMA. Then the vulnerability assessment is performed, often times through an automated process. We compile and then analyze the results. In these we must eliminate the false positives and negatives and boil it down to things that represent the truth of our own environment in context. We have to review these to ensure that we know that the items captured correctly characterize our environment, in other words we have to give it a reasonableness test, and then we have to always be sure that we assess the contextual relevance of the particular findings so that we can relate it to the actual environment and that gives it importance to the business decision process. Ultimately, this will have to be communicated to management to assist with informed decision making. 

Now, penetration testing is something that we in security often times discuss as one of those really fascinating sorts of things. The penetration testing is a very important technical tool for actually seeing how someone with intent against us can actually successfully compromise our system, invade it, capture information, capture additional information and knowledge of how our systems can be penetrated in other ways. Now, the key to this is putting together a proper plan of attack so to speak where we outline what our objectives are, we properly define and state our scope, what the goals are. There should always be agreed upon limitations, that it shouldn't go on forever, or that it shouldn't go into certain systems at certain times or whatever other limitations are appropriate, and then what would be acceptable activities for determining whether or not we have an affective and positive test? The categories of pen testing typically fall into one of these three categories, a zero knowledge test, which tends to be an outside in directed exam and usually simulates what an attacker starting from ground zero typically would do. We have the partial knowledge, where we have some knowledge of the environment, possibly gained by various kinds of exploration and reconnaissance, and then of course, we have our full knowledge test, where perhaps what we're doing is testing a past control application to insure that it actually does the job that it needs to do, but we have full knowledge of the actual environment. 

So, our penetration test methodology runs this particular five-step process producing the report ultimately that will be given to management. So, we go through all of this activities and come up with a Rules of Engagement document, then regardless of whether we're doing a zero knowledge, or a partial, or a full, we do our reconnaissance, then we do the research from the findings from that to innumerate the elements and learn as much as we can, then we do an examination to determine vulnerabilities that may in fact be present. From that, we will build a plan of attack for the execution and actual exploitation, then once we have actually done our exploitation successfully and carefully, very carefully, backed out of the system, we capture our results, put together our report, and then in documenting the findings, we give it to management, and describe for them all of the findings to be followed with a recommendation for corrective actions where needed. We can supplement this through application security testing, where we actually look at a specific application, determine the proper course of action to test it as the kind of application that it is, rather than something general so that we can evaluate how robust the application security controls are and evaluate whether or not it can defend itself, alert us in ways that we need, or if there are vulnerabilities present that require a different approach to mitigation. So, other forms of testing that we can do will be how vulnerable are we to denial-of-service? In other words how exposed are we to common denial-of-service attack types? In some areas war dialing might still be a viable strategy. We should of course do wireless network testing to determine how vulnerable that might be, weaknesses in implementation for example. We can look at PBX and IP telephony testing, and then we can do a test or a series of tests that actually test the robustness of our human resources by doing social engineering testing. Seeing if people have taken to heart the training that we've given them. Then what we need to do is we need to do reporting. 

Now, in reporting, what we need to do is we need to bring out anything that might potentially be life threatening. We need to identify attacks such as domain name servers or major databases and highlight the vulnerabilities, widespread automated attacks and how vulnerable we might be to those, highlight attempts to gain unauthorized access to a system or its data, and then develop a presentation on new attacks or vulnerabilities that might represent new threats requiring new actions, new mitigations, and new strategy perhaps again to make sure that our management is able to do better informed decision making and a guiding principle behind these will be our plan, do, check, act model, a widely used methodology of doing our planning, planning and designing our information security management system, do, we implement and operate the system, and then check, which is the area that we've just covered through risk assessment activities and various types of testing and then as warranted by the findings from such activities, we act to upgrade, modify, and change perhaps our strategy and how the program is going to work. We'll use the inputs from the various sources, our stakeholders, our business types, other sorts of trusted sources such as NIST itself or DHS with their US-Cert public facing activity, and part of that must be looking at the security and privacy requirements that come from various laws and regulations that we may be subject to and the generated outputs will be a framework and a managed information assurance program for both our internal and external reporting of our security and privacy program elements that will be used to satisfy various sorts of due diligence activities such as assuring our having done all things required to meet certain compliance standards that are placed upon us. 

Well, that concludes module nine of domain one, security and risk management and it concludes the end of this particular session. We will pick up with our next session with section 10 to understand and apply threat modeling. So, join us again for the next module where we'll talk about threat modeling, thank you.