Research

Continuing our series on iOS data security, we need to take some time to understand how data moves onto and around iOS devices before delving into security and management options. Data on iOS devices falls into one of a few categories, each with different data protection properties. For this discussion we assume that Data Protection is enabled, because otherwise iOS provides no real data security. Emails and email attachments. Calendars, contacts, and other non-email user information. Application data When the iOS Mail app downloads mail, message contents and attachments are stored securely and encrypted using Data Protection (under the user’s passphrase). If the user doesn’t set a passcode, the data is stored along with all the rest of user data, and only encrypted with the device key. Reports from forensics firms indicate that Data Protection on an iPad 2 or iPhone 4S (or later, we presume) running iOS 5 cannot currently be cracked, by other than brute force. Data Protection on earlier devices can be cracked. Assuming the user properly uses Data Protection, mail attachments viewed with the built-in viewer app are also safe. But once a user uses “Open In…”, the document/file is moved into the target application’s storage sandbox, and may thus be exposed. When a user downloads an email and an attachment, and views them in the Mail app, both are encrypted twice (once by the underlying FDE and once by Dat Protection). But when the user opens the document with Pages to edit it, a copy stored in the Pages store, which does not use Data Protection – and the data can be exposed. This workflow is specific to email – calendars, contacts, photos, and other system-accessible user information is not similarly protected, and is generally recoverable by a reasonably sophisticated attacker who has physical possession of the device. Data in these apps is also available system-wide to any application. It is a special class of iOS data using a shared store, unlike third-party app data. Other (third party) application data may or may not utilize Data Protection – this is up to the app developer – and is always sandboxed in the application’s private store. Data in each application’s local store is encrypted with the user’s passcode. This data may include whatever the programmer chooses – which means some data may be exposed, although documents are nearly always protected when Data Protection is enabled. The programmer can also restrict what other apps a given document is allowed to open in, although this is generally an all or nothing affair. If Data Protection isn’t enabled, all data is protected only with the device’s default hardware encryption. But sandboxing stil prevents apps from accessing each other’s data. The only exception is files stored in a shared service like Dropbox. Apps which access dropbox still store their local copies in their own private document stores, but other apps can access the same data from the online service to retrieve their own (private) copies. So application data (files) may be exposed despite Data Protection if the app supports “Open In…”. Otherwise data in applications is well protected. If a network storage service is used, the data is still protected and isolated within the app, but becomes accessible to other compatible apps once it is stored on a server. This isn’t really a fault of iOS, but this possibility needs to be considered when looking at the big picture. Especially if a document is opened in a Data Protection enabled app (where it’s secure), but then saved to a storage service that allows insecure apps to access it and store unencrypted copies. Thus iOS provides both protected and unprotected data flows. A protected data flow places content in a Data Protection encrypted container and only allows it to move to other encrypted containers (apps). An unprotected flow allows data to move into unencrypted apps. Some kinds of data (iOS system calendars, contacts, photos, etc.) cannot be protected and are always exposed. On top of this, some apps use their own internal encryption, which isn’t tied to the device hardware or the user’s passcode. Depending on implementation, this could be more or less secure than using the Data Protection APIs. The key, from a security perspective, is to understand how enterprise data moves onto the device (what app pulls it in), whether that app uses Data Protection or some other form of encryption, and what other apps that data can move into. If the data ever moves into an app that doesn’t encrypt, it is exposed. I can already see I will need some diagrams for the paper! But no time for that now – I need to get to work on the next post, where we start digging into data security options… Share:

We are happy to announce a new series, where for the first time we will research and document the issues around privileged user management (PUM). It may not sound as exciting as cloud anything, or iOS data protection, but it’s something you overlook at your own risk. Because administrators (those privileged users) have the keys to your kingdom. A sysadmin with malicious intent can cause a very bad day for you and your organization. And no, this isn’t just another recycled attempt to bring the insider threat back into vogue – much to the chagrin of the DLP vendors, who drove their first wave of growth based on the nebulous insider threat. First of all, privileged users (P-users) don’t necessarily need to be insiders. And most insiders have limited access and authorization entitlements, while administrators can basically giving themselves access to do whatever they want. That old privilege escalation thing. That’s why we are calling this series Watching the Watchers – because if not properly managed, administrators are Above the Law. Business Imperatives Changing Privileges We live in a brave new world of technology. What used to be within your site, in your data center, or running on your big iron, now may or may not be in any or all of those places. Even if your stuff runs in your data center you might not know exactly where and it may not be in your control. It may or may not be running on an operating system you understand. You may or may not control the pipes that lead to that data. And you certainly can’t tell business users and/or business partners that they need to go back to the old model, where you had visibility from the bare metal all the way to the data layer. Times have changed. Even better, you might not even know who is responsible for managing those specific systems. With layers of virtualization abstracting pretty much all physical networks, storage, and servers, there are many different folks responsible for managing the pieces of what we call an application. Even the term ‘application’ is really a misnomer – applications can be almost anything, processing anywhere, accessing data from anywhere, and presenting information to anyone, anywhere. Times sure have changed. So let’s start by defining what a privileged user is. Privileged User: Anyone with admin (or root) access to a device. Based on that definition, every user is a privileged user to some device. That’s a bit broad, so we’ll restrict our discussion (and this research) to users who manage critical devices – running applications, hosting databases, or pushing packets to the places they need to be. Sure, it’s problematic if the P-user in charge of the receptionist’s device (the receptionist) is compromised. But it’s much more serious if someone who can administer the device hosting your customer database gets owned. Let’s get a bit more specific about the business drivers and the impact on privileged users: Reduce Cost – Virtualization/Cloud: Many organizations are under dramatic pressure to continue reducing costs wherever possible. That means embracing technologies like virtualization to make better use of physical hardware, and cloud computing to make better use of data center real estate. The impact of this driver is scale. Now you have a lot more things to manage and they can be spun up and torn down at the click of a button or via script. Throw in the unbounded number of instances that can be run in the public cloud, and the only thing you can be sure of is a massive change management headache. Reduce Cost – Outsource: While data centers are virtualizing, organizations are contracting with (lower) cost management to do their (alleged) commodity work. You know, like managing databases and email. All kidding aside, it’s common to see third parties manage wide swaths of an organizations’ IT infrastructure – providing nameless, faceless folks (perhaps on the other end of a SAML link) with access to critical stuff. Agility – New Apps: If you think about a typical web app, it’s more ‘assembled’ nowadays than built from the ground up. And parts may be yours, they could be pieces you got from someone else, or they might include data from somewhere else, integrated into your environment via a foreign API. It’s hard to know what an application is nowadays. And if we don’t know what it is it’s generally difficult to manage. Yes, there are more business drivers, but you get the picture. Anyone with access to manage a device that runs something important (or is a component of something important) is a privileged user, and the change management issues inherent in this escalating complexity requires that administrators continue to become more efficient and leveraged. Which can result in errors, shortcuts, and general violation of good operational practices. Now let’s look at some specific threats these privileged users present. P-User Risk Assessment Yeah, we’re old school. We still like to assess risk, or at least run through a quick mental exercise to figure out how many ways we can get killed. So let’s do that with this explosion of devices managed by privileged users. Of course this isn’t an exhaustive list – more a back of the envelope exercise to uncover some of the biggest threats to our environment if these privileged users are compromised. And while we are at it, let’s define a new term, PUPwnage, for a compromised privileged user. Just rolls off the tongue, right? Compromised devices: This one is obvious. If a privileged user is compromised (PUPwned), the attackers gain access to any device they manage, and then the fun begins. Data leakage: PUPwnage can result in any and all data being stolen from the devices they control. Create accounts: PUPwnage allows attackers to create both user and admin accounts on devices, and to pivot through the environment, moving from one compromised device to another – stealing data thefts as they march along. Pollute applications and/or data: PUPwnage also results in application attacks, such as changing code to break functionality, creating backdoor access, deleting or changing data, or otherwise breaking your applications.