Wednesday, December 31, 2008

2008 Year End Summary

It’s been almost a year since I started blogging. Sam Buchanan, who has been blogging since 2001, tried to get me started a couple times years ago, but I didn’t really think I had anything to write about, or maybe I thought that nobody would read what I wrote, or maybe I wouldn’t admit that I didn’t really know what  blog was, so I never started. My boss finally convinced me to start writing, and this blog is the result. I’m probably late to the party, as the trend seems to be shifted toward micro-blogs or Tweets. I’m a fan of well written, original thoughts in the longer blog format though, so that’s what I’ve tried to present here on this blog.

Here’s a short summary of the interesting posts from the first year.

Security related posts include a post on protecting yourself from your own applications.  It’s a concept that we’ve used for years that unbeknownst to me is closely related to Biba and BLP. Hopefully I’ve recorded the essence. I also wrote some thoughts on de-provisioning as related to security, and a bit on the recent shift toward applications as the target of Internet hacks.

System management posts include thoughts on minimally configuring systems, on ad hoc versus structured system management, and a proof of concept that we did a few years ago on self provisioning servers. I got thoroughly annoyed by the bloggers who ranted on about ISP’s that didn’t patch their DNS’s overnight, making no allowance for a reasonable test/QA cycle, so I wrote some thoughts on rapid patching versus availability.

Availability posts outlined essential transitions to higher availability, touched MTTR and MTBF and availability when humans are included, and availability versus complexity. I also wrote a series of posts on estimating the availability of redundant and non-redundant systems. (The availability related posts seem to catch more search engine referrals than anything else on the blog).

Other possibly interesting posts might be the one on scaling our on-line instructional management system to over 14 million page views per day. For some people, that’s a small system. For us, it’s our largest application by far, touching almost all students and faculty in the state. We also started calculating the rough cost of running certain database queries and feeding the data back to the application developers, figuring that optimization effort should be tied somehow to operational costs.

Non-nerdy posts include a couple posts on energy use for wall warts and game consoles, a couple posts on privacy in a security camera and database infested world, and my initial post and a follow up post on my annoyance at having to be tethered to a bulky computer or notebook.

And finally, a nostalgia post generated a bit of interest among the been-around-the-block readers.

It’s been interesting.

Michael Janke

Tuesday, December 16, 2008

If it can browse the Internet, it cannot be secured

Tired of IE’s vulnerabilities?

You could switch to Firefox, but if you were honest, you’d have to admit that you still can’t declare yourself secure. Or you could try Opera, but then you’d have to manage critical patches also, though perhaps less frequently. There is nothing about Chrome or Safari that indicates that using them will make you secure. They may have fewer vulnerabilities, or it may be that fewer of their vulnerabilities have been discovered and published. You may be more vulnerable or less vulnerable by switching browsers, but you will still be vulnerable. Throw in cross platform vulnerabilities and the combined vulnerabilities of the various third party browser addons & the menu looks pretty bleak.

Frankly, as the threats from the Internet have evolved over the last decade or so, I’ve not seen a huge difference between the security profiles of the various browsers. Some have fewer vulnerabilities, some have more; some have an easier selection of somewhat more secure browsing modes, others are more difficult to configure reasonably securely. None, as far as I can tell, are bug free, hardened, or easily configurable in a manner that is sufficiently secure such that ordinary users can fearlessly browse the Internet. There are differences between the browsers, and I have a strong preference for one browser, but fundamentally the choices are only that of relative security, not absolute security. The most popular browser likely has the most problems, but it also is the biggest target. When or if a less used browser that currently appears to be more secure ends up the most widely distributed browser, it’s pretty safe to assume that it will be targeted and it will get hit, and the results will be more or less the same.

Even if you could build a perfectly secure browser, you still have the infamous simian keyboard-chair interface that will routinely click on the banner ad that installs malicious fake ‘security’ software or stumble upon widely distributed malicious content. I don’t think it is possible to secure that particular interface using current technology.

My conclusion is simple:
If it can browse the Internet, it cannot be secured.
Start with that premise. The security model that you begin to derive is significantly different than where we are today.

Tuesday, December 2, 2008

Startups and Early Adopting Customers

Any product, no matter whose it is, will only meet a fraction of your needs. Working with early startups gives you the ability to influence a product early in its life cycle and increase that fraction. You get to nudge a product in a direction that matters to you, while the startup gets unvarnished, raw, but valuable product feedback.

In a recent post on Security for All, Joseph Webster describes risk to innovation that startups face when transitioning to established corporations. From the point of view of a customer of startups, the transition that the startup needs to make is also interesting:


In a small startup everyone is intimately familiar with the customers, whereas large corporations have to make concerted efforts to allow a design engineer to even have marginal contact with a customer - and that’s usually second hand through either a sales or marketing initiative.[1]

As a customer, I’ve seen both ends of the spectrum. My team was one of the early customers of LogLogic back when the founder, VP, and the guy who came on site and racked up the appliance were one and the same. We had pretty good response from them on bug & feature requests, sometimes overnight, at least until they hooked up with some vastly larger customers. Once they hooked up with large customers, the startup correctly judged that focusing on the large customers would keep them in business.

On the big corporation side, Microsoft has a free customer-developer program called ‘Frontline’, where Microsofts own engineers and developers come on site to see how their customers are using their products. This gives individual developers & engineers access to customers in an informal one-on-one setting, where in theory each can learn from the other. We’ve had a couple of Microsoft SQL database developers on site as a part of that program and are planning on doing it again. The feedback loop in a program like that isn’t anywhere near as direct though.

There are also times that for some reason the early customers of a startup don’t seem to be able to influence the product. We are one of the earliest and largest customers of a small software company. It is surprising how little influence we seem to have on moving critical features and functionality forward within that company, even when we team up with the rest of the large customers and present a unified, prioritized feature request list. They are small and agile startup, so they should be able to do much better than what they are.

Many of us are big enough that we probably can influence a small startup if we get connected up early enough, but we are small enough that we’ll lose our influence once the startup catches a big customer, hires executives and moves to Silicon Valley. At some point in time, as Webster indicates, the lead engineer no longer calls on customers directly and at best can only focus on a few of the largest, if any. The feedback loop from customer to engineer to product isn’t simple and direct anymore, and the ability to move the product in a direction that solves your problems declines.

The transition point is about when you start getting sales calls from someone you’ve never met and who can’t pronounce your name.



[1]"The dark side of post startup innovation", Joseph Webster,Security for All