RE: Exchange Information Store Security? Send As...

• Previous message: Stuart Fox (DSL AK): "RE: Exchange Information Store Security? Send As..."
• Maybe in reply to: A. Bluecoat: "Exchange Information Store Security? Send As..."
• Next in thread: Glenn Pearl: "RE: Exchange Information Store Security? Send As..."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Thu, 3 Jun 2004 05:51:13 -0700
To: "A. Bluecoat" <abluecoat@hotmail.com>, <focus-ms@securityfocus.com>

Hello.
You have good instincts!

I'm no Exchange expert, but it would seem to me that giving trusted
server access to a user's application amounts to betting the security of
the server on the security of your user's application. Has it been so
thoroughly tested that you're comfortable with this? Does it run on
dedicated hardware in a secured location? If someone steals the hardware
it runs on (or spends a few minutes alone with it), what compromise
would be possible? Are the required Exchange Server credentials stored
on the client? (Insecure credential storage is a frequent flaw in the
security design of client-side applications.) Is the user's client
exposed to the Internet? What would happen if the user's special
software, or email client, were infected by a worm or virus? Do you
trust the user himself with what could easily amount to system
administrator rights?

Possible mitigations
1 --- After testing the application, allow it to run on dedicated
hardware in a secured machine room. Monitor the output for unexpected
behavior. This monitoring should be assigned to a system or network
administrator as an ongoing task, and tracked. In other words, take the
work as seriously as you take your daily backups. This may require
adding a worker or charging back the cost to the user's cost center.
2 --- Find a way to do what the user needs without allowing this
connection. For example, there are 100s of obscure features in Exchange
and Outlook (and other Office applications that integrate with
Outlook)... bulk mailers, e-mail merge, automated responses, advanced
filtering, rules that execute processes on any other program running on
the same computer.... or, with a little programming, any computer in the
domain....
3 --- Blocking strategies: Re-describe the technical problem as a
bureaucratic problem. Most enterprises have strict policies about what
software can be connected to their networks, which tend to be extra
strict in guarding mission-critical servers. If your user is in a
domain, group policy may well prohibit the installation of non-standard
software, which brings in the network administrator. Again, many
enterprises separate the work of network administration from the work of
database administration--even putting them in different departments.
(For example: When I was a dba I worked for Finanace. Network admins
worked for Building and Engineering Services (the same folks who owned
the phone system.) The network admin whose cooperation is required may
be in a different reporting structure that is not subject to the
pressure being exerted on you-effectively allowing you to sidestep a
direct confrontation by referring your user to an enterprise-wide policy
and administrative apparatus over which he has little leverage.

You're doing the right thing. Protecting your server is essential. ALL
your users depend on you-not just the one who wants an exception to
security policy. Managing risk is the core of security, and must be
considered in the broadest possible perspective.

I hope something here is helpful!

Willis Johnson
Microsoft Corporation

-----Original Message-----
From: A. Bluecoat [mailto:abluecoat@hotmail.com]
Sent: Wednesday, June 02, 2004 2:23 PM
To: focus-ms@securityfocus.com
Subject: Exchange Information Store Security? Send As...

Hey all,
I have a user with an application and userID that needs Send As and
Administer Information Store access on our Exchange servers. I've found
one
doc that advises against granting Send As to a single user but nothing
real
specific about why not - what are the risks? I understand it's best
practice, but I've got pressure to give an example of "why not?" Any
help
is appreciated. Thanks.

_________________________________________________________________
Getting married? Find great tips, tools and the latest trends at MSN
Life
Events. http://lifeevents.msn.com/category.aspx?cid=married

------------------------------------------------------------------------

---
------------------------------------------------------------------------
---
---------------------------------------------------------------------------
---------------------------------------------------------------------------

• Previous message: Stuart Fox (DSL AK): "RE: Exchange Information Store Security? Send As..."
• Maybe in reply to: A. Bluecoat: "Exchange Information Store Security? Send As..."
• Next in thread: Glenn Pearl: "RE: Exchange Information Store Security? Send As..."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]