Networking

Time to reconsider security zones in system and network design

As IT professionals balance many responsibilities, we may omit certain fundamentals that are made easier in the current technology landscape through multiple layers of abstraction, virtualization, and management. IT Jedi Rick Vanover suggests that it's a good time to rethink security zones.

The current inventory of networks and servers has many layers of abstraction, virtualization, and management in today’s data center. Recently in a discussion with independent security expert Edward Haletky, I discovered it is definitely time to revisit how security zones are provisioned in new and existing network infrastructure.

Edward pointed out that many administrators, myself included, are crossing security zones without even knowing it with the various layers of management and abstraction that are in use today. The security zones that I am referring to are the classes of service for various levels of a network infrastructure.

Take for example a typical server in today’s data center and also assume it is a virtual machine host. This particular server may have the following network attributes: a hardware management interface such as an HP Integrated Lights-Out management processor, the operating system management interface, the virtualization layer migration interface, a storage interface for a system such as iSCSI, and a number of virtual machines all on separate VLANs. In this example, the single piece of equipment interacts with no fewer than five security zones before the actual systems come into play.

This discussion brought me to consider that with technologies such as VLANs and options made available through virtualization, it is prime time to rethink where everything resides. Security issues aside -- it simply makes sense to separate these network presence points where they are classified as security zones. Performance reasons will also benefit, as I mentioned in a prior post about iSCSI network separation.

How do you approach different security zones on networks? Are VLANs enough -- or are fully separate switching environments adequate for your requirements? This area is very compliance- and requirement-driven, so there is no clear answer. Share your comments below on this area where we all can likely improve.

About

Rick Vanover is a software strategy specialist for Veeam Software, based in Columbus, Ohio. Rick has years of IT experience and focuses on virtualization, Windows-based server administration, and system hardware.

26 comments
mark.jones.melbourne
mark.jones.melbourne

Hey Everyone... Call me a broad generalist with about 19 years experience... that said... Network security or separation and the use of zones or classification systems is all about perspective. We are currently undertaking an IP renumbering of a campus network from a public range to private, so the talk of zones is something that I am working on right this second. Depending on your role as an administrator you will have your own opinion and perspective, and the more people that you involve... the longer the whole process takes... I agree that the KISS approach is a great simple structure... although it does not have much depth, it has plenty of width. I plan to use 4 or 5 classification zones (Public\Untrusted, Trusted, Restricted, Highly Restricted, Sensitive(DB layer) ). Each of these are separated using a control point (firewall for simplicity). That is the depth... we also have a range of networks that sit within each of these zones, creating the width... We will mandate ?by proxy? access which we use Bluecoat, F5, Alteon etc... meaning that all traffic must not cross an entire zone, therefore is proxied (forward, reverse). We have 3 logical firewalls (perimeter, external, internal) we use a range of virtual firewalls to separate Management, Backup, IT, Systems Assurance, Data Bases and more... (our users terminate on our external firewall) We also use virtual routers, VPLS, MPLS type approach... so therefore limit the scope of each network. If you are a small\medium network, stick with 3 tier... invest in reverse proxy, web server director or similar for your public facing stuff (multihomed) everything else private. I can draw it... writing it is not that easy... I am a visual person, not a list person :) I would love to participate in a shared (generic) design that we could make publically available...

jfreeze
jfreeze

Hi Rick - Great points you bring up. We deal with this issue a lot at Crossbeam (we provide a network security platform that virtualizes third party security applications within large data center environments). Based on our experience, we recommend that the network security infrastructure remain physically separate. This separation allows you to maintain strong "trust boundaries" and high performance/low latency, without the loss of flexibility and adaptability of virtualized application infrastructures. This deployment architecture relies on the emergence of a new generation of high performance security equipment which is able to consolidate and deliver multiple security services from a common platform that enables service selection decisions. For more, Throop Wilder elaborates on this topic in Network World http://tinyurl.com/mfnp3u Jim Freeze CMO, Crossbeam Systems jfreeze@crossbeam.com

richard.beebe
richard.beebe

This topic is very timely for us, though I wish you'd had more concrete suggestions on how to re-think security zones. We had 15 different security zones, 5 data centers and over 1000 servers. Our single biggest problem now is power and cooling. To help mitigate those, we've launched a major virtualization initiative. But, just as you've pointed out, that has led to even more zones and discussions about connections. We now have several storage nets, the console managment nets, LIO access, VMWare heartbeat, to say nothing of single physical VM servers with guests in different zones. Add in a few F5 load balancers, which also have to cross zones, and it's a real security and network design nightmare. The real high security servers are remaining in their own zones and on separate physical boxes, but it's the hundreds of other servers that are getting all tangled up. I'd love to hear some stories from others who have gone through this and made it work.

Deadly Ernest
Deadly Ernest

It's been near a decade since I worked in a high security area, but one of the basics of security then was you did NOT mix security zones or merge security layers. Even if it meant spending more money on more equipment. I can only think this is happening because people got lazy or too focused on saving money by making the biggest use possible of each server. One thing I was taught decades ago about security, physical security it was then, was 'Every cost cutting measure in a security system will cost you ten or more times what you save eventually, as the system is then much easier to breach.' And it will be breached, eventually as you can't make up what you lost without spending a lot more and once the cost saving mode turns on, it's impossible to turn off. Another problem is when the admins place all the servers together as that's more convenient for them. This is not a problem per se, but the usual effect is they then seek to simplify the remote monitoring and administration, and all the servers then end up connected on the same network, thus lowering the security again. this isn't so bad if it's a different network to the rest and works via extra NICs in the servers and their own dedicated router with the only other systems on it being the admin systems and they are not connected to any other network. Great in theory, but never happens in practice. I'm glad you raised the idea it should be reviewed, I'm frightened it got that bad in the first place.

standalone.sysadmin
standalone.sysadmin

Much like the dishwasher and vinyl furniture before it, virtualization is the latest in a long line of technological innovations that promise to release us from the doldrums of mundane maintenance and free up our lives for more exciting pursuits, all of which ultimately fail miserably. I don't think that anyone can argue that vinyl furniture was an advance in technology, but despite early promises to the contrary, upkeep is never as simple as just hosing it off every once in a while. Technically, it /could/ be done, but how many people have a drain and sewer line installed in their living room?

darrell.hixon
darrell.hixon

Trust a Crossbeam sales guy to jump in! Our company put our trust in Crossbeam 'C' series and now six months down the line we find out that the appliances now don't support Checkpoints new R70 software release! All Crossbeam want us to do now is buy the 'X' series - pretty poor. To enhance L2 security in a small (no budget) office deploy networking hardware from a well know vendor i.e. Cisco and follow their 'go/safe' recommendations on L2 security using tried and trusted security methods.

robert.wieters
robert.wieters

I'm not a security architect, but rather a network architect who works with the infosec team to marry the network to security best practices. So, that said, we are modularizing our data center using four simple security zones (Keep It Simple Stupid): The black, green, yellow, and red zones. Black is where all vlans converge from the top of rack trunked servers (VM, blade, commodity). From the black zone, the green designated (trusted) vlans (a specific range) are sent to the green zone aggregation...and so on for yellow (interal DMZ) and red (public facing DMZ) vlan ranges. Layer two ACLs prevent vlans from traversing the wrong trunk. All traffic inbound to a zone is proxied by an f5 via specific virtual servers/ports. Any time a packet crosses zones, it does so via a firewall/IPS. The zones are merely redundant aggregation switches that are multichassis trunked to each other and their zone partners. Also, they serve the gateways for all these vlans. I guess my point is, whether its a mgt network, a branch LAN, or whatever the case, it should still be considered a trusted, semi-trusted, or non trusted virtual LAN. Let the inherent L2/L3 access controls on your routers/switches work in conjunction with the perimeter firewalls/IPS to secure the zones from each other. The way your applications are arranged on your virtual servers will depend on your internal security policy. Ours allows for yellow/red vlans to coexist on the same physical server, and green vlans exclusively on others...regardless of the type of application in that zone. Thoughts?

b4real
b4real

My recommendation would be to do the following steps: -identify all network presence -categorize them: -Operating system -Device managemen -Network management -Hardware tools -Determine what the security zone requirements are for each of those types -Architect accordingly This is just a start, but we need to determine what we have now and re-architect the network(s) accordingly, Good choice on the F5, by the way.

Spamosborn
Spamosborn

Sounds to me like this conundrum in the virtual world is no different to that of the physical, namely one of finance. If an organisation is prepared to cough up for good security, it's then just down to good design to ensure your security posture is maintained - e.g. in larger organisations we've used separate physical hosts per security zone - zone X host carries zone X VMs, zone Y host carries zone Y VMs and so on... In a smaller organisation you're going to run into finance issues which may prevent arguments against taking this sort of approach, and likewise in a security negligent organisation the same problem will likely prevent such a business case being accepted. To me this is all about how you present a business case for virtualisation and how you manage the environment to prevent compromise of security posture in the future, not about whether we should be debating the collapsing zones. There's always a case for careful planning of your security controls, and if virtualisation is being proposed as an argument for relaxing controls, all that's happening is the finance department are trying it on again - stand firm people! :-)

fatman65535
fatman65535

Quote: "One thing I was taught decades ago about security, physical security it was then, was 'Every cost cutting measure in a security system will cost you ten or more times what you save eventually, as the system is then much easier to breach.'" I bet the genius at TJX who felt that their wireless systems did not need better security learned a very painful (and expensive) lesson in what happens when a breach occurs. My two cents - if that person was still on the payroll when that breach occurred; his (or her) @$$ would have been kicked out the door so fast, it would make your head spin.

eyerouteip
eyerouteip

When dealing with these and other security issues that I consider to be high on the priority list, the question from management is always the same.."Do we have a problem now?" or "Prove to me that we need it." Getting management buy-in is never easy and usually comes after something negative happens. The reson that I bring this up is isolating servers into security zones, would cost more dollars - either to physically separate at Layer 2 or even at the VM host level. I cringe everytime I imagine VM's strattling a firewall because both internal and external hosts are attached to the same physical machine. Some help or guidance on how to get management buy-in on best practices without having to jump through hoops would be very helpful. The same could be said for educating server administrators as well, this group of folks is usually the driving factor for centralized management and adminstration.

darpoke
darpoke

- I *love* my dishwasher. Saves me literally hours of boring chores every single week. What embodies progress better than that?

b4real
b4real

How many of us are overworked and under-resourced? This is the type of stuff that can slip through the cracks.

jdavis
jdavis

I don't understand the black zone. "Black is where all vlans converge"?

b4real
b4real

Robert: That is a great way to classify for many types of networks.

Deadly Ernest
Deadly Ernest

Sometimes the people with the knowledge are NOT in a position to tell the decision makers the full information needed to make the proper decisions - so the go down the wrong path and refuse to listen when those with knowledge speak. When that happens it's time to leave while you can still get full pay. One place I worked we were taken over and the new management weren't as concerned about security or operational performance as the old management - but about cutting costs to justify lower bottom lines, higher profit, and higher executive bonuses. At one point an incident occurred where I refused to carry out the order of my division head as it was, in my view, unlawful. He told me to do it or I'd be sacked. I tendered my resignation that day. Within three months 96% of the staff who were at the company at the time of take over eleven months earlier had resigned for similar reasons. Prior turnover of staff had been 1% per annum. Another twelve months and the company was sold again at less than half the value at the time it was bought.

b4real
b4real

Security zones there are another entity all together.

Deadly Ernest
Deadly Ernest

support by referring to the appropriate legislation or contract, if you can. One place I worked at they didn't want to spend money to add some more hardware into the gateway since it worked fine. No one could get top management to ante up the money until I pointed out the brand new contract they just signed with a major government department required the changes or they loose the $25,000 per month contract - hardware ordered the next day. In another situation I told the big boss that we didn't need to have the equipment and software if we didn't mind taking the risk of having a security breach, estimated as 0% to 8% risk, however a breach would result in him facing charges that could result in a half million fine for the company, fifty thousand fine for the board, and up to five years in prison for the CEO for failure to meet the security requirement s of the legislation. Approval granted that meeting. Sometimes you have to justify bot on the basis of the return of investment, but on the basis of 'can we afford to let it go wrong,' and 'can we afford the loss if it does.'

b4real
b4real

Leslie: You bring a valid point. There is cost to the configuration as such - but is it worth the return? Some organizations with regulatory issues may have these questions answered already. But for others, it doesn't always make sense. My goal is simply to open up everyone's eyes and maybe start the re-thinking process - if required.

b4real
b4real

This can even be VLAN assignments - again, what are the requirements mashed with the best practices for your situation.

robert.wieters
robert.wieters

Cisco, our VAR, and my extended corporate technology team seems to believe the model fits our organization while giving us latitude to correct a number of long-standing infrastructure and process issues. We are building the design at CPOC Lab in San Jose in September. It has turned into about a $2.6M re architecture project for a data center that is today bulging at the seams.

Deadly Ernest
Deadly Ernest

letting management know what sort of security risks are possible through IT as management can't be expected to know that. They also have a role to let them know what legislative requirements apply to IT and how they can be applied technically. Essentially, let management know a security concern exists. You're perfectly right when management makes a FULLY INFORMED decision and says 'no worries' or 'do it.' But too often management don't know they need to make a decision or lack the information to make an informed or intelligent decision. When that happens you have to fill the gaps for them so they can revisit the decision.

b4real
b4real

There is (usually) no clear answer that we can provide for every situation. As the blogger, that is a challenge I have. But, I appreciate community feedback to help me shape traffic forward to everyone's needs.

Ishron
Ishron

This discussion with management concerning the security of corporate assets is not a bottom up discussion but a top down as you say. The only caveat to security is whether the cost exceeds the value to the company. Management is the one to decide the cost to the company should something happen to the asset that the company is trying to protect. Management has to determine what is important to protect and instruct IT in the value to the business. It is then IT?s job to determine how to best protect that asset and what is the cost of that protection. Management then makes the decision whether the cost is justified. This list of secured assets should be reviewed at least annually to ensure that the company is making the right security investments. Value to assets in an organization are constantly changing and this list needs to be updated and out of date or depreciated assets should be removed. IT managers are not equipped for nor should they be making decisions around what assets are important to the company. If they are, then they are performing the wrong job function for that level. IT managers should be managing the effort to secure assets that the company tells them are important. While certain assets are obvious, there are other assets where they might not fully comprehend the value to the company. The owners of these assets within the company are the ones to define the value to the company and the value in terms of something bad happening to that asset in terms of the company being able to do business should they lose that asset. The first sign of an IT manager having trouble defining the value of IT to his management is an organization where there are unrealistic expectations placed on IT to secure the corporate assets. If these assets are not defined by the business then IT cannot be aligned to that business need. Therefore a business decision around the securing of these assets will be made at purely the IT management level to which the wrong set of priorities will be applied. This is really easy to manage today. In today?s business world, there are legal consequences for poorly managed stockholder assets. It should be fairly easy to remind management that it is their responsibility to define the company assets and what is the value of these assets to the company.

Editor's Picks