AWS, Verizon, and MEC: Demystified

Meanwhile in Security

Jesse Trucks is the Minister of Magic at Splunk, where he consults on security and compliance program designs and develops Splunk architectures for security use cases, among other things. He brings more than 20 years of experience in tech to this role, having previously worked as director of security and compliance at Peak Hosting, a staff member at freenode, a cybersecurity engineer at Oak Ridge National Laboratory, and a systems engineer at D.E. Shaw Research, among several other positions. Of course, Jesse is also the host of Meanwhile in Security, the podcast about better cloud security you’re about to listen to.

Transcript

Jesse: Welcome to Meanwhile in Security where I, your host Jesse Trucks, guides you to better security in the cloud.

Announcer: This episode is sponsored by ExtraHop. ExtraHop provides threat detection and response for the Enterprise (not the starship). On-prem security doesn’t translate well to cloud or multi-cloud environments, and that’s not even counting IoT. ExtraHop automatically discovers everything inside the perimeter, including your cloud workloads and IoT devices, detects these threats up to 35 percent faster, and helps you act immediately. Ask for a free trial of detection and response for AWS today at extrahop.com/trial. That’s extrahop.com/trial.

Jesse: This week, Verizon announced a deepening of its partnership with AWS with the launch of a private mobile edge computing, or MEC, service, which was previously only available from Verizon using Microsoft Azure cloud services. This new service complements the public MEC offering using AWS that Verizon introduced in August of 2020, and brings MEC solutions within reach of many organizations who could not consider implementing MEC in the past. What is mobile edge computing and what do these services provide? Mobile edge computing, sometimes called multi-access edge computing, is an infrastructure approach that provides cloud compute services at the edge of the network closest to the end-users of those services. To service implementations for mobile end-users, the hardware hosting the cloud services are co-located with the 4G or 5G networks rather than relying on transport to and from regular cloud services in addition to traversing the mobile networks.

This provides low-latency access for critical and real-time applications by users on those mobile networks. With the advent of 5G, latency on mobile networks has dropped down to or below levels commonly measured in landline-based networks. A common example cited is the use of MEC with self-driving cars for ultra-low latency access to traffic, weather, and other real-time conditions. However, a more practical example is using MEC to provide real-time analysis of crowd densities and line cues in public spaces such as theatres or public transit stations. The difference between public and private MEC is that, as the names imply, public implementations are accessible on the public internet, whereas private implementations are only accessible via internal private networks.

The latency for private MEC implementations tend to be much lower than public MEC implementations as well because the hardware running the compute services is physically located with the end-user systems, such as in a manufacturing plant or train station, but public MEC systems are usually located with a mobile network provider away from the end-users. The Verizon private MEC uses the AWS Outpost service, which is a hardware-based extension of AWS Cloud services physically located at the customer site rather than in AWS or Verizon data centers. These systems include Verizon 5G services for use on private local networks to provide low latency, easy to manage, and secure wireless access. Because of the co-location inside the customer network, the AWS Cloud services provided by this offering are only available to the customer hosting the hardware. The Verizon public MEC uses the AWS Wavelength service, which is a collection of AWS zones co-located with Verizon’s 5G network in select locations. These are generally available [over 00:03:53] AWS Cloud services, usable by nearly any AWS customer. Meanwhile, what about security and MEC?

Because the Verizon MEC services use existing AWS products, there are no new security mechanisms, tools, or requirements added to either of the public or private MEC services. The customer is required to manage all the usual security for systems and applications they deploy with either of the MEC solutions using the shared responsibility model with two slight differences with AWS Outpost. Let’s look a bit more closely at these two products and their security models.

AWS Outpost is essentially an AWS Cloud in a box or rack of servers physically installed in the customer’s location. This is remotely managed by AWS and provides a subset of the same AWS services, using the same APIs and other tools, as standard AWS offers in their normal regions. This is different than a wholly private and self-managed cloud implementation because AWS still manages the cloud infrastructure within the Outpost’s equipment.

Announcer: If you have several PostgreSQL databases running behind NAT, check out Teleport, an open-source identity-aware access proxy. Teleport provides secure access to anything running behind NAT, such as SSH servers or Kubernetes clusters and—new in this release—PostgreSQL instances, including AWS RDS. Teleport gives users superpowers like authenticating via SSO with multi-factor, listing and seeing all database instances, getting instant access to them using popular CLI tools or web UIs. Teleport ensures best security practices like role-based access, preventing data exfiltration, providing visibility, and ensuring compliance. Download Teleport at goteleport.com. That’s goteleport.com.

Jesse: With Outpost, there are two changes to the shared security model. Obviously, there’s an added layer of security managed by the customer to protect the physical hardware, and the customer must also provide adequate network access and security for the network. However, in terms of the systems, services, and applications running in the environment, operations and security are the same as running those same services in any other cloud environment. The hardware within the server or rack is built on the AWS Nitro platform. Nitro is a hardware implementation of the AWS hypervisor technology, coupled with chip-based hardware security subsystems.

This allows for a secure implementation of AWS Cloud services while also protecting customer environments and data. AWS Wavelength is the implementation of many of the familiar AWS Cloud services but co-located by AWS within mobile provider 5G networks, and uses the same shared responsibility model as normal AWS solutions. Essentially, Wavelength is used much like any other AWS environment. To use Wavelength, you must request access to the desired Wavelength zone or zones. Once access is granted, create or modify an existing AWS virtual private cloud, or VPC, with coverage extended to include the Wavelength’s zone or zones.

Then you deploy MEC-based services in the Wavelength zones as you normally would in other AWS regions and zones. Given this as an implementation of VPC, there are no additional security concerns outside the normal issues with managing a complex VPC environment. As always, you can limit access to these services and applications in all the usual ways with either the public or private MEC solutions. You can limit access to VPC connected systems, open it to public access and/or require authenticated access. However, one caveat is that to grant access from outside the organization with the private MEC solution using Outposts, your network must provide a path to the services just as you would set up any self-hosted solution today. For more details on the services, go to the AWS documentation for Outpost, Wavelength, and Nitro.

Now that we’ve covered what this announcement means, it’s useful to talk about how this might apply to your environment. Most organizations will have little or no use for MEC capabilities now or in the future. However, some organizations might find new uses for MEC now that the barrier to entry for this type of service is brought lower with the advent of these services as standard AWS and Verizon offerings. Implementing any solution that relies on low latency connections and high-speed calculations for near-instant results requires a non-trivial investment in time and resources, as we all know, but pushing such a solution to production use or as a rapid go-to-market strategy could be much faster and easier than it used to be using the services. The real security implications come if you’re implementing MEC solutions that touched your IoT devices, which historically weren’t involved in connected networks such as these. I’m [laugh] pretty sure that pricing is non-trivial as well, but you’d have to talk with our friends Mike and Corey at The Duckbill Group about cost analysis. I’m just the security guy.

Jesse: Thanks for listening. Please subscribe and rate us on Apple and Google Podcast, Spotify, or wherever you listen to podcasts.

Announcer: This has been a HumblePod production. Stay humble.