Archive for the ‘Vendors’ Category

I came across an article today about John Aycock and his new spyware class at the University of Calgary. Dr. Aycock is of the opinion that students learn better how to protect against spyware by first understanding how spyware works – and what better way for students to understand how spyware works by actually learning how to build some? Now this isn’t the first time this particular professor has espoused these particular beliefs (to great controversy) – specifically, this is the same professor that was criticized (mostly by the AV community) for offering a class that teaches students how to write viruses.

Now, put aside for the moment whether you think he’s right or wrong – we’ll get to that in a minute. For the time being, concentrate on the vendor response (consisting mostly of outrage and hyperbole.) McAfee likens the Calgary curriculum to torturing people (“It’s like saying that in order to be a better doctor you have to learn how to torture people”.) Sophos (always willing to give the benefit of the doubt) says it’s more like carjacking rather than the Mengele-esque pain frenzy described by McAfee (“Should we teach kids how to break into cars if they’re interested in becoming a policeman one day?”) Anyway, the upshot is that AV firms have gone on record saying they will never, ever, hire students who have completed these classes: “Representatives from McAfee and Sophos Internet security companies have vowed never to hire his students.” One wonders if they’ll hire students that have failed the class or if you have to actually pass it to get blackballed…

Clearly the response of these AV firms is unfair to at least one group of people; namely, the students. Is it the responsibility of a high-school senior to vet the politics of their potential professors before applying to a University? Should it be? If a student changes majors, is it their responsibility to change schools if a professor’s politics in their new program happens not to align with executives in industry? Where does a student go to consult the registry of professors whose classes make them unemployable in industry? Look – for the moment, put yourself in the shoes of one of these students: you’re bright and you completed your degree in computer science with honors. Now, it doesn’t really matter what your reason for choosing Calgary was – maybe you chose it for the excellent business school or maybe you got a scholarship (do Canadians need scholarships for school?) Anyway, no matter what the reason, Calgary was your pick. During your term, Dr. A’s classes made you so interested in AV that you decide to pursue a career in it after graduation. But then comes the sticky part: you apply to AV vendor after AV vendor. Inexplicably, you’re turned down at every firm. What’s going on? You research it, and find out that you’re blackballed; tough break… you can’t untake the class so you can’t get a job. Stick a fork in you.

So, the vendor response was hyperbolic and it was unfair to students. But these things would probably be acceptable if they’re at least justified. So, are they? It seems to me that the crux of the AV vendors’ argument is twofold: objection #1: these students are a threat and objection #2: the professor’s lab might be unsafe. So are these things true? Let’s break them down:

Objection #1: Calgary’s AV training makes students too good and too dangerous (like Benicio Del Toro in “The Hunted”). Now, maybe I’m overly skeptical, but let me ask you to compare two scenarios to illustrate why I think Calgary’s program is better than the alternative:

Scenario #1: a prospective AV employee goes to class with Dr. A and learns about malware ethics, malware countermeasures, and how malware works.
Scenario #2: a prospective AV employee spends their teen years reading electronic texts from underground groups such as the Ready Rangers Liberation Front or the Purgatory Virus Team. Maybe you reverse engineer a few viruses, maybe write a rootkit or two, maybe you write a virus toolkit or publish information on malware authorship.

Which option seems safer to you? Now, which one is more likely to get you blackballed by the industry? Apparently, the first one is unacceptable and the second one is accepted practice. How many of us in security got our start by reading less-than-reputable information sources on BBS systems or USENET (depending on your age I suppose.) Now call me cynical, but it seems to me like the Calgary program is more controlled, more conducive to learning, and probably safer because students get taught ethics while they’re learning about malware.

Objection #2: The Calgary lab is potentially unsafe – some virus a student writes could leak out and spread across the Internet like something out of “The Stand.” Bull. Now, I’ve beaten this drum in the past, but I don’t think AV vendors are the last stop when it comes to dictating laboratory conditions to research teams. For example, I raised this point when AV vendors criticized consumer reports for doing their thing to test AV protection. Why is Sophos sufficiently versed in how to create a robust laboratory environment for malware research purposes but the University of Calgary isn’t? Has Sophos studied the protection mechanisms that Dr. A has in place and published specific details on where they are lacking? No. Have they visited the lab to review the safety procedures? I doubt it. So why should it be accepted as a matter of course that they maintain a research lab, but somehow the University of Calgary doesn’t have sufficient capability to do so? This argument is spurious. I’ve said it before, and I’ll say it again: until somebody publishes some standards delineating acceptable practices for labs, nobody has the right to criticize. I don’t buy it that vendors like Sophos, McAfee or Symantec are better equipped to maintain a lab than Universities; in other words, selling software does not give you a claim to special dispensation when it comes to doing research…

Chutzpah, cajones, cheek, liver, gumption, moxie. Whatever word you use to describe it, you have to admit that it takes bucketfulls to put out the kind of marketing message that eEye’s sent out this morning. In case you haven’t seen what I’m talking about, eEye says they want to build a gigantic honeypot with your machine as the bait. For those unfamiliar with the term, a honeypot is “a computer set up to collect security data by deliberately attracting online attacks”. Now, I suspect that eEye doesn’t mean by this that they’re going to “deliberately attract online attacks” to machines running their client (at least let’s hope), and most other client security vendors already collect anonymous data from systems running their client (most ask you first if you want to participate.) But I have to say that I was definitely surprised and a bit impressed by eEye’s post-modern, punk-rock, “your machine, our bitch” marketing message.

However, bold marketing aside, I’m not going to participate in the free Blink offer. I’ve tested this product in the lab and observed a “marked decrease in system stability” on machines running Blink – I’d like to go into more specifics on this, but the research was conducted under contract so I can’t. I can tell you though, that we couldn’t run certain tests because portions of the performance and stability test harness wouldn’t run after installing the product (e.g. cygwin wouldn’t run and the COSBI profiler blue-screened the machine) on “vanilla” installs of the OS. So, unless eEye is going to support the hell out of this freebie (doubtful), I’m keeping it off my machine.

Note that our experiences were just that – our experiences; there are always tons of factors in play: maybe new versions of the product have solved this problem, maybe the problem was unique to the specific machines involved in our tests, or maybe there was no problem and we were just using it wrong…

Unless you’ve been living under a rock for the past two days, you’ve probably already heard about McAfee’s full-page ad in the Financial Times doing down the big M and alleging that new features are blocking their ability for their product to function. Even more recently, they’ve gone on the public record to say that Vista’s security will be reduced because of (ironically) two new security features that Microsoft is building into the product.

Here’s the argument: Microsoft has built a feature in to Windows Vista for the 64-bit platform that prevents folks from monkeying around with the kernel in unsupported ways (through a technology appropriately called “Patchguard”). Given that there are quite a few companies doing this, Microsoft has elected to target the 64-bit platform first so as to reduce the overall impact. However, probably in future it will expand to the 32-bit architecture as well. Microsoft alleges that by doing this, they can help users ensure reduced rootkit problems and greater stability. Now, McAfee and Symantec allege that by locking down the platform in this way, that Microsoft impedes their ability to sell product. Also, McAfee and Symantec are in a twist because of the fact that you can’t programatically disable the Windows Security Center that reports on AV installation status; they say that this impedes their ability to compete because they can’t programmatically disable the Security Center.

So, when I first read the press coverage of this, it sure sounded to me like Microsoft was being anti-competitive; but then I decided to educate myself on the various features that are under discussion – now I have a different opinion. Now I think that McAfee and Symantec are grandstanding. Why’s that, you ask? Well, here’s my take on this stuff:

Patchguard: If you take a look at the technical overview put out there by Microsoft’s Patchguard architect, Jeff Jones in his blog or if you look at the Vista kernel protection FAQ, you’ll notice that there is a subtle difference between what McAfee and Symantec are claiming vs. what the feature actually does. McAfee and Symantec claim that you can’t write certain types of code that interact with the kernel; however, that’s not what the technology does. Instead, the technology prevents products using undocumented and unsupported techniques for modifying the kernel. Take a look:

Was this kernel add-on part of the overall design? It can be, and if so, there should be predictable, well-defined interfaces that help it fit into the designed architecture. Otherwise (ie using non-documented methods), behavior is unpredictable at best… Of course, there is a difference between a driver developed by, say Hewlett-Packard, and some unknown code posted for shareware download. The former should be allowed to extend the kernel in defined/designed ways (ie. so your printer works) that the latter perhaps should not. The method for that on x64 is Kernel Mode Code Signing.

So, your options if you’re SYMC or McAfee are use defined interfaces and sign your driver. That’s not so onerous – HP has to do it for their printers to work, Canon has to do it for their scanners to work, and Western Digital has to do it for their harddrives to work. Seems to me like McAfee should have to do it too. In fact, it’s not just about fairness – I *want* McAfee to use documented interfaces. I *want* them to sign their driver. Why would I want anybody – including McAfee – to modify the kernel in a way that’s unsupported, undocumented, and untested? And frankly, it scares the hell out of me that they would fight to retain their ability to use the undocumented interfaces in the first place.

Now, somebody at McAfee might say that there are features that they can’t do because they can’t hook the kernel using “scary undocumented interface X”. However, I would ask them what those things might be; without some kind of specific example, I don’t believe it. Specifically, I find it hard to swallow that a vendor like Aladdin can write a filesystem driver that filters USB requests to encrypt data on the fly using documented interfaces, that a vendor like CA can write a driver that filters all incoming TCP connections using documented interfaces, and that a vendor like PointSec can write a driver to intercept filesystem calls using documented interfaces; but somehow McAfee can’t get it together to grep the filesystem for malware without “going commando” all over Windows Vista in a way that requires them to rewrite the kernel. WTF?! The answer is: they can do it and they will do it. So what’s motivating the outrage in the meantime?

Security Center: According to the outrage from McAfee et al, the way that the Windows Security Center is handled in Vista is also a problem; this has been represented in the press as Microsoft “forcing” users to use the Microsoft version of the security dashboard. Well, I guess technically that’s one way to say it; of course, another way to say it is that the feature prevents third parties from disabling the security center without user approval. From a user-choice perspective, the security center recognizes and integrates with third party products, was designed with openness in mind to facilitate this, and provides the user the ability to turn it off if they want to. What’s causing the ruckuss is that the user will actually have to make a decision to diable it rather than allowing Symantec or McAfee to nuke it for you.

Again, as with Patchguard, I want this. I *want* to make the decision about which vendor controls the security dashboard and I don’t want McAfee to take that decision away. I’m not going to use the Windows Security Center because I find it irritating, but I’m not going to use McAfee’s or Symantec’s either – for the same reason. In general, I don’t want McAfee making decisions for me about what Windows features are enabled or disabled just like I don’t want Microsoft deciding for me what browser I should use. It seems to me that in this case, Microsoft – by enforcing the user’s decision to choose what dashboard to use – is more about openness than McAfee’s ire about not being able to dictate to the user what security dashboard they’ll use.

I remember once being overwhelmed by an independent product review published in the US Airways in-flight magazine; it was for an energy-boosting supplement that sounded absolutely fantastic. I was ready to go out and buy it; when I happened to mention in coversation how cool this product sounded (and the fact that I had read this review of it), I was informed that the “review” was really an advertisement. And, sure enough, I had missed the small print that said “special advertising section” above the review. In that case, I neglected to fully understand who published the review I was reading, and what the intended purpose was – had I known that it was intended to promote the product, I probably wouldn’t have had the same reaction to the positive “review”.

Now before I get into how this anecdote applies to security, let me say that it’s not my intention to do down any vendor’s research; I have *NO PROBLEM* whatsoever with vendors publishing research that benefits them, that helps people look at a product in a different way, or that helps people understand a product’s suitability for their enterprise. All that stuff is perfectly grand. However, just like it was important for me to understand the motivation for the review in the US Airways magazine, it’s important for readers of these vendor documents not to forget why these things are published. Specifically, vendors are doing this stuff to forward their marketing goals – not as a public service. By the time most of these things reach your inbox, they have been carefully vetted, edited, and redacted to make sure that every aspect of the publication is in tune with the corporate marketing message.

Here’s my point: statistics can be represented any number of ways, right? And vendors who manufacture a product are more likely to draw conclusions from data that favor their product, right? Not because they are dishonest, mind you – just because they have skin in the game. And there’s nothing wrong with that. But between the malleability of the statistics and the fact that the majority of the research is published without a transparent methodology or intermediate data, you’re left at the end of the day with an artifact that (while useful for the vendor) should probably be read and understood by folks with their eyes wide open to the point of the document.

Now, in the past I’ve ranted about malware numbers from Symantec and McAfee, web application numbers from Fortify, email statistics from MessageLabs et al, and so on. This time, I happened to come across the CyberArk Privileged Password Survey via an article on the Register saying that administrative passwords are “abysmal”. OK, I’ll bite: how abysmal are they? Well, according to CyberArk, a manufacturer of software for securing administrative passwords, they stink on ice. Check out some of the conclusions from their research and their press release:

- “Approximately half of all enterprises have more privileged passwords than personal ones”
- “Privileged passwords are more powerful but less likely to be changed”
- “…up to 42% [of privileged passwords] are never updated…”
- “A major risk for hacker attacks and failed audits”

OK. So, are these things true? As with most vendor research, it depends on your point of view… For example, if you say there are “more privleged passwords than personal ones” – that’s a startling statistic and one that’s likely to get press attention. But is it useful as a barometer for the overall security of administrative passwords for our industry? Probalby not. Look, for example, at the support for this statement in the Cyber-Ark research:

* More than 500 employees, and each employee has an Administrator account associated with their workstation (72%)
* More than 500 servers with privileged password accounts (44%)
* More than 100 routers with privileged password accounts (41%)
* More than 100 software applications (71%), most of which connect with other applications (92%)

And guess what? All of these supporting facts are probably 100% accurate. But where it gets murky is not in the data but in the conclusion. For example, the majority of the “privileged accounts” in this analysis are comprised of local machine Administrator on desktops; specifically, the interpretation assumes a 1:1 ratio between workstations and employees with an admin account on every desktop. But where this falls down is in looking at publicly-avialable data conducted at taxpayer expense that suggests that 1:1 for this values is not the case. Instead, the data suggests that 1:1 is the saturation point for the workstation to employee ration and not a typical value. Consider for example, the most mainstream of all American corporations – Walmart. Is it the case that every Walmart employee has a workstation? How about the guy with the iron-lung who hands out the carts, the person putting out the produce, the individual ringing up merchandise… Clearly, they do not.

But moving beyond that… even if every employee did have a workstation, the ramifications of this fact depend on your interpretation of “privileged account”. For example, is a workstation’s local administrator account at the same level of risk and significance as a Unix server’s root account? I happen to think that these two things are very different – but the Cyber-Ark methodolgy assumes they are the same thing. Should they be treated the same in drawing conclusions? Maybe, maybe not. Hmmm…. murky.

Or take the idea that these administrator passwords make it more likely that you will fail audits; where’s the evidence for this? Say, for example, you’re a government entity regulated under FISMA; you follow – to the letter – the guidance from the NSA for configuring your workstations and you proceed to get audited by your IG. Are you likely to fail your audit or not? I would argue not. Again, the Cyber-Ark numbers are probably accurate, but one would probably be more inclined to disagree with the conclusion than agree with it in that scenario.

Everybody’s at BlackHat except me and apparently Michael
Howard. I sort of figured that since BlackHat got bought out by the CSI
people last year, that there’d be less people in attendance, but apparently that
wasn’t the case…  Anyway, as a consequence of that, chatter in the press
is off the charts with respect to Infosec: press releases are way up,
announcements are being issued like bullets from a tommy-gun, and everybody and
their brother seems to be writing about what’s going on in Las Vegas. Of course,
vendor mouthpieces are saying those things that they say and using BlackHat as
their pulpit to spread the message.  Yesterday, Caleb Sima (CTO of SPI
Dynamics) took center stage to make the proclamation that
blogs are evil:

Internet users who employ Web-based services such as Bloglines or Web
browsers such as Firefox to read Web site feeds and blogs are vulnerable to
embedded malicious code that can install spyware, log users’ passwords, scan
PCs and corporate networks for open ports and more, said Caleb Sima, chief
technology officer at SPI Dynamics Inc., an Atlanta-based Web application
security company.

Yes, apparently the blogosphere is like a gigantic petri dish newly filled
with fresh auger; any day, colonies of bacteria could come and spread like
wildfire throughout the tasty substrate.  And the reason nobody’s doing
it?  According to Caleb, because malware authors are dumb:

"The only reason we haven’t had a lot of problems yet is because no
one has really thought of it," he said… A Web feed could contain a link
to another Web site or blog that’s hosting malicious JavaScript. Or the Web
feed’s author could unknowingly paste that JavaScript into his own blog. Or a
blog may have an area allowing readers to post public comments. Those can also
store malicious bits of JavaScript…

Well that’s certainly one possibility – but I doubt it.  I think there
are other things going on too.  For example, maybe it’s not as practicable
as one might think; for example, I can tell you that I think it’d be a cold day
in hell before I "unknowingly paste" malware code into my blog
entries.  But maybe that’s just me.  Maybe some other bloggers might
be tempted to paste 40-50 lines of dense
javascript code into their entries from an untrusted source without
understanding what it does, stranger things have certainly happened. But are
bloggers more likely to paste in this nefarious code than folks users on
bulletin boards, users of services like MySpace, or other authors?  If so,
why?  Of course, it could also have something to do with the (on by
default) HTML-filtering
capability in MT 3.2 comments.  Could it be that the fact that you
can’t put scripts into comments on most blogs helps to keep down the number of
people doing that?  I would argue that it does – after all, the
impossibility of doing something usually tends to keep it from happening…

So thanks to SPI Dynamics for pointing out this danger and putting blog
readers on their guard.  After all, who needs blogs anyway?  Better we
stick to traditional media where content is more strictly controlled and this
kind of hacker
activity can’t happen.

I came across this article which talks about some new research from Kaspersky. I read this and I was extremely interested in how the primary material quantified “safe” in their analysis (there has to be more to it than made it to press.)

I sure would like to read the document, but I guess that’s not going to happen until this goes away:

There’s been some serious spin in the air of late. Yesterday, Biometric Access Systems put out some serious action entitled “Biometric lock ensures ultimate security.” Now, I’m not going to get on this company about the “ultimate security” thing (although somebody should probably tell them it won’t have the effect the intend.) Nope – these guys are a small shop, they’re in the SOHO/consumer marketplace, and they’re probably not used to security outside that environment – given these factors, leaping on them about their statements (inaccurate though they may be) is probably bad form.

Verisign, on the other hand, ought to know better. They’re distributing a white paper about why you should be using SGC (“international”) certificates on your web server. In the paper, they make some claims about these certs. For example, they say that “… among leading SSL providers only VeriSign can provide 128-bit SSL encryption

“He uses statistics as a drunken man uses lampposts – for support rather than for illumination.” 
                                                                                       ~Andrew Lang 

So, I feel like I’m on a one-man crusade sometimes.  Today, I came across
(via HackInTheBox)
a TechWorld article
called "Web Apps the Number One Security Blindspot" which basically
states that applications are a security "black hole" and that they’re
constantly being attacked with none to notice.  The article draws on a recent
report from
Fortify where they sampled a number of sites looking for attack patterns in
the wild and drew a number of conclusions based on those findings. They point
out that there’s a ton of activity going on out there in terms of application
attacks, and the further extrapolate relative prevalence of various attacks as a
percentage of overall attacks.   The instrument that they used to
collect the data of course, was their for-profit commercial tool.  

Now, I’ve pointed this out before, but there’s an inherent problem with
vendors producing research like this; particularly when that research uses their
commercial tool as the detection instrument. Specifically, these vendors
typically have a niche – and the reports produced within that niche are only
reflective of one particular area of focus.  For example, Fortify’s report
doesn’t have anything about phishing activity, malware, fraud, etc.  Is
that to say that these things don’t happen?  Of course not.  It’s not
mentioned because Fortify doesn’t do fraud detection, AV scanning or
anti-phishing solutions.  If they did, I bet it’d be in the report. 
Instead, what’s in the report is only what’s caught by their product.  So,
when they say that "On average, 50%-70% of attacks experienced by web
applications come from bots and bot networks searching for known
vulnerabilities", what that really means is "On average, 50-70 percent
of the attacks that Fortify detects are from bots" – and that’s probably
because automated, consistently-formatted attacks are more likely for a scanning
product to reliably detect. Plus, having a vendor publish these things tends to
lead to semi-biased conclusions like, "Fortify

So, in case you didn’t notice, I’ve been on vacation – so sorry about the slowdown in blogging activity. I’m back in the swing of it now, so the activity on this humble forum should once again increase. Anyway, in reviewing the million or so news or stories that collected in my box while I was relaxing in the sun, I came across this tidbit from last week where Sophos warns all computer users to switch to Mac. Check it out:

Macs will continue to be the safer place for computer users for some time to come… [That is] something that home users may wish to consider if they’re deliberating about the next computer they should purchase.

Interesting. I’m surprised by this for a few reasons. First of all, it’s reflective of a mixed-message from Sophos. If 10 out of 10 viruses don’t infect Mac, why is Sophos warning Mac users that they need virus protection? Seems like a bit of a muddle, doesn’t it?

Second of all it’s myopic; here’s Sophos giving generalized advice based on one very narrow view of the facts. Yes, it’s true that Mac’s have traditionally had less malware. However, they’re also slower to patch vulnerabilities than Microsoft by a wide margin, thereby increasing the attack surface for a malicious user. So while it might be less likely to get spyware, it might be more likely to get h4×0red. So, is it Sophos’ position that users are better off getting hacked than getting malware? Or is it just that Sophos (being an anti-virus company) has too narrow a focus to include this other information in their analysis? I’m going with the latter, in which case it begs the question, “what else are they not considering?” For example, Larry Seltzer, Gartner and others tell us that the Intel Mac – via bootcamp and parallels – is a veritable breeding-ground for malware. Of course, I’m not convinced they’re right, but what if they are? Has Sophos investigated these technologies to support their analysis or are they just shooting off the cuff?

Look, I’ve said this before and I’ll say it again. I think it’s irresponsible for AV companies to give generalized advice to users based solely on perceived trends in malware. They do it to get press, which is understandable; saying that everyone should switch to Mac is something guaranteed to get you a front-page somewhere. But what about the users that listen to it? What about the folks who’ll hear this advice and actually heed it. If they did, they’d be buying a system they’re unfamiliar with, requireing tens or hundreds of hours to learn how to use it, they’ve had to potentially invested thousdands of dollars, and they may or may not be better off overall. After all, they certainly could get malware anyway from the windows side of Boot Camp. Were they well served?

So, after all that fuss, Cisco’s gonna be a Platinum BlackHat sponsor?! Ummm… Yeah. How easy is that to see through? Clearly, last year’s debacle cost Cisco quite a bit in the court of public opinion and this year they want to take the opportunity to try to repair their image. Well I, for one, am not buying it.