Hurricane Ivan illustrated a need for new forms of Internet business risk management when it damaged an undersea cable and disconnected the Cayman Islands. The disconnection lasted more than two days and is an example of a risk beyond the control of the enterprise or the telecommunications carrier: a force majeure risk, or act of God. No amount of firewalls, intrusion detection or patches would have prevented it. Another undersea cable running to the Cayman Islands might have minimized the downtime, but at some point, the expense becomes greater than the risk, or at least greater than the cost of insurance for the risk.
On the Internet, physical risks such as hurricanes, floods and earthquakes are not the only force majeure risks, and not the most economically significant ones. Hurricanes are constrained in geographical scope. Worms, denial-of-service attacks and terrorism are not so constrained, and could cause even more aggregate damage than a hurricane. Put another way, offshore content caching may help prevent an outrage due to a hurricane, but wont necessarily avoid a worm.
Researchers at a May 2004 workshop in economics and information security speculated that “a plausible worst-case worm could cause $50 billion or more in direct economic damage.” That’s more than Hurricanes Andrew, Charley, Frances and Ivan combined. And that estimate is just for the United States.
Meanwhile, CEOs, who a year ago were saying “the Internet just works,” now are evaluating the possibility of taking out insurance against a global cyber catastrophic event that could interrupt their worldwide operations for days.
According to some estimates, the SoBig worm caused $30 billion in damages. Those numbers give some idea of the high end of the long-tailed distribution of Internet risks. Trailing down from there the risks become smaller but more frequent, including end-user software exploits such as the Internet Explorer scob worm, content caching attacks such as the Akamai DNS outage, and carrier problems such as cable cuts, routing flaps, congestion or denialof- service attacks.
These risks need management that goes beyond traditional risk management, such as deploying firewalls or hedging price futures. Fortunately, there is a range of financial risk transfer instruments that have already been tried and tested in other industries: insurance policies (as for fire and theft), catastrophe bonds (as for earthquakes and floods), performance bonds (as for electrical brownouts) and capital withholding (as in international banking). Now is the time to apply these financial risk transfer strategies to the Internet.
The most obvious strategy is insurance. AIG and InsureTrust already sell Internet business continuity policies, although there tend to be many exceptions in these policies, and they can be expensive. Better assessment of risks and better quantification of actual anomalies over time can help tune such policies to be more useful and cost-effective.
As more companies buy Internet business continuity insurance, they will also apply traditional Internet technical security measures more consistently because insurers will require it, just as they require sprinkler systems for fire insurance.
Yet no single insurer is likely to want to handle a $50 billion risk. Re-insurers have the same concerns. There’s a solution for this, too: catastrophe bonds.
Catastrophe bonds became popular after the Northridge earthquake made it difficult for many homeowners and businesses to get earthquake insurance.
The government of California, not wanting to have to act as guarantor of last resort, promoted the idea of a bond whose principal would go to cover an earthquake if it happened, but meanwhile would pay higher interest than most other bonds, with risk of loss of principal that would not be highly correlated with similar risks, such as a stock market crash or municipal bonds being downgraded. Those particular earthquake catastrophe bonds were never issued, but catastrophe bonds have become quite popular since then to cover not only earthquakes, but also hurricanes, floods and wildfires. “Cat bonds,” as they are called, expand the pool of capital available to cover large risks.
Not all risks that affect businesses are outages. The average Web user gives up on a transaction after eight seconds, and packet loss or latency can cause that much delay. ISPs often provide service-level agreements (SLAs) that cover not only outages but also milliseconds of latency. Yet ISP customers are often unhappy with SLAs and suspicious of ISP claims to have met them because ISPs validate their own performance. ISPs often pay goodwill SLA payouts to keep such customers happy, even when the ISP knows there was no SLA violation.
There is a better solution. Electric utilities use a form of catastrophe bond called a performance bond to cover brownouts. If an ISP could buy a performance bond that came with third-party claims adjustment and would pay validated claims, the customers would be happier even if there was no payout. The ISP would be happier because the bond would cost less than the former payouts. And the bond issuer would be happy with a new line of business.
Self-insurance is another possible financial risk-management strategy. Large international banks have agreed among themselves to extend their capital withholding formulas, formerly based on credit risk, to include operational risk. Since banks use the Internet extensively, this means they have to quantify Internet operational risk. Such banks will be self-insuring themselves for Internet business continuity risk, when they have fully implemented their Basel II New Capital Accord. As the size of Internet risk continues to increase, I wonder if banks’ quantifications will lead them to add buying insurance policies or performance bonds to their risk-management mix.
There is also risk management beyond financial risk-transfer instruments. ISP customers may want to know which ISPs have nonredundant paths to their customers, or which ISPs have histories of routing flaps. Such third-party reputation systems could be useful extensions to the rudimentary reputation systems already provided by CERT, USCERT, ISS’s X-Force and others. Systems for finding, tracking and recording physical hurricanes have developed past landline telegraph and ship-to-shore wireless. We have weather balloons, hurricane-chasing airplanes and ocean buoys plus ground-, air- and satellitebased radar using visible and infrared. We need the equivalents of all of these watching the Internet all the time.
ISPs may resist such visibility, but they may also realize that it could give them a competitive advantage - something customers can use to choose beyond price, speed and geography. And visualizations of such advantages could be quite useful in marketing.
So we have a range of financial risk-transfer instruments: insurance policies, catastrophe bonds, performance bonds and capital withholding, plus reputation systems - all of which can be applied to the Internet.
Whats the common thread in all these new-to-the-Internet risk-management strategies? They all deal with aggregated force majeure risk. Given problems that affect many users and enterprises at once, building local forts at each affected place is not a winning long-term strategy. A lock on the door is good, but an alarm system connected to a network of responders is better. Add to those insurance for when all technical means fail, and reputation systems for what’s going on where, when and why, and the combination is risk management that works.
John S. Quarterman is CEO of InternetPerils Inc., an Internet business risk-management intelligence agency that provides automated quantification and visualization products for risk managers and underwriters, so they can identify, track, analyze and forecast adverse Internet performance episodes and interruptions that comprise the Internet risks that harm their enterprises.
InternetPerils Inc. www.internetperils.com
For the second year, we've identified the people, organizations, techs and trends expected to have a major impact o… twitter.com/i/web/status/1…
October 16 2019 @ 18:12:06 UTC