Tag Archives: cryptocurrency

How to Stop Ransomware

When notorious criminal John Dillinger was asked during the Depression why he robbed banks, he famously replied: “Because that’s where the money is.” That simple observation may offer an answer to the surge of ransomware.

Even as companies struggle to strengthen their protections against hackers, we can target ransomware payments in some quite straightforward ways — and, if the criminals can’t get their money, what’s the point in hacking?

As this essay in the New York Times argues, “The United States does not have a ransomware problem so much as it has an anonymous ransom problem. If we can change the payment system to make the kidnapping [of businesses] less profitable, we will go a long way toward a solution.”

The author, Paul Rosenzweig, a former senior official in the Department of Homeland Security, says 95% to 98% of criminals involved in kidnaping people for ransom are caught and convicted, partly because they can be identified when the transfer of money occurs. By contrast, hackers demand ransomware in cryptocurrency, which, as of now, is extremely hard to trace.

Rosenzweig argues that the U.S. government could simply “adopt and enforce regulations for the cryptocurrency industry that are equivalent to those that govern the traditional banking industry. Cryptocurrency exchanges, ‘kiosks’ and trading ‘desks’ are not complying with laws that target money laundering, financing of terrorism and suspicious-activity reporting….

“For example, some cryptocurrency services offer a ‘tumbler’ feature. Tumblers take cryptocurrencies from many sources, mix them up and then redistribute them, making financial transactions harder to trace. This practice looks like money laundering and would be illegal in the nonvirtual world.”

Even though countries like Russia will probably continue to offer safe havens for ransomware thieves, the U.S. can take unilateral action and “refuse access to [the U.S. banking system] by cryptocurrency exchanges unless they demonstrate that they are equipped and prepared to prevent ransomware payoffs…. To be fully valuable, digital currency must also be convertible to cash, so the exchanges would have a strong incentive to comply.”

The U.S. could also require foreign banks to “impose stricter regulations on cryptocurrency. Because access to the American financial market is vitally important to foreign banks, they, too, would have a strong incentive to comply.”

There has been at least a bit of precedent for tracking and recovering the cryptocurrency used to pay corporate ransoms — after hackers shut down Colonial Pipeline in early May and were paid a ransom in Bitcoin that was valued at $4.4 million at the time, authorities recovered 85% of the Bitcoins.

There is also precedent for blocking illegal activities by cutting off access to the banking system. I saw an instance up close and personal in the mid-2000s when I was working on a book project with one of the world’s top poker players. He was involved in one of a series of high-profile efforts to take the popularity of poker on cable-TV and leverage it to build a massive online gambling site. While online gambling was illegal in the U.S., plenty of jurisdictions in the Caribbean were willing to host the site. Then the U.S. enacted a law that imposed major penalties on any U.S. bank that handled transactions for online gambling sites. And that was that. All the attempts at building national online poker sites shriveled up and died.

I suspect that companies and their insurers will still bear the brunt of ransomware for some time to come. Companies will need to shore up their defenses, with advice that insurers have developed by working with many clients across multiple industries and with technology companies that are working to stay one step ahead of the hackers. But aggressive action by the federal government could reduce ransomware significantly by going after the flows of money.

I look forward to the day when someone writes an article declaring the end of this scourge. I even have a headline in mind:

“Ransomware: Where the Money Isn’t.”

Cheers,

Paul

Future of Insurance to Address Cyber Perils

Standalone cyber insurance can successfully address a subset of privacy and security costs related to personally identifiable information, personal health information, payment card industry losses and increasingly some business interruption. However, outside of four industries (retail, hospitality, healthcare and financial institutions) generally no single insurance policy adequately covers cyber perils that result in funds transfers/crypto losses, bodily injury or tangible property damage-type losses. Organizations of all sizes, geographies and industries increasing rely on data analytics and technology, such as cloud computing, Internet of Things and artificial intelligence. These advancements add new and unique cyber exposures. Modeling of worst-case cyber scenarios compared with a review of the scope and exclusions of the base forms of multiple lines of insurance reveals potential material gaps in cyber coverage.

The number of cyber incidents with losses greater than $1 million (through early September 2018)

Recognize Financial Statement Impact

According to the Risk and Insurance Management Society, organizations’ total cost of risk declined for the fourth year in a row in 2017, but cyber costs moved in the opposite direction, rising 33%. Most boards of directors and management now include cyber perils and solutions in corporate governance discussions as they learn more regarding the potential financial statement impact of high-profile cyber incidents. Yet, organizations only insure a relatively small portion of their intangible assets compared with insurance coverage for legacy tangible assets.

Prudent organizations will spend the appropriate amount of time and resources on the risk management areas that are likely to have the greatest return on investment. For example, a disproportionate amount of attention is focused on cryptocurrency exposures, which affects a relatively small proportion of the corporate insurance buying population and related monetary losses. These are generally excluded from standalone cyber insurance policies.

See also: The New Cyber Insurance Paradigm  

Almost every large organization and most middle-size organizations will have some reliance on distributed ledger technology within the next few years – either directly or via one of their third-party suppliers, distributors, vendors, partners or customers. It is important for organizations to educate and prepare themselves:

1. Understand the intended scope of standalone cyber and professional liability insurance policies

Typical standalone cyber insurance policies specifically exclude funds transfers, crypto transfers and other cash and securities monetary losses. Crime policies are intended to address fund losses under specified circumstances. Similarly, payment diversion fraud coverage for “spoofing,” “phishing” and other social engineering incidents is generally excluded under cyber policies but possibly covered under crime policies.

However, two federal appellate courts recently ruled that policyholders are entitled to crime insurance coverage for losses arising from social engineering schemes.

  • July 2018: Facebook investors filed two different securities lawsuits: (1) the first based on the Cambridge Analytica user data incident; and (2) the second following Facebook’s lower-than-expected quarterly earnings release due to lower growth rate caused in part by allegedly unanticipated expenses and difficulties in complying with the European Union General Data Protection Regulation (“GDPR”).
  • Aug. 8, 2018: Securities class action litigation against a publicly reporting media performance ratings company disclosed in its quarterly earnings release that GDPR-related changes affected the company’s growth rate, pressured the company’s partners and clients and disrupted the company’s advertising “ecosystem.”

Typical professional liability and cyber policies also specifically exclude shareholder derivative securities and similar fiduciary liability litigation. A well-crafted directors and officers insurance policy is recommended to provide certain defense and indemnity coverage for such claims.

Absent extensive policy wording customization, the typical cyber insurance policy specifically excludes all bodily injuries and tangible property damage – both first-party tangible property damage (the insured’s own property) and third-party tangible property damage (property owned by someone other than the insured).

2. Silent and affirmative cyber coverage under other lines of insurance

When cyber exposure losses first emerged, insurers had not priced cyber risks into their broadly worded legacy policies, such as property and general liability. However, absent specific cyber exclusions, such as the CL 380 Cyber Exclusion, it is possible that legacy property, general liability, environmental, product recall, marine and aviation could inadvertently cover unintended cyber perils, thus the so-called silent cyber insurance coverage.

After making the first unintended cyber claims payment, some insurers, but not yet all, either exclude or sub-limit cyber risk from new standard policies and renewals. Granting affirmative full cyber limits coverage for an additional premium in such legacy policies is rare and slow to develop. Silent cyber coverage remains. In fact, according to multiple large insurance companies, the 2017 total amount of cyber-related business interruption claims payments were greater under property insurance policies than under standalone cyber policies.

Furthermore, aggregated/correlated/systemic cyber exposures have the potential to cause damages that are multiples of any loss seen to date (i.e. 10,000 customers of a cloud provider or energy/power/utilities). Catastrophe modeling for aggregated/correlated/systemic cyber risk is in its infancy. Innovative approaches for assisting insurers concerned about aggregated, clash incidents – or two different policies covering the same cyber peril – and silent cyber exposures are starting to emerge.

See also: Cyber: Black Hole or Huge Opportunity?  

To achieve cyber resiliency, consider cyber as a peril rather than as a standalone insurance policy. Assess, test, improve, quantify, transfer and respond to the larger cyber risk management issues based on a cost-benefit analysis of resource allocation. Insurance is complementary to a robust cyber resiliency risk management approach. Each organization should identify and protect its critical intangible assets and balance sheet by aligning the cyber enterprise risk management strategy with corporate culture and risk tolerance.

All descriptions, summaries or highlights of coverage are for general informational purposes only and do not amend, alter or modify the actual terms or conditions of any insurance policy. Coverage is governed only by the terms and conditions of the relevant policy. If you have any questions about your specific coverage or are interested in obtaining coverage, please contact your Aon broker. For general questions about cyber insurance, contact: Stephanie Snyder at stephanie.snyder@aon.com.

New Cyber Threat: Cryptojacking

It seems that with every advancement in technology a new threat vector is born. This theory holds true as we begin to embrace the world of cryptocurrency. Cryptocurrencies have emerged as an alternative means for financial transactions, while the value of a single Bitcoin cryptocurrency rose to $20,000 in late 2017. Hackers took notice and succeeded in stealing over $1 billion in cryptocurrency in 2018 alone.

Unfortunately, the cyber threat goes beyond the theft of the currency itself. This new platform has given birth to a cyber crime known as cryptojacking.

Cryptojacking Defined

Cryptocurrency can be earned by a process called cryptomining. Cryptominers must first solve complex mathematical problems to validate transactions. To do this, they use software to create a very complex cryptographic puzzle that requires massive amounts of computing power.

Rather than use their own resources, cyber criminals infiltrate the networks of unsuspecting victims to leverage the victim’s computers for their own mining activities. Hackers then send the results back to servers they control. This often results in slowing or crashing of computer systems, equipment replacement costs, increased energy costs and lost productivity.

See also: Cyber: Black Hole or Huge Opportunity?  

There are several attack methods, including:

  • Phishing emails: The victim clicks on a malicious link or attachment. This runs a code that injects a cryptomining script on the target computer. The script will continuously run, often undetected.
  • Drive-by mining: The hacker injects a cryptojacking script on targeted websites or pop-up ads. When a victim visits that website or receives a pop-up from the infected ad, the script will run and infiltrate the network.
  • Rogue employees: Insiders with access to IT infrastructure can set up cryptojacking systems, including physical servers, within the workplace premises.

Preventing a Cryptojacking Attack

There are several strategies that may help prevent a cryptojacking attack:

  • Web filtering tools should be used to block websites that are known to spread cryptojacking scripts.
  • A cryptojacking ad blocker can be installed to prevent infected ads from popping up.
  • Endpoint detection technology can recognize known crypto miners as soon as they penetrate the network.
  • Mobile device programs can manage vulnerable apps and malicious extensions that may be found on employee-owned devices.
  • Employees must be educated to recognize phishing emails in security awareness training programs.

Transferring Cryptojacking Risk

Many cyber security experts will agree that there is no silver bullet that will prevent all cyberattacks. As a result, the commercial cyber insurance market has evolved along with cyber threats to facilitate options for cyber risk transfer. These insurance policies can provide indemnification for both first-party direct costs and subsequent third-party liability costs in the aftermath of a cyberattack.

See also: The New Cyber Insurance Paradigm  

While policy wording can differ among insurance companies, there are common coverages that are found in many policies. These may be especially helpful in transferring financial losses specific to a cryptojacking attack, including:

  • Business Interruption – The cumulative effect of the slowing of hundreds or thousands of computers in one organization can lead to significant cost over time. Components may fail prematurely due to overuse, and critical controls may be affected. The resulting downtime and restoration process may cause financial loss, which may be recovered under a cyber insurance policy.
  • Network Security Liability – Companies may unknowingly transmit cryptomining code to other organizations, creating legal liability. Litigation costs and settlements may be covered under these policies.
  • Crisis Management – Hackers may change tactics after the initial cryptojacking attack. Once they have access to networks, they may move laterally and access sensitive information that they can monetize, such as Social Security numbers and financial records. Costs to retain external vendors to investigate and respond to the attack, including IT forensics firms, privacy attorneys, credit monitoring fees, notification and call center costs, may be covered.
  • Increased costs due to fraudulent use of a victim’s vendor services, such as a cloud provider or internet-based services, may also be a covered cost.

In light of the emerging threats posed by cryptojacking criminals, it is imperative that steps are taken to prevent, mitigate and transfer the risk. Technology-based controls, employee training and insurance risk transfer mechanisms should all be considered.

What Is and What Isn’t a Blockchain?

I Block, Therefore I Chain?

What is, and what isn’t, a “blockchain”?  The Bitcoin cryptocurrency uses a data structure that I have often termed as part of a class of “mutual distributed ledgers.” Let me set out the terms as I understand them:

  • ledger – a record of transactions;
  • distributed – divided among several or many, in multiple locations;
  • mutual – shared in common, or owned by a community;
  • mutual distributed ledger (MDL) – a  record of transactions shared in common and stored in multiple locations;
  • mutual distributed ledger technology – a technology that provides an immutable record of transactions shared in common and stored in multiple locations.

Interestingly, the 2008 Satoshi Nakamoto paper that preceded the Jan. 1, 2009, launch of the Bitcoin protocol does not use the term “blockchain” or “block chain.” It does refer to “blocks.” It does refer to “chains.” It does refer to “blocks” being “chained” and also a “proof-of-work chain.” The paper’s conclusion echoes a MDL – “we proposed a peer-to-peer network using proof-of-work to record a public history of transactions that quickly becomes computationally impractical for an attacker to change if honest nodes control a majority of CPU power.” [Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, bitcoin.org (2008)]

I have been unable to find the person who coined the term “block chain” or “blockchain.” [Contributions welcome!] The term “blockchain” only makes it into Google Trends in March 2012, more than three years from the launch of the Bitcoin protocol.

Blockchain

And the tide may be turning. In July 2015, the States of Jersey issued a consultation document on regulation of virtual currencies and referred to “distributed ledger technology.” In January 2016, the U.K. Government Office of Science fixed on “distributed ledger technology,” as does the Financial Conduct Authority and the Bank of England. Etymological evolution is not over.

Ledger Challenge

Wuz we first? Back in 1995, our firm, Z/Yen, faced a technical problem. We were building a highly secure case management system that would be used in the field by case officers on personal computers. Case officers would enter confidential details on the development and progress of their work. We needed to run a large concurrent database over numerous machines. We could not count on case officers out on the road dialing in or using Internet connections. Given the highly sensitive nature of the cases, security was paramount, and we couldn’t even trust the case officers overly much, so a full audit trail was required.

We took advantage of our clients’ “four eyes” policy. Case officers worked on all cases together with someone else, and not on all cases with the same person. Case officers had to jointly agree on a final version of a case file. We could count on them (mostly) running into sufficient other case officers over a reasonable period and using their encounters to transmit data on all cases. So we built a decentralized system where every computer had a copy of everything, but encrypted so case officers could only view their own work, oblivious to the many other records on their machines. When case officers met each other, their machines would “openly” swap their joint files over a cable or floppy disk but “confidentially” swap everyone else’s encrypted files behind the scenes, too. Even back at headquarters, four servers treated each other as peers rather than having a master central database. If a case officer failed to “bump into” enough people, then he or she would be called and asked to dial in or meet someone or drop by headquarters to synchronize.  This was, in practice, rarely required.

We called these decentralized chains “data stacks.” We encrypted all of the files on the machines, permitting case officers to share keys only for their shared cases. We encrypted a hash of every record within each subsequent record, a process we called “sleeving.” We wound up with a highly successful system that had a continuous chain of sequentially encrypted records across multiple machines treating each other as peers. We had some problems with synchronizing a concurrent database, but they were surmounted.

Around the time of our work, there were other attempts to do similar highly secure distributed transaction databases, e.g. Ian Griggs and Ricardo on payments, Stanford University and LOCKSS and CLOCKSS for academic archiving. Some people might point out that we weren’t probably truly peer-to-peer, reserving that accolade for Gnutella in 2000. Whatever. We may have been bright, perhaps even first, but were not alone.

Good or Bad Databases?

In a strict sense, MDLs are bad databases. They wastefully store information about every single alteration or addition and never delete.

In another sense, MDLs are great databases. In a world of connectivity and cheap storage, it can be a good engineering choice to record everything “forever.” MDLs make great central databases, logically central but physically distributed. This means that they eliminate a lot of messaging. Rather than sending you a file to edit, which you edit, sending back a copy to me, then sending a further copy on to someone else for more processing, all of us can access a central copy with a full audit trail of all changes. The more people involved in the messaging, the more mutual the participation, the more efficient this approach becomes.

Trillions of Choices

Perhaps the most significant announcement of 2015 was in January from IBM and Samsung. They announced their intention to work together on mutual distributed ledgers (aka blockchain technology) for the Internet-of Things. ADEPT (Autonomous Decentralized Peer-to-Peer Telemetry) is a jointly developed system for distributed networks of devices.

In summer 2015, a North American energy insurer raised an interesting problem with us. It was looking at insuring U.S. energy companies about to offer reduced electricity rates to clients that allowed them to turn appliances on and off — for example, a freezer. Now, freezers in America can hold substantial and valuable quantities of foodstuffs, often several thousand dollars. Obviously, the insurer was worried about correctly pricing a policy for the electricity firm in case there was some enormous cyber-attack or network disturbance.

Imagine coming home to find your freezer off and several thousands of dollars of thawed mush inside. You ring your home and contents insurer, which notes that you have one of those new-fangled electricity contracts: The fault probably lies with the electricity company; go claim from them. You ring the electricity company. In a fit of customer service, the company denies having anything to do with turning off your freezer; if anything, it was probably the freezer manufacturer that is at fault. The freezer manufacturer knows for a fact that there is nothing wrong except that you and the electricity company must have installed things improperly. Of course, the other parties think, you may not be all you seem to be. Perhaps you unplugged the freezer to vacuum your house and forgot to reconnect things. Perhaps you were a bit tight on funds and thought you could turn your frozen food into “liquid assets.”

I believe IBM and Samsung foresee, correctly, 10 billion people with hundreds of ledgers each, a trillion distributed ledgers. My freezer-electricity-control-ledger, my entertainment system, home security system, heating-and-cooling systems, telephone, autonomous automobile, local area network, etc. In the future, machines will make decisions and send buy-and-sell signals to each other that have large financial consequences. Somewhat coyly, we pointed out to our North American insurer that it should perhaps be telling the electricity company which freezers to shut off first, starting with the ones with low-value contents.

A trillion or so ledgers will not run through a single one. The idea behind cryptocurrencies is “permissionless” participation — any of the billions of people on the planet can participate. Another way of looking at this is that all of the billions of people on the planet are “permissioned” to participate in the Bitcoin protocol for payments. The problem is that they will not be continuous participants. They will dip in and out.

Some obvious implementation choices are: public vs. private? Is reading the ledger open to all or just to defined members of a limited community? Permissioned vs. permissionless? Are only people with permission allowed to add transactions, or can anyone attempt to add a transaction? True peer-to-peer or merely decentralized? Are all nodes equal and performing the same tasks, or do some nodes have more power and additional tasks?

People also need to decide if they want to use an existing ledger service (e.g. Bitcoin, Ethereum, Ripple), copy a ledger off-the-shelf, or build their own. Building your own is not easy, but it’s not impossible. People have enough trouble implementing a single database, so a welter of distributed databases is more complex, sure. However, if my firm can implement a couple of hundred with numerous variations, then it is not impossible for others.

The Coin Is Not the Chain

Another sticking point of terminology is adding transactions. There are numerous validation mechanisms for authorizing new transactions, e.g. proof-of-work, proof-of-stake, consensus or identity mechanisms. I divide these into “proof-of-work,”  i.e. “mining,” and consider all others various forms of “voting” to agree. Sometimes, one person has all the votes. Sometimes, a group does. Sometimes, more complicated voting structures are built to reflect the power and economic environment in which the MDL operates. As Stalin said, “I consider it completely unimportant who in the party will vote, or how; but what is extraordinarily important is this — who will count the votes, and how.”

As the various definitions above show, the blockchain is the data structure, the mechanism for recording transactions, not the mechanism for authorizing new transactions. So the taxonomy starts with an MDL or shared ledger; one kind of MDL is a permissionless shared ledger, and one form of permissionless shared ledger is a blockchain.

Last year, Z/Yen created a timestamping service, MetroGnomo, with the States of Alderney. We used a mutual distributed ledger technology, i.e. a technology that provides an immutable record of transactions shared in common and stored in multiple locations. However, we did not use “mining” to authorize new transactions. Because the incentive to cheat appears irrelevant here, we used an approach called “agnostic woven” broadcasting from “transmitters” to “receivers” — to paraphrase Douglas Hofstadter, we created an Eternal Golden Braid.

So is MetroGnomo based on a blockchain? I say that MetroGnomo uses a MDL, part of a wider family that includes the Bitcoin blockchain along with others that claim use technologies similar to the Bitcoin blockchain. I believe that the mechanism for adding new transactions is novel (probably). For me, it is a moot point if we “block” a group of transactions or write them out singly (blocksize = 1).

Yes, I struggle with “blockchain.” When people talk to me about blockchain, it’s as if they’re trying to talk about databases yet keep referring to “The Ingres” or “The Oracle.” They presume the technological solution, “I think I need an Oracle” (sic), before specifying the generic technology, “I think I need a database.” Yet I also struggle with MDL. It may be strictly correct, but it is long and boring. Blockchain, or even “chains” or “ChainZ” is cuter.

We have tested alternative terms such as “replicated authoritative immutable ledger,” “persistent, pervasive,and permanent ledger” and even the louche “consensual ledger.” My favorite might be ChainLedgers. Or Distributed ChainLedgers. Or LedgerChains. Who cares about strict correctness? Let’s try to work harder on a common term. All suggestions welcome!