Exam 70-124: Objective 6.3: Security Incidents | MCSE/MCSA Implementing and Administering Security in a Windows 2000 Network: Study Guide and DVD Training System (Exam 70-214)

Let's finish this book with some specific information on security, incidents, and problems you could have on your Microsoft network. In considering security incidents, you should ask yourself these questions:

In your current environment, do you have an incident response plan? In other words, will your staff become raving stressed-out lunatics filled with anxiety and anguish when your next incident occurs, or do they know the proper procedure to follow to resolve security incidents?
If you do have a plan of action, is your current staff up to the challenge? Can they handle the problems that occur, and are they trained to deal with any problem in a systematic way?
Can you lead your staff, or do you have a team leader who can guide everyone, during the next incident as it occurs?

If you answer "No" to any of these questions, you could be in trouble sometime in the near future. Let's look at how to deal with each incident and what you need to be responsible for.

Note

If you want to become the know-it-all guru of dealing with security incident response, you need to visit the Cert.org site for more information on the subject. CERT will show you how to build a plan for a Computer Security Incident Response Team (CSIRT) in detail. Check out the site at www.cert.org/csirts/csirt_faq.html.

Other sites you can visit for more information are CERT (www.cert.org) and FIRST (www.first.org).

Minimizing Security Incidents

One of the most pertinent strategies you can implement is to minimize the number and severity of security incidents. One of the biggest issues for security infrastructures is the fact that not a great deal of effort is put into the possibility that there could be a problem. In fact, most times when we come to an organization to resolve issues, the company's IT organization hasn't given security much thought. For that reason, many security problems linger in the darkness of the networks in question. It is your role as a security analyst to truly look at these possible problems and attack them head-on, one by one, in a process of identification and elimination, so that you can minimize the problems before they occur.

Damage & Defense…
Proactive versus Reactive Security Management

Too often, security problems are only dealt with as they occur. Without naming names (for legal purposes), we came in contact with an enterprise that worked in reactive mode, only dealing with issues as they arose. Reacting to problems as they come up never really fixes anything. Doing so is similar to placing a Band-Aid on a chest wound. You never fully learn what the initial underlying problems were, and worse, you never have the chance to head potential problems off at the pass. Consider the differences between reactive and proactive management:

Reactive management When a problem occurs, you simply react to it. The problem was never truly rooted out before it occurred; you might even have prevented the problem had you or your staff identified the possibility that it could occur. This management style is commonly nicknamed firefighting.
Proactive management With proactive thinking, you try to eliminate the possibility of the problem before it occurs in the first place. You strive to think of problems that could occur and implement safeguards to try to stop them before they do so.

You want to work proactively every day to eliminate problems before they occur. In a security sense, this strategy results in auditing of your systems and creating an incident response plan.

Because incidents do in fact occur (it's a fact of life), you need to train yourself to accurately deal with problems and incidents. On a Microsoft-based network, or any network for that matter, you should think of the following items, which we call a top 10 incident prevention list. This list will aid you in minimizing the impact, damage, and stress caused by any security incident that occurs:

Create policies that are written down and backed by management These can include a security policy, a disaster recovery policy, and a business continuity plan. Any plan you create needs to be written down, read by employees, backed by management, and updated constantly. Without these policies, you are missing the backbone of all security enforcement for your organization.
Test everything Now that you have plans and policies, do they work? In other words, if you have a disaster recovery policy that talks about utilizing a hot site, have you actually tried it? Is there a specific time frame in which you want to be operational again, and if so, have you tested or timed your recovery? Most times the answer to these questions is "No." It is essential that you test all your plans and policies to make sure they work before disaster strikes.
Audit and assess your network, systems, and staff on a constant basis Do you know who is accessing your systems? Do you know when they are accessing systems? Do you know who exactly has administrative rights over your entire Active Directory? Who has been delegated rights? You need to know all these things. You need to audit your systems to make sure that you have control over what people can do on them. A good rule of thumb is to audit your critical systems on a weekly basis, at least. After you've done that for a few weeks, you can get an idea of how often you need to audit based on baselined preliminary activity.
Verify your backup and restore solution You should be aware of where backups are maintained, who can access them, and your procedures for data restoration and system recovery. Make sure that you regularly verify backups and media by selectively restoring data. If you don't have verifiable backups, why were you doing them in the first place?
Implement defense in depth If you think slapping up a firewall on the network is your key to security success, you are seriously mistaken and most likely your network is in grave danger. A firewall is probably one of the most important protections on a network, but it is by no means the only piece of the puzzle that you need to implement.
Implement change management solutions You need total control over your network and systems. As a security analyst responsible for your business's infrastructure security, prepare yourself now to bump heads and make enemies. Make sure that every change on the network is documented, and back it up with a backout plan. You would be surprised how many times incidents happen based on your own people making mistakes or covering things up.
Security training is key to continued excellence Establishing security-training programs for both IT staff and end users is essential to keep your networks safe. There is a danger in people knowing more than you might like them to, but that's the point. Educate your users and staff, but make sure you are on top of things as well. Some of the best security personnel worked their way up the ranks from all areas of networking, systems, support, and development.
When you are completely locked down, do an independent audit When you have all your systems to your liking, call in an independent auditor. Have an outside team come in and test your security. This is an important element of your security plan. If you know that a group of security auditors couldn't get through your systems, you have done your job well. If they do get through, you'll gain some starting points for where you need to improve your security.
Build an incident response plan It is essential to create a plan in case everything falls apart. Let's say you lose a file server due to an attacker breaking into the system and deleting the contents of your hard disks. Now what? Make sure that you have a documented plan accessible by the right people (your team) when an incident does in fact occur.
Create a CSIRT A CSIRT is a group of people or a team that you build and give responsibilities for dealing with any security incident. Your CSIRT should consist of members whose duties are clearly defined to ensure that no area is left uncovered in your response. The link provided earlier in the chapter will aid you in building a CSIRT if you are interested in starting one.

Test Day Tip

The preceding list is a feature created for this book. It is not something you will have to master for the exam, but it helps you to think about what you need to do as a Microsoft Certified Professional and a security analyst working on Microsoft (or any other) technology. Because of the scenarios you will see on the exam, an understanding of the fundamentals of network security and analysis is expected; knowing this type of information will help you to figure out what a scenario question is asking. It will also help you to eliminate incorrect answers.

When reading over the top 10 list, you might start to think about new areas you might want to consider. That's good—it means that your thought processes have been stimulated and motivated toward network security.

One other idea you might want to think about is getting local law enforcement agencies involved when creating your incident response team for minimizing security risks. Remember, you are trying to minimize the possibility of security risks, and by having law enforcement visibly on your side, you could deter attackers from even thinking about trying something. This is especially true if you're trying to thwart internal threats, which are more common than external ones. When internal users think that a company might prosecute for damages resulting from an attack, you would be surprised at how quickly games and shenanigans on the network and its systems cease. It also helps to know how the law enforcement agencies operate so that when a problem does occur, you are "in the know" about their polices and procedures, which could speed things considerably.

Hackers

Hackers are not necessarily the cyberterrorists you think they are. The term hacker is actually an incorrect one when used to describe a cybercriminal. The media has come to use the term hacker in a negative way. You should be aware of the proper meaning of the word. A hacker is someone who constantly works on systems, tweaks them, and tries to exploit them for the benefit of higher knowledge and repair. The normal hacker is mainly a network and systems geek. You could say that all who were involved with this book are hackers in the purest sense of the word. You, the reader, could quite easily call yourself a hacker—hopefully the type who can be called a good hacker.

Bad hackers are those who learn tremendous amounts of information about systems and how to exploit them with tools already made or quite possibly with tools they make themselves. The difference between the two types of hacker is what they actually do with their knowledge. Someone who is highly malicious, with an intention to do bad things (such as take down Yahoo.com and cost the business a great deal of revenue) for any reason is not the hacker you want to be affiliated with. Even though that person is obviously very knowledgeable about systems and networks, their malicious side causes them to squander all their knowledge on pranks, mischief, and creating problems for people. These hackers simply want to crack someone else's system or otherwise use their expert programming or system and networking knowledge to cause disruption and harm.

Hacker Jargon

Now that you know what the term hacker truly means, you need to understand some of the different types of hackers:

Cracker A cracker is another name for a bad hacker. A cracker is a malicious person out to do harm or cause problems. Most security folk prefer the work cracker to hacker to refer to such people.
Attacker An attacker is another name for a hacker with bad intentions.
Script kiddie A script kiddie is a malicious person who does not possess in-depth system skills. Script kiddies are knowledgeable to an extent, but they're not experienced enough to build their own hacking tools. Script kiddies do not have a deep understanding of the systems they are trying to exploit, but they are able to obtain tools that superior hackers have built. They use downloadable tools and scripts from the Internet and are very good at creating problems with them.
Click kiddie A click kiddie is a step below the script kiddie. Click kiddies do not have a deep knowledge of systems, but they are able to use simple malicious tools that they can operate with a mouse pointer (hence the term click kiddie).
Black hat A black hat is simply another name for a malicious hacker, cracker, or attacker—in other words, a bad guy.
White hat A white hat is what you are striving to be, thus it is the most important term for you to know. A white hat is a security analyst who learns the techniques of crackers to better protect their own systems. A security analyst for a company is considered a white-hat hacker.
Gray hat A gray hat falls between the white hat and the black hat. The black hat finds a vulnerability and exploits it with malicious intent. A white hat finds an exploit and notifies vendors of the problem. A gray hat finds the exploit and does not exploit it him- or herself, but unlike the white hat who takes the problem to the vendor, the gray hat makes the exploit publicly known so others can exploit it.

Note

No need to worry too much about these terms for the exam. We've included them here so you know what the lingo on the exam means. You can learn more about white-hat hacking at the following site: www.whitehats.com/.

Unfortunately, the terminology can become even more distorted. There are other terms out there, such as phreakers. Stay aware of the jargon because it will in fact become your language in all the meetings, conferences, and day-to-day work-related events you participate in.

You might be asking, "If this material is not on the exam, why is it in this book?" The reasons it is so important that you know this information are:

Each term is used on the test within the scenarios. You are not going to have to repeat verbatim the difference between a good hacker and a bad hacker, but the term hacker is used, and you need to understand it.
Once you are done studying for and have taken (and passed) the exam, you will have become an MCP, and more important, a well-rounded expert on working with Microsoft Network Security implementations. This will enable you to obtain a position in which "walking the walk" and "talking the talk" will become everyday expectations for you.

Note

Make no mistake—you should not be looking at this exam in any way other than wanting to be an expert at deploying security solutions on a Microsoft network. This desire is important to both passing the test and truly learning the trade. This being the case, our goal is to fully prepare yourself not just to pass an elective exam and earn the MCP title, but also to be able to appropriately act and function as a security analyst on a Microsoft network. Business clients, bosses, and peers will hold you in higher regard when you know your technical jargon as well as the technology behind it. Practice the fundamentals of knowing your trade (walking the walk), but also know how to intelligently discuss it with others (talking the talk).