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.

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

How Cloak Labs Transforms Enterprise Messaging

Our customers need resilient, secure and easy-to-deploy application  messaging solutions that meet their changing demands. As more and more buzz around the cloud, application migration, security and compliance percolate to the surface, Cloak Labs has peaked the interest of more and more CIOs and Infrastructure Managers.

Transform: Cloak Labs enables enterprises of all sizes and industries to transform how they connect applications. Our cloud-based infrastructure provides scalability, embedded security, resliency and economies of scale. Because of the Cloud, our customers can rely on a service based messaging infrastructure, allowing managers to focus on mission critical tasks instead of deploying and managing costly VPNs and hardware.

Manage and Serve: As a service, Cloak Labs provides a robust network that guarantees the delivery of every message as well as providing “military grade” security and encryption.

Build: With Cloak Labs you can build application interfaces in minutes regardless of the application or transport protocol.

Consume: Cloak Labs’ application messaging services are easy to consume and do not require any hardware installation or IT training.

Application Interfaces: VPNs are not the answer

You have a new application, vendor or hospital that you need to interface to. Everyone in meeting grumbles about how the application interface will be built, where the resources will come from, and who’s budget will take the hit for adding the new partner.

To get started, you start thinking about everything that will need to happen:

1. A new VPN connection will need to be created to bring the new trading partner onto the network… paperwork with the hosting company or telco, network configuration changes, firewall ports opened, etc.

2. Depending on the application or partner you are working with, you need to understand what interfaces you will need support/build, e.g. does the application have a specific transport protocol you are not familiar with, is there a specific message protocol that you will need to convert

3. Specialist that have worked with these types of interfaces will need to be selected and contracted

4. Depending on how many connections you are creating, you may need to bring on additional staff to manage and support these connections

5. If any value added services such as guaranteed delivery or file tracking need to be implemented, this will increase the scope of contract work

6. Each connection will need to be tested thoroughly

VPNs provide the basic necessity of secure connectivity, but they are a unwieldy solution for IT organizations that are faced with deploying many connections and are limited on technical resources, time, and money.

When working with new trading partners, healthcare application interfaces, or vendors, VPNs may not make the most sense for your needs. Think about some of the problems you may face when adding new VPNs and how you can mitigate those pain points:

1. Are there other secure, application connectivity solutions available? If so, do they offer the most basic needs for interoperability?

2. Does the VPN solution offer file-level tracking, encryption, guaranteed delivery and web portals to view message and data traffic?

3. Are there solutions available that do not require changes to the firewall and/or network

4. Is there a solution that will require minimal IT support, reducing the total cost of ownership for maintaining secure outbound connections?

5. Will these connections continue to meet changing government standards for connectivity or will additional work need to be done to keep them compliant?

6. Is there a solution available that does not take weeks or months to implement?

There are many more questions to be answered, but the basic question is “can you find a better way?”. As technology advances and the Cloud becomes a more trusted platform for offering services, it may be time to start seriously evaluating alternatives to VPNs.

FTP is a Bad Idea

July 14, 2010 / CloudPrime, Security / 0 Comments

bad-toasterApplication-to-application messaging is a critical component of most enterprise grade organizations. On a daily basis, tens if not hundreds of thousands of application messages, files, requests, etc. are processed over their messaging fabric. What is interesting to note is how a lot of organizations are creating their application messaging network. For lack of a better solution, a lot of organizations are relying on FTP to transmit sensitive data over the network. This is bad.

FTP is a simple protocol that allows for the exchange of data over a network, but it should NOT be depended upon for sending any information that is regarded as sensitive or confidential in nature. The reason why FTP is a problem is because it does not encrypt data as it passes over the network and you only need a username and password to send/receive files. The real threat is that messages can be sniffed out or intercepted en-route, exposing each party to big-time security problems.

There are some simple ways to help secure FTP transactions, but for the most part, it is still an unsecure and unreliable way to send messages and by some estimates can cost an organization $300k to $1M per year in maintenance and recovery costs, even though FTP is “free”.

To further mitigate the issues with FTP, a lot of organizations will employ “roll your own” solutions that help secure the message network and provide the necessary features needed to comply with various requirements and compliance regulations. Where this becomes an issue is that typical RYO solutions can be rigid, hard to maintain, and are expensive to deploy (not to mention the resources that will be needed manage and update the network on a regular basis).

In the end, both FTP and “Roll your own” solutions leave a lot of gaps in an organization’s application messaging infrastructure that not only may hurt them from an operational and security standpoint, but end up costing them millions in maintenance and recovery costs.

Cloak Labs solves these problems by providing a completely managed service that allows applications to communicate with each other in a secure, reliable, and cost-effective way.


  • Cloak Labs’ patented technology makes sending messages through “the Cloud” safe
  • Guaranteed delivery of all transactions
  • Non-repudiation
  • Rules-based, encrypted message archival
  • Easy to deploy software Security Gateways
  • No hardware to buy or upgrade

To learn more about how Cloak Labs can help your organization implement secure and reliable application-to-application messaging network, contact us today.