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

20. Responsibilities Part1

When we talk about responsibilities, there’s usually, I guess you could say, a number of incident management responsibilities that we have to undertake and one of those and again the security manager might be tasked with having to get this set up. But one of them starts off with just saying that somebody has to develop the Is incident management and response plans. All right, again if you don’t have a plan then you’re going to have chaos. You are not going to have we talked about having a set of steps or what we call them actions earlier that we may have to take for certain types of events that come up. But we also know that somebody has to be responsible for coordinating the response activities to handle if you think the plan, there’s people who are going to handle the actions and somebody who’s going to be coordinating the different teams.

Because as I mentioned before, a problem with not accessing a database could be the server, could be the network, could be both. Maybe we have a virtual machine we need to move. I mean there’s so many things we could come up with as analogies. But the goal through coordination and handling it is that we want them to be effective and efficient. Now efficiency is a big deal. Effective? Well, I’m not saying effectiveness isn’t either, but often we are under a big time constraint. Lack of efficiency could end up wasting more time and that could become a new event that you have to deal with because again, we often talk about that maximum tolerable downtime. The other part of this of course, is having a method of validating, verifying and reporting of the protective or other type of countermeasure that you’re using.

All right, so let’s think about this validating. All right, so if your goal here is to protect yourselves from the people on the internet and one of your first lines of defense is what we often look at as a firewall, how do you validate that it is working? How do you verify that it’s working within the aspects of what you want and how do you get information from it so that you can report on how well it’s working? Well, there’s a number of different ways. Certainly through auditing we could validate or verify the security as we think and certainly through the logging of that device we can get the reporting. And so that’s again a part of some of the responsibilities that we should be looking at. And of course we also have to take a look at it from a planning budgeting and program development.

If we were to say, all right, we’ve done some of the verification, we see that maybe there’s still some issues, maybe we need to go and invest in something like an intrusion prevention system. Well that does take planning. We just don’t drop one of those in line. Remember, sometimes you can have too much security, meaning that you could shut down all access to data completely, which I guess, if you were trying to stop a hack, would have done it. But it doesn’t make that information highly available. Often budgeting is of an importance because we’re going to ask those questions about cost and cost. And budgeting comes with so many other things besides just the equipment, but the service contracts, the amount of time it takes to install the test, to set it up in the lab environment, move it to production, train people on how to use the product. And I could go on, which all of that, I guess you could say, kind of comes down to the program development.

21. Responsibilities Part2

As far as the responsibilities, there can be several approaches to how we do incident response. Now like I said, one approach could be containing the effects to lower or contain the cost. And again that’s just simply saying that we don’t want damages to spiral out of control. Really if you think about that, that’s one of our biggest concerns, right, is what it’s going to do to us. But in some aspects my responsibility, let’s say I’m just an ordinary user that’s supposed to be a little stick figure. If I’m just an ordinary user out there, maybe my responsibility is knowing the appropriate people that I notify for a response. And again, maybe another part of besides notifying, I guess you could also say that another part of my responsibilities is recognizing that there’s an issue out there. How do I do that? How do you accomplish that? Usually through training, hopefully making people’s awareness better.

Some may have the responsibility for quick recovery that may be the person who does the backups and the restores. As an example, it could also be the person that’s in charge of your virtual solutions or what we are now calling your cloud solutions because there’s many tools in the virtual environment through companies like VMware or Microsoft’s HyperV that can assist you with being able to recover a lost server very quickly. As one example with routers, we have a variety of protocols where we can have two routers acting as one router so that if one goes down, the other one can still take care of the traffic. So again, who’s responsible for that? And that’s part of what we’re kind of listing here when we talk about these responsibilities responding systematically to help prevent recurrence.

Okay? So that’s again a part of having the plan is that we have an approach, we have a system that we know we’re going to follow a certain step of actions and we also know that at some point we have to have documentation so that we can try to prevent it from occurring again. Or maybe as I said before, learning that our plan may need a little bit more improvement. And of course outside agencies in some cases we may have to deal with legal issues and law enforcement, whether they’re civil. Certainly there could be some civil issues, especially if you lost consumer data and they might begin lawsuits against you. And of course on the prosecution side of dealing with those who might be stealing information from you.

22. Responsibilities Part3

So the Information Systems Security Manager also needs to be able to define, as I said before, what is a securityrelated incident. Now these are just examples of how they might start saying, okay, well, let’s take a look at what some of these things are. For instance, malicious code. That’s what we used to call the virus and the worm, the Trojans, all the rest of it, I guess. Now we just kind of call it malicious code or malware. Unauthorized access to resources. This could be from internal or external threats. Internal threats, like I said, could be that disgruntled employee who’s maybe doing some of their own corporate espionage. That’s where we would talk a lot about auditing lots of systems up there to automatically audit access to these resources. A resource, by the way, is not just a file. It could be a server itself. It could be a number of different things.

Even maybe the unauthorized use of voice over IP to call numbers that have a charge on them. Unauthorized changes. We do a lot of discussion in the world of is about change control and that there should be a process for change control. One of the things I remember, and I’ll just use this as an example, is if we were talking about doing some use in Active Directory, and I had a printer over here in my network and there’s a group of people, an Active Directory group that has permissions to use that printer. And then I’ve got some guy from the mail room that says, hey, I need to print that printer. And your administrator says, well, this is easy, I’m just going to throw you in that group so you have permission.

All right, was it an authorized change? Well, why does it matter? Well, that group might also have permission to go to a part of your assets, your bank that can start issuing out loans or lines of credit. And because you put that person in the group that had the printer and that group can also control that line of credit system, then what did you do? You just gave that person ability to make that line of credit change. So now it’s unauthorized, usually because we want to open up some sort of a troubled ticket or something that we can have management look at, have it assigned to somebody, come up with some ideas of changes that we can use or make to to facilitate the ability for that person to use the printer without giving them extra permissions.

And then it goes through an approval process that’s a part of this change control. And of course, I kind of glossed over it at 10,000ft there, but it’s better than just having somebody try to put out a fire with sometimes these unauthorized changes. And of course, that’s one that sounds somewhat benign, it wasn’t done on purpose, but some of those could be misuse. Is another thing that we have to decide as a security related incident. Misuse, again, could be even misuse of your own email systems. We might have what we call the acceptable use policies that we have in place. It could be people using email to again send out maybe corporate espionage secrets, those types of things. Hoaxes and other types of social engineering.

Those are big, by the way. I know I already said it, that social engineering can account for at least 50% of the types of attacks that we have coming against us. And that’s because people are just going to call other people or send them emails to try to elicit information. It could be a hoax. One popular thing is to find a user and send them this email and tells the user. This might be an example of phishing, that their bank account is suspended and needs to be fixed. And so you follow a link, they go to that email, they follow a link and it goes to a malicious server that looks like their bank, but it’s going to steal their information at the same time. It could be my telling you you just won a prize and go sign up.

And by asking them to sign up, unfortunately so many people are going to use their corporate email account and because they don’t want to use a new password or remember a new password, they use the same password as they do from their corporate email account. And even though I’m not trying to attack that person personally, I am basically gathering information from them through a hoax that now I have a username and password to get into your systems. So a number of different things, again, it could be even surveillance and espionage. All of these are examples that we have to define, that the security manager needs to define so they know what a securityrelated incident is supposed to be.

23. Senior Management Commitment

Now in all of the things that we’ve talked about, it is important that we have the commitment of senior management. In fact, that’s crucial for the success of our incident management and response because in some instances it may end up that we have to get a different type of countermeasure. It may mean that we have to take some sort of action actionable type of event against an employee who may have accidentally or purposely cause problems with security.

And the goal is by having their commitment, is to hopefully to be able to lower the cost because we’re all in agreement. And again, by being in agreement, by doing our best to reduce the potential of loss. We’re hoping that it looks to us as though it becomes a good return on investment assessment and all of that are just examples of why we need to have senior management signing off and helping us in the enforcement of incident management. And the responses that we take.

24. Lesson 4: Incident Management Resources

Now, in this lesson, we’re going to take a look at incident management resources. That means resources such as policies and standards understanding the different types of what we call the Incident Response Technology or IRT concepts. The personnel, their roles and responsibilities, the skills they need, the awareness and training about audits internal external and the use of outsourced providers.

25. Policies and Standards

Now, your incident response plan should be backed up by policies, standards and procedures. Now, we could probably get into more depth about the concepts of each of these, but I think at this point that you’re pretty familiar with the idea that policies usually set the framework, the blueprint of what we want to achieve for security. And then from those kind of high level policies, we can form more specifics that result into a bunch of standards that we want to meet procedures as far as how we should actually go about with all of our activities that deal with information services.

26. Incident Response Technology Concepts

Now when we talk about the IRT, again the short way of saying incident response technology and we look at the concepts it starts off with as many security policies would be created on or based on, which is just the basic security principles. Remember that the idea of CIA we often expressed as a triangle or triad where we talked about confidentiality, integrity. And the thing that’s kind of always fun with the A is that it can stand for both availability and authentication. And there’s a few other things that could also be in there, even access control which would be authorization. And remember that usually in the middle of some sort of data or asset that’s important to us. And so our policy should address what we do for each of those factors as just a reminder.

With confidentiality we’re often looking at encrypting communications or data both while it’s being transmitted or while it’s stored on some permanent storage. We usually call it encrypting it while the data is in motion or at rest. The integrity is our way of knowing that data can only be changed through appropriate channels and that we can tell if the data has been changed. And the reason we took this and put it into a triangle is that if you were to move your security closer to the confidentiality and integrity let’s say you kind of focus your attention right there where I put that dot, it’s moving you further away from the availability. Meaning, again, you could have too much security and make your data inaccessible.

And likewise, if you move that too close to the availability and or all points in the triangle, you get the idea that at some point we find that mix that works for what we need, the non repudiation. A lot of that gets us into different types of encryption methods. One that’s popular that’s asymmetric is the RSA type. And what it basically means is that we should also have a system of not only being able to authenticate who sent me an email, but to as an example, somebody sending me an email versus that person not being able to deny having sent me that email. And a lot of times the reason we do that with RSA is that we are using key pairs. So if somebody sends me an email and if they encrypted it with their private key, and I had to use their public key to open it, as long as we trust the certificate authority that issued these keys, then we have non repudiation.

Because the only way I could have opened the email is if it used your private key. So it kind of proves that you sent it to us. And of course the idea here as well of compliance. Like I said, we ought to be looking at the laws and regulations or other standards that may affect our company. And so that’s the basics of what we’re trying to get into when we talk about including this into the technologies, the next area that we look at would be on your security vulnerabilities and weaknesses. Again, that comes from a number of sources. Again, physically it could be an issue. And when I talk about the physical side of it, it could be again, things like the power grid, it could be from theft of our information, physical theft of the actual storage devices.

It could be the technical side where we’ve talked about what we’ve talked about a lot of things. I think we may mention denial of service or maybe some sort of man in the middle attack. But here’s a big one. And by the way, this is one of the things I tell people when I’m teaching a class on firewalls is that a firewall is very easy to get through. It has two major weaknesses and let’s talk about that because they are kind of technical as far as a weakness. So we normally draw a firewall like that where we’re blocking the traffic. I’ve got my web server over here that I’m trying to protect and out here is that dangerous world of the internet where we are used to worrying about the hackers coming in there. The first weakness of a firewall is that it allows traffic. And I know that sounds funny to say, but I want that traffic to get to the web server.

I want the general public customers to get to my services that I offer. That’s great. So we use a firewall, you know, to block, you know, between 95 and 99% of the unwanted traffic but it allows traffic and that means that a hacker could find or craft an attack that works on whatever protocol import that your web server is running on. But the other problem is us, right? The people. And that is on the configuration. We could misconfigure some things, believe it or not. It could be a configuration weakness. It could be that we left it to the defaults. I’ve seen a lot of firewalls that are just plugged in with the default configuration. The default configuration is all traffic on the inside can exit and basically only the reply traffic can come back in.

But then also they’re often left with default usernames and passwords. So that becomes an issue for us. All right, so kind of hit that topic there as well as far as the concepts Internet protocols. Now I just left that kind of purposely vague for the most part. We use what’s called an OSI model to describe the open systems interconnect and we describe the type of method of communications that we use. On one hand, for getting to the different networks, we use an IP address. But of course in today’s world we’re slowly moving to IP version six. We talk about communication protocols like TCP or UDP, but there’s so many others with phone traffic. We’re looking at the real time protocol, RTP, different types of application services like DNS or TFTP servers.

And I could just kind of go on and on with all of the different types of protocols at the different layers that we use. And what’s important to know is that and by the way, even though IPV Six is the latest and greatest, it has a number of vulnerabilities and weaknesses that we have to account for. And you actually should address those issues with all of these protocols. And so even though they’re kind of the common core, all of them like I said, have their weaknesses, much of these were developed in some cases decades ago, some more recent than that, that didn’t have quite the outline of security hazards like we have today. So anyway, again, operating systems. So we know there’s a variety of, even in the world of Windows, there’s a variety of different operating systems both for client and servers.

With all of this by the way, no vendor company I’ve ever seen or worked with or even have read about has ever created flawless software. They almost all have the needs for patches because either a vulnerability or a bug has been found. Or it could again just be a misconfiguration. It might be nothing to do with the operating system. It could just very well be the people who configured it. So what else we have, we have Mac has their operating systems, the Unix range of operating systems, linux, for those of you who don’t want to think of Linux as Unix, which I guess technically you can’t. But anyway, so we have to understand that we need to put these different components into our incident response technology. If you’re not using any Linux servers, then you’re not going to worry about that.

I would say again, malicious code. There’s so many ways of dealing with malicious code. It could be just from putting antivirus software or firewall software on a workstation or directly on a server. It could be host. In that case that was hostbased. It could be network based. Again, also with antivirus or with proxy servers or with intrusion prevention and the rest of those things. We could have some of these network devices sitting up with automation. So network automation so that if a type of an attack was discovered it can quickly send out commands like to a firewall or to some other device to start blocking that attack. And of course all of these devices should be sending off their logging and event information.

Here I could probably ramble on and on and on with so many different examples. The goal by bringing all of this up is that incident response technologies are technologies that we can use to try to either contain, minimize and hopefully stop the actual security event that was reported to us. And we can use these different tools to move us to ultimately what would be something we call the desired state, sometimes called that baseline that I talked about before. Oh, and finally, programming skills as well. That’s typically where we talk about secure coding. And now that’s the one thing I’m not as I’m not a programmer. But I do understand the concept that 2030 years ago, when people were doing programming, they were more worried about efficiency and having very little resources.

I remember one person telling me that when they first started doing programming, they had to deal with one k of Ram. That’s all they had, one k. I can’t even think of a device that uses has so little memory storage. And so they had to be very efficient, and they wrote efficient code that didn’t blow it up the memory. But nowhere did they think about security in those days other than making sure the program didn’t crash based on the type of information that was sent in. But it’s through those programming skills and the idea of secure coding that we can try to reduce the possibility of having other vulnerabilities. And this is very important for you to consider as well if your corporation is doing any type of inhouse application development.

• Category: Uncategorized