What is CVSS – (the Common Vulnerability Scoring System)? How can it help me manage risk – and why is it an important step forward in security research? In this short video Gavin Reid CVSS Program Chair share’s his perspective on the vulnerability scoring standard
Sometimes it is interesting to take a look at darknet data and see what you come across. If you are not familiar with the term “darknet,” I am using the definition used by some in the service provider community where a darknet is a set of address space which contains no real hosts. That means no client workstations to initiate conversations with servers on the Internet. It also means no advertised services from those ranges, such as a webserver, a DNS server, or a database server. There is really no reason to see any traffic destined for addresses within those ranges. From a network point of view, it should be as desolate and deserted as the town of Pripyat in the Ukraine, within the evacuation zone due to the Chernobyl disaster back in the 1980s. However, in practice, you do see traffic to those address ranges, which is what makes that traffic somewhat interesting. Traffic destined to those ranges could be the result of malware attempting to locate machines to infect, part of a research project or it could be as simple as a misconfiguration or a typographical error. One example of traffic resulting from a typo would come from attempting to ping a host and typing the wrong address in. However, it would be hard to believe that all of the traffic seen in a darknet is the result of a mistake.
Setting up a darknet does not have to be hard to do. If your organization has address space that is not being used, then all that you need to do is advertise a route for those addresses and leave them unused. In our case, we have advertised several ranges and we collect Netflow data for the traffic destined to them from a nearby Cisco router. That Netflow data is exported to a collector, such as nfcapd, where it is aggregated for further analysis.
As I travel the world, I ask my customers two simple questions:
First, are you virtualizing your data center? (Universally the answer is yes.)
Second, have you deployed any virtual security solution? (Universally the answer is no.)
Wow. How can this be? Does a virtual data center not need security? Not a chance. It needs security more than ever. Most customers are confining their virtualized infrastructure into secure zones, or virtual local area networks (VLANs). That’s useful for a first phase, but excessive VLAN segmentation holds us back from achieving the efficiencies of the utility computing model—and it also gets really complicated really quickly.
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.
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.