One of the common requests we get in RFPs (Request for Proposals) from enterprises and especially large enterprises for Check Point Next Gen Firewalls is whether or not we integrate with vendor xyz or one of the many industry standards such as STIX/TAXII or X.509, a standard for defining the format of public key certificates. Any DIY enthusiast knows projects run smoothest when using the right tool for the job. Likewise enterprises know that tools that orchestrate processes and automate repetitive tasks will save time and reduce errors in the long run. Analyst firms echo these customer requests for security vendors to work well with others in their yearly surveys and reports such as the Gartner Magic Quadrants and the Forrester Waves.
So today we’re going to highlight one example where Check Point works well with Venafi, a vendor whose software protects and manages x.509 certificates—or as they like to say, machine identities. Organizations use Venafi Machine Identity Management to protect communications, commerce, critical systems and data, and mobile and user access. What does this have to do with Check Point firewalls? Let’s dig a bit deeper.
First let’s understand the role that certificates play in the trust relationship between browsers and web servers, for instance on a banking site. We all know that HTTP is not secure and that HTTPS is secure. In fact, the S in HTTPS stands for secure. So, our browsers can show the site is secure with a lock icon and we’ve likely heard a PSA (Public Service Announcement) to watch out for sites without a lock. So far, so good? Did you know the browser uses a digitally signed certificate from the web server and checks it against its own local certificate store of known trusted Certificate Authorities (CA) to verify the certificate authenticity? I knew you did. When the browser validates that the web server is trusted, then the client and web server set up an encrypted connection to safeguard the connection from anyone in the middle who would otherwise be able to intercept and view packets between the two.
In sum, HTTPS is secure because it guarantees the site you’re connected to has proven to a Certificate Authority that they are who they say they are and the data sent back and forth is unintelligible to eavesdroppers because it’s encrypted. Clearly having a secure connection to your financial site is a good thing and there are various initiatives underway like Let’s Encrypt that encourage the conversion of more web traffic from HTTP to HTTPS to make the Internet more secure.
To prove that they are who they say they are, web site owners must first get a digitally signed certificate for a web site from one of the trusted CAs. And periodically certificates need to be renewed which has caused some issues in the past. When a certificate expires, it stops working and triggers an outage on the system where it was installed. Here are a few of the more high profile incidents.
So, if certificate renewal has caused so many issues, why do we need it? Replacing certificates frequently reduces the chance of their becoming vulnerable to attack. In fact, certificate lifetimes are decreasing so renewals need to happen more frequently. Certificate Authority/Browser Forums guidelines dictate that websites need to renew or replace their SSL certificate at least once every two years. Some certificate lifetimes are shorter. For instance Let’s Encrypt, a free, automated, and open certificate authority (CA) issues certificates with a 90 day lifetime. They reason that a shorter lifetime limits damage from key compromise, for instance, because compromised or stolen keys would be valid for a shorter period. And because the Let’s Encrypt process is automated for Domain Validated certificates, it’s no less convenient to renew certificates with shorter lifetimes than it is for certificates with longer lifespans.
It’s easier to automate Domain Validated certificates because the validation process simply requires that site owners prove they own a site by making a change on the site. There are three types of SSL Certificates available today—each with increasing requirements for site validation; Domain Validated (DV SSL), Organization Validated (OV SSL) and Extended Validation (EV SSL). The latter two require a manual vetting process to prove site ownership.
So clearly automation can help simplify certificate acquisition for smaller organizations with one single domain as is the case with Domain Validated certificates. The Automatic Certificate Management Environment (ACME) protocol, designed by the Internet Security Research Group (ISRG) for their Let's Encrypt service enables automated deployment for less complex environments.
Automation is also the best way to manage enterprises with large networks and many connected devices. But the scope for larger enterprises may be much wider than that for Let’s Encrypt. Here is where certificate management tools that automate certificate management, ensuring web servers and firewalls have valid certificates come into the picture. Venafi and Check Point work seamlessly together to ensure that certificates used in the browser-to-website server trust chain are up to date.
If HTTPS is secure, then why do firewalls need to decrypt the connection from a browser to a web server? That’s a good question. We know and understand the need to have a firewall at the perimeter for basic filtering [What is a firewall?, Check Point Cyber Hub]. Web servers that are accessible to the Internet need only allow a designated subset of web traffic, typically on port 80 (HTTP) and port 443 (HTTPS) and can block the full set of available TCP (Transmission Control Protocol) ports (1-65535 are available, and ports in range 1-1023 are the privileged ones). For the novice, think of ports on a web server as individual apartments in a rather large apartment complex. The port number in the browser request ensures it gets delivered to the right occupant or in this case service or port running on the web server.
This of course still doesn’t answer the question of why firewalls need to open the packets by decrypting them to see what’s inside the encrypted envelopes. The short answer is that one reason firewalls need to do deep packet inspection to see if the client is trying to exploit a known vulnerability in the web server. (You may also want to check for signs that rogue certificates are allowing exfiltration.) Simple port-based protection is not enough.
Today’s Next Gen Firewalls include IPS (Intrusion Prevention System) which is a security function that detects and prevents attempts to exploit known vulnerabilities in software and hardware. For instance, in the Equifax breach, remote attackers were able to remotely exploit an Apache Struts vulnerability on the web server that was known and there was already a patch for. Patching the application on the web server could have prevented this, but patching takes time. IPS signatures detecting the attack are usually available as soon as patches are available. With an inline firewall that automatically updates its IPS signatures, then IPS is also able to prevent these attacks before the patch is applied. [Equifax data breach FAQ: What happened, who was affected, what was the impact? CSO Online]
To decrypt HTTPS traffic, firewalls need a certificate in the trust chain that is known to browsers. Firewalls essentially act as a proxy for the web server, decrypting the browser connection and, if needed, encrypting it again from the firewall to the web server. Venafi provides the visibility needed to discover and automate the full lifecycle of SSL/TLS keys and certificates so that Check Point Next Generation Firewalls always have current machine identities to inspect web traffic for threats.
The Venafi Adaptable Bulk Provisioning Driver for Check Point automates SSL/TLS machine identities used in Check Point inbound HTTPS inspection policies. Certificates, or machine identities, are defined as Venafi-synced objects within Check Point and automatically kept in sync with intelligence within the Venafi Trust Protection Platform.
Together, Check Point and Venafi fully automate the delivery and configuration of critical machine identities in use by organizations protected with Check Point NGFWs.
Check Point Next Generation Firewalls (NGFWs) and the Venafi Platform work together to protect privacy, secure network transactions and defend intellectual property. The integrated solution helps you identify which encrypted channels should be trusted, and which are being used as part of an attack. With Venafi in place, Check Point NGFWs have secure and unhindered access to machine identities, allowing them to detect and prevent attacks that hide in encrypted channels.
To learn more about our technology partnerships with other vendors in the management, cloud security, mobile security, identity, IoT security, SD-WAN security or other categories, visit our Check Point Software Technology Partner page.