CryptoComply Archives | SafeLogic

All posts in CryptoComply

30 Mar 2017

SafeLogic Wins Encryption Trophy at 2017 Govies

SafeLogic won at The Govies 2017!Security Today magazine announced the 2017 winners in “The Govies,” the Government Security Awards competition, honoring outstanding government security products. SafeLogic was selected as the winner in the ‘Encryption’ category for our CryptoComply product, adding another trophy to our case!

“It always feels good to win an award,” said SafeLogic CEO Ray Potter. “Being selected as the winner for encryption in a government-specific competition is even better. It really validates (pun absolutely intended) our strategy for FIPS 140-2!”

1105 Media launched its government security awards program in 2009, although they weren’t known as The Govies until two years later. Starting this year and going forward, 1105 Media’s newly relaunched Security Today magazine (formerly Security Products) will administer the awards program. Winners were selected using criteria including Features, Innovation, User Friendliness, Interoperability, Quality, Design, Market Opportunity, and Impact in the Security Industry, Technical Advances, and Scalability.

“The Govies is an amazing product recognition program whereby companies in the security industry can highlight their technology and solutions that work flawlessly within the government vertical,” said Ralph C. Jensen, editor in chief of Security Today magazine and securitytoday.com. “We received 28% more entries this year, which also corresponds with the need to provide better security options not only at the federal level but also at the state and municipal level of government. I believe these products and solutions only prove that the government relies heavily on the technology advances in the private sector.”

Other selections include SafeLogic customers BlackBerry, chosen for BlackBerry UEM in the ‘Convergence and Integrated Software and Solutions’ category and BlackBerry AtHoc in the ‘Emergency Communication Systems’ category, and Securonix, chosen for SNYPR Security Analytics for Hadoop in the ‘Big Data Analytics’ category.

BlogFooterWalt3

 

23 Mar 2017

FedRAMP Kicks It Up a Notch

FedRAMPHave you been following the evolution of the FedRAMP program lately? They are proving to be as nimble as any other group in federal, and even better – they are putting an emphasis on transparency. Check out their blog Focus on FedRAMP for example. After we gave kudos to the CMVP for their recent renewed efforts, it wouldn’t feel right to forget the folks at FedRAMP.

Last month, FedRAMP rolled out an update to their 3PAO Requirements. 3PAOs, Third Party Assessment Organizations, play a huge role in the process, just like the testing labs certified by NVLAP, the National Voluntary Laboratory Accreditation Program, do for FIPS 140-2. For each certification procedure to move smoothly, the 3PAOs and FIPS labs must meet an ongoing standard of excellence. In this case, FedRAMP worked with A2LA, the American Association for Laboratory Accreditation, and determined that they “need to strengthen the 3PAO accreditation requirements to provide for greater 3PAO oversight to ensure that a FedRAMP Accredited 3PAO provides the highest quality, most technically accurate assessments for the Cloud Service Providers (CSPs) who participate in the FedRAMP Program.”

FedRAMP-RAR-768x806An even bigger step forward was taken when FedRAMP unveiled the FedRAMP Readiness Assessment Report (RAR) Template as part of their FedRAMP Accelerated Process initiative in the summer of 2016. Their primary goal was to give Cloud Service Providers a pre-audit tool to self-assess and prepare themselves for scrutiny. But even more importantly in my opinion, the RAR was created as a living document, intended to be updated as needed to shed light on areas that need further interpretation. (Pro tip – make sure that you download the latest version of the RAR when you are prepping and doing due diligence. 3PAOs must use the most current RAR template that is available on the FedRAMP website at the time of submission.) This has been a huge help for CSPs hoping to secure FedRAMP approval. We have had more than a few frantic phone calls from CSPs that were suddenly faced with a mandate for FIPS 140-2 validation and they didn’t have a strategy. This should assist folks plan ahead and develop a more comprehensive plan in advance.

Despite our efforts to raise awareness about the requirement for FIPS 140 in FedRAMP over the last few years, it had still been a subject of debate. So it’s great that FedRAMP has finally made it more explicit in the RAR. For example, Section 4. Capability Readiness, subsection 4.1 Federal Mandates, bluntly asks “Are FIPS 140-2 Validated or National Security Agency (NSA)-Approved cryptographic modules consistently used where cryptography is required?” This should be no surprise, of course. A federal program requiring the crypto to be federally approved. That makes more sense than many bureaucratic requirements, doesn’t it? More below about the NSA caveat.

Further, check out subsection 4.2.1. Approved Cryptographic Modules [SC-13]:

The 3PAO must ensure FIPS 140-2 Validated or NSA-Approved algorithms are used for all encryption modules. FIPS 140-2 Compliant is not sufficient. The 3PAO may add rows to the table if appropriate, but must not remove the original rows. The 3PAO must identify all non-compliant cryptographic modules in use.

Table 4-2. Cryptographic Modules

  Cryptographic Module Type FIPS 140-2 Validated? NSA Approved? Describe Any Alternative Implementation
(if applicable)
Describe Missing Elements or N/A Justification
Yes No Yes No    
1 Data at Rest [SC-28]
2 Transmission [SC-8 (1), SC-12, SC-12(2, 3) ]
3 Remote Access [AC-17 (2)]
4 Authentication [IA-5 (1), IA-7]
5 Digital Signatures/Hash [CM-5 (3)]

As you can see from the Cryptographic Module planning matrix above in Table 4.2, FedRAMP is taking extra care to highlight the need for a FIPS validated module. They clearly had more than a handful of conversations with CSPs trying to argue for the use of a selection of algorithms from the CAVP list as ‘good enough’ and wanted to nip that in the bud. In fact, those were their bolded terms, not mine! The distinction is very important and the clarification was clearly needed.

I almost forgot. Circling back for those of you eyeballing the ‘NSA Approved’ verbiage as a potential loophole to bypass FIPS 140, I have just two words: Good. Luck.

That ubiquitous AES-256 implementation that you’re hoping will satisfy this requirement, because, after all, it is an included component for NSA Suite B… yes, well, it’s also included in FIPS 140-2 and therefore governed by CMVP/CAVP. So if there’s no CAVP certificate, and it’s not implemented as part of a CMVP validated FIPS 140-2 cryptographic module… well, let’s just say that you already missed St. Patrick’s Day and you’re going to need a whole truckload of four-leaf clovers for that to pass muster.

FedRAMP is taking great steps to take the mystery out of the process, and one of those major clarifications is the explicit reliance on the CMVP and FIPS 140-2 validation. If you’re reading this blog, you probably already know it, but nobody handles FIPS 140-2 requirements as quickly, easily, or effectively as SafeLogic. For more information, please explore our products and services at your leisure. They are designed to work in tandem and remove the hassle for your team. As always, contact us with any questions.

 

BlogFooterWalt3

7 Mar 2017

The CMVP Historical Validation List Is Here with a Vengeance

SunsetEditor’s note: This post was updated on March 14, 2017 to reflect a distinction that came to light in dialogue with CMVP – validations moved to the Historical List have not been revoked outright. The validation still exists, but are not for Federal Agencies to include in a new procurement. Agencies are recommended to conduct a risk determination on whether to continue using existing deployments that include modules on the Historical List.

Over a year ago, our blog featured posts about the RNG issue that was leading to certain FIPS 140-2 validations moving to the Historical List and the 5 year sunset policy that CMVP was adopting. [Geez, was that really more than a year ago? Crazy.]

Now the hammer has dropped, and the industry is seeing modules routinely relegated to the Historical List each month. The sunset policy created a waterfall in January 2017, and as of today, there are 1,914 modules on the Historical List, representing approximately 2/3rds of the total validations completed in the history of the CMVP.

Let me repeat that for emphasis. 1,914 modules.
Approximately 2/3rds of all modules ever validated by NIST to meet the FIPS 140 standard are no longer on the active validation list.

This includes some modules that were updated in 2016, and a few were even just revised in 2017! Many of these are hardware, so they are often more static and harder to update, but certainly not all. Check out the entire Historical Validation List for yourself. It’s a veritable “Who’s Who” of once-proudly validated companies. Big names, hot startups, none are immune. Between the sunset timeline and the active removal of modules that are no longer compliant, the herd has been severely thinned.

The takeaway? Maintaining FIPS 140 validation is really hard! It’s not “just one big push” to get on the list anymore. It requires constant vigilance to stay on top of the updates and to keep up with NIST’s reinvigorated policies. A more active CMVP can seem like a pain in the ass at first glance, but it is ultimately better for the industry. Nobody (except for lazy vendors) benefited from old, insecure, ‘grandfathered’ modules remaining on the active validation list. A stringent, active CMVP has embraced their role as a clearing house and it increases the value of the modules that do satisfy current standards. And I think they’re doing a great job.

This underscores the strategic significance of relying upon SafeLogic to complete and maintain FIPS 140-2 validation. As I tell folks every day, this is our focus. Our business is based upon the proper production of FIPS-compliant modules and their subsequent validation. Our customers reap the benefits of our work, and we succeed by scaling it, replicating our effort and leveraging our niche expertise for each client. CryptoComply is smooth and RapidCert accelerates the initial validation, but our customers have really appreciated the value of offloaded maintenance for the certificate. We talk a lot about the time, money, and effort with the traditional process, and the savings realized when using SafeLogic are growing. The delta is getting wider.

I scratch my head when a product manager boasts that they plan to roll their own crypto and get it validated. There are no bonus points for suffering in-house or for reinventing the wheel. When you hire consultants to complete a validation, you’re paying a premium for a single push, when the maintenance really is a constant effort. Consider those costs in time, money, and effort to complete your initial validation – and then add a multiplier for every revalidation you anticipate. It will be at minimum a quinquennial (every five years) project, and that’s if you’re lucky enough to avoid any other pitfall. The math doesn’t lie – the traditional path to FIPS 140-2 validation has become cost prohibitive. And if you’re pursuing Level 2 or Level 3, you still need a solid crypto module at the heart of the product. Using CryptoComply ensures that component meets the necessary requirements, again saving time, money, and effort.

CryptoComply is proven, again and again, to continually meet standards and retain its validated status with NIST. This is one of those situations where you don’t need to be creative. Choose SafeLogic, let us take care of the crypto, and you can get back to doing what you do best.

Written by Ray Potter

13 Dec 2016

RapidCert for CryptoComply | Java 3.0 Is Available!

CryptoComply | Java 3.0 is here!You may have noticed – SafeLogic has a new FIPS 140-2 certificate posted by NIST. Published on December 8th, it’s our CryptoComply | Java module, version 3.0! Fully compatible with Bouncy Castle’s recent FIPS API revisions and with a nice helping of SafeLogic’s secret sauce (yes, it’s orange), customers with Java deployments now have a natural upgrade path available with CryptoComply | Java 3.0.

Technical improvements over CryptoComply | Java 2.2 include a variety of bugfixes, a significant simplification of deployment, a single JAR that includes both approved FIPS mode and non-approved mode, and the promise of greater forward compatibility. Many of you are already aware of the technical benefits of Bouncy Castle’s latest release, and now SafeLogic’s CryptoComply offering includes RapidCert, which delivers your own FIPS certificate quickly. With a validation in your name and support from our technical staff, CryptoComply is a clear upgrade. See our Top 10 Reasons to Choose SafeLogic Over Open Source Encryption for more!

RapidCert is available NOW for CryptoComply | Java 3.0
License the software today and have a certificate in your name in 8 weeks.
It really is that easy.

Contact us immediately for a quote.

 

BlogFooterWalt3

9 May 2016

Patch Panic Prevented!

Well, that’s finally behind us. After days of anticipation and fear, OpenSSL’s newest patches were released last Tuesday with little official fanfare from the Foundation and no cute names for vulnerabilities, but a good amount of comments from the peanut gallery on Twitter. Of course, the initial fix is just the tip of the iceberg. A minor spike in antacid sales on Monday, a flurry of cancelled dinner reservations on Tuesday, and a fair number of naps taken on Wednesday notwithstanding, most operations teams are in the clear… for now. We’re in that lull, the waiting period when engineers are watching like hawks, hoping nothing else breaks and that no additional work is required. The black hats are picking and probing, hoping that these patches, like so many before, have spawned new vulnerabilities to explore. We will know soon enough what they have discovered. Fahmida Y. Rashid has a great rundown of the vulnerabilities and associated fixes in her column at InfoWorld, if you’re interested.

high-fiveI’m proud to say that here at SafeLogic, we handled this round of patches with grace and poise, delivering as promised for our customers. [Yes, I intend to flatter and compliment our technical team. They deserve it. High five!] Since many of our clients deploy a version of CryptoComply that is forked from and compatible upstream with OpenSSL, it is imperative that we remain on top of the latest developments. It’s one of our central mandates as a company. Our customers rely upon us to ensure that new builds are tested, operate properly for their deployment, remain in compliance, and are provided in a timely fashion. And we do, with bells on.

It’s not even so much that I just want to trumpet the accolades for our team when they do their job as expected… that is table stakes. I don’t even need to dwell on how they exceed expectations and beat time estimates on a regular basis. (They do, though!) It’s that this professionalism and commitment to customer success is what sets SafeLogic apart. Our technical team is the embodiment of what we espouse on the marketing side when we chronicle the ways that our CryptoComply products are an upgrade from open source alternatives.

We talk about strong support. We’ve asserted many times that in this exact scenario, SafeLogic simply takes care of the new builds and pushes it out to customers. We remind our customers and prospective clients that we offer dynamic, effortless updates to reflect the constantly changing landscape of operating environments. Further, our customers avoid the stigma of open source. Instead of telling their end users that “Yes, we applied all patches and we believe that we’re all set”, our clients are able to simply reassure the users, saying, “We use SafeLogic encryption. They handle all of it. We’re covered, and so are you.” It’s a wonderful thing to put their minds at ease.

Bottom line – whether you were one of the myriads of Twitter users complaining about the patching process, the “aging and bloated” codebase of OpenSSL, or if you just want a better way to handle your crypto needs, contact us now. We might already be working with your rivals, which would explain why they aren’t fazed by these patches. They are staying focused on beating you while SafeLogic takes care of the crypto piece. Don’t worry – we have the bandwidth to help you too. Let’s even the playing field and take this headache off of your plate. Let us be your secret weapon, your competitive edge, or the equalizer. Let this be the last round of OpenSSL patches that your engineers have to wrangle. Our technical team is ready.

BlogFooterWalt2

21 Oct 2015

Worse than Frenemies

You’ve heard the term ‘frenemies’ before, right?  You most likely have if you’ve got kids past middle school, unfortunately.  It’s the mash-up of ‘friend’ and ‘enemy’ with the distinction defined in the helpful illustration below.

FrenemiesEnemies

Today’s blog post is a public service announcement – Beware of frenemies.  Many of us forget about this life lesson once we are adults and it can really sting.  Frenemies come in several flavors in the business world, but many are friend/competitors.  Maybe these should be called ‘frempetitors’.

Our prime example is Samsung and Apple.  They have been engaged in litigation since 2011, and yet Tim Cook’s braintrust thought it was a good idea to contract with Samsung to produce A9 processors for the iPhone 6S.  Samsung was even accused of engaging in corporate espionage to displace TSMC, who had been slated for the full order.  Even the most forgiving folks would have to be a little suspicious, right?

Now the kicker – Samsung’s version of the A9 chip has been benchmarked for worse heat dissipation and shorter battery life than the alternative version by TSMC.  Was this malicious?  Was Samsung actively trying to undermine the reputation of Apple’s new flagship phone?  Popular Apple-centric blog ‘Cult of Mac’ says maybe they are.  The fact that the two corporate giants have been locked in mortal combat in both the courtroom and for market share automatically throws a shadow on the developing situation.  Despite Apple’s public claims that the variance is only 2-3% and it won’t affect typical use, Samsung doesn’t get the benefit of the doubt, since they are the very definition of ‘frempetitors’.  I’d love to hear the internal discussions in Cupertino on the topic.

So why do you care?  Well, we’ve had a spike lately in inquiries from companies in a specific industry that have been using an encryption product from their frempetitor.  Yes, they licensed a crypto module from [company name redacted] even though they are competing head-to-head against that company’s flagship product.  This boggles my mind.  We’re not talking about complementary offerings, we’re talking about the exact same kind of Apple-Samsung clash of the titans but on a smaller battlefield.  Why would you trust this frempetitor?  It’s not like their product is so fantastic that you had no choice. It’s certainly not that their pricing was so incredible that you couldn’t afford to pass it up.  For comparison’s sake, it’s not even like they provide FIPS 140-2 validation services, Rapid or otherwise.  This is just a head-scratcher.

What happens when their module isn’t working properly or if it is proven to be vulnerable?  Will they step up and patch it in a timely manner?  Or will they prioritize their own products and customers first, and you’ll have to wait until they get around to it?

What if your crypto provider pulls your license in an effort to sidetrack your engineering team and cripple your momentum, because you’ve been taking market share from their primary offering?  Are you prepared to pivot quickly on your competitor’s whim?

Would you be concerned that you are relying upon an internal component that was designed by a competitor?  What if it slows down your product’s performance?  What if it includes tracking capabilities so that they can monitor your install base?

Paranoid?  Sure, but definitely within the realm of possible.

If you ran a restaurant, you would never purchase your ingredients from a competitive restaurant.  You’d rightfully assume that they would cherrypick the best produce, the best cuts of meat, the proverbial cream of the crop, and leave you the rest.

Would your boss/investors/shareholders/customers give you the benefit of the doubt in these scenarios?  Is choosing to work with a frempetitor ever a justifiable position in retrospect?

Skip the heartache and paranoia.  Don’t get stabbed in the back and don’t give a competitor the opportunity to be a part of your supply chain.

If you are currently using encryption provided by a company that would stand to gain from your troubles, contact us immediately and we’ll help you escape from this dysfunctional relationship.  If you are considering them, please think very carefully about it before you move forward.  I don’t promise never to say “I told you so”, but I do promise that SafeLogic will be ready to help when you’re ready.  Plus, we have better modules, greater compatibility and platform coverage, and RapidCert‘s lightning fast validation is just the cherry on top.  Choose wisely!

BlogFooterWalt2

6 Oct 2015

The Need for Speed

TopGunThe Miramar Air Show was this weekend, a highlight of the year for Southern Californians.  Bay Area flight enthusiasts will get their own dose of the Blue Angels this weekend at Fleet Week San Francisco, before the iconic jet team heads to Oahu and then closes their season with dates in Georgia and Florida.  I like to think that our San Diego event holds a special place in the hearts of these naval aviators, since Marine Corps Air Station (MCAS) Miramar was the setting for the film that still reigns #1 among pilots – Top Gun.  I could have walked up to any of the soldiers on the base and asked if they ‘felt the need for speed’ and gotten a high five, or asked if they had ‘lost that loving feeling’ and gotten serenaded.  Forget that Maverick and Goose first inverted to ‘keep up foreign relations’ years before this generation’s hotshot pilots drove a car, let alone flew a plane; Top Gun is still the most effective two hour recruiting tool in the Navy.

Bottom line – the air show was awesome.  My son had a blast (the Shockwave jet truck was a big hit) and I was left with the same patriotic awe and inspiration as years past.  I’m still thunderstruck by the engineering feats that we have achieved, as a country and as a species.

I’m also equally blown away by our continually jaw-dropping idiocy.  Chatting with one of the aforementioned millennial pilots (I’m no senior citizen, but this kid was definitely born during the Clinton administration), he told me that while some of his superiors had received iPads for flight plans, he had not.  When I pressed him, he admitted that he used his own personal iPad… with a handy app that he had downloaded from the App Store, of course.  I was flummoxed.  Yes, the app (which shall remain nameless) has an excellent reputation and yes, it has a specific setup for military usage, including a worldwide library of Department of Defense Digital Flight Information Publications (D-FLIP) terminal procedures, airport diagrams, enroute charts and publications.  Very handy.

But who is authorizing this?  Or rather, who is looking the other way on this?  I’m not suggesting that the app is corrupt (although they fail to include FIPS 140-2 validation).  I recognize that the pilots are supposed to download their relevant data before takeoff and disable cellular signal while in flight.  Good rules of thumb.  But how about that GPS chip in the tablet?  That’s a major tracking beacon that has not been officially sanctioned. Or what if someone has hacked the app and is enjoying a MITM attack, collecting all user destination data?  In that case, they could theoretically isolate the military users, even the type of plane and originating location.  Gee, that wouldn’t be helpful information at all.

top-gun-2iPads have been a huge boost to efficiency and modernizing the habits of pilots, both the military and civilian.  I’m not disputing that.  In fact, I’ve been a major advocate.  That doesn’t mean that unbridled BYOD is okay, let alone encouraged.  It’s a tight margin for error and it’s shrinking.  We need to address it, because it’s not just the 20-something pilots that want it yesterday already, it’s every customer, big and small.

New solutions are a balancing act and always have been.  We constantly have to be vigilant, weighing the advantages of the technology with the compromises that we recognize in the current version before we can feel comfortable deploying it in sensitive environments such as the military.  This is a recurring theme in our CEO’s talks nationwide at security and technology conferences.  It’s just not enough to build something better – it has to be secure.  And it’s not enough to build something secure – it has to be ready faster.  And if it’s secure and fast?  Yes, it’s gotta be better than what’s already out there.

As a technology vendor, you need to enter production faster.  Getting bogged down in the FIPS 140-2 process is a fools’ errand, but we definitely have it figured it out.  Build your product, add CryptoComply, move fast, beat your competitors, and win market share.

If you’ve got the need for speed, then you need RapidCert.

P.S. – Top Gun 2 is in the works, bringing back Tom Cruise as Maverick.  Seriously.

BlogFooterWalt2

24 Jun 2014

Pro Tip: Encrypt Medical Data

SafeHealth_v2_orangeThere has been a ton of chatter about the recent fines levied by the U.S. Department of Health and Human Services Office for Civil Rights (OCR), and for good reason.  Money talks.

The Department of Health and Human Services (HHS) assessed a record $4.8 million in fines from New York and Presbyterian Hospital and Columbia University, after they submitted a joint breach report that dates back to September 27, 2010.  And to resolve a HIPAA breach case from over two years prior, Concentra Health Services and QCA Health Plan, Inc. agreed to pay a combined $1,975,220.00 in April 2014.  That’s right, nearly seven million bucks combined.  These must have been just ridiculously egregious breaches, you say.

Well, not exactly.

In the first case, resulting in the highest HIPAA-related fines yet, Patrick Ouellette reports that the electronic personal health information (ePHI) of 6800 patients was exposed to internet search engines, related somehow to an application developer’s deactivation of a personally-owned server.  My guess is that the dev didn’t do a comprehensive wipe on his testing machine, so when he started his next project… ouch.

In the second case, a laptop was stolen from an employee’s car outside of a physical therapy center in Missouri.  It contained ePHI of 148 patients… and the laptop had not been properly encrypted.  This was the key ingredient to becoming a major example set by the Office of Civil Rights (OCR).

Although HIPAA regulations draw no distinction between health information that is more sensitive (oncology lab test results, Center for Disease Control type stuff, etc) and clearly less sensitive (patient progress reports while rehabbing a torn meniscus, for example), we can say with reasonable confidence that this small local physical therapy center’s data was likely in the latter category.  But like I said – HIPAA makes no distinction.  The relatively small pool of potentially affected patients made no difference, either.  The OCR’s investigation yielded evidence of perpetual compliance violations and a general policy of ignoring the regulations.  That is the recipe for trouble, and the financial repercussions are clearly major.  Encryption is a baseline for medical data security.  It should be considered a non-negotiable starting point, but certain institutions continue to drag their heels.

Let me paint you a picture.  To seasoned criminals planning a heist specifically to harvest patient data, encryption is a deterrent, but does not make a system impregnable.  By comparison, virtually all of these incidents are inadvertent – a lost tablet here, a stolen laptop there.  Encryption is extremely effective in these scenarios, to keep the equipment loss from escalating to a full-blown breach.  In short, it keeps a hack from becoming a hacker.  It insures that the local juvenile delinquent who puts a brick through a window just to grab a four year old PC to sell for drug money will be doing that – and nothing more.  The laptop will be a brick itself shortly thereafter, and you can be confident that the smash-and-grab will not expose patient data in plain text, and will not yield a two million dollar price tag.  ePHI is safely obfuscated, and your biggest problem will be deploying a new laptop to your employee.

Simple, right?  Then why is this still like pulling teeth for some providers?

Kamala Harris

Kamala Harris

If the financial penalties aren’t a strong enough motivator, litigation is on the table as well.  California’s Attorney General Kamala Harris has made no secret of her interest in the topic, offering medical identity theft prevention tips to the public this fall.  This winter, Harris filed suit on behalf of California against Kaiser concerning a 2011 breach in which an unencrypted external hard drive was sold at a thrift store, containing a plain text database of Kaiser employees, along with Social Security numbers, dates of birth, addresses… and oh yeah, their family members’ information too.  Worse, Kaiser only alerted about 10,000 of the 30,000+ affected employees.  Not pretty.

So now you’ve got the OCR looking to fine you, the Attorney General suing you, and we’re not done yet.  Just like in the enterprise environment, you can’t even rest once you’ve trained employees and given them some tools.  You still need to safeguard against disgruntled or malicious employees.  “You won’t give me a new laptop?  Fine.  I’ll just ‘lose’ this old one.” Or worse, “You won’t give me that 5% raise? Fine. I’ll just ‘lose’ my unencrypted device and we’ll see how much you’ll pay.” Scary stuff.

Susan McAndrew

Susan McAndrew

The stance of the OCR is clear, and it is straight forward.  “Covered entities and business associates must understand that mobile device security is their obligation,” said Susan McAndrew, OCR’s since-retired deputy director of health information privacy. “Our message to these organizations is simple: encryption is your best defense against these incidents.”

Michael Leonard

Michael Leonard

It should be a no-brainer, but we continue to see companies holding out.  Iron Mountain’s Director of Product Management for Healthcare IT, Michael Leonard, commented recently on this.  “From our perspective, it is – I’ll say ‘puzzling’ – that organizations don’t encrypt more of the content even within their four walls.”

I’m not sure ‘puzzling’ is strong enough.  Idiotic, maybe?  Concentra Health Services and QCA Health Plan, Inc. were forced to cough up more than $13k per patient whose record was exposed, and that may just be the tip of the proverbial iceberg.  HHS Chief Regional Civil Rights Counsel Jerome Meites predicted an increase in fines from the $10M assessed in the last twelve months by the agency.  “Knowing what’s in the pipeline, I suspect that that number will be low compared to what’s coming up.”  That’s ominous, and should be a wake up call to anyone who thinks that they can simply fly under the radar.

The reality is that encryption should be automatic.  It should be offered in every software solution deployed to healthcare providers at every level.  To help reinforce the transition, SafeLogic provides FIPS 140-2 validated encryption for these solutions.  Remember, in the eyes of the federal government, only cryptographic modules certified by the CMVP are considered acceptable.  This assessment has extended to the healthcare industry as well.  HIPAA’s requirements have not yet explicitly required the use of FIPS 140-2 encryption exclusively, but customer requests already do, and the writing is on the wall for future versions of the standard.

For more information on the role of validated encryption in HIPAA regulations, please download SafeLogic’s whitepaper.

BlogFooterWalt

31 Oct 2013

New White Paper: Addressing the Common Criteria Protection Profiles for Mobility

commoncriteria_logoLast week, the US Government’s Common Criteria Evaluation and Validation Scheme (CCEVS) announced Protection Profiles for Mobile Devices (MD) and Mobile Device Management (MDM) systems.  The Common Criteria is an international standard for the evaluation of security features within IT products.  It is also widely recognized as a crucial certification needed for products seeking addition to the Unified Capabilities Approved Products List (UC APL), administered by the U.S. Defense Information Systems Agency (DISA).  Products which successfully earn addition to the UC APL become eligible for procurement and deployment by the various agencies of the United States Department of Defense.

These new Protection Profiles embody the requirements that are to be met by a specific technology type in Common Criteria evaluations.  The Mobile Device Protection Profile (MDPP) contains the security functional requirements for mobile devices such as smartphones and tablets.  The Mobile Device Management Protection Profile (MDMPP) includes the security functions to be evaluated including key protection, protected communications, mobile device configuration, and administration.

Cryptographic support functions are critical requirements in these new Protection Profiles, as anticipated.  It is important to note that while many vendors pursue both Common Criteria certification and FIPS 140-2 validation, the latter does not automatically satisfy the former.  The encryption requirements in these new Protection Profiles reflect certain standards imposed by NIST for FIPS 140-2, but they are not interchangeable.

We are proud to present a white paper explaining the cryptographic elements of these new Protection Profiles, available for immediate download.  This paper also presents information on how CryptoComply, our drop-in module, addresses and meets each encryption requirement for the MDPP and MDMPP and discusses the benefits of leveraging the crypto module.  CryptoComply integration is streamlined, designed to eliminate the several engineer-years it would take to build and implement these functions.

ApiTech_LogoResizeFor a real life scenario, please refer to SafeLogic’s Case Study with API Technologies, also available for immediate download.  API Technologies was seeking an updated listing on the UC APL, and they were able to accelerate the process by integrating CryptoComply.  In tandem with SafeLogic’s RapidCert, API Technologies satisfied all requirements and proceeded directly to the JITC testing phase.

For SafeLogic customers who integrate CryptoComply, drop-in compliance is just the first advantage.  RapidCert is a huge differentiator for those who seek FIPS 140-2 validation, while CryptoComply Professional Services brings SafeLogic’s expertise to the table, whether that entails custom software development, Common Criteria consulting, or something else altogether.  Our goal is to make these processes as easy as possible.

23 Sep 2013

Look What the NSA Dragged In

LookWhatNSA

There are many changes to track in the world of standards-based crypto, another on the long list of challenging facets in this industry.  These changes can sometimes include the algorithms themselves.

NIST Special Publication 800-131A defines transition timelines for what NIST considers to be weak or weakening algorithms.  It makes sense; as computing power increases, the underlying strength of cryptographic algorithms (whether for encryption or hashing) diminishes.  This is tricky business though, as some of these algorithms are part of protocols implemented by technology vendors and are widely supported and adopted by the industry.  It’s hard for some folks to develop towards those changes because of user adoption, customer environments, backwards compatibility, and other reasons, but eventually the algorithm must be phased out.

We are currently facing an entirely different and even more rare algorithm change, which requires quick action and leaves little time for a planned transition.  It was the direct result of the discussions on surrounding entropy sources and the 800-90 series of draft Special Publications from NIST.  SP 800-90A is titled “Recommendation for Random Number Generation Using Deterministic Random Bit Generators” and does just that.  However, one of the methods listed is now under scrutiny, and NIST has re-opened the public comment period to address concerns from the community.

The end result is a consensus revocation of confidence in the security of the Dual EC DRBG algorithm.  In the wake of the NSA revelations, the industry has become very sensitive to potential conflicts of interest and this algorithm is suspected of containing backdoors.  Even though Dual EC DRBG is a FIPS-approved algorithm, NIST is currently recommending against using Dual EC DRBG until SP 800-A is re-issued.

In this context, SafeLogic issued a notice on our support portal.  SafeLogic agrees with NIST’s evaluation and we discourage the use of Dual EC DRBG until further notice.  Fortunately, there is no impact to our FIPS 140 certificate, our customers’ FIPS 140 certificates, or our customers’ products and solutions. Dual EC DRBG is one of many algorithms available for use within CryptoComply for Mobile and CryptoComply for Server modules, but requires specific customer action to select and activate the algorithm in question.  Our default is AES 256 CTR, which is covered in Section 10.2 of SP 800-90A, and if that is not your preference, there are several other options that are still endorsed by NIST.

Of greater concern is the prevalence of use across the industry.  While SafeLogic has not promoted the use of Dual EC DRBG, it is the sole algorithm in use for some solutions.  In others, including the entire RSA BSAFE family of cryptographic toolkits, Dual EC DRBG is of primary importance and is used as a default algorithm in every version of BSAFE and Data Protection Manager (DPM).

RSA responded by making a similar announcement, advising all developer customers to discontinue use of the algorithm immediately.  They plan to update their libraries ‘as needed’ and ‘change the RNG as appropriate’ as well.  This, of course, does not help existing customers, who must follow technical guidance provided by RSA to update their own implementations.  This is no trivial undertaking and is by no means immediate.  RSA has provided a complicated and time-consuming recipe for an antidote, while the poison itself is already at work.  While I’m sure many developers spent their weekend on this, the popularity of RSA’s BSAFE product line leaves a high probability that there are many more still vulnerable and struggling to respond.

If you are in this group, please reach out.  SafeLogic is making the team available to answer any questions you may have about algorithm selection, how to respond to these advisories, and how CryptoComply may solve your issues.

BlogFooter_Ray

12