Data Flow on iOS

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:

Read Post

Watching the Watchers: Access to the Keys (to the Kingdom)—New Series

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.

Read Post

Totally Transparent Research is the embodiment of how we work at Securosis. It’s our core operating philosophy, our research policy, and a specific process. We initially developed it to help maintain objectivity while producing licensed research, but its benefits extend to all aspects of our business.

Going beyond Open Source Research, and a far cry from the traditional syndicated research model, we think it’s the best way to produce independent, objective, quality research.

Here’s how it works:

  • Content is developed ‘live’ on the blog. Primary research is generally released in pieces, as a series of posts, so we can digest and integrate feedback, making the end results much stronger than traditional “ivory tower” research.
  • Comments are enabled for posts. All comments are kept except for spam, personal insults of a clearly inflammatory nature, and completely off-topic content that distracts from the discussion. We welcome comments critical of the work, even if somewhat insulting to the authors. Really.
  • Anyone can comment, and no registration is required. Vendors or consultants with a relevant product or offering must properly identify themselves. While their comments won’t be deleted, the writer/moderator will “call out”, identify, and possibly ridicule vendors who fail to do so.
  • Vendors considering licensing the content are welcome to provide feedback, but it must be posted in the comments - just like everyone else. There is no back channel influence on the research findings or posts.
    Analysts must reply to comments and defend the research position, or agree to modify the content.
  • At the end of the post series, the analyst compiles the posts into a paper, presentation, or other delivery vehicle. Public comments/input factors into the research, where appropriate.
  • If the research is distributed as a paper, significant commenters/contributors are acknowledged in the opening of the report. If they did not post their real names, handles used for comments are listed. Commenters do not retain any rights to the report, but their contributions will be recognized.
  • All primary research will be released under a Creative Commons license. The current license is Non-Commercial, Attribution. The analyst, at their discretion, may add a Derivative Works or Share Alike condition.
  • Securosis primary research does not discuss specific vendors or specific products/offerings, unless used to provide context, contrast or to make a point (which is very very rare).
    Although quotes from published primary research (and published primary research only) may be used in press releases, said quotes may never mention a specific vendor, even if the vendor is mentioned in the source report. Securosis must approve any quote to appear in any vendor marketing collateral.
  • Final primary research will be posted on the blog with open comments.
  • Research will be updated periodically to reflect market realities, based on the discretion of the primary analyst. Updated research will be dated and given a version number.
    For research that cannot be developed using this model, such as complex principles or models that are unsuited for a series of blog posts, the content will be chunked up and posted at or before release of the paper to solicit public feedback, and provide an open venue for comments and criticisms.
  • In rare cases Securosis may write papers outside of the primary research agenda, but only if the end result can be non-biased and valuable to the user community to supplement industry-wide efforts or advances. A “Radically Transparent Research” process will be followed in developing these papers, where absolutely all materials are public at all stages of development, including communications (email, call notes).
    Only the free primary research released on our site can be licensed. We will not accept licensing fees on research we charge users to access.
  • All licensed research will be clearly labeled with the licensees. No licensed research will be released without indicating the sources of licensing fees. Again, there will be no back channel influence. We’re open and transparent about our revenue sources.

In essence, we develop all of our research out in the open, and not only seek public comments, but keep those comments indefinitely as a record of the research creation process. If you believe we are biased or not doing our homework, you can call us out on it and it will be there in the record. Our philosophy involves cracking open the research process, and using our readers to eliminate bias and enhance the quality of the work.

On the back end, here’s how we handle this approach with licensees:

  • Licensees may propose paper topics. The topic may be accepted if it is consistent with the Securosis research agenda and goals, but only if it can be covered without bias and will be valuable to the end user community.
  • Analysts produce research according to their own research agendas, and may offer licensing under the same objectivity requirements.
  • The potential licensee will be provided an outline of our research positions and the potential research product so they can determine if it is likely to meet their objectives.
  • Once the licensee agrees, development of the primary research content begins, following the Totally Transparent Research process as outlined above. At this point, there is no money exchanged.
  • Upon completion of the paper, the licensee will receive a release candidate to determine whether the final result still meets their needs.
  • If the content does not meet their needs, the licensee is not required to pay, and the research will be released without licensing or with alternate licensees.
  • Licensees may host and reuse the content for the length of the license (typically one year). This includes placing the content behind a registration process, posting on white paper networks, or translation into other languages. The research will always be hosted at Securosis for free without registration.

Here is the language we currently place in our research project agreements:

Content will be created independently of LICENSEE with no obligations for payment. Once content is complete, LICENSEE will have a 3 day review period to determine if the content meets corporate objectives. If the content is unsuitable, LICENSEE will not be obligated for any payment and Securosis is free to distribute the whitepaper without branding or with alternate licensees, and will not complete any associated webcasts for the declining LICENSEE. Content licensing, webcasts and payment are contingent on the content being acceptable to LICENSEE. This maintains objectivity while limiting the risk to LICENSEE. Securosis maintains all rights to the content and to include Securosis branding in addition to any licensee branding.

Even this process itself is open to criticism. If you have questions or comments, you can email us or comment on the blog.