To understand secure domains, it is helpful to think of virtual LANs or VLANs. The first time I remember hearing about VLANs was in the early 90s, when I took a meeting in my Massachusetts offices with Charlie Giancarlo, while he was at a company called Network Equipment Technologies (NET). Charlie was trying to describe how ATM switches could emulate Ethernet broadcast domains and to that end used the term VLANs. I remember the light bulb going off in my head when Charlie, struggling to define an emulated LAN, said this is not an emulated LAN but more like a ?¬¢‚Äö?ᬮ??¨Virtual?¬¢‚Äö?ᬮ¬¨?? LAN. All the Ethernet switch vendors, such as UB, Synoptics, Cabletron, Kalpna, Synernetics, Crescendo/Cisco, Alantech were using the term VLANs to describe a technique to create, modify and in essence manage broadcast domains.

VLANs played a huge role in the market expansion and adoption of switched Ethernet LANs, since corporate IT managers were now able to design networks to increase performance by reducing the number of end systems per broadcast domain, provide logical barriers between groups and place certain applications in higher priority VLANs. Before VLANs, a LAN was one large broadcast domain with every PC and server being interrupted to process packets resulting in the slowing down of the entire network as it grew. The only way to segment these networks was to put a very expensive router in between broadcast domains, which also increased the complexity and operational cost of a LAN. This limited the scale of LANs and capped the market size of Ethernet switches.

Enter VLANs. VLANs and VLAN tagging in essence changed the way corporate networks were designed. VLANs allowed priority or quality of service to enter LANs, and with the ability to aggregate VLANs thanks to VLAN-tagging, routers didn´t have to be distributed widely throughout a LAN. Remember the term ?¬¢‚Äö?ᬮ??¨Router On A Stick?¬¢‚Äö?ᬮ¬¨?? or ?¬¢‚Äö?ᬮ??¨One Arm Router?¬¢‚Äö?ᬮ¬¨?? to describe a router with a single LAN interface providing inter-VLAN routing? The entire network design paradigm changed with VLANs. In short, VLANs simplified network design, increased performance and reduced the need for and cost of LAN-based routing.

So what does all of this have to do with secure domains? A lot. There is a huge requirement to segment networks into security domains, which is strikingly similar to the need for broadcast domain segmentation in the 90s. The requirements for secure domains are as vast as the number of companies in the global economy. Some firms require separate departments, some need to
group certain desktops, servers and applications, some want to create extranets with suppliers, partners and customers. Some firms and universities provide services for the federal government, which places strict restrictions (with steep consequences) on access to data, systems and information requiring a secure domain to be wrapped around this work. Then there are the
relatively new legislative and presidential initiatives such as Homeland Security initiatives, the Sarbanes-Oxley Act, the Presidential Decision Directive 63 (PDD 63), and the Health Insurance Portability and Accountability Act (HIPAA), which mandate that corporate boards in essence place secure domains around certain privacy information plus financial work product and
process. If they don´t, these initiatives carry severe non-compliance repercussions for employees, executives, board members and the enterprises at large.

Perhaps the simplest definition of a secure domain is the grouping of IT resources into a protected networked space. This protected space will be as porous or impervious as the corporation requires. Can you build a secure domain today? The answer is yes, but it´s very expensive in both acquisition and operational cost. Just like Ethernet LANs, before VLANs network designers
could install routers between broadcast domains but this design was cost prohibitive. So too are secure domains implemented with today´s technology. Today network designers would have to install firewalls around IT resources to approximate the service as a secure domain. And if you want to know if there is an intrusion into that space the designer can install an intrusion detection
system or IDS. And if you don´t want to be exhausted with reams of alarms and alerts the network designer can install an intrusion protection system or IPS. And if you want to provide zero-day attack prevention or mitigation in that space, the network designer can install a Network- Based Anomaly Detection or NBAD device. Just think of all the cost, and more daunting the
work involved in creating a secure domain with today´s security appliances. Racks of security appliances would be placed around the IT resources being protected and since appliances are physical devices many resources may not even be accessible to an appliance-based secure domain. Then there is the configuration of all these devices and their day-to-day operations; it´s
exhausting just to think about it. Even if the costs of appliances drop to zero dollars, it´s the fear of being responsible for all these appliances that will prevent their adoption at the end of the day.

What the above means is that security appliances will have a place in the design of secure domains but will be relegated to traditional appliance placement such as in data centers and firewalling internet access. To deliver on the promise of secure domains, firewall, IDS, IPS, NBAD, virus and worm scanning security features need to be deeply embedded in the network
fabric and their configuration and management centralized. Embedding security features into the network fabric will reduce acquisition cost while operational cost efficiencies will result from the centralization of configuration and management. But just like VLANs, secure domains will change network design. For example, network designers have raw bandwidth, broadcast
domains, routing and VLANs to mold and shape their networks to meet business requirements. For all of these network resources there are design guidelines and principals. In VLANs, the industry provided guidance on the number of devices per broadcast domain, the number of VLANs per LAN interface, the maximum number of VLANs supported on an Ethernet switch,
quality of service levels per VLAN, how to place VoIP traffic over a VLAN, etc.

Unfortunately, there are no such guideposts for building secure domains. Secure domains are but a concept in corporate networking today. A concept however, that is market driven and which has obtained the attention of network security heavy weights such as Cisco, IBM, Network Associates, Symantec, Trend Micro, Microsoft, Computer Associates and a host of other firms such as HP, Sun, Juniper, Extreme Networks, Foundry Networks, Enterasys, Aruba Networks and many others. Secure domains are a work in progress and as this work progresses I´ll write about it here in the Lippis Report and bring current thinking on the subject to you in our Enterprise IP Communication conferences in Atlanta, New York and Los Angeles.
In the mean time network designers should be asking all of your vendors and service providers to explain their secure domain strategy and Trusted Network roadmap. Also you may want to rethink how you´re using and deploying security appliances in your network by keeping them in their traditional roles, and resist moving them further into LAN architecture.

Now as for Charlie Giancarlo: even though he used VLANs to describe an ATM LAN feature, in the end he did finally get it right and he is now Cisco´s Senior Vice-President and Chief Technology Officer, and President, Cisco-Linksys, LLC. Oh, and by the way the Ethernet switch market has grown by over $9B since Charlie paid me that visit. Secure domains will have the
same effect.

Posted 12 November 2004 at 7:17 am under Lippis Report. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.