I’ve covered the proliferation of digital traces, as well as how those footprints can be combined to de-anonymize data, eroding the privacy of users. This week, we see another chapter emerge in this storyline, with a report from Computerworld about tools for mining social networks and other open sources. In this week’s Cyber Risk Report, we talked about the risks posed by these tools to organizations, and I’d like to expand on that, as well as some benefits, here in this post.
Today we are releasing the 2009 Cisco Annual Security Report, which pulls together a full year’s worth of cyber security-focused collaboration from across the entire Cisco Security Intelligence Operations team. The 2009 Cisco Annual Security Report is a comprehensive look back at the year’s highlights with an eye towards what we can expect to see going forward.
Throughout 2009 we saw a host of new threat developments, gripping front line skirmishes, inspirational cases of the White Hats locking arms to combat evil, and alarming new levels of cybercrime audacity and sophistication.
With this report the Cisco Security team is introducing new tools to help customers better assess the evolving threat landscape. To address IT security professionals’ demands for better insights on the threat pipeline, we are introducing The Cisco Cybercrime Return on Investment Matrix (CROI), which is a framework for quickly assessing techniques and business models criminals will be investing and divesting from. Uniquely, the CROI Matrix is built from the perspective of the cybercriminal and how they rate their portfolio of scams and techniques from an investment perspective. We believe this approach is fundamental to understanding how the threat landscape will look in the coming year.
To date, a major gap exists in vulnerability standardization: there is no standard framework for the creation of vulnerability report documentation. While the computer security collective has done a bang-up job in several other areas, including categorizing and ranking the severity of vulnerabilities in information systems with the widespread adoption of the Common Vulnerabilities and Exposure (CVE) dictionary and the Common Vulnerability Scoring System (CVSS), this lack of standardization is evident in every vulnerability report, best practice document, or security bulletin released by any vendor or coordinator. This blog post explores a nascent standard to close this gap.
Lack of Standard Promotes Chaos
Conventionally, the documentation of vulnerabilities is an ad hoc, producer-specific, and overtly non-standard process. Each vendor compiles, collates, and produces their own version of a vulnerability document that may or may not be similar to comparable reports by other vendors. To see examples of this, consider the 2008 multi-vendor “outpost24 TCP” vulnerability report from major producers such as Cisco, Microsoft, or CERT. Because each producer employs a unique and non-cooperative document structure, users must manually parse individual reports to find information that is germane to their environments. Additionally, the documents are typically flat and do not facilitate nor support any sort of automated processing.
In this week’s CRR, we continued to follow an interesting roller coaster of events that has overshadowed electrical companies in Brazil over the past few weeks. There have been reports that recent power failures were a result of computer hacking, a rebuttal that the failures were not caused by hacking, and finally reports that power company websites were hacked into (though without any power failures). This has resulted in a flurry of media reports, fear mongering about “cyber attacks,” and general uncertainty about what is and is not possible.
The Bay Bridge, connecting San Francisco to Oakland, California, carries approximately 280,000 vehicles per day. Many of those vehicles are transporting employees to their workplaces in the greater San Francisco-San Jose-Oakland area, which is why those of us who work at Cisco headquarters in San Jose were directly affected or know someone who was by the bridge’s recent and unexpected shutdown. This debacle, caused by failing and falling bridge beams, left thousands of workers stranded, backed up in traffic, or forced to find alternate means of getting to work, such as circuitous commutes, ferries, or public transit. Others found alternate means of working.
Employees with remote access capabilities and those whose jobs do not require full-time, in-person presences could telecommute during the bridge closing. Although this does not seem like a revolutionary notion in our day and age of anywhere, anytime work and with wireless access in every airport, hotel, and coffee shop, are most organizations gearing up all of their essential employees with the capabilities to work remotely? Can businesses ensure business-as-usual during major interruptions, such as severe weather, widespread employee illness, or bridge closings? New data suggests they can not.