ISACA CISM – Domain 04 – Information Security Incident Management Part 9

50. Escalation Process for Effective IM

So let’s take a look at the escalation process for effective, not incident messaging. Remember, we’re talking about incident managing. So what we basically when we think of escalation, that means things are going from incident to worse and we need to kind of look at that. And that means that the security manager should have an implement, I should say an escalation process so we can kind of establish the events that are going to be managed and understand that one thing could lead to another. And depending on how successful we are or are not in taking care of each of these incidences, that we may have to continue to escalate and make things well. Let’s take a look at it and just kind of get an idea of what I’m trying to say here. So one incident could lead to another. I gave this example so many times already.

A router goes down, you can’t get to the database. The incident of the router going down led to the incident of not being able to retrieve your data. So with each event there should be a list of actions and the sequence that they should be performed in, which includes again, the responsible parties that are involved in this. Now, if in the actions they’re completed successfully, then you’re going to basically move to the end of emergency section. Everybody is going to be happy at that point. But if they’re not complete and not completed at the maximum allowed time, then you may have to go to the next action. So if the action were to reconfigure the router and you couldn’t get it reconfigured in time and maybe you have a backup of the configuration, the next action might be just to replace the router because you’ve taken all the maximum time allowed.

Because remember, we have objectives and every action we take takes time. Now if at some point you’ve reached the maximum time and going from one action to the next action, then we begin to panic a little bit more because remember, we had the maximum tolerable downtime right? And at some point we had the MTO that said if we exceeded it, we’re out of business. And so at that point we would say, okay, according to our plan, we’ve gone and done these actions. We’ve hit the maximum time. We’re now in alert status. Alert status means we may be pouring more resources into getting this job done and looking at all of our options. And if it keeps getting worse and the alert responses fail, at some point we’re going to escalate and say, hey, we’ve gone from alert to fullfledged disaster. We’re on the verge of being out of business.

51. Help Desk Processes for Identifying Security Incidents

Now, as far as the helpdesk, and I’ve mentioned this before, there should be processes involved, even if it’s just a simple list of boxes where this helpdesk person on a computer screen or wherever is putting checkboxes in there. And we’ve got some process that says if A and B or C then report, or however you want to put that together as a process. See, that’s kind of a process, an if then statement. So that means that the security manager should have a process number one. Well, here’s the goal and here’s the reason why we want prompt recognition.

We want the help desk to have a process in place to be able to recognize when there’s a problem and then know how to route the help desk call, how to like I said, to determine if it’s a security incident at all, even if it’s a false positive. As I said, I’d rather get a false positive. That’s where they think it’s an incident. And then after we respond, we see that it’s really not right at that point. It’s like, okay, that’s good. Life’s going on. The Help desk can finish whatever the solution is. But again, the goal, like I said, is the prompt recognition. And of course, ultimately part of any response is or any incident management is the help desk and everybody else in the organization should have a process in place that they can make a notification.

52. Incident Management and Response Teams

So I’ve talked a lot about the IMT, the Incident Management team and the IRT. The Incident Response team. There’s a number of, I guess, examples of the different types of teams that would fall into these categories. One might be what we call the emergency action team. And by the way, this is not an allinclusive list by any means, but just to give you some ideas of what the concepts are. So this Emergency Action Team, they could be like the fire wardens or whatever term you want to use for response, or bucket crews. And they’re the ones that emergency, right? They’re the ones that put out the fires. Okay, now fires put out how much damage was done. That’s where we’re going to have, again, qualified people or team members. I’ll just say qualified people that can do an assessment of the damage, whether it’s a physical asset, is it a complete loss, is it restorable, salvageable Emergency Management Team coordinating all the activities of the other recovery teams.

Management Team that sounds like people that are going to make decisions for us. In some cases, in a physical structure, damage may have a relocation team relocating not only the people that work for us, but the equipment as well, right? The computers, the servers, the network stuff, the rest of it. And the security team. Sometimes they call this the computer Security Incident Response Team. And they’re the ones responsible for, I guess you could say that they’re going to be doing a lot of the monitoring of the security systems of communications link, trying to contain any ongoing security threats, resolving security issues. And again, these are just examples of the types of teams that might make up all of the Incident Management and the way in which different parts of our teams do their different categories of help in the response.

53. Organizing, Training, and Equipping the Response Staff

Alright, another part of this topic is, as we said before, organizing training and equipping the response staff. Now number one, we’ll talk a little bit more about this with the business continuity and disaster recovery. But all response plans should be tested and that should include, I should say this includes with the members of the different teams, teams. We could test and assess each team. But remember, there is a coordination, there is a communications. We need to know that these have been tested. But for those people not in there, or even those who are, we need to make sure that they have the training. Number one, they should at least have an introduction to what the incident management team does. We ought to have a way of monitoring the team members, make sure we have the appropriate roles, responsibilities, procedures.

In many cases, the only training they might have is the practice, the testing, the putting in practice, what we call the on the job training. At least hopefully that gives them some comfort with knowing what the policies are as they’re going through there, knowing, I guess we could just call it the SOPs, the standard operating procedures. They hopefully know what tools are available to them. So that’s all great, that’s a good experience for them. We may also have a system for formalized training where we may need to make sure that we have people at a certain level of competency which is important to us, which the goal of that formal training with everything else is to hopefully make sure that our incident management capability is as at the best level it could be.

54. Incident Notification Process

Remember, notification is where it starts and somebody’s got to notify the IRT. And that is the first, it is the most important step if nobody tells us about it. And remember, this notification can come through systems that utilize automation. So it doesn’t always have to be the people, but it is the most important part of this process, whether it’s manual or automated or not. Once the IRT is there, it may be up to the IRT to know again the process of who they notify. Maybe they need to notify HR. Maybe it’s risk management, public relations, right? It just continues on this list. But it starts here first and then depending on what your goals are and what you’ve worked out through these processes, then the IRT can notify the different other teams at that point.

55. Challenges in making an Incident Management Plan

So there are some challenges in making an incident management plan. And we’ve talked about this, so I’m going to use it kind of as just an overview or as a review of what we’ve already talked about. Remember, management has got to be with you. If they’re not in there, if we don’t have that top down approach, then we’re not going to have a lot of success with our solutions. Organizational consensus. We, we talked about it from two aspects. Number one, we wanted to make sure we met the business needs. The other thing is, do we all agree on the plan? And when I say agree, I mean do all the different departments that are putting this together that’s important? A mismatched organizational goals, that’s more about the needs, I would say, so what if we don’t have consensus? Maybe we need regular meetings.

Was everybody involved in the process of coming up with this incident management plan? Another problem is turnover. If through attrition you’re losing employees that are key to this team, then you’ve got a new person to bring on, a new person to train, a new person to get consensus with, to practice, to test. And that can cause a problem with the overall plan. Again, we could have under communication. I guess when I say under, I mean not enough or too much. We have sometimes some people, every organization I’ve been to, I’ve probably had people say, can you talk too much, you’re over communicating.

And then if I’m late at getting back to an email, then people say, I’m flying under the radar, you’re under communicating. And it kind of goes both ways, I guess. So we need to make sure that again, that’s part of what we need to work on. And another challenge is how complex is the plan? How much area does it cover? How wide is the plan? If this plan goes through all aspects of the organization, we’re talking about needing lots of team members with their expertise and everything else that I’ve been talking about. And that might be also adding to not only the complexity, but the ability to communicate, as I said before, and trying to just make this plan work.

56. Lesson 9: BCP/DRP

Now we’re talking about some of the resources that we need for incident management. Now many resources can be available within the organization and maybe they need to be identified and possibly even used for helping develop the incident management and response plan. Now of course some of these are going to be right off the top. The policies and standards, I mean the policies are what we have to be in alignment with, or alignment I should say. And that is because those policies really are designed to help correspond with the business objectives. They may be corresponding with regulatory laws that we have to follow. The standards give us those boundaries that we have to work in and so we have to stay within those and they can be a good part of the plan, but they also can help shape what the plan is going to be.

Now some of the types of things as far as the technologies that we have to deal with, well security principles, all right, when we’re dealing with our plans and we’re talking about security principles, we’re really getting into the area of identity and access. At least that’s the term that Microsoft likes to use, IDA, that involves our authentication, our authorization, identity management, dealing with ways in which people connect, log in, authenticate, how many different services and different applications do they have to interact with. And so there’s a lot of things that we have to possibly consider. These are resources of course, but they might be a part of what we’re making plans for as far as the response. Other technologies we deal with are of course vulnerabilities and weaknesses.

Now every bit of software that I’ve ever seen or ever heard of has usually got some sort of bug or vulnerability. Weaknesses could be and by the way, it’s not just software, there could be vulnerabilities in the physical security of the system or the organization, weaknesses that could easily be exploited. So we have to be aware of these and realize that we’re working with these types of goals in minds, public access to the Internet, all sorts of things we have to be concerned with as far as the technologies, what kind of access are we going to use unencrypted protocols, are we going to use encrypted protocols? Are we going to have virtual private networks that might be using IP security? Web access could be with secure socket layer transport, layer security.

Obviously we have a lot of different types of traffic that can come across the Internet. Everything from voice over IP traffic to the dissemination of information that we’re trying to send maybe to other companies, web servers that are providing content or ecommerce. We have all sorts of network protocols, applications and services that we have to deal with when we get into that realm. We have everything that works at layer two, generally ethernet stuff we have to deal with address resolution protocol, the different types of attacks about that with Spoofing, with potential man in the middle types of attacks. With the network layer, we have to deal with the types of IP addresses that we use.

If it’s IP version four, IP version six, or maybe something else novel used to have the old IPX at the transport layer. Again, we have TCP and UDP and many other protocols that are potentially going to be communicated back and forth. If it’s voice over IP, we have real time protocol. So all of these are things that we have to be familiar with, as well as all the applications and services. And the applications get us up into the web browsing capability and file transfer and remote access and all sorts of services, the DHCP services that are available for us. Some of the other network security issues are things like the domain name service DNS. It wasn’t that many years ago that Dan Kaminsky published a really scary vulnerability that we have in DNS servers that affected by the way, every single DNS server out there, regardless of who the vendor was.

Not only that, but for the most part that vulnerability still exists.Now companies like Microsoft have tried to come up with plans and ways to be able to prevent this DNS cache poisoning that Kaminsky found. But that’s just another example of some of the network security issues that we have to be aware of. I guess what I’m saying at this point is we have resources. We have to identify and possibly use them. But these resources that we’re talking about here are resources for communications. And guess what? Yes, we do have to develop potentially an incident management plan and response plan to deal with these types of weaknesses. Wow. We get into the operating systems. What is your corporation using? There’s all sorts of flavors of Windows on the server technology still currently in use 2003 and 2008 and whatever is coming in the future.

Operating systems can range. Hopefully no older than Windows XP and Windows Vista. Windows Seven. But we still have other operating systems besides Microsoft. A variety of Linux flavors, unix mainframe type of technologies, SNA communications with some of those IBM types of mainframes. So we have to be able to also be thinking of that in our response plans and management. Oh, the extent of malware capability. I got to tell you, malware is just evolving like crazy. The things that we can do with malware, with all of the abilities to offer remote access into systems or to send buffer overflows and start doing remote command executions, it’s crazy the stuff we can do. I mean, ten years ago, our biggest concern really was a virus that might corrupt some files, denial of service attacks, that’s what we had.

But boy, it’s absolutely gone crazy. In fact, one company I do, some use their product. The company is called Core Security. They got this tool called Core Impact, and it kind of helps. I think. Give me an illustration to give you about the extent of malware. Now, it’s not malware. It’s designed for you to be able to do penetration testing. But they have a variety of types of attacks that they have created on their own to take advantage of vulnerabilities to see if they could exploit it. Many of these attacks will take remote control over that system. And what they do is they install an agent on that system and then from that agent, that agent is communicating back to them, which usually means it traverses your security setups that you have because most often we allow communications from inside the network to come out.

It’s the ones coming in that we’re very restrictive of. And so now it communicates back to home. And then I can upload all of my attack tools, and I do mean all of them, if I wanted to, into that server that I’ve just taken over that is now inside of your network and then launch those same attacks from the inside, where I’ll have much more success because I’ve already circumvented your perimeter security. So why did I bring that up? Malware of many sorts can do the exact same thing. And that just is trying to help you understand the complexity of today’s malware, what it can do. And of course, we also need to have the skills of programming.

Programmers, I believe, can be some of the most dangerous hackers that are out there. Because when it comes right down to it, if I’m working at auditing and doing a penetration test, I’m using software that other people have created to be able to try to manipulate and take over systems and to see if I can break in and how strong those are the skills of programming. I think when people know how to create scripts, use a variety of languages that work very well against the Windows operating system, against the Linux and Unix operating systems, I mean, really, we have to be careful. So we have to plan for all of these types of things that would be included under the, you know, technologies that we have to be aware of.

• Category: Uncategorized