The Converging Network

The end of Netscape as we knew it

The passing of an old friend... Yesterday AOL announced it would no longer continue the development of the Netscape browser. Along with Mosaic and HTML, the Netscape web browser (Mozilla-based) is what most of us thought of as the Internet, even created the Internet as end users know it (though there is now evidence that Al Gore worked on Netscape code early in its existence.) 

It seems like only yesterday (if you close your eyes and squint real hard) that you were cool if you were using the Netscape Communicator server to develop web sites and products for the world wide web. (It's seems odd now to say "world wide web" instead of "the web".) My original business plan for BoldTech Systems was to be a web site development company. The business plan modeled out how many customers we'd have, how many sites web be developing per week, etc. Despite some early efforts with a few local companies and GNN who was bought by AOL, we instead became a telecom systems integration consulting company. (I think there's a connection there somehow, lol.)

Netscape created a lot of excitement, was new and cool, and marked the beginning of the '90s Internet hay day. It was a heady and hopeful time. You had the feeling that you were working on the forefront of a new generation of technology. Networking and software came together in new and interesting ways. Web sites led to web apps, delivery of all kinds of content, and new kinds of businesses. It also led to the market breathing a lot of its own exhaust, like startups whose business plan was to register domain names like furniture.com or pharmacy.com. While things did get way out of hand and then later suffer through a needed correction, you can't take away what Netscape did to lead the way creating a new generation of software and networking.

Hats off and a thank you to the Netscape browser for helping reshape the industry we work in today.

Podcast 50 - "The Big 50" and more

Welcome to our 50th podcast. Has it really been that many? Well, the links don't lie so I guess we've hit a new high water mark.

For our 50th podcast, Alan and I kick back and just talk about what we want to discuss. No guests this time, just us 'ums.  During The Converging Minute I talk about virtualization and security, and how the two are intersecting. Alan and I then turn to topics of interest where we discuss:

• Is security slowing down the adoption of virtualization?
• What good is "menstrual NAC" - you know the kind that only checks devices once a month and my new rules on NAC
• The new space race to put IP technology into space being led by Cisco
• Can UTM be 50% of the network security market?

It's nice to get back to our regular show format, and I hope you enjoy it too. Also, something that I'm very remiss in mentioning is to thank Alan for all of the additional work he does on the podcast.

Alan's been "sound engineer" on the podcast since day one, and while we don't edit our discussions or interviews (they are pretty much as is, just like we recorded them), there is still quite a bit of work involved. Every podcast, Alan splits and combines the channels, splices all the segments together, level-ates the file so everything is the same volume level, and then uploads the file to our ClickCaster site. So "thanks big Al" for all the extra things you do for our podcast.

Enjoy the podcast and feel free to drop us any suggestions or questions at podcast@stillsecure.com.

mp3 file

Wanted: "Slash" to run data center fabric of the future

Are we ready for the Cisco/VMware virtual data center? Get ready because that's the message about the data center's future from Cisco and VMworld 2007. Essentially, grid computing, storage and networking with VMware as the data center OS and Cisco's Vframe managing the data center network cloud. Cisco describes this all as the "data center fabric". It may sound dreamy right now but if Cisco is really able to pull off this software strategy, it would literally change the face of the data center.

Stuck right in the middle of this strategy is the shifting sand of Microsoft's virtualization licensing restrictions, which has had VMware up in arms for some time. Microsoft's ability to control when it's OS can be virtualized may allow them to charge for licenses but restricting the technology that can be used raises anti-competitive vibes. Linux obviously does not have these same Microsoft complications but it would take a tectonic plate shift to completely displace Microsoft from the data center. Not in our lifetime anyway. I still see the major sticking point as to whether Cisco can pull of this software coup, it truly would require Cisco to become a very strong software company.

A huge complication no one is talking about is how the "data center fabric" intersects multiple disciplines across IT. Network design, provision and management mashed up with data center server and applications management, software development and system administration sounds like the Pittsburgh Steelers Kordell "Slash" Stewart equivalent of the IT career path.

This organization upheaval, and IT skills and change of job descriptions will be an even bigger challenge than any of the technology issues Cisco is likely to face. Microsoft has made much stronger inroads into networking than Cisco has into IT systems. This game isn't over so I wouldn't assume creating a happy ending for Cisco will be an easy one.

Cisco NAC module for ISR's - shot across the bow or converged network?

Last week rumors circulated and this week Cisco announced a Cisco NAC hardware module for their Integrated Service Routers. It's basically a PC on a blade that inserts into the expansion slot of Cisco ISR routers. Now, mind you, it's still running the same seriously flawed (in my opinion) Perfigo/Clean Access NAC product all the other Cicso NAC Appliances run, so it will experience the same flaws and limitations. But the fact of the matter is there will always an audience out there who will buy Cisco no matter what and just hold on until they assimilate the product and fix most problems.

Frankly, I'm not a bit surprised to see this, not because I had any privy insider goo on Cisco's product plans, but rather I've been espousing exactly this for NAC and convergence for quite some time. (I guess in your own blog you can take claim for knowing anything you want too, lol.) Cisco's move of NAC into ISR routers makes sense from several perspectives, and I'd say the move was inevitable.

Here's my "tongue-in-cheek" top ten reasons the NAC module for Cisco ISR routers happened:

10. Security products start as best of breed/standalone products, and over time most migrate into network infrastructure and become value add or standard features

9. Whether you call it admission control or access control, NAC first happens at the edge. Distributing NAC into edge routers just makes sense.

8. First, NAC in routers. Next, NAC in switches. Nevis and Consentry, time left to get acquired is getting short

7. No one bought last week's PR exercise in revisionist history about the Cisco NAC Framework and Cisco NAC Appliances merging into a single NAC strategy, so hopefully this week's NAC announcement will help all of us forget that lame-o announcement

6. If you can't scale, just make smaller versions of your product

5. If Cisco converges NAC security into the network infrastructure and uses Intel hardware to do it, what's left for that Ashley-blogger-dude to gripe about

4. How else would Cisco pinch you for more bucks when you buy a commodity router appliance?

3. It's a good way to get NAC to the SMB and SME markets.

2. The dang router had an expansion slot - an Intel card had to go in there someday!

And... the number 1 reason.....

1. Cisco only did this to make Chris Hoff feel good; NAC is a feature, not a market.

Okay, putting my personal feelings about Cisco's NAC products aside for a moment, moving NAC into routers and switches makes a great deal of sense. Not that the whole product should live there, but elements of NAC make perfect sense to distribute out to the network edge where traffic and devices can be dealt with at the point of connection. More than just behavioral IPS retreads marketed as post-connect NAC solutions, but strong NAC endpoint compliance engines and strong IPS technologies that perform valuable security services at the point of connection.

Cisco has some serious architecting to do before the Cisco NAC ISR module becomes more than just a delivery vehicle for providing a router and NAC in one package. Integrating NAC into the network ednge is a very viable approach but Cisco's announcement isn't about that as much as it is about bringing NAC to SMB and SMEs.

Oooo free stuff, and you can help with product design

We'll be doing tests of the Cobia and Strata Guard IPS module user interface designs at Black Hat (August 1-2) and LinuxWorld (6-9). If you are interested, please send your contact info (email, phone number) to cobia@stillsecure.com.

Oh, yes. There is some free stuff for those who participate. Thanks!

Aggregation is inevitable

DNS on your router? Yes. Richard Bejtlich who has a great blog over at TaoSecurity posted about it yesterday. As Richard notes, Cisco routers have been DNS-capable for the last year or so, though probably many don't know it. There's actually a site that describes various uses of router-DNS combination, such as having a router cache and forward DNS requests for devices within a DMZ. One of Richards concerns about combining these and other services is the potential security risk of one compromised service providing access to other services on the same device or box. The obvious solution is the one we've largely followed to date; apply separation of duties on different boxes.

Consolidation, functional aggregation, or convergence; regardless what you call it, this is already happening. Sure, there will always be reasons to have specialized boxes but the trends are all pointing in the opposite direction. Because of trusted relationships between devices and networks, even specialized or single function boxes still pose a very significant risk if compromised within the network.

Richard's basic position, if I'm adequately summarizing it here, is that businesses without the sophistication or expertise will place a greater reliance on converged devices. That be the case but I believe different causes are creating this result, not lack of sophistication. In many cases, it may just the opposite. Let's look at some of the drivers around convergence.

• Managability - Less devices, less vendors, less disparate technology simplifies management. Smaller business have less infrastructure needs. Larger enterprises want ways to both standardize equipment at remote and smaller offices, and drive down the management costs (including people) needed to service, monitor and maintain infrastructure across the organization. Convergence helps achieve that goal.
  
• Economics - While networks, computer equipment and security are all vital to maintaining a functioning business, the cost to operate and manage the infrastructure is an overhead cost. Convergence helps reduce costs by simplifying network complexity, and taking advantage of the lower cost equipment in the UTM, UNP, multi-function devices, and increasingly, general purpose computing Intel/AMD technology (both in appliances and with off-the-shelf hardware.)
• Resources - Hardware is a delivery mechanism, not the end result. Why have five boxes if I can have two? Why have two if in this situation one meets the needs? We've grown up in a networking paradigm where a box does a function. What more functions - add more boxes. From a security view it makes sense; separation of duties reduces risk. But it's the underlying software, whether burned into a chip, loaded from a flash drive, or brought in from a disk drive, that delivers the services. The hardware is the speeds, feeds, and operating platform for those services.
• Disassociation of hardware and software - We're coming to the realization that for most applications, the binding of services performed by software to a specific hardware platform makes just as little sense in the network as it does in the data center. Sure, switches need lots of switch ports because of the port density requirements to fulfill their role in aggregating network traffic. But does a router, firewall, DNS or other network services really have to be bound to a single piece of hardware? In most cases, not really. Matter of fact, it is a significant limiting factor because increasingly it is unnecessary to bind them together. To support the networks of the future, these bonds must be broken and even Cisco recognizes this, though it is yet unclear if they will truly make this transition "to software" successfully.

I'm not saying that Richard is wrong, necessarily, just that there are other factors at play here. Some I've listed above. As the network gets pushed further and further out, as the perimeter dissolves into many micro-perimeters, and as the network reaches out and interconnects more of the world we live in, economics and scale changes the game on us. Make it easier. Drive down the life cycle cost. And deliver more. Make it viable for new communities to deliver and manage these services. Those are the laws of progress that will help make convergence inevitable.

Can Microsoft, Cisco and IBM work and play well together?

That's what customers what - better interoperability between Microsoft, Cisco and IBM, according to Peter Galli's eWeek article following Microsoft's recent Interoperability Executive Council attended by large Microsoft customers. Microsoft claimed that attendees feel Microsoft's web services are well put together but that IBM and Cisco could use help from Microsoft. I find that hard to believe, at least in the case of IBM's BEA, but hey, they only talked to Microsoft for this article.

I can relate. Integration and interoperability are huge challenges, especially for large enterprises where so much effort in these organizations are put into making products and technologies work together. I spent the first half of my career doing just that for telecom and financial companies. Those lessons learned are a lot of what's gone into the Cobia Framework, the underlying software architecture within Cobia that gives Cobia modules all of the open, plug-n-play, distribution transparency and other key capabilities. I've learned, through past hard knocks, that throwing a bunch of software on an operating system and plastering it over with a nice GUI does not an architecture make. It's one of the reasons I believe some vendors don't want you under the hood of their appliance. You might see what a mess things are or how much real proprietary technology (or lack of) you are paying for.

Interoperability is a challenge. Vendors usually only give customers APIs - the details (and you know what they say about the details) are left to the customer. Reminiscent of the phrase; "Some assembly required." Without some real partnerships and alliances, there's not much likely to come from the Interoperability Executive Council's request to Microsoft to work with IBM and Cisco. Asking Microsoft to do this may just be an exercise of tilting at windmills.

This is an area where I believe open source and architectures like the Cobia Framework will play a role. Customers want ease of use but they also want something that will "work and play well together" in their network. Innovation like this is not likely to come from the big vendors, especially when it requires they enable their competitors to compete more effectively against them. Open source projects and products are in a much better position to solve this problem, and that is my aim with Cobia. By creating an open source platform with a well defined software, operating system, network, distributed and interoperability architecture, it is much more feasible to bring networking, VoIP, security, video onto a converged platform and network. As we reveal more plans and capabilities in Cobia I think we'll see how this can happen and fit in with the goals of the vendor community and users.

A short flight home

I'd say it's been a very successful Interop for all involved in my company. As usual today was comprised of many more vendors selling vendors, and competitors stopping by to try and to snag a tidbit or two. Now, for packing up our stuff and heading home.

I'd like to take a moment and thank everyone involved in putting together our presence at Las Vegas Interop this year. Cherie, John, Aimee, Rob and Sonya all did a bang up job and it's really appreciated. I'd like to thank Jason, our Cobia community volunteer who worked the show with us. And of course everyone form the sales and technical team who worked the booth. Bizdev of course played a huge role bringing in the partnerships and programs we announced. Most of all, thanks to Cherie for leading the effort for our Interop presence.

Until next time (can you say "Black Hat"?) everyone, many thanks.

Update: I failed to mention one very important person in my original post and that is Tova Sand of tovadesign.com. Tova did all of the graphics and layout work for the booth, online and print materials. Fantastic job, Tova. Thanks for all great work!

I love it when a plan comes together

I always like to get my hands dirty on the projects I work on. Not programming as much anymore (I work with too many code wizards who would show me up very badly) but more the networking, security and product design and management. And I get pretty wrapped up in it too. I can't help it because of the sense of ownership I have, and the responsibility I feel to all the people who invest so much of themselves in products.

Every once in a while something happens where I have the opportunity to sit back and gain another perspective on things. That's happened this week at Interop.

Almost all of my time this week has been filled with analysts, press and partner (current and future) meetings. As a result, I've not been able to spend very much actual time in our booth at the show. As I walked back to the StillSecure booth on Wednesday after one such meeting, I came up upon our booth and I had to take pause. I probably observed the happenings there for several minutes.

The booth was a beehive of activity. Demos were happening at each of our demo stations, led by members of our development and QA team. The benches were filled and even more people were standing in the back to hear the presentation by our product evangelist. Marketing team and sales team members were engaged in dialog with people in the isles.

You've heard quarterbacks describe how the game goes into "slow motion" where they can see all of the playing field, and the play develop right before them. I stood there for what seemed like several minutes just taking it in. The scene was like observing the movement pieces in a fine chronograph watch, all doing their part to create such highly accurate time which we take for granted all too often.

As I approached closer I was promptly handed three business cards of interested partners who stopped wanting to learn more about our programs. Then two different parties descended into two threads of a Q and A conversation wanting me to join in. Back to real time. Time for observing is over. Get back in the game.

I tell you about this because it helped me appreciate how much hard work goes into such an event. My general rule is that when things look easy, it's because a lot of people (here and in the office) put a ton of hard work into it. Aimee, John, Rob, Sonya and Jayson for example, put in a ton of work behind the scenes. And of course there's our entire program management, product design and product development teams. That's why all of this looks so easy. I'm just thankful that in the thick of things, something created that moment for me to pause and take in what everyone's hard work has created. Cherie is our trade show leader. My hat's off to her and the entire team for all helping make Interop a success for the the company.

I love it when a plan comes together. Better even yet, when your team members' talents, skills and passion make that plan come to life. Thanks team.

Security meets technology lifecycle

I recently did an interview with Brian Robinson at IT Security about StillSecure's Cobia product launch. A bit different from other interviews, Brian picked up on several things I've talked about during various interviews and discussions but don't always make into standard product announcement coverage.

Part of my theme about network and security convergence is that they not only should live side-by-side in the network, but that security is increasingly being embedded into the network infrastructure itself.  It's part of a natural technology evolution; new technologies are introduced as standalone solutions and over time, if they prove valuable, become elements within other technologies, in this case the network infrastructure.

Another way to look at this is a phrase I've heard others use (and borrowed myself at times) about the "operationalization of security". (Now, there's a mouthful - I don't use the phrase that often because it's hard to say and not slur the word, lol.) As security technologies are deployed throughout the network, the operational responsibilities for those technologies usually gravitate into an operations oriented organization, such as Network Ops or Network Engineering. (I'm referring to larger companies here of course.) Security teams are tending to focus more on policy, compliance, planning and vendor technology research.

I had an interesting conversation with an analyst from a well known firm who basically agreed with these ideas. One of the things I've learned about organizations, particularly big ones, is lots of different organizations may say they are responsible for some product category or technology but it most often comes down to whose budget actually has the money to buy it. They are really the decision makers in many cases.

Sometimes that money moves too - it may start in security and once deployed it migrates to the organization responsible for operating it or folding it into the overall network and infrastructure planning. Companies I've seen that do the best job of this actually recognize this cycle of events and organize their planning, evaluation, purchasing and implementation around the fact that this happens. It makes for a lot less in-fighting and politics over who controls what.

I've taken one small element of what the IT Security article was about and expanded on it a bit here. The article was actually much more about some thoughts of mine on Cobia. Feel free to check it out if you'd like to read more.