ISACA CISM – Domain 03 – Information Security Program Development Part 3

19. Pitfalls

Now, there are some other pitfalls. The implementation of your security program, as I said, can come into some resistance. Again, it just could be people with resistance to the changes. And that’s not an unusual thing. You might be taking away responsibilities from people that are used to having a little bit more power, not because you’re penalizing that person, but because through the proper designation of role goals and responsibilities, maybe something needs to be at a different level with different decision or command structure. So you may be destroying what some people consider of these little kingdoms that are in there, sometimes these little clicks that show up, especially in larger corporations.

You might have a perception to people that your increased security is reducing the access required for them to do particular job functions. I can certainly see that I use a little what I think is a kind of a funny story. What I saw happen to myself personally many years ago, more than maybe close to 15 or 16 years ago, a company I was doing some work with. I got a new color laser printer back in the day when that was expensive, and I used it to create holiday cards because I had a user account that had permission to do that. They were auditing and found out I used their expensive printer to create something. They didn’t know what. I told them, well, you should. You got the card. I sent it to them, all right? So if they had a better security policy.

That might have said, hey, you know what? There’s no reason for Ken, the contractor to be able to use this color laser printer. And so I might take as I have a perception that says, hey, that’s reducing my access. Unfortunately, I couldn’t make the argument for my job function. But you get kind of the picture that sometimes we realize that you had access to something you really didn’t need, or maybe there was a process you had to go through to get some of these things approved that can also lead back to the resistance. Now, you might have a bunch of poor metrics that are out there. Again, metrics measurements important to us to be able to manage things effectively, to know if we’re in compliance.

And sometimes you might run into some poor metrics and have an overreliance on them. You may also just have a mistake in the strategy, seeing something that you didn’t expect. So failure of the strategy could cause a problem depending on project management. You may have some poor project management that might result in delays, and you may even have some solutions you are choosing to use, but suddenly realize there are a lot of bugs or issues with the software that previously were undetected or might not have been seen because of the level of implementation you were at wasn’t complete. And that could also cause you a setback. So again, there are a lot of things that could cause resistance in the implementation of this program.

20. Objectives of the Security Program

Now, one of the main objectives of your security program should be the implementation of strategy that is done in as most costeffective manner as you can while also trying to minimize the impact on the business function. All right, so that seems like a kind of a phrase that might sound like it’s a lot of work and there is, but let’s look at it and take it down into a couple of steps. There may be many ways to reach your objective. There’s no doubt if your objective is to reach a desired state of security. Now, in those options that you have as you’re designing, ultimately when we talk about the roadmap, the way in which you’re going to get there, you may have several issues that deal with how much it might cost that corporation or organization to be able to get to that specific desired state.

But at the same time, when you start making changes to the security program, it will have an impact on how people do business. If you change policies about acceptable use for the way in which they can browse the internet or you talk about ways in which you’re going to monitor all the emails to make sure that corporate secrets aren’t being sent out, people will feel an impact. If you suddenly say there’s no reason why this group of people should ever have access to these printers because we use them for productions of pamphlets and things like that, marketing tools, there’s an impact. And I’m not saying it’s a bad thing, but it does affect the way business is done.

So we’re trying to find a way to get to that desired state while making sure that we are as unabasive as possible both in cost and in the impact of how the business runs. Now, whether or not your strategy has been developed in great detail or it’s just at a conceptual level, the program development is going to need a lot of planning and design to be able to eventually become your project plan. For all of the reasons I just mentioned that you have to try to find a good balance in between the cost and the impact of the business. And in fact, I might not even think that good balance is a way I should say it, but we’re going to try to find the cheapest and less impact manner that we can get to to get to the desired state.

21. Program Goals

Now when we look at the program goals and we take it, you know, kind of like the idea of at a high level when we look at it, you know, 30,000 foot view your outcomes for your programs. Your desired outcomes should include some of the following points, probably all of these points really strategic alignment. Remember, the goal again is that we have to support the business objectives, the business functions. We’re not out to change, change how our company or organization does their business. That’s what they’re designed to do is if they sell Widgets, they need to sell widgets. We’re not out to try to stop that or to change that or have them go and make something else. We’re out to try to help support that business function.

Now in the part of this program, goals really have to say, well, how do I know where I’m going? How do I even know where I’m starting to get to this desired state? And that’s why we have risk management being handled as a part of the security program because that risk management helps us all the way through to the desired state. It tells us where we currently are. And as we’re going in the direction to the desired state, we can continue to look at risk management. We should look at risk management because on our way to the desired state, risks will change, they should change. And for all we know we might actually introduce new risks because of some of the changes that we’ve made. And risk management is about trying to discover those and again, try to keep risk at a minimum all the way to the desired state.

Now at some point there’s going to be a benefit. We call that the value delivery and we should be able to help outline in the security program what the value delivery is going to be to the organization from making these changes. Now we realize that you only have so much to work with, we call them resources. You only have so many people. Those people have certain skill sets. You have only so much in the budgetary constraints that you have to deal with. So you have to work and figure out how your program goals are going to fit within the resource management here’s where sometimes a decision might be made about outsourcing maybe to bring in people with the skills you need to implement certain types of controls. Now there has to be also an assurance process integration.

Again, right, we’re trying to make sure that we are basically delivering what we want. And how do I know that what I’m doing is actually working? How can I give you the assurance that we’re on our way, that we’re making progress towards that desired state? Well, that’s usually done through a series of measurements we call performance measurements. Again, we need to be able to find a way that we can adequately monitor and measure how we are doing at the certain milestones or checkpoints that we’ve set up to get to the desired state? How do I know I’ve even met the desired state unless I have a way of testing it, of measuring it to know that we’ve actually achieved what the original program goal was.

22. The Steps of the Security Program

Now, as we look at the steps of your security program, the first step is defining the objectives. Again, this should be as clearly defined as we can. And the design is to have these objectives out there so we can help kind of close the gap between where we are currently and what the objectives are. So in a way, this is the big picture, if you would. But they have to be very specifically defined. It’s kind of like the saying I said before, that, you know, if you don’t have a target, you’re going to hit it every single time, right? In other words, the units like shooting an arrow blindly and just wherever it lands, you say, oh yeah, that was our objective. That’s not the case in a security program. Right. We need to know specifically what it is that we’re trying to get to. Now, at some point we have to realize that even if we meet our objectives 100% of the way, maybe even go past what we had hoped for in the objectives, there are still risks, residual risks, and we can’t eliminate those.

But our goal is to be able to get to a point where we know that the organization is willing to accept the risk that still remains. We also need to make sure we can measure that so that we can see that we have met that particular state and those objectives and the goal of getting to a point of residual risks that we’re willing to accept. We call that the desired state. That’s pretty much getting to that point where we said we needed to be. And again, that’s where those measurements can come in and the risk management. So we can basically say, all right, this is what we started with. This is where we said we needed to get to. We’re there so we’ve hit that desired state. We’re willing to accept the risk risks that are still there because we’ve certainly reduced them to a point that they’re tolerable.

23. Defining the Roadmap Part1

Now we know our goal is to get from our current state to the desired state and we need a path to basically get there. And that’s what the roadmap is designed to do. So when we talk about defining the roadmap, what we’re saying is we need it so that with the Information Security Manager doesn’t have to start off with a blank slate. Now, what I mean by that is that if I say, okay, here’s the desired state of security and, and I know where I’m at, the question is how do I get from here to there, right? We don’t have an automatic GPS that’s going to give us the best path. And if we run into some constraint, reroute us automatically, we have to manually come up with this way of saying that these are the increments, these are the steps that we’re going to go through on our way to getting to that desired state.

So that means that what we have to do is have a good skill or hopefully an effective skill at creating that roadmap so that the Information Security Manager can develop their program that follows that roadmap on a way of getting to the desired state. So I hope that as you’re thinking still about the fact that we’re trying to create the security program and we started off with our objectives, we knew our current state that now the roadmap exists so that I can develop my program, that road map. Now the roadmap should have several parts of it put together as a complete roadmap. Of course, where are you going, the objectives. Now we’re also going to look at the scope. We’ll talk about these here in just a little more detail as we go on. We have constraints that we have to consider with the roadmap, the approach that we’re going to take, and of course, what is the measurable result?

24. Defining the Roadmap Part2

Now, while we’re developing a road map, we are going to start with a review, a review of your existing data, your applications, systems, facilities and processes. Now, as much as this may sound redundant, well, I’ll just get it out there and try to break it down. A review objective is a statement of what is to be determined in the course of a review. All right, so I said the word review twice. But really what we’re saying is that there is an objective of why we’re doing the review, and the objective defines the information that the security manager is trying to get out of the review. Now, from that information, we may be able to determine scope. Scope is a term that we use to refer to the mapping of that objective of the review that we’re doing to the item that’s being reviewed. In a way, the review objective might, you might say, dictates the scope. Now, remember that scope deals with understanding that it’s not just one little business unit that may be affected by what we’re reviewing, but looking at the entire organization as a whole.

25. Elements of the Roadmap Part1

Another part of what we look at is, of course, with the roadmap is dealing with constraints. Now, constraints are basically the situations that the reviewer has to operate in. Now remember, the constraints can be budgetary straights, can be that of the resources of people, of the environment itself, of the facilities. And part of what we’re trying to do is through the review is make sure we do understand what the constraints are, knowing that that’s going to be basically the boundaries that we have to operate in. Now, the approach, or at least what we’re looking at and putting this together as having a set of activities that are going to cover the scope in a way that we meet the objective of the review following those given constraints.

So again, that’s kind of a way we’re saying what’s the approach of the review? Well, we’re going to have to stay in those constraints. We know what objects we need to review, we know what the objective of the review is. And so basically our approach to doing it is going to have whatever activities we determine that are going to try to cover the scope of what we’re looking for, meeting the objectives and staying within those constraints. Now, the main goal is to identify the best approach that has the fewest constraints. The results is an assessment to see if the review objective was met and be able to help answer the question is this secure?

26. Elements of the Roadmap Part2

Now as we look at the elements of the roadmap, we have to remember again the roadmap is used to implement the information security strategy and there are a number of factors that we have to consider while working with the actual roadmap. That’s why we talk about the elements, the factors we have to deal with. With a welldeveloped strategy, there should probably already be a high level roadmap already created. Now, if we don’t have a good strategy or if we don’t have risk objectives, then we actually have a risk that nothing’s going to be integrated or prioritized and this make a very poor security program.

27. Elements of the Roadmap Part3

Now much of your security program is going to involve designing controls that are going to meet the objectives and then of course, deciding on a course of projects to be able to implement and deploy those tests and then test those controls. So here’s where you see the roadmap coming into play, right? We’re saying, okay, I know what we need to be able to get to those objectives, but it may be a long term project. I know we’ve talked about the this before, that I may say, okay, to get from my current state to that desired state, I might not be able to make it in one big step, but instead, I may have to make several smaller projects, smaller initiatives to get to that point where we eventually get to the end of the roadmap.

That’s part of what we’re looking at is that we know that we have these controls, they’re going to meet our objectives, but I have to figure out what that course of projects are going to be and the proper order to implement those to be able to eventually deploy and test the controls. Now again, you should be able to look at this in a way that the organization is doing its business because we need to make sure that we try to find out if the organization will be able to absorb these new security activities without negatively impacting the business objectives or the organization’s objectives. So that’s a part of what we have to think about as we’re going through this process of creating the roadmap.

Now during the design of your security program, of the security program, I should say the manager should focus on the relationship between general and application level controls. Now again, that should be hopefully a step by step breakdown of all the interrelated activities that cover the infrastructure and the operating environment. Well, as your security measures. Now as I talk about this, general and applicationlevel controls will kind of break those down for you in just a couple more minutes. But general controls hopefully sound like those controls that may have a wider scope or a broader base that it’s going to affect.

• Category: Uncategorized