In a recent survey of 200 health care CEOs, it was revealed that at the beginning of the COVID-19 pandemic, 62% of respondents’ organizations were executing digital transformations. However, as in so many other enterprises, nearly all the respondents (97%) indicated that the effects of the pandemic also accelerated their digital transformation projects.
Private data centers, co-locations, public data centers, software-as-a-service (SaaS), and unified communications as a service (UCaaS) are all valuable options for healthcare IT organizations as they navigate the ever-changing demands for delivering innovative applications and services that impact patient care.
Many of the accelerated digital transformations during the last couple of years directly relate to improving patients’ experience and access to medical support. Consider just a few:
Telemedicine for more convenient and timely appointments with physicians, registered nurses, and physicians’ assistants
Patient portals that offer efficient online mechanisms for asking questions, requesting refills, and scheduling appointments
UCaaS offerings such as Webex, Zoom, and Microsoft Teams for more personal communications with all caregivers
Yes, all three of these services were available to, and in varying stages of adoption by, IT organizations. Yet, post-pandemic, they are far more widely adopted and deployed by health care organizations. And they have skyrocketed in use and popularity in caregiver and patient communities. These digital transformations are improving the care, and attention patients receive and helping to streamline the process for the caregivers.
Maintaining quality, availability, performance, and security of these critical patient services – particularly as deployment options create greater complexity and less control for the IT teams – can be a challenge.
Explore how one health care organization leveraged NETSCOUT visibility as it digitally transformed its environment with mobile communications, SaaS, and public cloud initiatives.
In Part 1 of my series on Transport Layer Security (TLS) decryption, I went over a few basics of encryption, discussed TLS 1.2, and concluded by outlining the improvements TLS 1.3 provided. In this second installment, I dive into TLS decryption in versions TLS 1.2 and 1.3.
TLS Decryption
To decrypt TLS sessions, there are a few requirements. One of the options is to be either on the client or on the server. The client and server must be able to decrypt the session at some point to use the information. For some scenarios, this may be all that is needed, but this, unfortunately will not scale well.
Another option is to have a copy of the server’s private key and use it to listen to the traffic as it traverses the network. This works in some scenarios and will allow sending all the decrypted traffic to a security or monitoring tool for further analysis. There are two problems with this solution. The first is that it will work only if you control the server. It will never work to decrypt internal client traffic out to the internet. The second is that it will not work for TLS 1.3, even if you have the server’s secret key. TLS 1.3 uses ephemeral keys, so you can’t passively listen to the traffic and then decrypt it.
To decrypt sessions from multiple clients to multiple servers, it is necessary to be a person-in-the-middle so that traffic can be modified between the client and the server. In this situation, the initial state for a TLS 1.2 session is a little different. NETSCOUT nGenius Encryption Appliance (nDA) needs to be able to see all the traffic between the client and the server. The client needs a certificate authority (CA) and public key, but now this certificate needs to be generated by nDA. The server initial state remains the same. nDA has its own self-created CA certificate and public and private keys, the CA’s certificate and public key, and its own server public and private keys.
TLS 1.2 Decryption
So, what is the process for decrypting TLS 1.2 sessions? The start of this TLS session is the same: The client sends a Hello message that includes a list of the cipher suites it supports. The server responds a with a Hello message, picks one of the cipher suites, and includes its server certificate and its public key. This message is intercepted by nDA. nDA replaces the server public keys with its own and re-signs, using its CA private key. This is a key the client trusts, so it goes through the same steps as before: The client authenticates this server certificate by decrypting it with the CA public key. It then generates a premaster secret, encrypts it using the server public key, and sends it to the server. This message is intercepted by nDA as well. It uses its own private key to decrypt this message, recovers the premaster secret, and is then able to generate the session key from the premaster secret.
NETSCOUT
nDA now does two more things. First, it processes the server Hello message, authenticates the server, and encrypts the premaster secret, just like the client would, and sends this to the server. It also responds to the client with an encrypted handshake message, which establishes TLS session 1. The server decrypts the message it receives, generates the session key from the premaster secret, and sends its handshake message. nDA receives this message and knows TLS session 2 is also active. The client, nDA, and server all now have the same session key, and nDA will be able to decrypt all messages between the client and server.
The overall process for decrypting TLS 1.3 is similar, but there are fewer overall steps, because a few of the above steps are combined. nDA acts as both the client and the server, modifying the keys as appropriate so that nDA winds up with two TLS session keys – one with each side.
To Be Concluded
In my third and final installment, I’ll demonstrate a few ways the client can determine if this is happening on its connections and show why TLS is still secure, even when nDA is used to decrypt transactions.
Next-generation mobile technologies such as ultra-reliable low latency communications (URLLC), high speed enhanced mobile broadband (EMBB) and the deployment of the multi-access edge cloud (MEC) are enabling both enterprise-specific applications and services as well as enhanced end-user services and experiences—key revenue targets for mobile operators.
These new services combined with the burgeoning Internet of Everything are bringing an evolutionary shift in connected devices and 5G usage.
But these new services also are attracting the attention of attackers. DDoS activity has skyrocketed since 5G non-standalone (NSA) networks started going live, and carriers now are beginning to deploy 5G standalone (SA) networks, giving attackers an even larger attack surface with higher-value targets.
What’s the Risk for 5G Service Providers?
The greatest threats for providers of 5G services are network availability/downtime problems, loss of data, and inability to meet regulatory or compliance dictates. Although all three are of concern, service providers are especially concerned with DDoS attacks and threats that directly impact network availability.
The entire purpose behind DDoS attacks is to disrupt and deny a service. It’s no secret that 5G service providers are banking on those networks to deploy new services and improve the bottom line. But when those services are disrupted by attacks, 5G customers—especially enterprise customers—feel the greatest impact.
And enterprise customers are definitely concerned about the security of 5G networks, as evidenced by Accenture’s recent survey of more than 2,600 business decision-makers. 35 percent of those business leaders expressed concern about 5G security, and 62 percent said 5G will leave them more vulnerable to attacks.
Just How Bad Is It?
Communications service providers (CSPs) are no strangers to DDoS attacks, as the latest NETSCOUT Threat Intelligence Report shows. CSPs make up four of the top 10 targets for DDoS attacks, accounting for more than 384,000 attacks in 1H 2021.
Three areas of specific concern for 5G service providers are:
Expanded services enabled by 5G:This includes new services on 5G networks, as well as the increased traffic that will be generated by an uptick of connected mobile devices.
Internet of Things (IoT):IoT device growth is astronomical, with every connected device generating a larger attack surface for attackers to target.
5G standalone (SA) core:5G SA networks are in the infancy of deployment, and they enable services such as enhanced mobile broadband (embb) and massive machine type communication (mmtc)—making them even more attractive to attackers.
What Can CSPs Do to Stop Attackers?
The good news is that CSPs have ways to mitigate DDoS attacks and other threats against 5G networks.
To learn more about the threats being targeted against 5G networks and how to protect against them, download our white paper 5G: A Blessing and a Curse. You can also reach out to us today for an analysis of your 5G networks and how to best protect them against attacks.
