We're going to continue now with the CISM review seminar on section 43, and we're going to discuss domain three, information security program development and management.

Now in this section of our program, you're going to learn about security program frameworks, scopes, and charters, program alignment with business processes and objectives, various frameworks, management and administrative types of activities, operations, the performance of internal and external audits, we're going to further our discussion on metrics, and we're going to talk about specific controls.

Now the program that needs to be developed will be the security manager's responsibility, and these will be in a uniform fashion so that we can report routinely to executives and management on the progress of the program and any findings. It may be that we need to create a new one or take an old one and alter how it performs to make it better.

Now, any kind of a program in this area needs to be the result of a well-developed security strategy. We have to look at how we design it and we have to get buy-in from management and other stakeholders. As we discussed in the previous section, we need to look at the effective metrics, define them clearly, and make sure that they're collected on a timely basis and at the right location.

This program, more than just risk, must address how the program will actually perform day to day to ensure that they align with business goals. We will always need to be aware that cost and effort need to be kept under control, and in doing so, that we're spending as much time, effort, and money as needed to accomplish the program, but that we're watching it so that we're not overspending or understanding.

So we move on to section 44, where we're going to discuss the goal of the program. Any program of this type, of course, must be very clear about its goals and how they align with the business that this program is a part of. One of the goals, of course, is to do cost containment and ensure that all the efforts are as effective and as efficient as possible.

One beginning point would be to do a gap analysis to determine any goals that may have been set up in the past and any differences between the goal and what was actually achieved so that we can define better the objectives for this program. When we define objectives, we need to look at the forces that drive the need for security in this enterprise based on the uniqueness of this particular enterprise. Some examples would be regulatory compliance, which will differ from one type of enterprise to another, the increase in security incident cost and frequency, as may be the case in either an industrial sector or in the particular enterprise, concern over damage to reputation, a growing concern in the minds of most executives in most enterprises, compliance with PCI DSS if PCI, payment card industry standards, are a concern of this particular enterprise, and any sort of goals in the business itself that might change usually to increase risk so that we can tailor our program to deal effectively with them.

Now, the security program development represents a wide assortment of activities in an organization. Most of these activities will have a direct impact on personnel, business processes, or the information technology. Oftentimes, security programs are focused on linking many disparate activities in an organization that are all in one way or another associated with the protection of valuable information assets.

Another way of thinking of security program management is that the security manager and the team, if there is one, acts as a catalyst to ensure that activities throughout the organization are carried out in a way that does not produce unacceptable risk.

Bearing that in mind, we're going to talk about section 45 and explore the strategy that needs to be developed for the program. So looking at the scope and charter of the information security program, we find ourselves coming into potentially a new environment and we must understand all of those things that form the expectations of those we will encounter, both of us and by us.

Our goal here is to develop a scope and a charter for the program. As such, we need to capture the expectations and verify its accuracy with those in this particular environment. We need to take a close look to determine where security fits in, who it's going to be reported to, who reports to you, and what is needing reporting. We need to try to avoid reporting up to the same departments that we regulate because this can create a conflict of interest and prove to be less effective.

Now, former managers may be available to provide information that isn't documented. And here's a point at which we must be very sensitive and aware of the differences in culture and the impacts that they can have on our program, both before, during, and after its operation.

Here we have a graphic that can depict how we're going to develop the strategy. Starting in the upper right hand corner, we have the determination of the desired outcomes for this activity. Then we need to define what the objectives are going to be, both the state and the level.

From there, we need to perform that risk analysis gap analysis so that we can determine what those are, the targets that we have set up, and where we are in relation to them. The gap analysis will then direct us as to how we can close that gap.

From this, we'll develop a strategy. We create the roadmap that we have discussed in earlier sections, we will develop the program details to implement the strategy, and we will seek to manage the program in order to ensure that we meet the objectives and achieve the closure of that gap and the desired outcomes. And as you see there at the bottom center of this particular slide, this is going to be an iterative and ongoing process.

So we need to look at who does what. A program of this type, without having clear responsibilities and accountabilities, would be very ineffective. Starting with the information security manager, it is common to find them as a member of senior leadership. They go by various titles, VP of security, CISO, CSO, et cetera, and it's more important to know the role that they have than their title. There may be that these functions roll up to a chief risk officer or even to the COO or CEO. The larger the organization, the more likely there's going to be layers of management involved. The audience and the reporting to that audience will always need to be taken into account as we study and apply to the culture.

Next, we need to look at resources that will help. Now, these resources have been covered in the past. So please review back in our previous sections in the metrics and monitoring section to refresh yourself on what those will be. We need to look again at constraints that hurt, that disable the program rather than enable the program.

When we look at constraints that hurt, we have to look at what the challenges may be to our program being successful. Frequently, we find impediments where there is resistance to change, a perception of reduced access due to increased security, over-reliance on wrong metrics, a misconceived strategy, and its failure, the assumption that procedures will be followed without confirmation, suggesting that we need to be sure that we do the trust but verify approach, poor project management, and previously undetected broken software.

Depicting these constraints in the form of scenarios can provide a great deal of illumination as to how they come together, how they perform, and how they may be circumvented or removed, or the conditions improved. Frequently, this involves limited funding and a lack of owner buy-in, which results in no process or controls implementation.

If we experience turf wars, this may be a serious challenge that results in no control implementation. Good management examples and adequate buy-in for budget or results and effective controls application can improve their implementation.

Specific challenges facing the security manager may include a view that security can be fixed with technology, which, as we've discussed, is only part of the answer. Also, increased security makes the job harder. Again, not a wrong perception, but one that we have that we have to work against. We'll find that the situation will improve due to following influences as these.

There may be legal or regulatory mandates, customer or partner expectations. If applicable, there can be PCI DSS expectations. We can run the risk of increased litigation and a rise in the cost of our cybersecurity insurance.

So we want to look at three potential areas of success. One, senior management support, considered to be one of the most crucial areas. It can be very difficult to obtain and to maintain, especially if the program extends over a long period of time. Nonetheless, it is crucial to obtain and to maintain. We can use various information sources such as industry status reports, the various statistics that are reported, impact analyses, threat reviews, and a variety of other metrics.

Another area of successful will involve funding. A lack of funding could of course be a symptom of a lack of senior management support. Proper funding addresses the questions of security value, meaning that the value is perceived and accepted and supported, or that it is not.

One of our requirements is we have to demonstrate where the money is going and the importance of the investment, and of course that we are getting our money's worth. If we find the support exists, but the money doesn't, we may have to find out where we can leverage different budgets from different business units to increase the funding and the support, how we can improve the effectiveness of the existing controls to get more out of what we already have. Working with steering committees can increase resource allocation, but it is just one of the methods that we may need to explore.

Part of this problem will be solved by continuously showing management why security has a positive impact on business goals and is an enabler more than it is an impediment. A never-ending problem can be staffing. There may be several obstacles to this, including poor understanding of how the resources are allocated. We'll have to generate reports and metrics that demonstrate security staff efforts. We have to map each role to show how they protect assets, to verify and extol their function and success. And if necessary, consider outsourcing if new staff can't be added.

Let's take one particular area and look at the five challenges of developing an incident management plan. Again, we look at a lack of management buy-in and organizational consensus. There is the perception that incident management doesn't align effectively with business goals. It may be that our culture is such that if we lose the champion of incident management, we lose all management support and funding.

Any time a program of this type suffers from poor communications, there can be a loss of support for perceiving that this particular area is confused or ineffective. And if we have an overly complex or very broad plan, it may be that there are functions built within that almost guarantee its failure. So these challenges must be effectively addressed to management and then demonstrated as working in order to maintain the support that we require from them.

And with the thought of the possible constraints that we're going to be faced, we need to move into section 49, the information security program development and management and the action plan.