Re: [P1619-3] OASIS EKMI Article in InformationWeek

[Arshad Noor <arshad.noor@strongauth.com>]

Hi Luther,

Please see responses embedded in your message below.

Arshad

Luther Martin wrote:
> I'm not sure that I buy this (Arshad's) vision of the future of key management. The place where I've seen customers asking for a key management solution right now is in the area of key management for storage. Lost storage is currently the single biggest cause of data breaches, so your favorite optimization technique will show that that's where most of the resources should be spent: the last numbers that I saw estimated that over 75 percent of identities compromised were compromised because of lost storage.
> 

  I'm not so sure about the percentages.  The three largest data-breaches
  I know of are TJX (94M records), CardSystems (40M) and Hannaford (4.2M)
  out of a total of estimated 230M identity-theft incidents.
  (http://www.privacyrights.org/)

  All three breaches were from live, on-line systems (one of them is even
  rumoured to have been using DB encryption with the decryption key
  sitting in the same DB as the ciphertext).  Collectively, they make up
  60% of reported breached records.  So, I'm not sure where the 75%
  number from lost-storage comes from.

> And because this market will probably be the first place where lots of key management products are sold, we'll probably find that it's storage vendors who will be the incumbents in that market when more general uses of key management start to get more attention. So if key management products for storage devices can easily be used for more general enterprise key management, I believe that the storage vendors are well positioned to win a significant fraction of that market. This is why I'm involved in P1619.3 but not in OASIS EKMI.
> 
> The claims of needing encryption to be regulatory compliant are also a bit misleading. You certainly need encryption per PCI DSS 2.0, but that's one of few cases where you actually do. In HIPAA, for example, all you're required to do is to address the issue in some way. Encryption is one way, but many other cheaper and easier alternatives exist. With other regulations, you similarly have to protect information, not encrypt it. If you look at the public comments during the drafting of many of the US laws, you'll see this mentioned explicitly. "Are you saying that this will require us to encrypt data?" "No, we're just saying that you have to protect it in some way." As an ex-auditor (from my days at Ernst & Young), I'm not sure that you'll have much luck with convincing the auditors in ISACA that their clients really need encryption in many cases.
> 

   I'm not suggesting that ISACA Auditors are going to tell their clients
   that they need encryption.  That's not what Auditors are supposed to
   do.  I'm stating that we're planning on educating ISACA Auditors about
   EKMI and training them to ask the right questions about mitigating
   data-breach risks.  Their clients are going to make the appropriate
   decisions to manage the risks that the ISACA Auditors highlight.


> And while it's certainly possible to have data breaches at different levels of the encryption stack that you've drawn (I use a similar picture, but with fewer layers to keep it simpler), I believe that the reality is that encryption at the higher levels won't become a pressing issue until the storage issue is addressed. There's so much personal data out there from data breaches that the street price of a full identity can be as low as $1 these days. The hackers going after data are now criminals engaged in for-profit activities. They can either do lots of work and get less data by attacking at the higher levels in the encryption stack of they can get more data by going after the lower levels. So just like Willie Sutton said that he robbed banks "because that's where the money is," today's hackers target storage because that's where the data is. If a hacker can make more off a single backup tape that he can from a lifetime of snooping at the application layer, where is he go
ing to focus his efforts?
> 

   I am not disputing that there is a short-medium term need to encrypt
   data-at-rest at the storage layer.  If a company has the ability to do
   it now in their application layer, I recommend they to do it.  Where
   they have to wait for an ISV to deliver that capability, I tell them
   to ask their ISV to deliver the capability, and that they take other
   shot-term measures to mitigate their risks.  Storage, OS and DB-based
   encryption are all options for the short-term.

> I'm also not sure that XML is the way to go. A small subset of XML perhaps, but nothing as full-featured as SKSML. The talk that Tim Bray (co-editor of XML 1.0) gave at the December 2007 IETF meeting (http://www.ietf.org/proceedings/07dec/slides/xmltut-0.pdf) summarizes far more eloquently that I ever could why this is true. The experience of Tim and the others in the IETF is that XML has its place, but it's not in most protocols.
> 

   I've documented the reasons why I preferred XML in my ACM paper,
   (http://middleware.internet2.edu/idtrust/2008/papers/07-noor-ekmi.pdf)
   so I won't repeat them here.  I had to make a choice; XML was it, and
   it has worked for me so far.

   WRT the features of SKSML, these were originally driven by business
   use-cases and Security Officers.  The DRAFT 6.0 version is based on
   input from many TC members - all documented at the OASIS website in
   the mail-archives.

> It's clear what Arshad's thoughts are in this area. Does anyone else have anything that they'd like to add?
> 

   I'm sorry that we see things differently, Luther.  I think we're all
   working towards the same end-goal; our approaches are the only thing
   that's different.  But, as the French are so fond of saying: "vive le
   difference".

Arshad Noor
StrongAuth, Inc.

> ________________________________________
> From: Arshad Noor [arshad.noor@strongauth.com]
> Sent: Tuesday, July 01, 2008 6:33 PM
> To: Luther Martin
> Cc: P1619-3@LISTSERV.IEEE.ORG; ekmi; Ramon Krikken; Trent Henry; Eric Maiwald; jon.oltsik@enterprisestrategygroup.com
> Subject: Re: [P1619-3] OASIS EKMI Article in InformationWeek
> 
> [Note:  The protocol used within a Symmetric Key Management System
> (SKMS) - one of two major components of an EKMI (the other being a
> PKI) - is the Symmetric Key Services Markup Language (SKSML).]
> 
> To date, there is only one implementation of the DRAFT 1 version of
> the SKSML protocol (an open-source implementation called StrongKey,
> produced by our company and available at www.strongkey.org).
> 
> The protocol, after much discussion within the OASIS TC over the
> last 18 months, is at DRAFT 6 and is scheduled to be released to the
> general internet for review and comments within the next 10-14 days
> (it is under ballot within the committee as we speak).
> 
> While confidentiality agreements with our customers preclude us from
> mentioning where it is being used, I will point you to some publicly
> available statistics on the number of downloads of StrongKey at
> SourceForge.net:
> 
> http://sourceforge.net/search/?type_of_search=soft&type_of_search=soft&words=strongkey
> 
> If we assume that a mere 2-3% of the downloads are in use, that makes
> 30-45 EKMI's using the DRAFT 1 protocol.  Not much, I agree, when you
> compare it to the millions of downloads of software like the JDK,
> Apache, JBoss, etc.; but we're talking about a paradigm-shift in
> cryptographic key management here - a highly specialized niche - so
> it will take time to register.
> 
> I will also point you to the OASIS EKMI TC home-page, where you can
> see the publicly-visible supporters of the protocol, which includes:
> 
> - CA
> - FundServ (a Canadian company)
> - MISMO (the Mortgage Industry Association in the US)
> - PrimeKey (a Swedish company)
> - Red Hat
> - the US Department of Defense
> - Wave Systems and
> - Wells Fargo.
> 
> What is not visible - unless you are an OASIS member - is that two
> of the three largest software companies in the world, two of the three
> largest security software companies in the world, and two very large
> consulting firms, are all Observers on the Technical Committee.
> 
> While the number of EKMI TC members certainly is smaller than the
> 1619.3 WG, there is a broader acceptance across business sectors for
> the vision of EKMI.
> 
> Given this, I would like to make a suggestion to the storage vendors
> in the P1619.3 WG.  (Please don't shoot the messenger because of the
> unpopularity of this message I'm about to give) :-).
> 
> It is my personal belief that the market for storage-device based
> encryption will dry up within 3-5 years.  Why?  Because of the
> following:
> 
> An application stack on a running server resembles something like the
> following diagram (I've simplified it for brevity - real applications
> typically have more layers in the stack):
> 
> +-----------------------+
> |   Application Layer   |  <-- Focus of OASIS EKMI TC efforts
> +-----------------------+
> |   Network Layer       |
> +-----------------------+
> |   Web-server Layer    |
> +-----------------------+
> |   Application Server  |
> +-----------------------+
> |   Database Layer      |
> +-----------------------+
> |   Operating System    |
> +-----------------------+
> |   Storage Device      |  <-- Focus of IEEE P1619.3 WG efforts
> +-----------------------+
> 
> While transparently encrypting/decrypting data as it goes in and out
> of the storage device makes it easy for enterprises in the short-term,
> it does not protect them from attacks on plaintext in any of the layers
> above the storage device.  The only threat that encrypted storage
> devices protect against is, theft.
> 
> For an always-on, operational system in a data-center, this is an
> insufficient counter-measure against data-breaches, since an attacker
> may be reading plaintext at ANY of the layers above the storage device
> and land the company on the front-pages of the Wall Street Journal and
> CNN in spite of the encrypted storage device.
> 
> This is not to say that the OASIS effort eliminates the problem - it
> does not.  However, it minimizes the attack-surface to the minimum
> possible target, and allows the enterprise to not have to duplicate
> protecting data in any of the layers below the application layer.
> 
> Given that many application developers already have to protect their
> applications from X-site scripting, SQL Injection, and a host of new
> application-specific vulnerabilities, adding encryption to the list
> of things to do is going to become a formality.
> 
> The OASIS effort is also planning on educating IT Auditors through
> ISACA about potential vulnerabilities in the stack (as shown above),
> so ignorance on the part of developers/managers will not be an excuse
> for too long if they want to comply with SOX, GLBA, PCI-DSS, HIPAA,
> FISMA, PIPEDA, EU Directive, etc.
> 
> It is my belief that once ISVs and customers recognize this problem,
> they will start modifying their applications to encrypt data at the
> application layer.  Once we're past the tipping-point on that, there
> will be little need for duplicating encryption on storage-devices.
> 
> Notwithstanding this, I believe there is a place for the P1619.3
> protocol in the short-medium term - it is to take the keys and polices
> supplied by an EKMI and push it down to the storage devices for
> storage-based encryption in the intervening years before applications
> encrypt data directly.  Towards that end, what is needed is a compact
> binary protocol that can be used between the Management Console of the
> Storage environment and the storage device itself, while the MC itself
> becomes an EKMI client and uses the SKSML protocol to get the keys
> and policies.
> 
> It is my belief that the WS-MAN based XML protocol being worked on by
> the P1619.3 WG will create confusion in the marketplace.  While this
> will serve the key-management vendors in the WG (who are not members
> of the OASIS effort), it neither serves the industry nor the storage
> vendors.
> 
> Since the market for encrypted storage-devices is not a long-lived one,
> how much effort do storage vendors want to put into building XML-based
> protocols, libraries, tools and MC applications, when another effort has
> reasonable acceptance and traction, and can be easily used to meet the
> goals of the storage industry?  If storage-industry budgets allow for
> duplicating the OASIS work and dealing with the mixed-marketing messages
> that customers receive, that's a different issue.  However, if you want
> to optimize your investments while making the most of the opportunity
> that presents itself over the next 3-5 years, then it makes sense to do
> the minimum necessary work on the binary protocol and use the OASIS
> XML-based protocol where it makes sense.
> 
> Arshad Noor
> StrongAuth,Inc.
> 
> Luther Martin wrote:
>> How many vendors have implemented EKMI? Are there any users of it? Knowing how it has succeeded or failed might provide some particularly useful insights for P1619.3.
>>
>> ________________________________
>> From: Gary Palgon [gpalgon@NUBRIDGES.COM]
>> Sent: Tuesday, July 01, 2008 7:22 AM
>> To: P1619-3@LISTSERV.IEEE.ORG
>> Subject: [P1619-3] OASIS EKMI Article in InformationWeek
>>
>> Oasis' open Enterprise Key Management Infrastructure initiative promises less-complex encryption. But will vendors get on board?
>>
>> http://www.informationweek.com/shared/printableArticle.jhtml?articleID=208800937
>>
>>
>> Gary Palgon
>> VP Product Management
>> gpalgon@nubridges.com<UrlBlockedError.aspx>
>> nuBridges, Inc.  |  1000 Abernathy Road  |  Suite 250  |  Atlanta GA USA 30328
>> Tel:  +1 770 730 3592  |  Fax:  +1 770 730 3784
>>
>> www.nubridges.com<http://www.nubridges.com>
>> The Secure eBusiness Authority