By Andrew Conry-Murray The Green Grid is a new standards body promoting energy efficiency in the IT industry. Its goals are to reduce energy costs and help enterprises better manage energy usage by developing industry-wide metrics for measuring power usage and efficiency, create technology standards, and promote best practices for data center power management. This week the Green Grid introduced its board of directors: AMD, APC, Dell, HP, IBM, Intel, Microsoft, Rackable Systems, SprayCool, Sun Microsystems, and VMware. "When it comes to IT, we are seeing customers are paying as much if not more for energy and power on a yearly basis as they are for purchasing computer equipment," says Tom Bradicich, IBM Fellow and VP of Systems Technology for the Rack, Blade and x86 servers, and a director on the board of Green Grid. The first goal of the organization is to define standard metrics around energy usage and efficiency for IT hardware, particularly servers. Hardware vendors can then design products and compete in the market against those metrics. The body also plans to create best practices for energy-efficient data centers. In addition to IT hardware, long-term plans include power-related metrics for software applications; silicon; and power, cooling and management technologies in data centers. Why bother with a new standards body? The Green Grid believes it can drive new standards more swiftly than existing organizations. "When one wants to accelerate a standard or initiative, it helps being able to travel in your own organization rather than an existing body with its own bylaws and initiatives," says Bradicich. "But we will work closely with other standards bodies. In some cases, specifications will be submitted to other standards groups." IT vendors, enterprises and individuals are invited to join the Green Grid. The organization also released three new white papers, available here.
Saturday, February 7, 2009
Vendors to Set Standards for IT Energy Efficiency
Posted by Roy Zafar at 3:49 PM 0 comments
Labels: Network and System Management, Network Infrastructure
Monday, February 2, 2009
Data Center vs. Network
By Andy Dornan If Cisco Systems gets its way, data centers eventually will be replaced by virtual machines running somewhere on a switch or a router. It's spent the last 2 ½ years talking about the virtual data center, and in July this year made its boldest claim yet: that in the long term, virtualization will mean the end of physical servers. In the short term, Cisco is trying to make the case for offloading specific server functionality to network devices. Its progress has been slow so far, but a partnership with SAP promises to move some SOA functions on to Cisco blades by the end of this year. The theory is that because SOA breaks applications into smaller components, they can more easily be spread across different devices. 3Com has gone even further, running VMware on its routers. That theoretically lets it replace any Windows or Linux server. This kind of offload obviously makes sense for networking vendors, but what does it mean for customers who buy into it? Right now, little change as far data center design and network architecture are concerned: So far, it's only high-end core switches and routers that can handle applications, so Cisco and 3Com are just competing with IBM and HP for data center real estate. It won't stay that way forever. The main sales pitch for moving things inside the network is flexibility, which necessarily means some functionality now found within the data center will move elsewhere. So if you buy into the networking vendors' vision, start planning for a smaller data center. If they get their way, it will gradually shrink it in favor of branch-office boxes (think souped-up Riverbed and Silver Peak) or software as a service.
Posted by Roy Zafar at 7:47 AM 0 comments
Labels: Data Center, Network Infrastructure
Saturday, January 31, 2009
Leveraging Your Infrastructure
By Mike Fratto NAC deployments often require more integration than seen at first blush. Especially when the NAC products don't meet with expectations. Take user login/log-offs that were a problem I mentioned in my review of ConSentry's product. There are ways to mitigate problems or bolster your NAC deployments using features you already have. The issue is that the LANShield Controller, their in-line NAC appliance, didn't detect log-offs properly and that means its simple for one user to impersonate another because the attacker is already local to the network and can easily pull a cable from a wall or PC to jack-in. ConSentry did say it is addressing this issue in a future release, but what can you do in the meantime? First off, if you're using Windows in an Active Directory environment, and who isn't, the first thing you can do is disable login caching in AD’s Group Policy Object. By default, the workstation will cache the last 10 logins. The benefit is if a workstation can't access the Directory, the user can still login to the workstation and be productive. Or an attacker could just pull the network cable, login using AD account that had been cached, re-connect the cable, and get access to the network as the previous user. If you disable login caching by setting cached logins to zero and don't allow logins using local accounts, then if the Directory isn't available, the user can't login over the network. The downside is if the user can't login, they can't work, so you need to ensure you have a fault tolerant AD deployment or just bite the bullet. At any rate, doing so at least stops one avenue of attack. Setting cached logins to zero on laptops won't work, however. Windows simply doesn't handle multiple user accounts gracefully (or at least I haven't found a way that it does), so if your laptops are set to zero login caches, users won't be mobile. Besides, another way to by-pass ConSentry's solution is to simply yank the cable from the workstation and replace the MAC and IP address in another workstation. We may be able to look to the network for a potential solution using features in switches that generally called IP locking which maps an IP address and MAC to a switch port and defeat moving addresses arbitrarily. Now, I haven't tested this yet, but I plan to ferret the efficacy of this proposed solution and the gotchas. DHCP is an easy one to handle. Switches from Cisco, Extreme, and HP, to name a few, support DHCP assignment enforcement. The switches snoop on the DHCP handshake and map the offered IP address to a MAC address and a port. If the IP address shows up on another switch port, all traffic should be rejected from it. Also, when the switch port becomes inactive from a host being pulled from it, the IP address mapping is removed. Those two functions promise to thwart physical impersonation. In some cursory testing, I found that at least Windows hosts, when they lose the physical connection, will re-run DHCP when it is reconnected. I haven't explored all the various situations or other OS's. If you have experience with these features, I would love to hear about them. E-mail or post a response. That's great for DHCP, but what about hosts with static IP addresses? Yeah, this is where IP address management gets a bit more difficult. You could statically map IP addresses to ports, but if you're in an organization of any size, static mapping becomes an awful lot of work. I don't have an answer there (do you?) except to suggest moving your workstations to DHCP or just deploy 802.1X. Generally speaking, with DJCP, hosts will continue to receive the same IP address over and over and you can statically map IP addresses to MAC addresses. That will reduce some of the management overhead once you get the static mapping rolled out. NAC enforcement and network infrastructure will eventually merge, not necessarily to the exclusion of other NAC technologies, but network enforcement at the switch makes sense whether that means 802.1X, or purpose-built secure switches from the likes of ConSentry or Nevis Networks. When it does, maybe these quirks will just fall by the wayside. In the meantime, check out what your switches can do.
Posted by Roy Zafar at 8:41 AM 0 comments
Labels: Network Infrastructure