SSL-based communication can inhibit other parts of your security strategy. Most IDS (intrusion-detection system) and virus-scanning services can't interact with SSL, so encrypted traffic is allowed to pass without question. What's needed is a slightly different architecture, one that provides a mechanism that allows encrypted traffic to be inspected by your edge-protection devices before it's passed further into your back-end infrastructure. Two physical connections are made for every logical connection. The client connects to the device, and a separate connection from the device to the server is made to fulfill any client requests.
Such an architecture is often called a co-appliance or side-arm configuration. By using a traffic-management device--usually a load-balancer--you can provide a method by which you can follow those security policies you so painstakingly created (see graphic "Web Infrastructure in a Side-Arm Configuration").
In this configuration, SSL-encrypted traffic is decrypted by first directing the traffic to the SSL appliance so it can be checked by the IDS and virus-scanning services. Once it passes through this outer crust, it's passed back to the load-balancer/content switch and on to your servers.
Another way to provide this functionality is by ensuring that your traffic director can terminate SSL sessions. The device serving as your traffic director would be configured as a reverse proxy for SSL connections, handling all encryption and decryption services between itself and the client. This removes the need for an external SSL appliance but introduces additional issues: If you use the client certificates to authorize access, they will be authenticated by the traffic-management device, not your application servers, unless you're using a traffic manager capable of inserting the user credentials into the HTTP header, such as F5 Networks' Big-IP (see Sneak Preview "Big-IP 5000 Switch Marks New Territory for F5 Networks").
Some industries need to continue SSL sessions all the way to the back-end Web servers. Financial and banking institutions, in particular, fall under stringent security regulations that require all transactions be encrypted regardless of whether they are internal or external. If this is a requirement for your business, you must ensure that your traffic director can terminate the SSL session with the client, and initiate SSL connections with devices deeper in your infrastructure. This type of configuration has an added benefit if your traffic director can use client certificates, which provide protection by offering a more secure method of identification. This isn't a perfect solution--certificate stores are often kept on disk and could be stolen--but it's more secure than nothing. If you go with this option and require a client certificate to connect to your back-end servers, you can prevent direct connections from the outside to your servers.
To realize the benefits of cloud-native software, an application must actually be cloud-native—designed to run in the cloud, interacting with disaggregated cloud services, fully manageable as code—to deliver the expected benefits.
By combining resources and expertise, the AI-Enabled ICT Workforce Consortium will offer a blueprint for how industries can adapt to an AI-dominated future.
IT leaders should heed the guidance of cybersecurity insurance providers who think businesses should prioritize security education, incident preparedness, regular internal audits, and ongoing vulnerability scanning and patching.
