Archive for the ‘Analysis’ Category

Verizon at SANS Incident Detection Summit

Wednesday, November 18th, 2009

The SANS WhatWorks in Incident Detection Summit 2009 will be held on December 9-10 in Washington, D.C. It follows the 2008 and 2009 editions of the SANS WhatWorks in Forensics and Incident Response Summits. For this summit, SANS is teaming with Richard Bejtlich to create a practioner-focused event dedicated to incident detection operations. The SANS Incident Detection Summit will share tools, tactics, and techniques practiced by more than 40 of the world’s greatest incident detectors in two full days of content consisting of keynotes, expert briefings, and dynamic panels.

Wade Baker (Risk Intel) is on the Commercial security intelligence service providers panel and Andrew Valentine (IR) is on the detection using logs panel. Should be an interesting event.

We hope to see you there.

ICSA Labs Product Assurance Report

Monday, November 16th, 2009

Today ICSA Labs (an independent division of Verizon Business) released a report based on testing results and observations taken during its 20-year history certifying security products. We mention it here because several members of this team worked with ICSA Labs to design the study, collect and analyze data (a non-trivial feat given the time span), and write the report. Although bookended by other information and recommendations, the bulk of the report hits on three main topics: how often product deficiencies occur during testing, which types occur most often, and what factors contribute to their occurrence. We hope readers will find the report helpful in their mission to protect information and useful to the decisions and deployments made in support of that mission.

You can get it here: www.icsalabs.com/whitepaper/report

Weekly Intelligence Summary: 2009 – 11 – 13

Saturday, November 14th, 2009

The most significant impact on risk over the last week was November’s Microsoft Tuesday security bulletins, and most developments this week had a positive impact on risk. Kerfuffles over another SMB issue is of little consequence as was the news of SCADA hacking in Brazil. The US Congress has taken up data privacy and breach legislation, but it remains to be seen whether it will increase risk by costing business more to comply, or decrease it by better protecting data. Signing the DNS root zone will have a positive impact on risk, but use of non-Latin alphabet in domains will probably be looked back upon as negative.

Weekly Intelligence Summary: 2009 – 11 – 06

Monday, November 9th, 2009

The most risk significant development this week was Microsoft’s Advance Notification for release of six security bulletins on 2009-11-10. Sun released an update to Java addressing seventeen vulnerabilities, but none are presently the target of attack. Historically, Java vulnerabilities are ignored by criminals or attacked months after patching. Social networks continue to be a primary target of criminal activity. Gumblar, the FTP-stealing trojan is now targeting Wordpress blogs. Bredolab, Virut and Zeus activity continues with malicious code disguised as shipping confirmations and money transfers. However, sending pharmaceutical spam has been occupying most criminal cycles.

Weekly Intelligence Summary: 2009 – 10 – 30

Monday, November 2nd, 2009

Most of the threat activity for this week was directed towards Facebook and Twitter users. Large e-mail campaigns for password reset confirmations led to compromised Facebook accounts and Trojan installations, with the primary goal of stealing bank account information. Sun issued advance notification to patch at least six vulnerabilities in Java on Tuesday, 2009-11-03. There is also an unspecified buffer overflow vulnerability in the current version of Java System Web Server. The Guardian Newspaper reported a “sophisticated” intrusion on their jobs site, and Gawker Media became the victim of a malvertisement similar to September’s attack on the New York Times.

On Asset Valuation.

Thursday, October 29th, 2009

Last week on Twitter, Jeremiah Grossman, Whitehat Security, asked if there was a simple way to perform asset valuation. Since then there have been posts from Russell Cameron Thomas, Andrew Jaquith, and Gunnar Peterson on the subject that have all been very interesting. The answers provided ranged from the simple to the complex.

Before we talk about asset value and Infosec, let’s first discuss some accounting concepts (I always like to get the unpleasantness out of the way as soon as possible).

To begin with, our IT assets usually are utilized in what we might think of as an object-oriented manner. That is, we can model them (from a risk standpoint) as parts of a greater process that generates revenue. Some can be seen as more directly contributing to revenue than others possibly, but they all operate as a whole. Think of an e-commerce order for example, and how many IT assets might be involved in taking that order. Now if we could value that whole process as an asset itself we might be able to break down contributions into sub categories and discuss value that way, but unfortunately, processes aren’t usually classified as *assets* in common accounting statements.
(more…)

Weekly Intelligence Summary: 2009 – 10-23

Friday, October 23rd, 2009

The following is the executive summary paragraph to the weekly Intelligence Summary report Verizon Business Cybertrust Security’s Risk Team provides. The purpose is to capture in one paragraph the most risk-significant events, over the past week, from an enterprise perspective.

The most risk-significant event this week was Oracle’s quarterly release of a Critical Patch Update, but none of the vulnerabilities are the target of known attacks. Data breaches dominate the rest of the week’s events with news of medical records off-shored for transcription being sold on India’s information black-market. A NASA scientist was arrested for trying to sell classified information. A former Ford employee was arrested for copying 4,000 proprietary files to an external drive prior to leaving Ford to work for BIAC, the fifth largest automaker in the People’s Republic of China. Point of sale devices were suborned at McDonalds locations in Australia. A security team in Europe reported 1,045 incidents of a compromised ATM “trapping” cards for later criminal use and a payment processor in Belgium reported a breach and at least 1,000 victims with financial losses.

Weekly Intelligence Summary: 2009 – 10-16

Friday, October 16th, 2009

The following is the executive summary paragraph to the weekly Intelligence Summary report Verizon Business Cybertrust Security’s Risk Team provides. The purpose is to capture in one paragraph the most risk-significant events, over the past week, from an enterprise perspective.

Risk relevant events this week were dominated by security bulletins from Microsoft and Adobe. Infrastructure component vulnerabilities have also been announced, but without widespread reporting and discussion among security professionals. Availability failures disrupted service for T-Mobile Sidekick users, all of Sweden, OS X Snow Leopard users and customers of Google’s Postini mail service. While there was a surge in reports of several different Trojan horses, the malicious code risk environment has become more risky at roughly the same pace we’ve been experiencing over the last several months.

Security decision methods poll Results

Monday, October 12th, 2009

A couple of weeks ago, I wrote a post on how we in the security industry make decisions. After a bit of waxing philosophical, I proposed a list of decision “methods” I regularly see in use among organizations. I also created a small survey (that contained a few additional methods) to capture your experiences for comparison. The response was not overwhelming by any stretch but the results are below (click the image to make it bigger).

Decisions survey results_small

(more…)

Weekly Intelligence Summary: 2009-10-09

Friday, October 9th, 2009

The following is the executive summary paragraph to the weekly Intelligence Summary report Verizon Business Cybertrust Security’s Risk Team provides. The purpose is to capture in one paragraph the most risk-significant events, over the past week, from an enterprise perspective.

Microsoft made their pre-release announcement for October Black Tuesday and 13 bulletins, eight “critical” using their criteria. Patches for the SMB2 and IIS/FTP vulnerabilities are among those expected. Adobe’s advance notice for their quarterly security update to Adobe Acrobat and Reader includes a vulnerability they know is being used in limited, targeted attacks, other vulnerabilities will be patched too. The mass compromise of web mail passwords dominated this week’s news; we agree with ScanSafe’s assessment they were probably the result of malcode infections and not phishing. The scale of this infection/breach is more significant to enterprise security than the web e-mail accounts that were compromised. Reports the FBI director’s spouse refuses to allow on-line banking is a serious indictment of on-line trust and we will be tracking related reports of trust erosion, especially by high-profile individuals, groups and companies.

RSS URL Change

Friday, October 2nd, 2009

Hi, an administrative note to let you know that the URL for our RSS feed is changing to:

http://feeds.feedburner.com/verizonbusiness/tWvQ

If you encounter any difficulties, please let us know in the comments to this post.

Thank You!

Security Decisions – How do you make them?

Monday, September 28th, 2009
As a student of both the fields of Information Technology/Security and Management Science (http://en.wikipedia.org/wiki/Management_science), I often find myself looking at security issues through a “decision-oriented” lens. For the most part, these two disciplines make good bedfellows – especially when one considers that engineers dominate the Information Security field. Please don’t misinterpret this; I have a healthy respect for and advocate our need of engineers (I’ve even helped teach and graduate some of them). However, not all of our problems are engineering problems and I do believe that our ability to truly manage information risk is hindered by a shortage of input from other disciplines (though I’ve seen at least some improvement in recent years).
One area where the engineering and management mindset clash is in decision-making. The engineer asks “What do I need to know to precisely formulate all factors in this decision?” while the management scientist asks “What do I need to know to make a good decision?”. In such matters, I side heavily with the management scientist.
The obvious application of this is in evaluating potential security initiatives or projects (“Should we do X, Y, or Z?”). In most cases, it is impossible to precisely formulate all factors in the decision, so we abandon the “scientific” route and revert to some other method of making it (see below). This is where our predominantly engineering mindset hurts us. Instead, we should realize that organizations have always made decisions using varying amounts of information of varying quality. Our dilemma is not new. Valid and vetted approaches exist for structured decision problems with an abundance of precise data and also for unstructured problems with sparse amounts of “fuzzy” data. They are out there and eagerly waiting for us to apply them to problems in our domain.
Ok, I’m off the soapbox. The main goal of this post is to ask how your company makes “Should we do X, Y, or Z?” decisions. I’ll start the conversation by listing the methods I see used most often. In doing so, I make no judgment on any method’s ability to support good decisions (though it’s clear some have more value than others).
The “Adamant Auditor” method: You’ve been here. The 22 year old kid shows up 3 months out of the university with his checklist etched in stone. He darn well better be able to check off all those boxes or you’re toast. “But if X does Z and Y does Z, then X=Y… and we’ve done Y” you argue only to receive blank stares. Good luck with that. Unless you can build a credible risk-based argument, you might as well just do X like he says.
The “Peer Pressure” method: This is the grown-up equivalent to doing what the cool kids do “Peers X and Y are doing Z, so we should too” is the justification here. It might be that X and Y have their act together and are great role models. Then again, they might think that alcohol, blindfolds, and a game of high-speed Chicken make for a great Friday night. Remember what your Mama said – “If so and so jumped off a cliff, would you?”
The “WIBeHI” method: If you’ve ever used anything that sounds remotely like “Wouldn’t It Be Horrible If X happened, therefore we should do Y” to justify a security initiative, then you’ve used this method. The potential worst-case scenario (and often some extra FUD for good measure) is the main decision criterion in this approach.
The “Guru Guidance” method: Every organization has its guru and every guru has his opinion. Just ask him. It might be that nobody understands the technical justification behind what they’re recommending, but he knows his stuff, right? Right?
The “Poll the Panel” method: Often called the “Delphi Method” but I’ve never thought the name very fitting. No journey to a mystical oracle with secret knowledge is required; you simply gather your smart folks and get them to come to a decision. The assumption is that decisions made by many are better than decisions made by one.
The “Pet Project” method: Perhaps it was the advertisement in that magazine on the plane. Maybe that analyst report. Who knows why your boss wants that project so badly, but its clear she does. And in this job market, who’s going to argue? If you can get it done while also squeezing in something with actual benefit, there’s a chance you can still put a mark in the Win column.
My tone here is obviously facetious but I am quite serious that I believe these methods (or some form of them) account for the majority of security decisions made in most organizations. Is this your experience as well? We’ve put up a quick, one-question poll on the topic here and would love to hear from you (we’ll share the results later). If any of these methods resonate or if you have some to add, please chime in.

As a student of both the fields of Information Technology/Security and Management Science, I often find myself looking at security issues through a “decision-oriented” lens. For the most part, these two disciplines make good bedfellows – especially when one considers that engineers dominate the Information Security field. Please don’t misinterpret this; I have a healthy respect for, and advocate our need of, engineers (I’ve even helped teach and graduate some of them). However, not all of our problems are engineering problems and I do believe that our ability to truly manage information risk is hindered by a shortage of input from other disciplines (though I’ve seen at least some improvement in recent years).

One area where the engineering and management mindset clash is in decision-making. The engineer asks, “What do I need to know to precisely formulate all factors in this decision?” Meanwhile, the management scientist asks “What do I need to know to make a good decision?” In such matters, I side heavily with the management scientist. (more…)

Re-imagining Information Security Standards

Tuesday, September 22nd, 2009

Hollywood calls it “Re-imagining”.  The creative types call it “rebooting”.  We might settle for “re-thinking”. But since it seems to be all the rage these days to take a second look at a subject, I thought I’d apply the concept to one of our favorite topics, Information Security Standards.

RE-IMAGINING INFORMATION SECURITY STANDARDS
Hollywood calls it “Re-imagining”.  The creative types call it “rebooting”.  We might settle for “re-thinking”.  But since it seems to be all the rage these days to take a second look at a subject, I thought I’d apply the concept to one of our favorite topics, Information Security Standards.
I admit that this is an incomplete thought, but I’d like to share it with you for two reasons:
1.)  At the end of a podcast I was part of recently, one of the other panelists challenged our industry to stop whining about our current state of affairs and do something better.
2.)  To request your feedback on the idea.
So here’s my thought: if we’re going to re-imagine InfoSec standards, as if we could do it all over again, I think there are three basic requirements any standard needs in order to be useful at all:
1.) A standard must provide for its own obsolescence/evolution  (falsification and a transparent falsification process must be built in)
2.) A standard must provide means of measurement (both for the outcome of the standard, and to measure the quality of standard adherence)
3.) A standard must reference, and be able to be referenced in, vernacular and in measurement (the language of the standard has to make sense to other standards)
RE-IMAGINING INFOSEC STANDARDS: THEIR NATURE
Digging right in, if we want to re-imagine standards we might start by reviewing the fundamental nature of what a standard is.  In a very real sense, our standards are models.  As such, any standard is only a hypothesis about how to keep our information confidential and available while maintaining its integrity.  But if we’re going to (finally) acknowledge that InfoSec standards are models/hypotheses, then we need to embrace a fundamental premise behind scientific theory: a model or hypothesis is meant to be tested, falsified, and evolved.  As such, our new view of InfoSec standards would require that we keep whoever developed the standard (or its current custodian), accountable for that scientific method.
Science Requires Falsification and Innovation
Now ideally, we’d have two things built into the concept of accountability.  These two ideas would mean that the standard would provide for its own obsolescence or evolution, and are the premise behind my first usefulness requirement, “a standard must provide for it’s own obsolescence/evolution  (falsification and a transparent falsification process must be built-in).”
1.)  The InfoSec standard itself should have a falsification process built into them.  The standard might describe the pursuit of falsification, what falsification/failures for the standard might look like, and provide us with the means to report a probable failure.
2.)  The standard custodian should provide transparency and reporting about that falsification process. Practitioners would have up to date knowledge about failures so that they can keep an eye out for them in their own environment, and hopefully be able to offer a modification to or alteration of the standard based on new information.  So whether this is just “patching” the standard or if it leads to a whole new hypothesis, we (the InfoSec community) would at least have visibility into a need to “re-secure”.
RE-IMAGINING INFOSEC STANDARDS:  THEIR PURPOSES
Related to our examination of fundamental nature, let’s think about what InfoSec standards are a model *of*.  We said that they are models we build to help us with our quest for maintaining the C, I, and A of our business data.  In that regard, we might suggest that they are about Information Security “engineering” and management.  In other words, design and implement practices to ensure C, I, and A and then establish practices to maintain the desired level of C, I, and A.  But if you’re building a control framework or understanding how you should best operate it, both disciplines require the use of measurements. This then necessitates the development, use, and reporting of metrics (indeed, the concept of measurement would be very useful in the scientific method process above).
The Purpose of Standards Requires Measurement
So while we’re re-imagining InfoSec standards, let’s imagine this: standards that tell us not only how to measure the standard’s outcome (secure enough) in a state of nature assessment, but also how to measure the actions that cause “secure enough” – what we might call the quality of standard adherence.  This gives us my second standards usefulness requirement,  “a standard must provide means of measurement (both for the outcome of the standard, and to measure the quality of standard adherence)”.
This way (and only in this way) we might know that by having expended X amount of effort for compliance to the InfoSec Standard, it produced Y amount of outcome.  Then people who implement the standard can discuss how they got Y+n amount of outcome for X-z amount of effort thanks to some new control, or how they are consistently seeing Y amount of outcome from year to year regardless of whether they spent X-1 or X+1 amount of effort, and so on.  But we are at the point, as an industry, where measurement is not just desirable – these days it’s actually necessary.
RE-IMAGINING INFOSEC STANDARS: PLAYING NICELY TOGETHER
Finally, since we’re trying to describe a new way of looking at security standards, maybe we could discuss the creation of a means by which models might be able to contribute information to each other.
You see, my belief is that Information Security, as we’re able to describe it right now, is too complex for one over-arching textbook sized model.  Rather, I believe that we’ll be more effective if we break the big problem up into smaller, more digestible chunks.  So practitioners of the various operational security duties can actually focus on their area of expertise, and not try to be masters of multiple domains (specialization is good, they say).
Standards Must Communicate To Have Aggregate Value
However, if we took the time with a whiteboard to try to paint a picture of all the components of organizational security (talking about the various areas of security specialization in sort of an object oriented sense, if you will), I’m betting we’d see that each area of security needs to be able to share information with others in a meaningful manner.  So Software Development processes need to exchange information with Vulnerability Management, who needs to talk to Intrusion Detection/Prevention, who needs to talk to Incident Response, and so on.  Now if we can establish rationalized metrics for the models (above), then ideally we’d be using a common security taxonomy, or at least using translation documents provided by the standard that would allow us to use one disciplines metrics (prior or posterior) if relevant to another discipline.  This gives us my final standard requirement, “a standard must reference, and be able to be referenced in, vernacular and in measurement (the language of the standard has to make sense to other standards)”.
Carrying that idea forward, it would probably be a great thing to have multiple competing models in any specific field, and wouldn’t it be wonderful if the language and meaning that they used were the same or easily translated (other than measurement models, obviously)?  So we would have an idea of comparative (in)effectiveness between competing models!
MOVING TOWARD A RE-IMAGINING
Yeah, so I’ve described a dream world of candy cane trees, rainbows, and happy unicorns.  Sure.  And I know it might take a generation or two of security professionals to get there.  But that doesn’t mean we can’t start now, and start with our current standards bodies – especially within the context of the pursuit and transparency of falsification and the development of meaningful metrics.  All it takes is the will to try and the willingness to fail.  As my co-presenter David Mortman and I said at Black Hat this year, “Models don’t have to be perfect, just ego-less”.Hollywood calls it “Re-imagining”.  The creative types call it “rebooting”.  We might settle for “re-thinking”. But since it seems to be all the rage these days to take a second look at a subject, I thought I’d apply the concept to one of our favorite topics, Information Security Standards.

I admit that this is an incomplete thought, but I’d like to share it with you for two reasons:

1.)  At the end of a podcast I was part of recently, one of the other panelists challenged our industry to stop whining about our current state of affairs and do something better.

2.)  To request your feedback on the idea.

So here’s my thought: if we’re going to re-imagine InfoSec standards, as if we could do it all over again, I think there are three basic requirements any standard needs in order to be useful at all:

1.) A standard must provide for its own obsolescence/evolution (falsification and a transparent falsification process must be built in)

2.) A standard must provide means of measurement (both for the outcome of the standard, and to measure the quality of standard adherence)

3.) A standard must reference, and be able to be referenced in, vernacular and in measurement (the language of the standard has to make sense to other standards)

(more…)

Security concerns in a “D-I-Y” Economy

Monday, September 21st, 2009

 

A few months ago C|Net published an article claiming current economic conditions have resulted in greater enterprise use of free and open source technologies.  This sparked an internal discussion about whether the supposed tendency would have an impact on risk to the enterprise.   As such discussions are wont to do, it descended into the quagmire of “how secure is open source”, and eventually died a quiet death after the RISK team grew weary with the topic. I had already half-heartedly begun a blog article framing the debate, but quickly filed it away under ‘do not resuscitate’.
However, three subsequent events brought additional insight to the matter, namely:  an XKCD cartoon, the build-out of a lab test bed, and a team-member’s ailing water heater. These unrelated events convinced me to go ahead and blow the dust off the blog entry and get it posted.
Suppose your enterprise is one of those which are attempting to “do more with less” (as we all are), and further suppose that the task of building, testing, and deploying “something new” falls to the technology group that has expertise in doing “other things.”   It isn’t too much of a leap from here to see where the technology choice for “something new” might be guided by price.  After all, if the CFO’s daughter’s grade school can download a “something new” and make it work then surely the enterprise technology group can do at least as well.  Does this sound familiar?
Returning to our theoretical DIY technology team, we find them diligently at work deploying and debugging the aforementioned “something new.” As is often the case, something goes awry when following the published documentation. As you are undoubtedly aware, when technologists find themselves in unfamiliar territory they tend to rely on the “wisdom of the collective” to solve problems.  This phenomenon is well expressed in the Tech Support Cheat Sheet published in a recent XKCD ( http://xkcd.com/627/ ).   The prevailing thought goes along the line of this, “surely someone else has had the same problem, and was diligent enough to document the experience for the good of the order.”   Therefore, after plugging the salient details into their favorite search engine, the erstwhile tech team awaits the wisdom of the oracle.
What follows are excerpts from  “free advice” to searches related to diverse “something new” deployments on a lab test bed over the past several weeks:
-                       chmod 777 fixes  this
-                       grant all on database.* to  …
-                       allow tcp any  any
-                       community  public
-                       allow tcp  23
-                       do not change the default  password
-                       allow from  any
-                       security  manager=”no”
-                       disable rules which generate  excessive log entries
-                       allow root login:  yes
-                       everyone  fullcontrol
-                       chown -R www-user  *
-                       allow-update { any;  };
In almost every case the first several rounds of online advice included advice to RTxM in various states of  dudgeon, and if reading the fine manual didn’t suffice there was always some  well meaning individual with an expedient (though potentially dangerous) solution: “I did X and it works!”
And what about the water heater? One of the Risk Team members’ water heater died a few weeks ago, and as he had never experienced a water heater replacement in any home, he asked for any advice his colleagues might have to offer.  After much discussion about what sorts of plumbing problems qualify as “DIY” , Bill Murray of the RISK team gave the following advice: “Do it  yourself. You will learn a lot that you will never use again.  You will also learn that even when the pros are not cheaper, they are still worth the difference.  You will use that over and over.”
So, in wrapping this together I would say that one of the significant risks posed to the enterprise by “economically driven DIY” could result from situations where “community advice” might make its way into production without appropriate review and control.  Clearly this is not the problem when the enterprise has “the pro” plumbers on staff or on call.

A few months ago C|Net published an article claiming current economic conditions have resulted in greater enterprise use of free and open source technologies.  This sparked an internal discussion about whether the supposed tendency would have an impact on risk to the enterprise.   As such discussions are wont to do, it descended into the quagmire of “how secure is open source”, and eventually died a quiet death after the RISK team grew weary with the topic. I had already half-heartedly begun a blog article framing the debate, but quickly filed it away under ‘do not resuscitate’.

However, three subsequent events brought additional insight to the matter, namely:  an XKCD cartoon, the build-out of a lab test bed, and a team-member’s ailing water heater. These unrelated events convinced me to go ahead and blow the dust off the blog entry and get it posted.

(more…)

Preparation for Internet Attacks

Tuesday, August 25th, 2009

by William Murray

Headlines this week have reported on denial of service attacks against  Twitter, Facebook and several other social networking sites.  These follow attacks in July against various government sites in the US and South Korea.  The headlines have elicited all kinds of commentary, most of it stopping just short of concluding that the sky is falling.  In all of this coverage, I have seen almost nothing about what this means to the average enterprise or what one ought to do about it.
Denial of service attacks work by exhausting finite resources.  (They are different from an attack that compromises a system and then breaks it or shuts it down. ) Historically we thought of them as exhausting system resources.  For example, “Syn  flood” attacks against servers work by exhausting memory until the server dies.   However, modern distributed denial of service (“DDoS”) attacks (“distributed” modifies “attack,” not “denial of service”) work by exhausting network band-width, usually the “last mile” to the victim.
To maximize the availability of resources in general, and information assets in particular, it helps to have some appreciation of the threat.  Most of the threats to availability are natural, not man-made.  They include everything from massive events like Hurricane Katrina to component failures.  Historically, most of the man-made threat has been accidental, errors and omissions.  This was in part because even the most malicious lacked the resources or motivation for more than the most local attacks.
The modern open network has changed that.  Not only may an individual control vast stolen resources (”bot-nets”) but he can direct them against a target of choice.  At first, the use of this power was by children and other amateurs and targets were somewhat random.  Increasingly the power is used by professionals and victims are chosen to make money (e.g., by extortion or short selling of securities).  The attack against Estonia, among the tiniest of nation states, has created fear that nation states might attempt to use the links between them to attack one another for political or military purposes.
Our fundamental strategies for ensuring availability include adequate capacity and reserves, easily deployed, avoiding single points of failure, planned response to events, and insurance.  The planned responses include relations with key suppliers.  Here is where the potential for denial of service attacks suggests a new tactic, pre-arrangement with one’s upstream network service providers.
Steve Gibson reports that in the first well-publicized attack against grc.com, it took him 12 hours to find the right individual at his internet service provider and ten minutes for that person to fix it.  Since one will rarely have so much capacity that an attacker cannot exhaust it, assistance from one’s upstream provider is always helpful and may be essential.
Internet service providers offer multiple alternatives for mitigating denial of service attacks, from simple filtering, alternative addresses, alternative paths, to capacity for absorbing the attack.  Many spell out these services in their offerings.  Some of these services are separately priced.  (For the few enterprises that are targets of choice for denial of service attacks, there are specialized services that offer massive capacity for absorbing attacks.)
Media coverage to the contrary notwithstanding, and at least for the time being, for the average enterprise, network-based denial of service attacks will be rare and short lived.  They may be slightly more likely than regional disasters but less damaging. They should be addressed in the context of other threats to availability.
That leaves the issues of a national denial of service attack,  like Estonia, a global denial of service attack, like SQL/Slammer, or “Cyber Terrorism.”   The so-called attack against Estonia was really a number of loosely coordinated attacks against a very small nation state that was unusually dependent on the Internet.  While somewhat effective, even it consumed only a small portion of the total capacity of  even that small country.  The recent coordinated attacks against the US and S. Korea were even less effective.
SQL/Slammer was a global denial of service attack which attempted to exploit a wide-spread vulnerability to organize Internet nodes against the Internet itself.  It produced a noticeable, localized, and short-lived decrease in the useable capacity of the Internet.  Because it was easily recognized, it was possible to put filters in place to shut it down within hours.  However, one can easily visualize a more heterogeneous attack that would have been more difficult to stifle.  One cannot afford to dismiss the possibility of such an attack. However, as time passes, the potential for it to be effective diminishes.   The wide-spread use of restrictive policies, e.g.,  default deny, personal firewalls, resists the marshalling of the Internet’s nodes against itself, the capacity to be exhausted increases, and the preparation and strategies of the operators improve.
Terrorism can be defined as an attempt to achieve political ends by frightening the populous.  While the death and destruction is beyond question, its effectiveness in achieving its ends has always been questionable.  In modern terrorism, the means have become so separated from the ends that the terror has become and end in itself.  The speculation about “Cyber Terrorism” is based upon the idea that the  Internet might be such an attractive means to a terrorist as to make its use for  an attack all but inevitable.  To the extent that it permits a small number of people to exercise control or project power at a distance, the Internet is an attractive attack vector.  It is certainly attractive as a means of demonstrating the vulnerability of a highly technologic society.  However, as a means of creating terror, it is far less attractive than random death and destruction.
“Think globally, act locally.”  For most of us, the proper response to any potential for “Cyber Terrorism” is  to  protect our own  resources so that they cannot be used against our neighbors.

Recent headlines have reported on denial of service attacks against Twitter, Facebook and several other social networking sites.  These follow attacks in July against various government sites in the US and South Korea.  The headlines have elicited all kinds of commentary, most of it stopping just short of concluding that the sky is falling.  In all of this coverage, I have seen almost nothing about what this means to the average enterprise or what one ought to do about it.

Denial of service attacks work by exhausting finite resources.  (They are different from an attack that compromises a system and then breaks it or shuts it down.) Historically we thought of them as exhausting system resources.  For example, “Syn  flood” attacks against servers work by exhausting memory until the server dies.   However, modern distributed denial of service (“DDoS”) attacks (“distributed” modifies “attack,” not “denial of service”) work by exhausting network bandwidth, usually the “last mile” to the victim.

(more…)