Bitcoin is an emerging technical and economic phenomenon, based upon a self-published paper by Satoshi Nakamoto. Many sites have taken notice of Bitcoin and have published some very thoughtful “what is Bitcoin,” “How-to get started” documentation. But the resources available to address Bitcoin are few, and primarily oriented toward enthusiasts, casual hobbyists, or those interested in making and securing a profit off of Bitcoin generation (“mining”). In this post, we make an effort to extend the Bitcoin security body of knowledge, but from an organizational perspective: what are the risks associated with adopting Bitcoin, intentionally or unintentionally.
Read More »
I started my professional life using a mainframe. Back then the people running the mainframe world were known as the “data center guys.” These guys had a certain DNA combination that created an expanding waistline, a retreating hairline, a belt buckle the size (and shape) of Texas, and a penchant for big iron. This crowd ruled the data center for a long time, but virtualization in the data center is now driving a radical shift that seems to be changing everything.
Instead of having an application running on a dedicated tower of hardware power, apps are now free from the limitations of the infrastructure underneath. Hardware is evolving rapidly into dynamic blocks of utility computing (and storage and networking) that can be standardized, widely deployed, and efficiently utilized. This change is good news, as it can cut data center costs by 50 percent or more. If the big iron crowd from the mainframe days doesn’t adopt this fundamental shift, they’ll be hanging up their Texas belt buckles in the computer museum next to the punch card, the VAX, and a replica of the ILLIAC.
The same shift is also happening with security. Since most security products are primarily software based, it is not much of an effort to repackage these products as “virtual security.” But merely repackaging security products misses the point. Today’s security architecture was built at a time when the workplace was very different than it is today. End users would come into the office and work on a PC, which sat on a desk and was connected by a wire to a port on the wall. At this time, the IP address was a pretty good proxy for the user’s identity. And applications would each run on their own tower of power—hardware that was often running in a unique data center rack or racks. Therefore segmenting the data center in this era was relatively easy; it was based on IP address ranges and, later, on virtual LANs (or VLANs).
But the workplace of today (and tomorrow) looks very different. We’re no longer tied to a specific lump of hardware. We expect to access our apps in the cloud from any device, at any time, from anywhere. Therefore the IP address is a less useful means of defining data center boundaries.
We need a new capability that allows the security team to maintain its meaningful policy enforcement capability, while enabling that policy to be relevant across all infrastructure—physical and virtual. An important nuance here is that the policy should be consistently enforced across physical infrastructure as well as across virtual infrastructure from any virtualization vendor. This level of enforcement requires special access to the hypervisor. Without this access, a virtual security solution can’t see traffic between two virtual machines (VMs).
How the various security vendors plan to address hypervisor access is still an open question. And how that question gets answered is significant—and is likely to reshape the security vendor landscape.
So as we consider various virtual security solutions, simply repackaging today’s security software as a VM running in a cluster of other VMs is extremely uninteresting. Instead we must reimagine the way that we build and deploy security solutions. How do we bridge the policy model from today’s hardware-based firewalls to the virtual firewalls of tomorrow? How can we maintain a separation of duties, so that security policy definition is separate from traditional network operations? And how will we orchestrate all of these components in the dynamic, nimble data center of tomorrow? These are not small issues. But of course, that’s what makes my job fun.
Tags: data center, security, virtualization
This year, Cisco Live! comes to Las Vegas where a record breaking 14,000 customers, partners and technical experts will converge on the Mandalay Bay Convention Center for five days of rich, deep interaction and discussion around all aspects of networking, including security.
Come see TrustSec, ISE and other Security Demos at the Main Cisco Booth at Cisco Live!
At the Cisco main booth (Booth 1349) we are going to have a number of security demos, including:
The Cisco SecureX Architecture – two-part demo of how a holistic approach can deliver better security.
- Part 1: Cisco Cius and Apple iPad in a HIPAA/medical situation where MACSec, AnyConnect and other technologies are shown enabling secure data exchange with better security, compliance and confidentiality.
- Part 2: With access control enabled with TrustSec and ISE, we illustrate virtualized desktop capabilities on Cius and other endpoints, as well as content security with Cisco IronPort and ScanSafe.
Read More »
… 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:
Some recent challenges faced by multinationals have included:
- Environmental damage
- Product safety
- Data loss
- Supply chain/partner practices
- Corruption and ethics
- Regulatory and accounting violations
Read More »
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.
Read More »