Mail authentication schemes like DKIM and the new dmarc.org group use cryptographic signatures to help authenticate mail and prove that it really is from who it purports to be from. So, if the mail can authenticate the sender, the phishing problem goes away, right?

Unfortunately not. One huge problem is that even if you have all the crypto stuff so you can be 100% sure that a message really is from, say, BANK-AMERICA.COM, you don't know whether BANK-AMERICA.COM is actually your bank or not.

I've made a little game called Phish or Fair. It shows you a domain name, you guess whether it belongs to Bank of America. Try it out and see how you do.

Then see if you can figure out why a bank would use over a thousand different domains. My example here is Bank of America, but they're no worse than other big banks; I picked them because their name is easy to search for.

If banks were serious about phishing, they'd pick one name, one domain, and use that consistently. But they don't.

PS: BANK-AMERICA.COM belongs to some guy in France.

Written by John Levine, Author, Consultant & Speaker

Scotland Yard. Some of the interest is due to marvel that two such sophisticated organizations could be had, some is due to schadenfreude, and some is probably despair: if the bad guys can get at these folks, is anyone safe? To me, though, the interesting thing are the lessons we can learn about what's wrong with security. Many of the failures that led to this incident are endemic in today's world, and much of the advice we're given on what to do is simply wrong or arguably even harmful.

The first issue is how Anonymous managed to record the call. The ways we'd see it done in a movie — tapping a phone line or listening to law enforcement official's cell phone — are comparatively difficult to do. They're not impossible, but they're not the easy way for a task like this. Rather, what appears to have happened is what most outside security experts immediately suspected: Anonymous read an email giving the details of the call, and simply dialed in, in the same way as the intended participants. The message was sent to "more than three dozen people at the bureau, Scotland Yard, and agencies in France, Germany, Ireland, the Netherlands and Sweden;" a single security flaw anywhere along the chain could have resulted in the leak.

Here we see the first flaw: the call details were, effectively, a shared credential. It is quite probable that the conference call moderator had no idea who had dialed in. We see the same phenomenon with role accounts: many people share the password for the login, email access, etc. It may happen in the large — postmaster@example.com — it may happen when a vacationing executive gives a secretary the password to his or her email account; it may happen when spouses or romantic partners share passwords. Whatever the reason, it creates a security risk.

Reading further into the article, we see that "One recipient, a foreign police official, evidently forwarded the notification to a private account". At that point, it's tempting to blame that official, say he or she was poorly trained or disobedient, and stop worrying. Apart from the self-evident fact that a single security lapse shouldn't compromise everything (a proposition easier to state than to make happen), I strongly suspect that this unnamed official was behaving very rationally: he or she either wanted email access that was too inconvenient via the proper mail servers, or wanted a different human interface. If this person had no access to work email from home, or felt that, say, gmail was enough better that their productivity was improved, it's not surprising that this would happen. It shouldn't happen — and one would hope that a police official working on cybercrime would understand the risks — but in a strong sense the failing was organizational: if my hypothesis is correct, they may have failed to make it easy for people to do the right thing. Let me stress this: a security mechanism that is so inconvenient that it tempts employees to evade it is worse than useless, it's downright harmful. (Note well: I'm not saying that this official did the right thing; I'm saying that organizational policies or technologies may have led to too much temptation for people who are trying to be more productive.)

But how did Anonymous know which outside email account to monitor? This article notes that assorted groups have made a habit of targeting law enforcement email servers, with some success against less-sophisticated police organizations. That would yield a list of email addresses, and perhaps passwords. Perhaps more importantly, it can show who was using an outside mail server, one that isn't protected by VPNs, firewalls, one-time passwords, and the like. At that point, the attackers have several ways to proceed.

First, they could try this law enforcement email password against the outside mail server. The odds are high that it will succeed; far too many people reuse passwords. And why do they do this? Because they have too many passwords to remember, especially if they're all "strong". And of course, people are forbidden to write them down.

Most of the advice we get on security starts with "pick a strong password". (Look at CERT's advice: the very first thing it tells people to do is "always select and use strong passwords". Patches, a really effective defensive measure, are mentioned fourth.) Strong passwords are not a bad idea, but you're in much more trouble if you reuse passwords. No one can possibly memorize all of the passwords they have; reuse is the usual answer.

A second way in which the attackers could have compromised the official's account is via a spear-phishing message, booby-trapped to install a keystroke logger. That's been seen, though more often in a national security context. If the attackers did this, even encrypting the emails wouldn't have helped; the same malware that stole the login password could probably steal the private key as well. But I'm pretty sure that no encryption was employed; most encryption systems are too hard to use. Smart-card based decryption would have helped (though such things are far less convenient to use); though there are still attacks, they're more involved, and arguably less available to a group like Anonymous.

It's clear that there wasn't a single failure involved; in particular, the crucial mistake of forwarding work email to a personal account was quite plausibly a rational response to organizational policies. Preventing recurrences of this kind of incident will not be easy; there are too many weak spots.

Written by Steven Bellovin, Professor of Computer Science at Columbia University

Since Verisign is a public company, they file a financial report called a 10-Q with the SEC every quarter. According to the SEC's web site, Verisign filed their 10-Q for June through September 2011 on October 28th. where it's been available to the public ever since.
Like every other 10-Q, it has a Risk Factors section which lists all the reasons that the company might fail, so don't sue us. Normally those sections are pretty routine, key employees might quit, customers might desert us, key contracts might not be renewed, that sort of stuff. But this 10-Q contained this bit:

We experienced security breaches in the corporate network in 2010 which were not sufficiently reported to Management.

In 2010, the Company faced several successful attacks against its corporate network in which access was gained to information on a small portion of our computers and servers. We have investigated and do not believe these attacks breached the servers that support our Domain Name System ("DNS") network. Information stored on the compromised corporate systems was exfiltrated. The Company's information security group was aware of the attacks shortly after the time of their occurrence and the group implemented remedial measures designed to mitigate the attacks and to detect and thwart similar additional attacks. However, given the nature of such attacks, we cannot assure that our remedial actions will be sufficient to thwart future attacks or prevent the future loss of information. In addition, although the Company is unaware of any situation in which possibly exfiltrated information has been used, we are unable to assure that such information was not or could not be used in the future. The occurrences of the attacks were not sufficiently reported to the Company's management at the time they occurred for the purpose of assessing any disclosure requirements. Management was informed of the incident in September 2011 and, following the review, the Company's management concluded that our disclosure controls and procedures are effective. However, the Company has implemented reporting line and escalation organization changes, procedures and processes to strengthen the Company's disclosure controls and procedures in this area.

Apparently nobody got around to reading it until today, at least nobody who understands the business well enough to know what it means.

All the press reports I've seen just regurgitate that paragraph, adding a few quotes from people close to Verisign who all said they didn't know about it either, and security types who told us that it's an enormous big deal. (Now that you've read the paragraph, you're as qualified to pontificate as anyone.)

Personally, I don't know if it's an enormous big deal or not. Risk factor sections tend to be written as pessimistically as possible, so you can skip over the parts about they cannot assure you and so forth. One thing I do know is that it happened over a year ago, so if anything significant happened as a result, and Verisign knew about it, they'd have told us about that, too, on the principle that you release all your bad news at once. So this means that either it really was just a minor network breach, or the evil consequences are so deep and subtle that we may not know about them for years and years, if ever. I'd tend toward the former, but then, I'm not a Verisign stockholder.

Written by John Levine, Author, Consultant & Speaker

Remarks by Kroes:

"The Internet does not belong to any one group, but attacks on it affect every group. So let's work together, all sectors, all levels, public and private, national, international and European. So that we can safeguard the security of the systems that increasingly underpin our lives, today and in the future."

"In tomorrow's world, if the Internet is not secured, nothing will be."

Full statement published here.

From the report: During the third quarter of 2011, Akamai observed attack traffic originating from 195 unique countries/regions, up from 192 in the second quarter. After making its first appearance in the top 10 list in recent memory in the second quarter, Indonesia vaulted to the top of the list this quarter, generating 14% of observed attack traffic. Myanmar, which had suddenly appeared at the top of the list in the prior two quarters, disappeared from the list just as suddenly in the third quarter, potentially indicating that the attack traffic that had been observed originating from the country has either been shut down, or is now coming from other places. With Myanmar dropping out of the top 10 list, South korea moved into it, more than tripling its observed level of attack traffic, responsible for 3.8% in the third quarter. In addition to South korea and Indonesia, Taiwan, China, India, and Egypt were all responsible for higher percentages of attack traffic as compared to the prior quarter.

Attack Traffic – Top Originating Countries

Read full story: Dark Reading

This is a widely attended educational event hosted by the Congressional Internet Caucus Advisory Committee (ICAC), part of a 501(c)(3) charitable organization. More information about the 15th Annual Tech Exhibition and Reception can be found at:

http://www.netcaucus.org/events/2012/kickoff/

What: Congressional Internet Caucus Advisory Committee's 15th Annual Kickoff Reception & Technology Exhibition
When: 5-7 PM, Wednesday, Jan. 25, 2012
Where: Hart Senate Office Building, Room 902
RSVP: RSVP's appreciated. Please register at the website or onsite at the event.

Follow the event on Twitter: #ICACTech

This event is free and open to the public.

In July 2012 Verisign will award two $200,000 grants to the researchers who submit the most compelling proposals focused on the infrastructural and access challenges facing developers, service providers and most importantly, users in the developing world and elsewhere. The 2012 grants represent a continuation and expansion of a successful grants program that concluded in October 2011. Full details of the grant program, including details on how to apply, are available at www.verisigninc.com/grants.

"The continuing success of the Internet's global expansion will hinge on the existence of robust, secure and constantly improving core infrastructure," said Dr. Burt Kaliski, Jr., senior vice president and chief technology officer of Verisign. "Verisign has always been committed to upholding the stability and security of the Internet and is proud to support the research that will keep the infrastructure strong for the next billion Internet users in the developing world."

Verisign launched the Infrastructure Grant Program in 2010 to coincide with a yearlong celebration of the 25th Anniversary of .Com. In the inaugural program, Verisign awarded four $75,000 grants (for a total of $300,000) to university researchers to support compelling infrastructure research projects. That program concluded in October 2011, when the four winning researchers presented their findings at a grant symposium at the Newseum in Washington, D.C.

Building off of the success of the inaugural program, Verisign has both increased the size and narrowed the focus of the grants in 2012, soliciting research that focuses on the infrastructural and access challenges faced by users in the developing world and elsewhere.

To judge the grant submissions, and determine the final grant awardees, Verisign is assembling a blue ribbon panel of experts who have played leading roles in developing the policies and technology that have supported the Internet's growth. The full list of judges will be posted in the coming weeks.

Verisign will announce the winners of the 2012 Infrastructure grants in summer 2012.

Lying at the heart of the cycle is the fact that these hot threats have never been particularly new. Within the security community, we tend to talk about the evolution of the threat landscape. If you speak with the relevant experts about a particular threat category you'll uncover that the back story to many of these "hot threats" often goes back a decade or two. Mobile malware threats are certainly no exception.

A history lesson in the evolution of mobile malware is hopefully not required, beyond to say that today's hot threat has evolved over a couple of decades and poses less of a technical challenge than many believe or commonly portray. But as history so often reveals in these cases, when a new threat is similarly labeled and thrust into the limelight for the first time, there's all too often a stampede towards apparently novel and threat-specific solutions.

Solutions (and I use that term very loosely) within the mobile malware threat mitigation arena are increasingly difficult to differentiate from one another. In the confusion of defining a new threat and the nomenclature that accompanies it, the underlying technologies and viability of their approaches can get lost rather easily.

What is the "Mobile Threat"?

When I meet with customers, prospects and journalists, I get a lot of questions about the Mobile Threat. In particular, how should businesses work to defend against it? My immediate response tends to be "what do you define as the mobile threat?"

The term "Mobile Threat" is amorphous — it has become a catch-all to encompass anything not physically tethered to a network and happens to be newish from a technology perspective, and likely subject to some new (previously unencountered) formulation of evilness. That sounds like a kind of wishy-washy definition (and it is), but catch-all's usually are. Instead, I'd rather focus on one aspect of the Mobile Threat — that of the mobile malware threat.

As I described in a blog entry illuminating a handful of security predictions for 2012, mobile malware threats continue to be misunderstood. It's all too easy to dive deep in to the various technologies that expose mobile devices to new forms of attack and vectors of compromise; just as it's rather easy to describe the various built-in technologies that the developers and engineers of the mobile devices have included to prevent many of the "legacy" threat categories we're already all too familiar with.

You could spin a lot of cycles looking into the "what if's" of mobile security threats but, at the end of the day, if you want to determine which threats and attack vectors are going to be the most immediate and protectable concern for your organization you only need to understand two things — how do your employees really use their mobile devices, and how are cybercriminals going to monetize their control of these devices?

For a moment, think about this. While Smartphones and Tablets often share a common operating system and maybe even the same application markets or stores, they are used in different ways, at different times, to accomplish different tasks. For this reason the attack vectors cybercriminals (and espionage-focused agencies) choose to launch against them are different for each category of mobile device. The tools — of which the most commonly encountered category is "malware" — are likely to be transportable between devices, but the vectors for installation and the type of meaningful information that can be extracted via them are quite different.

When it comes to the cybercriminals that target mobile devices (which constitute the core element of the "Mobile Threat"), it is interesting to note that they're pretty much the same entities that have been historically successful in targeting traditional non-mobile devices. That shouldn't really be a surprise to anyone — it's all about monetizing the victims. If a particular cybercriminal group specializes in online banking fraud and a third of their potential target list shifts to tablet-based banking applications, they need to make a business decision — do they target the new platform or optimize their attacks against the traditional devices. As mobile application use increases, there's an increasing driver for cybercriminals to invest in new mobile tool development. Similarly, if employees are wirelessly connecting to corporate systems and assets using mobile devices in preference to other traditional platforms, the attackers are forced to target these new devices and develop the appropriate tools.

It's important to note that, while the end-point device is physically changing and the specifics of the tools the criminals need to develop and install upon the compromised devices is also changing, at the enterprise network and Internet infrastructure level there has been no change in criminal behaviors; nor is any change actually needed by them. The vast majority of C&C communications are HTTP-based regardless of the malware family or compromised device type. By speaking the same language, the cybercriminals can keep their existing infrastructure… business as usual!

Written by Gunter Ollmann, VP of Research at Damballa

After thinking about it for a while, I came up with the following representation:

The two axes represent how skilled the attacker is, and how much a particular victim is being targeted.

I dub the lower left "joy hacks". These are the province of the script kiddie or the novice hacker. They've learned about "cool" tools, and they try them out on anyone in reach. Ordinary care will generally deflect joy hackers.

As the attackers' skill level moves up, you get what I call "random hacks". (I'm not fond of that name; any better suggestions?) People who write new worms often fall into this class, especially if the worms exploit 0-days. But worms are generally random in their targets. If you're a spammer or a botnet builder, though, that's fine; a low-bandwidth node may not be able to spew as much garbage as a well-connected one, but as the saying goes, "from each according to his ability". Your best defense here is the usual technical litany: turning off unneeded services, keeping up to date on patches, etc.

The X axis, which reflects targeting, does not necessarily imply particular technical measures. In general, though, it means that the attacker will gather as much intelligence as is feasible about the target. (Again, I'm quite unhappy with my name, especially when I have to translate it into the noun for the attacker.) Spear-phishing attacks, which show a knowledge of the organization and the victim and perhaps the purported source of the message, show the efficacy of this. The attacks themselves may not be novel, but the extra information the attacker has helps immensely. This is an arena where education and process help.

The upper right (or the upper right of the upper right) is, of course, the Advanced Persistent Threat, what John Erlichman so memorably called the "big enchilada”. Here, you need everything you can bring to bear and then some: patches, education, process, luck, and perhaps sacrificing the entrails of a virgin artichoke on your keyboards.

Do APTs exist? Assuredly; if it accomplished nothing else, Stuxnet showed that. Are most attacks on high-profile companies APTs? I suspect that some are and some are not — but I haven't investigated or even reviewed the investigation of any of them, so I won't comment. Are nation-states behind APTs? Unknown and probably unknowable, though the more sophisticated the attack (and especially the more comprehensive and sophisticated the target intelligence was), I'd say it becomes more likely (which is not the same as "likely"). Should you worry about APTs? Ask yourself this: who would be likely to target you, and how good are they?

Written by Steven Bellovin, Professor of Computer Science at Columbia University

Nixu Secure Name Server (SNS) 2.5 Series
Introducing a number of user-friendly features such as out-of-the-box support for DNS views and newly designed Graphical User Interface.
(Click to Enlarge)

"To reduce the number of attack vectors, our recommendation in most enterprise use cases has been to run dedicated DNS servers for external and internal networks" said Ville Kummu, the Director of Technical Operations at Nixu Software. "Having said that, we are seeing an increasing number of use cases where serving out several views from an individual DNS server is warranted. These include gateways between mobile networks and extranet set-ups where enterprises serve out different DNS data to general public and their external partners."

The new GUI in Nixu SNS has been designed based on an active dialogue with Nixu DDI end-user community. To make their lives easier, the development efforts were targeted at creating a simplified way of presenting and managing general DNS configurations. "After providing a sneak peek preview of Nixu SNS 2.5 to select customers, they described the new GUI as modern, clean, minimal and intuitive. That really made my day." Kummu added.

Find out more about Nixu SNS and download a free evaluation.

What Happens in an Internet Minute
Source: Intel (Click to Enlarge)

Looking at the traffic data, Intel asks if there is sufficient attention being paid to investment in infrastructure.

Imagine the state of the network in three years, when the number of connected devices is projected to be double the world's population. Can our networks scale to handle predicted traffic and meet consumer expectations for immediate access from multiple devices?

What about security?

Among highlights from the infographic:

• Nearly 640 Terabytes of traffic are being transferred each minute by global IP networks;
• 6 million Facebook views; 2 million Google search queries;
• 30 hours of video are being uploaded to YouTube; and
• 1.3 million videos are being viewed.

The email I received put it this way:

Governments invest in infrastructure every day — roads, bridges and airports — but what about network infrastructure?

Hopefully, network operators will not follow the practice of governments in infrastructure investment. The state of our roads, bridges and airports seem to be case studies on why network investment is best handled by the private sector. My experience is that governments tend to use "just too late" provisioning.

Written by Mark Goldberg, Telecommunications Consultant