Secure Internal Communication (SIC) Basics

[TheDroppedPacket]

Trying to get a better understanding of SIC and how it is used for communication between Check Point devices...

To establish the initial trust, a gateway and a Security Management Server use a one-time password. After the initial trust is established, further communication is based on security certificates.
[Security Management R80.40 Administration Guide. Check Point Software Technologies. 3 May 20. 24 Sep 20. <https://sc1.checkpoint.com/documents/R80.40/WebAdminGuides/EN/CP_R80.40_SecurityManagement_AdminGuide/Content/Topics-SECMG/Secure-Internal-Communication.htm>]

Am I understanding correctly that the two peers involved in establishing SIC will always be whatever device is being setup (gateway, logging server, etc.) and the primary management appliance, since the management device is a certificate authority? The one-time password is used to establish trust and then a TLS certificate is issued from the management appliance for actually securing communication. That certificate is then used for any cross-device communication.

For example, if I have a gateway that needs to send logs to a logging appliance, SIC is established with the management device first for both the gateway and the logging appliance. Once a certificate is issued from management for both gateway and logging, gateway will be capable of transferring logs directly to the logging appliance. The one-time password is used solely for establishing trust and is not used as something like a pre-shared key for communication—it is not a symmetric encryption based on the key. After the trust is established, and a certificate issued, all necessary communication (such as logging) can be established. For this reason, SIC is always established using the one-time key from the gateway to the management appliance, and from the logging appliance to the management appliance, and then logs can be sent directly from the gateway(s) to the logging appliance independent of management.

Am I understanding correctly or am I way off? Thank you!

[Bob_Zimmerman]

The trust establishment negotiation is actually from the management to the gateway and from the management to the log server. The rest is accurate, yes.

[EricAnderson]

Correct. The points that I would add (or expand on - for the benefit of others):

• SIC can also be established with/from a secondary management server, as long as it's active
• Once established, managed devices (like your GW and dedicated log server) can communicate directly with each other the same way since their certs are signed by the same CA (management)
• The most-often forgotten/misunderstood facet is that resetting SIC (if required) has to happen on both GW and Management. It is (normally) a "one time" thing, but it's also a "two way" thing.

-E

[Bob_Zimmerman]

• The most-often forgotten/misunderstood facet is that resetting SIC (if required) has to happen on both GW and Management. It is (normally) a "one time" thing, but it's also a "two way" thing.

Elaborating on this one a bit. Resetting SIC should almost never be necessary, and it often makes problems worse and reduces your ability to troubleshoot the problem. While building your understanding of the system, I would recommend only resetting SIC if support tells you to.

I bring this up because I have been in environments where the "solution" to entire classes of problem was to reset SIC. After some troubleshooting, I found out this only "worked" because the real problem was a transient interface failure and resetting SIC took long enough for the failing interface to start working again on its own.

SIC doesn't just break. The only times I have legitimately needed to reset it were when rebuilding a failed management from the ground up, changing the name of a device (SIC certificates are name-based, and CPD doesn't like using a cert with a name different from the hostname), or dealing with a deeply dumb NTP issue which broke the entire ICA on the management.

[cciesec2006]

Elaborating on this one a bit. Resetting SIC should almost never be necessary, and it often makes problems worse and reduces your ability to troubleshoot the problem. While building your understanding of the system, I would recommend only resetting SIC if support tells you to.

I bring this up because I have been in environments where the "solution" to entire classes of problem was to reset SIC. After some troubleshooting, I found out this only "worked" because the real problem was a transient interface failure and resetting SIC took long enough for the failing interface to start working again on its own.

SIC doesn't just break. The only times I have legitimately needed to reset it were when rebuilding a failed management from the ground up, changing the name of a device (SIC certificates are name-based, and CPD doesn't like using a cert with a name different from the hostname), or dealing with a deeply dumb NTP issue which broke the entire ICA on the management.

Cisco Firepower Thread Defense (FTD) has something similar to SIC but much simpler. It is called a "one time password" that both the Firepower Management Center (FMC) and the gateway FTD must match.

[TheDroppedPacket]

Thank you for all the great replies and information!

I don't want to sideline my own forum thread here too much with another conversation but the background of why I am researching the subject... When I upgraded management and logging from R80.20 to R80.40, I had problems communicating with logging. Support walked me through reestablishing SIC with logging. We have a "dummy" server associated with a public IP that translates to the private IP of the logging appliance. (This predates my time as an administrator in the environment.) When SIC was reestablished, I believe it was done with the NAT'ed object and not the actual appliance object. The actual appliance shows the red X with "Secure Internal Communication is not operational with 'device'. Verify that SIC is initialized or was not reset." We are not successfully receiving logs against that external IP as we were prior to the upgrade. Instead, some logs are being passed internally over VPNs (private IP of the logging appliance being listed as secondary), which is resulting in additional VPN traffic load. My intention is to reestablish SIC with the actual appliance and see if it resolves the issue.

If this sounds incorrect or dangerous in some way, I will simply open a case with support for advice/direction.

Reference:
How to reset SIC
https://supportcenter.checkpoint.com...tionid=sk65764

[EricAnderson]

SIC doesn't just break. The only times I have legitimately needed to reset it were when rebuilding a failed management from the ground up, changing the name of a device (SIC certificates are name-based, and CPD doesn't like using a cert with a name different from the hostname), or dealing with a deeply dumb NTP issue which broke the entire ICA on the management.

We agree, and I didn't mean to say that SIC does/should break often at all - but we may be referring to slightly different things. It sounds like you're talking about times that you've had to reset/reinitialize the ICA itself - which is an entirely different (and yes, even less common) undertaking. I'm referring to reset of SIC with a single managed device because of things like IP change, name change, or physical replacement/rebuild.

I also agree that it's often used too quickly and ends up "resolving" issues that are more based on bad policy/config.

Cisco Firepower Thread Defense (FTD) has something similar to SIC but much simpler. It is called a "one time password" that both the Firepower Management Center (FMC) and the gateway FTD must match.

While vendors all have their own methods of doing the equivalent, I believe CP's SIC is a solid combination of simplicity and efficacy. Maintaining "open server" capability dictates that the solution be hardware-independent, certificates are multi-purposed to simplify/strengthen centrally managed S2S VPN, and it can survive backup/restore. Most of the complications (and unnecessary resets) come from mistakes elsewhere, which, yes, are fairly easy to make. Anything simpler would make me question the security/efficacy.

-E

[EricAnderson]

I don't want to sideline my own forum thread here too much with another conversation but the background of why I am researching the subject... When I upgraded management and logging from R80.20 to R80.40, I had problems communicating with logging. Support walked me through reestablishing SIC with logging. We have a "dummy" server associated with a public IP that translates to the private IP of the logging appliance. (This predates my time as an administrator in the environment.) When SIC was reestablished, I believe it was done with the NAT'ed object and not the actual appliance object. The actual appliance shows the red X with "Secure Internal Communication is not operational with 'device'. Verify that SIC is initialized or was not reset." We are not successfully receiving logs against that external IP as we were prior to the upgrade. Instead, some logs are being passed internally over VPNs (private IP of the logging appliance being listed as secondary), which is resulting in additional VPN traffic load. My intention is to reestablish SIC with the actual appliance and see if it resolves the issue.

The use of a secondary/dummy log server is all to common. It stems from the fact that CP leans toward using the "Main" IP addresses of objects for internal communications. It's most often seen when using a combination of local and remote gateways, with remotes delivering logs over the internet. The local devices have no problem routing to the private IP of the log server, but remotes need a static/public NAT for it. Even if the log server object has an automatic static NAT, it's not used for the delivering logs.

It like one of many cases where CP is trying to make things simple/easy with objects - as opposed to manual IP definition. Giving us the option in the GW config to manually define an IP address for log delivery, rather than a log server object, would eliminate that ugly, dummy, "perpetually disconnected" log server object. Most wouldn't need/want to, but it would be a better/cleaner (and not exactly difficult) workaround for those who need it.

The other, better, more official answer to this is supposed to be the "Apply for Security Gateway control connections" option on the NAT settings of the log server (or other Check Point Host objects). The theory is that the Static NAT defined here would be used over the Main IP. Confusion is that even local devices would use it, but they should NAT it correctly and make it a non-issue. One historic issue/limitation was that even if the management/log server supported it, if the gateways were running older version that didn't, it wouldn't solve anything.


-E

[Bob_Zimmerman]

We agree, and I didn't mean to say that SIC does/should break often at all - but we may be referring to slightly different things. It sounds like you're talking about times that you've had to reset/reinitialize the ICA itself - which is an entirely different (and yes, even less common) undertaking. I'm referring to reset of SIC with a single managed device because of things like IP change, name change, or physical replacement/rebuild.

I also agree that it's often used too quickly and ends up "resolving" issues that are more based on bad policy/config.

Change management's name? Need to reset the ICA and all trust relationships. I hit that mostly when rebuilding a failed management (I wrote the process for the three-file rebuild, and used it on a near-daily basis for years). That NTP thing also trashed the guy's ICA (not valid before 2036, not valid after 1910, so it revoked and reissued every leaf cert every second), so we had to reset it.

Change a firewall's name or replacing the firewall with another unit? You should only need to reset it between the management and the firewall. Hit this a surprising number of times with people who put a device model in the firewall's name, then wanted to change the name to remove it (or the other way around). They get treated as network devices, and I don't know any other network vendors who care about the hostname to nearly the same extent Check Point does.

You shouldn't need to reset SIC after changing an IP. CPD only cares about the name and the certificate/key so after telling the management about the new IP, it should still be able to talk.