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:
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.
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.
Spring is finally here, and besides being a good time to clean the attic, garage or basement, it is also a good time to clean the configuration on your Cisco IOS devices — removing unneeded ACEs from ACLs, maybe setting some interfaces as passive, removing VLANs from trunks, etc.
And while doing said cleaning, hey, why not also check the device configuration against the Cisco Guide to Harden Cisco IOS Devices, to make sure we’re doing our best to keep those Cisco IOS devices as secure as possible?
When looking over the recommendations on the hardening guide, time and again people are puzzled by this line:
“Issue the no mop enabled command in interface configuration mode in order to disable the Maintenance Operation Protocol (MOP) service.”
And they come back to us with questions like, “what is MOP, why do I have to disable it, and is it even relevant if I’m not running DECnet?” Well, today we hope to clear up some of the confusion that might surround the unMOPping of a Cisco IOS device, so gather round for a story. Sorry, no marshmallows, but I think it will be interesting nonetheless.
This week we’re trying something new and a little different (at least for us). We’ve created a poll that we hope will be a fun addition to the Cisco Security blog.
Background On This Week’s Poll: You may have heard of this social network called Facebook. It used to be that people joined Facebook as part of a University affiliation and it was mostly used to keep track of school friends. Users let others know about their interests, hobbies, and favorite bands. As Facebook has grown it has morphed from a way to connect with friends into one of the de-facto ways people communicate with many in their personal life and, increasingly, in the business realm. This extends to bosses, high school friends and frienemies, and that second cousin twice removed.
When security professionals are left scratching their heads trying to twiddle the nerd knobs or decipher the market-speak of Facebook’s opt-out dialogs, how does this bode for an ordinary user?
Last weekend I had a friend quit Facebook while we were IM’ing on Gmail. I was surprised how easily he made this decision, as it seemed to be rather drastic. I asked him if it was because of the recent privacy trends and he said, “no, I’m just getting tired of not knowing what I’m sharing.” While an anecdote isn’t the singular of data, quitting Facebook has apparently been a growingtrend. Read Write Web noted that leaving isn’t so easy (emotionally?), and Facebook has been working to quell some people’s fears. All this has left me wondering: