The Symposium, held during February 1-3, 2010 under the sponsorship of ICANN’s Security Group and DNS-OARC, provided an opportunity to exchange ideas among people from all parts of the DNS community about what it means for the DNS to be “healthy,” and how the community should go about measuring its health. Co-sponsoring the symposium were Kyoto University and Nara Advanced Institute of Science and Technology.

According to the conference keynote speaker, Andrew Sullivan [of Shinkuro, Inc.], one of the big challenges in defining health is that health of a large ecosystem such as a forest often supports — even encourages — locally unhealthy conditions. In other words, health is not a universal term that applies equally to all parts of a system at once; it implies a value of health that is relative to the entire system. Drawing a similar kind of parallel between the DNS and human health, many of the speakers and participants grappled with notions of measurement, privacy preservation, pattern analysis and, notably, the ongoing challenge posed by searching for unknowns in large data sets.

The conference website contains all of the symposium background material, and will also contain the final report, due to be published in March 2010.

1. Activate your response plan

Rather than responding to the waves of panic that are likely circulating around the sales and executive teams, the most productive thing to do is to rely on your advance planning to start the response process rolling.  Remembering that the key to solving problems is usually communications, you should focus on providing company executives with regular updates. Then you can focus on the technology issues without undue badgering.

This is, I think, the right time to remind that one of the best antidotes to security crises is to have an computer security incident response team (CSIRT) capability.  This resource, whether in-house or contracted out, can save countless amounts of downtime. You can learn more about incident response from places like the Forum of Incident Response and Security Teams (FIRST).

2. Set up a war room

When Skype suffered a major outage — which, though not a DDoS, had some of the massive but temporary service disruption characteristics of a DDoS — we set up two war rooms: one near the company executives and one in the heart of the engineering center. This kind of arrangement not only allows “the right people” to come together face-to-face, it also allows for a focal points to form for network operations, media/PR, and the executive team.  This location is focused on communication, so be sure to have redundant means at your disposal in case your chosen system (phone line, Jabber, Skype, etc.) is itself impacted by the attack.

3. Think tactically

Your first general priority is limiting downtime, so you have to quickly assemble the data available to you to identify the cause of the problem and its target. Work with your ISP or network peers to maximize your options within the terms of your service contract, and preferably without incurring additional costs.

While you can have traffic shunted or blackholed, do keep in mind that such measures as having new network addresses assigned to critical resources may likely cause lasting secondary effects, such as the invalidation of IP-bound digital certificates. For lengthy attacks, it may be worth the effort to have a plan for a temporary customer notice website, which can keep customers informed of the company’s efforts to restore service.

For small businesses, these kinds of services can often be arranged ad hoc, but it’s best to have a planned service with a specified DDoS service level agreement. In addition, cutover of these services may require coordination with your domain registrar or your ISP.

4. Think strategically

Your next general priority is preventing further downtime. This requires more thought and more research; you need to identify the rationale for the attack. In other words, why did someone target your infrastructure to attack today? Is there a pot of gold at the end of the attack?  Is the attack you’re experiencing merely cover for another, separate attack whose aim is to steal valuable customer data?

There are many possibilities here, but the point to make is that the CISO of the organization needs to be well aware not only of the technology in play, but also of the risk matrix relating to data available on the network and even things like public perception of the company. Many otherwise mundane companies have been hit by hackers or so-called hacktivists merely due to the public position of a single member of the company’s board of directors.

5. Document, review and train

If there’s one silver lining to an attack, it’s that the event can serve as a crucible for learning for the entire staff, including people far outside the technical teams. Take notes as the event unfolds, including the time that decisions (even mundane ones) were made. Also take time to understand the cost impact of the attack and its remediation. During a post-mortem, these notes will serve better than any cockamamie exercise could to develop better processes and procedures for the next time.  The bad news is that there probably will be a next time.

It was a little bit unnerving to give a talk about Japanese language and business culture to an audience that included a large number of Japanese. After all, they would all have much more experience than I do in Japanese business settings. But I tried to make the case that the differences–things that lead to misunderstandings–are extremely important, too. I was really excited to get positive feedback not only from the overseas audience, but also from the Japanese audience. That so many people enjoyed the talk made me very pleased indeed.

I remember going to my very first FIRST annual conference in Monterrey, Mexico, back in 1998. At that time, I was an an official representative for Sun Microsystems to the organization and was amazed by the level of international participation. Since then, interest in computer security incident handling has grown exponentially, and therefore the breadth of the audience has become far more diverse, both in geography and in mission, than it was even ten years ago. I think that this change speaks volumes about the information security business, and I think it’s a trend to which we should pay close attention.

My goal for this keynote is to set out what I think incident handling will mean in the context of cultural changes in the information security handling profession. After all, even the smallest of organizations is investing — willingly or not — in response measures to security threats. In the face of the present economic downturn, it will be very interesting to see how many companies will remain interested in computer security.  But because even the most Luddite of company executives sees the risk that comes along with ignoring the perils of information security, I doubt the lights in the IT security department will be going out anytime soon.

If you’re in the information security industry, I highly recommend the FIRST annual conference.  If you can make it, by all means please attend!

Although there have been previous reports of foreign-sponsored cyber-penetration attempts against the US power grid, this initiative by NERC represents the first tangible acknowledgment of the scope and complexity of the problem.

The original article is available from the Wall Street Journal online.

The Hoover Institution recently published a call-to-arms about botnets, provocatively declaring that botnets should be called “electronic weapons of mass destruction”, given the fact that critical infrastructure can be easily put at risk by botnet operators. And this point is driven home in the fact that major power and telecommunications utilities are already highly interconnected with the public Internet, thus allowing for the asymmetric leveraging of tens or hundreds of thousands of mundane home computers — via the illicit introduction of malware — into attacks on such things as SCADA (supervisory control and data acquisition) elements that manage critical infrastructure.

As a case study, the article’s authors explore the case of the April 2007 cyberattack against Estonia, both in terms of what was put at risk as well as how the world should respond to such cases. Although we still find it a stretch to make the parallels with military conflicts too concrete, the point is well taken that such forms of asymmetric warfare put the advantage in the corner of the attacker, whether that attacker is a sophisticated nation-state or a ring of profiteering cyber-criminals. Both of these groups are abetted by the same lack of security on the Internet.

Although the article is long on observation and short on prescription (aside from advocating a very active form of defence), it is a very well-reasoned summary overview of the threats that exist today on the Internet. In short, it explains why we need a call-to-arms and what might happen if we don’t heed the warning.

The article entitled eWMDs: the botnet peril by John J. Kelly and Lauri Almann appears in Policy Review, No. 152, Dec. 2008/Jan. 2009 by The Hoover Institution.

The flaws highlighted by US-CERT include a buffer overflow, several denial of service risks and the possibility of privilege escalation. These are serious enough, but once again incident response teams are faced with a challenge in finding information about remediation for the vulnerability or even a reliable point of contact at the vendor for obtaining further information.

According to the US-CERT circular, the flaws affect version 5.7 (and earlier) of its Habitat software, and AREVA has released a security patch that addresses the flaws. It is worth noting that the bugs are serious, allowing a knowledgable attacker to crash monitoring systems and, in the most serious instance, to execute arbitrary commands remotely, without the need for access credentials. For this reason, US-CERT highlighted the importance of network monitoring and of ensuring isolation of networks containing SCADA control and measurement components. Unfortunately, even the more security conscious of infrastructure operators is more and more likely to have planned or unplanned points of connection to public networks.

It is unfortunate that SCADA equipment vendors are often less than transparent about the risks in their products, for commercial reasons.  And because of the unique nature of the SCADA industry, there is far less independent and non-government-funded scrutiny of these network components. In this line of business, there seems to be an unhealthy degree of what appears to be security through obscurity.

Notes:
[1] CVE is the Common Vulnerabilities and Exposures database

The vulnerability is tied to a cryptographic weakness related to the MD5 cryptographic hash function. The practical effects to web security based on this weakness is serious, but can be corrected by replacing vulnerable server certificates with ones not yet known to be vulnerable to attack.

In January 2009, Govcert.nl published a very useful fact sheet on these vulnerabilities that provides both a basic primer on the problem and the pros and cons of the available remedies.  Although there is no doubt that sites using MD5 hashes need to take action, these guidelines are intended to help IT decision-makers more easily choose the best course of action available for their individual circumstances. [The following is based upon Govcert.nl Factsheet FS-2009-01, which is available from their website, and subject to a Creative Commons by-sa 3.0 license.]

Vulnerabilities in the Internet PKI caused by the use of MD5

On 30 December 2008 a group of researchers at the ‘Chaos Communication Congress’, an annual security conference held in Berlin, gave a practical demonstration that the ‘Public Key Infrastructure’ (PKI) on the internet has some serious weak spots.They demonstrated that they had been successful in creating a rogue certificate that was trusted by all common browsers.

An overview of the facts:

Researchers have created a rogue certificate that can be used to impersonate any website in the world.

• This rogue certificate is automatically trusted by all the common browsers.
• The researchers achieved this by making use of weaknesses in MD5, a cryptographic hash function.
• Even though the weaknesses of MD5 have been known for many years, it is still used to sign certificates on the internet.
• If you still make use of certificates that are signed using MD5, then you need to replace it as soon as possible.

In this factsheet you can read a short explanation of the research, the risks in the short term and the actions that need to be undertaken both by yourself and by other concerned parties. We conclude this factsheet with two paragraphs with background information on digital signatures, hashes, collisions and the shelf life of cryptography in general.

The research in brief

This research has an impact on the use of certificates to set up secure connections between a browser and a website. This concerns an ‘HTTPS’ or ‘SSL/TLS’ connection. Such a connection can be recognised within browsers by means of a padlock or in some cases by a coloured address bar.

The research demonstrates that when a certificate has been signed (or appears to have been signed) by a competent authority (a Certificate Authority or CA for short), this no longer offers any guarantee that this certificate was also verified by this authority. This means that there is no longer any guarantee that the certificate actually belongs to the correct party. In other words: in the past you had a large degree of certainty with a secure connection that you were dealing with the right website (after checking the certificate). Now it has been demonstrated that this security can be compromised by a practical attack.

Certificates and secure connections

A certificate is the basis of two functionalities of a secure connection. These functionalities are most of all important for applications where personal or financial data are transmitted to another party, for example in the case of telebanking, egovernment services and online shopping.

1. The encryption of data exchanged between the browser and the website. The result is that data can no longer be read by third parties.
2. The possibility of monitoring whether a connection has really been made to the correct website.

The research to which we refer in this factsheet has an impact on the second function of a certificate.

Because there are still CAs that sign certificates with MD5, an obsolete cryptographic method, the researchers succeeded in creating a rogue certificate that appeared to have been signed by an official Certificate Authority (a root CA). As a result this rogue certificate is automatically trusted by all common browsers. What is even worse is that the rogue certificate itself can act as a Certificate Authority.

As a result, the researchers are in a position to create and sign a certificate themselves for any random web server in the world, which cannot be distinguished from a real one and which is trusted automatically. They can therefore impersonate any random other party without the visitor to a website being able to discover this on the basis of the certificate.

What are the risks in the short term?

The researchers admit themselves that it is unlikely that another person is going to be able to implement such an attack on the internet PKI in the short term. GOVCERT.NL has also not detected any attacks at the time of writing and more or less discounts that there are already rogue certificates in circulation at this time.

In order to carry out such an attack one needs specialised knowledge of the weaknesses in MD5, the obsolete cryptographic method still used by some CAs for signing certificates. In addition, the researchers themselves developed methods to create a rogue certificate in a short time. They believe that the CAs in question that still
make use of obsolete digital signatures will have enough time to move over to new methods.

In conclusion, the researchers have taken some measures to prevent the certificate they have created from being misused. The researchers have nonetheless made it known that they will eventually publish their methods, probably in a few months.

If it was not already clear following the previously publicised attacks in 2005 and 2007, there is not the slightest doubt now that it is irresponsible to continue to use MD5.

Protection against vulnerability and the actions you can undertake yourself

The researchers demonstrated with their research that the internet PKI contains weak spots because some CAs still make use of obsolete means of creating a digital signature. As a consequence the entire PKI is at risk, not just those persons who have dealings with the CAs in question. The following analogy will clarify this to a certain extent: if it turned out that it was very easy to obtain a real passport in a certain municipality in the Netherlands under false pretences, then that would be a problem not only for the residents of that one municipality but would also undermine confidence in the value of every passport for everyone who came into contact with passports.

The foregoing makes it clear that individual end users and owners of certificates can do very little to protect themselves against this vulnerability, let alone solving these. In an ideal situation the following would now happen:

1. Every CA that still makes use of MD5 would stop doing so as quickly as possible and would migrate to a better hash function.
2. Everyone who still has a certificate that has been signed with MD5 will replace this as soon as possible (see also: ‘Replace MD5 … but with what?’ on the following page).
3. If the above two requirements are met (or that much earlier as is considered necessary), the browser vendors can withdraw support for MD5.

The most important parties in the above process are the CAs and the browser vendors. CAs bear a responsibility to make use of sensible cryptographic methods on the basis of their task as a trusted organisation that is permitted to sign certificates within a PKI. It is necessary to evaluate on a regular basis whether a cryptographic method is (still) reliable. It is the case that cryptographic methods that are reliable now may not be reliable for various reasons at a later time.

Browser vendors can exercise a great deal of indirect influence on CAs, because they determine which certificates—and therefore also the type of certificates—they include and trust in their browsers as standard. In this way they can serve as an extra motivation. If browser makers stop supporting MD5 (the weak hash function), then this would have immediate consequences for the certificates signed using MD5 that are still in circulation. These will stop working or generate warning messages, depending on the choices made by the browser vendors.

All this does not mean that you should not undertake a number of actions yourself:

1. As an end user there is almost nothing you can do to reduce the risks of this proven threat. At this time there are still so many certificates with a MD5 signature in circulation that rejecting such certificates completely is not really a practical solution. There is an extension in circulation for Firefox5 that alerts the user to signatures based on MD5, but in practice this normally generates false positives. This is only an option for home users with expert knowledge.
2. It is important within organisations to keep track of which and what type of certificates are in use, even if you have your own internal PKI with a root certificate. This includes certificates from your official websites, your internal websites, client certificates and other solutions that make use of SSL certificates, such as SSL VPNs.
3. If you are still signing certificates internally on the basis of MD5 then make plans to phase this out. If you make use of certificates that are signed on the basis of MD5 then you need to replace these as soon as possible with certificates signed on the basis of a more recent algorithm. You can read more in the following paragraph about your options.

Replace MD5 … but with what?

The researchers’ motivation in publishing this research was to demonstrate that it has for a long time been irresponsible to use MD5 to sign certificates and they have been very successful in this. You therefore need to migrate now, but the question is: “To what, if MD5 is no longer satisfactory?”

The successor to MD5 is SHA-1, but an even newer variant has been available for some time, namely SHA-2 (a collective name for SHA-224, SHA-256, SHA-384 and SHA-512). It has also been demonstrated that SHA-1 has some weak spots and it is expected that SHA-1 will in the not too distant future disappear as a result of practical attacks. The US National Institute of Standards and Technology (NIST) goes even further. It requires American government organisations to abandon SHA-1 and move over to a SHA-2-variant before the end of 2010.

You have two options at the moment:

1. Transition to SHA-1. This is the easiest option. SHA-1 is supported by practically all CAs and all software. It is therefore relatively easy and cheap to make the transition. The disadvantage of this option is that SHA-1 already includes known vulnerabilities. Although this is not yet a practical threat, the strength of SHA-1 may soon come under pressure. If this is the case then it will be necessary to make a new transition, which will involve fresh costs.
2. Transition to SHA-2. This option is less simple. Support for SHA-2 is far from being a matter of course for all CAs and all software. Before you migrate to SHA-2 you will need to find out if you are also going to have to upgrade your software. This of course entails additional costs. Moreover, the use of such a certificate can also create a problem for some visitors to your website if their browser does not support SHA-2. There is also an advantage to migrating to SHA-2. It is by far the most future-proof option at this time because SHA-2 is expected to last another ten years before any practical attacks will be possible.

[The original factsheet was published by Govcert.nl and is available in PDF format from their website.]

According to the survey, nearly two-thirds of Millenials are either unaware of their companies’ information technology policies or are simply not inclined to follow them. It also highlighted the acceleration of a trend among younger workers that shows a bias toward using technology to connect with colleagues, peers, family and friends, instead of relying on telephone calls or face-to-face contact.  In other words, young workers’ habits are underscoring the difference between the technology that organizations provide their workforce and how young workers actually want to use technology to communicate and collaborate.

“The message from Millennials is clear: To lure them into the workplace, prospective employers must provide state-of-the-art technologies,” says Gary Curtis, managing director of Accenture Technology Consulting. “And if their employers don’t support their preferred technologies, Millennials will acquire and use them anyway. In order to acquire and retain the best talent, organizations must understand the technologies that the new workforce expects — and then find a way to support their employees without compromising enterprise security.”

The Accenture survey is the latest in a long string of studies in workforce behavioral analysis that points to employees as the weak link in the security chain.  While social networking software has long been the bane of CISOs, the evidence seems clear that information security and human resource policies must take modern technology into account or risk becoming obsolete.

What’s most interesting about this report is not the specifics of any particular set of cybercriminals, but instead in the number of channels used to convey the goods as well as the pedestrian style of commerce, including several online How-To guides, used to entice would-be sellers to peddle their stolen goods.

Although this report is heavily biased toward reporting numbers and statistics, by enumerating price lists for stolen data and of the number of command-and-control networks used on a daily basis by cybercriminals, CISOs can put a much more firm opportunity cost estimate for failure to apply proper controls to sensitive customer data. In addition, in an appendix to the report, Symantec offers readers its recommendations for mitigation strategies to shore up data security risks.