Asymmetric Risks in Value Chains

October 28, 2014 / Integration, Security / 0 Comments

Big_&_Small_PumkinsBusiness need to connect with other businesses to trade and add value. Making trading fast and efficient means integrating software systems. And that means risk.

Letters, faxes, and telegrams may seem slow and quaint but at least they had the virtue of being safe. In today’s environment clicking on an unsafe link or opening an innocuous file can potentially lead to a billion dollar loss or even the end of your company.

Following last year’s massive Target breach attention has moved to Wall Street; the JPMorgan breach is causing state and federal regulators to add to the already massive internal pressures to improve security. One particular area of attention is the risk that comes from 3rd party vendors.

New York State’s top financial regulator, Benjamin M. Lawsky, emphasized the gathering danger to the financial system when vendors’ security is lax.

There are several critical problems in dealing with 3rd party risk. The first one is that the risk exposure is hugely asymmetric in most cases: one party has much more to lose than the other. This leads to the second problem which is that the smaller party can’t afford to spend nearly as much as the larger one on cybersecurity. The skill of their security staff will be lower, they will have fewer tools at their disposal, they may even be too small to afford round-the-clock monitoring. They also probably cannot afford enough insurance to compensate their larger partner for losses.

The first instinct of the larger party is to seek to impose their internal security standards on the smaller party; the goal is to avoid the smaller party becoming the weak spot in the fortress wall. This has the effect of raising trading costs. If the smaller party is a vendor then that vendor will need to raise their prices to cover the extra security costs. At some level those costs may become prohibitive; at my previous company we ended up no-bidding certain RFPs because the attendant security overheads were too high relative to the deal size. The next thing to suffer is agility: vendors whose security has been certified become automatically preferred for future work because of the time and expense involved in certifying new vendors. This reinforces the upward pressure on prices as incumbents are protected from new competitors. Innovation suffers as well.

How can businesses integrate with their value chain without taking on untenable, asymmetric risks? The Cloak Labs Global Virtual Bus provides businesses with a way to loosely couple with their partners. Using a combination of cryptographic and network techniques, the Global Virtual Bus can insulate each partner from the security risks of the other. Credentials do not need to be exchanged, firewall ports do not need to be opened, connecting servers do not need public IP addresses.

Learn More! Download the White Paper!

The Feds Fear of Unbreakable Encryption

October 7, 2014 / Conversation, Security / 0 Comments


Recently Apple announced they have strengthened encryption on its mobile (IOS) devices to the point that it can no longer decrypt their contents on behalf of the government, even when presented with a valid search warrant. Google followed suit, announcing that Android devices would be encrypted by default.

On the heels of the unauthorized release of nude pictures of many celebrities, apparently purloined from iCloud with stolen/hacked credentials, many might see these moves as being strongly in the interest of consumers’ privacy.

The director of the FBI, James Comey, begged to differ. Attorney General Eric Holder followed suit. Both cited concerns about such encryption hindering criminal investigations.

The US government has been fighting strong cryptography for years. Cryptography has been classified as armaments and subject to export controls. The US (and the UK) benefitted strongly from a cryptographic advantage in World War II and through much of the cold war: the US could break its enemies’ cyphers but not vice-versa. In 1993 the NSA introduced the clipper chip and tried to make it a standard. This effort failed spectacularly as the market completely rejected a chip that contained a backdoor for the NSA.

Cloak Labs is committed to protecting data privacy. The very idea of a master key or a backdoor into a security system is anathema to those who are serious about security.

The security industry’s efforts to improve security were bolstered by Edward Snowden’s revelations about widespread NSA wiretapping activities in 2013. For example there are now a number of secure email systems (ex: Proton Mail).

I believe that what is really concerning the US government is the idea that encryption is moving from being something optional that is hard and error-prone to configure to something that is standard, default, and easy (specially given Apple’s focus on ease of use). Criminals might not bother to setup security or might set it up incorrectly. Now Apple and Google are protecting even the dumb criminals who are just buying phones at their local store.

By abusing their surveillance powers so egregiously for so many years the US government has lost significant goodwill with a large segment of the American public. Not only do consumers want to be protected from lawless hackers, many of them no longer trust their own government. Parallel reconstruction, where an intelligence agency that nominally targets foreign intelligence targets provides secret intelligence to domestic law enforcement agencies who then reconstruct it in order to make it admissible in court, makes a mockery of the rules of evidence.

It’s extremely unlikely that congress will pass legislation that requires companies such as Apple and Google to make it possible/easier for the government to access private information. If they did, it would cripple American products in global markets.

Device encryption will force the government to get a suspect to provide their password (or fingerprint) to unlock it to access evidence. In some cases the courts have held that a defendant cannot be compelled to provide a password since they might incriminate themself by doing so. In other cases the courts have compelled a defendant to reveal their password. This might make for an important Supreme Court case someday.

Cybersecurity Represents the Internet’s Technical Debt

August 20, 2014 / Security / 0 Comments

Not very long ago and not very far away, scientists, engineers, and possibly Al Gore, began inventing the fundamental building blocks of the Internet.

Internet Timeline

Development of the Internet from Arpanet to W3C (Internet Society Graphic)

During this period of accelerating invention, those making the important discoveries were primarily concerned with getting things to work. Few networks were connected together and those that were tended to have close relationships and a high degree of trust. A network inside a building or facility was secured by physical access. Password access to the local network was largely sufficient.

Security was always an afterthought
The hacker movement closely followed the development of the Internet. In the 1970s many hackers amused themselves by hacking phone networks, so called phreaking. One of the first large scale network hacks was an attack on 60 institutions including Los Alamos Laboratory and the Sloan Kettering Cancer Institute. The first firewalls emerged in the late 1980s as basic packet filters. It wasn’t until the 1990s that researchers begun working on layering security on top of TCP/IP, the fundamental protocol of the network, which unfortunately happened to be fundamentally insecure (no encryption, no authentication of access points, etc…). DNS, the service that translates natural language names such as into machine addresses such as, was also fundamentally insecure. Work on DNSSEC didn’t start until 1990.

Enter Technical Debt

Technical debt is a metaphor referring to the eventual consequences of poor system design, software architecture or  software development. The debt can be thought of as work that needs to be done before a particular job can be considered complete or proper. If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on.

Technical debt is incurred in almost every software project of any complexity. There’s always a nagging bit that could have been done better, an interface that should have  been exposed, test cases or documentation that should have been written. Projects incur technical debt because of lack of time, lack of resources, sloppiness, poor training, poor vision, and countless other reasons. However there’s little doubt that most projects would never ship if all the technical debt had to be paid beforehand. The Internet is not a single project, it is a mammoth collection of smaller projects, with the core projects having significant debt on the security side.

Move fast and break things. Unless you are breaking stuff, you are not moving fast enough. – Mark Zuckerberg
The entire internet security industry, including Cloak Labs, owes its very existence to the technical debt incurred by the designers of the Internet. Of course the Internet would still be under construction if it had been required to be secure from the very beginning; you wouldn’t be reading this in a web browser or on a mobile device and you’d be wondering what to do with all the free time you would have had from not having to keep up with Facebook and Twitter. Those closely concerned with cyberwarfare have even advocated that we shouldn’t have an Internet due to the high risks it creates for our modern infrastructure (power, water, financial services, transportation, healthcare, …) Have we amassed so much technical debt that our economy will eventually crash, not unlike what happened with mortgage debt in 2008? If you had been one of the inventors of the Internet, what would you have done differently knowing what you know now?

When you park your data do you hand your keys to the valet?

August 5, 2014 / Security / 0 Comments

Car Keys

Security remains a top concern for IT managers considering the cloud. This is symptomatic of trust issues when working with cloud providers. After all, when you hand your precious data over to a cloud provider in general you are also handing over the keys! Just like when you valet your car. You’ve never met the young gentleman with the red vest and the bow tie but you are handing him the keys to your brand new Mercedes! Your corporate data could be worth much much more.

Once you’ve handed the valet the keys to your data you have no control over how he (she) handles those keys or who they might share them with. This applies to your data as well. The primary fear is that hackers might gain access to your data and exploit it, resulting in loss of your business reputation and real money. Cloud applications, even when they are encrypting data in the cloud, have the keys to your data somewhere. Exploiting the application may reveal the keys or the application might be altered into revealing your data.

Inadvertent release (leakage) is also a possibility. The application may have a bug or security hole that someone might stumble into. The application thinks you’re asking for your own data but the requestor is actually someone else. Such errors are unfortunately all too common.

Then there’s access by state actors. For data stored in the US, the US government has several legal tools available to get access to your data without you ever being informed. If you’ve given your keys to the valet, the feds present the right legal documents to the valet (subpoena, national security letter, sometimes even less) and the valet gives them your data. Recently a NY court held that the US also has legal authority to request data that is stored overseas! This brings new legal risks for data stored everywhere. Foreign authorities may start making requests for data stored in the US by US companies that have overseas subsidiaries. European efforts to keep data in-country may become moot if the providers have presence in other countries. While one of the key benefits of the cloud is to make location irrelevant if this NY judge’s decision is upheld there could be a significant legal downside. Companies will feel that if they hold data in their own data centers at least they will be informed when their data is being requested by authorities.

At Cloak Labs we don’t hold our customers’ private keys. Only the sender and recipient of a message can read its contents. We don’t have to ask you to trust our cloud infrastructure, encryption and decryption happens on your premises. Our cloud infrastructure just queues and transports encrypted messages. Were we to be subpoenaed for your data, we would of course legally be forced to cooperated, but all we could provide authorities with is highly encrypted messages. We don’t wear shiny red vests and bow ties and we don’t have the keys to your data.

CloudPrime is now Cloak Labs!

May 16, 2014 / News / 0 Comments

We are pleased to announce that we are changing the name of our CloudPrime operating company to Cloak Labs. This name change is designed to better focus our brand on what we actually do: protect and secure your high value data.

Although the CloudPrime name is very straightforward, in practice it turned out that while many people correctly understood that the Cloud in CloudPrime meant we were a cloud-based company, the Prime didn’t immediately evoke prime numbers and cryptography. As a computer scientist might say, it was one level of indirection too far from obvious.

The Cloak in Cloak Labs refers to our first mission, which is security. We’re here to secure your messages from everyone except the intended recipient. That includes us: we don’t have the keys to your messages and we can’t decrypt them even though each one passes through our network (actually twice, for redundancy and reliability).

The Labs in Cloak Labs reflects who we are: computer scientists, security experts, engineers. We wear the lab cloaks so you don’t have to. Our job is to keep making our service more secure, more reliable, easier to use, more scalable, and more open.

In conjunction with the name change we’d also like to announce our new website:

In the near future when you visit you will automatically be redirected to

The new Cloak Labs website includes a number of new pages describing our product. It also integrates our blog directly into our main webpage. This way visitors don’t have to deal with two different sites. The new site is also mobile-responsive and touch-compatible so you can visit on any phone or tablet as well as using your desktop or laptop – the information is the same from any device just presented in a way that best suits each device!

It’s going to take awhile to change our software itself to reflect the Cloak Labs brand but as we visit each module in our code to improve it we will do just that. In addition, customers should continue to use “CloudPrime” on checks until we update our billing processes.

Years ago a wise man told me that A “brand” is a promise made to its customers. It’s not just a name or a tag line. Our promise to you is that we will keep your messages secure and deliver them reliably; cost efficiently and with minimum effort on your part. By doing that we will also keep your enterprises more secure against ever increasing security threats.

If you’d like to keep up with the exciting things that are happening at Cloak Labs, please visit and read our blog at We’ll also continue to update you occasionally via email as well; hopefully not too often!

Thank you!

Dr. Michel Floyd
CloudPrime Cloak Labs

The Gap in HIPAA’s Requirement for Encryption in Transit and at Rest

This post is going to get a wee bit technical so bear with me. There is a well publicized HIPAA requirement that

PHI (protected health information) must be encrypted in motion and at rest.

This requirement has been interpreted to mean that:

  • PHI transmitted over a network (or even carried via removable media) must be encrypted
  • Data on disk must be encrypted

HHS documents often refer to NIST’s Guidelines on TLS. (TLS is what has replaced SSL except in normal discussion). What the current Heartbleed problem with OpenSSL lays bare for all to see is the gaping hole in what encryption in motion can mean.

The problem is that for the most part the encryption in motion is different than the encryption at rest. Different algorithms and keys are used and different systems have responsibility for crypto. Simply put, this requires the data to be unencrypted when moving from the network to the disk.

Cloak Labs’ technology allows a message to go from one server behind a firewall to another server behind a second firewall without exposing either server to the outside world. Inbound firewall ports don’t need to be opened on either side and the data stays encrypted in webserver RAM, essentially adding an extra barrier between your sensitive data and potential attackers.

Defense in Depth: Why SSL is not Enough

April 10, 2014 / Healthcare, Security / 0 Comments

This week’s revelations of the Heartbleed defect in OpenSSL has been eye opening for the entire Internet. Bruce Schneier labeled it “Catastrophic. On the scale of 1 to 10, this is an 11.”

The Snowden revelations raised our collective concerns for the security and privacy of the internet. Even those who attribute only noble intentions to the NSA realize that if the NSA can crack a code then perhaps less savory actors can as well.

SSL is something we’ve all taken for granted as something that just works to keep internet connections secure. As computers have gotten faster key lengths have increased. The SSL algorithm itself has been replaced by TLS but the old name has stuck around. SSL has been so useful and simple that it has been embedded into every browser, almost every VPN, and now even in thermostats and smart refrigerators. The Internet security community has figuratively put almost all their eggs in one basket. That metaphorical basket has just been dropped on the floor and now we have a cleanup on aisle 4 of epic proportions.

At Cloak Labs we have reviewed our production and development systems to make sure that we are not vulnerable. Our enterprise messaging system does not use the defective version of OpenSSL and was never at risk. We did have to patch one of our WordPress servers but that was about it.

But more importantly, Cloak Labs’ messaging technology provides defense in depth. Even if we had been running a defective version of OpenSSL the RSA and AES layers used to protect your messages would have not been compromised. The security provided by AES is second to none and Cloak Labs’ robust approach to PKI makes compromise of the RSA layer virtually impossible.

At Cloak Labs we enjoy using fortresses as visual metaphors for network security. In that vein, here’s SSL:

Frontier Fort

Frontier Fort (Courtesy PublicDomainPictures)

And here’s Cloak Labs:

Vauban Fortifications

Defense in Depth as Designed by Sébastien Le Prestre de Vauban

Vauban was one of the foremost military engineers of the 17th century. He mastered the concept of fortification in depth. I learned about him studying about the past glories of France in the French expat schools I attended as a child.

Which fortress would you rather be inside of?

Dr. Michel Floyd
Cloak Labs

KISS principle comes to mind – Keep It Simple and Secure

June 19, 2013 / CloudPrime, Security / 0 Comments

As a former colleague said to me after hearing about my new job, “I always knew your head was in the clouds.”  Well, I guess he was right.  If your head isn’t in the clouds yet, it’s time to learn about a cloud-based Messaging as a Service (MaaS), solution.

But, what is the value of application messaging in the cloud anyway?

If the goal of your organization is to remain competitive in today’s marketplace, it is already growing the business by adding new partners.  But, for those in IT, on boarding new partners comes with a host of problems.  It’s not easy to share data securely and quickly across applications and sites.  Forget about adding a VPN for each new location – the task is too challenging to do quickly, and the costs go through the roof.  That’s not going to make any boss happy.

So, what can be done to achieve the results management is looking for?

In this case, the KISS principle comes to mind – Keep It Simple and Secure!

  • Use your existing network connectivity – Don’t spin-up new VPNs.
  • Remember last mile locations – Most have low bandwidth and usually, the IT support staff is the office administrator.
  • Keep costs down – Don’t go asking for any capital funds from the IT budget.
  • Provide guaranteed delivery – Make sure it gets there so you don’t have to worry about re-transmits.
  • Make it simple to deploy and support – Hey, you’ve already got a full time job and don’t need another one, right?
  • Be best friends with the auditors – Keep them happy by giving a detailed audit trail of every transmission.

To learn more, read the IBM QuickView. Reposted from

Amy Auman, CloudPrime

Athena Health: More Disruption Please

October 10, 2012 / CloudPrime, Healthcare / 0 Comments

I recently spent an amazing two days at the Point Lookout Resort in Northport, Maine with a community of “disruptors”.
Athena Health’s second annual More Disruption Please Conference, an event aimed to accelerate disruptive innovations in health care, brought together more than 100 CEOs, entrepreneurs, Venture Capitalists, academics, and software engineers to discuss ways to drive the industry towards innovation, openness and collaboration.

Traditionally, the healthcare has been an industry driven from top down. After attending this conference, I realize this is going to change dramatically. Bringing innovative technologies into healthcare will change the way information is distributed and transferred. These technologies will enable doctors to spend more time with their patients and give them better care.  The less time the doctor has to spend on paper work and transferring information, the more time they will have for their patients.

Our world is ready for a disruptive innovation in healthcare.

From my conversations at the conference, it is clear that the first phase of this disruption is the use of smartphones and the process has already begun. I decided to test this by looking for diabetes apps on my phone and 20 came up! Can you imagine the global impact this will have? Technology is global and allows us to have access to people instantly–We can have a specialist in Iceland look at our chart in seconds. Just think about the billions of users this can benefit?
While we are already seeing disruptive innovations working, I believe a dramatic difference will be seen within the next five years. In underdeveloped areas we are seeing a huge difference as they are coming from a clean sheet of paper.
Cloak Labs is a disruptive innovation. We supply the secure messaging that medical applications can interface to. Cloud computing in general will have a huge impact in healthcare. Costs of healthcare will be reduced, we will have greater access to industry specialists across the globe, and we will have easier communication. The percentage of smartphones is rapidly increasing which will enable this change.

This is not just hype, it is reality. Once the applications are in place, we will all see a disruption in healthcare and many other industries, for that matter.

The Cloud in Healthcare – Top 10 Takeaways from iHT2 San Francisco

March 30, 2012 / CloudPrime, Healthcare / 0 Comments

In the spirit of David Letterman’s top 10 lists here are our takeaways from the San Francisco iHT2 event this past week.

  1. IHPs (large integrated health providers, like university systems, etc), are by and large going with EPIC for EHR solutions, thereby automatically forgoing a degree of flexibility and any chance of real near-term interoperability.
  2. The historical problems of security, reliability, and control with Cloud-based solutions are being rapidly overcome, and the cost savings from hosting data and applications in the Cloud are becoming so compelling that increasingly complex medical organizations and systems will require the Cloud in order to be effective and efficient…..or risk becoming extinct.
  3. The HealthCare system, as usual, is the last great industrial complex to accept collaboration and efficiencies based on advances in information technology.
  4. There has been a dramatic shift in the last two years toward the use of mobile and portable devices in all aspects of care, and this will only increase.
  5. Nobody can really define the phrase  “HIPAA compliance,” it is best approached and understood as a process, it is not just about security.
  6. 30% of the vendors sponsoring were cloud-oriented.
  7. Edge, last-mile connectivity in a HIPAA compliant fashion was a common pain point from small patient practices to large integrated health providers.
  8. Cloud-based or service platforms having the ability to be more nimble and in turn handle the growing complexity of connectivity, interfacing, and interoperability are available and should be considered.
  9. The cloud mitigates the need for traditional software upgrades and release cycles.
  10. CIO’s and CMIO’s are opting to outsource for best-of-breed services and applications.  Driven by skilled resources in healthcare IT becoming increasingly scarce and more robust SaaS/cloud-based options being available.