Secure Messaging with Microsoft Exchange Server 2000

2017-07-07 02:10:07

There are a number of models for identifying and quantifying information systems risks. Most of these models require a fair amount of specialized training to be useful, because performing a strict risk assessment involves a number of fine points that are well beyond the scope of this book. However, before you rush off to hire a Certified Information Systems Security Professional (CISSP) to do your risk assessment (not that doing so is a bad idea by any means, as long as you hire one with a background in risk assessment), wouldn’t it be helpful if you could evaluate your risks yourself? You can do so to a good degree using the two risk assessment models I present in this section; the models help you begin to identify and quantify various threats and risks to your information systems well enough to start fixing the most serious ones. In fact, I suggest you apply the two models in combination.

The STAVE Model

This model doesn’t really have a formal name; I made up STAVE because it’s pronounceable. The key elements of risk assessment described in the CISSP curriculum and in Krause and Tipton’s Information Security Management Handbook, however, revolve around the five elements in STAVE, so it’s worth presenting them here to give you a stronger conceptual framework. The five elements of STAVE are simple to understand: safeguards, threats, assets, vulnerabilities, and exploits. However, for maximum understanding, let’s talk about the STAVE elements in a slightly different order, beginning with the assets and working our way through the elements that indicate what risks those assets face and how we can fix them.

Assets

Assets are something valuable that you have; they can be tangible or intangible. If you don’t have any valuable assets, it’s probable that no one will attack you on purpose. Of course, being asset-poor doesn’t mean that you won’t be attacked, merely that you won’t be an intentional target. The more numerous, valuable, or irreplaceable your assets are, the higher the likelihood that they’ll be attacked. Notice that in this context, asset doesn’t just mean a physical object or a juicy piece of information; some of the most valuable assets of sites of organizations like CNN and the New York Times are their perceived trustworthiness and integrity.

Assets have a value associated with them. In the case of a physical asset like a building, a stack of gold ingots, or a fighter plane, the value is pretty easy to calculate. For an intangible asset, like the value of a complete database of your company’s customers over the last 15 years, the value might be much more difficult to pin down. Having said that, getting relatively accurate asset values will help you clearly identify where the biggest potential risks are. A small risk of losing a highly valuable asset might be more important than a larger risk to a less valuable asset.

Threats

A threat is something bad that can happen. The exact set of threats you should worry about varies from asset to asset. For example, one of my clients is a large law firm located in a downtown area that occasionally floods. Because the company is located on the 37th floor of the building, the primary concern isn’t the physical computer assets; it’s the value of the company’s data and of its reputation as a trustworthy guardian of the legal records it maintains.

Along with identifying the threats themselves, you need to be able to prioritize them in some way. This could be done by severity (for example, if this threat occurs, how bad will the effects be?), by likelihood, by frequency, or by some other criterion that’s specific to your business. Brainstorming with a list of assets is a great way to develop a prioritized threat list. Draw all of your assets on a chart and then start listing threats to each of them. There might be more threats out there than you realize!

Vulnerabilities

A vulnerability is something that allows a threat to apply to an asset. In other words, a vulnerability is a weak spot that, if not mitigated, allows an attacker to use a specific threat to damage or gain control of a particular asset. Vulnerabilities can be anything that an attacker can exploit: unlocked doors, unpatched workstations, users who keep passwords in plain view, and flaws in installed software are all-too- common vulnerabilities.

Identifying vulnerabilities can be tricky. Some are obvious (like the notes with passwords on them), but some are much more subtle. In fact, attackers can, and do, expend large amounts of time and effort finding new vulnerabilities and using them before you, or the vendors who make the products you use, can find them. For that reason, you cannot always count on being able to eliminate vulnerabilities; in some cases, the best you can do is mitigate the ones you know about and try to proactively protect yourself against known classes of vulnerabilities. This logic gave birth to the modern antivirus software field.

Hold It Right There!

A brief pause in our discussion of the STAVE model is necessary because there’s a simple but subtle point to make here: eliminating assets, threats, or vulnerabilities reduces or removes any particular risk. Let’s say that you do such a good job of securing your Exchange systems that you get a fat bonus, which you use to buy one of those fancy plasma-screen TVs. You install it in your living room in such a way that it can be seen from the street. You are in the habit of leaving your front door open, with only the glass storm door keeping intruders out. Let’s analyze your risk based on what we know:

The asset is your spiffy new TV, valued at about $7,000. It’s even more valuable to you because your spouse is very unlikely to let you ever buy another one, so you want to hang on to it.

The threat is having someone steal the TV by entering through your open front door, or by breaking the cheap lock on the door while you’re not at home.

There are several vulnerabilities: your habit of leaving the door open, the open door itself, the flimsy locks on the front and back doors, and the lack of an alarm system. The reason I cite the door-open habit separately is simple: without proper attention to processes and education, the best safeguards in the world will be ineffective because administrators and users will fall back on their old, insecure habits.

You can mitigate this risk by doing one of three things. First, you could fasten the TV to the wall, making it more difficult to steal even if a thief manages to break into your house. Second, you could move to a town with a lower occurrence of theft. Finally, you could address the vulnerabilities by changing your security procedures, remembering to close the door, closing your curtains, and upgrading your locks. Doing any of these things greatly reduces the risk to your asset; doing several of them virtually eliminates it. Notice that not all of these proposed mitigating measures are really practical, though—clearly, addressing the vulnerabilities is the best place to start.

What does your fancy TV set have to do with information systems security? Using risk assessment to drive security choices acknowledges the compromise between risk and cost. The cost and trouble associated with moving is far too great just to reduce the risk of someone stealing your TV. However, it probably is worthwhile to close your windows and upgrade your locks. You cannot wave a magic wand and make all potential threats magically disappear, although you can (and should) work to minimize any threats over which you have control or influence. The biggest win for administrators is to clamp down on vulnerabilities; we’ll talk more about the specific process for locking down Microsoft Windows 2000 servers in Chapter 6, “Windows 2000 Server Security Basics.”

Exploits

A vulnerability by itself isn’t particularly interesting. An exploit, alas, is a different story; it’s a piece of code or behavior that takes advantage of a particular vulnerability. The difference between an exploit and a vulnerability is slight but significant. If you forget to close the telnet port on your firewall, that’s a vulnerability. If someone uses it to hack your server, that’s an exploit.

Unless you’re the one doing the hacking, you probably won’t have any control over exploits aimed at your machines. However, every time you fix or remove a vulnerability, you’re rendering useless all the exploits that use that particular security gap.

Safeguards

Safeguards are just what their name implies: they are procedures, devices, or programs designed to safeguard assets against threats and exploits. Some safeguards are preventative, whereas others are designed to limit the potential damage from a known or suspected vulnerability. Safeguards are all around in the systems we use today. Banks use safeguards like armed guards, surveillance cameras, big steel vaults, and serial number tracking. Computer systems use safeguards like strong password policies, smart cards, and security auditing logs. A good risk assessment clearly identifies what safeguards are currently in place and what they safeguard against. A better one also points out new or modified safeguards that can help reduce the danger from the risks identified in the assessment.

The STRIDE Model

Microsoft uses a different, more specific model to guide their internal security processes, including design and security reviews. The STAVE model is a good framework for general security concepts; Microsoft’s model, called STRIDE, is normally used by developers and designers to identify and resolve security issues in their application code. STRIDE is useful for us, too, because we can use it to evaluate the potential risks to a messaging system with only slight modification. The six letters in STRIDE each represent a particular risk. Those risks, and their effects on Exchange, are as follows:

Spoofing user identity I’ve already mentioned spoofing, but the STRIDE model talks about it in the specific context of an attacker who can impersonate another user. Spoofing rears its head in two ways within Exchange. One is usually legitimate; Exchange allows users to delegate access to their mailbox, so that another user can send mail on the mailbox owner’s behalf. The other, Simple Mail Transfer Protocol (SMTP) spoofing, is difficult to guard against, because SMTP wasn’t (and still isn’t) designed to offer any significant degree of security.

Tampering with data An attacker who maliciously changes data is often much harder to detect, and does much more damage, than a smash-and- grab Web site defacer or disk reformatter. Why? First, you might not find the modified data until some time has passed; once you find one tampered item, you’ll have to thoroughly check all the other data on your systems to ensure that nothing else was tampered with. Modifying data in Exchange requires the correct privileges, which means that this particular threat is usually coupled to privilege-escalation attacks.

Repudiation Remember the discussion in Chapter 2, “Security Protocols and Algorithms,” of how digital signatures provide nonrepudiation? The R in STRIDE stands for repudiation, and it represents the risk that a legitimate transaction will be disowned by one of the participants. This isn’t a direct threat to Exchange messaging systems; however, if the systems are used for business transactions, the risk that a transaction will be repudiated exists. Without digital signatures, it’s trivial to forge transactions, and most people understand this. Unfortunately, that widespread understanding means that the unscrupulous have a ready-made claim for repudiation: “I never sent that e-mail! Someone must have forged it.”

Information disclosure In the STRIDE model, information disclosure means that an attacker can gain access, without permission, to data that the owner doesn’t want him or her to have. This is a very broad definition; one of your jobs is to refine it by specifying which kinds of information disclosure worry you. For example, most sites aren’t worried about the fact that the Exchange SMTP server identifies itself as such, but some are. On the other hand, almost no company is willing to allow individual users or administrators to have unfettered access to each others’ mailboxes.

DoS DoS attacks make it impossible to use a resource. They’re tricky to defend against because they involve the overuse of legitimate resources. You can stop all such attacks by removing the resource used by the attacker, but then real users can’t use the resource either. In addition to common DoS attacks against the network or Windows components, Exchange is vulnerable to DoS attacks that attempt to consume all of the disk space on the drives where the information store databases are located.

Escalation of privilege Exchange itself depends on the underlying Windows authentication system, discussed in Chapter 3. You might think that this makes Exchange less vulnerable to privilege escalation attacks; the truth is that this dependency doesn’t make it any less vulnerable. An attacker who can successfully escalate his or her privileges might be able to use those privileges to gain elevated access to Exchange, depending on how you’ve assigned Exchange permissions. This topic is worthy of more discussion, so I cover it in more detail in Chapter 7, “Installing Exchange with Security in Mind.”

The STRIDE model is quite useful as a way to help build a taxonomy of threats. As you list the risks to your Exchange systems (as we’ll do in the next section), you can pigeonhole them into one of the six STRIDE categories, giving you a convenient roadmap of the threats and risks you’re most likely to face.

Asset and Threat Assessment for Exchange (or, What Would You Like to Not Lose Today?)

Part of risk assessment is identifying the assets you have to lose. Even a quick, back-of-the-envelope inventory is better than nothing, but the more time and effort you put into your inventory the more useful it will be to you. Of course, you have to put a commensurate amount of effort into identifying the threats you face, too, so that you can adequately assess the risks to your assets. The particulars will vary according to your operations, but the overall principle is the same.

Asset Inventory

Make a comprehensive list of your assets, informational or otherwise. Some will be obvious, like the server and network hardware that hosts your Exchange infrastructure, or the stored message data in your mailbox and public folder stores. Some might be less obvious: Have you considered the value of data that is on your backup tapes? What about the information value of message headers? Here are some specific questions to ask to guide you in this process:

Which assets, if lost, would result in a cessation of normal business activities? How long would that cessation last, and how could you recover from it? For Exchange, this usually includes stored mailbox data, but it can also include documents or records stored using Exchange’s Web Storage System. It might also include permissions or security data.

For any particular asset, what would happen if you lost access to it for 15 minutes? For an hour? For a workday? For a work week? For an entire month? Your answers to these questions must be specific, and should include objective cost or loss figures. Knowing exactly how much it costs to be without e-mail for a day is a wonderful way to figure out which availability and security measures make sense.

Which assets could potentially be compromised without you knowing it? The best example is probably communication links, because they can generally be monitored without either endpoint becoming aware of the monitoring. Other examples include WLANs and traffic to and from cell phones or other devices that can wirelessly send and receive e-mail.

If they were compromised or leaked, which assets could provide useful, nonpublic information to competitors? Which of those assets can be restricted so that their competitive value is eliminated or reduced? Any message-related data that leaves the company falls into this category. That includes messages that have to transit networks (including the Internet) that you don’t control.

Which assets, if disclosed, would make attacks on other assets possible? User credentials and passwords are one obvious example; so are unprotected backup tapes, DNS data, and other seemingly mundane materials like organizational charts. (There’s a reason why the old Soviet Union classified their phone books!)

Which assets have intrinsic value? These are the assets of greatest interest to an attacker. Companies that deal with high-value transactions like oil and gas leases, commodities futures trades, and the like obviously have lots of these, but so do companies that make expensive manufactured goods or components.

Which assets are you legally or contractually required to maintain? What happens if you fail to maintain them? Health care companies face stiff penalties if data about their patients is compromised, and many other industries have similar regulations. If compromised, what other assets might make it impossible to meet those requirements?

Which assets lose value if their integrity is compromised? If a newspaper prints a false story, the costs go far beyond the cost of the paper and the ink. If a stock exchange occasionally forgets trades, the reputation of the stock exchange is permanently damaged, costing far more than the value of the transactions. Damages to some assets can be more complex than total destruction.

Once you’ve identified the assets and the potential loss associated with each of them, you’re ready to start asking some harder questions. For each asset, ask these questions:

What threats exist to that particular asset? (Do you even know which threats might exist? If not, this is a terrific time to find out!) Are there threats that might cover multiple assets, or even classes of assets?

What vulnerabilities enable the threats you just identified? Be sure to include vulnerabilities caused by poor security processes or lack of user and administrator education; it’s tempting to blame every vulnerability on the software vendors, but that misses some of the biggest, juiciest weak spots.

How frequently can you expect these vulnerabilities to be exploited? This is a hard judgment call to make, because the frequency of exploit will depend on a number of variable, hard-to-determine factors: How public is your site? Is there any special reason people might target you? Do you have particularly valuable, sensitive, or controversial data?

What safeguards can you apply to mitigate the threat; avoid, reduce, or transfer the risk; or block the vulnerability? Obviously, closing off vulnerabilities is the most effective safeguard in most cases, but you might not always be able to address every vulnerability in that manner.