Check Point HTTPS Inspection Concerns

[Di_Junior]

Dear Mates

We wish to enable https inspection on our environment, but there are some privacy concerns. Thats why I am writing this post to get some feedback from the community. I am not worried about how it is done, I am would like to know if answers to the questions below:

1. If I access for example hotmail.com, is it possible to see the user credentials (username and password) on the logs?
2. Is the inspected information stored on the gateway ? for how long? or the information is no longer visible after the inspection is done by the gateway?

There is currently a need to get https inspection working, but I need to have answers to questions that may be raised at the C level. We intend to start with the Outbout Inspection first.

Thanks in advance

[Danny]

1 - No user credentials are shown in the logs.

2 - You can't see the decrypted information on the gateway and it's not stored at all, only handled by the processes during inspection.

[Di_Junior]

Thanks @Danny

That is great, this feedback gives me a peace of mind.

However, sk108202 says: The Security Gateway uses certificates and becomes an intermediary between the client computer and the secure web site. All data is kept private in HTTPS Inspection logs. Only administrators with HTTPS Inspection permissions can see all the fields in a log.

Any comments on that.

[PhoneBoy]

Whatever data you can see today for unencrypted traffic, you'll be able to see for encrypted traffic.
For example, if you're using App Control/URL Filtering, you'll be able to see the full HTTPS URLs that people surf to in the logs.
It won't log things like usernames/passwords or other PII unless you're specifically looking for certain things with DLP and/or Content Awareness.

[FedericoMeiners]

It would be nice to have a statement from Check Point on how the clear text data is protected while doing HTTPS Inspection, I guess that at some point is ""accessible"" in memory at least for some daemons.

Having said that and knowing Check Point philosophy I'm pretty sure that it's not accessible by users.

In the end it all depends on your C level of psychosis (AKA risk tolerance). If we speak about risk, not having HTTPS Inspection is far more riskier than worrying about credential sniffing in a hardened OS that performs that function. 

Remember that you can bypass various categories.

___

[PhoneBoy]

There is one situation where the cleartext of an HTTPS connection is definitely accessible: when using the Mirror and Decrypt function in R80.20+.
This will "mirror" all traffic (including decrypted HTTPS traffic) to a specific port on the device.
This is needed to enable other devices to log the contents of specific traffic, which certain regulatory frameworks require.

Obviously, if a nefarious person has access to your Security Gateway, whether it's doing this or not, you've got much bigger issues to worry about.

[Nir_Naaman]

Some customers have regulatory obligations that prevent them from dumping decrypted traffic in cleartext. We are currently testing a new scheme that addresses this concern.

In particular, a Check Point Azure VMSS is performing HTTPS Inspection, and using Mirror and Decrypt to dump the decrypted traffic to a Check Point NDR sensor for advanced threat analysis, behavioral analytics, and selective packet capture. This is performed over Large Scale VPN (LSV) to deliver end to end IPsec protection for the dumped traffic in transit. LSV allows the scale set to expand (or contract) without requiring policy installation on the NDR sensor.