In case you haven't been keeping up with developments, last week some FUD came around about how ET was gonna haxor your bank account and use it to make REALLY long distance phone calls. Well, quite unexpectedly the situation has become much, much worse. SC has unfortunately elected to lend this cruft an air of respectability by including this asinine story in their "top infosec news" category. The premise of the argument seems to be that aliens, somehow aware of the intimate details of how SETI@home works, are going to write a computer virus that will infect machines by means of the signal data sent around from SETI@home and thereby somehow cause serious damage. Just for the record, this was no less dumb when it was the plot of "Independence Day" (remember when Jeff Goldbloom wrote that computer virus that killed the alien mothership.) This kind of paranoid rambling is why physicists shouldn't do security (note that this works in reverse for all you aspiring Newtons stuck in InfoSec).
There are quite a few reasons why the premise is dumb, but let's start with the most obvious one: the nearest star is 4.3 lightyears away - this means that in the optimal case these aliens would have to come up with a way to hack not the machines of today, but the machines that we'll be running 4.3 years in the future. Humans couldn't do that, and we build the stupid things - some alien with tentacles for a face isn't going to figure out how to interact with *OUR* devices that we ourselves haven't even built yet. Look, four years ago we were all running Windows 2000 (maybe) or something older (probably) - the platform du jour is XP SP2 - a platform that hadn't been developed yet in 2001. Maybe somebody could pull off hacking a machine 4.3 years in the future if we lived on the set of the 'Hackers' movie, but not in any real life scenario.
Plus how's Xenu gonna get the source code? Telepathy? Even in the extremely unlikely scenario that these aliens were to get ahold of the most current source of the platform, understand the hardware architecture of the futre, and get a copy of the most current source of SETI@home - they would still need to understand it enough to find a vulnerability. Not to mention that they would then need to manipulate their radio emissions or whatever in order to exploit the vulnerability of the future that they somehow managed to find. Blah. That's about as likely to happen as my growing a set of wings and flying to Ming's palace myself for a preemptive strike.
Don't get me wrong - I have oceans of respect for ssh in all its many forms: ssh, scp, sftp, sshd... even OpenSSH and SSH Communications. However, I couldn't let this one slip by without saying something. Today, SSH Communication Security Corp. put out a press release stating that they are now fully compatible with OpenSSH.
This is all well and good, but here's my question - OpenSSH started in 1999, at which time it used the same source base as SSH 1.2.12. Right at that moment - when they were the same product - they were seamless and completely compatible. Why then, do we have to wait seven years to get that seamlessness back? Look, here's my beef: both OpenSSH and SSH Communications have a time and a place - there are reasons to use each in different contexts. And despite what you might think, they are not competitors - if you need one, only that one will do (e.g. if you need it to be free a $475 product won't cut it, and if you need support an unsupported product won't cut it.) So why are they always going at each other like Jennifer Aniston and Angelina Jolie stuck in an elevator?
Oh, you don't think there's any hostility? There is, you know. To see it in action, check out the serverwatch.com article where an SSH spokesperson cites an "11:1 vulnerability ratio against OpenSSH" and where he says that "OpenSSH can't be FIPS 140-2 certified." Aside from the deceptiveness of these two statements (one would expect this type of vulnerability disparity given their relative usage and FIPS 140-2 certification for OpenSSL - and thereby OpenSSH - is in the pipeline), the tone of these comments is unmistakeable. On the other side of the equation, OpenSSH users are certainly no less vocal about their preferences.
Look, here's the point: there are times when you might want to use OpenSSH (like when you don't have a budget for software or if you wish to redistribute without the hassle of getting a license) and there are times when you might want to use SSH's product (like if you're in the government or you want commercial support). It would make both products better - by leaps and bounds - if the animosity would stop and both parties made it seamless right out of the box. Everybody would benefit: us users wouldn't have to jump through hoops in order to get machines to talk to each other, SSH would be able to sell more units (and thus make more money) while simultaneously reducing the number of support calls, and OpenSSH would have quite a bit less static on their mailing lists about getting the two products to interoperate. Everybody wins... So why hasn't this been a priority all along rather than a newsworthy new feature?
Props to SSH for taking the first step.
The Register is running a story today about how cybercrime has become more lucrative than drugs. That sounded like an astonishing factoid, and completely blew me away... and then I read the footnote. Apparently, they are counting copyright violations and the costs of malware in that number - accounting for well over 75 percent of the cited "losses", these numbers are grossly eggagerated by the industry at large.
First of all, most copyright loss stastics start from the premise that everyone who uses a piece of pirated software is "lost revenue" - in other words, that they would have bought the software if they weren't pirating it. The same with music, movies, and so on. That just isn't the case. I know quite a few people with pirated copies of Acrobat - a 175 dollar value. I seriously doubt that the majority of these folks would have anted up a buck seventy-five for a legit copy of it if they didn't get it from a friend on the sly. I think the same is true of music - if a person dowloads Poison's "Talk Dirty to Me" because it's stuck in their head, does that mean the record company is missing out on an album sale? Would these folks otherwise have leapt into their cars for a wild ride to Sam Goody if they couldn't sit comfortably in their underwear and download it over eMule? According to these stastics, the answer is yes. I disagree.
Secondly, although I am not going to argue against the statement that malware is a problem (and an expensive one), the dollar loss values cited by industry at large often take into account numerous "intangables" that may or may not be realistic. For example, I used to work for a firm that included "lost resources" (the time spent by personnel to fix the virus) for salaried employees. Now, nobody likes to work late, but salaried employees don't cost you more if they stay overtime. Sometimes the loss stastics include software costs for AV. No matter how you slice it, they are almost always eggagerated.
Anyway, props to The Register for putting the footnote in, but jeers to the folks who put these misleading statistics together.
Just FYI - we're raising the catastrophe alert level on the TerrorMonger Alert Con to "phenomenal terror" in light of recent evidence that ET is going on a h4xx0r rampage the likes of which we have never before encountered. As if there wasn't enough FUD already, a respected physicist over at Fermi labs has sent out the alert that "SETI at home" is nothing but a breeding ground for a new type of worm - one designed to incinerate the human race!
Needless to say, I'm forced to question the legitimacy of this science. Not for the reasons cited by other researchers, but rather because I'm thinking that if the aliens wanted to take us over, that they could just activate the R6 protocol and be done with us all.
You can't make this stuff up.
I came across this article this morning. It's "Ask Leo" commenting on the security of OS X compared to other platforms. Leo himself seems pretty astute, but what really sent me over the edge were the comments; don't get me wrong, I love my Mac - but the complete lack of sense demonstrated by the raving Mac users forces me to comment. Most of the comments are from Mac users making the claim that Macs are inherently more secure than Windows. It came as a surprise to me that people really believe this, since the logic it's founded on is about as easy to follow as a Boston road atlas. Check out some of the highlights:
- If you talk with hackers, they'll tell you that at this point the Mac is considered THE prize, because everyone keeps claiming that it can't be done. Still, they don't succeed.
- Wouldn't a hacker gain the greatest glory by creating the world's first virus for Mac OS X, instead of virus number 119,587 (or whatever it's up to today) for Windows?
- Try this one on for size: according to Apple, there are "close to 16 million Mac OS X users" in the world and there are still zero (0) viruses.
Mac is the "prize"? No malware for apple? WTF - Are these people for real? Look, let's clear up the myth about the "no OS X viruses" crap. Really, there are tons . Is there some magic that keeps Apple virus free? Is it really fantastically challenging to create one? Let's put it to the test; get your stopwatch out... ready... set... go...
[emoyle@eden:~]$ vi osxmalware.sh
#!/bin/sh
find / -iname \*.sh -exec cat ./osxmalware.sh >> {}\;
:wq
[emoyle@eden:~]$ chmod +x osxmalware.sh
30 seconds. Of course, there will be "this isn't really a virus" nay-sayers. To preemptively retort, would you argue that Yankee 38-C is a virus? Trend Micro, Symantec, CA, F-Secure, Panda, Sophos and McAfee all seem to think it is - and it does exactly the same thing as the dinky little script up yonder. So of course Mac is not immune to malware - not like any platform really could be.
And is Mac really "the prize" - completely immune to all vulnerabilities? It would seem to me that "the prize" would be best at staying vulnerability free. Let's pick a vulnerability at random (say CVE-2005-1992) that impacts OSX and check out Apple's track-record on it in light of the overall timeline:
Jun 17: Vulnerability in libruby found
Jun 20: Debian patch announced
Jul 12: Mandrivia patch announced
Jul 28: SuSE patch announced
Aug 5: RedHat patch announced
Sep 22: Apple OS X patch annouced
Gee, that's almost three months after the fact, and about a month later than the nearest Linux distribution. Are you really sure about it being "the prize"? Something tells me the answer is "no." Actually, they've done pretty poorly in that particular instance.
I love my Mac, but I refuse to live in the magical fantasy play land.
'Tis the season for console game platforms, and everybody's gearing up for the new X-Box 360. I actually played some World War 2 fighting game (Call of Duty, maybe?) on the demo unit at Target, and the realism was a bit too much for yours truly. It promises to be one hell of a gaming platform. Sales are expected to be off the charts - according to CNN, Microsoft is expecting 3 million units sold in the first 90 days. Ouch, that's a lot of units. And one really cool feature of the XBox is the integreated network connectivity - via RJ45 or via Wireless - both are built in and completely seamless.
So, the plan is: in six months, we'll have tens of millions (or more) of these machines deployed. They'll all have identical hardware and firmware. They're all capable of running arbitrary software. And the majority of them will be permanently affixed to the Internet. Hmmm... Is it me, or is this setting off alarm bells for anybody else out there?
How long is it going to be before a malware author figures out that this homogenous XBox world is a "heaven" for their nefarious activities? We've already had malware that targets the PSP, why not the even more powerful XBox 360? Wouldn't every XBox in the country make one hell of a botnet? Not to be negative, but all the signs are there - the media attention that would be focused on an XBox worm would be tremendous, such a worm would have almost unprecedented virulence, and we've already seen this type of thing on other platforms. I wonder if the folks over at MSFT have thought about this, and if so what they've built in to XBox for security (or at least anti-malware) features? Hopefully they at least have an automatic firmware update capability...
Ah yes, CSI. It has something for everybody: romance, suspence, mystery, action, gore, etc... In a "taking it way to seriously" move, folks have issued statements pointing out that CSI Greg "dig the hair" Sanders neglected to follow forensic best-practices when analyzing digital evidence. The folks over at "CY4OR" have pointed out that the technique that Greg used was irresponsible and would never stand up in a court of law (I'm assuming that "CY4OR" is a 'r33t way of saying "cipher", but I could be wrong about that...) Anyway, according to these folks:
"Not only could this potentially damage evidence, any incriminating data that was uncovered would undoubtedly be thrown out of a court of law as the proper evidential procedures would not have been put in place. The evidential continuity would have been compromised and a criminal case could collapse."
Yeah; what he said. As a fan of the show, I'm deeply concerned. After all, shouldn't evidentiary procedure be the centerpiece of all entertainment? I mean, in this case it stands out particularly strong because it cuts agains the grain of the hyper-realism that is the rest of CSI. After all, when a forensics specialist kicks down a door and takes on a gang of thugs in a gun-battle, you'd think there'd be at least some paperwork or something...
Yep - I agree with CY4OR - we really need to make sure that entertainment is judged against the yardstick of real-life experience. The same way that Star Trek represents the reality of modern physics, CSI should really work harder on reflecting real-life evidentiary procedures.
Everybody's favorite demon prince Bill "Baphomet the Unholy" Gates brings us a new treat - the Microsoft Satan... er... Safety Center. Actually, I'm just kidding about the Satan thing. Although I'm sure that the souls over at Symantec are greeting this development with the same type of welcome as they would an infernal army.
The safety center is actually very good - it's friendly, which is a feature often overlooked by some of the mainstream anti-virus vendors, and it's geared toward the "joe average" computer user - not geared toward the security researcher. There are links on the page to everything from making sure your machine is in optimal configuration for security (like checking to see if patches are installed and security features enabled) and there are links there also to help you tune the performance of your machine.
Microsoft is gearing up for something, and something tells me that the SYMC, McAfee, Trend, and the like aren't going to be too happy about it. All we need is a link on the desktop or a link from that little shield icon on SP2 and I think we can start selling short our SYMC stock...
I saw on the Peter O'Kelly Reality Check that Oracle purchased Thor Technologies and OctetString.
Both are vendors of security tech according to the press release. Anytime Oracle says "security", I get suspicious. Here's the lowdown - Thor Tech sells "privilege management" and OctetString sells what are basically proxies but for databases. They also have an open source JDBC-LDAP bridge (a good idea.) The OctetString purchase makes sense to me, but I'm not clear on why they would want Thor... What's Thor have that Oblix didn't have?
In a move totally unanticipated by yours truly, the ICANN has remained under the control of the U.S. Given that none of the recommendations from the WGIG left the current structure intact, I didn't even anticipate that this would be on the table. Honestly, I'm glad I was wrong...
Remember the other day when I was talking about why assigning liablity for buggy code was a bad idea? Bruce had argued that we should sue companies for buggy software - which I argued was not a good idea because smaller companies that made freeware tools (e.g. Counterpane) wouldn't release such a tool given the risk. Well, as if to prove my point, the folks over at Elcomsoft (remember them) pointed out what is arguably a security flaw in PasswordSafe. I say "arguably" because it's a "how to make a dictionary attack viable" kind of flaw; Microsoft argued this wasn't a flaw per se when the same thing happened to them (with L0phtcrack) so maybe it's not a flaw here either.
If we all followed the "company liability" model, now would be the time to start getting our class action together against CounterPane; if we followed the "developer liability" model, I suppose we would need to sue Bruce himself. In my opinion, both are obviously foolish - nobody cares more about security than Bruce Schneier... Why sue him for someone else's creativity?
I've said it before, and I'll say it again: there's nothing more dangerous than an idiot with initiative. Sony is now recalling all CD's protected by their controversial DRM technology. This is probably a good thing, since folks digging around the uninstaller noticed the fact that the rootkit removal tool is itself a rootkit.
No, seriously - it's an ActiveX, it's marked "safe for scripting," and the developers broke one of the cardinal rules of ActiveX - i.e. if you say it's "safe", it shouldn't for example be able to connect to an arbitrary Internet site, download software, and execute it. Ouch. As a former developer, I can tell you "never do that".
In other news, BlackHat just got bought by the folks that brought us CSI.
I'll keep this entry short, since I'm not sure how many of you will care... But, I'll tell you a secret: I love biometrics. I got my start in security in the biometrics industry, and I've tried to be an active voice ever since. I've tried to help folks in the community steer their solutions away from things that are doomed to fail (like using them for online banking) and towards things that are more likely to work (using them to enforce licensing schemes the way Bloomberg has done.)
As an interested party, I am a bit saddened by the recent passing of the Biometrics Consortium email list. Apparently, the proverbial bell is tolling for the Biometrics Consortium - and it's tolling loud. The BC email discussion list was a haven for everything biometric for years, and for anybody who has been keeping up, the list is gone and the community is worse off for it. The quick story is this: a few government employees got together (the BC is a government-funded endeavor) and decided that an email list was too expensive to maintain... so they replaced it with a web forum that nobody uses. Reaction to the move was mixed (but primarily negative) - alternative lists were proposed, but the traffic on those lists is minimal.
I've never seen solidarity like what the the BC list represented in any other security discipline: academics, business folks, government, and vendors all participating in a central universal forum - sharing research, sharing insights, and everyone playing nicely together. It really was a haven. All in all, it is a solemn time for biometric innovation.
Last week gave us an interesting behind the scenes look into how content companies approach the ongoing copyright debate: we saw the Sony rootkit get exposed by the technology community, judged in the court of public opinion, and subsequently get left on the side of the road. So now Sony has promised to keep their CD's free of noxious content (at least as far as software goes - Ashley Simpson will apparently keep singing.) Everyone seems to be doing their victory dance, but I'm curious - how much did consumers really win? Was it a "confetti in the streets" victory - or maybe just a "Miller time" sort of victory? My apologies if I seem to have a negative outlook, but my quick take is that as far as things go, we won a "MillerTime" (kiddie size) sort of victory - if even that.
First and most importantly, we won nothing on the "fair use" front. It would seem to me that Sony maintains the same vise-like grip on when/how you play your music as they did yesterday. They just removed one of their technical controls. Do their rights change without the technical enforcement? If there's a cop sitting on the side of the road looking for speeders, does it become legal to speed when the cop pulls away? Clearly not. In other words, consumers are in the same position relative to Sony as they were before. Nothing's changed. In my opinion, the issue is that Sony felt it had the right to do what they did in the first place. I doubt that they're view of that has radically changed since they made their decision.
We got zilch on a technical front. The fact that this particular rootkit on this particular platform is gone doesn't mean that there aren't other technologies waiting in the wings that take away your control over a device you own... What's to come will take away our control just as effectively as Sony's rootkit, but will be forwarded by the technology. Mark my words, by the time DRM comes around, it will be so hidden inside something legitimate that we'll be begging for it to happen.
So, no - I don't think this was much of a victory. Sorry to disappoint.
The folks over at MIT have put together a study entitled, "On the Effectiveness of Aluminium Foil Helmets: An Empirical Study":
We evaluated the performance of three different helmet designs, commonly referred to as the Classical, the Fez, and the Centurion. These designs are portrayed in Figure 1. The helmets were made of Reynolds aluminium foil. As per best practices, all three designs were constructed with the double layering technique described elsewhere [2].
It's hilarious. Of course, this research and the efficacy of the MIT methodology has been counter-argued here by other scholarship.
Thanks to Diana for passing this thread along.
As promised, here are the specifics for the Security Curve "Horrific Catastrophe Yousa-People-Gonna-Die TerrorMonger Alert Con". First of all, by contrast to the other traffic lights out there, we're doing more than just malware, or just terrorists, or just what's probable. Our "con" runs the gamut from the bird-flu pandemic to rampaging armies of the undead. We're all about preparedness.
To personalize the fear that you'll experience at each level, we thought it best if the "alert zones" had a mascot. As such, here are the levels of the Security Curve system - what we call affectionately "terror levels":
Terror Level "Moderate" (Mascot: "Sleepy Kenny") - Kenny represents the lowest level of terror, "moderate" terror. Here we see Kenny sleeping it off - unaware of the panic that he is about to experience. The alert con is designed to never be at "moderate level" status - it's not scary enough. We just liked the picture. Terror Level "Cranked" (Mascot: "Kenny") - No longer sleepy, Kenny is fully cognizant of the lack of safety in the world around him. Terror sets in as he becomes aware of the truism that what can go wrong will. His terror turns to grim acceptance as he recognizes he cannot change what is. Terror Level "Heart Attack" (Mascot: "Jenny") - We see Jenny here with her party hat on. She's oblivious to all the pain, suffering, and drama going on around her. Hey, Jenny, get that grin off your face - don't you know that bird flu is coming, that the polar caps are melting, and that Longhorn is almost here? Terror Level "OH OH OH" (Mascot: "Bunny") - The bunny is the "most totally in your face" pet ever. As such, he makes a fitting mascot for our new con. Notice his copy of "Building Internet Firewalls" in the background? Yeah - safety bunny. Terror Level "OMFG" (Mascot: "Angry Bunny") - Here he is, the bunny again. We think the expression on his face speaks for itself as to why he is the appropriate mascot for the OMFG terror level for maximum fearmongering. Note that this is the default state for the "Horrific Catastrophe Yousa-People-Gonna-Die TerrorMonger Alert Con" |
In case you haven't been keeping up, Adam Shostack has a series of interesting articles about the Mac this week. As a regular Mac user, I highly recommend checking these out.
He started with commentary about the security ramifications of OSX86 - Apple's impending move to the x86 architecture. He moved from there on to Apple's handling of Quicktime 'pay to play' fixes. And then he rounds it all off with commentary on DRM rootkits for the Mac. There are a number of people who have said that you're de-facto in a better security position if you are using a Mac (you know who you are), but I think Adam's comments might color your view a bit if you've been holding that position.
Probably not the best week to comment to the press on the relative security of OS X.
We've all seen the DHS security traffic light. You know the one: where green means "move along citizen" and red means "if you can read this you're probably already crispy." Don't worry, I'm not going to rant about the DHS terror alert light - I actually happen to think it's a good idea. I do wish they would "normalize" the data so that we could move out of yellow every once in a while, but all-in-all, I've got no beef with the DHS on this one. However, I do have a beef with all the "wanna-be" traffic lights.
Like a mother hen, the DHS "threat advisory" has spawned a clutch of little infosecurity "threat advisories." We have at least ten in infosec:
There's the Symantec "Threat-Con" which tells us about "network incident activity" and "overall malware activity".
Next, there's the "Virusometer" from Panda that tells us about what Panda's software is out there finding "in the wild".
If that's not good enough for you, there's the CA "SECCON" that tells you about the state of "malware and vulnerabilities".
Of course, there's the venerable "InfoCon" that tells you about attackers, worms, and the like:

There's the VirusList.com "Virus Epidemic Threat Level"
telling us about, again, malware.
And last but not least are the NY State Office of Cyber Security "Threat Indicator" (currently at low) and the New Hampshire Department of Safety "Alert Indicator" (also at low).
Whew... What a list! In case you haven't noticed by now, these "indicators" are all reporting more or less the same metrics (mostly AV output), but they have different methodologies for normalizing the data into a high level metric. While one meter might have 3 levels (like "high, medium, low") somebody else might have four or five (like "unprecedented, eggregious, ridiculously high, severe, and pretty high.") Not only is the normalization different and the methodology different, but the indicators rarely say the same thing.
So how useful is that? If you said "useful like a glass hammer" I'm right with you. Since I can't possibly contribute any more confusion than there already is, we see no problem with our adding another voice to the cacaphony. As such, Security Curve proudly announces our new dashboard: the "Horrific Catastrophe Yousa-People-Gonna-Die TerrorMonger Alert Con." We will post the details in a subsequent post (Diana has some great pictures queued up for it) along with a URL that you can include on your webpage to keep up to date on the fear-mongering.
Taking a quick break from infosec and into the broader realm of law-enforcement, I pose the following hypothetical question:
What do you suppose would happen if I was involved in a hit and run, then I was videotaped almost running down a crowd of pedestrians, and then I told a crowd of police officers that I was drunk behind the wheel? I think it's a safe bet that I'd spend the night downtown in the "windowless hotel", don't you?
Apparently, not so if you're Paris Hilton. To illustrate the point that we're all equal under the law - but that some of us are more equal than others - the LAPD let Paris and her friends stumble away unchallenged from a videotaped hit-and-run, obvious reckless driving, and a probable DUI. Don't believe it? See it on video. It's being rebroadcast by CNN to give it that air of legitimacy.
I'm sick of reading regulatory advice from vendors. Everybody's getting "suited up" and ready to leap on board the "two factor" bus because of the recent FFIEC authentication guidance. Every tired authentication vendor seems to have come out of hibernation to wave around a copy of this year's FFIEC authentication guidance and extoll the virtues of two-factor authentication. I think vendors need to stop doing this for once and for all.
A quick search in Google news shows announcements specifically mentioning the FFIEC guidance by TriCipher, by PassMark, by BioPassword, by Callingid, by Entrust, and by ActiveIdentity (nee ActiveCard). Whew, that's quite a list; I've never even heard of some of these people. Yes, vendors are clinging to the FFIEC report like it's a winning powerball ticket.
The language in these press releases is carefully chosen and in some cases quite deceptive; the implication is that two-factor is 1) a requirement for compliance and 2) that somehow the report recommends specific approaches. Check these out:
- "...provides a variety of two factor authentication methods that meet FFIEC guidance" [TriCipher]
- "...delivers the capabilities examiners will now look for, a second factor for authentication..." [PassMark]
- "The new guidance ... require[s] strong authentication when a customer logs into his bank account over the Internet." [CallingID]
Clearly, there is an agenda at work. Like almost every other piece of regulatory guidance out there, the notion that the vendors would like to install in the buying public is: buy our product and you're compliant.
My opinion about two-factor authentication is unchanged - that unless something major happens in the industry that it's not going to be economically feasible for large-scale deployment - particularly in retail banking (or retail brokerage for that matter.) In order to justify my stagnation, I need only draw on the primary sources. Here's the relevant passage from the 2005 guidance:
- "Where risk assessments indicate that the use of single-factor authentication is inadequate, financial institutions should implement multifactor authentication, layered security, or other controls reasonably calculated to mitigate those risks."
This is not a mandate; "where it's indicated" means not every case and two-factor authentication is only one option - the others are "layered security" or "other controls." I have a firewall, does that count as "another control?" Does the fact that I'm sitting at a secure terminal on my bank's premisis count as "reasonably calculated mitigation?" Once again, this is not prescriptive - nor should it be. The FFIEC is creating a framework within which FS can operate; they are not drastically changing the technology landscape for every bank out there.
But wait isn't there more, you ask? What about all that stuff in the "background" section (pages 2-3) about the different factors and "what you have, what you know", etc. There's a reason for that. This is from the 2005 guidance:
Authentication methods that depend on more than one factor are more difficult to compromise than single-factor methods. Accordingly, properly designed and implemented multifactor authentication methods are more reliable and stronger fraud deterrents.
By stark contrast, this is from the 2001 guidance:
Authentication methods that depend on more than one factor typically are more difficult to compromise than single factor systems. Accordingly, properly designed and implemented multi- factor authentication methods are more reliable indicators of authentication and stronger fraud deterrents."
With the exception of the omission of "typically" and the addition of "of authentication", these two passages are repeated verbatim. 2005: "There are a variety of technologies and methodologies financial institutions can use to authenticate customers..." - 2001: "There are a variety of authentication tools and methodologies financial institutions can use to authenticate customers. " Etc., etc., etc.
Look - the point is that they've been saying this since 2001 and you don't see two-factor all over the place in bankerage. Actually, I don't know of any bank - with the exception of Bank of America - that's actually trying to do two-factor authentication for retail; and BoA has some extenuating circumstances. Actually, in 2001, the FFIEC specifically said, "In general, multi-factor authentication methods should be used on higher risk systems." This section has been omitted in the 2005 guidance (or maybe they just moved it so that I can't find it.)
Anyway, thus concludes my rant... From now on, I'm going to strategically ignore vendors that quote the FFIEC; I recommend others (particularly practitioners in Financial Services) do the same... I have no beef with the FFIEC; I think they do what they do very well; however I'm starting to question it when vendors try to make a regulatory play...
All of us are following the Sony DRM "rootkit" issue, right?
Since this story broke, I've been asking the question if Sony's DRM software is going to be considered "malware" by the AV/spyware players. CA has answered that question for us, and the answer is "yes, it most certainly is". They've added it to the CA Spyware Encyclopedia, and has given it a very thorough analysis.
This is a good move for CA in my opinion; the home and corporate buying public has spoken loud and clear about their feelings about this software and I think CA is heeding that sentiment. Take 5 minutes and look through the ocean of responses and comments to Mark's SysInternals blog entries - note how many are from administrators experiencing pain:
I'm just some network admin. Just a couple hundred users, a few servers, nohting special. I've encouraged users to bring CD's in to work if they want to listen to music 'cause I don't really have the bandwidth to support a lot of streaming content. Silly me.
or
I am sysadmin ... This Sony's Rootkit just makes my work harder... Having this program installed calling home is a security risk that no sysadmin can take, period. No matter how you call it: rootkit, DRM, etc. It opens a door in an already difficult to secure OS.
I know what side I'd want to be on if I were an anti-spyware player. Kudos to CA for reading the market and taking a stand.
For anybody who's not been paying attention, this hasn't been such a good week for Oracle. This week marks the release of Voyager, the first ever Oracle worm, as well as research from David Litchfield pointing out the issues with the October patch. My question is - if the patch has bugs, do we need a patch for the patch? If so, will Oracle release it quarterly?
As a connoisseur of human folly, I saw the chocolate cigarettes with an iMac on it and I just had to pass it along.
Last week marked the release of the preliminary NIPP (National Infrastructure Protection Plan) from the DHS; all 175 vague pages of it. It also marked the release of an audit of FEMA's database security, basically telling us what we already know - that FEMA's database security is in line with the rest of IT security in the DHS (i.e. minimal and poorly implemented.)
Never being one to remove the splinter from their own eye before recommending a "vigilant foreign-body exploration posture" to others, the DHS includes a "honey-do" list in the NIPP for the world at large. There's a laundry list of task items for the private sector, additional specific recommendations broken down by sector, and to-do's for academia (unfunded, of course.)
In general, I'm thinking that the recommendations will probably fly better with those folks who are out of the loop on the DHS security track record... On the upside, if you choose to ignore the recommendations by infrequently auditing, taking years to develop a security plan, not conducting training exercises, and having lax technical controls - you can honestly say that you've modeled your security program on how the DHS does business. If you decide to go that route, just remember that what works for the DHS may not work for you - after all, in the private sector, you're accountable to your customers.
In case anybody's paying attention, Grokster has shut their doors. Their website is down and their service is inaccessible. I guess everybody already knew this was coming, so there should be no surprises.
On a related note, Ed Felten has an interesting take on some of of the recent RIAA legal activity here.
I keep seeing the same analogy again and again in the security press. Mostly it goes like this: "It's good to outsource your information security; your burglar alarm uses a monitoring service, right?" The most recent one I came across was this one - and it's the same tired metaphor. This time, it's David Beesley (huge picture of his head found here) from Network Defence (an outsouring provider) telling us that "outsourcing your network security is as easy as outsourcing your office security." The truth is though, that they are not the same. Here's why:
The dynamics of "office security" (physical security) change according to locality; meaning, once you wire a facility for burglar, fire, ingress/egress - that's it. You don't have to go back in and rewire the alarm system until the facility changes in some way. And how often do the facilities change? Once a decade? Twice? Even if you swapped facilities every year, it's still pretty infrequent. But, as we all know, information security has nothing to do with locality - instead, it's tied to business process, personnel, and technology. Now, how often do you change any of those? Once a year? Twice a year? Probably not. We have to update patches, we have to keep education balanced with attrition, we might want to change our business processes for better efficiency... In fact, the infosec landscape changes to some degree every day.
No - unfortunately the only thing "network security" has in common with "office security" is the fact that they happen to have a similar spelling. "Lead guitar" and "lead pipe" have similar spelling; are they the same?
There's a new report about DHS security out there - this time from the inspector general. In case you haven't been keeping up, the DHS has been slammed by the GAO, congress, and just about everyone else.
My favorite quote:
“We recommend that DHS continue to consider its information security program a significant deficiency for 2005”
Is it just me or does anyone else feel like we're trapped in a skit from "Mondo Bizarro"? Everyone is in a hubub about who to sue for software bugs: Howard Schmidt says sue the developers, Bruce Schneier says sue the vendors, and Pete Lindstrom says not to sue anybody, but to send vulnerability researchers to jail. It's a veritable "who's who" of information security, and they're all saying the answer to software security is in the courtroom.
I, for one, wholeheartedly object to the trend. As a former developer, and a former vulnerability researcher, I can't even believe we're discussing the matter.
First and foremost, let's get prison terms and chain-gangs off the table. Now, to be fair to Pete, he says in his blog that he was kidding about actually making bug research a crime, but the part about it being good-natured tomfoolery was in his blog - not in the published article. Some folks might read the article and not know that he was kidding - they might seriously consider his recommendation that bug research be "off limits". And why not? Isn't telling people about breaking copy protection illegal nowadays? Why not telling people how to "circumvent protection mechanisms" in software?
As to who to sue, clearly it's not (as Howard Schmidt argues) the developers. I can honestly say that I would never have written a lick of software if I knew that I could be held personally liable for bugs. After all, all the developers I've ever met don't get to control their own sechedule - they are told the deadline they have to meet (which is always too short) and they have to choose what corners to cut to make the timeframe happen. Not to mention the fact that no matter how careful you are, some bugs always happen. I don't think I know anybody who would write software - or scripts, or batch files, or web pages, or flash, or word documents with macros in it, or anything else that could potentially be considered "code" - if a bug means they (and not the company) would be held liable. Oh, and don't forget microcode - so no fancy new video card for you. I don't think anyone would be left in the business to turn it into anything more than a lump of silicon and plastic - between microcode, ASIC's, and drivers - there's just too much software (shudder) to take the risk.
I also don't think that we want to go with the Bruce approach. We already have a model for how this would go down - malpractice (and malpracitce insurance) in the medical industry (which, may I remind you, isn't working so well nowadays.) Of all the proposals, his is the most innocuous - at least if companies are liable some people would still be around to write some software. Although, they would all be working for companies that could afford the "bug insurance" - like Microsoft, Oracle and Sun. Smaller companies would likely find that the costs were too high. Forget small companies giving away free software - companies that give away free tools like Counterpane's PasswordSafe or Tenable's Nessus would likely not take out an expensive liability policy when there's no commercial upside other than marketing.
I don't want to live in that world.
The other day, I mentioned a product called Trustifier and OS security in general. I got some clarification from the folks over at Googgun (the folks that make Trustifier), and I figured I'd pass the information along.
At the time, I had thought that Trustifier was a Linux distribution (which is one half of the story,) but it turns out that it can also be installed on an existing RedHat box. In my opinion, this changes the dynamic a bit, since Trustifier gives Redhat the type of access control and audit typically required within the "high surety" world such as federal, financial, and insurance. For example, folks using RedHat in the US Government will likely be interested because it gives the type of additional access control and other security capability as SE Linux, but in a COTS product. Given recent DoD 'COTS' directives, I'm thinking there's an advantage over and above SE Linux for many programs...
I recently reached out to Alex Wheeler, who I met on a job interview a number of years ago and who impressed me with his energy, intelligence, and drive. I noticed that he was doing quite a bit of research in the AV space, which really got me thinking about the state of malware scanning in the industry today...
In general, most current AV technologies are based on pattern matching. Basically, they're like 'grep' except with a fancy UI and signature update capability. Not that that's a bad thing, mind you. There were products (e.g. Thunderbyte) back in the day that worked in other ways, but the market chose the 'grep approach' over and above other detection methods. The dynamics were such that heuristic and behavioral scanners give more false readings: false positives (warning about things that are not malware) and false negatives (not warning about things that are malware.) The grep-based products had a higher rate of accuracy. That accuracy is one of the strong points of pattern matching - and therefore was historically a strength of signature-based AV scanning.
In my opinion, there is an equation at work that doesn't bode well for scanning-based AV in the long term. The equation is:
scantime = (datavolume * numberofpatterns) / (cpuspeed + iospeed)
Why this is a problem:
- "Data Volume", the amount of data scanned (number and size of files) is increasing exponentially.
- "Number of Patterns", the number of malware signatures that products must process per file is increasing exponentially.
- CPU speed is increasing linearly (Moore's law)
- IO speed is increasing linearly
This means that the time needed to conduct a scanning operation is increasing at an exponential rate; since AV performance is tied directly to scanning time, this means all signature products will become slower at an exponential rate over time. It's already started; Norton AV is exponentially slower today than it was yesterday - and exponentially slower than it was the day before that. This isn't a huge problem today, but it will be - we've seen only the "flat part" of the growth curve. But as anybody who's used Norton rcently can attest, the performance of these products is rapidly becoming a factor.
There are some noteable exceptions to the rule; CA, SpyBot S&D, and others use an intelligent spyware scanning methodology to "cheat" the equation by minimizing the data that needs to be scanned. Non-signature products like Savant and IBM's AXE are making a resurgence.
I guess time will tell.