CISSP: Domain 1, Module 3
The course is part of this learning path
This course covers the third of 4 modules in Domain 1 of the CISSP, covering security and risk management. It will focus on risk and risk assessments, annualized loss expectancy, vulnerabilities and threats, risk response, countermeasures, considerations and controls, assessment types, penetration testing and reporting.
The objectives of this course are to provide you with and understanding of:
- An introduction to risk, including qualitative and quantitative risk assessments
- How to identify threats and vulnerabilities
- The risk assessment analysis process, including risk assignment or acceptance
- Different security and audit frameworks and methodologies and how to implement the program elements
- Risk frameworks
This course is designed for those looking to take the most in-demand information security professional certification currently available, the CISSP.
Any experience relating to information security would be advantageous, but not essential. All topics discussed are thoroughly explained and presented in a way allowing the information to be absorbed by everyone, regardless of experience within the security field.
If you have thoughts or suggestions for this course, please contact Cloud Academy at firstname.lastname@example.org.
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.
About the Author
Mr. Leo has been in Information System for 38 years, and an Information Security professional for over 36 years. He has worked internationally as a Systems Analyst/Engineer, and as a Security and Privacy Consultant. His past employers include IBM, St. Luke’s Episcopal Hospital, Computer Sciences Corporation, and Rockwell International. A NASA contractor for 22 years, from 1998 to 2002 he was Director of Security Engineering and Chief Security Architect for Mission Control at the Johnson Space Center. From 2002 to 2006 Mr. Leo was the Director of Information Systems, and Chief Information Security Officer for the Managed Care Division of the University of Texas Medical Branch in Galveston, Texas.
Upon attaining his CISSP license in 1997, Mr. Leo joined ISC2 (a professional role) as Chairman of the Curriculum Development Committee, and served in this role until 2004. During this time, he formulated and directed the effort that produced what became and remains the standard curriculum used to train CISSP candidates worldwide. He has maintained his professional standards as a professional educator and has since trained and certified nearly 8500 CISSP candidates since 1998, and nearly 2500 in HIPAA compliance certification since 2004. Mr. leo is an ISC2 Certified Instructor.