Email a colleague    

February 2011

Single Sign-On: The Cornerstone of Network Security & Integrity

Single Sign-On: The Cornerstone of Network Security & Integrity

Security vendors who serve the enterprise market usually give short shrift to the unique security requirements of telecoms.  And the reason for this boils down to simple dollars and cents.

Security vendors make the lion’s share of their money from enterprise security solutions where the goal is to mostly protect “data at rest“ — relatively static data stored in, say, a credit card, intellectual property, or customer database.

But telecoms face an altogether different issue: The data they protect is “data in motion“ — massive volumes of traffic traversing large and highly complex multi-layer, multi-vendor networks that whizz past many end-users.

There’s another issue too: People have long considered telecoms impervious to attack. “What hacker is sophisticated enough to hijack a telecom network anyway?“ they say.

Well, recent events are changing some minds here.  The Stuxnet bot, for example, successfully targeted Siemens’ equipment in power plants.  And not long ago, one-fourth of all Internet traffic was redirected to servers in China.

Last year, TRI completed a study and found that comprehensive network security is not well understood — by telecoms and enterprises alike.  Most IT/telecom professionals think of security only in terms of cyber defense: the repelling, detecting, and remediating of viruses and worms through firewalls, intrusion prevention systems, and antivirus software.  Yet the critical role of central security management functions provided by Security Information Event Management, (SIEM), and Network Behavioral Analysis, (NBA), systems is largely unknown outside of security specialists.

Another critical but overlooked security measure is single-sign on.  Sure, people recognize the convenience benefits of single-sign on, but there’s also a very compelling security case for it, especially in telecom.

An oft-quoted cyber security joke is that the problem lies “between the keyboard and the chair,“ in other words, the user visiting evil websites.  But here’s the surprising thing: The greatest security threat is not the careless Web surfer, but the innocent misconfiguration of network elements like routers, switches, and firewalls.  And single-sign-on is a big help in the configuration area.

Having implemented single-sign solutions for telecoms and network equipment providers alike, Sergio Pellizzari, solutions architect of Nakina Systems, has vast expertise is this area and so we’re pleased to have him as our first guest in this telecom security blog.

Sergio was with Nortel for more than 18 years until 2001 when he left and co-founded Nakina Systems.  There he spearheaded the concept of a Network Operating System: a mediation layer between the Element Management Systems (EMS) and the Network Management Systems (NMS), a concept becoming all the more important to telecom service providers as their networks move from a centralized switch architecture to a distributed array of network elements and operating systems.  Any misstep in the configuration of these devices can create security vulnerability or cause a service outage.

In this interview, Sergio gives us a deep dive on single-sign-on, explaining why it’s important for reducing outages and securing network elements.  He also shows us why telecom requirements for single sign-on are far more demanding than those serving the enterprise.

James Heath: Sergio, to begin, can you give us a quick rundown on the impetus behind single sign-on at carriers?

Sergio Pellizzari: Sure, James.  Traditionally, network equipment providers (NEPs) have tried to offer it by having an EMS launch a session to the network element itself, but often credentials are different for the EMS and the element in question.  In a multivendor network, a single operations person may have to remember 20 or more different sets of individual and group credentials.  Well, service providers got sick and tired of that because there were way too many logins to manage (and the cost of yellow stickies and their inherent security risk was too high!).

So in recent years, telecoms have begun to simplify secure network element access and also track the logins to aid in troubleshooting.  And these newer, more stringent single-sign-on requirements have opened up opportunities for companies like Nakina to leverage their network element and telecommunications knowledge and deliver solutions.

I know that in the enterprise IT space, there are plenty of companies who offer single-sign-on capability.  Why aren’t these solutions adequate for telecom?

In general, telecoms need something with a far greater scale, reach, and centralized control than enterprise shops.

In the enterprise, single-sign-on appliances are usually installed to access a database or maybe an SAP application.  But at a telecom, the scale is far greater because you’re talking hundreds of operations staff simultaneously accessing dozens of multi-vendor network elements, so scalability is big requirement in telecom.

Another problem is the limited “reach“ possible with your typical enterprise single-sign-on appliance.  Most telecom networks are regional networks that were acquired and merged over time, and the firewalls that guard these networks are still regional.  Now an enterprise appliance can’t necessarily punch through those firewalls.  In other words, if you want centralized control, you need something on both sides of the firewall.  And that’s possible with our multi-tiered software solution.

Another issue is that many enterprise security solutions require installing an agent on the end device.  Now that’s not a problem in a Windows or Solaris environment when you’re simply running an application.  Sure! Throw a little security daemon on there you can talk to.

Unfortunately, you can’t do that in the telco world.  Telecom vendors are reluctant to put agents on products like their femtocells or eNodeB’s.  They are not going to spend a year and a million dollars doing verification testing of their products and then allow third party software on their platforms.  The potential risk to the equipment performance is too great.

How do you avoid putting software agents on the equipment and still provide network-wide reach?

Our approach is to write software adaptors that speak natively to the network element.  Every user logs in to our system, which logs them into the network element using the credentials supplied by the service provider.  In this way, we act as a proxy so the end user never knows the credentials actually used to log them into the device.

There are a few advantages to this approach.  First, since Nakina controls user access to any network element, we can record all user actions using video logging.  Second, we don’t need to put any software on the network elements themselves, so we don’t impact equipment.  Finally, we can reach through firewalls so carriers can access their whole network from one swivel chair.  The bonus with our adapters is that we have the capability to rotate the passwords on the end devices, separately from the user, so the users don’t actually know the credentials used by the system to access elements directly.

We’ve heard the story about efficiency and the problems with single sign-on, but what about actual security problems?  Have you run across any horror stories that show why single sign-on is important?

Well, one of the stories I like to tell concerned a well-known cable provider and all their VoIP service was going to a fairly large partner-carrier of theirs.

A staff member of the partner carrier was trying to log onto a router through Telnet, which is quite common.  Telnet is handy because you can use it to configure any router on the planet that comes from Cisco or Juniper.  You just Telnet to a box, type in the IP address, and bang — you’re logged on as a power user and can do whatever command line stuff you like.

Now imagine as you Telnet to a box, you get a digit in the address wrong.  Well, in this case, they typed in “69,“ when it was supposed to be “89.”  And as bad luck would have it, this mistake gave them access to the exact same model of box but outside their operational region.  So here’s a case where they did the right thing to the wrong box, which happened to take down the cable providers’ VoIP service for a full 12 hours!

Reminds me of the Swiss cheese story.  If security protections are layered like slices of cheese, each security flaw is a hole that has no impact until that extremely rare time when all the cheese holes line up.  And that’s when a disaster occurs, like the one you described.  But tell me, Sergio, how would single sign-on as executed by Nakina avoid the case you just discussed?

Well first of all, we wouldn’t permit low-security access via Telnet for every user.  Second, someone from one region would not be presented with an opportunity to log in to an element in a different operational region.  And finally, though we can’t prevent them from doing the right thing to the wrong element, our centralized logging and video logs provide a detailed record of the transaction so you’d at least know exactly who did it and that lowers your mean time to repair significantly.

Is there any advice you can give the service providers or the NEPs on how to tackle their single-sign-on problems?

The problem is that service providers and NEPs are coming at the problem from two different directions.  Equipment vendors would love to offer a single-sign-on capability but most development organizations do not address single sign-on company-wide.

But even if a vendor could offer single sign-on to all their products, no service provider is a single vendor shop anymore, so a unified single sign-on from one NEP doesn’t solve the fundamental problem.  And here’s where we feel a neutral third party who can deliver a multi-vendor single-sign-on capability adds great value.

When a network gets large, you not only need to ensure that it’s secured, but that all the security-related parameters are set appropriately.  So single sign-on is a key element of an all-embracing concept Nakina calls “network integrity.“ And network integrity is not limited to security, but encompasses related things like physical inventory of installed equipment, equipment configurations and the maintenance of these device configurations.  So when networks stand on this sort of bedrock, you can build and deliver lots of fancy services on top and never have to worry about the foundation collapsing underneath.

This article first appeared in Billing and OSS World.

Copyright 2011 Black Swan Telecom Journal

 
Sergio Pellizzari

Sergio Pellizzari

Sergio Pellizzari is solutions architect of Nakina Systems.  He was with Nortel for 18 years till he left to co-found Nakina in 2001.  He is a pioneer of the Network Operating System, a mediation layer between the EMS and NMS.

Nakina Systems provides Network Integrity Management solutions to the telecom industry worldwide.   Contact Sergio via

Black Swan Solution Guides & Papers

Related Articles