DTRAP Blog

In this post I talked about the motivations for DDOS. Political acts, extortion, revenge… all typical motivations.

That doesn’t really account for the Mirai DDOS. The first one on September 19, 2016 was motivated by gaming. The attacker went after the company that hosted a tool used by Minecraft against DDOS. Then there was an even bigger one on October 12. According to the FBI, that one was also motivated by Minecraft.

Let’s take a step back and look at the Mirai botnet. First, it was IoT devices, the first known attack that originated from them. The botnet was created by taking advantage of default passwords and telnet and other vulnerabilities, but I’m going to concentrate on those two

I’m concentrating on those two factors because they are issues we have known about for years. There are 147 CVEs that mention default passwords. This goes back to 1999, but that’s only because CVEs were first recorded in 1999. telnet has had a secure replacement available since 2005, so we shouldn’t still be relying upon it.

And yet, still IoT devices use both insecure methods, allowing Mirai to cause havoc at least twice. We learned to use ssh and other secure access methods on computers attached to the Internet, but it appears we didn’t learn the same lesson with IoT.

This is a case where we really could have benefited from hindsight.

After the DDOS, we fixed everything that caused this and now everything is great, right?

Well, no, not so much. Mirai is still out there and has been updated to look for new vulnerabilities and it still uses default passwords and telnet. We still haven’t learned and it’s still possible for IoT devices to be easily added to a botnet.

Studying the causes of this problem as well as proposing potential solutions is a good topic for a Field Note for DTRAP. If this is in your field of expertise or you’d like to propose a solution, write one.

Once upon a time (I always wanted to start a blog post like that) the air gap considered a primary defense. If your computer wasn’t connected in any way to the Internet, then it was safe. Safe from viruses, safe from external attackers, it the gap between the computer and the Internet protected your computer,

In 2010, that all changed. Stuxnet was a malicious computer virus that installed itself via a USB drive. Even if your computer was not connected to the Internet, it was still vulnerable. In particular, it attacked SCADA systems, but the end result holds true. Any computer/computing device, whether or not it is actively connected to the Internet, is vulnerable.

What does this say to me? It says that we have to be careful of our assumptions. We assumed that because a computer wasn’t on the Internet, it wouldn’t get a virus. My first encounter with a virus was actually transmitted by floppy disk, so the idea of an air gap solving all was only after the Internet was prevalent.

We forgot what we learned from floppy disks and had to relearn it with USBs.

Going forward, what else can we learn from past events? George Satyana said “Those who cannot remember the past are condemned to repeat it.”. We need to learn from history, which is the point of the column “With the Benefit of Hindsight”. If there an historical event that resonates with you, then consider the event. What did we learn from it, what should we have done differently, and what can we do going forward.

Submit your article to https://dtrap.acm.org/

In thispost I talked about sampling bias.  I’m going to expand more on that subject, because I think it’s interesting and useful.

Cavemen is a popular trope.  We like to think that our ancestors spent all their time in caves, because that’s the evidence we’ve found.  The caves protect the artifacts, so of course they’re found there. That doesn’t mean that our ancestors spent all their time in caves at all.  It just means that’s where the evidence is.

We run into similar problems when studying malware.  We often use a sandbox to contain the malware, but that often means we only see what the malware authors want us to see.  We’re stuck in a cave, in other words.

The problem is that outside of the cave is the potential to affect other computers who aren’t interested in being part of the experiment.  We want to know how malware works outside of the cave, but as old maps used to say, “Here be dragons”. (Well, they didn’t say that, but it works for this analogy).  Outside of the cave, dragons. Inside of the cave, misinformation.

We want containment to avoid the dragons, but at the same time we must be aware that we are dealing with potential misinformation.  This makes generalizing on malware difficult, but in order to study it appropriately, we must try.

DTRAP promotes containment in studying all cybersecurity, not just malware.  We want to be responsible researchers and not release the dragons.

Every bit of research begins with an idea. I wonder if… Is it possible that… Could we maybe…

These are sentences I’ve started when doing my research. Things like, I wonder if this malware uses that vulnerability and what does it mean for the future. Is it possible that malware authors are collaborating? Could we learn about the economic model of DDOS providers and use that to subvert them?

On the other hand, practitioners often start with a problem. How can I stop… What will let me… What should I expect…

I’ve started the same sentences when I worked for a startup ISP. How can I stop the malicious traffic? What will let me find malicious actors on my network? What should I expect if I enact a new security policy?

We, as a field, need to communicate these questions between researchers and practitioners. The questions from a practitioner should spark ideas to a researcher, helping them focus their research on current problems. On the other hand, the questions a researcher poses should also be considered by a practitioner. Are their questions the solutions to your future problems?

The goal of the Field Notes article type designed by DTRAP is to spark that research and the questions. As a practitioner, is there something you wish the researchers could answer? Write a Field Note that outlines the question, why it’s important, and what you think of the future.

Field Notes are also open to researchers, we want to hear what you think is a future problem. Will practitioners feel the same way? We want to use them to bridge a conversation between both groups.

Submit your Field Note to https://dtrap.acm.org/ and help us have a little more conversation.

The amount of data in Cybersecurity research is sometimes overwhelming.  To get around this amount of data, we sample. That means we choose a subset of the overwhelming ocean of data and deal with a much smaller pond.

We must be careful when we do this sampling, it’s possible to introduce sampling bias.   This is when some parts of the data ocean are more likely to be picked than other parts. Continuing with the ocean analogy, it’s when you pick all your samples out of the Bermuda Triangle but ignore the entire Atlantic Ocean.  Your results aren’t generalizable to the entire Atlantic Ocean in that case, they’re only relevant to the Bermuda Triangle.

Which is exactly the problem with sampling bias.

Returning to the world of Cybersecurity, suppose you’re studying network traffic.  If you only study the traffic that your organization sees, then that’s not generalizable to the world at large, unless you have a very good reasoning behind it.  The statement ‘My Organization is just like the Internet’ is one that requires a lot of explanation. It’s possible that it’s true, from a certain point of view, but you must explain that point of view.

DTRAP wants your results to be generalizable, that is, to have external validity.  Avoid sampling bias in your research.

Moving research in the area of cybersecurity into practice often is difficult for many reasons.

I decided to look at another field which has similar issues, medicine, and read a few papers on the topic. These papers include:

• Glasgow, Russell E., et al. “The future of health behavior change research: what is needed to improve translation of research into health promotion practice?.” Annals of Behavioral Medicine 27.1 (2004): 3-12.
• Berwick, Donald M. “Disseminating innovations in health care.” Jama 289.15 (2003): 1969-1975.
• Glasgow, Russell E., and Karen M. Emmons. “How can we increase translation of research into practice? Types of evidence needed.” Annu. Rev. Public Health 28 (2007): 413-433.

These papers considered the barriers medical research faces before it can become clinical practice. Each paper considered various barriers, but I was interested in one result that all three had.

The complexity of the result from research was a key indicator of whether doctors would easily integrate the result into practice. The more complex the result, the harder it is for doctors to move the result from a research environment into a clinical practice. Since doctors and nurses are under pressure to provide more and more support to patients with fewer resources, the addition of a complex procedure is often resisted.

Can we consider the same thing in Cybersecurity?

Yes and no, it depends on how we define complexity, which is very tricky to define. Do you add complexity when you buy an entire new defensive system, or is that just a question of expenditures? Or if we define new procedures for users to avoid certain attacks, is that complexity? The details of what makes something complex will not transfer to cybersecurity from medicine.

We can, however, take lessons from medicine and apply them to cybersecurity. For example, the perceived benefit of a change has a lot to do with its adoption. That seems intuitively to apply to cybersecurity as well. If a change is complex, but promises to defend your organization from all phishing attacks, then the complex change may be worth the mental cost of understanding it. But we have very few such broad assurances in cybersecurity. Perhaps safest to search for simple, explainable improvements.

This is a topic that we need to study further so we can understand what difficulties are present and how we can do better. DTRAP wants to bridge the gap between researchers and practitioners and I believe this is an important part of that.