Rational Survivability

Endpoint Security vs. DLP? That's Part Of the Problem...

Larry Walsh wrote something (Defining the Difference Between Endpoint Security and Data Loss Prevention) that sparked an interesting debate based upon a vendor presentation given to him on "endpoint security" by SanDisk.

SanDisk is bringing to market a set of high-capacity USB flash drives that feature built-in filesystem encryption as well as strong authentication and access control.  If the device gets lost with the data on it, it's "safe and secure" because it's encrypted.  They are positioning this as an "endpoint security" solution.

I'm not going to debate the merits/downsides of that approach because I haven't seen their pitch, but suffice it to say, I think it's missing a "couple" of pieces to solve anything other than a very specific set of business problems.

Larry's dilemma stems from the fact that he maintains that this capability and functionality is really about data loss protection and doesn't have much to do with "endpoint security" at all:

We debated that in my office for a few minutes. From my perspective, this solution seems more like a data loss prevention solution than endpoint security. Admittedly, there are many flavors of endpoint security. When I think of endpoint security, I think of network access control (NAC), configuration management, vulnerability management and security policy enforcement. While this solution is designed for the endpoint client, it doesn't do any of the above tasks. Rather, it forces users to use one type of portable media and transparently applies security protection to the data. To me, that's DLP.

In today's market taxonomy, I would agree with Larry.  However, what Larry is struggling with is not really the current state of DLP versus "endpoint security," but rather the future state of converged information-centric governance.  He's describing the problem that will drive the solution as well as the inevitable market consolidation to follow.

This is actually the whole reason Mogull and I are talking about the evolution of DLP as it exists today to a converged solution we call CMMP -- Content Management, Monitoring and Protection. {Yes, I just added another M for Management in there...}

What CMMP represents is the evolved and converged end-state technology integration of solutions that today provide a point solution but "tomorrow" will be combined/converged into a larger suite of services.

Off the cuff, I'd expect that we will see at a minimum the following technologies being integrated to deliver CMMP as a pervasive function across the information lifecycle and across platforms in flight/motion and at rest:

• Data leakage/loss protection (DLP)
• Identity and access management (IAM)
• Network Admission/Access Control (NAC)
• Digital rights/Enterprise rights management (DRM/ERM)
• Seamless encryption based upon "communities of interest"
• Information classification and profiling
• Metadata
• Deep Packet Inspection (DPI)
• Vulnerability Management
• Configuration Management
• Database Activity Monitoring (DAM)
• Application and Database Monitoring and Protection (ADMP)
• etc...

That's not to say they'll all end up as a single software install or network appliance, but rather a consolidated family of solutions from a few top-tier vendors who have coverage across the application, host and network space. 

If you were to look at any enterprise today struggling with this problem, they likely have or are planning to have most of the point solutions above anyway.  The difficulty is that they're all from different vendors.  In the future, we'll see larger suites from fewer vendors providing a more cohesive solution.

This really gives us the "cross domain information protection" that Rich talks about.

We may never achieve the end-state described above in its entirety, but it's safe to say that the more we focus on the "endpoint" rather than the "information on the endpoint," the bigger the problem we will have.

/Hoff

The Walls Are Collapsing Around Information Centricity

Since Mogull and I collaborate quite a bit on projects and share many thoughts and beliefs, I wanted to make a couple of comments on his last post on Information Centricity and remind the audience at home of a couple of really important points.

Rich's post was short and sweet regarding the need for Information-Centric solutions with some profound yet subtle guideposts:

For information-centric security to become a reality, in the long term it needs to follow the following principles:

1. Information (data) must be self describing and defending.
2. Policies and controls must account for business context.
3. Information must be protected as it moves from structured to unstructured, in and out of applications, and changing business context.
4. Policies must work consistently through the different defensive layers and technologies we implement.

I’m not convinced this is a complete list, but I’m trying to keep to my new philosophy of shorter and simpler. A key point that might not be obvious is that while we have self-defending data solutions, like DRM and label security, for success they must grow to account for business context. That’s when static data becomes usable information.

Mike Rothman gave an interesting review of Rich's post:

The Mogull just laid out your work for the next 10 years. You just probably don't know it yet. Yes, it's all about ensuring that the fundamental elements of your data are protected, however and wherever they are used. Rich has broken it up into 4 thoughts. The first one made my head explode: "Information (data) must be self-describing and defending."

Now I have to clean up the mess. Sure things like DRM are a bad start, and have tarnished how we think about information-centric security, but you do have to start somewhere. The reality is this is a really long term vision of a problem where I'm not sure how you get from Point A to Point B. We all talk about the lack of innovation in security. And how the market just isn't exciting anymore. What Rich lays out here is exciting. It's also a really really really big problem. If you want a view of what the next big security company does, it's those 4 things. And believe me, if I knew how to do it, I'd be doing it - not talking about the need to do it.

The comments I want to make are three-fold:

1. Rich is re-stating and Mike's head is exploding around the exact concepts that Information Survivability represents and the Jericho Forum trumpets in their Ten Commandments.  In fact, you can read all about that in a prior posts I made on the subjects of the Jericho Forum, re-perimeterization, information survivability and information centricity.  I like this post on a process I call ADAPT (Applied Data and Application Policy Tagging) a lot.
   
   For reference, here are the Jericho Forum's Ten Commandments. Please see #9:
   

   

2. As mike alluded, DRM/ERM has received a bad rap because of how it's implemented -- which has really left a sour taste in the mouths of the consumer consciousness.  As a business tool, it is the precursor of information centric policy and will become the lynchpin in how we will ultimately gain a foothold on solving the information resiliency/assurance/survivability problem.
3. As to the innovation and dialog that Mike suggests is lacking in this space, I'd suggest he's suffering from a bit of Shitake-ism (a-la mushroom-itis.)  The next generation of DLP solutions that are becoming CMP (Content Monitoring and Protection -- a term I coined) are evolving to deal with just this very thing.  It's happening.  Now.
   
   Further to that, I have been briefed by some very, very interesting companies that are in stealth mode who are looking to shake this space up as we speak.

So, prepare for Information Survivability, increased Information Resilience and assurance.  Coming to a solution near you...

/Hoff

Breaking News: Successful SCADA Attack Confirmed - Mogull Is pwned!

A couple of weeks ago, right after I wrote my two sets of 2008 (in)security predictions (here and here), Mogull informed me that he was penning an article for Dark Reading on how security predictions are useless.  He even sent me a rough draft to rub it in.

His Dark Reading article is titled "The Perils of Predictions - and Predicting Peril" which you can read here.  The part I liked best was, of course, the multiple mentions that some idiot was going to predict an attack on SCADA infrastructure:

Oh, and there is one specific prediction I'll make for next year: Someone will predict a successful SCADA attack, and it won't happen. Until it does.

So, I'm obviously guilty as charged.  Yup, I predicted it.  Yup, I think it will happen.

In fact, it already has...

You see, Mogull is a huge geek and has invested large sums of money in his new home and outfitted it with a complete home automation system.  In reality, this home automation system is basically just a scaled down version of a SCADA system (Supervisory Control and Data Acquisition.)  Controlling sensors and integrating telemetry with centralized reporting and control...

Rich and I are always IM'ing and emailing one another, so a few days ago before Rich left town for an international junket, I sent him a little email asking him to review something I was working on.  The email contained a link to my "trusted" website.

The page I sent him to was actually trojaned with the 0day POC code for the QT RTSP vulnerability from a couple of weeks ago.  I guess Rich's Leopard ipfw rules need to be modified because right after he opened it, the trojan executed and then phoned home (to me) and I was able to open a remote shell on TCP/554 right to his Mac which incidentally controls his home automation system.  I totally pwn his house.

So a couple of days ago, Rich went out of town and I waited patiently for the DR article to post.  Now that it's up, I have exacted my revenge.

I must say that I think Rich's choice of automation controllers was top-shelf, but I think I might have gone with a better hot tub controller because I seem to have confused it and now it will only heat to 73 degrees.

I also think he should have gone with better carpet.

I'm pretty sure his wife is going absolutely bonkers given the fact that the lights in the den keep blinking to the beat of a Lionel Ritchie song and the garage door opener keeps trying to attack the gardener.  I will let you know that I'm being a gentleman and not peeking at the CCTV images...much.

Let this be a lesson to you all.  When it comes to predicting SCADA attacks, don't hassle the Hoff!

/Hoff

Understanding & Selecting a DLP Solution...Fantastic Advice But Wholesale Misery in 10,000 Words or More...

If you haven't been following Rich Mogull's amazing writeup on how to "Understand and Select a DLP Data Leakage Prevention Solution" you're missing one of the best combinatorial market studies, product dissection and consumer advice available on the topic from The Man who covered the space at Gartner.

Here's a link to the latest episode (part 7!) that you can use to work backwards from.

This is not a knock on the enormous amount of work Rich has done to educate us all, in fact it's probably one of the reasons he chose to write this opus magnum; this stuff is complicated which explains why we're still having trouble solving this problem... 

If it takes 7 large blog posts and over 10,000 words to enable someone to make a reasonably educated decision on how to consider approaching the purchase of one of these solutions, there are two possible reasons for this:

1. Rich is just a detail-oriented, anal-retentive ex-analyst who does a fantastic job of laying out everything you could ever want to know about this topic given his innate knowledge of the space, or
2. It's a pie that ain't quite baked.

I think the answer is "C - All of the above," and t's absolutely no wonder why this market feature has a cast of vendors who are shopping themselves to the highest bidder faster that you can say "TablusPortAuthorityOakelyOnigmaProvillaVontu."

Yesterday we saw the leader in this space (Vontu) finally submit to the giant Yellow Sausage Machine.

The sales cycle and adoption attach rate for this sort of product must be excruciating if one must be subjected to the equivalent of the Old Testament just to understand the definition and scope of the solution...as a consumer, I know I have a pain that needs amelioration in this category, but which one of these ointments is going to stop the itching?

I dig one of the first paragraphs in Part I which is probably the first clue we're going to hit a slippery slope: 

The first problem in understanding DLP is figuring out what we’re actually talking about. The following names are all being used to describe the same market:

• Data Loss Prevention/Protection
• Data Leak Prevention/Protection
• Information Loss Prevention/Protection
• Information Leak Prevention/Protection
• Extrusion Prevention
• Content Monitoring and Filtering
• Content Monitoring and Protection

And I’m sure I’m missing a few. DLP seems the most common term, and while I consider its life limited, I’ll generally use it for these posts for simplicity. You can read more about how I think of this progression of solutions here.

So you've got that goin' for ya... ;)

In the overall evolution of the solution landscape, I think that this iteration of the DLP/ILP/EP/CMF/CMP (!) solution sets raise the visibility of the need to make decisions on content in context and focus on information centricity (data-centric "security" for the technologists) instead  of the continued deployment of packet-filtering 5-tuple network colanders and host-based agent bloatscapes being foisted upon us.

More on the topic of Information Centricity and its relevance to Information Survivability soon.  I spent a fair amount of time talking about this as a source of disruptive innovation/technology during my keynote at the Information Security Decisions conference yesterday.

Great conversations were had afterwards with some *way* smart people on the topic, and I'm really excited to share them once I can digest the data and write it down.

/Hoff

(Image Credit: Stephen Montgomery)

Captains Obvious and Stupendous: G-Men Unite! In Theatres Soon!

So Rich and Rich, the ex-analytic Dynamic Duo, mount poor (ha!) arguments against my posts on the the Jericho Forum.

To quickly recap, it seems that they're ruffled at Jericho's suggestion that the way in which we've approached securing our assets isn't working and that instead of focusing on the symptoms by continuing to deploy boxes that don't ultimately put us in the win column, we should solve the problem instead.

I know, it's shocking to suggest that we should choose to zig instead of zag.  It should make you uncomfortable.

I've picked on Mogull enough today and despite the fact that he's still stuck on the message marketing instead of the content (despite claiming otherwise,) let's take a peek at Captain Obvious' illucidating commentary on the matter:

Let me go on record now. The perimeter is alive and well. It has to be. It will always be. Not only is the idea that the perimeter is going away wrong it is not even a desirable direction. The thesis is not even Utopian, it is dystopian. The Jericho Forum has attempted to formalize the arguments for de-perimeterization. It is strange to see a group formed to promulgate a theory. Not a standard, not a political action campaign, but a theory. Reminds me of the Flat Earth Society.

I'm glad to see that while IDS is dead, that the perimeter is alive and well.  It's your definition that blows as well as your focus.  As you recall, what I actually said was that the perimeter isn't going away, it's multiplying, but the diameter is collapsing.  Now we have hundreds if not thousands of perimeters as we collapse defenses down to the hosts themselves -- and with virtualization, down to the VM and beyond.

Threats abound. End points are attacked. Protecting assets is more and more complicated and more and more expensive. Network security is hard for the typical end user to understand: all those packets, and routes, and NAT, and PAT. Much simpler, say the de-perimeterizationists, to leave the network wide open and protect the end points, applications, data and users.

It's an ironic use of the word "open."  Yes, the network should be "open" to allow for the most highest performing, stable, resilient, and reliable plumbing available.  Network intelligence should be provided by service layers and our focus should be on secure operating systems, applications and readily defensible data stores.  You're damned right we should protect the end points, applications, data and users -- that's the mission of information assurance!

This is what happens when you fling around terms like "risk management" when what you really mean is "mitigating threats and vulnerabilities."  They are NOT the same thing.  Information survivability and assurance are what you mean to say, but what comes our is "buy more kit."

Yeah, well, the reality is that the perimeter is being reinforced constantly. Dropping those defenses would be like removing the dikes around Holland. The perimeter is becoming more diverse, yes. When you start to visualize the perimeter, which must encompass all of an organization’s assets,one is reminded of the coast of England metaphor. In taking the measure of that perimeter the length is dependant on the scale. A view from space predicts a different measurement than a view from 100 meters or even 1 meter. Coast lines are fractal. So are network perimeters.

"THE perimeter" is not being reinforced, it's being consolidated as it comes out of firewall refresh cycles, there's a difference.  You accurately suggest that this is occurring constantly.  The reason for that is because the stuff we have just simply cannot defend our assets appropriately.

Folks like Microsoft understand this -- look at Vista and Longhorn.  We're getting closer to more secure operating systems.

Virtualization is driving the next great equalizer in the security industry and "network security" will become even more irrelevant.

Why don't the two Richies and the faithful toy-happy squadrons of security lemmings get it instead of desperately struggling to tighten their grasp on the outdated notion of their glorious definition of "THE perimeter."  That was a rhetorical question, by the way.

De-perimeterization (or re-perimeterization) garners panic in those whose gumboots have become mired in the murky swamps of the way things were; they can't go forward and they can't go back.  Better to sink in one's socks than get your feet dirty in the mud by stepping out of your captive clogs, eh?

The threats aren't the same.  The attackers aren't the same.  Networks aren't the same.  The tools, philosophy and techniques we use to secure them can't afford to be, either.

Finally:

Disclaimer:  I work for a vendor of network perimeter security appliances. But, keep in mind, I would not be working for a perimeter defense company if I did not truly believe that the answer lies in protecting our networks. If I believed otherwise I would work for a de-perimeterization vendor, if I could find one. :-)

I can't even bring myself to address this point.  I'll let  Dan Weber do it instead.

/Hoff

Captain Stupendous -- Making the Obvious...Obvious! Jericho Redux...

Sometimes you have to hurt the ones you love. 

I'm sorry, Rich.  This hurts me more than it hurts you...honest.

The Mogull decides that rather than contribute meaningful dialog to discuss the meat of the topic at hand, he would rather contribute to the FUD regarding the messaging of the Jericho Forum that I was actually trying to wade through.

...and he tried to be funny.  Sober.  Painful combination.

In a deliciously ironic underscore to his BlogSlog, Rich caps off his post with a brilliant gem of obviousness of his own whilst chiding everyone else to politely "stay on message" even when he leaves the reservation himself:

"I formally submit “buy secure stuff” as a really good one to keep us busy for a while."

<phhhhhht> Kettle, come in over, this is Pot. <phhhhhhttt> Kettle, do you read, over? <phhhhhhht>  It's really dark in here <phhhhhhttt>

So if we hit the rewind button for a second, let's revisit Captain Stupendous' illuminating commentary.  Yessir.  Captain Stupendous it is, Rich, since the franchise on Captain Obvious is plainly over-subscribed.

I spent my time in my last post suggesting that the Jericho Forum's message is NOT that one should toss away their firewall.  I spent my time suggesting that rather reacting to the oft-quoted and emotionally flammable marketing and messaging, folks should actually read their 10 Commandments as a framework. 

I wish Rich would have read them because his post indicates to me that the sensational hyperbole he despises so much is hypocritically emanating from his own VoxHole. <sigh>

Here's a very high-level generalization that I made which was to take the focus off of "throwing away your firewall":

Your perimeter *is* full of holes so what we need to do is fix the problems, not the symptoms.  That is the message.

And Senor Stupendous suggested:

Of course the perimeter is full of holes; I haven’t met a security professional who thinks otherwise. Of course our software generally sucks and we need secure platforms and protocols. But come on guys, making up new terms and freaking out over firewalls isn’t doing you any good. Anyone still think the network boundary is all you need? What? No hands? Just the “special” kid in back? Okay, good, we can move on now.

You're missing the point -- both theirs and mine.  I was restating the argument as a setup to the retort.  But who can resist teasing the mentally challenged for a quick guffaw, eh, Short Bus?

Here is the actual meat of the Jericho Commandments.  I'm thrilled that Rich has this all handled and doesn't need any guidance.  However, given how I just spent my last two days, I know that these issues are not only relevant, but require an investment of time, energy, and strategic planning to make actionable and remind folks that they need to think as well as do.

I defy you to show me where this says "throw away your firewalls."

Repeat after me: THIS IS A FRAMEWORK and provides guidance and a rational, strategic approach to Enterprise Architecture and how security should be baked in.  Please read this without the FUDtastic taint:

Rich sums up his opus with this piece of reasonable wisdom, which I wholeheartedly agree with:

You have some big companies on board and could use some serious pressure to kick those market forces into gear.

...and to warm the cockles of your heart, I submit they do and they are.  Spend a little time with Dr. John Meakin, Andrew Yeomans, Stephen Bonner, Nick Bleech, etc. and stop being so bloody American ;)  These guys practice what they preach and as I found out, have been for some time.

They've refined the messaging some time ago.  Unload the baggage and give it a chance.

Look at the real message above and then see how your security program measures up against these topics and how your portfolio and roadmap provides for these capabilities.

Go forth and do stupendous things. <wink>

/Hoff

HyperJackStacking? Layers of Chewy VMM Goodness -- the BLT of Security Models

So Mogull is back on the bench and I'm glad to see him blogging again. 

As I type this, I'm listening to James Blunt's  new single "1973" which is unfortunately where Rich's timing seems to be on this topic.  'Salright though.  Can't blame him.  He's been out scouting the minors for a while, so being late to practice is nothing to be too wound up about.

<If you can't tell, I'm being sarcastic.  I only wish that Rich was when he told me that his favorite TexMex place in his hometown is called the "Pink Taco."  That's all I'm going to say about that...>

The notion of the HyperJackStack (Hypervisor Jacking & Stacking) is actually a problem set that has been discussed at length and in the continuum of these discussions happened quite a while ago. 

To put it bluntly, I believe the discussion -- for right or wrong -- stepped over this naughty little topic months ago in lieu of working from the bottom up for the purpose exposing fundamental architectural deficiencies (or at least their potential) in the core of virtualization technology.  This is an argument that parallels dissecting a BLT sandwich...you're approaching getting to the center of a symmetric stack so which end you start at is almost irrelevant.

The good/bad VMM/HV problem has really been relegated to push-pin on the to-do board of all of the virtualization vendors and this particular problem has been framed by said vendors to be apparently solved first operationally from the management plane and THEN dealt with from the security perspective.

So Rich argues that after boning up on Joanna and Thom's research that they're arguing the wrong case completely for the dangers of virtualized rootkits.  Instead of worrying about undetectability of this or that -- pills and poultry be damned -- one should be focused on establishing the relative disposition of *any* VMM/Hypervisor running in/on a host:

Problem is, they’re looking at the wrong problem. I will easily concede that detecting virtualization is always possible, but that’s not the real problem. Long-term virtualization will be normal, not an exception, so detecting if you’re virtualized won’t buy you anything. The bigger problem is detecting a malicious hypervisor, either the main hypervisor or maybe some wacky new malicious hypervisor layered on top of the trusted hypervisor.

To Rich's credit, I think that this is a huge problem and one that deserves to be solved.  That does not mean that I think one is the "right" versus "wrong" problem to solve, however.  Nor does it mean this hasn't been discussed.  I've talked about it many times already.  Maybe not as eloquently...

The flexibility of virtualization is what provides the surface expansion of vectors for threat; you can spin up, move or kill a VM across an enterprise with a point-click.  So the first thing to do before trying to determine if a VMM/HV is malicious is to detect its presence and layering in the first place...this is where Thom/Joanna's research really does make sense.

You're approaching this from a different direction, is all.

Thom responded here, and I have to agree with his overall posture; the notion of putting hooks into the VMM/HV to allow for "external" detection mechanisms for the sake solely of VMM/HV rootkit detection is unlikely given the threat, but we are already witness to the engineered capacities to allow for "plug-ins" such as Blue Lane's that function "along side" the HV/VMM and there's nothing saying one couldn't adapt a similar function for this sort of detection (and/or prevention) as a value-add.

Ultimately though, I think that the point of response boils down to the definition of the mechanisms used in the detection of a malicious VMM/HV.  I ask you Rich, please define a "malicious" VMM/HV from one steeped in goodness. 

This sounds like in practice, it will come down to yet another iteration of the signature-driven IPS circle jerk to fingerprint/profile disposition.  We'll no doubt see anomaly and behavioral analysis used here, and then we'll have hashing, memory firewalls, etc...it's going to be the Hamster Wheel all over again.  For the same reason we have trouble with validating security and compliance state for anything more than the cursory checks @ 30K feet today, you'll face the same issue with virtualization -- only worse.

I've got one for you...how about escaping from the entire VM "jail" entirely...Ed Skoudis over @ IntelGuardians just did an interview with the PaulDotCom boys on this topic...

I believe one must start from the bottom and work up; they're trying to make up for the fact that this stuff wasn't properly thought through in this iteration and are trying to expose the issue now. In fact, look at what Intel just announced today with vPro:

New in this product is Intel Trusted Execution Technology (Intel TXT, formerly codenamed LaGrande). Intel TXT protects data within virtualized computing environments, an important feature as IT managers are considering the adoption of new virtualization-enabled computer uses. Used in conjunction with a new generation of the company's virtualization technology - Intel Virtualization Technology for Directed I/O - Intel TXT ensures that virtual machine monitors are less vulnerable to attacks that cannot be detected by today's conventional software-security solutions. By isolating assigned memory through this hardware-based protection, it keeps data in each virtual partition protected from unauthorized access from software in another partition.

So no, Ptacek and Joanna aren't fighting the "wrong" battle, they're just fighting one that garners much more attention, notoriety, and terms like "HyperJackStack" than the one you're singling out.  ;)

/Hoff

P.S. Please invest in a better setup for your blog...I can't trackback to you (you need Halo or something) and your comment system requires registration...bah!  Those G-Boys have you programmed... ;)

What Do "Grassy Knees," a Gartner Analyst, Cuban Garlic Chicken and Poor Fashion Choices Have in Common?

It's not the sordid tale of lust, information security and circus midgets you might have been expecting from the title, but instead the highlights of a couple of evenings spent entertaining a wayward analyst soul from Phoenix.

Rich Mogull, Gartner analyst and data protection mercenary, was in town for a couple of evenings, and I played cruise ship entertainment director.  It's what I do.  If a fellow blogger or security wonk comes to my town, has a few minutes to spare, it's my self-appointed duty to make damned sure they have a good time.

I'm all about the full disclosure.  It's how we roll. 

As Rich so kindly nominated me for "Best Host for Security Geeks in Boston" I must suggest that he plays the role of visiting team quite well.  Damned good head on his shoulders, fun dude to talk with and listen to, and should you ever need saving on the side of a snow-covered mountain, it seems that he's all you'll ever need.

We had a great dinner at the Naked Fish (which incidentally has nothing to do with my tattoos,) and then ended up closing that down in favor of the hotel bar in Bedford in which we most certainly were the worst dressed amongst the crowd.  We executed on the wild tech. guy role very well using every free napkin in the house to scribble the solutions to every known security problem currently defined.

I called Shimmy because whilst late, I suggested I could do his podcast drunk with Rich adding beatbox sound effects in the background.  Alan listened to me ramble for 10 minutes before he asked "Who the hell is this!?"

The next night we hit BeanSec! and hooked up with Mike Murray, 78% of Veracode's employees (except for Wysopal who is now finally too l33t to hang with us) and 46% of Crossbeam's staff.

I tried for an analyst trifecta:

Jaquith was invited but he was in Utah gettin' all Mormon'd up.  Rothman was, well, not there because BeanSec! is not pragmatic enough.  Stiennon was busy securing the network fabric of the entire nation state of Haiti and nobody @ IDC would answer my calls.  Ah well.

Despite that, a good time was had by all.

Good seeing you, Rich.  Come back sometime...as soon as you add me to your BlogRoll, that is. ;)

/Hoff

(P.S. Just to be clear, a "Grassy Knee" is one of the specialty drinks at the Enormous Room in Cambridge where we hold BeanSec!  along with the "Bad Babysitter" and "God in Little Pieces."  Any other imaginative definition is your own fault, you perv.  That is all.)