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:
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.
Just wanted to let you guys know how much of a help this article was. I was tearing my hair out when my boss told me we would have to put a CAS Exchange box in the DMZ even though MS doesnt support it. Now we have some other options.
Travis, We are glad that the article was of help to you.
I wanted to ask on question on this topic as I could not find a clear answer anywhere. The are many references to using the ISA server in the DMZ, but my experience of ISA has been to use it as a firewall either between my private LANs and DMZ or from the public Internet and my DMZ. Would it be correct to assume that this article is using an ISA server exclusively as a DMZ server with no network interfaces directly in the private LAN space?
This leads me to my comment. In my new build out, I have been faced with this exact task, how do I secure my Exchange server resources that are required to have a public facing prescience? The one solution I come up with time and time again is what I believe will be the best option. Mainly because ISA (and its predecessor Threat Management Gateway) are discontinued by Microsoft… albeit, TMG will be support until 2020. Still, I wanted something that would be more future proof.
For everyone struggling as I did, I found what I believe are the perfect set of articles on Microsoft’s TechNet blog. The articles describe how to configure a reverse proxy solution using IIS and Application Request Routing. Keep in mind, this will NOT address SMTP traffic.
I hope these prove to be as valuable to others as they have for me!
Part 1: Reverse Proxy for Exchange Server 2013 using IIS ARR
Part 2: Reverse Proxy for Exchange Server 2013 using IIS ARR
Part 3: Reverse Proxy for Exchange Server 2013 using IIS ARR
Thank you Matthew, that does seem like a good option to TMG.