The Long Tail of the SDL and a Product Review

Let me start with a disclaimer to “Ron Obvious” that these posts are just from a Long Tail lens. I do understand that life is more complicated than one economic theory.

I am doing some interesting contract work at the moment reviewing a Security Development Lifecycle (SDL)  for a global pharmaceutical company and reviewing a product for a VC firm. Both projects have very interesting implications if you buy into the Long Tail theory.

The Tail of the SDL - I was hired by the CSO of a global pharmaceutical company based here in Europe to take a look at their Security Development Lifecycle (SDL) and try to explain why it wasn’t working. He invested the equivalent to a million dollars last year with a “big four” firm to build it yet external audits were still horrible and causing embarrassment as he started his annual budget cycle. My obvious initial reaction was that culture takes time to change but after some high-level background discussions I thought I had figured out the issue over the phone.  Having now spent a week on-site validating my theory as well as taking a high level look at the software security program as a whole I was right.  The “big four” started out by looking at how software was built at this company. They interviewed the development team and were told they were a RUP (Rational Unified Process) shop. All good if you are an auditor; structured organized and well documented. They did dig a little deeper and understand that like most companies they were a RUP “like” shop and had modified it to suit their exact needs. They then built security standards, processes and a lifecycle around RUP. In fairness this supporting material was not bad. It wasn’t good but it wasn’t bad.

So what was the problem?  It was a Long Tail issue if you view life through a Long Tail lens of course! RUP was used to build software at the head of the tail. It was the ‘ official” development methodology mandated by the company. But as anyone who has ever worked in a development environment in a big company knows (and people who just read and build services from them don’t) is that in the real world people build software in a million different ways. There will be the guy who has his own subversion server running on his VM ware laptop, the “XP” (eXtreme programming) dudes in the cube farm and the gray beard guy who still writes COBOL for the mainframe. The RUP maybe the short tail but everything else is used to produce software in the Long Tail and this is the majority. What the big four had failed to understand is how My Photosoftware gets built in the real world and built an SDL for theory and not the practice. The majority of software being produced still had no security development lifecycle.

Product Review - I have been hired by a VC firm who is deciding wether to invest in a first round of financing for a small startup. It’s product management due diligence work if you will; they essentially want my opinion on wether the product will likely sell now and want to derive a set of good ideas for how the product should grow so they can scope the pot of investment money that will be needed in a second round to make the company scale. It is interesting work. I go to a bunch of friendlies who know I am not trying to sell them anything and get honest market feedback, combine it with my opinions and for a weeks worth of  review they get an independent opinion and a new lens. It is with their permission I post this. I am doing the same kind of work directly for two new startups in the coming weeks and will hopefully post lessons learned from those engagements as well.

This product solves the real-world problem of file transfer between two companies who don’t have anything in common apart from end user email relationships. You can basically send bulk files using real file transfer mechanisms across the Internet initiated from an email conversation and some Exchange forms. It solves a real world practical problem I see all the time. Keys get exchanged seamlessly using S/MIME (the system even generates S/MIME certs for you if you don’t have them) and in general it has one of the most intuitive UI’s I have seen in ages. Business users get it right away. BUT (and this is the big but) it uses one file transfer protocol and one crypto algorithm. This means that in order to sell the product today the sales guy has to find the technical buyer whose security religion (or dogma depending on his nature | side of bed he woke up on) matches that of the product designer. “I am sorry but we only do TLS here, SSH is so …..”….”SSH is the standard here mate, we are a UNIX shop”. More importantly still is that the potential market for this company is to build a flexible file transfer platform that can be integrated into line of business applications thus reducing the cost of future development, reducing the cost of operations and providing “dead-easy” solutions to mundane daily problems.  For the startup it would be a “sticky” solution.

Again the designer created for the short tail making an assumption that a popular algorithm and popular file transfer protocol was sufficient to address the needs of the customers. He should have thought about the Short and Long Tail and designed the product for the total market. 

Am I obsessed by the Long Tail? I think it is a healthy passion.

Explore posts in the same categories: Long Tail Security, Security Industry, Startup

One Comment on “The Long Tail of the SDL and a Product Review”

  1. MikeA Says:

    I know that you gave a caveat up-front, but here’s where the long tail doesn’t work, especially in product design.

    Coming out of the gate you have to design for the largest *common* audience. Sure, the largest audience overall may be in the long tail, but they also have wide and varied requirements, settings, dependencies, etc. When writing a v1 product (even more so in a start up environment), you need as much “bang for your buck” as you can. Adding lots of features to attract the long tail makes the product more complex to design, code, test, deliver and maintain.

    So here’s my caveat as well :) Although a product has to focus its requirements/features on the short tail initially in order to limit scope to a reasonable and actionable level (no, “boiling the ocean” - one of your favorite sayings if I remember!), the product *must* be designed/architected so that it can be easily modified/upgraded/support plug-ins/etc to suit the long tail. Not necessarily straight away, but if it’s not at least on the roadmap then the product is not scalable and “brittle” in such that a change in market conditions (or technology as in your example) can mean the end of the company.

Comment: