Proper Disclosure of Technology

Date July 28, 2008

As you might have read, I recently moved some equipment into the NJ colocation. One of the documents I generated for that move was the rack diagram, showing all of the equipment being installed, and where in the rack it went.

Being sort of proud of it, I showed it to some people in the corporate HQ when I was in the office there, and the CEO saw it. He asked, "This is all the equipment in the rack?". I verified that it was, and he said, "Good. Now get with X (the head salesman) and work on text describing this for him. I want to use it in marketing materials."

Now, on a certain level, I don't mind selling the company's product based on our technology. In fact, I'm pretty proud of what I've managed to put together, and I think if you're going to throw almost $100,000 into technology, that technology should help you actively recoup the expenditures.

My main concern is security. I'm certainly not someone who relies on security through obscurity (although it never hurts to have some of that, too), but I'm questioning what information I should release.

I've gone to measures on this blog to not reveal the name of the company that I work for, mostly because I don't think it's important to the blog itself, but also because I'd rather not reveal the internal structure of my company to anyone interested in learning more about it. It's none of their business.

In that same light, I don't really want sales material handed out stating that I've got 2 Juniper SSG5s setup in a cluster configuration, and that when they hit our website, they're actually talking to high availability Kemp LoadMaster 1500s. If I've done my job right, even with that knowledge, they wouldn't be able to break in, but it's still more information than I feel is comfortable.

The path that I'm leaning to not having the sales guy release any of the diagrams I've made this far, and not mention any of the specific technologies we're using, but only vague generalities. "High Availability clustered firewalls" instead of SSG5s, and "multiple redundant load balancers" rather than LoadMaster1500s. I haven't decided what I want to do about operating systems. Personally, I think the fact that we're a linux house means that our servers are more reliable. I'm sure a Windows admin would feel the opposite. I suppose it's much like any other divisive choice, and that polite conversation should steer away from it. Religion, politics, income, and operating system choice.

Any ideas on how you or your company approach this issue (or how you would, given the chance?)

  • lazzurs

    Hello,

    I know this is something a lot of companies have a problem with however I would suggest it is a good thing. Anyone looking to attack your network that required that knowledge can get it. Everyone else will be interested to see your architecture and might even be able to suggest improvements.

    I feel that a lot of sys admin work is done in the dark for this reason and I believe it is one of the great flaws in modern systems administration. While the software and protocols we use are open the architectures are not.

    As you said, if you are doing your job that information will not work to the advantage of an attacker and maybe the information being out there will be an extra reminder to be extra vigilant.

    Just my thoughts of course :)

    Take care.

  • Matt

    @lazzurs

    Thanks for the comment. That's an interesting take on architecture improvement that I hadn't considered. I guess I never thought about getting or giving infrastructure advice based on marketing materials.

    It's probably because I've never seen any that have any degree of specifics (which was another reason I wanted to be ambiguous).

    I suppose in a more open environment, that wouldn't be the case, though.

  • Scott Cover

    Depending on your target audience, anything above the generic buzzwords of cluster, high-availability, etc is just going to be wasted breath anyway.

    Stick with the things that make people comfortable, because too much information is going to be lost on any non-technical people.

  • Dan C

    I tend to take the approach that, like you suggest, abstraction from the intricate details is the best compromise.

    If it's for marketing purposes then most people would just like to see a pretty diagram that demonstrates what they think should meet their needs.

    It's here-nor-there what specific model of router or what flavour of UNIX comprises that complicated mesh. Merely that it is all there.

    If they want to know more for legitimate reasons, then they can always ask.

    The only downside of this which I begrudge slightly is that it goes against the OSS model of sharing knowledge. It doesn't leave much scope for corps to share the very clever things they have done with the use of different open source products back with other people.

  • Matt

    DanC said
    It doesn't leave much scope for corps to share the very clever things they have done with the use of different open source products back with other people.

    Fortunately, I've got a blog for that ;-)

    Thanks for the post! I'm not an OSS purist, but I recognize that it's an important part of the ecosphere that has to be maintained, and I appreciate the work that all the OSS developers put forth. Heck, I've even submitted a patch ;-)

  • Dan C

    Indeed :) And as a fellow sysadmin that has also been migrating datacentres in the past month, it's always interesting to read what/how other people are doing stuff.

    On the other hand as somebody without a blog and weary of our commercial IP; it pains me slightly that many other people cover the same R&D ground of bolting different technologies together over and over again, without a proper "forum" to pool that knowledge, as is present with much of the OSS world.

    Anyway, I'm slightly off-topic now. Thanks.

  • Nate

    IMO trying to hide details like specific hardware and such is a waste of effort. Like lazzurs said if someone really wants that info, they'll be able to get it. The argument to this is what if a script-kiddy uses this info to get in. Well like you said if you've done your job they won't be able to because you'll have everything locked down.

    That being said, if this is for marketing purposes then yea go ahead and obscure away. Technical details are going to confuse and scare mere mortals away. If they want more details then you can provide the full on technical specs.

  • Matt

    @Nate

    Interesting idea, having a separate technical data sheet. I hadn't considered that. I suspect that the details our clients would be interested in would actually be in the client-software side, and I highly doubt that team would be willing to provide them.

    I actually asked the salesman about how many people had asked about the technical side, regarding redundancy and fault tolerance. He said that, as of yet, no one had ever brought it up, or cared about it.

  • Jim

    What I have found working for my current company is that when we give a tour, our clients are much more interested/impressed with our storage, computing power, and flexibility in graphics file handling than any of the nitty-gritty networking details.

  • Kenny

    I'd say be vague with the information. Anyone who wants the specifics will ask for them.