Welcome to the BigFix Blog

By now, visitors to www.bigfix.com will be aware that we have snagged the prestigious role of corporate sponsor of the 2009 Sysadmin of the Year competition. Needless to say, we jumped at the chance to do this when we learned that the previous sponsor had lost interest after an unsuccessful attempt to turn the contest into some kind of viral video fest.

While we certainly view the SAOTY contest as celebration of sysadminhood, we’re going back to fundamentals by recruiting a panel of judges to soberly weigh the qualifications of entrants in the balance. We’re not sure just how many judges we need, but thus far, we are very pleased with the panel. Amrit Williams, current BigFix CTO, former Gartner research director and IT security blogger is our chief justice. Other bench warmers include Johnny Long, founder of Hackers for Charity; Ryan Russell, author of “Stealing the Network” and other books; Robert Scoble, whose Scobleizer blog has become essential reading in Silicon Valley and beyond; Ben Kus, instigator and founder of the BigFix User Group; and Aeleen Frisch, author of Essential System Administration and a living legend in the USENIX SAGE community.

As it stands, we have rules, a court, and rewards for the virtuous. What we really need are more claimants for the prize. Who can draw the Sword of SAOTY from its stone? Or more realistically, who take home a complete “Guitar Hero” gaming set up to amuse oneself when not writing new chapters of sysadmin history?

In a world where “New!” may be the most powerful word in the marketing vocabulary, there are advantages to technologies that had their origins a while ago and have incrementally improved over the years. To me, BigFix is a case in point.

BigFix was born in the late 1990’s and tailored for the computing resource environments of that time. If I recall 1999 or so correctly, 400 MHz was a blazing clock speed, 64 MBytes was a generous memory, and 8 Gigabytes qualified as a cavernous disk drive. In terms of connectivity, 10 MBit/Sec Ethernet was standard in most enterprises, but almost everyone else connected to the Internet via a 56K modem.

The original design objectives for BigFix was to provide a mechanism for worldwide system status reporting and content distribution that would tread as lightly as possible on available computing resources. The last thing anyone wanted was to have the visibility and service delivery tail wag the host computer dog. From there, BigFix’s architects kept the BigFix Agent small (then 1-2 megabytes), and able to be throttled so as not to degrade end user experience. The designers also took care to build in features that would enable BigFix management communications over almost any wide area connection–from the plainest of POTS connections, to high-bandwidth fibreoptics.

The minor miracle here is that BigFix started small and has stayed that way. The BigFix Agent might have added some heft (currently somewhere between 4-6 MBytes), but still sips rather than guzzles system RAM. In fact the percentage of RAM occupied by the agent has shrunk to the neighborhood of 0.1 percent of a typical PC, Mac, or laptop environment. Likewise, administrators can throttle Agent operations to conserve processing bandwidth and generally not get in the way of end users acting productively. Many customers, in particularly in retail and hospitality industries and those whose global networks extend into less developed parts of the world, highly value the fact that we never came close to discontinuing support for narrow bandwidth connections.

There’s an old saying in Silicon Valley that Intel giveth and Microsoft taketh away. BigFix is one company, however, that has never regarded Moore’s Law and its corollaries as a license to consume mass quantities of memory, processing power, or network bandwidth. Staying true to our poverty-stricken roots  is one way that we have steadily expanded our competitive advantage over less nimble, overstuffed competitors as time has gone by.

Straight up, I’m not a soft touch for humanitarian appeals. But listening to Amrit’s podcast with Johnny Long, founder of Hackers for Charity struck a very sympathetic chord with me.

What caught my attention was Johnny’s eyewitness description of the impact his work was having on the lives of people who have found themselves on the wrong end of life’s lottery. Let me cite a couple of examples Johnny mentioned. Setting up a wireless network inside an office in Uganda has enabled a charitable organization to double the number of child sponsorships it can process and manage. Similarly, creating a secure website for the organization has given them an Internet storefront from which they can receive donations from anywhere in the world.

Something else riveted my attention. Johnny describes how he walked away from conventional success and renown in corporate IT to redirect his talents for the benefit of the less fortunate. I admire this intensely despite or because I realize that I do not have it in me to do anything remotely similar. Johnny is a hero, and heroes distinguish themselves by doing things the majority of humans cannot.

After reading this article on SIEM moving to the cloud <here>, it got me wondering… is all this talk of moving functions to the cloud simply a way of making security someone else’s problem?  I worked for a SIEM vendor in the past so I’m somewhat familiar with the technical challenges of aggregating and correlating vastly different data sources into something that makes sense, and is actionable.  There are business challenges as well.  Which sources do we care about? Which events are just noise and which do we need to respond to?  What are the appropriate responses?  Do we even have an incident response policy?  Have we tested it?

Those are the questions IT security and operational teams should answer well before deciding if this is a function that should be outsourced.  The “cloud” is cool.  It offers real benefits.  But it doesn’t solve the tricky bit about balancing technology with people and process.

I realize that the compliance driver is the reason for implementing SIEM in the first place so it’s not going away… however, if the focus is switched to how desktops, servers, and laptops are configured in the first place – that would certainly reduce the number of alerts generated by a SIEM, alleviating the costs associated with managing it.  And perhaps making outsourcing unnecessary.  Not to mention making audits much less painful…

Note: This post is the first from Michael Shea, BigFix IT Systems Engineer. We certainly hope it won’t be his last.

—–

The paper describing the hijacking of the Torpig botnet by the fine folks at UCSB is very engaging, even for those with technical training of less than Olympic caliber. Among the interesting topics covered are the browsing patterns of an estimated 182,000 infected hosts.

While the technical details were of great interest—in particular, the concept of Domain Flux and the infrastructure of a botnet—as an IT engineer of a growing technical company, [BigFix] the browsing analysis jumped right off my page. I’d like to point out four very special points the paper raised.

Since these are browsing habits of people who are already infected, chances are that if you see anything familiar, you might rethink the way you – or your community – use the web.

1. The first thing that caught my attention in sec. 6.1 was the discussion of the number of financial accounts that were stolen. That was idly interesting, but the last sentence woke me up:

“38% of the credentials stolen by Torpig were obtained by the password manager of browsers, rather than by intercepting an actual login session.”

I can’t tell you how many times I’ve shoulder-surfed people “logging in” to data-sensitive sites with a single click. These metrics on its risk are sobering.

Personally, I have no use for a browser’s password manager, but if you do: think seriously about how much you do, or don’t, want be one of those 38%.
(In passing, I do have to admire the botnet’s approach on this topic: kind of the digital equivalent of hitting it with a wrench.)

2. In section 6.4, we are reminded again of the importance of having a good password policy:

“Our analysis found that almost 28% of the victims reused their credentials for accessing 368,501 web sites.”

There are ways to make a gaggle of passwords different, easy to remember, and yet not require a password manager. I would love to get into some ideas on how to do that, and welcome the discussion it would generate … but perhaps another time.

To paraphrase one of the popular metaphors in the paper’s conclusion: people understand the concepts of the security of a car but don’t bother to apply those same concepts to their computing environment.

Fundamentally, would you leave your car, house, and work keys all on the hood of your car every time you parked it? That’s the effective risk incurred by reusing passwords among such sites through a browser’s password manager. The only real difference is that not to see the risk usually means not to think about it*.

3. Section 6.5 of the paper glances at the infected computers themselves, and discusses the zeitgeist of peoples’ actual browsing activity. The highest single observable interest of Torpig-infected users is to seek jobs and submit resumes, at 14%.

Sure, in today’s economy, a pile of those are probably home users. But if I were to somehow sniff any company’s web traffic on any given day, I would fully expect to see non-manager-initiated job board HTTP requests. What I mean to say is that just because it’s a work computer doesn’t mean it’s inherently safe. Yes, it’s presumably being protected by the IT staff, but no security measures are foolproof, and they haven’t been since the first rooster crowed at the dawn of civilization.

4. Finally, the paper noted that:

“… online security is a concern of the infected population (almost 10% of [infected emails] mention phishing, viruses, and spyware), but only a few people seem to suspect that they are using an infected machine.”

Torpig in particular builds sophisticated phishing pages for common banks, eBay, and PayPal sites that are very devoted to passing surface authenticity tests (sane URLs, valid SSL certs, etc.), so it isn’t too surprising that once infected, the users would only have dug the machine deeper into the disease.

Still, standard rules apply – in a nutshell, if you think something’s suspicious, it probably is. Specifically, if you log in to a site that immediately asks for your bank account number or social security number – look to your computer’s health, it might well be running a temperature.

The constant war between security and convenience rages on like the climax of a John Woo movie. No one wants to go through all the work they need to in order to keep a secure and sane computing environment. I can’t blame them—I didn’t used to lock my car until after it got looted a few times**.

Managing risk is something that can’t be done only by your CI/SO, just like managing corporate costs can’t be done only by the CFO. At some point, on some level, everyone has to be involved.

You can park your car with the windows down with the keys in the ignition***, or you can take the keys and roll up your windows. You can keep using the same password that you’ve had for years, (your firstborn’s name, your favorite candy, what have you), and use that for everything you do online, or you can devise some memorable means of switching up your passwords that is unique to every site yet meaningful only to you, so you can wean off the training wheels of a browser’s password manager.

After all, it’s easier to replace your car than your identity.

Notes

*cf. “turn up the radio when the engine starts to make funny noises” and other such metaphors by Tim Keanini
** Yes, I’m a slow learner.
***Or, if you live in the San Francisco Bay Area, you can leave your laptop visible in the back seat of a locked car.

A snapshot from our booth at the Infosec show in London the last week of April. IMO a good old fashioned trade show with plenty customers and prospects with whom to talk. A pleasant contrast to shows whose attendee cadre have become increasingly vendor dominated.

The BigFix presence at an industry conference that we dare not mention because we irritated them so much has been a huge success. The BigFix shuttle bus quickly became the only way to travel from the Moscone Convention Center to downtown San Francisco Hotels in any semblance of luxury and dignity. Those joining us on board received useful tschotschkes, welcome refreshment and an opportunity to make themselves heard through a survey we distributed on the buses. We’ll have more to say about that when we compile results.

In the meantime, here are a few pictures from the show, including a BigFix bus, Trend Micro’s Eva Chen at a Trend Micro social event and a “publicity still” from a forthcoming videocast featuring (left to right) Tom Miller, Trend Micro; Mark Starry, Concord (NH) Hospital; and Amrit Williams.

BigFix CTO Amrit Williams and Dave Watson, currently CTO of MedeAnalytics, a health care management consulting firm, discuss Watson’s experiences in managing explosive growth of distributed computing assets against a background of escalating regulatory and market-driven initiatives for health care delivery automation.