Ray Potter, Author at SafeLogic

All posts by author

8 Feb 2015

On Encryption Keys (and Anthem) – Part 2 of 2

SafeHealth_option2_orangeThe Anthem breach encouraged me to wrap up this blog series and talk about key management in a genuine security context. When the Anthem breach first was public, it looked as if patient records were accessed because of lack of data encryption. Then Anthem stated the real reason for the breach: they only encrypt data in flight to/from the database(s) and rely on user credentials for access to data in the database. Why didn’t they encrypt the data in the database? Well, per Health Insurance Portability and Accountability Act (HIPAA) requirements, they don’t have to as long as they provide protection of the data via other means. Like elevated credentials.

That worked well, didn’t it?

They were compliant, but obviously not secure. To add more security to compliance programs like HIPAA, there have been some cries for enterprises to implement encryption. So how do you encrypt data properly? Well, it all depends on your environment, the sensitivity of the data, the threat models, and any tangible requirements for regulatory compliance. Here are some general guidelines:

  • Use validated encryption.
  • Use strong, well-generated keys.
  • Manage the keys properly.

Use validated encryption. Federal Information Processing Standard (FIPS) 140 is the gold standard. The Advanced Encryption Standard (AES) is one of the FIPS-approved algorithms for data encryption, and it is a better encryption algorithm than what Joe the Computer Science Intern presented in his thesis project. It just is. Plus, part of the FIPS 140 process involves strenuous black box testing of the algorithms to ensure they’re implemented properly. This is crucial for interoperability, and proper implementation of the AES standard also provides a measure of confidence that there aren’t leaks, faults, etc. Always look for the FIPS 140 certificate for your encryption solution.

Use well-generated keys. A password-based key (PBK) is crap. Here a key is derived from a password after it’s hashed with a message digest function. PBKs are crap because most passwords are crap. They’re subject to brute-force attack and just should not be used. Password-Based Key Derivation Function v2 (PBKDF2) makes password-based keys a bit stronger by conditioning the digest with random elements (called salt) to decrease the threat of brute force. But the threat is still there.

Keys should be as unpredictable and “random” as possible. Unfortunately in software environments it’s difficult to obtain truly random data because computers are designed to function predictably (if I do X, then Y happens). But let’s say you can get provable random data from your mobile device or your appliance. Use that to feed a conditioning algorithm and/or pseudorandom number generator. Then use that output for your key.

Use strong keys. The strength of a key depends on how it’s generated (see above) and how long the key is. For example, the AES algorithm can accommodate key sizes of 128-bits, 192-bits, or 256-bits. Consider using a key size that correlates to the overall sensitivity of your data. In Suite B, 256-bit keys can be used to protect classified data at the Top Secret level. Is your data tantamount to what the government would consider Top Secret?

Also consider the environment. Constrained and embedded environments (think wearables) may not have the processing power to handle bulk encryption with 256-bit keys. Or maybe data is ephemeral and wiped after a few seconds and therefore doesn’t need “top secret level” encryption. Or maybe there’s just not enough space for a 256-bit key.

Use a key that is strong enough to protect the data within the constraints of the environment and one that can counter the threats to that environment.

Manage your keys properly. You wouldn’t leave the key to your front door taped to the door itself. Hopefully you don’t put it under the doormat either. What would be the point of the lock? The same applies to information security. Don’t encrypt your data with a strong, properly generated data encryption key (DEK) then leave that key under the doormat.

Consider a key vault and use key encryption keys (KEK) to encrypt the data encryption keys. Access to this key vault or key manager should also be suitably locked down and tightly controlled (again, many different ways to do this). Otherwise you might as well just not encrypt your data.

While we’re at it: rotate your keys, especially your KEKs. Key rotation essentially means “key replacement” … and it’s a good idea in case the key or system is compromised. When you replace a key, be sure to overwrite with Fs or 0s to reduce any chance of traceability.

Store those DEKs encrypted with KEKs and protect those KEKs with tools and processes. And remember to balance security with usability: rotating your KEK every 2 seconds might be secure, but is your system usable?

Anthem wanted the data to be useful, which is why it wasn’t encrypted at the database. But that usability came at a high cost. The good news is that it is possible to encrypt data and have it be usable.

 


Encryption is a critical, necessary piece of a system’s overall security posture. But it’s not the sole answer. In Anthem’s case, records were accessed via those “elevated user credentials” … which means that malicious hackers were able to get in to the authentication server and raise privilege levels of user credentials (usernames/passwords) that they either knew or gleaned from the auth server. So in this case, it’s irrelevant if the breached data was encrypted; the hackers had authenticated and authorized access to it.

So what’s the answer?

When this was first reported I tweeted this:

Editing_Encryption_Keys — Part_1__What_Are_Keys_Exactly_

Defense in depth means providing security controls to address all aspects of the system: people, process, and technology. Technology is the most difficult pillar to lock down because there are so many layers and threats, hence so many products such as firewalls, IDP, APT, IDS, SIEM, 2FA, AV, smart cards, cloud gateways, etc.

Encryption is a fundamental element for security of data at rest and data in motion (control plane and data plane). Even the strongest encryption with proper key management won’t protect data that is accessed by an authorized user, because it has to be usable. However, encrypted data and tight management of keys provides a critical, necessary piece to a robust security posture.

I hope this provides some guidance on how to think about encryption and key management in your organization.

 

BlogFooter_Ray

24 Jan 2015

On Encryption Keys – Part 1 – What Is a Key?

Last week I met with a customer to help solve, among other things, some challenges around key management and key lifecycles. I thought I’d kick off a blog series on keys: what they are, their generation, use, recommended strength, etc.

First, let’s briefly address what a key is: a key is what protects your data. It’s a (hopefully!) secret parameter fed into an encryption algorithm to obfuscate data in a way that only someone with the same key can decrypt the data and read it as intended.*

Here’s how I explained it to my 10-year-old daughter:

Think about the door to our house. When the door is locked, only someone with a key can get inside. (Ok sounds more like authorization but stay with me). When inserted and turned, the key hits the pins that triggers the locking mechanism and unlocks the door. That key is the only key that can lock and unlock our door.

While quite elementary in my mind, it’s a relatively good example of the value and importance of the key lifecycle, which I briefly discussed with my daughter after she asked the following questions:

  • What if someone copies the key?
  • What if our neighbors lose our spare key?
  • How do we know if someone else used our key?
  • Does someone else’s key work in our lock?

All are relevant questions in relation to cryptography as well. Over the next couple of weeks, we’ll talk about how keys should be generated, ideal key sizes, and general key management issues and best practices.

Fair warning: there is no single, correct answer. We’ll use this series to address dependencies and variables such as environments, data sensitivity, and threat models.

*This is known as symmetric encryption, where one key encrypts and decrypts data. In asymmetric encryption a public key is used to encrypt data and only its associated private key can decrypt the data.

 

BlogFooter_Ray

5 Jan 2015

My Worry and Optimism for Cybersecurity in 2015

toughroad8ball

Let’s face it – 2014 was pretty bad from an information security perspective, and I believe we will see a rise in the frequency, severity, and publicity of malicious hacks and breaches in 2015.

I’m worried that as a community, hell, as a society, we won’t see enough progress in this uphill battle of infosec. I’m not blaming anyone or pointing fingers. Security is hard because every organization is different: different people, different policies, different network topologies, different vendors, different missions, etc. (and that is why there is no silver bullet for security). In general, I’m worried about some SMBs that lack the resources to set up a proactive security posture. I’m concerned about some large enterprises that will continue to lag and not fully embrace security.

But… I’m optimistic. Security is at the tip of everyone’s tongue now. It’s “cool” … and cool is good.

SMBs have options for cloud productivity and storage solutions with security built in – at the very least, better security than what they could do themselves. Larger organizations can integrate many different solutions to enable their security posture.

Security is about defense-in-depth, which is to say having security at all layers, from policy and training to two-factor auth and encryption. Aggregate organizational differences can be met with the right technologies in the right place.

I’m optimistic because there are so many good and talented people working very hard to stay ahead of the bad guys. There are new technologies and new ways of thinking. There are VCs willing to fund such companies. There is more adoption and acceptance of security in the marketplace. There are companies with an assigned CISO to keep their business focused on security and out of the news.

So how do we make 2015 better to ease my worrying and reinforce my optimism?

Everyone: keep evangelizing. We have to keep talking about security and encouraging it. We need to think about security in new and emerging markets like wearables and IoT. I think after all the news in 2014, stakeholders are starting to get it. Perhaps we need better / tighter regulations. We need to talk about what’s real, what’s viable, and what’s manageable.

Product vendors: build security into your lifecycle. It’s doable. Microsoft initiated the Security Development Lifecycle with impressive if not astounding results. Cisco is doing it, along with many others. Security is a process. Bake it in to your software development. It’s good for you and your customers.

Buyers: check for the right encryption. Not all encryption is equal. Is your vendor using homegrown encryption written by Joe the Intern? Or is it standards-based? Just because a vendor says they implement AES doesn’t mean they do it correctly. Encryption needs to be correct to be true and interoperable. Look for FIPS 140 validation on your preferred vendor’s encryption library or ask for the certificate number.

All businesses: Assess the value of your data and where it resides. Then deploy the right products. Security is a process. Organizational security starts with security risk management, which guides the organization in protecting its assets. Before selecting security controls, the organization must know what data it needs to protect, the value of that data, and the lifecycle of that data. Whether protecting credit card numbers, user files, intellectual property, internal emails, provocative Mardi Gras photos, product roadmaps, money… all of that needs to be protected in an organized and actionable way.


Over time, we’ll explore more in each of these areas. In the meantime, this worrier is optimistic that we will stay focused, deliver, and do our best to make 2015 better.

 

BlogFooter_Ray

22 Dec 2014

The Sony Hack Just Does Not Matter

Several times this year we’ve heard about hacks and compromised systems (more so than I can remember in recent history), and I have to say I’m truly amazed at all the press on the Sony hack. But why is this garnering so much attention?

Simply put, its effects are felt by a wider audience.The_Interview_2014_poster

  • Sony cares because of loss of revenue and tarnished reputation.
  • Movie stakeholders (the producers, actors, etc.) care because it could impact them financially. I have never read the relevant agreements for this industry, but I’m sure there is a force majeure clause that will now be subject to an unprecedented interpretation and a great deal of legal precedence going forward.
  • Theater owners / workers care because of supposed threats against their establishment, loss of revenue, and the inconvenience of replacing a movie in their lineup.
  • Consumers care because they can’t see a movie with some very funny comedians.

Banks or retailers get hacked and it makes the news for a couple of days and fades. Maybe it’s not serious enough? The Home Depot, Target, and Staples attacks don’t really take anything away from the consumer. They can still shop at those places, albeit with new credit card numbers. So they don’t really feel the effects. An entertainment company is hacked and it’s an act of war cyber-vandalism. So much so that the President has weighed in and vowed a response. I guess compromising a retailer is just a nuisance.

Finally, there is breach that consumers actually care about. The JPMorgan breach doesn’t directly affect the average family. We are, sadly, getting accustomed to being issued new credit cards and putting band aids on breaches in that industry. We can tolerate the Fortune 50 losing money, but don’t mess with our entertainment. That is intrinsically American.

Perhaps I should rethink this title, as now attackers may have found an avenue that will encourage even more attacks. And let’s face it: we have thoughts of actual war dancing through our heads. This isn’t script kiddies and folks just looking to make a quick buck. These are hackers with nukes.

At SafeLogic we’ve done a fair bit of evangelizing this year, trying to get makers of IoT devices and health wearables to build security in as opposed to treating it as a cost center and a reactive initiative. So with that in mind, let’s think about this:

If halting the release of a movie gets this much attention and buzz , what happens if critical infrastructure is compromised? What if people can’t get water? Or they get only contaminated water? What if the power grid is blacked out? What happens when connected “things” are compromised? These are the absolute scariest scenarios, the effects of which are far more impactful than what you’ve been reading about this week. These effects are real.

Let’s not discover what happens in these “what if” scenarios. We need awareness and we need plans and we need action. I’m hoping that everyone takes the Sony hacks to heart and thinks about what truly matters… Especially this time of year.

Oh, and encrypt your data with SafeLogic’s validated and widely-deployed encryption solutions.

BlogFooter_Ray

15 Oct 2014

Putting a Muzzle on POODLE

SafeLogic is not vulnerable to POODLEYou may have seen the news about POODLE recently.  The good news is that it’s not as severe as Heartbleed, which affected server-side SSL implementations and had repercussions across most web traffic. The bad news is that it’s still seriously nasty.

POODLE is an acronym for Padding Oracle On Downgraded Legacy Encryption and essentially allows an attacker to decrypt SSL v3.0 browser sessions. This man-in-the-middle attack has one major constraint: the attacker has to be on the same wireless network.

That renders POODLE irrelevant because everyone locks down their wireless networks, right? Oh yeah, except those customer-friendly coffee shops with public wifi. In places like Palo Alto, you can bet there is a *lot* of interesting information going over the air there. Or at conferences, where diligent employees handle pressing business and aggressive stock traders log in to their account to buy the stock of the keynote speaker (or short it if his presentation lacks luster).  The threat is real – session hijacking and identity theft are just the tip of the iceberg.

It’s worth noting that this is a protocol-specific vulnerability and not tied to vendor implementation (such as Heartbleed with OpenSSL and the default Dual_EC_DRBG fiasco with RSA). That makes it a mixed bag. The issue affects a wide variety of browsers and servers (Twitter, for example, scrambled to disable SSLv3 altogether), but users do have some control.  This is because SSLv3 can also be disabled in the client within some browser configurations, so check your current settings for vulnerability at PoodleTest.com and install any patches when available for your browser.

Some browser vendors have already made moves to patch against this threat and permanently disable SSLv3.  Meanwhile, others have dubbed server-side vulnerability “Poodlebleed” and offer a diagnostic tool to assess connectivity.

From a government and compliance perspective, Federal agencies should be using TLS 1.1 according to Special Publication 800-52 Rev 1. TLS 1.1 is not susceptible to POODLE. FIPS 140 validations and SafeLogic customers are not affected.

If you’re interested in a deep dive, I recommend this fantastic technical post by Daniel Franke, which also provides a great history of SSL and its challenges.

BlogFooter_Ray

6 Oct 2014

It’s Q4 Already?

It’s hard to believe we are in Q4 already. If you’re in the Bay Area, it still feels like summer!  But here we are, rapidly approaching Halloween and the holidays, watching football and playoff baseball.

I don’t really do quarterly company updates on the blog; in fact, I think Walt would argue I don’t write enough blog posts in general. But I’m just too excited. SafeLogic has had a great year and I’m really proud of the work that the team is done. A more detailed recap will happen towards the end of the year – Walt will be sure of that!

I’m on the way to Orlando now to talk at Gartner Symposium about security and compliance with Paul DePond of Globo, one of our customers in mobility. If you follow us on Twitter (and why wouldn’t you?), you’ll notice that I’ve been on the road speaking quite a bit recently. The content has been a blend of education and evangelism. I’m trying to get developers in emerging areas of technology to think about building security in to their solutions. I know it’s no easy task but I want to be sure folks are thinking about emerging threats. It’s easier with SafeLogic, but that’s another story. I want folks to understand the need for and value of strong encryption built with compliance in mind.

We have talked to customers and potential clients in some very cool new spaces, and it’s encouraging to see a more mature comprehension of the advantages offered by validated crypto.  Questions from analysts and press are becoming more sophisticated, and end users are really adapting to the landscape.  It’s gratifying to see folks genuinely care about how their data is being protected.

It’s been a very fun and very busy year… and we have some cool surprises in store, in both the short and long term. I can’t wait to share more.

BlogFooter_Ray

3 Jul 2014

Happy Independence Day!

Stars and StripesWow.  It feels like just yesterday that I blogged about the importance of our freedom and opportunity, and how thankful I am to be thriving in the USA.  That was a year ago.  In ‘SafeLogic Time’, where we try to compress a month’s work into a week, and a year into a month, this feels more like a decade!

Much has happened since the summer of ’13.  I encourage you to go back and re-read some of our blog posts to recap.  It’s really pretty interesting to harken back to the challenges that we were facing last year and how we have solved some, while others are very much still threatening.  We will be selecting certain posts as suggested reading for what the Twitterverse likes to call #ThrowbackThursday… although I know that Walt really enjoyed X-Men: Days of Future Past, so that might be contributing to the retro theme too.

Some things have definitely remained the same.  SafeLogic still pursues innovation in security and encryption, prioritizing the safety, privacy and liberty of our customers, and our customers’ customers.  I’m still thankful and proud to be an American, and I’m still planning to grill, watch fireworks and put away a few cocktails.

In a landscape strewn with failed companies, startups deeply in the red, and ousted executives, I’m excited for Independence Day.  I have a lot of pride as I continue to lead this company, as SafeLogic continues to operate independently, at a profit, and with no venture debt.  It’s the most clear, direct way that I can say definitively that we will be here when you need us.  Next month, next year, or whenever you’re ready.

Happy Independence Day!

BlogFooter_Ray

18 Jun 2014

Tizen, Connected Cars and Buggy Whips

Two weeks ago, I had the privilege of giving a presentation at the 2014 Tizen Developer ConferenceSafeLogic_Tizen_Logos

The first thing that you should know is that this was a fantastic event.  Most of us will hear “user group” or “developer conference” and reminisce about our own early experiences, the coffee-and-donuts geek meetups, complete with a folding chair for each wannabe Wozniak.  This was much more.  With a variety of speakers tackling an equally diverse set of topics over a three day stretch, and a significant investment of time, money and energy from Intel and Samsung, I highly recommend attending in 2015 if possible.  It was a very smooth and well-coordinated conference, for speakers, attendees and exhibitors alike.

The second thing that you should know is that my session rocked.  ‘Security-Centric Development for IoT and Wearables’ was one of the few talks that had a specific focus on data protection.  My hope is that I was able to influence attendees to consider security as a non-negotiable aspect of their development efforts, and maybe next year we will see more like-minded sessions on the agenda.  At the very least, I had fun launching SafeLogic footballs into the audience and nobody got a concussion.

To be honest, I was blown away by the ideas bouncing among the audience.  There were developers from seemingly every corner of technology, all with a vision of success based on the same operating system.  It was inspiring to see how many different folks saw potential in the same place.  Since the conference, it has felt like everywhere I look, there is another potential application for Tizen, another opportunity to join the Internet of Things and another chance to connect.  The scary part is that it all has to be secured.  Remember, IoT is only as strong as the weakest link.

One session at the Tizen Developer Conference included a discussion of the connected car collaboration efforts of the Linux Foundation, IBM, Intel and Local Motors.  It made me think of the article I had just read on CNN, aptly titled ‘Your car is a giant computer – and it can be hacked’.  Scary stuff, and spot on.

GoogleCarThe Toyota Prius has solidified its place in the garage of everyday Americans based upon efficiency, not horsepower, and has been immortalized as the test mules for Google’s self-driving car project.  Tesla’s fully electric Model S was the top selling full-sized luxury sedan in 2013… not bad for a vehicle designed by tech geeks.  Google has pushed the envelope even further now, internally developing prototypes for an all-new self-driving vehicle that incorporates features of both.  The landscape is clearly changing – and quickly.

Steering wheels are the next buggy whip, and data security will be more important to safe transportation than seatbelts.  Driver error will be replaced by the threat of compromised communications.  Could you imagine arriving at your destination, only to find yourself at a location chosen by a malicious hacker?  Or having your vehicle overridden and driven into a wall, off a cliff, or into a lake?  There is serious potential in self-driven cars, but even more serious potential for disaster.

The Tizen platform is not uniquely vulnerable to these threats.  All of IoT inherently is.  A smart toaster in your kitchen has to be as secure as your car, even though it isn’t 3000 pounds of metal going 70 miles per hour.  Until developers begin treating all devices with the same level of respect, I encourage all of us to tread carefully.  Hackers relish the challenge of creating mischief as much as they value the results, so assume that you may be a target.  We all are.

If you are a developer in IoT, please check out CryptoCompact.  We have begun our pilot program, so consider it an open invitation to integrate military-grade encryption within your project.  We’re all in this together, so let’s stay safe.

BlogFooter_Ray

8 Apr 2014

SafeLogic Responds to Heartbleed

We just issued an advisory notice for customers regarding the recent Heartbleed vulnerability in OpenSSL.

The issue doesn’t reside within our CryptoComply module; it’s in the higher level OpenSSL libraries that (can) call into our CryptoComply module. This means there is no FIPS impact to our customers… however, there is a security impact.

Folks, this is serious stuff. Key material is subject to being disclosed to attackers. Even if you’re using another crypto module with your vulnerable OpenSSL implementation, patch it immediately. But just patching it isn’t enough. Consider this the right time to update your keys and certificates. You should assume that an attacker knows them by now. 

I have to say that I’m very proud of the SafeLogic team here. We responded and had new builds commencing within a few hours of the notice. We provide upstream OSSL stack as a value to our customers, and it’s important to all of us that they run securely. Builds run through smoke testing and functional testing to ensure proper operation for FIPS, and builds are available on our support portal.

We’ll continue to stay on top of this. We’re not only looking to help our customers… we want to help protect the industry at large. This is that big of an issue. Security awareness becomes key, so let’s keep this at top of mind.

BlogFooter_Ray

26 Mar 2014

Are We Ready for IoT?

As an industry, we’re not over the hump for mobile security yet. We’ve gone from protecting the device to protecting the app to protecting the data. We’ve come a long way in terms of security for mobility, and we still have a long way to go.

And yet a new challenge looms.

I’m talking about the Internet of Things (IoT).  IoT is a connected, well, everything. Cars, wearables, home automation, industry-specific devices, etc. It will all be connected. The Internet of Things market will be huge. Even data centers are prepping for its rise. Some folks have justifiably begun calling it the Internet of Everything.

So are we ready for IoT? Well, at SafeLogic, we are. Over the next few weeks you’re going to see some new blog posts and an exciting announcement. We’re going to talk about risks, challenges, and solutions. Because after all, we are only as secure as our weakest link.  In IoT, there are so many links that we don’t have a choice – we have to get it right from the start.

BlogFooter_Ray