A Shack in the Woods, Crumbling at the Core


Imagine a run down shack. The kind I’m thinking of is like the cabin my grandfather bought in the late 60’s. It was about 16’x20’, built in the 30’s and then left to rot. It had wooden blocks for its foundation, it sagged about a foot in one corner as the wood blocks shifted and rotted, it was musty, moldy and damp. It was the very definition of deferred maintenance. A menagerie of non-human mobile life forms called it home. It was a shack, kind of like the one pictured here.



There are applications like that, lots of them. We probably all know where they are. Most of us will only have to look someplace in our data centers. Think of an old shack when you think of those applications.

What do you do with a shack like that? You could paint it, put new doors and windows in it, add on a bedroom and a porch, maybe even add plumbing and a bathroom. You could even secure it (from the rain) by fixing the roof. But what about the foundation? Sure you can remodel and add on to a house with a rotten foundation, but to do so is to negate much of the value of the other improvements. Your bathroom will have a sagged floor, your doors and windows won’t fit right, and your shiny new front porch will detach from the shack as the shack rots itself into the ground. You’ll have a maintenance headache that doesn’t really do what it should.

The obvious first step is to jack up the shack and build a concrete foundation. If you bite the bullet and fix the foundation first, the rest of the improvements can be built on something solid and long lasting. If the foundation is solid and square your improvements will be cheaper and easier to build. Skip that part and everything else you do will be difficult and expensive to build and poorly done at the end anyway. It’ll be a square addition added on to a crooked cabin.

Back to your rotting application - the one with the unsupported operating system and database, broken data model, the dead, archaic, insecure code that nobody understands. Are you re-skinning it to look nice? Are you grafting on features and business logic onto the sagging foundation? Or are you digging out a new footing and pouring concrete?

The business unit doesn’t know or care about the foundation, they only care about the user interface and the features. Our job is to convince them that they need to spend time and money on the foundation, not just the features.

Tell them the story about the shack in the woods.

Minimal Installations & the Consultants who Have no Clue

I've got a simple mantra that I sometimes express as the 'Least Bit Principle'. It's not complicated. In any system, install and configure the least number of services, packages, configurable entities, permissions or privileges necessary for system functionality. This goes way back to the days when one needed to disable defaults services while hardening a new server (chargen anyone?) and it applies to any complex system, such as operating systems, databases, routers, firewalls, etc. It's not new, it's not radical.

The fundamentals of this principle are self evident.
  • What is the minimum software needed to support the application functionality? (Hint: It's not 'Entire Distribution')
  • What are the minimum file system privileges necessary for application functionality? (Hint: It's not 'Everyone/Full Control')
  • What are the minimum database privileges necessary for application functionality? (Hint: It's not 'DBA' or 'DBO')
  • What are the minimum services that need to be running to support the application functionality? (Hint: You don't need chargen, rsh, rcmd or IPX)
For software installation, general expression of this principle is that if a package or feature is not installed, it does not have to be maintained, patched or upgraded, and more importantly, if the package or feature is not installed it cannot be accidentally enabled in an unconfigured or partially configured insecure state. When code red and slammer hit, how many of the victims  knew they were running SQL server or IIS? Many of them didn't know that the vulnerable software was even installed and running, much less that they had to patch it or they'd be screwed.

This is extremely valuable for Solaris and Oracle. For both of those, we are able to minimize the installations and defer a significant number of patch cycles simply because the vulnerable feature or package is not installed.  If the vulnerable software is not installed, we do not have to consider the vulnerability. It's even on Microsoft's radar. With server 2008, it is finally possible to install a minimized version of the operating system. I dream of the day when my IIS server will not have a GUI browser, and I'll be able to ignore vulnerabilities and patches that infect the pathetically insecure userland software that infests my servers.

So a vendor (Sun) offers to help out with a proof of concept. They delegate the actual install to a VAR. The consultant paid by the VAR (or Sun) shows up and starts to build an 'Entire Installation' server. We insist that 'Entire Installation', which includes software that we will never, ever use on that server, is not appropriate and does not meet our standards. We declare to the consultant that what we need is 'Reduced Networking Core System Support'. The vendor (Sun) provides and supports minimized installation options for the software (Solaris) and we expect the consultant to perform a minimal installation plus the specific packages necessary for supporting the intended application. What's so hard about figuring out a dependency tree and installing the minimum software necessary to resolve the dependencies? The consultant balked.

In this case, fatigued from having to deal with clueless consultants, we said screw it. We'll end up running the proof of concept with an 'Entire Installation', throwing it away and doing the minimal installation later when & if it moves to production. It shouldn't have to be that way though. It's 2009 and I expect consultants to think and act like it's the 21st century.

Why are all my 'vendor' posts also tagged as 'annoying'?

SMS as Two Factor Authentication Spoofable?

Speculation as to why there is an apparent rush to buy a certain model of an old Nokia cell phone.
'The 1100 can apparently be reprogrammed to use someone else's phone number, which would also let the device receive text messages. That capability opens up an opportunity for online banking fraud."
If true, then an SMS to a cell phone would no longer be reliable for two factor authentication. Impersonate a person's phone long enough to log into their bank account? That'd be amusing.