June 2, 2010 will be a day that Armando Galaragga and the fans of Detroit Tigers baseball will not soon forget. That night, Galaragga came one play short of being awarded a perfect game, a Herculean feat that has been accomplished only 20 times in the more than 100-year history of major league baseball. On what would have been the final play of that game, Galaragga’s attempt to keep the final batter from reaching base was ruled unsuccessful, and his perfect game was instead given a less-spectacular distinction of being only one of ten nearly-perfect games to be spoiled by the final batter.
Worse still for Tigers fans, the umpire who called the runner safe admitted upon review of footage after the game that the runner should have been ruled “out,” and Galaragga should have had his perfect game. But in a case that is eerily similar to the one we reported on in this week’s Cyber Risk Report (CRR) about a pedestrian who sued Google, it would be the disgruntled fans eager to seek revenge on the mistaken umpire who would craft the nightmare from which a Toledo man would hope to soon awake.
Read More »
There isn’t much new or exciting about tabbed web browsing, which has been more or less mainstream for the last 5 years. Likewise, the HTML standard has had the ability to refresh a page to a different URL via meta tags for much longer than that. So what do we make of Aza Raskin’s recent announcement of “tabnabbing” as a new and dangerous in-browser phishing attack? We covered the basic aspects of this threat vector in this week’s Cyber Risk Report, but let’s dive a little deeper here.
Read More »
As the environmental disaster resulting from the British Petroleum (BP) oil spill unfolds in the Gulf of Mexico, I am reminded of common problems in the information security industry. Granted, the scale and potential impact of the oil accident—with thousands of barrels of crude spewing out of a hole on the ocean floor a mile deep each day, endangering sensitive coastline ecosystems from Texas to the Florida panhandle—are thankfully hard to duplicate in the world of technology. A bad patch release or a data breach can cost a company millions of dollars and engineers their jobs, but in most cases, lives are not at risk. Lack of “circuit breakers” regulating stock exchange trading may lead to the evaporation of close to a trillion dollars in minutes, but trading can be halted, plugs can be pulled. Not so with this oil spill, where despite BP’s best efforts to contain the disaster, extensive and probably long-lasting damage to the Gulf Coast and losses to the fishing and tourism industries appear unavoidable.
Reading over Congressional testimony and media analysis of the spill, it appears that several mistakes were made that have analogues in the world of technology. They were mistakes that highly-trained, intelligent people who should know better, make. They should look familiar to us in the high-tech world. Here are five:
Read More »
Who is performing computer incident coordination? Ask someone from the computer security world and the answer will probably be CERT/CC. If you are not from North America but instead from the Asia Pacific region, then you might hear JPCERT/CC or AusCERT, while Europeans may add CERT-FI or CPNI. All of these teams, together with your respective national CERT, are the “usual suspects” when computer incident coordination is concerned because they have done such tasks in the past and are still doing them today. Each of these teams has handled the coordination of large incidents where multiple sites were involved. If your site is involved in a large-scale incident, and if your policies allow it, you may consider asking some of these organizations to help you handle the incident.
But each of these teams is also finite in size and their main mandate is not to investigate and coordinate each and every computer incident that is reported to them. These teams will look into all reports sent to them, but they won’t necessarily get directly involved in every incident because they simply cannot scale to coordinate each and every one.
Read More »
The deployment of Internationalized Domain Names (IDNs) reached the root of the DNS infrastructure in recent weeks with the creation of four internationalized Country Code Top Level Domains (ccTLDs). Mentioned in our Cyber Risk Report, these newly deployed IDNs represent Egypt, Saudi Arabia, the United Arab Emirates, and the Russian Federation.
IDNs leverage Unicode to display various non-Latin scripts, such as Arabic or Chinese, within computer applications. An encoding syntax called Punycode bidirectionally transforms the Unicode that is needed to represent these scripts into the subset of the Latin script that is used for domain names. This essentially reduces the scripts of the world into a form suitable for processing by applications that have no understanding of Unicode. This, for example, transforms the newly minted TLD for Saudi Arabia, السعودية, into xn--mgberp4a5d4ar so that it can be processed similarly to any ASCII-based domain name.
Punycode has several advantageous characteristics. For example, it encodes the discrete components of a DNS name individually making it possible to encode only part of a DNS name. Encoded name components are prefixed with xn--. One such partially-encoded DNS name is xn--vckfdb7e3c7hma3m9657c16c.jp which, with one encoded and one unencoded label, represents the Japan Registry Services. This partial encoding has allowed the use of local languages in parts of the world for several years without support for IDNs at the DNS root.
Allowing users to connect with one another or online resources without the constraint or burden of Latin characters is certainly a good thing. However, there are security risks to be understood.
Read More »