Video Transcript

ROGER: Hi, everybody. Welcome to the inaugural session of the AlienVault experts’ opinions and ideas. We just named that. I am very fortunate today to be with an old friend and a colleague, and someone I consider a mentor and a true leader in the realm of security, and that’s Dr. Ed Amoroso, who is the Founder of Tag Cyber.

ED: Hi.

ROGER: For many years, he ran up the security operations at AT&T, and today, I’m going to ask Ed about SDN (software-defined networks) and the implication on security both good and bad. I’ve been really looking forward to this because it was about 7 or 8 years ago that an employee of mine was in my office, banging on the table and banging on the doors that SDNs were going to change everything, and the world was going to be a completely different place. And I’ve got to admit I didn’t get it. I didn’t get it technically. I think I have an idea now, but I also didn’t understand how quickly it would be upon us.

ED: Right.

ROGER: Give our audience a little background on SDNs—what is it, why is it so important, and what are some of the macro-level impacts it will have?

ED: I’d be happy to. So, if you think about software-defined, it’s a way of using software to virtualize something that previously was tangible. For example, when was the last time you bought a calculator? Never, right? I mean, if you go back, you and I would go buy a calculator. We would buy a TI calculator. It was a piece of equipment we held in our hands. Eventually, that became virtualized as an application that ran on another platform. So, we all use calculator apps on other things—software-defined calculators.

When was the last time you bought a flashlight, right? Now we use our phones. A piece of software has actually virtualized something that you would never have dreamed in a million years could be virtualized. A flashlight? What are you talking about? I need something that’s going to emanate light, and the idea that now flashlights are apps on some other platform is also kind of natural, but we don’t always think about that.

When you take a moment to think, ‘Hey, you’re right! I do use my phone as a flashlight. I do use my phone as a calculator,’ so the question becomes “Can you use infrastructure—a vanilla, baseline computer infrastructure—to implement other types of hardware components that you never would have dreamed could be virtualized.

In the world that I’ve lived in, that you and your team lived in as well, that’s a world of network devices, routing, switching, computing, and so on. So, take a router, for example, the idea that it is a piece of equipment in our mind that takes a bunch of network inputs and network outputs and makes decisions, and we would think of it as the traffic cop that sits in your network with wires going in and out.

So, the question becomes “Can you software-define that?” And the answer is you absolutely can. You can create a software object. We would use the term “virtualized function” or “network-virtualized function.” There are all these different variations on NFV and NFs and so on, but basically, you're virtualizing the network component, and that becomes a piece of software that does what a piece of hardware used to do, and that has a lot of implications.

For the folks listening here, if you’re a CIO of a small company, the idea of introducing a routing function or switching function or whatever always conjures “hardware,” and hardware means some sort of procurement, some sort of delivery, some sort of installation, some sort of test, and then you're carrying capital as part of your annual budget. You realize that when you put the hardware in place, it’s a material piece of capital. That’s the financial implication on your business.

Now, suddenly, that becomes a button that you're provisioning on a portal perhaps through your service provider. Then it raises an eyebrow, and you say, “Hold on here a minute! That changes the game a little bit.” So, I can actually build networks now creatively with routers and switches and hubs and load balancers that are no longer piece of equipment in a rack but just pieces of software that I provision by clicking on buttons. Anybody listening, if they think about that, they can think of a thousand implications I can’t even think of, but that’s the promise of software-defined networking. It changes the management game for people who fool around with those types of things.

ROGER: So, very flexible, very fluid, very dynamic. One of the first things that comes to my mind is a little bit of a concern. You know that old calculator, that old router, that old switch, the hard disk drive? These fail when components get old and tired and break, but boy, from a logic point of view, you could trust them, right? You go up higher in the stack in the world of ifs, thens, and elses and software, and there are a lot more mistakes and errors. Is that a cause for concern with software-defined networking if we’re able to algorithmically, in real time change our networking? Are there security implications? Quality implications?

ED: There are probably some cons. I mean, one thing from a very tangible level—your flashlight wears out. 1s and 0s will never wear out. From now until the end of the universe, the 1s and 0s will continue to operate, and that is a profound concept, the idea that software does not wear out. In fact, the term “software maintenance” is a misnomer because you're not really doing maintenance. You tend to be adding features or fixing mistakes; you’re not maintaining something that quote-unquote is “wearing out.” I think our grandchildren and perhaps later generations won’t even know what it means for something to wear out. They’ll know what it means for something to evolve. So, that’s the first thing.

The second is that if you design things properly, as I think… There have been little pockets in our history where I think software design was going through better times and times when things were worse. In the early days of UNIX, there was an idea of building a software tool, which meant you built one little thing. One thing! It doesn’t do two; it doesn’t do ten. It does one. It does it well. It does it simply. It does it a demonstrably correct way, and then it gets put onto a library shelf, where you can reuse it.

I think that’s an amazing concept, and SDN is very conducive to that because the way SDN works is that you develop a component called a “controller.” It’s a blob of control software that, for an old telecomm person like me, reminds me of signaling System 7, but you can think of it just as a big management structure. It has two sets of interfaces. We think of it as a southbound interface (things pointing down), all the things that are being managed—computers, networks, routers, and so on—and then a northbound interface, where you put applications on. Those apps can be very simple software tools that do one simple function, and I think that if the design is done properly, we can at least get to the point where the overall architecture supports and encourages elegant software design.

Now, yes, you’re right—when you build software, we still have problems with software engineering. People can’t fundamentally build large, complex systems using software, so you can come to one of two conclusions for that. One, don’t use software—that’s not a good conclusion. But how about the second being don’t build large, complex systems?

ROGER: [inaudible 00:08:17]

ED: Right! You go, “Well, wait! How do you build these big, complex things?” The answer is you build a house from a lot of little bricks, right? The brick guy doesn’t worry: “Oh my God! How is this going to fit into my house?” The guy making the brick makes the brick and makes sure it’s smooth and it makes sense and it’s sturdy. There’s a brick, and then that brick is used by someone to build a house. I think too much of these complex systems that we see… You know, “I have to do this; I have to do that; I have to do this,” and we do it all, instead of focusing on building one component, so I think SDN encourages that to some degree.

ROGER: Great informative background and good advice. So, let’s talk about it from a security point of view. What are some of the things that we’re going to be able to do in an SDN environment to help enhance our security that we’re not able to do in a traditional environment?

ED: Yeah. Well, one is the whole identifying problems and replacing with a clean image. Today, when we go to patch, it’s a mess, right? You're not sure where you need to put the patches, and it’s hard to deploy them. Well, there’s this image of the… A hardware image of the pizza board appliance being broken, and you pull the pizza board appliance out, you whip it in the garbage, you put a clean one in. SDN is software, but it still has the same concept that I think you’ll see patching and provisioning be simpler because we can build clean images off in some laboratory, make sure it’s right, and then just deploy those images, and that’s a simpler kind of thing. Forensics is made simpler because we can basically grab an entire image, drop it into a forensics lab, do what we need to do.

All of these interesting things pop up, but perhaps the most important thing is something called service chaining. That means when you have an SDN environment, the functions that need to be put into that environment are deployed virtually. So, for example, let’s say, Roger, you and I are running a retail store that does a lot of business at, say, holiday time, Christmastime, in December. And we’ve got an architecture in the old days with a bunch of hardware components, and we decide that we want a little more security before the retail season, because we do all of our business in November and December. How easy is it for us to deploy a new firewall, put it up for two months, and then take it down? It’s crazy.

But with software, we push a button, and the service chaining concept of a virtual appliance being put in place, connected in a gauntlet manner to that virtual connection to whatever workload you're trying to reach, leaving it up for a couple of months—it’s just software. And then when we’re done, de-provision it? That rocks. That concept for security is what we’ve all been looking for forever: the ability to deploy rapidly, the ability to be a little uncertain. “I want the bad guys to not really know what I’m running or when or where or how. It would be good to mix it up a little bit. How about I try a little bit of this for a couple of months? Why not? No need to be so predictable.”

All that carries promise that I don’t think the community has even begun to consider yet. Quite frankly, it gives the SDN vendors, tier 1 carriers, big advantage because seeing your LTE network or 5G network, you have a relationship with a tier 1 carrier, and to the degree that they can essentially allow you, in your mobile infrastructure, to just point and click—that’s a big advantage for them.

Now, the industry will find ways to work around that, but I think you probably will see some emphasis in the coming years on tier 1s offering these things natively. We’ll have to watch, and then what will happen is great companies (like AlienVault) will build the technology that will service chain in, and that’s the thing you click on. It will be your logo, but the framework will be 5G. You're not going to build a 5G network. We all have it.

ROGER: Right.

ED: So, it’s really kind of a promising future because I think the defenders will have more capability as a result of virtualization and software-defined networking. Does that make sense?

ROGER: Really well put.

ED: Yeah.

ROGER: As a software developer, the idea that my most important algorithms are how I detect threats… All of the other stuff I have to do to get the data off the network and prepare it in a way that I can run those algorithms is overhead, and if there’s an SDN environment that allows a vendor to just drop in that little piece of code that’s very germane to what they do best, boy, what a great world that will be.

ED: That’s what we’re looking forward to.

ROGER: Last question. There are some people that are skeptical that say, “Well, this is all great, but it’s going to take forever to roll out.” The first thing I would say to them is basically every cloud environment today is software-defined networking—Amazon Azure or what-have-you—but help us understand a little bit more the timeframe of when you expect to see this everywhere. We mentioned in the mobile environment from the carriers. Are we talking a year, two years, five years? If you’re a CIO, and you're buying network here, what’s your horizon for this?

ED: Well, I think there are three different timeframes. There are small companies, medium companies, and large companies. In the old days, if you and I were sitting here in the ‘90s, I would tell you the advantage goes to the big guys because they have bigger budgets, they have bigger teams, they’re going to move more quickly. Blah, blah, blah.

Today, it’s the inverse. Small companies are already in the cloud. They really are. I started my little consulting and advisory business after leaving AT&T, and it took me about three days to have an infrastructure up and running with invoicing, payroll, email, calendar, everything, and you go, “Wow, I wouldn’t have been able to do this in the old days.” And the architecture is distributed; it’s virtual with virtualized security. It’s very cool.

ROGER: It’s all backed up in the cloud.

ED: But if you go tell… So, small companies are already there. At the other end of the spectrum, a big, monster bank has already got a massive, sunk infrastructure. They’ve got embedded operations. They’ve got a perimeter around the whole place. They’ve gone through umpteen different audits on that—expensive ones, where the stuff is on the wall and gives them the ability to operate. You start ripping things out and moving to the cloud, you're invalidating audits. You have regulatory issues. Suddenly, you can’t operate. You can’t do that. So, advantage now goes to the little guys, and you’ll see the smaller companies moving really fast, medium companies pretty fast, and the bigger companies relatively fast.

ROGER: [inaudible 00:15:28]

ED: So, tell me when the regulatory community becomes more enamored with cloud, and I’ll be able to answer your question for the bigger guys. You shouldn’t be afraid of software-defined networking if you’re a regulator or auditor. It would be crazy to not take a moment to think through how that can help rather than saying, “No, it’s new! No, no, no, no.” So, I think the answer to the question really: The smaller guys fast, the medium guys a little bit less fast, and the big guys will have the biggest challenge. So, we’ll see.

ROGER: Boy, that is some great advice, and we’ll leave it there. Most of our audience are small- to medium-sized enterprises and taking advice from someone who is at one of the largest. If you’re small and nimble, take advantage of that, and act fast.