October 31st, 2007 · No Comments ·
We brought you
- 2 national action: Cybersecurity and critical infrastructure protection
- Cyber warfare – biggest threat is China overestimating its limited capabilities
- Reliability and dependability of information networks – millions hit by BlackBerry systems failure
- Reliability and dependability of information networks – lessons from the Taiwan earthquake
|Be prepared – governments must try to draw their own conclusions and work on contingency plans
|The problem is that while you DO want to inform the public on what is going on, you are at the same time for operational reasons hindered to say all that you know. And the way the press will present the events is likely to more help attackers achieve their purpose than to help inform the public.
|We tell you about the seven lessons learnt from the Estonian attacks.
Because of holding information close to one’s chest, during such an attack as experienced by Estonia, disclosure in practice (Please click on the link, Login as guest – click on this link again and voila free access) means that one gets very little insight into how banks are handling on-line extortion. Moreover, financial institutions are, of course, afraid of reporting similar events to the police because it might reach the public and, thereby, hurt their repuation. The recent SAS disaster with another Q400 plane is just one example of how much more damage can happen to a firm’s brand and customer trust, once the media gets hold of the story.
This story is of interest in so far, as we were not dealing with what is generally understood to be a zero-day exploit – attacking infrastructure (Please click on the link, Login as guest – click on this link again and voila free access).
In fact, no new techniques were being used by the attackers against Estonia. Some have labelled the attackers as being similar to a bunch or mob of soccer hooligans. In this case the only difference seemed to be that they were doing they could be considered the online
ESTONIAN DDOS ATTACKS
During April and May of this year, massive online attacks were launched against Estonia. Although Estonia was able to respond to these incidents and prevent critical damage, the attacks represent an escalation in how attackers may use the net to launch an attack against a country’s communication infrastructure.
Similar to a zero-day exploit – Estonia experienced stages of threat exposure but well understood methods were used by attackers. For instance, the attacks started with pings and quickly scaled up to more sophisticated attacks, including those enabled via botnets from outside Estonia. One attack was launched by a specially crafted botnet with targets hard-coded in their source.
The timing of the attacks, their scope and the sudden availability of botnets to aim at Estonian targets suggest that some level of organization was involved. However, there was no evidence found that would one allow to identify the parties responsible.Overall, neither were the attack methods new or sophisticated nor were they particularly large as far as DOS attacks go or used a new way as is exhibited with zero-day exploits
. Unfortunately, they were enough to seriously disrupt several services in what is a very Internet-dependent country. For instance, because bank sites were crippled, many citizens were unable to conduct ordinary transactions such as buying gas and groceries.
The presentation slides you can get below as used by Hillar Aarelaid
reveals that while one generally is afraid of having to cope with attacks against such critical infrastructure as electricity networks or transportation systems, the distributed denial-of-service (DDoS) attacks against Estonia focused on private networks, users and business infrastructure. Internet Service Providers (ISPs), banks and media houses were the primary attack targets and had to be protected to assure service.The talk summarized and analzyed these attacks and, most interestingly, outlines the defenses taken during these incidents that occurred 2007 between April and May.As well, the presentation provides deep inside into traffic flows and attack patterns that were used by the malicious users during those events.
‘eSStonia’, as used in the title of this presentation, refers to the name given to Estonia on a number of Russian-language websites. This in reference to some Russians accusing the Estonian government of being fascist – see the SS abbreviation.
You can get the complete set of slides here:
Hillar Aarelaid (October 19, 2007). eSStonia- the case of the Estonian DDoS attacks. Presentation slides given at the GovCERT.NL conference, Response & Responsibility track, Lessons learnt. Noordwijk, NL. (8.1 MB download – 124 slides, pdf file, beef starts at p. 13 with traffic graphs and technical details) check it out!
You may have to download the above file using ftp or use Download Manager – nifty open source (copy link into program and voila), since the file could be too big to download with http protocol if one has a busy and/or slow connection (need help, see end of this posting for how to get it).
ISSUES THAT MUST BE ADDRESSED
Going through the slides I was wondering about the role of the international community in coming to the aid of Estonia. Yes it was instructive (positive and negative). More important is, however, can we summarize the 7 lessons learnt from the Estonian attacks to help us all be better prepared?
|Better defense – 7 lessons learnt from the Estonian case
||critical incidence response matters
||have a systematic and clearly understood procedure in place that allows a quick identification of what a critical incident response is and what kind of responses must be invoked rapidly (i.e. automatisms) to have a chance to defend against an emerging threat.
Estonian responders first focused on the targets rather than sources. Filtering technology was used to throttle back on traffic aimed at target systems, which, at its peak, reached between 100 to 1,000 times the normal amount of traffic (see also slides above)
||team must be able to make critical decisions fast
||it was decided to protect certain systems.
Once those were identified, all connections to those systems from outside the country were blocked. In addition, efforts were undertaken to lure away attackers from critical systems those that were less critical ones.
||critical infrastructure can mean something different
||for Estonia, where much business is being done on the net, critical infrastructure meant financial and communication services by private business were under attack and these are critical to the country’s well-functioning economy.
Soon after 2007-04-27 – people were unable to buy such essentials as gas and groceries suing their payment cards.This is in contrast to what we usually accept as being critical infrastructure, namely electricity and transportation networks.
||no new attack techniques emerged
||the level of traffic was not surprising and the mitigation tactics used were tried and true.But what will happen if the attackers are using fast-flux networks or DNS amplification attacks (Please click on the link, Login as guest – click on this link again and voila free access) and to begin with they launch a new variant of a Storm-type worm
||coordination is vital
||all the above can be further complicated if the defense has to be coordinated in real time with several hundred or thousands of ISPs.
As Estonia’s experience illustrates, coordination and cooperation with a centralized incident response is critical to achieve success. Here this was the case with CERT-EE working closely with private ISPs and banks etc. Unfortunately, in many countries such centralized approach will be difficult to achieve unless the right things are put in place NOW.
||trusted social networks are the key to coordinate a successful response
||even CERT-EE needed help and support from others…. and here social networks come in handy … how else can one convince an ISP in another country to take off a server that is part of a fast-flux network?Developing trust takes time and effort while both parties have to give. If the exchange is one-sided, similar to a social relationship such as a marriage, things go sour.
Yes, together we are stronger but only if we have developed trust over time. Thereafter, a certain degree of sharing or disclosure may result in further growth of trust needed to defend better next time.
||post mortem analysis – learning to improve
||without analyzing past events learning cannot occur. The challenge with the Estonian example is that other countries must learn from the Estonian experience.Can there be enough disclosure allowing this exchange of information to happen? Yes, but only based on trust that will, in turn, enable other national states to improve their procedures in case of an attack.As importantly, this type of international collaboration must be improved beyond government CERTs. Hence, without getting the major ISPs and financial institutions involved in other countries, post mortem analysis might not help us much in preparing for the next attack of this kind or worse (e.g., more sophisticated against several states at the same time – see point 4).Could the European Union through something like ENISA help with these efforts? Furthrmore, might EISAS be a venue toward success or would such a system be too big of a network to instill trust amongst members?
|Better security means disclosure but without trust it remains a pipe-dream
Point 6 does not mean that we do not need regulatory frameworks to lock these hooligans up if need be (see Sweden – DDoS and cybercrime convention etc.). As importantly, while collaboration might start via social networks, a formalized structure has to be put in place. This allows collaboration to work regardless of people changing jobs.
Accordingly, agreements and letters of collaboration or support signed by ministers or other parties responsible such as a CEO are then needed to make it work as smoothly as possible (e.g., get funding to meet and discuss what was learned at one location).
After anlayzing points 1-7 above, it is vital that the lessons learnt culminate into appropriate changes in the response system. Once that has been adjusted, a fire drill has to be conducted to make sure it works as intended. In practice, this means that both, governmental and other parties, have to test how it works to be prepared for the day when another attack really hits.
Without testing if emergency procedures work, especially collaboration across agencies and corporations, it will most certainly not work as intended. If we need convincing, nobody would dare sending an army into battle without having trained its soldiers. Neither would a town dare in having a fire brigade that has never received any training or practiced its emergency procedure with a fire drill. The same applies for information security and protecting communciation networks large and small, national and international, design a response system and test it with an exercise every few months but at least once a quarter.
OTHER GovCERT.NL presentations from OCTOBER 2007
2 One Laptop per Child (OLP) – GovCert.NL symposium – empowerment for end-users working with their desktops
2 govcert.nl 2007 conference – user empowerment and information security
To make it more convenient for you to take advantage of CyTRAP Labs’ offerings, just provide us with your e-mail address below. You can personalize your subscription to make it suit your needs.
SECOND ALTERNATIVE FOR GETTING FILE
Click the following link to retrieve the file:
If the above link isn’t clickable, copy and paste the link into a browser to download the slides