The objectives for the information security strategy has to be defined. We have to develop metrics. The next part that we're going to talk about, what are the goals? How do we define the objectives? What is that desired state or future state, and what are the risk objectives? We have to define the goal. The goal typically is how are we going to protect the organization's information assets? We have to locate and identify that data. That information. We then have to value the information, indicate what business dependency there is on that in order to help identify sensitivity and what would happen if we lost that data. That classification is going to help us to avoid over controlling or under controlling and will help us establish cost-effectiveness. The long-term objective, of course, is to achieve a desired state, to allocate the appropriate resources to do that, and to state in terms of specific goals which are aimed at alignment and supporting the business activities. That being said, we have to understand that some of these are going to be organization-wide, while some of them are going to be business unit specific. We have to develop the business linkages if you would, link the controls, the security requirements directly to a business objective. Remembering not to forget the operational level, because improving those linkages on an ongoing basis will help us achieve a beneficial outcome. To define that desired state, it really is a point in time picture. It's impossible to do quantitative definition because there will always be some qualitative aspects, but we need to get as close as possible. Now, there's some standards that will help us do that. COBIT 5. Even COBIT 5 has something called the process assurance model that we could use, Capability Maturity Model, Integration. By the way, that used to belong to the Software Engineering Institute out of Carnegie Mellon. It now belongs to ISACA. We could use the balanced scorecard or the frameworks from SABSA. The folks that share award are out of Canada from Zachman. We'll use the international 27000 series, we could even use FISMA. If we talk about COBIT 5's Process Assurance Model, there basically are six different process capability levels. It starts out with an incomplete level, then it goes to performed, managed, established, predictable, and optimizing, and if you look at this slide, you're going to see that there are a total of nine different process attributes. If we take one of those as an example and we look at COBIT 5, and we look at things like EDM, 0, 1, 2, 3, 4, and 5 we can see that they're broken down into alignment, planning, and organizing, followed by then building or acquiring and implemented, followed then by delivering service and support, and then wrapping that up once we get the controls in place by monitoring, evaluating, and assessing whether those controls are working or not. When we talk about CMM, there are basically five layers that help us define the maturity of our system. Initial, managed, defined, quantitatively managed, and then last of course, but not least, continuous improvement or optimizing. One of the other things that we could use is that balanced scorecard, and we get four different perspectives. From a financial perspective, we ask ourselves the question, in order to succeed financially, how should we appear to our investors, to our stakeholders? We identify the objectives, the measures, how we're going to target that, and what are the initiatives we're going to take in order to achieve that? From an internal business process perspective, how do we share our stakeholders and customers? What business process do we have to excel at? Then we have a learning and growth perspective as well as a customer perspective. One of the other things that we can do is we can put together an enterprise wide architectural approach. We take the enterprise architecture and we take the subset which is the iteration security enterprise architecture and we define that. What is our foundational structure? What are the controls that we put in place in order to support that architecture, including the different business process architect? One of the other things that we can use is the ISO 27000 series to define that. You'll recall that 27001 is the governance standard and 27002 are the controls, are the code of best practice. In 27002, there are a number of different areas from risk management, human resource security, access control, all the way down through compliance. From that strategy point of view, the risk objectives that we have to identify, what is the organization's risk appetite, what are they willing to accept, and what is their risk tolerance. How much wiggle room do we have? Because risk is a very complex subject and it's subject to organizational trade-off. Risks, costs money regardless of the treatment option that we select, whether it is to mitigate, accept, transfer or avoid.
