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

73. Third-party Service Providers Part1

We also have to address the thirdparty service provider. Now, they may again provide you partial or complete business processes or services. It’s just a matter of maybe where your resources were lacking that you had to bring in a third party to help out. Now, as such, we need to know that there has to be some level of access to our organization and even to our information systems for that 3rd 3rd party to be able to function. That does present a new set of risks that we have to account for in our security program. In fact, the information security manager should be able to ensure that there are appropriate policies, procedures and processes to help. Basically designed to address the outsourcing lifecycle. Again, the life cycle is from when we first initiate this, develop the communications, maintain it, monitor it, and at some point maybe retire it. So there’s nothing again wrong with thirdparty service providers, but we need to make sure we are accountable for the actions of what they have the ability to do within our network. And there’s also that argument that we should be looking at how secure that third party is.

74. Third-party Service Providers Part2

Now as we continue to look at the thirdparty service provider, the other hand of this, as I said, is to talk about what is that third party doing to maintain that security? So there are some things that our organization and a third party really need to commit to for this relationship to work. Number one, we got to talk about things like how data is stored with security, because it is important to understand that if our data is used by this third party, they in many ways have some responsibilities for keeping it safe. Ultimately, it is our data. So ultimately we have the responsibilities. That means that we need to work with them to understand what they’re doing to be able to help maintain that security. We also have to make sure we have the appropriate allocation of resources that are there to be able to maintain security.

Now, that could mean that we are creating maybe external connections through VPNs. So we need to make sure we have a way of being able to deal with user account logins perhaps what kind of software they’re using, to what extent of encryption we might see with those VPNs. And also to look at the devices we might be using, they might be connecting to the server directly through maybe something like Microsoft’s routing and remote access. Maybe they’re connecting to a VPN concentrator or some other security device that’s capable of doing these VPNs with them. But again, we want to know what is the appropriate resources we need to be able to maintain that security. We also got to make sure that we take responsibility for security rather than expecting that the organization supply additional safeguards.

All right, so what does that mean? Well, what it’s saying is we have to really make sure that we commit, if I have a third party that they’re going to commit to holding up our expectations of security, rather than my having to come up with even more additional safeguards to allow that third party to have access to my information. Now we also have to have accountability. Accountability is the auditing. We need to make sure that we are keeping track of the actions of what has occurred on both sides.Right. For the service provider, connections to us are working with a service provider. We have to make sure we can maintain all the application security processes. In part of doing this, working with a third party, we still want to make sure that not only do we maintain that security, but to try to make it as transparent as possible to the customers. Now, I have kind of a side note of that when we talk about making things transparent in third parties.

I was brought in as a third party to do some work with a company in the Deep South. It was in the middle of Mississippi, and when I was there, I was working with this organization’s customers and they didn’t want them to know that I was even a third party in this process. They wanted me to be transparent to the customers. Unfortunately, as soon as I said hello and good morning in their nice Southern draw, they said, hey, where are you all from? It was kind of hard to be quite transparent as I wanted to. Now, on a technology side note, we can make that very transparent, but those are kind of the aspects that we are trying to look at that sometimes I don’t want the customer to know that they are working through a third party in dealing with my organization. So sometimes in those processes we want to keep that transparent, especially in the application security.

We should also have well defined procedures for how to deal with an incident on both sides and policies about how to destroy or sanitize data when it’s no longer needed by both sides. In other words, if I was a company that developed software and I have a third party developing a piece of my application and they have my source code when our contract is up, I’m expecting that they’re going to have a way of destroying or sanitizing my property, my source code that they were using in the services that they were rendering, because I certainly don’t want that to be out in the wild. I don’t want them to violate the copyrights and use my software offer, maybe for their own gain. That’s at least one example of what we mean by having policies that we mutually agree about on how to take care of that information that we may have shared in common.

75. Integration into Lifecycle Processes

We know that we want security to be integrated into the lifecycle process. In fact, we said that this security should be designed from the very beginning and built into the entire project management through this entire lifecycle of the development, the implementation, the deployment, the managing and the monitoring and eventually the ending of the project. So it’s important to remember that as a security manager we have to make sure, sure that we have processes involved as things may evolve, that we have to consider that as a part of the actual life cycle and working with security in that aspect. So if you consider the idea that through the life of my security program that technology processes do evolve, there are updates to operating systems, there are changes to what can be offered by certain types of controls, there’s also new ways of attacking information, new ways of storing data. The whole world of the cloud network with them as a service provider is becoming very popular. So things are evolving and they’re doing that right in front of us as we are working in this field.

But it is a part of the software development lifecycle and we need to make sure that we are looking at that from every aspect of the SDLC. As long as the security program is running. Now, that means that we should have someone accountable. Ultimately we would be as the managers, but someone accountable for the policy compliance and this should be done through a request change. So as things evolve, we don’t just suddenly do the upgrade, we don’t just suddenly join the cloud, we go through hopefully a proper type of change request. And that’s an important aspect because through a request of a change, whether it’s an upgrade to a system, adding a new system, a new service provider, we need to be pretty much able to make sure that we can maintain policy compliance through the request to change. That does take planning. That means we have to pretty much identify where the change changes are going to be initiated. We also need to know how they’re going to be funded and how they’re going to be deployed because with each change it has its own inherent life cycle that we have to deal with.

76. Monitoring and Communication

Now, there are many different ways we can take a look at monitoring, and so we’re also going to talk about both monitoring and communication. But the monitoring considerations is that we have to realize that they need to be implemented in your security program, regardless of the scope or size of that program. As an example, any change or modifications of controls need to be monitored to make sure that they are operating, operating as intended. Now, whether or not they were changed or modified, I would still make the point that we have to monitor them to make sure we are staying in compliance. Now, part of monitoring might involve reviewing logs or other types of alerts we have, depending on the control, the ability to make notification to people about alerts or about important log information. A lot of that can be done through technologies like SNMP that if a certain type of event happens, it initiates a trap.

We send a message out that can be logged. Many devices will generate information that’s sent to a central logging server we often call a syslog server. And again, different vendors have their own central management type of software that can gather this information, whether it would have been sent or not, but can pull the information or request it so they can keep that in centralized locations, making it even easier for us to monitor. And then going above and beyond that, many software companies have an automated process that’s capable of reviewing the logs and actually being able to use some intelligence as to telling us what’s happening. Looking for signs of actions that could be bad for our network, could be a process failing, could be the sign of some sort of malicious attack. So we have many ways to be able to review that information.

Now, what is important, though, is what is the information? Is it any good? It’s important to remember that we need key controls that are important to us to be monitored and if possible, to monitor them in real time. As an example, I did some work at a bank institution working in basically the core of the network that supported the ATM machines, not the ATM as an encapsulation method. And it was rather interesting because they were using HP open view as a method of monitoring things in real time. And of course, if there was an alert, if there was something that went wrong, you would see a graphical representation by color coding changing. And what I was looking at was a map of a portion of the United States with all of the ATM machines. It was amazing how many ATM machines they were monitoring in just one section. And I could see a bunch of these ATM machines blinking red where they’re going offline or blurting out errors.

And of course, at the bottom of the screen would be the list of what’s happening in real time. And I was looking at him, I said, is there always that many problems with your ATM machines? And it was interesting because they said, well, no, usually it’s very solid, but when we see that kind of activity, then they flip, flip, flip. Next thing we’re on the Weather Channel, they said, you can see it’s a huge thunder and lightning storm. And it has a tendency, apparently, to zap those machines that are out in the public, which made me remember, now I’m never going to get money in the middle of a thunderstorm. But it was interesting because that is really what we’re talking about here on the ongoing monitoring. And they were looking at the key controls. They were in charge of ATM machines. They had to make communications work so that people could get money when they need to. And so they had ways of monitoring that in real time.

77. Documentation

Now of course, with any security program, we have documentation. Now, our documentation is really there for all aspects of our security program from the start to the stop. Now, we’ve been kind of talking about changes. And so, of course, when we have any changes, there should be appropriate documentation that records what those are and also at various stages of the change to ensure that it’s current. Now, some of the things, things we might put in the documentation, of course, or things like what the program objectives are, the roadmap that we’re following, the original business case that got us to the point where we were starting this entire program, we also should be documenting what resources are required with the risks and controls. Again, that could be the standards, the procedures, the guidelines.

Certainly documentations of the budgetary costs of any systems that are being used, their designs and their architectures should be a part of this documentation as well as once we have the roadmap down, we have the project planned, what are the milestones, what are the timelines. Many of these things in the documentation can also help us when we are doing the monitoring to see if we are on target, if we’re at or under budget or having cost overruns, whether or not we had the required resources, or if we see changes that we need. But regardless, having documentation allows us to know, number one, what our plans are, what our expectations are, and can help us in making sure that we are still trying to achieve the proper objectives in the long run.

78. The Plan of Action Part1

Now, part of our documentation may be the plan of action. Well, remember we said a gap analysis should have been done because it helps identify the projects that shows us where the improvements are needed. You know, I may come up with a security program and through the risk analysis part of this, or through risk management, I may have noticed that an existing countermeasure is performing as I expected it to be, that its current state was actually my future desired state. And so I don’t really need to do anything more with it. So having a gap analysis there would just show me there is no gap. So I have nothing to deal with. But if there were to be changes, if my current state is different, again as my desired state, then we know there are improvements.

And some of those improvements could be very small. They can be very complex. So the plan of action is our way of being able to pretty much say we have a project and so we’re going to have this plan that includes the time, the budget and a measurable result. Now, a lot of these projects, as I described, could be technology implementations. It could be, like I said, just reconfigurations things that we need to change to be able to meet whatever the current objectives were, which again, is trying to get us into compliance with our security overview, the security program.

79. The Plan of Action Part2

Now, as we look at the plan of action, we realize that it should encompass what we call the TQM, the total quality management, which is ideal for us to be able to say, all right, what does it take to get that? What are the elements? Well, some of the elements that you should see in a plan of action to be if we really want to look at it as total quality management are things starting off like the vision. Now, if you can imagine the vision, of course, is this overview of what what’s the real goal? It should be a clear and compelling statement about the organization’s purpose. Now, from there, how do I get to that vision? Well, we have some strategic objectives. Now, those objectives are going to be the set of goals that help move us towards the purpose or the vision.

Now, along the way to getting to those objectives, there are going to be some milestones that we might want to hit. Some things we call the critical success factors. Those are going to be the circumstances or events that we go through that we have to achieve to get to the objectives. We also have to have those key performance indicators, the KPIs. Those are going to be our concrete metrics that we can use to ensure that those critical success factors are being achieved. And again, remember, it’s one thing to say I’ve made it to this important point to make it to this CSL, but if I don’t have metrics to help validate and prove that I’ve gotten there, then it’s just guesswork. And we don’t want that. We want to be able to show it in a measurable way. And we also have to have the key actions. These are going to be the initiatives that are going to be delivered to be able to achieve the objectives and the key goal indicators.

80. Lesson 9: Information Infrastructure and Architecture

All right, let’s take a look at this idea of information infrastructure and its architecture. Now, when we look at the term infrastructure, it’s really the base or the foundation with which the information systems are going to be deployed. Now, that means it’s going to be comprised of computing platforms, of networks, middleware layers for a wide variety of applications. But the infrastructure is just that it’s the way I look at it is how everything is interconnected and capable of communicating with each other. So when I think of an infrastructure for information systems, I’m thinking that there are, of course, cables, there are ports, there’s switches and routers. There’s the servers, the software running on the servers of the operating systems and all of these things that are involved to be able to really support our goal. So that’s the architecture.

• Category: Uncategorized