Resources that Help — Part Two


The course is part of this learning path

Start course
1h 8m

In this course, you will be introduced to domain one — the first of four domains of the Certified Information Security Management certification. We begin by introducing the Domains part of the CISM exam and introducing some security concepts before moving on to the strategy of information security governance.

Then we look at the roles, functions, and responsible parties within information security governance. Finally, we take a look at the wide range of resources that complement the human factor when implementing information security.

Learning Objectives

  • Understand the main components and requirements of the CISM Domains
  • Learn about the roles and functions for information security governance
  • Learn about the additional resources that can be used for IT security

Intended Audience

This course is intended for anyone preparing for the Certified Information Security Management exam or anyone who is simply interested in improving their knowledge of information security governance.


Before taking this course, we recommend taking the CISM Foundations learning path first.


One factor that's involved in ensuring that human elements are involved, is the organizational chart itself. Within an organization, it's very likely that various factions will appear. And sometimes certain of these may see changes as a threat.

Now, senior management should foster more flexible attitudes towards change, and must lead the way, lead from the front so to speak. We have to recall that IT and security priorities may sometimes conflict and we in striving to achieve the balance must recognize these and do what we can to eliminate them where possible.

Organizations are frequently a hybrid of centralized functions and decentralized functions, with responsibilities and accountabilities spread across the entire enterprise. Now in certain cases, the centralized is often preferred because it supports consistent performance and quality. But in many organizations, decentralized work is necessary because there are multinational companies with locations spread throughout the globe. 

The decentralized may be able to overcome issues related to local laws and regulations better than a centralized structure might. It might also work well for companies that acquire other companies, or various kinds of companies for which remote workers are the norm.

One of the things that decentralized seems to do as well, is bringing the admins and their respective user groups closer together. Whereas centralized may in such cases provide greater bureaucracy, and thus lower satisfaction and lower efficiency.

The human factor of course, pervades the entire organization, both the positive and the negative aspects. This means that we have to put together a security awareness program that reinforces the security to all employees in a way that meets that particular audience's needs and understanding.

Now, in many segments, this program will be required by laws, such as HIPAA in healthcare. But we have to recognize the training personnel is vital to improving security effectiveness. The hard part oftentimes is determining what skills or information need to be taught and to whom.

We make the mistake sometimes of hiring overqualified personnel that can lead to high turnover, or inappropriate matching of a person with skills to the type of role they actually fulfill. So training needs to be an ongoing process with attention paid to how to match the one, the need for performance, the need for skills, with the role in which the person possessing them will fill. Keeping them and keeping the training program running often proves to be more cost effective than allowing high rates of turnover, and failing to address the training need.

As with any program, we need to have an audit function that captures and measures how the program is performing. Through audits we determine security deficiencies in terms of controls and compliance, as well as human performance. These can be performed as internal operational style or external in the form of compliance style. The focus will always be on the combination of people processes and technology, and the accomplishments of the compliance goals or operational goals before them.

Internal audits are oftentimes conducted by committees not associated with the area being audited to ensure that we have objectivity. Internal audits can also be conducted by security managers on a routine basis, and may have to be done due to smaller organizations not having the diversity of personnel or the budget to support having an external one performed.

Where possible external audit should be conducted by a third party to ensure objectivity and conformance to standards. It could be done by a finance department. However, the results might not be making it back to the security personnel who will be responsible for implementing the recommendations and closing out the findings.

We also find that there are laws that mandate the periodic audits of either operational or compliance style, such as FISMA, such as Gramm-Leach, such as HIPAA and other laws required. All of this is designed to ensure proper and appropriate compliance enforcement. To do this, we have to develop policies and procedures that allow us to recognize and handle security violations and the conditions and the behaviors that caused them.

This of course, will require management buy in to ensure that this remains a priority. One way of doing it, is to ensure that self reporting is possible, and that it fosters trust and openness. Some issues, however, are going to have higher levels of compliance than others. For example, keeping people out of a nuclear control room is more important than locking in office computer when away. And this example, as simple as it is, is reflective of our need to recognize the variation in priority. Certainly, it's important to lock the office computer. However, keeping visitors out of the nuclear power plant control room is also in its own way, equally critical.

Now it's part and parcel of every program that we develop, there is the need for doing threat and vulnerability assessment to ensure that we're focused on those things that really are focused on us as targets. One of the things that we find is that threats tend to be constant, whereas vulnerabilities may come and go, whether we patch them or they're patched by their vendors for the respective product. And so we do a threat assessment. And this has value as part of the strategy development, because we need to understand the various options and the related costs to making the appropriate good decision to mitigate as needed.

Most cost-effective to analyze threats and vulnerabilities separately, simply because they are two different types of elements requiring different types of approaches and solutions. From this process, of course, we should develop policy so that it maps to a particular threat profile, not specific vulnerabilities. And a vulnerability assessment incorporates more than just automated scans, we have to also employ periodic penetration testing, various other types of test procedures, various practices, I just know are different technologies, we have to include the physical through our facilities and our personnel, we have to look at requirements and a variety of other factors.

We also need to do formal risk assessments. And these start with listing the threats that we now know that we face. From this, we have to set the second step to identify the risk associated with these threats. And we typically have to make an estimation of the likelihood or probability of occurrence and impact both type and order of magnitude.

From this, the third step will automatically come to determine what our exposure is to these various threats, risks and impact. We will need to determine threat frequency, threat magnitude, and what our organizational vulnerability is to these.

We have to of course, pay special attention to the frequency of occurrence because this require potentially more robust or certainly quicker to recover and ready again, types of responses. And in our classic way, we need to calculate the annualized loss expectancy from these various findings.

One thing that needs to be considered throughout all of these analyses, is what impact this is going to have on us and what sort of insurance coverage we may need for it. We might want to consider rare high impact risks, things that we may not be able to actually do anything proactively effective against, such as natural disasters, embezzlement, lawsuits and other types.

Insurance that we can consider is first party which covers us for most sources and includes various recovery costs. Third-party insurance covering liability with third parties, or fidelity insurance or bonding, protecting against employee theft or embezzlement. Business interruption insurance can help us through various types of disasters. And then of course, there's always government aid, which is not necessarily something that we can consistently routinely count on.

What we should also do, is conduct a resource dependency analysis to determine things that are critical, things to which variations of its performance or presence, we are very sensitive to. This is in its way similar to disaster recovery planning. Because we take a close look at systems, hardware and software and get an assessment of how critical that component might be, and how sensitive we are to it, whether it's here or whether it's changing and its performance parameters. This can be used instead of a business impact analysis to ensure the strategy looks at all critical resources. In comparison to the business impact analysis, this looks at pieces rather than the impact of the business of the loss of a resource.

Fundamental to all of this will be third party risk as well. We need to look at our outsourced services and our supply chain both for suppliers of product and service that go with what our enterprise is in business to produce, and to the services that we use as part of our program.

Many times outsourced services are looked at as a way to cut costs in certain areas. It is however, proving to be difficult to quantify and mitigate the associated risks with these things, both what it means to take them on and what it means to have them solve the particular problem they're being brought on board to solve.

One of the concerns by internal employees and executives, is the loss of control that may seem to accompany employing third party services. Providers may operate at different standards. When we build contracts with these outsource services, we need to be careful to ensure that our standards are built into the contract, and that they encompass other standards that the outsourced services may have to comply with, but to ensure that our requirements are being met all the same.

We have of course, the special case of mergers and acquisitions that require due diligence before any such thing is done or in the case of a divestiture, before the divestiture itself is made to see what exposures are enterprise the divesting one may have in the process. And then of course, we have to worry about all of the other things, the cats and dogs so to speak.

Looking at these other operational support and assurance providers, we find that they fall into many categories such as legal compliance, audit, procurement and so on. Internally, our own departments in these areas support or deprecate our performance for information security. And of course, what we want to accomplish, is that they actively support and enhance our ability to achieve it. But we must make the appropriate steps to ensure that that is the outcome.

It can be that various parts of our strategy work extremely well. Whereas other areas, such as might be on this list, are not given the proper attention and therefore act as weak links. We have to ensure that we identify these gaps and overlaps that may provide inappropriate training or possibly confusion by overlapping. to ensure that all of these departments are pulling the team along with all of the other horses, all of the other departments in the enterprise so that the program is working well along all fronts.

We come to the end of the first section. We'll take a short pause here and then we will continue on with section 30, Information Security Governance, constraints that hurt.

About the Author
Learning Paths

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.