Cisco Blog > Security
No doubt the eruption of social media applications, networks and tools has caused a significant ground disturbance; some would say it’s been a series of category nine earthquakes. I recently had the pleasure of reviewing the results of a Cisco commissioned survey provided to 500 information technology security professionals in the US, Germany, Japan, China, and India concerning social media and personal devices conducted by InsightExpress.
Do take the time to review these results, and in doing so I think you will share my realization, that with everything new there are unintended and unforeseen security issues, both real and perceived. These issues appear to be at the root of the substantial consternation amongst the participating information technology security professionals. Indeed, this multidimensional capability called social media is in fact permeating the hermetically sealed secure environments of our businesses, or so it would seem. It is time to get out the plow, hitch up the horses and hoe a few rows in order to plant the seeds to grow healthy and sustainable security practices and capabilities surrounding these concerns.
So let’s dig into the issues that are making the respondents twitch. “Our employees are using unsupported applications on their laptops.” Is that you making the comment? Or are they thinking of you when they responded? Are “unsupported” social media applications used at the office? Is it you? How about peer-to-peer (P2P) software and networks, is it a necessity of your business for you to be connected and sharing work content? Or perhaps you are using an externally hosted and maintained service (aka cloud); especially given the large number of respondents who indicated they had employee clientele doing just this. But I believe a bit more context needs to be evolved to fully understand the issue(s) or we may find ourselves making “much ado about nothing” (with a tip of the hat to The Bard).
Read More »
A blog post that appeared last Friday, observed that Facebook is signing their mail with DomainKeys Identified Mail (DKIM) using a 512-bit RSA key. The author went on to analyze the security of doing so as compared with a longer key, and concluded that a determined attacker could probably factor the public key quickly enough to be useful in sending falsified messages purporting to be from Facebook. The blogger, John Graham-Cumming, said:
Some months ago I started an 8 core Mac Pro machine at work on breaking this key. It ran for 70 days non-stop and was close to a break when I had to use the machine for something else.
If I can do that, pretty much anyone can. And those people will be able to forge mail from Facebook. Facebook has a simple solution, of course, just change the key length. And if you are using 512-bit RSA keys in your DKIM implementation, please stop.
PS The owner of a spam botnet could factor keys like that very quickly. Imagine having a few thousand machines that can be used for key factoring.
One question that comes to mind is how many other domains are using 512-bit keys? It’s hard to answer this question directly because one needs to know the “selector” (key name which is included in the signature) to look up the key, but some of the data Cisco has collected on DKIM metrics gives an approximation. The methodology is a bit indirect because we don’t collect the selector name for successful verifications (only for failures), but since we usually get a smattering of verification failures for domains sending us messages, we can use that data to infer the selector names they use.
Read More »
If you’ve ever taken a look at the (now deprecated) RFC-1700 (a.k.a. “Assigned Numbers”), or at its replacement, IANA’s maintained PORT NUMBERS database, you may have been as puzzled as I was about these two lines:
tcp-id-port 1999/tcp cisco identification port
tcp-id-port 1999/udp cisco identification port
What is that supposed to mean? Does Cisco IOS devices have some kind of custom IDENT server running on ports 1999/tcp and 1999/udp? Well… no. This is yet another instance of “gather around the campfire to hear a story.”
Read More »
June 17, 2010 at 12:00 pm PST
The case of the compromise of a video to Wikileaks and unconfirmed claims of compromised U.S. State Department cables by an Army Intelligence analyst stationed in Iraq from classified government networks has been widely reported and commented upon, highlighting numerous security, ethical, moral, and legal lapses. There is no doubt that the military and government organizations involved have been conducting similar, less public reviews and official investigations are continuing. As a case study for security risks, this incident could easily generate a laundry list of issues to be examined as well as an equally long list of lessons learned. Although many of the details may never be fully disclosed due to the sensitivity of national security, many of the issues are fairly obvious and well known to security professionals and have been highlighted in numerous case studies. Similarly, most of the issues should have been addressed in policies, procedures, and controls in most business and government environments. The elephant in the room that many would prefer not to discuss and that is often overshadowed by discussion of technologies and policies are the people: the most complex of security risks.
Read More »
Over the last few years, there has been a push to severely limit entire categories of attacks (such as buffer overflows) by incorporating specific hardware functionality with various compiler options to produce more secure code. When developing software, it is easy to mandate that these compiler options be utilized during software development, but how does the end user determine if the options were actually used? Before we can determine what compiler options have been enabled, we must first examine some of the functionality that has been developed to help protect code. Some of the options include:
Read More »
