I read the following in the DXL Architecture Guide (page 14) and the way I am reading it just doesn't make sense that it is a security concern ONLY for off network endpoints. It seems like it would be a problem for any endpoint subnet. There may be some key piece of information I am not understanding but the wording is ...alarming.
Production Architecture with a DMZ
The DXL can be used safely for clients that are off network. In the case that TIE functionality is desirable off network, DXL brokers can be located in a DMZ and the DXL port can be exposed to the internet.
Directly exposing a TIE slave is more complicated. For standard TIE queries, the clients do not need direct access to the TIE server. Clients just need to connect to a DXL broker that does have access to a TIE server.
However there is one major exception to this. Uploads to Advanced Threat Defense require direct access to the HTTP port of the Master TIE server. Given the security concerns regarding exposing TIE directly to the internet is a security tradeoff to not perform ATD submissions when off network. In that case a simple DXL hub with access back to the DXL is recommended.
If anyone can provide some clarification or tell me how I can get it from Intel Proper I would greatly appreciate it.
I'd be happy to weigh in for you on this topic, but I think part of your question was cut off ("It seems like it would be a problem for...???").
Can you please elaborate on your question?
Is the bothersome part that Intel Security doesn't recommend placing the TIE Server in a position where it is directly accessible from the Internet? This recommendation is inline with many other multi-tier enterprise applications. The presentation layer is exposed to external access (in this case the DXL broker) but the backend application and database are kept segregated within the data center.
The final note above points out that the current design of the combined TIE + ATD solution brings a minor limitation, because submission of potentially malicious files from TIE endpoints does not currently happen with DXL transport; it uses straight HTTP transport from the endpoint to the TIE Server (and from there to ATD). So off-prem clients won't be able to submit potentially malicious files to ATD for analysis, but they remain connected to the DXL (through teh DMZ broker) and so still have the ability to request and receive reputation information.
Thanks Scott, that helps some.
I think I don't have a good understanding of one fundamental aspect though. What exactly do they mean by "on network" vs. "off network". Since I haven't found a good definition in the documentation, contextually it seems "off network" endpoints cannot access the internet, but can access other endpoints. I could be completely off though.
The bothersome part isn't TIE Server placement because, as you say, it is consistent with other applications. It's more so that I don't understand the implication that ATD integration makes it more at risk, but ONLY where the endpoints are "off network".
In this context "off network" is intended to mean "not connected to the corporate network", or "off premises". This might be a roaming user sitting at a Starbucks, in a hotel, or at home, without an active VPN connection.
how about a second TIE Server?? The actual DXL version should support mulit EPO, multi TIE in one DXL fabrix. How about a single TIE Server in DMZ?
How should a customer handle "off network" endpoints to provide uploading/analyzing files to/by ATD (i know, this is only possible over TIE )
A secondary TIE Server is also not recommended in the DMZ, as it would includes a complete replica of the primary server, and also synchronizes all updates upstream.
For systems that are off-premises, if they are connected to the corporate network via VPN, they would have no limitations on submitting samples to ATD for analysis. We are working on a more general solution to allow ATD submissions from off-prem users within TIE, but I don't have a date for that I can share at this time.
hope this solution is available soon. Since customers are using an Agent Handler in DMZ, MCP for webtraffic and HIPS installed on theire Systems an VPN Connection is not generally used by customers.