Moodle Threat Modeling

In Chapter 1, we learned that security threats are in no way new and that security needs to be factored into any Moodle project right from the start. So, knowing that designing for security is vital to any Moodle deployment, how do we actually identify those threats? In this chapter, we introduce the concept of threat modeling, a set of tools and techniques we can use to identify threats, which was originally outlined by Adam Shostack in his book, Threat Modeling: Designing for Security. As we introduce this chapter, we remember the words of US economist Thomas Schelling:

“A person cannot… draw up a list of things that would never occur to him.”

Often, in conversations where security incidents are discussed, I hear sentences beginning with “I’m surprised they didn’t consider...” But should we be surprised? Again, just because a threat immediately occurs to you doesn’t mean to say it crossed the minds...

Technical requirements

In this chapter, we will use the Microsoft Threat Modeling tool to create threat models for our Moodle infrastructure. This is a software application designed to run on Windows only. If you are a Linux or macOS user currently without access to a Windows environment, consider installing a Windows Virtual Machine so that you can follow the examples in this chapter. Microsoft provides evaluation versions of Windows for various virtualization platforms at https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/.

Cybersecurity terminology

The language of cybersecurity has its origins in the military. So, for example, if you have installed lots of plugins that you don’t use, then the effect is to increase your installation’s attack surface. To understand this concept, let’s consider the famous drawing of the arrangement of opposing naval fleets immediately before the Battle of Trafalgar, as shown here:

Figure 2.1 – Reducing the British fleet’s attack surface by arranging ships in single file

It is very clear from Figure 2.1 that Admiral Nelson arranged the British naval fleet to ensure as small an attack surface as possible. Imagine being on a ship of either the French or Spanish fleet. Your view of the British columns would be limited to the ships leading the columns.

Without spies or detailed reconnaissance, the French and Spanish would have no appreciation of the threat coming up at the rear of the British columns. Compare...

What are we working on?

How you start identifying threats, at least initially, will depend on whether you work alone or in a team. If you have the luxury of colleagues, then I would strongly suggest you work with them as a security team. But, that said, don’t worry if you work alone, as the tools and techniques we describe in this chapter can be used in either context.

Although it’s a situation where we tend to think of bad actors trying to break out rather than break in, let’s take the real-world example of a prison service. Prisons organize security teams – the team in my local prison is known as Team McQueen – named after Steve McQueen and his starring role in the film The Great Escape. Their job is to plan how to break out of the prison and their planning includes using their understanding of the prison’s architecture, protocols, individual responsibilities, and procedures. In a similar vein, you and/or your security team will be tasked...

Identifying threats with STRIDE

The acronym STRIDE was developed by Loren Kohnfelder and Praerit Garg to help with the identification of threats by categorizing them. Each letter identifies a different category of threat:

• Spoofing: Pretending to be something or someone you’re not
• Tampering: Modifying something you shouldn’t, either for sport or for your own advantage
• Repudiation: Avoiding responsibility for something you did or claiming responsibility for something you didn’t
• Information Disclosure: Revealing data to someone who isn’t authorized to see it
• Denial of Service: Absorbing all the resources of a service so that it can no longer function
• Elevation of Privilege: Someone doing something they aren’t meant to do

It’s worth remembering that STRIDE reminds us to consider these six threat categories – it doesn’t tell us to restrict ourselves to just these six. Using a framework such as STRIDE...

What are we going to do about it?

The STRIDE analysis we just carried out has provided us with a list of threats we need to address. Remember that there will undoubtedly be others that haven’t occurred to us, so never consider your list complete. Also, remember that a threat isn’t the same as a risk – and that the probability of a threat being exploited is not the same as the expectation that it will occur.

Fundamentally, there are four ways of dealing with a threat. We can do the following:

• Transfer
• Eliminate
• Accept
• Mitigate

Let’s now understand the implications of each approach for our Mathaholics project, starting with transferring threats.

Transferring threat risks

If we choose to outsource our Moodle hosting to a third party – a Moodle partner, for instance – then we are, essentially, hoping to transfer the threat risk to them. However, as described in Chapter 1, although third parties might be happy...

Did we do a good job?

To judge how effective our DFDs and threat models are, we can ask the following questions:

• Is there any aspect of the Mathaholics platform we haven’t modeled? If anything is missing, then there will certainly be threats we have not captured.
• Do our models and data flows reflect reality? It’s all too common for one team to plan, another to execute, and attack vectors to be introduced as the intentions of one team diverge from the other.
• Does everyone agree with what’s captured in the diagrams and models? Any dissension from the team is a sure sign that a threat has been missed.

Treat diagramming and modeling as an iterative process. We must continue refining them as the Mathaholics platform is being developed. You may well find that there are aspects of the model that don’t correctly reflect the final project. For example, your organization may have decided that managing its own database software was too onerous...

Summary

Identifying security threats is critical but, given the complexity of modern high-availability, cloud-based platforms such as Moodle, it isn’t always obvious where the security vulnerabilities will be found. In this chapter, once we learned about the terminology, we saw how DFDs can be used to identify where data might be vulnerable to attack.

We saw that DFDs can become very complex very quickly, and how having a software tool to help us build the model and track the changes becomes useful. To address this challenge, we have the Microsoft Threat Modeling Tool, which we also started using in this chapter.

The STRIDE security threat categories have been introduced in this chapter. We used these to consider aspects of the Mathaholics platform that are at risk of attack, and you will be able to apply these to your own Moodle project.

Finally, we considered ways to ensure that we are validating our own work. The key thing to stress is that ensuring the security...