The article mentions the following security
1.   Device username Password
2.  The playbook app also has a separate password.
3.  Some data is kept on the team wifi and is only accessible at the practice facility.
4.  256 bit AES encryption for data in transit.
5.  Remote wipe capability
6.  3 bad passwords wipes the application

We  can presume the app data is encrypted and can’t be synced to the cloud in iOS 5.

Will this be enough to stop Bill Belichick?

Here’s GoRemy’s Ode to Spygate

For those not familiar with Good, Good has an app for the phone.   The app connects to the Good data center.    A good server in our data center talks to the Good data center and our Exchange server.    In terms of connections it is similar to Blackberry.   The difference is the data is kept within a theoretically secure vault.

In every example of mobile phone policy or discussion of mobile data security it seems step one is don’t allow jailbreaking.   Good has the ability to check for jailbroken phones and based on your config either exit the app or wipe the app.

Jailbreaking iPhones became a big thing for a while.   People like to tinker.   Is jailbreaking necessary anymore?  Jailbreaking predates the appstore.   Now the phrase “there’s an app for that” is a cultural meme.   Jailbreaking was also used to get the phone onto unapproved carriers.  iPhone is now available on Verizon, and a third carrier rumored soon.  There is tethering, but now the phone company wants to sell that to you and will probably catch up with you if jailbreak to tether.    iOS5 is rumored to be bringing in many of the features formerly only available through jailbreaking such as an approved “alert” system and wireless syncing.   Facetime over 3g was also rumored for iOS5.

Jonathan A. Zdziarski made an impassioned plea for jailbreaking.   It is no longer available on this blog, so I’m linking to archive.org.  His argument is that DRM is bad, DRM is not security.  He argues that attacks on jailbreaking are fear-mongering.   Zdziarski wrote that blog post in opposition of Charlie Millers comments in 2009 that “if you care about security, you dont use a jailbroken iPhone.”

More recently, Charlie Miller commented about jailbreaking this August in an interview with Tom’s Hardware.    “Yes, jailbreaking does weaken the security of the device by circumventing the security architecture as designed by Apple (code signing, running apps as user mobile in a sandbox, etc). “   In 2009, he was more bold stating , “The process removes around 80 percent of the security protections built into the phone’s software, making it more vulnerable.” 

Saying jailbreaking is risky for an enterprise phone doesn’t mean it is the model of security if not jailbroken.   The jailbreakme PDF exploit (now patched) used vulnerabilities in mobileSafari and IOKit to priviledge escalate.   The SMS vulnerability Miller found was in the build in SMS software.   Malicious software has made it through the vetting process into Apple’s AppStore.

People are free to do whatever they want with their own phones.   But once you ask me to put corporate data on it, now I’m involved.   I think we need to approach this with an abundance of caution.  No matter how secure an app is it is relying on a untrustworthy operating system if that device has been jailbroken.  If someone used privilege escalation to gain administrator on a corporate computer we wouldn’t say “glad that works better for you” and go about our day.

Up next some similar comments about Android.

He noticed that the hardware address was listed on the retail packaging of an Apple server he just bought.   Personally I think that would be quite convenient.   In a corporate environment, that may need to be updated in an asset tracking database.   From the comments on the article, Apple isn’t the only vender to do that. 

 Gewirtz might even have a point, if he was talking about this information disclosure allowing access to internal company networks that use MAC address as a whitelist for devices.

Instead, Gewirtz is repeating out of date wireless security advice and generating a security concern from that.     Gewirtz is concerned that if you were doing HW address filtering on your wireless network, and a bad guy saw your retail package (no.  no beavis style chuckling), they would then be able to connect to your wireless network after defeating your wireless encryption.

That is actually an unfortunately phrased argument in his article.   “ Once allowed onto the network [via mac address spoofing], the intruder would simply have to begin the process of cracking your encryption.”   Actually the wireless attacker can sniff your traffic without a hardware address.   When he sniffs the wireless traffic, he will find the hardware address in the clear (unencrypted).   He/She didn’t need the retail packaging after all.   

 Stand down Gewirtz.   This is only an issue if you
1.  put your wireless security hopes in HW address filtering rather than WPA2.
2.  Your computer uses the hardware address to generate the IPv6 address. (most don’t due to privacy concerns.

That would have been a better scare article.   Maybe he should recycle that article as IPv6 gets more widely adopted.

• Certificate Trust Policy
• libxslt
• Quicklook
• WebKit

Exploitation of the most severe of these vulnerabilities may lead to remote code execution.

Isn’t this the 3rd update in the past five or six weeks?  

Does your corporation account for iPhone patching?

Apple’s writeup of the security vulnerabilities is posted at this link.

Quicktime can be updated through Apple Software Update or via download at www.apple.com/quicktime/download.

Quicktime was last updated 2.5 months ago.

SCUP can deploy MSP, MSI or EXE.   In the past I had used a BAT file to set registry keys, copy configuration files and run the install.   So that isn’t going to happen unless I compile that into a EXE.    Quicktime also requires the update of Apple Application Support.  

I decided to use my old friend SMS Installer to package the install files into one EXE and perform the installation actions.    I decided to make it as simple as possible.   The SMS install script is something like this:

Get Environment Variable %WinDir% into variable windir
Install File \\server\sourceDIR\quicktime to %empt\quicktime\
Execute %temp%\quicktime\appleapplicationsupport.msi /qn reboot=reallysuppress (wait)
Execute %temp%\quicktime\quicktime.msi
ALLUSERS=1 DESKTOP_SHORTCUTS=0 QTTASKRUNFLAGS=0 REGSRCH_INSTALL_ASU=0 /qn reboot=reallysuppress (wait)

The command-line options seem to kept the “Q” systtray icon or desktop shortcuts from occurring.   But I didn’t manage to disable checking for updates when Quicktime is opened.   It also has the really annoying new interface.   In the past I solved those problems by dropping configuration files.   That could still be done with a bit more testing.

Compile your EXE in SMS Installer (or your favorite tool to create an install file).  

Once you’re install file is ready to go you’re ready to add it to SCUP.   Select Create Update and run through the wizard.

Update Information

Update Title: Quicktime 7.6.7   (this could be anything)
Description:  Quicktime 7.6.7 improves security and is recommended for all Quicktime 7 users on Windows.   (generally I take the description from the security advisory)
Classification: Security Advisory
Bulletin ID: HT4290
Vendor: Apple
Product: Quicktime

Extended Properties

Artcle ID: HT4290
CVE ID: CVE-2010-1799
Severity: Critical
Support URL:  could be an internal url or http://www.apple.com/quicktime/download
More Info URL: http://support.apple.com/kb/HT4290
Impact: Normal
Reboot Behavior: I left this on ‘can request reboot’ although SMS Installer is returning a 0 by default

Define prerequisite Rules

 Processor Architecture = x86
and
Windows Version Greater than or Equal to
major Version 5, SP Major Version 2, Minor Version 1
Product Type = workstation

Apple supports Quicktime on XPsp2 or greater.   Apple uses a separate install file for x64.   I chose keep things simple for now and not try to package that in here.

Select Package
Installer Type = EXE
Update Package Source = Browse to your install file (I used UNC path)   doesn’t need to be accessible to anything but your installer.
Download URL or UNC = Paste the same path as above.
Command Line = /S   (this tells the SMS installer file to run silently.   If you used a different packager you’re on your own)

Define Applicability Rules
File Version:
Common Paths – select program_files
Path – quicktime\quicktimeplayer.exe
Comparison – Less than
Version – 7.67.75.0

AND
Registry key exists
HKLM\Software\Apple Computer, Inc.\Quicktime

Define Installed Rules
File Version
Common Paths – Program_Files
Path – quicktime\quicktimeplayer.exe
Comparison – Greater Than or Equal To
Version 7.67.75.0

Now you’ve got an update that is ready to go.   Publish it to WSUS and then sync to SCCM as you would with any other SCUP update.    I always see people complaining that very few venders supply CAB files for SCUP.   The fact is before this year, very few SCCM admins were using SCUP.   Vender supplied CABs might not be configured they way you want anyway.   For example the Adobe CAB for Flash assumes you want all your computers to have Flash.   If you only want to upgrade existing Flash you need to either collection limit the update or write your own detection rules.

I hope reading thought this you understand now how to roll your own update for even a complicated update like Quicktime.   Make sure you thoroughly test your deployment.

Companies that don’t want to use ActiveSync but still feel pressured into making the iPhone an option are looking to Good to do so.  

From the release notes:
• Complete landscape view – Including email list view, calendar, contacts and attachments.
• Conference dialer – quickly and easily dial into a conference bridge without having to memorize the conference pass code.
• Maps integration – quickly find the location of your meeting on a map and even get driving directions.

A change not mentioned is that when I receive a signed message instead of no indication the message is signed, I now get a message:

The sender has digitally signed the message with a personal certificate.  To verify the signature you can read this message on your desktop computer.

I can still read the message on the device, as I could before the update.   Without signature verification, I feel like this update only provides a false sense of message source identity verification.  

Its my understanding that full S/MIME support is on the roadmap.

Back in July, the US Copyright office ruled it is legal to jailbreak your iPhone in order to install non-appstore apps or even to unlock the phone to use with another carrier.

What does this mean for iPhones used the enterprise?

Just because something is permissible under the law, that does not mean that a corporation must allow it.    Apple may still make it a violation of their terms of service and void the warranty. 

Jailbreaking  offers a greater potential for malware to be run on the phone.  Do you remember the iPhone jailbreak worm?   A popular jailbreaking technique was setting up SSH and leaving a default password.   Doh!

Dave Zatz had a recent post asking if there was even a case for jailbreaking anymore.

So while my company is full of engineers who like to tinker.   While the phone has corporate data, we need to enforce a no jailbreaking policy.

As I understand it we were able to bring our Good license back up to date without much trouble.  So the remaining question is will the current gadget accessory, the iPhone, work well with Good.    Part of security is usability so this post will largely focus on Good’s usability.

Installation
For those not familiar, Good is installed as an application from the App store.   Once that is installed, it can be provisioned over the air just like the Blackberry.   No issue there.  

Policies
I’m sure you can find other places that do a blow-by-blow comparison of the policies available on a Blackberry versus Good.  I think it has the policies needed.  One issue we had for a bit was every time we exited Good even for a second, we’d have to reauthenticate when we returned to it.   It turned out we had the security policy a bit too tight.  The Good environment can be set to timeout after x minutes whether you have the app open or not.  

Email
Good does not do S/MIME.   This really sucks.   This is on their roadmap for this year.   First being able to verify signatures and then later being able to encrypt/decrypt messages as well.   So they’ll be catching up with Blackberry.    I haven’t heard if Apple has any plans to support this natively on the phone.  I didn’t ask if PGP support was in the offering.  

There seems to be issues with HTML only emails.   I’ve had that issue with a couple of message where nothing displays.   To be fair we had an issue like that with the Blackberry.   If I recall correctly they hated Cyrillic characters.

Attachments
I have not checked what attachments are supposed to be readable.   I had issues with a few docx files.  Yet when I sent myself a docx test file, it opened correctly.   There is a configuration to keep larger attachments (4 MB by default) from downloading to the device.

If you used Notes or Tasks in Outlook those items are not synced

There are a number of Good settings that aren’t supported on iOS 4 right now.   You are unable to deploy the iPhone configuration file using Good.   It’s a good idea to be able to refresh that configuration rather than just when the phone is new.  In Good’s compliance policy they have a section to force Good to close or wipe itself if it detects the phone is jailbroken.   If I understand a co-worker correctly, he was told by Good that feature doesn’t work on iOS4 either.  I haven’t gotten an answer on how Good tells its jailbroken.   It appears that its checking for installed software (and I’d need to supply the names of the apps to look for).

Calendaring
My only issue with Good and calendaring is the meeting reminders are worthless.  Seems like whether the app is unlocked or not, I get “good meeting reminder” then I have to open Good to see what the meeting was.   One of those security tradeoffs.   But a meeting title isn’t that secret to me.

Apparently delegation is not working.  My Director issued an invitation from Good to a Senior Manager.   The Admin Assistant was unable to accept on his behalf even though she had the correct Exchange rights.   I’m wondering if that is a Good configuration issue rather than something that would require a patch.   

Bottom Line
It’s a bit sad but Blackberry is no longer something they’d have to pry from my cold dead hands.   The Good application is more than acceptable usability and I think security too.   I probably check mail a bit less because it’s in a separate application but that can be a good thing.  The work/life balance can be improved if I’m not looking at work email every 5 minutes.

I’ve now heard question about allowing Good to be installed on personal iPhones.  Check out the Forrester article I linked to yesterday for some tips on policies to use in that event.  To a certain extent the flood gates are opened.   If Good is good enough for a corporate iPhone.  What about personal iPhones.  What about Android. 

I’d love to hear what other people do about a device pin/passcode versus a Good pin/passcode.   Some people feel with a strong passcode policy on the Good application no device passcode is necessary.   I’m not sure I agree with that.

The thing to remember is these research company articles focus on feature sets.   Can you check the encryption box.    Can you require a pin.   Can you remote wipe.    While that is a good baseline, I’m worried about security not box checking.   Can you bypass the encryption still is first on my list.   So they bury security considerations deep within the article after spending half the article saying the iPhone 3.1 was secure enough.   No.   It wasn’t .   iOS 3.1 failed to fix the Zdziarski Method.   There was also the insecure backups in Zdziarski’s videos.   And then later there was the boot PIN bypass.    Lets not forget that Apple downplayed or denied these issues.   That’s just how they roll.

Andrew Jaquith equates iPhone security with PC security.   Yet denies that the phone needs any of the security software that a PC would have.   He says because people don’t worry about Cold Boot Attacks against Full Disk Encryption, they shouldn’t worry about encryption bypasses on the iPhone.    My FDE product claims to have protection in place against the cold boot attack.   Additionally, the FDE still protects against cold boot attacks when off.   Lastly, laptop computers are necessary.   Replacing the Blackberry with an iPhone is personal preference.   Thus different requirements are possible.  I would suspect a phone is much more likely to be lost, and now it s a candidate to be stolen as well.

The iPhone already found a home in organizations that don’t care about security.   What is supposed to allow us to sleep at night and deploy the iPhone is the new encryption.   Each App can now have a separate data container with its own encryption keys.   Check out Anthony Vance’s blog post .   Only Mail by default is encrypted this way.   Each app developer would have to specifically use it.   I wonder if a year from now we’ll have similar security issues as were found in ios 3.

I feel pretty secure about my corporate email inside a GoodLink on the iPhone.   But what other data will end up on this device?   Fortunately, the iPhone doesn’t seem to like our brand of EAP-GTC.   So it stays off our internal wireless.   We keep them off the ASA by not enabling it for access.  (I’m guessing that request isn’t far behind).

 I feel a bit offended by the tone that anyone stopping to evaluate the security of the iPhone must be a security idiot.   (even though they do go on to say that Corporations under strict regulatory control will need the stronger security of the Blackberry).