So our next section is going to be applying the security governance principles. So in this module, we're going to look at alignment of the security function to strategy, goals, mission and objectives; processes; security roles and responsibilities; we'll examine some control frameworks; and then we'll look at some very important activities we're going to do known as due care and due diligence. 

So what are our objectives? The information security management validates appropriate policies, standards, procedures, guidelines; and that they are implemented to ensure the business operations are conducted within an acceptable level of risk. Now acceptable level of risk, just to pause here for a moment, means that the organization must examine risk, and must decide in the various context where we will find it, what is acceptable and what is not, both in order of magnitude and in type of risk. So acceptable level of risk is a fluid term that will be determined by your organization. Now security exists to support and enable the vision, mission and the business objectives of the organization. As I'm sure you're aware, for decades security has been the one to say, no I'm sorry we can't do that. It's a clever idea, but it's too risky, and therefore we can't. So rather than being an enabler, it was a disabler. As a consequence business oftentimes went ahead and did what it was doing anyway, and then eventually handed it off to security to fix. 

In today's world, as best embodied by the CISSP, security must be an enabler. We must say instead of, no I'm sorry we can't do that, we need to say, you know that's a good idea, when it is, and say, how can we do that more securely? How can we examine that, to approve it, so that we get the benefit and don't take on the potential security risks that might come with it? Enablement will do much better to make the business perform better and elevate the level of security the business will enjoy long term. So let's look at the information security management system hierarchy. 

We start with the business drivers. That's what we're doing, that's where we're going. It defines the priorities from the business' perspective. So at the top level, we have the why. In the middle, we have our enterprise policy and standards hierarchy, and the defined roles and responsibilities. This level provides us with the what and the who. And then at the bottom level, which is not a matter of priority, simply a foundation, we have the procedures, the specifications, and the implementation guidance. And this is the how to. So we start with the business drivers at the very top driving us down through getting it done. And this is the way we enable ourselves so that we can enable the business to be more successful at lower risk. Now it should be very obvious to all of us that there is operational alignment that must take place. The business that you're in regardless of what that business might be, is not information security. But you have a tremendous amount of investment and capital tied up in the information that makes your business special. Gives you an advantage. You have at the very least, sensitive information regarding finances and personnel that have to be protected. So information security is going to be a fundamental building block of your organization's operation. 

So as the broader foundation, we have our operational environment, in which exists the organization's mission, in the sector that it does its work in. Within that, we have the information infrastructure, the systems, the data, all of the instrumentalities that make it possible for that business to operate and be successful in that sector. And then within that will be the information security function. And it will deal primarily with security of information and the privacy function, to make sure that any individually identified components are captured and protected from wrongful disclosure. Everything must be aligned with the business because the business sets the context. The information infrastructure has to provide operations support for it to be successful in that context. And the security function needs to provide protection for the information assets that allowed it to execute successfully within that sector. 

Now budgets are of course always the basis of many disagreements, much discussion, and the occasional tussle between one organizational element and another. And one of the things security has suffered over the decades is that it oftentimes ends up being short-changed in terms of its budget. Well, that may be the case where you are. But security is becoming more and more important. Now that doesn't mean we're going to get a landslide of funding and endless time to get it all done. We're still going to have to be extremely conscious that we have a budget that we have to work within, and that we have to make our fullest contribution in the way that we consume it. 

Now historically, security has proven to be less expensive and easier to justify, and more easily integrated with operations when we design it in, rather than building it on later. And what we're trying to achieve here is security by design. That's part of the enablement I mentioned earlier. Now there are of course other factors such as these: the number of staff, the level of security protection required, the various tasks and work that needs to be performed. We have, of course, our compliance issues and the regulations that we'll have to meet along the way. We have to have properly qualified and certified staff. And that will, of course, mandate that we do training. Not just initially but ongoing. And like anything else in business, as the old saying goes, if you can't measure it, you can't manage it. So we have to decide on what metrics we're going to use and the degree of metrics tracking that we're going to do as part of this function. 

Now a word about metrics. As with sports, there are a million metrics that we in security could choose to inform our operations and our decision making processes. The metrics have to be chosen with care to ensure that they contribute to operational management and ultimately actionable intelligence. The measurements that we collect should provide the information on long term trends as well as illustrating day-to-day workloads. The risk that we face in picking our metrics is that many metrics will seem attractive. But they have to be examined much more closely to ensure that we get the information that we need for operational management, and that they do ultimately produce actionable intelligence, so that we can address risks and issues much more productively. So the resources that we have to do all this will include positions like these: System and Network Administrators, Policy and Compliance Officers, even Legal Council and QA Testers. Now these parties are going to contribute major source of requirements. They're going to contribute something that we like to tell ourselves that we need, and sometimes we would prefer to function without it, but the fact is we really do need it. We need their feedback. We need their involvement, such that their feedback tells us the important things we need to hear about our program. They're also going to be key sources of indicators. Sometimes it comes in a comment, sometimes it comes in an email, but we need to know what's going on in the real world, and sometimes the symptoms of things that are not going so well will come from sources like these. And we're going to need that input to continually continuously improve our program. To make all of this work, we're going to need organizational processes. 

The workflows that we have are going to provide the basis to accomplish tasks and create potential security risk, even though we want them to address the risk in a more negative way. In other words, to reduce it. The organizational processes are the way that we're going to implement controls and safeguards, to preempt violations as regards our compliance posture. Now these processes must be understood in terms of their flow, their interaction, information delivery, feedback mechanisms, so that they can assist in the risk identification, qualification and mitigation. Now, let's pause here for just a second and examine this term, qualification. We always talk about quantification of risk. Well, we need to qualify it as well. By qualifying it, we're going to add the attributes of how real and how relevant is a given risk that we may be examining. A common example that I use is glaciers. 

Glaciers are real but the question has to be asked, in the kind of business that you're in, are they relevant? Now, this may seem an odd comparison, but the fact is there are a great many risks that your business faces every single day of its operation. But you must always ask the question, are they relevant to me and to this business? Because if you do not qualify them as real and relevant, you may end up spending a lot of time and effort on risks that matter very little in the real world to your business. So you must qualify these risks to ensure that you establish real and relevancy of the various risks so that your mitigation efforts will produce the value that you seek. We're going to need to integrate our security practices within workflows so that the workflows are elevated in their security value and we improve our programmatic effectiveness overall. Now all of these of course is about the stuff that we're doing. But what about the parties that are doing this? 

The information security officer is a very common position in companies these days, much more so than in past decades. And their duties may vary possibly quite a bit. But in general, the C-Information Security Officer is the party who is accountable for ensuring the protection of all the business' information assets, from intentional and unintentional loss, disclosure, alteration, destruction and availability. In other words, this is the person who oversees the assurance that we are achieving our objectives for confidentiality, integrity and availability. Now the information security officer can report to organizational management in a variety of ways. And all of the examples you see on this slide are present in the real world. In some cases, they report to the CEO. In other cases, probably very commonly, they report to the IT department. In some cases, they could be reporting to the administrative services department or insurance and risk management, or internal audit or reporting to the legal department. 

Now the things to consider in these reporting models include things like, what is the scope? What is the level of authority? What is the level of responsibility? Are they in a position to actually succeed in the mission that they're given? Who are they reporting to? What is the focus of that particular department? For example, if a CISSP is in the internal audit department, what is their objective? What reporting do they do? What sort of things do they look at? And oftentimes, puts the CISSP on the other end of the spectrum from where CISSPs normally are. On the security side. Well, this doesn't actually mean that they've gone over to the dark side. What it means is is they have a different way of looking at things, a different way of contributing to the overall security and protection of the information assets of the organization. Whichever reporting model, it is most critical that the person in that role is set up to succeed in every material way for their role. The audience that they have, the party that they are reporting to, the various things that they have to see to, that information security professional needs to facilitate success in that function as well. But there isn't one right way of doing this, as I'm sure you know. 

In the course of doing this particular module, we're going to examine some security control frameworks. Now they have different objectives, as you'll see in the coming slides. The traits that they share in common include these: they must be consistent in the way that they're applied, they of course must be measurable in how they do what they do so that we know whether or not they're being effective and achieving the goals. The very idea of a framework means that they are standardized. 

A framework needs to be considered comprehensive in the area that it addresses. And ideally, they should be modular. You could say, plug and play. So as the frameworks themselves change over time, which they all do, we would be able to unplug a particular module, that may no longer have relevance, or may have been superseded by something else, and by unplugging one, we plug in another, replace it, hopefully with something of improved or better integrated functionality than the module that it's replacing. But as I said, all of the control frameworks share these kinds of characteristics regardless of what their particular objectives might be. So let's examine some of those a little more closely. 

So here you have some examples of the various control framework types that we have. These come in the various forms as I've mentioned, to achieve these different objectives: here we have COSO, we have the ITIL, also known as Service Oriented Architecture, we have the COBIT and then we have the well known ISO 2700 series. And each of these can be one of several overlayers to the information infrastructure that they seem to apply control and security to. Underlying all of our security frameworks are the policies and procedures. And all of the other things that we're going to engage in is the principle known as due care. Now due care is defined as when "a reasonable person "with the same training, experience, "would exercise under a given set of circumstances". Each of you symbolizes a reasonable person in this definition. It also establishes an individual's or organization's legal duty to a particular audience that they serve. 

Due care is followed up by an investigative process that we all know as due diligence. Due diligence is an act of management in furtherance of the principle of due care. Performance of tasks that ensure full investigation and full disclosure of all the relevant and quantifiable risk elements, and that includes qualification of them as well. Now things that we might do as part of exercising Due diligence would include verifying through background checks, employees. To make sure that they are who they claim they are. That they have the experience or degrees or certifications that they claim they have. That the experience that they say that they have can be validated by someone else. We do information security assessments to make sure that what we think the controls are doing or what the structure or infrastructure is doing is in fact what it is doing and that it's achieving the kinds of objectives we've set for it. We want the risk assessments of physical security systems to be complementary and enhancing to the IT ones. And we can use threat intelligence services as part of our overall Due diligence to enhance our knowledge and awareness of what the threat environment might look like that we face.