Building the IT Stack We Really Want
In an eWEEK column last autumn, I proposed "a new default: to configure system privileges from the bottom up, instead of starting with wide-open systems and frantically battening down their hatches before something bad gets in." I heard that thought coming back to me in a conversation this past week with Rix Kramlich, the VP of marketing at Solidcore Systems Inc., when he opined that "software today is never deployed: Its always in development mode."
In most environments, Kramlich observed, theres no real difference between code on a developers workstation and code on a production server: Theyre both just strings of bits that the system will execute as instructions if anyone with the right privileges says to do so.
When you think about, thats not at all how things should work. Once a module gets rolled out as part of a running enterprise IT stack, "soft" is the last thing you want it to be. Crystallized in place, presenting carefully cut facets of function at precisely chosen angles, is more like what we have in mind. If we found it economical to wire enterprise applications in hardware, we probably would, rather than tolerating our continued exposure to buffer overflows and other attacks that take advantage of softness.
Its downright ugly to leave software at the mercy of anything that might come along to change it: like asking people to work in a building made of still-oozing mud, propped up by the scaffolding of firewalls and other add-on security systems. Yuck. No wonder things are a mess.
Solidcore is hoping to change the rules with a new offering announced today, called S3 Security, that inventories and identifies the specific code on a system thats allowed to run -- and simply does not allow anything else to execute. A system controller appliance acts as overseer: It determines whether a system is in an update mode, when new code or modifications are allowed to come aboard, or in a change-blocked mode where nothing is allowed to alter "solidified" code.
Crucially, not even a command thats given with administrator privileges can take action that would launch unknown code or alter code thats been authorized to run. Many modes of attack are thereby neutralized: Bob Lescaleet, MIS manager at Pace Suburban Bus Service in Arlington Heights, Ill., told me last week that Solidcores technology lets him do system patching on his own schedule, rather than in a continual crisis mode.
Also improving system manageability are new virtualization offerings, announced this morning, from aptly named Virtual Iron Software Inc., which seeks to enable system operators to virtualize in either direction -- either consolidating or dividing physical systems. Im used to seeing an IBM mainframe, for example, carved up into multiple virtual Linux servers, but Virtual Iron also goes in the other direction. "We completely separate physical from virtual: We can make a virtual system span several physical machines," said Virtual Iron CTO Scott Davis when we spoke last week.
Crucially, Davis added, "Were transparent to the application: Any Novell or SuSE Linux application runs out of the box," he said, and can take advantage of all the resources of a multisystem constellation if the application is multithreaded and scales on an SMP or NUMA machine.
The latest Virtual Iron update incorporates the Xen open-source virtual machine monitor developed at the University of Cambridge, part of a strong continuing trend in the direction of open-source technology entering enterprise applications.
But in the meantime, I welcome the kind of thinking thats represented by these Solidcore and Virtual Iron products. Both of them address the growing need to define an IT system by what its supposed to do, instead of getting bogged down in hardware complexity -- or trying to build a fence along the fractal boundary of what we want to prevent.
Tell me where youd like to draw the line on system misbehavior at email@example.com.
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.