The ritual is largely the same. I do my morning stuff (usually consisting of some meditation and some exercise), I grab a quick bite, and then I consult my list of things that need to get done. It is long, and seems to be getting longer. The more I work, the more I have to do. It’s a good problem to have, but it’s still a problem.

And going to RSA two weeks ago exacerbated it. I had a lot of great conversations with lots of folks who want to license our research, have us speak at their events, and have us advise them on all sorts of things. It’s awesome, but it’s still a problem.


Of course you probably think we should expand and add a bunch of folks to keep up with demand. We have thought about that. And decided against it. It takes a unique skill set to do what we do, the way we do it. The folks who understand research tend to be locked up by big research non-competes. The folks who understand how to develop business tend not to understand research. And the very few who can do both generally aren’t a cultural fit for us. Such is life…

But that’s not even the biggest obstacle. It’s that after 4+ years of working together (Rich and Adrian a bit more), we enjoy a drama-free environment. The very few times we had some measure of disagreement or conflict, it was resolved with a quick email or phone call, in a few minutes. Adding people adds drama. And I’m sure none of us wants more drama.

So we put our heads down and go to work. We build the pipeline, push the work over the finish line, and try to keep pace. We accept that sometimes we need to decide not to take a project or see how flexible the client is on delivery or scheduling. As with everything, you make choices and live with them.

And while it may sound like I’m whining about how great our business is, I’m not. I am grateful to have to make trade-offs. That I have a choice of which projects I work on, for which clients. Not that I can’t find work or deal with slow demand. The three of us all realize how fortunate we are to be in this position: lots of demand and very low overhead. That is not a problem. We want to keep it that way. Which is basically my way of saying, where is that shovel again? Time to get back to digging.


Photo credit: “Digging out auto” originally uploaded by Boston Public Library

Securosis Firestarter

Have you checked out our new video podcast? Rich, Adrian, and Mike get into a Google Hangout and well hang out. We talk a bit about security as well. We try to keep these to less than 15 minutes and usually fail.

2014 RSA Conference Guide

In case any of you missed it, we published our fifth RSA Conference Guide. Yes, we do mention the conference a bit, but it’s really our ideas about how security will shake out in 2014. You can get the full guide with all the memes you can eat.

Heavy Research

We are back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, where you can get all our content in its unabridged glory. And you can get all our research papers too.

Advanced Endpoint and Server Protection

Newly Published Papers

Incite 4 U

  1. Incentives drive organizational behavior: I am not sure why Gunnar tweeted a link to something he posted back in October, but it gave me an opportunity to revisit a totally awesome post. In Security Engineering and Incentives he goes through the key aspects of security engineering, and incentives are one of the four cornerstones (along with security policy, security mechanism, and assurance). Probably the most important of the cornerstones, because without proper incentives no one does anything. If you have ever been in sales you know the compensation plan drives behavior. It is that way in every functional part of the business. In the not-so-real world you have folks who do what they are supposed to because they do. And in the real world, those behaviors are driven by incentives, not risk (as GP points out). So when you wonder why the Ops team ignores the security policy and developers couldn’t give less of a crap about your security rules, look at what they are incented to do. Odds are be secure isn’t really on that list. – MR
  2. Persona non grata: The Mozilla Wiki does not really capture the essence of what’s going on with Mozilla’s Persona project, but the gist is that their effort to offer third party identity federation has failed. There is some debate about whether technical or financial derailed the project and prevented it from reaching “critical mass”, but I think the statement “We looked at Facebook Connect as our main competitor, but we can’t offer the same incentives (access to user data)” pretty much nails it. If you wonder why Yahoo is ditching Facebook and Google federation services in lieu of their own offering, understand that identity is the next generation’s “owning the user”, and a key means for data providers (advertising networks) to differentiate their value to advertisers. The goal of federated identity was to offer easier and better identity management across web applications, doing away with user names and passwords. But identity providers have seen the greatest benefit, through enrichment of the data they collect. – AL
  3. Ranum and Turner on whitelisting: Searchsecurity posted a great discussion between Marcus Ranum and Aaron Turner on whitelisting. I have been a huge fan of the technology for years as well, and have been doing a bunch of research on what is now called application control. I will link to our completed AppControl white paper later this week. Aaron provides a bunch of real-world perspective on the challenges, which echo the way I described the Double-Edged Sword. Marcus keeps coming back to the reality that iOS and now OS X can be governed by whitelisting, which is basically the App Store model. So is it just fear that is still preventing folks from embracing this security model? Maybe, but I don’t know that fight is still worth fighting. For those use cases where AppControl is a no-brainer, just do that. For those where you have to think about it or face an onerous application management situation, look at something like advanced heuristics which can do a decent job of protecting a subset of the most targeted applications, as I described in the Prevention post in our Advanced Endpoint and Server Protection series. – MR
  4. You don’t need to see his identification: I like being able to look at the code changes on Github and similar sites – you get to see fixes for serious security bugs like the TLS security bug reported last week. If I read this correctly it was a simple uninitialized return variable. But what bothers me is how this could have gone undetected – the first thing you do when testing SSL/TLS is send bad or odd certificates to see if the user still connects. And uninitialized return variables should pop up in static analysis as well. Much in the same way the goto bug in OS X makes a security paranoid’s hair stand on end, it is hard to imagine how this bug – bypassing one of the three crucial checks – was not caught during normal testing or manual code scans. It also reminds me to put logging code into exception handlers, because executing a routine called ‘fail’ should not be confused with successful operation. – AL
  5. Turning the tables on the adversary: Dave Meltzer has a good line of discussion on TripWire’s blog about increasing the cost to attackers of compromising your devices. His point is that you should make it fiscally irresponsible to exploit you. Great idea, but how? One suggestion is to decentralize your most valuable assets. That makes sense but also increases your cost to manage that data. So you need to trade off increasing the cost to adversaries against screwing up your own financial models. Another suggestion is to force the adversary to burn a very valuable (expensive) 0-day attack. That requires making sure you can defend yourself against widely available tools like Metasploit and the zillion attack kits available on the gray market. It comes back to Corman’s magical HDMoore’s Law. If you can’t defend against Metasploit, you have very little chance to cost an adversary much of anything. So get working on that, okay? – MR