Efficient Charity

You should put more padding where it hurts the most to get hit, especially if you're short on padding.

In supporting effective risk management we're used to employing a rational approach, or at least we're used to trying to do so. We've come to understand that while simply applying some portfolio of standards or lathering on some best practices can improve the status quo for many organizations, it's not enough. Understanding your unique risk profile and addressing those risks based on projected impacts will dramatically outperform such a blanket approach, given a fixed set of resources.

How many of us take the same approach when giving to charity?

It's one thing to take something you'd be spending time doing in any case and adding a charitable twist; that's certainly a praiseworthy approach, squeezing more good out of our decided activities instead of squandering the opportunity. However, if our standard is to do the most good, I'm not sure most of us ever consider the true opportunity cost of walking our chosen path.

I found this blog posting recently, and it struck me in a powerful way: 

http://lesswrong.com/lw/3gj/efficient_charity_do_unto_others/

Depending on your disposition you may be inclined to take some of the examples as judgemental, but they're really not. They're aimed at encouraging more honesty with ourselves about where we allocate our time and effort, and why.

Having done so, we can make sure that whatever our goals, we're actually moving toward them instead of veering off in some random direction and thinking we'll end up where we expect. If that means fixing the ills of the world, having some fun, or doing a little of both, great. However, if we honestly consider the paths we didn't chose and find in them a better way to reach the things we call out goals, perhaps we should choose that different path.  Or admit a different goal.

Second Field Report from the Remote Wireless Survey

Field report just received from our latest survey team.

No rogue WAPs detected...

Painting a cloud on the basement wall with XenServer!

Ok, I finally got sick of juggling random PC's around, and I never have my custom VMs around exactly where I need one. So I built this in my basement. Not done yet.

Dual WRT54Gs running Kamikaze, one with a live radio, the other set up to route every port as a separate untagged vlan (custom iptables script to support full rule mesh on each interface, i.e. all cross-com between internal nets vetted)

2 Supermicro pizza boxes (now running as a XenServer pool) acquired on the cheap, single proc 2.4GHz x 4-core, 8Gb. 4x NICs. iSCSI target on the bottom running 3x512Gb drives on a RocktRaid SATA (will add more capacity later). Core switch 24xGigE D-Link also on the cheap (will upg to cisco/extreme later when I find *that* good a deal ($40)).

Remote access VPN and external content pushed through an HA pair of Citrix Netscaler VPX tech preview VMs, one on each XenServer host.

More painting clouds on my basement walls to come later.

-Chris

First field report from the Remote Wireless Survey

No rogue wireless access points detected...

RE: "It’s Only a Model"

In response to "It's Only a Model" at A Techie's Musings

-----

I tend to think of “positive-security” as a design principle, but almost always actually speak of it as a “positive-security model”, since it is usually applied in the context of a functional system.

In other words, security is a sub-feature of a system designed to accomplish some goal. The design of that security feature (it’s model) utilizes the principle of “positive-security”, therefore the security feature is based on a “positive-security model”.

But let’s not get bogged down in semantics :)

I agree wholeheartedly about your comments on the benefits of using a positive security model. It’s not a panacea, but really makes you re-frame your thinking about risk in a productive way.

If you’re trying to minimize your attack surface, trying to block every potential failure is a futile exercise. The search space is just too large. But by employing a positive description of what is expected (think of this as helpful in the same way that a unit-test is helpful), you can, in one fell swoop, excise the entire search space of things that are potentially bad (along with things that are known to be bad) because they simply have no place as imput for that module’s task.

It amounts to an excellent way to avoid wasting resources and converge on desired results.

Of course, you may still need to take a scalpel to your “design-valid” inputs, because the code we actually write often contains logical failures as well, but that’s why unit tests along with positive-security models work so well!

-Chris

A Simple Rationale for Risk Management (slight reverb)

Please read A Simple Rationale: Risk Management (and IT Security) for part One.

.....

So, IT Security is what happens when we successfully manage our risks. Plain and simple.

That doesn't mean that predicting the world itself is plain or simple, just that if we can figure out how to manage our risks effectively, guessing wrong hurts a whole lot less.

Where that can translate into an upside benefit isn't always clear, but here I think our previous skydiving example still serves us well.

Some risks are obvious game-enders; all wearing a parachute does is get you in the game and out the airplane door (At least, I'd hesitate a good long while without one), but it's the inconspicuous backup chute that gets you down to the ground in one piece when things get complicated.

Ever heard of that guy that's always the first one out of the plane? The wreckless maniac? Yeah. You can be sure he packed his own backup chute... and checked it three times. He's done everything within his power to limit his losses, so there's nothing to slow down his decision to jump. He doesn't fail to commit. He's already out the door. Oh, and by the way, only 1 person gets to jump today; the rest of you can go home.

I don't know about you, but it's happened to my business before; you rarely ever get a second chance to regain a lost opportunity. If you've missed the jump zone, it's a long flight home. Better luck next time; next time, hopefully, after you've addressed your risks and can commit to a clear decision.

Sooner or later, we'll all invariably make a bad prediction. The difference is this: with good risk management it will be a mistake we can survive. And that's what long-term business success is really made from, surviving the mistakes that we need to make, in the course of exploring alternatives and ensuring there isn't a better path to achieving our goals.

And if we don't find that best path, our competitors probably will. And that, I'd say, is clearly a risk that needs to be managed.

Cheers,

Chris Healey

A Simple Rationale for Risk Management (and IT Security)

What the heck is this thing we call "IT security"?

I've been in IT and information security for over 12 years, and nobody has ever really convinced me that they have actually achieved a clear and focused viewpoint. Some come very, very close. Most omit something of key relevance.

But what I do know is that a lot of things are done in the name of security, and those things are usually looked at a trade off between convenience and effectiveness. Basically there is this idea that controlling anything is hard, and the harder any particular something is, the less of it we want clogging up the engines of our business. Competition is hard enough without handicapping ourselves at the starting line. And so we look at this thing we don't really understand, called security, as if was something "extra", and the conclusion we reach is: How little spending can I get away with on it and still do business?

Well, maybe asking about security wasn't the best core question after all. I have a better one:

What is doing business, really?

Ultimately, it's making decisions in the pursuit of some goal. Usually that goal is seen as turning a profit, but even if you have another mission, you can't lose money for long before you not doing much anymore. And these decisions we make can really be reduced to only two concerns: their potential benefits and their potential costs.

So fully half of our responsibility in making the right decisions for our businesses is managing the risks that we face! We could certainly pretend that tradeoffs don't exist, and that all income simply flows into our pockets, but that wouldn't make our profit greater than our expenses. To do that we need to focus on both increasing our profits *and* managing our risks/costs.

But, as we've all learned at one point or another, the world isn't that predictable or cooperative. We might have some idea of what costs we'll face, but we often don't really know until our 20/20 hindsight kicks in. This is exactly where the benefits of risk management start to shine. Managing our risks is, at its root, doing business in a way that limits our potential losses. But at it's very, very best, risk management can enhance our ability to push past our previous performance limits, allowing us confidently grasp those golden opportunities that would have been beyond our reach before.

Most IT operational risks we defend against are biased toward loss. This means that if everything goes according to plan, we're right where we expected to be, but if things go badly, we stand to lose a great deal. Not the best iterated investment strategy. However, by limiting our downside risks through diligence and care, we can reclaim a portion of our risk tolerance that we previously squandered. We can bank some risk for another day. And believe me, having a pocketful of risk to spend can be very handy indeed, especially if we're careful to allocate that risk on endeavors that actually have some upside potential.

Business is risky in the same way that skydiving is risky; it's never quite a sure thing, but it's not that bad after you figure out what a parachute is (and why knowing where your ripcord is located can be useful).

So, what the heck is this thing we call "IT security"?

IT Security is what happens when we successfully manage our risks. Plain and simple.

Cheers,

Chris Healey