Skip to main content


Showing posts from July, 2008

Are we Outrunning the Bear?

Or wasting our time trying?

Amrit's latest post has me thinking about what's been one of our brew pub round table topics lately.

There is an old joke about the hikers who cross paths with a grizzly bear. The first hiker immediately takes off his hiking boots and puts on his running shoes.

The second hiker: “why are you doing that - you can’t out run the bear”.

First hiker: “I don’t need to out run the bear, I only need to outrun you”.

In a sense, if hacking today is focused on profit rather than challenge or ego, as perhaps it once was, then the miscreants will likely follow the least cost or least resistance path to their goal (marketable data, marketable botnets). If that is true, our goal needs to be to outrun the other hikers, not the bear.

Fortunately there appears to be a limitless supply of slow hikers (clueless developers, sysadmins, security people and their leadership, or more likely - competent developers, sysadmins and security people led astray by clueless leaders…

Presumed Hostile - Your Application is Out to Get You

OR:Your applications are hostile, are you protecting yourself from them?Or maybe:The assumption that your applications are insecure and that you need to protect yourself from them should be a factor in building your security model.The Intent:The intent of this post is not to break new ground, but rather to describe a concept in a simple framework that can be committed to memory and become part of the 'assumed knowledge' of an organization. The Rules:#1 - In general, the closer a system or component is to the outside world or the more exposed the system is to the outside world (the user, the Internet or the parking lot) the less trusted it is assumed to be.#2 - The closer a system or component is to the data (database), the higher the level of trust that must be assumed. #3 - Any traffic or data that flows from low trust to high trust is presumed hostile. Any data flowing in that direction is assumed tainted. Any systems that are of higher trust assume that the lower trust syst…

Estimating the Availability of Simple Systems - Introduction

I've spent a bit of time thinking about how to estimate the expected availability of simple systems. I'm interested not in detailed calculations of complex systems, but rather in rule of thumb type of estimates for simple systems. I suspect that this problem can be as hard or as easy as one would like to make it. I'm going to try to make it easy. Wish me luck. This post introduces the estimations. Part One covers non-redundant systems. Part Two covers simple redundant systemsAssumptions:I'll start out with the following assumptions:(1) That you have a basic understanding of  MTBF and MTTR.(2) That your SLA allows for maintenance windows. Maintenance windows, if you are fortunate enough to still have them, allow 'free' outages, provided that the outage can be moved to the maintenance window.(3) That you have the principles laid out in my availability post implemented, including: Tier 1 hardware with platform management software installed, configured and tested.…

Estimating the Availability of Simple Systems - Non-redundant

In the Introductory post to this series, I outlined the basics for estimating the availability of simple systems. This post picks up where the first post left off and attempts to look at availability estimates for non-redundant systems. Let's go back to the failure estimate chart from the introductory postComponentFailures per YearHours to RecoverHours Failed per yearWAN Link.584Routers, Devices.24.8SAN Fabric.24.8SAN LUN.112.12Server.584Power/Cooling122And apply it to a simple stack of three non-redundant devices in series. Assuming that the devices are all 'boot from flash and no hard drive' we would apply the estimated failures per year and hours to recover in series for each device from the Routers/Devices row of the table. For series dependencies, where the availability of the stack depends on each of the devices in the stack, simply adding the estimated failures and recovery times together gives us an estimate for the entire stack.For each device:.2 failures/year * …

Estimating the Availability of Simple Systems - Redundant

This is a continuation of a series of posts that attempt to provide the basics of estimating the availability of various simple systems. The Introduction covered the fundamentals, Part One covered estimating the availability of non-redundant systems. This post will attempt to cover simple redundant systems. Let's go back to the failure estimate chart from the introductory post, but this time modify it for redundant (active/passive) redundancy. Remember that for redundant components, the number of failures is the same (the MTBF doesn't change), but the time to recover (MTTR) is shortened dramatically. The MTTR is no longer the time it takes to determine the cause of the failure and replace the failed part, but rather the MTTR is the time that it takes to fail over to the redundant component. ComponentFailures per YearHours to Recover (component)Hours to failover
Hours Failed per yearWAN Link.58.05.025Routers, Devices.24.05.01SAN Fabric.24.01.002SAN LUN.112.…

Estimating the Availability of Simple Systems

As system managers, we are tasked with building and maintaining systems that are expected to be ‘always on’. Our objective of course, is to bridge the gap between our users definition of ‘always on’ and our accountants definition of ‘under budget’. In my experience, the gap tends to be large.With that goal in mind, I’ve outlined a method for quickly estimating expected availability for simple systems, or ‘application stacks’. For purposes of these posts, a system includes power, cooling, WAN, network, servers and storage.The introductory post outlines the the basics for estimating the availability of simple systems, the assumptions used when estimating availability, and the basics of serial, parallel and coupled dependencies. Part one covers estimating the availability of simple non-redundant systems.Part two covers estimating the availability of systems with simple active/passive redundancy.My hope is that there prove useful as rules of thumb for bridging the gap between user expecta…

The Pew Broadband Report and the Digital Divide

The digital divide appears to be more complicated than we thought. From the 2008 Pew Home Broadband Report it looks like only a fraction of non-Internet users are actually held back by the availability of broadband. A whole bunch of non-users are simply not interested, and another large group  doesn't have the money.  The plethora of task forces that meet to talk endlessly about the digital divide need to think about cost and interest, not just availability.

Among people who do not use the Internet (27% of adult Americans)
43% of non-internet users are over the age of 65 or, put differently, 65% of senior citizens do not use the internet.43% of non-internet users have household incomes under $30,000 per year. When asked why they don’t use the internet:
33% of non-users say they are not interested.12% say they don’t have access. 9% say it is too difficult or frustrating. 7% say it is too expensive. 7% say it is a waste of time. So we have an age problem, which will eventually will r…


It's the end of a long day, I'm a thousand miles from home, on a rural Montana road driving not too far over the speed limit. There is nothing around - except - what's that?The neural net kicks in. Somewhere in the vast emptiness between my ears, the pattern matching algorithm registers a hit, the bell dings, the right leg stomps the middle pedal, the left leg stomps the left pedal, the ABS brakes kick in, the flashers go on and the Subaru stops. In the ditch is a person kneeling, a lump of something potentially sentient, and a badly bent motorcycle, wheels up.Yep - I'm first on the scene of a motorcycle accident. They aren't hard to recognize, especially if you've seen a whole bunch of them during your motorcycle road racing phase.Now what the heck do I do? I'm not trained in anything like first aid. The only rule I could remember from high school first aid is 'Remain Calm'. Ok - I'm calm, now what? What's rule number two?  Damn - can't…