Security in a networking environment first starts
with considering the importance of a security model within the
networking environment. Part of the security model involves internal
security practices, and a portion of the security model depends on the level of security built in to the technology products being implemented.
When
implementing Exchange 2007 with security in mind, a lot of the security
infrastructure is dependent on the security built in to the Windows
2003 network operating system as well as the Exchange 2007 messaging
system. Microsoft plays an important role in establishing a secured
messaging environment from which an organization can build its security
infrastructure.
An organization must then
assess its risks and develop a security strategy that is customized to
address the risks identified by the organization. Within Exchange 2007,
the administration function of the Exchange messaging system is based
on administrative roles in which an administrator allocates roles and
levels of security access to other administrators and support personnel
in the organization.
Microsoft’s Trustworthy Computing Initiative
As
the largest software company in the world, Microsoft has always been a
target for people who thrive on hacking computer systems, whether they
are doing so simply for the challenge, or with malicious intent.
On
January 15, 2002, Bill Gates announced the “Trustworthy Computing
Initiative” that focused the company in a new direction. The goal of
this initiative was to create reliable, secure, and private
technologies and committed the company to making products that protect
user privacy.
Now, Trustworthy Computing
is no longer an initiative; it is a corporatewide tenet that guides the
development and maintenance of their products from the moment they are
imagined until they are no longer supported. This new way of doing
business has resulted in a significant reduction of publicly reported
vulnerabilities in Microsoft products across the board.
Secure by Design
Under
the Trustworthy Computing Initiative, a process has been implemented
known as the Security Development Lifecycle, otherwise known as the
SDL, which requires Microsoft developers to create formal threat models
when they begin the design of a product. No longer are products
envisioned and developed with potential security risks addressed as an
afterthought, now all products, including Exchange 2007, are developed
with an eye toward secure computing from the drawing board.
As
an added measure, before a product ships, it is submitted to a final
security review, or FSR, where a team of security experts review it to
answer just one question—From a security perspective, is this product ready to ship?
Secure by Default
With
older versions of Exchange (prior to Exchange Server 2003), the
products were shipped with an “implement first, secure after”
philosophy. Many services and functions were enabled by default, regardless of whether they would eventually be utilized in an environment.
With Exchange 2003, and now Exchange 2007, the opposite approach has been taken—by default, many services and functions are disabled
at the time of installation, only to be enabled by an organization if
the determination is made that the function is needed. Thanks to this
mentality, organizations are less likely to have features unknowingly
enabled that might present a security risk.
One
such example is access to email via RPC over HTTP. To allow users to
utilize this functionality, it must be enabled on each server where the
user’s mailbox resides. By default, this technology (now known as
Outlook Anywhere) is disabled.
Secure by Deployment
Microsoft
provides applications and documentation that enables information
technology (IT) personnel to implement Exchange 2007 securely and
successfully. These tools enable an administrator to ensure that all
network prerequisites are met, and that the environment is properly
configured and ready to accept the implementation of Exchange 2007.
Microsoft
also provides training resources to ensure that administrators are
adequately prepared to deploy Exchange 2007. These training resources
should be reviewed by any organization implementing Exchange 2007, and
should be made available to administrators prior to implementation of
the product to ensure a successful deployment.
Assessing Your Risks
It has been said that “The only completely secure computer is one that is turned off—and even then, only if no one can find it.”
As
with most jokes, there is some underlying truth to the statement or it
wouldn’t be funny. Any computer that is accessible to authorized users
is potentially accessible to malicious intruders. When designing
security around particular subsets of data, you must strike a balance
between security and usability—if you make the environment TOO secure,
it is too difficult or time-consuming for valid employees to access the
data.
In addition, an organization must
consider the value of the data that they are trying to protect. For an
email environment, this can be a particularly challenging task, as the
actual value of the data contained can be difficult to assess. However,
asking yourself “How much would it cost the organization if our email
was destroyed, altered, or stolen?” and assigning an accurate monetary
value to the data will help you determine how much you can feasibly
spend to protect it.
The next step in
assessing your risks is to analyze possible security vulnerabilities
for the service or functionality with which you are working. The
following is a list of some areas of security that you should take into
consideration:
Viruses or Trojan horse messages—
Viruses have existed in the computer world long before the first email
message was sent. However, just as email provides users with an easy
method of communication, it also is an extremely efficient method of spreading
malicious or troublesome code. Once considered the largest problem that
email administrators had to face, viruses have been combated by an
entire industry devoted to their prevention.
Spam—
The proliferation of unsolicited messages, often referred to as “spam”
mail, has truly become the bane of the messaging world with recent
estimates stating that spam accounts for 85%–90% of the messaging
traffic on the Internet today. These unsolicted, usually unwanted, and
often offensive advertisements cost companies and users billions of
dollars annually in lost time and productivity. Unfortunately, because
sending bulk messages to thousands (or millions) of recipients can be
accomplished with very little expense, offending companies do not need
a large response to maintain profitability. It is sad to note that as
long as this method of advertising is profitable and effective, spam
will be with us to stay. Fortunately, Exchange 2007 has several
features to help alleviate the problem.
Address spoofing— One tool that is commonly used by the distributors of both viruses and spam is known as address spoofing.
By changing the From line in a Simple Mail Transfer Protocol (SMTP)
message, users can often be fooled into opening a message that they
think is from a friend or co-worker, only to find that the message
originated somewhere else entirely. This method has been especially
effective in the distribution of email worms. Because the message
appears to come from a known associate, and often has an intriguing
Subject line, the unwitting recipient opens the message and, if not
properly protected, becomes a distributor of the virus to others.
Phishing— Over the past several years, a relatively new type of fraudulent email has emerged. Known as phishing,
this attack comes in the form of an official looking email message,
often appearing to be from a reputable organization, such as a credit
card company or a large electronics retailer. The message usually
contains a link that, once clicked, brings up an official looking
website—often an exact replica of the official site that is being
mimicked. However, the fraudulent site has one purpose, to fool you
into giving away personal information, such as passwords, credit card
numbers, or Social Security numbers. With this information in hand, the
offending party can steal your identity, make charges to your credit
card, or otherwise profit from your loss.
Exchange Server 2007 Administrative Roles
In
Exchange 2000 Server and Exchange Server 2003, there was not a clear
separation between administrators of users in Active Directory (AD) and
the administration of Exchange recipients. Utilizing the previous
model, based on predefined security roles, administrators had to be
granted high-level permissions to the Active Directory environment to
perform even relatively simple Exchange recipient–related tasks. In
addition, the majority of Exchange recipient management had to be
accomplished utilizing the Active Directory Users and Computers utility.
Exchange
2007 has implemented much greater logical distinction between these two
environements. Utilizing newly designed administrator roles,
organizations can assign administrators permission to perform
Exchange-related tasks, while minimizing their ability to directly
modify the Active Directory itself. Furthermore, the majority of
mail-related configuration items can be administered directly from the
new Exchange Management Console and Exchange Management Shell.
This
is important to Exchange security because you no longer have to grant
administrative privileges over your Exchange environment to domain
administrators (who might not have worked with Exchange at all). On the
other side of the same coin, Exchange administrators can be granted
permissions over the Exchange environment, yet remain restricted in
Active Directory. This enables organizations to limit areas of
responsibility based on proper administrator aptitude and abilities.
Table 1 lists the new Exchange 2007 administrator roles and the Exchange permissions associated with each.
Table 1. Exchange 2007 Administrative Roles
| Administrator Role | Members | Member of | Exchange Permissions |
|---|
| Exchange Organization Administrators | Administrator, or the account that was used to install the first Exchange 2007 server | Exchange Recipient Administrators
Administrators local group of <Server Name> | Full control of the Microsoft Exchange container in Active Directory |
| Exchange Recipient Administrators | Exchange Organization Administrators | Exchange View-Only Administrators | Full control of Exchange properties on Active Directory user object |
| Exchange Server Administrators | Exchange Organization Administrators | Exchange View-Only Administrators
Administrators local group of <Server Name> | Full control of Exchange <Server Name> |
| Exchange View-Only Administrators | Exchange Recipient Administrators | Exchange Recipient Administrators | Read access to the Microsoft Exchange container in Active Directory. |
| | Exchange Server Administrators (<Server Name>) | Exchange Server Administrators | Read access to all the Windows domains that have Exchange recipients. |
