Voltage Security http://www.voltage.com Wed, 01 Oct 2014 00:56:15 +0000 en-US hourly 1 Voltage Comments on Apple Pay http://www.voltage.com/blog/payments/voltage-comments-apple-pay/ http://www.voltage.com/blog/payments/voltage-comments-apple-pay/#comments Thu, 18 Sep 2014 00:06:16 +0000 http://www.voltage.com/?p=6189 […]

The post Voltage Comments on Apple Pay appeared first on Voltage Security.

With the new Apple Pay announcement, Apple validates the data-centric security model and shines a spotlight on the need for the payment world to move on from vulnerable static credit card numbers and magnetic stripes to protected versions of data such as tokenized or EMV style authenticated payments.

With this data-centric security strategy, as applied to mobile-originated payment transactions, Apple Pay may help reduce risk of data breaches and credit card theft.- However, payment ecosystems will have mixed traditional card payments and new restricted use payment tokens and a variety of wallets, such as Host Card Emulation varieties (HCE). To avoid any risk from advanced threats, merchants should continue to protect all transaction data unilaterally, given the likely mix of older at risk data, and less risky, but still potentially valuable payment tokens in transaction flows. This is already easily achievable with current data-centric security solutions, such as Voltage SecureData.

The retail world today is still in an early adoption phase with regard to new payment methods and mobile wallets. US based retailers in particular still have to contend with EMV upgrades, legacy mag-stripe data, card-not-present e-commerce capture and a variety of advanced threats. Merchants will also need to update their retail infrastructure to accept Apple Pay, and likely many other wallet schemes. Thus for many years, legacy static credit and debit cards, EMV cards and newer schemes like Apple’s will need to co-exist, and advanced threats across all of them need to be mitigated to avoid continued breaches and customer data exposure.

Fortunately, even with exciting innovation like Apple Pay, mixed payment environments and credit card data can be secured end-to-end, from the point of card/wallet read to the secure payment host, with Voltage’s contemporary encryption solutions and advanced tokenization technology. This enables retailers to accept new and old payment approaches, all protected under a unified data-centric protection framework, to thwart advanced threats and protect customer data while ensuring a seamless, yet secured, customer experience.

Contact us here for more information or to talk to one of our data-centric security experts.

The post Voltage Comments on Apple Pay appeared first on Voltage Security.

http://www.voltage.com/blog/payments/voltage-comments-apple-pay/feed/ 0
Securing Hadoop: What are Your Options Webinar by Hortonworks / Voltage http://www.voltage.com/blog/voltage/securing-hadoop-options-webinar-hortonworks-voltage/ http://www.voltage.com/blog/voltage/securing-hadoop-options-webinar-hortonworks-voltage/#comments Tue, 09 Sep 2014 21:18:16 +0000 http://www.voltage.com/?p=6140 […]

The post Securing Hadoop: What are Your Options Webinar by Hortonworks / Voltage appeared first on Voltage Security.

Thanks to all who joined us on our Hortonworks/Voltage webinar, “Securing Hadoop: What are Your Options?”  For those who couldn’t attend, we’re sorry we missed you.  We’ve included a link to the webinar recording below, and we hope you can listen in!   On the webinar, Hortonworks’ Vinod Nair presented the recently-announced Apache Argus incubator: a central policy administration framework across security requirements for authentication, authorization, auditing and data protection.  Sudeep Venkatesh, of Voltage Security, defined data-centric protection technologies that easily integrate with Hive, Sqoop, MapReduce and other Hadoop interfaces.


A number of questions were asked on the webinar—here are a few:

Q: How far has Hortonworks come in development for Windows?

  • With HDP 2.1, the code lines for Windows and Linux for HDP Stack components have converged. HDP 2.1 is supported on Linux and Windows. The few functional gaps are being addressed in the near term. Details can be found at http://hortonworks.com/hdp/.

Q: Are you going to support OAuth for authorizing a resource in Argus?

  • Support for OAuth as a means of authenticating a user will be made available in a future release of HDP as part of Apache Knox.  The authorization framework in Apache Argus covers fine-grained access control for HDFSHBase and Hive in HDP 2.1.
Q: If data is protected at rest, using a data-centric encryption approach like those offered by Voltage,  will that data  still be encrypted when it travels through the network?

  • Yes, this is one of the benefits: with Voltage’s format-preserving technologies, sensitive data that is protected remains protected even as it transits the network, and also as it is used (and often can be used in analytics in its protected form).


Listen Now!  Link to the recording

Stay Connected:

Hortonworks: http://hortonworks.com/blog/

Voltage: http://www.voltage.com/

The post Securing Hadoop: What are Your Options Webinar by Hortonworks / Voltage appeared first on Voltage Security.

http://www.voltage.com/blog/voltage/securing-hadoop-options-webinar-hortonworks-voltage/feed/ 0
Regarding the Recent Supreme Court Rulings http://www.voltage.com/blog/miscellaneous/regarding-recent-supreme-court-rulings/ http://www.voltage.com/blog/miscellaneous/regarding-recent-supreme-court-rulings/#comments Wed, 02 Jul 2014 21:28:25 +0000 http://www.voltage.com/?p=6086 […]

The post Regarding the Recent Supreme Court Rulings appeared first on Voltage Security.

Recently the Supreme Court issued several rulings that will help stem the tide of lawsuits filed by patent trolls. Please go here to read the rulings.

Likely nervous about this, Protegrity’s law firm  issued a press release which was a misleading and incorrect attempt at characterizing our recent settlement with their client.

Please go here to read the original Voltage blog post on the Voltage/Protegrity settlement.

The post Regarding the Recent Supreme Court Rulings appeared first on Voltage Security.

http://www.voltage.com/blog/miscellaneous/regarding-recent-supreme-court-rulings/feed/ 0
Data Breaches – Lognormal Distribution? http://www.voltage.com/blog/breach/data-breaches-lognormal-distribution/ http://www.voltage.com/blog/breach/data-breaches-lognormal-distribution/#comments Wed, 11 Jun 2014 20:33:31 +0000 http://www.voltage.com/?p=6029 […]

The post Data Breaches – Lognormal Distribution? appeared first on Voltage Security.

As I have noted before, the size of data breaches seems to closely follow a lognormal distribution. But if you spend a while collecting all that’s available about the breaches from last year and start writing R programs to analyze it, you soon find that this does not seem to be true anymore.

But if you plot the data, a reasonable explanation seems to appear: while lots of the data fits a lognormal model fairly well, there is very little information about very small breaches. This is not really too surprising. When data breaches were not as common as they are now, people might have been more diligent about reporting every breach, even if it exposed a few records. But now, it is probably the case that nobody really cares about the micro-breaches, so they are essentially not reported.

But in any case, here is a graph that summarizes the 2013 breaches that I could easily find information about. The grey bars represent the actual breaches while the blue line shows a lognormal model for the data. The two seem to agree fairly well, except for the very small breaches, where I could not find any such breaches reported, so I would guess that the same model is still fairly accurate today.


The post Data Breaches – Lognormal Distribution? appeared first on Voltage Security.

http://www.voltage.com/blog/breach/data-breaches-lognormal-distribution/feed/ 0
Cryptography for Mere Mortals #12 http://www.voltage.com/blog/pci/cryptography-mere-mortals-12/ http://www.voltage.com/blog/pci/cryptography-mere-mortals-12/#comments Tue, 10 Jun 2014 17:34:31 +0000 http://www.voltage.com/?p=6005 […]

The post Cryptography for Mere Mortals #12 appeared first on Voltage Security.

An occasional feature, Cryptography for Mere Mortals attempts to provide clear, accessible answers to questions about cryptography for those who are not cryptographers or mathematicians.

Passwords, part 1

Q: Why does it seem like after every website hack, we’re told both “We don’t believe passwords were compromised” and “You should change all your passwords”?

A: “It’s complicated”—the answer has multiple facets.

First, remember that the word “believe” is in there: the company doesn’t want to say “Your password is absolutely safe”, because, as we’ve learned repeatedly, the facts surrounding a breach tend to evolve. So even if the first indications are that there was essentially no risk—say, the passwords were hashed with a salt and then stored in an database protected with strong encryption, and the breach was that someone stole a laptop containing the encrypted database—it might turn out later that things weren’t as secure as believed (the laptop’s owner finally admits that there “um, might be a Post-It in the bag with the machine that has the database password on it…and oh, yeah, we also discovered that the update to salt the passwords didn’t ‘take’, so they’re just hashed…”).

Second, by now the public expects to hear “Reset your password” after a breach, if anything vaguely resembling passwords was involved. Thus the concern is that it would sound unconvincing to say “Oh, no, don’t worry, your passwords are safe, honest, trust us!”—especially when you consider that the biggest post-breach problem the victim is usually worried about is contained in that word “trust”: the stolen data is stolen, gone, nothing they can do about it except figure out how it happened and keep that from happening again; what they need to do is convince their customers that it’s OK to continue doing business with them.

Third, we all know that changing passwords periodically is a good idea anyway and that we don’t do it often enough (except for those sites that force us to, and we grumble when they do so). So when LinkedIn gets breached and everyone is told “Change your passwords”, the folks who don’t use LinkedIn ignore the advice; but then when eBay gets hit, a bunch more will respond. So the net is that more people get around to changing their passwords, which is a public good.

The risk, of course, is “breach fatigue”: that people hear this so often that they stop paying any attention to news about breaches, and never change their passwords!

And of course if Voltage SecureData is used, then the cost of a data breach is minimized—persistently protected data is of no value to an attacker, and in fact does not trigger breach notification requirements in most cases.

The post Cryptography for Mere Mortals #12 appeared first on Voltage Security.

http://www.voltage.com/blog/pci/cryptography-mere-mortals-12/feed/ 0
Eight Best Practices for Private Email Communications http://www.voltage.com/blog/security/eight-best-practices-private-email-communications-2/ http://www.voltage.com/blog/security/eight-best-practices-private-email-communications-2/#comments Mon, 02 Jun 2014 22:01:57 +0000 http://www.voltage.com/?p=5996 […]

The post Eight Best Practices for Private Email Communications appeared first on Voltage Security.

Earlier this month, Voltage Security hosted a webinar entitled “Rethinking Email Security: Eight Tips For Private Email Communications”.  The webinar was positively received by the all those who attended. Below we share the link to the full webinar recording, and excerpts from the content.

With the ongoing concerns about enterprise privacy, and the pervasiveness of email communications, these eight tips are more timely than ever!

 Full webinar recording can be found here.

 1. End to End is a Must: Ensure data is protected while at rest and in transit. By shifting focus to protecting the data itself, it will be secured persistently, wherever it goes. Email Encryption solutions that rely on two or more different encryption technologies inevitably end up splitting messages at some point in the mail flow, creating security gaps and allowing room for data to be compromised. A single, streamlined solution – based on a single technology for all use cases – ensures that data is protected persistently. In recent months, many organizations have been migrating to an email service in the cloud, where it is critical that sensitive information must be encrypted before it enters the cloud, protecting it from access by IT operations and breaches.

2. Don’t Hinder ComplianceEncryption does not have to break, or require extensive additional infrastructure for, compliance scanning, archiving, and e-discovery. The ability to roll out encryption while still maintaining critical features such as archiving, eDiscovery, DLP, and email hygiene scanning is a must. Your solution should be able to encrypt and decrypt messages based on compliance and mail routing policies, and should offer lightweight tools and plugins to support existing archiving and e-discovery business processes.

3. Stateless Critical for Simplified Operations: Deploy a solution that is stateless, with no certificates or keys to manage, ensuring lower infrastructure and operational costs. Keys can be generated dynamically, on demand when they are needed, eliminating the need to keep and maintain a key store. With a stateless solution, the need for keys or certificates to be backed up and replicated across servers is eliminated, providing infinite scalability. Additionally, disaster recovery should be as simple as taking a one-time backup of the master secret, which can then be used to easily recreate a new key server that can generate keys for past and future messages – with no loss of data.

4. One Encryption Technology  IBE: Deploy a single encryption technology that can work across all use cases and all end points, whether that is a desktop, mobile device, smart phone, tablet, or web browser. Voltage Identity-Based Encryption™ (IBE) can address all of these use cases for both internal and external email communications. Whenever an email is encrypted, always use the same delivery mechanism – email should follow a push delivery model to the recipient’s existing inbox, rather than having to create a separate inbox for the sole purpose of maintaining secure email communication. Needlessly managing multiple encryption technologies and delivery methods only increases complexity and cost across the IT and Help Desk organizations, and frustrates users.

5. Ease of Use for Senders and Recipients: Implement a solution that is easy to use, with the freedom to send ad-hoc secure communication to anyone, without having to worry about doing a key exchange, or whether the recipient has a certificate or shared password. The solution should work across a variety of commonly used endpoints, including mobile devices, email clients, and Web browsers – with little to no impact on how senders and recipients use email.

6. One Infrastructure – Multi-Tenancy Capable: Find a solution that supports multi-tenancy, where each tenant can have its own policies and branding to address the unique requirements and use cases of different lines of business, departments, and geographic regions – all under a single email encryption infrastructure.

7. Flexible Architecture that Enables Business: Find a solution that is flexible in terms of its architecture – one that will not lock your enterprise into a specific deployment model, and that can support on-premises, cloud, and hybrid deployment models. The solution should also be able to address complex mail flows, and integrate with a variety of email infrastructure, business applications, and websites. An ideal solution is one that is able to work today, but also one that will be able to adapt to changing business needs in the future.

8. Proven in Real-World Deployments: Look for a solution that that is standards-based and proven in real world deployments. Traditional encryption technologies such as S/MIME, PGP, Symmetric Key, Webmail, and others have failed because they have poor user experiences and are costly to operate. Find a solution that has proven time and again that it can be deployed enterprise-wide, not just within small pockets of an organization. If your company does business globally, then finding a solution that has successfully scaled across multiple countries – with a single infrastructure – is a critical.

9. BONUS: A Look at Heartbleed & IBE: Data centric encryption helps to protect sensitive information when there is a vulnerability like Heartbleed. Another approach to mitigate the risk of vulnerabilities and breaches is to use a solution that can rotate private keys every N days based on policy, which will significantly limit the attack footprint if a private key is compromised. Only the information that was encrypted during that limited time period will be at risk. With traditional PKI, private key rotation is not an option. Finally, be sure to test for the worst case scenario. If your master secret is every compromised, doing a root key rollover should be a routine procedure.


Voltage SecureMail meets and exceeds these eight best practices. For more information on Voltage SecureMail, go here  and for a free trial go here.

The post Eight Best Practices for Private Email Communications appeared first on Voltage Security.

http://www.voltage.com/blog/security/eight-best-practices-private-email-communications-2/feed/ 0
The Next Generation of Encryption http://www.voltage.com/blog/crypto/next-generation-encryption/ http://www.voltage.com/blog/crypto/next-generation-encryption/#comments Fri, 09 May 2014 14:00:21 +0000 http://www.voltage.com/?p=5952 […]

The post The Next Generation of Encryption appeared first on Voltage Security.

Mark Bower, VP Product Management & Solutions Architecture, Voltage Security on data-centric security at Infosec Europe 2014 via Bank Info Security & Data Breach Today.



The post The Next Generation of Encryption appeared first on Voltage Security.

http://www.voltage.com/blog/crypto/next-generation-encryption/feed/ 0
Reducing Payment Card breach risks in e-commerce without impacting the consumer interaction http://www.voltage.com/blog/miscellaneous/reducing-payment-card-breach-risks-e-commerce-without-impacting-consumer-interaction/ http://www.voltage.com/blog/miscellaneous/reducing-payment-card-breach-risks-e-commerce-without-impacting-consumer-interaction/#comments Tue, 22 Apr 2014 16:00:51 +0000 http://www.voltage.com/?p=5917 […]

The post Reducing Payment Card breach risks in e-commerce without impacting the consumer interaction appeared first on Voltage Security.

It’s sad to see yet another data breach like this one – especially for online shoppers as in this case. But the good news is there are ways to reduce the impact. Another technique to mitigate this risk is to use end-to-end encryption from the browser to the processing host at the merchant, or to a secure payment acquirer. Techniques like Page-Integrated Encryption, for example, enable this end to end model and are used by the world’s largest e-commerce processors and merchants already from card-not-present risk reduction and compliance. With this approach, the one-time-random key encryption of cardholder data can happen in the browser (mobile, desktop etc.) automatically, protecting data in transit beyond where SSL terminates – so the load balancer, webserver, app server and so on don’t see cardholder data. Only the trusted host can decrypt. This can be implemented very quickly, and isolates sensitive data from upstream higher-risk environments.

When implemented correctly and validated, it’s an approach that can both limit the scope of applicable PCI controls, but more importantly provide another simple, no-nonsense method to mitigate the risk of cardholder breaches. There are no silver bullets, but with the right technology, the risk as reported can be dramatically shifted in favor of the merchant without disrupting the business and consumer flow – something that EMV, consumer wallets, and other approaches cannot. Transparency for consumers is critical, and expected in today’s one-click to buy competitive e-commerce landscape.


Mark Bower

VP Products & Solutions

Voltage Security

The post Reducing Payment Card breach risks in e-commerce without impacting the consumer interaction appeared first on Voltage Security.

http://www.voltage.com/blog/miscellaneous/reducing-payment-card-breach-risks-e-commerce-without-impacting-consumer-interaction/feed/ 0
Voltage Security and Protegrity Settle Litigation http://www.voltage.com/blog/current-affairs/voltage-security-protegrity-settle-litigation/ http://www.voltage.com/blog/current-affairs/voltage-security-protegrity-settle-litigation/#comments Mon, 21 Apr 2014 17:07:29 +0000 http://www.voltage.com/?p=5915 […]

The post Voltage Security and Protegrity Settle Litigation appeared first on Voltage Security.

Today Voltage Security announced that Voltage and Protegrity have reached a complete and full settlement of the ongoing litigation between the two companies.

“We are pleased to have this matter behind us,” said Sathvik Krishnamurthy, CEO of Voltage Security. “Settlement was a straightforward business decision that allows us to continue moving forward with operating and growing our business without further meritless distraction on this topic.”

Krishnamurthy went on to say, “Independent of the settlement, Voltage remains committed to innovation in cryptography and in the proactive management of its IP portfolio and licensing program. We are proud and committed to be working with industry standards bodies, for instance the current work we are doing with NIST around standardizing Format-Preserving Encryption via the FFX specification.  We firmly believe that vendors who lay claims to innovation in cryptography must openly publish their algorithms and techniques, show wide academic peer-review that demonstrates provable security, and adopt fair and open IP licensing policies in order to gain the trust of customers, and the broader market.  We have been committed to this approach from the beginning and will continue to distinguish ourselves in this manner in the future.”


The post Voltage Security and Protegrity Settle Litigation appeared first on Voltage Security.

http://www.voltage.com/blog/current-affairs/voltage-security-protegrity-settle-litigation/feed/ 0
Thinking about DES http://www.voltage.com/blog/crypto/thinking-des/ http://www.voltage.com/blog/crypto/thinking-des/#comments Tue, 15 Apr 2014 20:07:44 +0000 http://www.voltage.com/?p=5908 […]

The post Thinking about DES appeared first on Voltage Security.

Originally by Luther Martin, Chief Security Architect, Voltage Security.

The beginning of modern information security can probably be traced back to the creation of the Data Encryption Standard (DES) as Federal Information Processing Standard 46 by the US National Bureau of Standards in 1977.

Advances in technology eventually rendered DES obsolete and it was officially withdrawn as a standard in 2005. During the 28 years when DES was an active standard, the information security industry was essentially born, passed through a painful adolescence in the dot-com era and eventually reached the point today where it’s a relatively mature field. You can now get both undergraduate and graduate degrees in information security, and if you do this, you’ll be studying technology that didn’t exist when DES became a standard.

An early government publication about DES can provide some insight into exactly how far things have come since the early days of the field, so let’s take a closer look at “Privacy Data: The Data Encryption Standard Provides Valuable Protection,” United States Government Accounting Office Transfer Paper 8, from March of 1987, a paper that was actually published 10 years after the standardization of DES.

With today’s 20/20 hindsight, the discussion of the security provided by DES in this paper seems almost amusing. Like when it cites the original DES standard to justify the relatively modest level of cryptographic strength that DES provides:

The expected number of tests to recover the correct key is 255. Thus, at a rate of one microsecond per test 1142 years would be required to recover the correct key. 

Using today’s technology, it’s actually possible to recover a DES key in just a few hours, so while DES might have provided an adequate level of protection when it was first introduced, it probably doesn’t do this today.

And while the GAO paper was written a full decade after the invention of public-key cryptography, it didn’t seem to realize the full possibilities of its use:

Some observers feel that the eventual preferred communication system may incorporate two encryption systems: the DES for the secure transmission of data proper and another type of system that will only be used for the key-management portion of the transmission.

That’s exactly what’s done today in TLS, the protocol that’s used to provide secure sessions to millions of web servers today, although DES has almost universally been replaced by stronger alternatives.

The most interesting part of the GAO paper may actually be the description of a way to generate cryptographic
keys for use by DES. Today, to generate a key for a symmetric algorithm like DES you would just call one of the many pseudo-random number generators that are available. Back in the early days of DES, things were apparently much more difficult. Here’s how the GAO paper describes a way to generate a DES key:

Since a randomly generated keyword offers the greatest security, the following procedure is offered as a fast, unbiased method of generating random numbers:

1. Obtain 7 coins, paper, and a pencil.

2. Shake coins in cupped hands.

3. Without observing states (“heads” or “tails”), place coins on table and keep covered with hand.

4. Extract one coin from the group and record its state – e.g., “heads” is “1” and “tails” is “0.” (Optional: record state of coin on DES keyword recording form, figure 3.2) Repeat for each of the next 6 coins.

5. Select the parity bit so that the total number of “1’s” in the 8-bit byte is odd (i.e., including the parity bit itself).

6. Repeat steps 1-4 to generate seven more bytes.

7. Translate successive 4-bit groups into their hexadecimal representation and use the resulting 16-digit hexadecimal number as the DES keyword.

That’s right – they’re actually describing a way to generate DES keys by flipping coins! The GAO paper even includes a handy printer-ready table (the DES keyword recording form that’s mentioned in step 4 of this process) for help in organizing the bits that you might generate in this way.

Things have definitely changed a lot since 1987.

Reading this GAO paper also left me with some questions that there’s no obvious right answer for: How will today’s guidelines for using encryption look to people 20 to 30 years from now? Will the HIPAA privacy rules seem quaint and archaic? Will the PCI DSS seem like a reasonable set of guidelines?

I think I know the answers, of course, but only time will tell if I’m right or not.




The post Thinking about DES appeared first on Voltage Security.

http://www.voltage.com/blog/crypto/thinking-des/feed/ 0