Home BLOG Page 2

BLOG

Think You’ve Got 5G Security Issues Protected? Think Again.

by Ron Parker Ron Parker No Comments

As interest in 5G continues to heat up, you’re likely to hear a lot more about 5G security. You may not, however, be hearing the whole story. Most conversations around 5G security centers on the standards put forward by 3GPP last year. Those standards are a good starting point, don’t get me wrong, but they’re not the last word on 5G security issues by a longshot. Why? Because they completely leave container security out of the conversation.

5G Security and Containers

There are a lot of new network elements to consider in a 5G architecture, but the biggest change in 5G is the fact that almost everything is now running on containerized software. In terms of 5g security threats, containers are prime targets for cybercriminals because they contain sensitive data such as passwords and private keys. Understanding how to protect containers from security threats is just as important as protecting the transport layers and gateways in a 5G network. Building on what 3GPP has proposed, we believe that 5G security protection has four main objectives, only two of which are currently addressed by the 3GPP’s recommendations.

A Four-point Approach to 5G Security

Let’s start with what 3GPP has already proposed for 5g security standards:

1. A trust model with two distinct, onion-layered approaches for roaming and non-roaming networks. In the non-roaming network, this model features an Access Management Function (AMF) and Unified Data Management (UDM) in the core, wrapped by the Authentication Server Function (AUSF). For roaming networks, 3GPP introduces the Security Protection Proxy (SEPP) for secure connectivity between the home and roaming networks, and the Network Exposure Function (NEF) to protect core services from inappropriate enterprise requests.

2. Encryption and authentication via Transport Layer Security (TLS), certificate management and OAuth2.

But what about security for the 5G services themselves? As the network shifts from hardware to software, telco operators need to have software security provisions in place to protect their data and their customers. At Affirmed, we see this as involving two distinct but complementary initiatives:

3. Secure software development. App developers need to ensure they’re writing secure code, validating it securely (i.e., using static code analysis), drawing from secure repositories and building everything on a secure base layer foundation (e.g., Fedora).

4. Secure containers. Containers represent attractive attack vectors for cybercriminals. 5G operators need to protect these containers by securing the orchestration engine (Kubernetes) with proper role-based access controls, guarding containers in use (through runtime container security) and managing access permissions between the containers via automated policy-driven networking and service mesh controls.

The need for container security isn’t unique to telcos, and that’s actually a good thing because they can now leverage existing security tools that have already been developed for other cloud-native applications. Unfortunately, a lot of telco vendors aren’t familiar with open-source tools like Aqua (for container security) and Falco (for orchestration engine security). Instead, these vendors leave software out of the security discussion, and that leaves telco operators with some big security holes to fill.

The Bottom Line on 5G Security

If telco operators expect to dominate the 5G landscape, they’ll need to stand on the shoulders of some pretty big cloud companies, particularly where containerization and security are concerned. 3GPP’s security recommendations are a good introduction to 5G security needs, but software security is half of the 5G story. If your vendor is telling you only about that part of the story, talk to Affirmed.

 

It’s Time to Come Clean About Cloud-Washing

by Sean O’Donoghue Sean O’Donoghue No Comments

They did it again. Another company has taken their old software, cleaned it up a little for deployment in the cloud, and called it cloud-native.

We call it cloud-washing. Like the “green-washing” of old, where companies would make claims of environmentally friendly products and practices when, in fact, little had changed from the past, cloud-washing is simply the rebranding and repackaging of monolithic, sub-optimal, on-premise software to appear innovative. Creative, maybe. Innovative, never.

True cloud-native software is built specifically to leverage the inherent benefits of a cloud architecture: hyper-scale, high resiliency, service velocity, and hybrid cloud flexibility, for example. Unfortunately, some companies have discovered their own shortcut to the cloud: port their old software onto virtual machines, repackage it as “virtualized” software and stuff it into a container. That isn’t cloud-native, it’s cloud deceptive.

At the core of the deception is a desire for innovation. Communications service providers (CSPs) are facing unprecedented challenges as they look to support an ever-expanding digital economy. Services revenues are flat or declining, while data and video traffic are exploding. As a result, the business model for CSPs is currently inverted, as revenue per bit converges with cost per bit, leaving little room for profit.

Hyper cloud providers such as Amazon, Google, and Microsoft, on the other hand, are turning in record profits by delivering innovation at a very low cost using cloud-native models, open-source services, machine learning, and self-service models. To survive and thrive in the new digital economy, service providers will need to follow suit, embracing the same models, processes, and technologies used by the leading hyper cloud providers. It’s a new world for CSPs, which is why it’s critical for them to have truly cloud-native solutions.

What does a real cloud-native solution look like? Basically, there are five main design principles that determine whether an application is truly cloud-native:

1. Multi-Cloud Support

By its very definition, cloud-native software is designed to be hosted in a multi-cloud environment. Software that cannot be deployed in a public, private, and hybrid cloud environment is not cloud-native, period. Simply connecting to a cloud isn’t the same as being built to run in any cloud.

2. Container Packaged

Software packaging and delivery have evolved from single, monolithic software packages to virtual machines and, more recently, containers. Container and orchestration platforms such as Docker and Kubernetes bring clear advantages to a cloud-native architecture by making applications more lightweight, open, portable, and easier to deploy, orchestrate, operate, upgrade, and manage. Some vendors use the right buzzwords (e.g., containers, pods, Docker, Kubernetes) but have the wrong ideas about cloud-native characteristics, and instead, they package their software as a big, complicated blob.

3. Dynamically Managed

Cloud-native software should be elastic. It should be scaled once for the initial load and then automatically scale up or down using cloud-native tools such as Kubernetes or Helm as demands increase or decrease. We call this dynamic management, and it’s a monumental mind shift for CSPs that are accustomed to dimensioning network solutions based on peak traffic scenarios with very limited agility.

4. Microservices Oriented

IT teams have already successfully implemented a microservices-based architecture for front-end channel applications as well as for back-end customer management and order management applications. CSPs can now invoke and re-use these microservices components in different combinations to simplify software upgrades or create new services. If software claims to be microservices oriented but shows little evidence of delivering autonomous, changeable, replaceable services, you’re probably looking at a cloud-washed product.

5. Externalized State

One of the limiting factors in scaling an application is statefulness, particularly its session state. Applications in which the application and session state have not been externalized to a high-availability store will have a hard time functioning in the cloud.

The Last Word about Cloud-Washing

The promise of 5G as a catalyst for nonstop reliability, new service innovation, and increased revenue is well documented. Re-architecting the network around the aforementioned architectural principles is the foundation for the promise of 5G. At Affirmed, we call that a platform for innovation.

The race to digital services is already underway, and competition will come from all sides. CSPs need a web-scale, cloud-native network architecture that can deliver next-gen digital services. These networks will have to deliver ultra-high performance and advanced features such as network slicing, service automation, and real-time analytics to radically accelerate service creation and drive down network costs.

More than ever, service providers will need to roll up their sleeves and fully evaluate each architectural element, principle, and capability of their 5G platform. This means challenging vendors on their cloud credentials, their roadmaps, and their commitment to open-source technology. In short, insist that your vendors come clean about whether or not they’re selling true cloud-native technology or simply cloud-washing their old products. A high-performance, cloud-native architecture using open-source technology can open your 5G future to more agility, flexibility, and opportunity. Don’t settle for anything less.

The Traditional Telecom Vendor Is Dead. Long Live the Continuous Innovation Partner!

by Seshadri Sathyanarayan Seshadri Sathyanarayan No Comments

For years, the traditional telecom vendor has been the leviathan on the landscape, generating billions of dollars in revenue through hardware, software, and network-related services. But those vendors are going the way of the dinosaur—that is, toward extinction. Telecom operators (i.e. Communication Service Providers, or CSPs) are looking for a new kind of partner, one that can help them innovate and evolve to compete in a cloud-based world that they didn’t create and can’t easily control. It’s a frightening world for many CSPs, one teeming with exotically named inhabitants like Kubernetes, Jaeger, Docker, Elastic and Istio. And it’s the reason why the role of telecom vendors, more than ever, is to help CSPs tame this new world.

What has become increasingly apparent in my conversations with customers around 5G and the future is that CSPs aren’t looking for network vendors. They’re looking for Continuous Innovation Partners (CIPs). In other words, they’re seeking partners who can help them effectively leverage cloud-native, microservices-based technology to drive innovation and service creation.  Telecom operators understand that the fast-fail, webscale development mode popularized by Amazon, Google and others is the future, but they also realize that they don’t have the skill sets and expertise to seamlessly shift to a service creation environment based on containers, microservices, NoSQL databases, and other advanced technologies. That’s where CIPs enter the picture.

The CIP effectively splits the DevOps process by focusing on the development side of the equation, allowing CSPs to focus on the more familiar operational side of managing networks and subscribers. In an environment where services are constantly being created and updated, this looks like a Continuous Innovation/Continuous Development (CI/CD) process. In the CI/CD framework, the CIP is responsible for:

  • Synching code between developers (a/k/a “checking in” code) and building it out
  • Testing the individual service/microservice components
  • Performing quality control
  • Deploying new code to a test environment
  • Fetching the latest builds
  • Service integration and regression testing
  • Packaging and archiving

This process typically takes place in an isolated part of the network, away from production, so as not to impact existing network services. In this way, telecom partners can quickly decide whether to shelf the service or move it into their production network and scale it. By accelerating the service creation process, the CIP allows the telecom operator to adopt a fail-fast mode of deployment and more quickly monetize services that look profitable.

Of course, not every telecom equipment vendor is ready to take on the role of a CIP. At Affirmed, we had a significant head start with our cloud-native UnityCloud platform. To create UnityCloud, we analyzed hundreds of different cloud developer tools to find the best few dozen, then packaged and integrated them with our cloud-native, microservices-based architecture. Doing this required a deep understanding of cloud developer tools and concepts, something that lies outside the core competency of most CSPs and even most telecom vendors.

It’s not unusual for CSPs to register apprehension the first time they see UnityCloud up close, because many of the components are unfamiliar to them. But this apprehension soon becomes comprehension as CSPs realize that we’ve already done the heavy lifting for them by selecting and packaging these cloud-native tools together. By working with a continuous innovation partner like Affirmed, CSPs can leverage the cloud for a competitive advantage without retraining themselves or investing millions to update their software development skills.

The road to 5G is a journey, but it’s a journey that telecom vendors must be able to take with their customers. With a continuous innovation partner (CIP), telecom operators (CSPs) can reach their goals sooner and continue on a path of innovation and monetization for years to come.

Affirmed Networks Awarded Leaders Board Partner Twice in a Row as Part of Intel® Network Builders Program

by Amit Tiwari Amit Tiwari No Comments

Good leaders understand the value of teamwork. They know that good ideas can come from individuals, but good solutions come from people. That’s why it means a lot to us to be recognized again for this year’s Intel® Network Builders Winners’ Circle Awards: it validates everything we believe at Affirmed about the importance of leadership.

Intel Network Builders represents a broad ecosystem of solutions vendors, equipment manufacturers, systems integrators, and communications service providers that have come together to build better solutions using Intel’s industry-leading technology. This year, only a few dozen partners were selected for the Intel Network Builders Winners’ Circle, representing an elite corps of Intel partners. Those companies selected for the Winners’ Circle are awarded the status of Partners, Solution Partners, and at the highest level, the Leaders Board.

This year marks Affirmed’s second year in the Leaders’ Board, and it is representative of the collaboration between Affirmed and Intel to bring together the best of both technologies.  Affirmed’s solution runs on Open NFVI environment which uses Intel® Architecture powered by Intel® Xeon® Scalable processors, accelerating time to deployment with deterministic behavior and transforming network technology with value-propositions for Communication Service Providers, including top-of-the-line performance, lower cost per bit, better ROI, and as a future proof platform for 5G services.

This year’s award comes at a critical time in our industry, as telco operators and enterprises prepare for the commercial arrival of 5G services. Together with our partners, we’ve helped advance the adoption of Network Functions Virtualization infrastructure (NFVi), move network services to the edge for greater efficiency, and deploy 5G services to real customers. The opportunities for growth and innovation are just beginning, and we’re determined, along with our partners, to build the next generation of solutions that drive growth and innovation.

Being named a member of the Leaders Board means that, together with Intel, Affirmed Networks is making meaningful contributions to the acceleration of network transformations around the world—contributions like building the world’s fastest 5G cloud-native platform. We’ll continue to work with technology visionaries such as Intel, Red Hat, and VMware to ensure that the advances being made in cloud and virtualized architectures can benefit telco operators too.

This is what leadership looks like. It’s about putting your customers first and leaving your ego at the door. Accolades like the Leaders Board validate that what we’re doing is important, but the real validation comes from knowing that we’re not just giving our customers the best that Affirmed has to offer, but the best that Intel, Dell, HPE, Red Hat, VMware, and other leaders have to offer as well. Together, we can do more than transform networks; we can change the world.

Cloud Native: The Disaggregation of Software

by Seshadri Sathyanarayan Seshadri Sathyanarayan No Comments

“If virtualization is the disaggregation of hardware, then cloud-native is the disaggregation of software.”

As we stand on the cusp of 5G’s arrival next year (according to most analysts), it’s surprising to me how many people in the industry still don’t agree on what 5G will look like when it does arrive. You’ll hear the usual terms in a conversation about 5G —virtualization, cloud-native, the Internet of Things—but little consensus on what constitutes a true 5G network. Is virtualization enough or does a 5G network have to be cloud-native too? Is a cloud-native architecture simply one that features containerized software or is it something more?

 

What is Cloud-Native Architecture? Here’s a Simple Definition:

Part of the confusion around cloud-native architecture stems from our industry’s affection for making the simple complex. For example, the industry definition for cloud-native invokes a whole laundry list of requirements—containerization, microservices, network slicing, etc.—that many in the industry don’t fully understand. It was during one such conversation, at a recent panel session on 5G networks, where I finally discovered a simple way of defining cloud-native architectures. “If virtualization is the disaggregation of hardware,” I said, “then cloud-native is the disaggregation of software.”

 

Disaggregation & Cloud Native

For me, that’s the whole crux of the 5G discussion right there. Virtualization is a mandate for 5G, true, but there’s a higher purpose for 5G than squeezing more cost out of the network: a mandate to make money. This requires an innovation platform built on cloud-native architecture principles that can enable new network slices and fail fast modes of operation. And disaggregating software is the key to creating and managing such a platform and driving new revenue opportunities of the 5G future. Achieving the right level of disaggregation is the true art within the science of Cloud Native.

To be clear, cloud-native is more than disaggregated software. It involves, among other things, containerization, dynamic management, an externalized state, a service mesh and, perhaps most importantly, a microservices-based architecture. Unfortunately, many network equipment vendors are clouding the perception of cloud-native by limiting its scope to a few checked-off boxes. They build on a foundation of hardware virtualization by re-packaging their existing software in containers, provide some dynamic management tools and announce that their solution is cloud-native architecture. Not surprisingly, their 5G conversations also stop short of promising more revenue. Instead, their focus is on operational and capex savings. Let’s be very clear: If your 5G roadmap ends at network savings, you’ll be running out of road a lot sooner than you think.

Ultimately, 5G is defined by how you define success. If success is saving money and watching other people innovate, then stick to virtualization. But if you define success by shaping the future and embracing the opportunity, cloud-native is a must. There are a lot of roadmaps out there, but in the race to revenue, the path for 5G is clear: the winners will be those who figure out how to drive revenue through new services, faster than the competition.