getwired.com

I like opening with that subject – because it’s two words that Apple seems to never want to see next to each other.

On Slashdot today, an article covered my friends from F-Secure discussing the barriers that are precluding the antivirus industry from making inroads in protecting iPhones from malware.

Indeed, they are correct, you cannot build A/V into the iPhone platform – the API is explicitly designed to forbid that. However, I have to counterpoint. I mentioned in a tweet several days ago:

“The constraints keeping security s/w from diving deeper into the iPhone platform are the same ones precluding any need for them.”

Yes, you read that right. I’m saying that the iPhone doesn’t need antivirus. Instead, Apple’s bigger problem is the lack of a mature platform management solution for the iPhone. Let me show you why.

When I went to Winternals, we rapidly discovered a giant chasm in security as Mark and I discussed how UAC (LUA at the time) would fall far short of creating a security boundary for Windows Vista (and continues to do so for Windows 7). The chasm is the latency between these steps:

1. Exploit is identified
2. Malware is authored and released
3. Malware spreads
4. Malware is identified
5. Malware can be contained

You see, the flaw is that step 4 has to exist at all.

The fundamental flaw is blacklisting. Instead of fighting the good (but intractable) fight trying to identify all of the bad code, whitelisting relies on the premise that only known good, known trusted, code can start at all.

At Winternals, we created Protection Manager to respond to this hole in the security market. The key goals of the product were to only let known trusted code run, and to optionally run it with least privilege. In 2006, Microsoft acquired Winternals and, regrettably, discontinued the Protection Manager product. While Windows 7 features AppLocker, which theoretically applies whitelisting to Software Restriction Policies, I believe AppLocker has some fundamental shortcomings that I’ll discuss in a future post. Some aspects of Protection Manager, most notably the premise that a Digital Signature (code signing) is the best way of authenticating that code is:

1. From a trusted source and
2. Not been tampered with since publication

After Winternals, I worked on whitelisting again at CoreTrace, where the Bouncer product evolved to also recognize the importance of Digital Signatures, as one of the sources of Trusted Change. Only known trusted code is allowed to execute first off, and only code with specific properties is allowed to enable new code to be added to the whitelist.

Today, you hear mention all over the Internet of the rickrolling iPhone worm. Many have mimicked the code created on a whim by Ashley Towns, the worm’s creator. But the fundamental issue here isn’t the iPhone’s susceptibility to malware. Nope. Not at all.

You see, all existing worms that have compromised the iPhone rely on the fact that the iPhone must be both jailbroken and it must then have SSH installed, with an unmodified root password. Both qualify as best of breed “worst practices” from a security perspective.

In fact, those of us who haven’t jailbroken our iPhones (not arguing the ethics of that – that’s a separate conversation for another time) were not, and are not, susceptible at all. Why? Because the iPhone infrastructure as defined by Apple utilizes whitelisting. Only applications signed by software vendors that Apple has authorized (and that have signed the code) are ever countersigned by Apple and pushed through the App Store to be downloaded for purchase. Similar, but not as restrictive, constraints exist for Apple’s Enterprise program for application publishing.

To date, I have not seen any published malware that runs on an iPhone that has not been jailbroken or otherwise forced to run unsigned code (see Law #1 in the 10 Immutable Laws of Security. Any hack that does ever do so will rely on somehow compromising the signature infrastructure used for application publishing on the iPhone by Apple.

You may recall my original point – that the problem was the lack of enterprise management software of the iPhone itself. At CoreTrace, we were approached by an organization we were already working with that was realizing the growing number of Macs – and of even more concerning, the number of “rogue” iPhones (phones brought in by employees, and connected to the local wireless network and/or Exchange Server without IT ownership at any level).

The more we dug into it and researched, including the limited analysis necessary of the iPhone API and two fun, but largely circular conversations with Apple in Cupertino, the more we realized that they weren’t asking for, nor could we deliver (at least on non-jailbroken hardware) any form of “Bouncer for iPhone”.

Instead of security, the problem posed to an enterprise admin by the iPhone is that as an organization, you don’t need to control what is running on your iPhones from a “bad code” perspective, rather that the iPhone needs hardcore, Apple provided (and secured) management in order to control how “renegade” the devices themselves are. That means the ability to:

1. Prevent connectivity of jailbroken hardware to an organization (Exchange, wireless, Bluetooth, or other)
2. Prevent jailbreaking of connected hardware (or sever connectivity at a hardware level when it occurs)
3. Explicitly control which Apple or Enterprise published applications can be downloaded or run on connected iPhones (don’t allow games, allow only these 10 applications, etc)
4. Explicitly control the iPhone’s software image, configuration, and settings (much as Group Policy can do with Microsoft Windows systems) – NOT trying to reverse engineer how images get pushed out in a decentralized way via iTunes itself
5. Explicitly control how applications can access any PII on the device or in documents (GPS location, email addresses, address book or call history info, etc)
6. Explicitly control document DRM on the platform as IRM/RMS can do for Microsoft Office and Windows

Today (even following those conversations with Apple), KACE is the only vendor I’m aware of that performs any aspect of this kind of work, besides Apple’s weak Configuration Utility. KACE’s is very comprehensive – but both approaches suffer from the fact that they are after the fact management solutions, not built into the hardware and software of the iPhone itself.

From the time that I was at Microsoft, I kept hearing more and more “security experts” talk about how the impending doomsday was coming for handhelds. It still hasn’t really come. I believe that through their native use of whitelisting, Apple has fended this threat off for the foreseeable future for the iPhone platform. Instead, I believe that the biggest problem facing the iPhone isn’t “potential attackers” – there will be plenty of those – but their chance of success is very low.

Instead, it is the iPhone’s impending success eating into the enterprise market from the bottom up that is the problem. The lack of an enterprise management solution that is built into the deepest aspects of the system will not preclude the iPhone’s success at building up a rogue enterprise following. But it will both leave a bad taste in the mouth of the IT admins fighting the good fight to try and keep their organizations secure, and potentially introduce some bad compliance-related headaches in organizations already struggling to keep/retain compliance, due to the lack of DRM and platform control over the device itself and any information on it.

Apple itself needs to come to terms that the iPhone (and the Mac platform itself, frankly) need proper security and policy management at the lowest levels, or de-emphasize their viability as an enterprise platform on both counts.

Sorry for the length of this post – but this topic has been burning in me for a bit – I needed to get it all down for the record.

In last week’s posts, I began describing how metadata has failed us – or we, as lazy humans, have failed to use it.

Dr Hayes (David) opined here and here that “indexing isn’t the same as categorizing, but finding belongs to both…”. As always, I have to agree with David – but I also have to say that this is one of the problems with metadata as a descriptor. If we rely on “people” (those lazy things that will sit at a SBUX drive-through for 20 minutes instead of getting out of their car, walking up, and getting a cup of coffee in 8 minutes) to put in metadata, then it doesn’t work.

Indeed David has pointed out the “goof” in my last post. That is, that intrinsic data is that which can be actively indexed anyway. Extrinsic data is innately categorization – because to date it has required “people” (see above) to populate it. And that’s where it falls apart.

The difference between indexing and categorization, at the end of the day, is nerdspeak. My mom doesn’t care how the photos get organized – just that they do, and that (let’s be honest here) there is a minimal amount of “processing” necessary to take the 30 pictures she took today, and make them easily available to the family (this isn’t taking into account the step that should be there, helping her realize that sending 4 5MB pictures via email is a bad idea – love you anyway, mom!).

So what’s my overarching point here? That consumers just want their photos and movies to be available to themselves, and family and friends, as quickly and easily as possible, and not in some way that requires watching 90 minutes of digital goo just to see little Timmy’s first words. Indeed, software should continue to evolve to help consumers apply important metadata to their photos automatically. Hey – you changed locations, you’re not in Dallas anymore – you’re in Orlando – let me offer that. Apple has made many of these steps via their “Faces” feature, and by applying geotagging intrinsics to the iPhone 3G and beyond. Can’t remember where you were? Let me apply a lat/long to it! Only problem is, most non-Apple cameras (digital and video) still don’t support geotagging yet (I expect that to change, but only over the next 3-5 years). And then, they still only apply lat/long, they don’t yet take that data and turn it into information (this lat/long = New York City). Lat/long to the typical consumer are simply nerd porn. They’re useless metadata.

iPhoto (not iMovie, alas) also offers to cut up imported photos into “Events”. By default, events are just photos, correlated by their intrinsic categorization of “date they were taken”. Since cameras today (probably good, since the UI would suck) offer no way to apply any sort of extrinsic “event” data such as a birthday, holiday, vacation, etc, this is probably as good as it will get in the short term.

Faces, on the other hand, attempts to at least help you tag your photos based upon who is in them. But as I found out when discussing this with a person I met up at Terra Burger, it’s only so good. He has two boys, 2 and 5 – and the software cannot yet tell them apart most of the time. So it’s a start – but still leaves a lot to be desired. It also doesn’t work on video yet (and of course Apple still has yet to truly tie video, photo, and archival together in one function – which I think they need to do for Mobile Me to ever be worthwhile).

Long ago, I had ideas about how to help create software for Windows Media Center that would help squish commercials out of the DVR-MS files automatically. It’s actually not terribly hard. Similar logic can be applied to automatically “categorizing” (to use David’s words) video automatically, and then assisting you in processing it. Similarly, pre-processing it in such a way that long “overtakes” of video can be constructively edited down quickly into shareable snippets on Mobile Me or YouTube should become commonplace. But we’re a ways away from that.

My next post will focus on how I work diligently to avoid the overflow of photos and videos (trust me – it’s new to me – even last year’s family trip to Chicago wound up on the editing booth floor for over a year). It’s a struggle, since the software still doesn’t help you much. But I’ll give some advice, and discuss more about how software can help us move past this over the next… decade or so.

On Twitter, I was reminded of course that metadata (the lack of it) isn’t just a home media problem. It’s pervasive in our lives – especially the more you let technology into your life. I’ll expound upon that later.

In my first post I mentioned WinFS, and why it was symptomatic of the “metadata problem” that we all live with today. I’ve chosen to hone in on home media just because it’s something that we all live with – specifically the problem I mentioned earlier, where we all have media goo that we’ll never share again. Those memories that you took the time to photograph or record – may as well be buried in a cave somewhere never to be seen again.

The key problem here is two-fold. 1) You’ve recorded onto “analog” media. Hey – even if it’s a DVD, you have no way to truly “search” it. Photos are a “hand index” media only unless you begin with digital photos (check out the upcoming post on iPhoto and iMovie as they relate to that). 2) Any references that you may have had to the content of the images/video become lossier the longer you go from the time of capture to the time you try to “catalog” them. You can’t remember which day was which, which cousin was who, or where that boat tour was, and what the name of the lake was that you went across.

Truth be told, we’re all innately horrible at capturing these kinds of details about events and memories. Only the lucky person gets to recall exactly how to get back to where they were driven once without needing a map or directions. Most of us need notes, maps, or other tools to recall the small details – the kinds of things you want to recall when viewing the photos or videos with the kids a year later.

When was the last time you set the metadata properties for a Microsoft Office document you were working on? Wait – you didn’t KNOW you could add metadata properties to Office documents? Well – even if you did, you haven’t set one more times than the number of thumbs you have. I know. Don’t lie to me.

For this reason, I am electing to define two types of metadata. Intrinsic – that which can be innately, directly gathered from the media itself, and extrinsic. My example in my first blog entry in this series, the above example of Office documents, and to a large degree WinFS’ design (as most of us would have experienced it) are all extrinsic. Much like taking the time to catalog a series of 35mm photos or slides, or edit a bunch of VHS-captured memories into any form of tolerable viewing (perhaps even with captions or cataloging), nobody does this. We don’t have the time to do this – at least more than a few times and then we tire of it. Thus, “memory to media goo”. The cool new device or media type becomes frustrating because our initial intention – to share memories with others or preserve them in a useful way for ourselves, is just too damned hard.

Simply put, using extrinsic metadata to organize anything sucks. Even if it works in theory, it doesn’t work at scale, in real life. We all give up and stop trying to use it for all but special cases.

Instead, intrinsic metadata is the future. In my next post, I’ll be discussing intrinsic metadata, what it is and how it works (when it does) and where we’re all going from here.

I’ve been spending a bit of time looking into something that has bothered me for awhile. I refer to it as “Predatory Utility Software”, or “PUS”.

On Christmas day, I received two pieces of spam. These were admirable because they were able to defeat SpamSieve (my favorite software purchase of 2008). They were frustrating because they offered a piece of… software called “Error Nuker”.

For years, I’ve been telling people that so-called “registry cleaners” don’t do anything, and in fact can be the single most destructive tool you can run in Windows. One bad edit, and you can kill Windows.

I’m not even going to delve into the method that many tools like this use to spread themselves. While not “malware” in the truest sense of the word, spamming novice users, and confusing them to the point that they download tools like this should be illegal.

Windows gets “cruft” in the registry and occasionally in the filesystem over time with the installation, uninstallation, and updating of applications and Windows itself. The thing is, though this cruft in the registry causes your registry hive files to grow in size, it is benign. Tools such as this that lie to users and tell them that “errors” will occur are frankly more malignant than the actual problem they feign to solve.

I ran “Error Nuker” on a test Windows VM. It took quite a bit of time to “scan” my system, telling me each of the locations it was scanning. But you know what? In the end, all it did was point out locations in the registry that referenced files on the disk that were no longer there.

Now, it’s important to note that dead links from the registry are usually the result of uninstalling the application that put them there*. Meaning that, the only thing that cares that the link is dead is the application or application(s) that are no longer there! Meaning it does nothing!

*This tool also calls out files in Most Recently Used (MRU) menu locations in Windows – which if you are like me, you edit, send, and delete documents like crazy. But these MRU links being dead is hardly what I’d call an error condition.

“Error Nuker” is something like $20-$49 (depends on which spammer you get solicited by, I guess). Frankly, it isn’t worth free. It literally does nothing, and although it has a safe delete option, the fact that it is just a glorified registry cleaner means it’s effectively useless. An analogy? Do you think washing your car will make it go faster? Me either.

I’ve seen worse “PUS” – specifically the kind that is truly malware. But it’s really a shame that we’ve gotten to this point, where Windows users will fall prey to junk software pimping itself as fixing Windows’ problems.

Saw this hit the wire yesterday(Starbucks laptop theft) . It is indefensible. In 2006, Starbucks could not find 4 out of use laptops, each containing between 10,000 and 50,000 employee’s personal identifying information.

The time has come for the federal government to enact laws. Not compliance laws, but identity theft protection laws that make the rampant careless storage of employee, patient, or customer personally identifying data a felony. There are at least three things wrong with this latest Starbucks identity theft issue:

1. Employee, customer, and patient data should NEVER be stored on a mobile system unencrypted, and frankly shouldn’t be there to begin with.
2. Employee, customer, and patient data should NEVER be stored on any system unencrypted, whether the system is secured or not.
3. Starbucks didn’t to diddly to protect this data after losing it several times before, and in fact lost nearly twice as many employee’s personal data this time as last time (97K vs. 50K).

Frankly, compliance initiatives to jack to secure employee, patient, and customer data. The insane number of laptop and desktop thefts that are occurring every year (my wife’s data from IBM over 13 years ago was lost last year!) that are 100% completely preventable through the simple use of volume encryption software can be stopped immediately. But senior executives are not being held accountable for the inaction of their company, regardless of who “makes the mistake”.

The federal government needs to act on preventable identity theft. Now. This is a pattern of bad behavior that senior executives in organizations everywhere need to be made clearly aware of, and given severe, personal financial penalties for not stepping forward and preventing.