In a recent conversation with a colleague, it was noted that a company had recently had a Distributed Denial of Service (DDoS) attack against its website. Though various support persons had been called in in the middle of the night to address this issue, the after action report indicated that a security engineer had not been called for over an hour, and only after the source had been identified. Ironically, the notes identified the situation as a DDoS from the very first moments of the incident due to system reports. I queried of my colleague whether this was standard procedure or there was a mix up by not calling the security engineer? It stated it was standard procedure and it was asked of me why would I think it otherwise since the DDoS is a network event. I explained that DoS and DDoS events are not always network events, they are security incidents, and if the support teams knew it was a DDoS from the outset, then it would be common place to have a security engineer in the Incident Response Plan as a first responder. Security engineers would be able to use their skills and tool set to determine if the event were something larger or directed at another location and be able to assist with recovery. That statement revealed an interesting thought process that is worth exploring. Are DoS and DDoS events systems or network events and therefore systems administrators and network engineers should respond and not security? Let’s explore this a bit…
What is a DoS?
DoS stands for Denial of Service. Google defines a DoS as “an interruption in an authorized user’s access to a computer network, typically one (DoS) caused with malicious intent.” The U.S. Federal government, through the National Institutes of Science and Technology (NIST) defines a DoS as “The prevention of authorized access to resources or the delaying of time-critical operations.” (NISTIR 7298 Revision 2) Either definition is rather simple, a DoS denies authorized (and probably unauthorized as well) access to a resource or operation.
What is a DDoS?
DDoS stands for Distributed Denial of Service. It is essential the same concept as a DoS, yet it is a “…technique that uses numerous hosts (or sources) to perform the attack.” (NISTIR 7298 Revision 2).
What is the Difference between a DoS and DDoS then?
Based upon our new understanding of the definitions of each, the difference is simple. In a DoS scenario one source is attacking one target. In a DDoS scenario, multiple sources are attacking one target.
How Can One Detect a DoS/DDoS?
One thing Common Sense Security is not going to teach you is exactly how to attack a target or compromise a target. Instead, we will look at detection, or what to look for, so as to understand what you are being attacked by.
There are a number of methods that may identify a DoS or DDoS scenario is occurring. At the very heart of any DoS / DDoS scenario is that the service you are trying to use is not available to use. These services may be an Internet connection from your home (outbound), accessing a website, accessing an application or similar. However, just because it is not available does not mean you are being DoS’ed. It could simply be that the resource is failing or may have even been shut off.
One of the tell tale signs that characterizes a DoS scenario is that the resource is available but is slow or only intermittently responsive. There is something blocking your path to it. This is typical when an network or Internet based attack is occurring. In these cases the Internet or network connection is so congested you just can’t get through. Think of this like a traffic jam on the highway. You leave your home in central Illinois and want to go downtown Chicago to the Field Museum. You hop on I-55 and buzz along at 70mph (of course no one breaks the speed limit here 🙂 ). As you I-55 turns into the Stevenson Expressway (which is basically inside the beltway for you East Coasters) someone has thrown every car in Chicago onto the north bound lanes of I-55. If that occurs you are not getting to the field museum, or if you do it was a stroke of luck. That is like a network DoS.
The field museum is still open, people who are close can get to it and enjoy it, but you can’t. Sometimes the network DoS is so effective that the congestion extends right up to the server itself. Or to use our traffic jam scenario, right up to the front doors.
Another DoS option is to only attack the serving resource itself. In these cases the network is fine and allows traffic to reach the server, but the attacker has forced the server into a constant reboot or shut down the protocol or on board service that activates the webpages or application. It is even possible that the web pages or application is active but you cannot use a database or get to a very specific resource. Using our traffic analogy again, in this case I-55 is fine, you get to Chicago and you get to the Field Museum, but someone locked the doors.. Or maybe you can only get into the lobby and can’t get any further. Or, to take this on step deeper, maybe you can get all around the museum but can’t get to a specific exhibit (I would be frustrated if I couldn’t get to the U-509 submarine, myself).
We could go on with other possible scenarios and analogies, but I think you are at this point understanding that a DoS is simply denying you, an authorized user, access to a resource that you want to get to. Through the examples, we have shown that not every DoS is a network issue. What we have done is demonstrated actions that have led to the DoS scenario.
The Value of a Security Engineer:
Can any of the demonstrated scenarios be cleaned up by a Network Engineer or Systems Administrator? Yes, they most certainly can and your business, website or whatever is being denied can be back online probably rather quickly. If that is your sole goal, get back online and forget about it, then do so and keep on keeping on and forget security.
However, I would argue that in a DoS scenario you need to know (must know in some industries) why it happened, from where it came, what the true target or intent was and how to prevent it from happening again so that you and your business comply with laws and regulations and at the least, do not waste time repeating your cleansing efforts. If you are a small business and had to hire a consultant to clean up the DoS, I am sure you do not want to repeat the cost of $100 per hour consultants for umpteen hours every couple of days.
One can never understand, without further investigation, the motive(s), method(s) or other specifics behind such a scenario. This is where your Security Engineer is your resource (hopefully). Your experienced Security Engineer has (or should have) the skills, knowledge and tools to determine why the attack is or did happen, understand what is the target, understand how to prevent it in the future and assist in the clean up. If the attack rises to the level of involving law enforcement assets, a Security Engineer should also be versed in the collection and handling of evidence. These are all skills taught in basic Comptia Security + and ISC SSCP courses and testing.
Back to our original story, the business chose to get back online quickly and not involve security until it was potentially too late. The people on site at the time believed the DoS occured in part due to a failure of a networking device and that device being overloaded by a small DoS event. Further investigation, however, revealed that the DoS was targeted and was done so as a “hactivism” (a later post will explain this) statement against a particular scenario. By the time this was discovered though, logs were lost, corrective actions had been taken that resulted in evidence being inadmissible for a law enforcement scenario and for all intents and purposes the opportunity was lost in general.
So, should a security engineer be involved in every DoS scenario? In my opinion a resounding yes. It is often that a simple DoS investigation uncovers other motives or even other attacks taking place. All too often the DoS scenario exists as a result of a careless attacker making a mistake or an intentional attacker making a statement that exposes his deeds.
However (there is always that but), in a small business or in your personal life, one must take into account the business need for getting systems back online or simply moving on to another like service and balance that with the security requirements or needs. If you are in a heavily regulated industry or a client of such (i.e. Banking or financial), then you better have Security in the lead of your incident response plan. If you are a small candy store in downtown small town U.S.A., then maybe the first time you recover and move on.