NIST 800-53 data encryption as it applies to Reverse Proxies

[MLewars]

I am working on a compliancy question and would like some feedback.

I have a web application behind a reverse proxy.  All requests are interrogated with the policy enforcement and policy decision point, appropriate access control limits direct backend requests. The question is related to the nature of the reverse proxy as it terminates the original TLS request and initiates the TLS request to the backend web host.  During the interchange, the java process has access to the stream of content in memory while it builds the next TLS connection and passes the request.

Has anyone else had to provide specific proof related to the remediation or acceptance of the state of the user data being passed between java processes/threads related to the encryption of data in flight?  If you did, how deep did the evidence need to go?

Any feedback is appreciated.

Regards, Mitchell Lewars, CISSP

[denbesten]

I would answer the question just as I would for the web host itself.  Both the proxy and the web host are processing the data (e.g. "data in use" as opposed to "data at rest" or "data in transit"). Systems that process data by their very nature need cleartext access.   Along the same lines, you should be implementing similar controls on both layers -- patching, software pedigree, least privilege, minimum footprint, etc.

Alternatively, you might be able moot the compliance question by avoiding decryption on the proxy -- so that it remains "data in transit".  For example, a load balancer can avoid decryption by switching its decider from session-cookie to source-IP.