… and five minutes to ruin it. - Warren Buffett, Chairman and CEO, Berkshire Hathaway
Is it just me, or are corporate scandals—really big ones—becoming more frequent? It seems that I read every week about companies for whom millions of dollars in shareholder value and years of good will were erased in days—not just in legal fees, recalls or liability payouts, but in brand value: that conceptual, priceless entity that helps make the best companies into household names. The situation seems to be particularly perilous for custodians of customer data, and those whose value is highly invested in their brand. Here are some reasons why this may be so:
Perhaps most clearly, the advent of social media and the 24/7 news cycle has compressed time frames and given individuals or small groups disproportionate voice, regardless of their accuracy or agenda.
Consumers trust corporations less than ever, according to the Edelman 2011 Barometer of Trust. (There is a silver lining to Edelman’s research, as the tech sector enjoys greater trust than any other.)
Last year, on this same blog, we published a post whose title was “The True Story Behind the Cisco Identification Port” -- which you’re invited to read now if you haven’t done so already. In short, back in the days of IOS 11.0, a “feature” was implemented on the Cisco IOS code handling the TCP protocol: if a TCP SYN packet destined to the router was received on port 1999/tcp, a RST would be sent back, but within the payload of the TCP datagram, Cisco IOS would insert the string cisco. This “feature” was put in place on purpose -- its goal was to be able to quickly determine over the network if a given IPv4 host was running Cisco IOS. Cisco removed this “feature” starting with Cisco IOS release 12.0 mainline through CSCdk85821.
Now let me tell you a similar story -- but with more twists and suspense
Back in 2003, a Cisco Technical Assistance Center (TAC) engineer made a very simple request: in order to troubleshoot IPv6 issues which could be related to the Cisco IOS switching path, it would be nice to have a way to generate (within Cisco IOS itself) an IPv6 packet that, when received by a Cisco IOS device, would be punted to the CPU and out of the CEF path. This was indeed considered useful, and was hence implemented as an option to the “IPv6 extended ping” functionality within Cisco IOS. The original implementation was as follows:
On the sending side: When performing an “IPv6 extended ping”, the user would be asked if a Hop-by-Hop (HBH) extension header (EH), a Destination Options EH, or both EHs should be inserted between the IPv6 header and the ICMPv6 header of an outgoing ICMPv6 Echo Request. Either EH would carry a single PadN option of size 4, with the PadN data being 0x00 bytes.
On the receiving side: The Cisco IOS code handling ICMPv6 was modified to check for the presence of an HBH EH on any IPv6 packet carrying an ICMPv6 Echo Request received by the device and whose destination IPv6 address was any IPv6 address assigned to any of the device interfaces. When replying to the Echo Request with an Echo Reply, if such an HBH EH was present, Cisco IOS would also insert an HBH EH on the outgoing IPv6 packet -- payload of the HBH EH again being a single PadN option of size 4, with the PadN data being 0x00 bytes.
A Cisco IOS device, on reception of the ICMPv6 Echo Request packet with the HBH EH (if the device was located in the path between the source and destination), or with the Destination Options EH (if the device was the final destination) would then punt the packet to the CPU to process the EH. And because the ICMPv6 Echo Reply sent back to the source (if the device was the packet’s final destination) also included the HBH EH, you would be able to troubleshoot the switching path on both ends from one end. The TAC hence got another tool to troubleshoot customer issues and everyone moved on to other things.
Today, there are many strong cryptographic algorithms and protocols, standards for their use at every layer of the network, and interoperable implementations in many products and in open source. When used appropriately, they provide strong safeguards against attacks that target our networks. Unfortunately, none of this good cryptography will protect anybody if it is used with secrets that are guessable.
Humorist Gene Weingarten claims he knows the secrets that protect the U.S. nuclear launch codes: 070494, which happens to be the date of Obama’s daughter’s birthday. No doubt the secrets are actually better chosen than that, but the joke conveys an important truth: you can’t expect everyone to choose passwords well. You should regard passwords that are human-generated or human-memorable as being guessable. A cryptographic system is only as strong as its weakest element. When human-generated keys are used in cryptography, the system should not be expected to resist a knowledgeable attacker.
The most secure key management technology is digital certificates; you should use them when you can. If for some reason you can’t, and you need to use shared secret keys, then you should make sure that those keys are generated by a uniform random process, and not by an administrator in a hurry. I will get to advice on certificates and key generation later, but first, I would like to explain why passwords and cryptography don’t mix well.
One of the key tools in the cybercrime toolbox is the drive by web exploit. Simply put, a drive by exploit is when a website is somehow violated such that it later causes the download of software, often from a different server and typically malicious in nature, without the knowledge of the end user. This software may be later used for a variety of things. It may be a key logger, recording keystrokes to capture things like passwords and credit card data, it could be a botnet client, turning the victim PC into a zombie used for spam, DDoS or even Bitcoin Mining. Regardless, the fundamentals remain the same. Do something bad to a website and then that website causes a silent install of malware on visitor machines.
OK, so we all know that mobility has become an absolute necessity in business. How many of us can honestly say that we could last even a day without our smart phone or tablet? We check our email, run enterprise apps, access the ERP, and conduct a host of other activities that require secure VPN access. But just like anything else, there’s a big difference between what we want and what we can (or should) have! After all, enterprise strength mobility requires enterprise strength security – something that’s been sorely lacking in all but a few mobile devices.