This is the input I use to a threat model when discussing the impact of jailbreaking with app makers. Remember that I know nothing about your company, the value of the assets you'll be storing/accessing on your iPhones (to you nor to the attacker), who the attacker might be and so on.
For a non-jailbroken iPhone, I consider that the software on the device is completely under the control of the owner. Opportunities for installing code are restricted to the App Store and an enterprise deployment configuration, if the phone is set up for enterprise deployment.
This means that we can restrict ourselves to vulnerabilities (and the possibility of trojan data-sending features) in deployed apps, and to the data available in these apps. The most likely risk I consider in this situation is losing the handset; either for it to wind up in the hands of an attacker or in an industry with a zero-tolerance policy to data exfiltration. Exploiting an installed app to gain access to the data is a possibility, but I expect it to be unlikely unless your specific user is being targeted. There are better things to make botnets out of than iPhones.
Understanding the threat posture of an installed app probably means asking the vendor for an assessment, and only deploying apps where the vendor can provide such information. How far the vendor is willing to go to get a dollar sale is an open question; a third-party vulnerability assessment may be an option.
As reported in the Fraunhofer Institute paper, some of the data in the Apple-supplied iOS apps is not protected using the file protection facility, because it needs to be used by background services so potentially while the device is locked. This means that on finding a device lying around, such data is accessible to the attacker. However, business content such as mail attachments are not part of this data, and indeed Apple has upgraded the protection status of some of the data since the report was published. Whether data used in third-party apps is protected in such a way can again be discovered via assessing the app.
When data is protected, it can only be accessed (by any part of the OS including the kernel) once the user has entered the correct passcode, so the data protection is consistent with the passcode strength. The way in which iOS derives the protection key from the passcode removes the possibility of offline attacks, and forces online attacks to proceed at very slow rate (with the option of forcing data erasure after a number of failed attempts).
OK, so that's a non-jailbroken iPhone. Now let's consider the transition: how do I jailbreak an iPhone? The first option is deliberate manual jailbreak by the owner, which is the most likely route. In my experience the owner is not necessarily a technical user; they could have been told by a friend or colleague that jailbreaking gives them more control, or more apps via Cydia or similar. Most jailbreak documentation calls on the user to change the default root password, so in this case it is likely that the attacker doesn't know the root credentials for the phone.
The second option is a drive-by jailbreak, using e.g. a PDF vulnerability. This could be either deliberately initiated by the owner, or they could be coerced into visiting a vulnerable file sent for example as an e-mail. The way most jailbreaks work is to modify the bootloader to load a non-OEM kernel. This means that the jailbreak functionality won't be available until the user has rebooted the phone, at which point any unlock encryption keys have been thrown away.
The final option is that the phone is under the control of an attacker who then uses a manual jailbreak technique. This does not require that the attacker know the passcode. After jailbreaking the passcode will still be required to access protected data as the decryption key is derived from that passcode. To retrieve protected data, the attacker will need to return control of the jailbroken device back to the owner. Essentially the attacker needs exclusive access to the phone for around 15 minutes: I consider that unlikely; a social engineering attack (or straightforward theft-and-return) is a small possibility.
So what can be done with a jailbroken iPhone? Conventional wisdom says anything can be done, that the phone's operating system is now as open as a regular desktop OS; but let's consider the likelihood of various scenarios.
For a start, all of the risks associated with a non-jailbroken iPhone still exist.
Installing common third-party remote access or monitoring tools such as sshd can be achieved if they are part of the jailbreak OS image, if the attacker has a route to deploying them onto the phone (say while controlling the device in the last jailbreak route listed above) or if the user chooses or is coerced to install the tool. In the case of sshd, valid credentials for the phone, such as the default root password, must be known to the attacker. Because prepackaged builds of such tools exist, this attack does not require a clever or resourceful attacker. Because the sandboxing restrictions of the stock kernel are lifted for a jailbroken phone, the remote access tool can access all files in all apps - including protected files while the device is unlocked.
The attacker could, through similar mechanisms to that for installing stock tools, deploy special software such as a Trojan version of an existing app, or custom malware like event loggers and uploaders. This is a more technically-advanced version of the same attack, and because it doesn't really offer much benefit to the attacker over using standard tools I consider it much less likely. The (ab)use case for this attack would be where an app uses its own internal authentication and crypto protocols, and the attacker needs to acquire the user's in-app credentials or otherwise view the in-app content that never appears to the rest of the OS in a readable way.
So the conclusion is that there are more risks associated with jailbroken iPhones than stock iPhones: indeed the attack surface of a jailbroken phone is a superset of the attack surface of the stock phone. Is that important? As I said at the top, it depends on your users and your assets.
