How to Maintain Governance, Mitigate Risk, and Manage Compliance
Watch the webinar
How well you protect your customers’ high-profile data will determine your viability in the encrypted era.
Secure Sockets Layer (SSL) was first adopted by the financial services industry nearly 25 years ago due to the need to secure data in transit. Today, nearly 90% of page loads are encrypted with SSL or Transport Layer Security (TLS, the successor of SSL), which has become the standard for organizations of all sizes, and in all industries. Several factors have driven this adoption, including the EU General Data Protection Regulation (GDPR), Google search results ranking preferences, browser warnings for HTTP (cleartext) sites, and the ease of getting inexpensive or free certificates (Let’s Encrypt), to name just a few.
While this evolution improves user privacy and security for web traffic, it comes at a price: the potential hazards of malware cloaked in encrypted traffic and increased workload demand. Financial services organizations, more so than others, now have the burden to implement solutions that ensure the integrity of their underlying infrastructures and payment systems while protecting customer financial information—all without hindering the speed and availability of their banking services.
90% of page loads on millions of sites sampled are encrypted, based on F5 Labs Threat Intelligence research.
Encrypting traffic is great for preventing man-in-the-middle attacks that can potentially allow an attacker to view or alter financial data; however, encryption can make inspection or analytics devices and services blind to that traffic. Encrypting and decrypting traffic consumes a lot of computational power, so many security inspection solutions like an Intrusion Detection/Prevention System (IDS/ IPS), malware sandbox, next-gen firewall (NGFW), and others either don’t decrypt at all or take such a huge performance hit that they pass along encrypted traffic just to keep up.
Everyone knows that malware is dangerous, but it typically takes a layered defense to identify and stop
it from propagating to other users and devices—or from exfiltrating data. Malware can be acquired from several different sources such as malicious web sites or phishing emails, so it’s crucial to inspect egress network traffic to ensure malware is unable to call out to command and control servers and that no sensitive data is leaving your controlled environment. This becomes a challenge as nearly all attackers are now using encrypted channels to hide their malware’s outbound communications.
There are also difficulties associated with inspecting inbound traffic. An app or website is often crucial to an organization’s business—34% of web apps are reported as being mission critical, according to the F5 Labs 2018 Application Protection Report. And when your application is essential, you’ll likely have security solutions like a web application firewall (WAF) or an intrusion detection system (IDS)/intrusion prevention system (IPS) to filter out malicious traffic. In addition to security inspection devices, you may need to run app traffic through analytics engines or customer experience solutions. All of these solutions offer unique value—but decryption at scale is not likely one of them.
OF WEB APPS ARE REPORTED AS BEING MISSION CRITICAL, AND THEY'RE AT RISK FROM MALICIOUS TRAFFIC.
A recent F5 Labs study showed that 75% of malware uses encryption to hide its tracks from the security devices designed to identify and neutralize it—and that figure is likely to continue increasing. When implementing a defense-in-depth strategy, many administrators deploy security solutions in a serial chain to defend against malware. This is incredibly inefficient, and also leaves the door open for malicious traffic to be passed through by an overwhelmed security inspection solution. You need visibility and security, but you can’t sacrifice performance.
An SSL/TLS solution to decrypt traffic and send to inspection devices is a good first step to mitigating the effects of malware. However, it may introduce unnecessary latency if certain traffic doesn’t need to go through certain inspection devices. For example, if a user’s outbound traffic is going to a known good site (or IP address), and the data loss prevention (DLP) solution doesn’t detect anything sensitive, does the traffic still need to go through the NGFW or the IDS? Perhaps, but it’s important to have the ability to customize the path of your traffic according to your risk tolerance.
Changing older ciphers as they are deprecated is easier when there is a centralized point of control.
The TLS protocol has a passive surveillance countermeasure called perfect forward secrecy (PFS) protection, which adds an additional exchange to the key establishment protocol between the two sides of the encrypted connection. By generating a unique key for each session the user initiates, PFS guarantees that an attacker cannot simply recover a single key and decrypt millions of previously recorded conversations.
As PFS becomes the de facto standard—especially as this is the only method allowed within TLS 1.3—you’ll need to have a plan for any passive inspection solutions for inbound traffic. Previously, with RSA keys, you would share the key with any of those solutions. However, this is not possible with PFS generating a unique key for each session. F5® SSL Orchestrator® can either decrypt and forward cleartext traffic to inspection solutions, or it can decrypt and re-encrypt using TLS 1.2 with RSA. The second option does put the onus back on the inspection devices to decrypt, but the solutions would not be required to be inline with traffic—and thus would not increase latency nor would there be cleartext data in transit within your data center.
No vulnerabilities have yet been found with the elliptical curve ciphers, which are mandatory when implementing PFS; but as we all know, anything that's secure today won’t stay that way forever. Security research and hacking tools continue to advance, as does computing power—and that will inevitably help uncover a vulnerability. Having a centralized point of control for all decryption and encryption makes it easier to change ciphers as old ciphers are deprecated.
Having the ability to see inside the packets ingressing or egressing your network is a great step, but it’s only the first step. Resorting to manual daisy-chaining or configuration to manage decryption/encryption across the entire security stack is tedious. And we all know that any policy that mandates things must be a certain way always come with an exception. SSL Orchestrator delivers visibility at great scale but differentiates itself from the pack with orchestration. Classification and orchestration are especially key when it comes to bypassing the decryption of regulated data, such as PII associated to GDPR or HIPAA requirements.
HAVING THE ABILITY TO SEE INSIDE THE PACKETS COMING INTO YOUR APPLICATIONS, OR GOING OUT FROM YOUR NETWORK, IS A GREAT STEP; BUT IT’S ONLY THE FIRST STEP.
Orchestration provides policy-based traffic steering to a service chain based on risk and dynamic network conditions. Via the virtue of being a full-proxy for both SSL/TLS and HTTP, SSL Orchestrator can make intelligent decisions to steer inbound and outbound traffic to the appropriate service chains within the security stack—taking the burden off existing security devices in the network. And while most of your traffic is likely HTTPS, SSL Orchestrator allows you to intelligently manage decryption and re-encryption with other traffic types like STARTTLS within FTP, IMAP, POP3, and ICAP.
Learn about the privacy, performance and security benefits of TLS 1.3 and why it’s critical to ensure visibility and orchestration into your encrypted traffic.
Explore the latest SSL/TLS encryption management technologies, easily integrated into your entire infrastructure, and enabling your existing security inspection tool investments.