Intel Software Guard Extensions (SGX) Is Mighty Interesting

I am in a bit over my head here, but take a look at the first two presentations at the Workshop on Hardware and Architectural Support for Security and Privacy. Intel is preparing to introduce a new capability in their processors to support use of secure encrypted memory spaces on commodity CPUs. Their objective is to provide applications with a secure ‘enclave’ (their term) with a protected memory and execution space. It’s called Intel Software Guard Extensions (SGX). This could be significant – especially for battling malware and cloud computing. Think secure key management in the cloud with hardware-enforced sandboxes on endpoints. Developers will need to code their software to use the feature, so this isn’t an overnight fix. However… It seems like a powerful tool to battle malware on endpoints, especially if operating system manufacturers leverage the capability in Windows and OS X to further improve their sandboxes. And imagine a version of Java or Flash that’s fully isolated. This could offer material improvements to hypervisor security – for example by eliminating memory parsing attacks. And encrypted memory should mean volatile memory (RAM) is even protected from cloud administrators trying to peek at encryption keys. HSM vendors should also keep an eye on this because it might offer comparable security to hardware-based key managers (but probably not for key generation and a few other important pieces, for those who need them). Think of virtual HSMs and key managers that run within the cloud, without the worry of keys being compromised in memory. It looks extremely interesting but I freely admit that some of it is over my head. But if I am reading right, the long-term potential to improve security is impressive. Share:

Read Post

FireStarter: KNOX vs. AZA mobile throwdown

A group of us were talking about key takeaways for the 2013 Cloud Identity Summit last week in Napa. CIS 2012 focused on getting rid of passwords; but the conversation centered on infrastructure and identity standards such as OAuth, OpenID Connect, and SAML, which provide tool to authenticate users to cloud services. 2013 was still about minimizing usage of passwords, but focused on the client side where the “rubber meets the road” with mobile client apps. Our discussion highlighted different opinions regarding the two principal models presented at the conference for solving single sign-on (SSO) issues for mobile devices. One model, the Authorization Agent (AZA) is an app that handles authentication and authorization services for other apps. KNOX is a Samsung-specific container that provides SSO to apps in the container. It’s heartening to hear developers stress that unless they get the end user experience right, the solution will not be adopted. No disagreement on that but buyers have other issues of equal importance, and I think we are going to see mobile clients embrace these approaches over the next couple years so it is worth discussing the issues in an open public forum. So I am throwing out the first pitch in this debate. Statement I believe the KNOX “walled garden” mobile app authentication model offers a serious challenge to Authorization Agents (AZA) – not because KNOX is technically superior but because it provides a marginally better user experience while offering IT better management, stronger security, and a familiar approach to mobile apps and data security. I expect enterprises to be much more comfortable with the KNOX approach given the way they prefer to to manage mobile devices. I am not endorsing a product or a company here – just saying I believe the subtle difference in approach is very important to the buyers. Problem User authentication on mobile devices must address a variety of different goals: a good user experience, not passing user IDs and passwords around, single sign-on, support for flexible security tokens, Two-Factor Authentication (2FA) or equivalent, and data security controls – just to name a few. But the priority is to provide single sign-on for corporate applications on mobile devices. Unfortunately the security model in most mobile operating systems is primarily intended to protect apps for other apps, so SSO (which must manage authentication for multiple other apps) is a difficult problem. Today you need to supply credentials for every app you use, and some apps require re-authentication whenever you switch between apps. It gets even worse if you use lengthy passwords and a password manager – the process looks something like this: You start the app you need to run, bounce over to the password manager, log into the password manager, grab credentials, bounce back to the original application, and finally supply credentials (hopefully pasting them in so you don’t forget or make an invisible typo). At best case it’s a pain in the ass. Contrasting Approaches Two approaches were discussed during CIS 2013. I will simplify their descriptions, probably at the expense of precision, so please comment if you believe I mischaracterized either solution. First, let’s look at the AZA workflow for user authentication: The AZA ‘agent’ based solution is essentially an app that acts as a gateway to all other (corporate) apps. It works a bit like a directory listing, available once the user authenticates to the AZA agent. The workflow is roughly: a. The app validates the user name and password (1.). b. The app presents a list of apps which have been integrated with it. c. The user selects the desired app, which requests authentication tokens from an authorization server (2.). d. The tokens enable the mobile application to communicate with the cloud service (Box, Evernote, Twitter, etc). If the service requires two-factor authentication the user may be provided with a browser-based token (3.) to supplement their username and password. e. The user can now use the app (4.). For this to work, each app needs to be modified slightly to cooperate with the AZA. KNOX is also an agent but not a peer to other apps – instead it is a container that manages apps. The KNOX (master) app collects credentials similarly to AZA, and once the container app is opened it also displays all the apps KNOX knows about. The user-visible difference is that you cannot go directly to a corporate app without first validating access to the container. But the more important difference for data security is that the container provides additional protection to its apps and stored data. The container can verify stack integrity, where direct application logins do not. KNOX also requires apps be slightly modified to work within in the container, but it does not require a different authentication workflow. User authentication for KNOX looks like this – but not on iOS: Rationale Both approaches improvement on standalone password managers, and each offers SSO, but AZA is slightly awkward because most users instinctively go directly to the desired app – not the AZA service. This is a minor annoyance from a usability standpoint but a major management issue – IT wants to control app usage and data. Users will forget and log directly into productivity apps rather than through the AZA if they can. To keep this from happening AZA providers need the app vendor to alter their apps to a) check for the presence of an AZA, b) force users through the AZA if present, and c) pass user credentials to the AZA. The more important issue is data security and compliance as drivers for mobile technologies. The vast majority of enterprises use Virtual Desktop Infrastructure (VDI) to manage mobile data and security policy, and the KNOX model mirrors the VDI model. It’s a secure controlled container, rather than a loosely-coupled federation of apps linked to an authorization agent. A container provides a clear control model which security organizations are comfortable with today. A loose confederation of applications cannot guarantee data security or policy enforcement the way containers can. One final point on buying centers: buyers do not look for the ‘best’

Read Post

Counterpoint: KNOX vs. AZA throwdown

Adrian makes a number of excellent points. Enterprises need better usability and management for mobile devices, but co-mingling these goals complicates solutions. Adrian contrasted two approaches: AZA and KNOX, which I also want to discuss. Let me start by saying I think we are in the first or second inning for mobile. I do not expect today’s architectural choices to stick for 10+ years. I think we will see substantial evolution, root and branch, for a while. Here is a good example of a mobile project: The Wall St. Journal just published their 1,000th edition on iPad. It is a great example of a mobile app, works in both offline and online modes, is easy to navigate and packed with information (okay – just ignore the editorial page) – it is a great success. The way they started the project is instructive: Three and a half years ago, The Wall Street Journal locked six people in a windowless room and threw down a secret challenge: Build us an iPad app. You have six weeks. And so we did. We started with a blank slate–no one had ever seen a tablet news app before. This is not uncommon for mobile projects. A few takeaways: We are learning our lessons as we go. There is an architectural vision but it evolves quickly and adapts, and did I mention we are leaning as we go? Evolution today is less about enterprise-level grand architecture (we already have those, called iOS and Android, themselves evolving while we scramble to keep up) – it is incremental improvement. Looking at AZA vs. KNOX from ground level, I see attractive projects for enterprise, with AZA more focused the here and now. KNOX seems to be shooting for DOD today, and enterprise down the road. This all reminds me of how Intel does R&D. They roll out platforms with a tick/tock pattern. Ticks are whole new platforms and tocks are incremental improvements. To me AZA looks like classic tock: it cleans up some things for developers, improves capabilities of existing systems, and connects some dots. KNOX is a tick: it is a new ballgame, new management, and a new way to write apps. That doesn’t mean KNOX cannot succeed, but would the WSJ start a new project by learning a new soup-to-nuts architecture just to handle security requirements (remember: you need to launch in six weeks)? I know we as security people wish they would, but how likely is that in the near term, really? The positive way to look at this choice is that, for a change, we have two interesting options. I may be overly pessimistic. It is certainly possible that soup-to-nuts security models – encompassing hardware, MAC, Apps, Platforms – will rule from here on out. There is no doubt plenty of room for improvement. But the phrase I keep hearing on mobile software projects is MVP: Minimum Viable Product. KNOX doesn’t fit that approach – at least not for most projects today. I can see why Samsung wants to build a platform – they do not want to be just another commoditized Android hardware manufacturer, undifferentiated from HTC or Googorola. But there is more to it than tech platforms – what do customers want? There is at least one very good potential customer for KNOX, with DOD-type requirements. But will it scale to banks? Will KNOX scale to healthcare, manufacturing, and ecommerce? That is an open question, and app developers in those sectors will determine the winner(s). Share:

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.