Placement of Exchange FE/CAS Servers in a PCI Compliant Environment

A client asked a great question, and I wanted to share this with others who may be facing the same challenge…

We are in the middle of a re-architecture of many things on our network – one of those being Exchange.

Currently we have just one box for exchange that does everything – all roles.

In the past when I was doing a lot of security audits, Exchange 2003 was the norm and for that there was the concept of a Front-End server which could provide services such as OWA.

Since I started focusing on pre-sales in the Cisco world Exchange 2007 and then 2010 came out and with that came the end of the Front-End OWA server and the beginning of roles.  One of these roles is something called the CAS (Client Access Server).  This is now what provides access to OWA, Outlook Anywhere services, etc.

Microsoft has written many articles about how they strongly advise against locating the CAS server in a DMZ or perimeter network:

http://blogs.technet.com/b/exchange/archive/2009/10/21/3408587.aspx

http://blogs.msdn.com/b/brad_hughes/archive/2008/05/05/how-not-to-deploy-client-access-servers.aspx

However, this seems to violate PCI 2.0 DSS Requirement  1.3.2 stating “Verify that inbound Internet traffic is limited to IP addresses within the DMZ”

From what I can comprehend – it appears that we must either risk degraded email functionality or break PCI since these two stances seem to completely contradict each other; and I can’t find anyone online discussing this obvious contradiction.

In all of the work that you say your PCI team does I would think they would have run into this by now and was just curious to hear their approach on how to tackle this extremely annoying scenario that Microsoft has created.

Let me know if anyone has any ideas…?

This is a great question, and yes, we’ve dealt with this several times.  There are actually two aspects to this…  First, there’s the question of whether your Exchange infrastructure needs to be considered in-scope for PCI at all.  Maybe you’ve already gone through those considerations, but we often see people able to leave the Exchange systems out of scope if they’re properly segmented from the Cardholder Data Environment and there isn’t any cardholder data being handled by email (which can cause all sorts of compliance challenges anyway).  If email is not used to transmit credit card numbers and those systems are properly segmented away from systems that do handle cardholder data, those email-related systems can likely be left out of PCI scope entirely.

The second aspect is the part you asked about – how to address Microsoft’s recommended deployment guidance as well as PCI DSS requirement 1.3.2.  The answer is actually contained within the two sites you sent links for (above)…  Microsoft recommends that you deploy a reverse proxy (i.e. ISA Server) in the DMZ.  The reverse proxy can be used for pre-authentication and can then communicate securely with the CAS server, which can be left on the internal or server segment.  This is in support of DSS requirement 1.3.2 because the only thing that is actually exposed to the Internet is the proxy server, which is in the DMZ.  The CAS server is only accessible internally, or from the proxy server over port 443 (which can be allowed through your firewall).  As an added benefit, you can use the same proxy server to help control your outbound traffic (per DSS requirement 1.3.5).

Excerpt from the first web page linked above:

The best way to deploy Exchange CAS with respect to a perimeter network is to put a reverse proxy you trust in the perimeter, configure the firewall between the perimeter and the intranet to be as restrictive as possible and to host the CAS server on the intranet. This will get traffic inspection and other reverse proxy security filtering in place in the perimeter.

As extra defense, you can also configure pre-authentication to be done on the reverse proxy. This might not be possible for all Exchange protocols if you want to expose some advanced functionality like Exchange 2010 Federated Free/Busy and Calendar Sharing to the Internet (see Understanding Federation and Understanding Federated Delegation for details about these features). But you can configure the pre-authentication for as many clients and protocols as is supported by the reverse proxy and the scenarios you want to enable.
Excerpt from the second web page linked above:

Our guidance recommends that an ISA Server or another reverse proxy server be placed in the DMZ to handle requests for Internet Exchange Services such as OWA and ActiveSync.  ISA 2004 and later allows ISA to operate in a Workgroup (non-domain) configuration and still pre-authenticate requests to Active Directory.  This ensures that no unauthenticated traffic is ever passed to the Client Access Servers and also ensures that every URL and request is processed and scanned by ISA URL Filtering/Scanning/and IDS feature-set.  This allows for a single port to be opened up (443) to each Client Access Server in the internal network (to allow ISA Web publishing) and is the most secure configuration by far.

Jeremy Simon, PCI QSA, CISSP, CISA
Practice Lead, PCI Compliance Services

HALOCK is a cyber security consulting company headquartered in Schaumburg, IL, in the Chicago area and advises clients on information security and conducts PCI preparedness assessment, scoping, remediation, validation, and compliance maintenance services throughout the US.