Moodle Security – First Steps

Consider for a moment why you secure your property. Access to your home is likely protected by a lockable door. Have you considered all the reasons why you have a lockable door? Perhaps your reason is an emotional one: you feel safe if your door is closed and locked. Perhaps you want to impress the outside world with a chunky door and a strong-looking lock. Perhaps you have a more practical reason: you want to prevent a bad actor with bad intentions from entering your property, such as to steal a piece of fine jewelry.

Have you attempted to mitigate the risk of theft by insuring your property? If so, the insurance underwriters may well specify the type of door and type of lock you should use to ensure coverage. This means that if you haven’t followed your insurer’s access protection requirements, they won’t cover your loss if these protections are breached.

But what if – and this happens all too frequently – you let the intruder into your home without realizing that they intend to steal? And if you take legal action against the intruder because you consider yourself wronged, then what if they claim that it wasn’t their intent to keep your jewelry? What if they claim they intended to return it? Can you prove their intention to do you wrong?

At the very highest level, securing a Moodle installation is very similar to securing your home. As you read this chapter, you will learn how to gauge an organization’s risk tolerance by appreciating the compliance and standards frameworks within which that organization operates.

We will also investigate the kinds of constraints that are placed on organizations by their insurers. To understand statutory requirements, we will be exploring data protection regulation from both a European and US standpoint as European Union (EU) and US regulations set international standards.

After having built this context, you will be introduced to a fictional tutoring company: Mathaholics. We will be putting ourselves in the role of the Mathaholics Moodle Security Advisor in this book.

In this chapter, we will cover the following topics:

• A short history of hacking
• Fundamental security requirements
• Understanding risk
• The regulatory environment
• Creating a risk register

I’m introducing this chapter with the assertion that security problems are not new. So, taking the advice of Sir Winston Churchill, who famously said “Study history, study history,” let’s begin this chapter with a brief discussion on hacking.

Technical requirements

There are no technical requirements for this chapter.

A short history of hacking

The World Wide Web is a telecommunications system, and hacking telecommunications systems is in no way a new phenomenon. Let’s briefly take a look at some examples.

The Watergate scandal – a man-in-the-middle attack

The Watergate scandal began in 1972 when operatives linked to President Nixon’s re-election campaign were caught wiretapping phones inside the Democratic National Committee’s offices in the Watergate building (hence the name the Watergate scandal and why any modern-day political scandal in the West gains the suffix gate). These operatives wanted to listen in to the conversations of their political opponents for political gain. Today, we describe this kind of hack as a man-in-the-middle attack.

Phreaking – VoIP fraud

Beginning in the late 1950s, phreakers (a name derived from phone and freak) began reverse engineering the tones that are used to make premium long-distance calls. Why? Partly for sport and partly so that users could commit toll fraud by making free long-distance (or toll) calls around the world. The whistles and tones needed to commit toll fraud were generated by devices called blue boxes, an example of which is shown here:

Figure 1.1 – A blue box, used for hacking telephone systems

Did you know that before founding Apple, Steve Wozniak and Steve Jobs built and sold blue boxes? This may go some way to explain – at least from a security standpoint – Apple’s far more rigorous control over its own devices: for example, not being able to modify or update the operating system. It’s also important to realize toll fraud is still a problem: today, we know it as VoIP fraud.

Cracking encryption – SSL attacks

As a final example, we are used to checking that a website we visit displays a padlock/lock icon in the browser address bar as this indicates that the communication between the browser and the server is encrypted:

Figure 1.2 – A padlock icon in the address bar shows a secure connection

Did you know that the world’s first programmable electronic computer was Colossus, which was successfully used to hack secure military communications in World War II?

Key takeaway

There is nothing new under the sun and hacking is no exception. Always assume that bad actors want to gain access to your Moodle – either for sport or for gain.

Now that we have reviewed the history of hacking and understood how far back it goes, let’s start understanding the importance of paying attention to security requirements to combat future hacks as early as possible.

Fundamental security requirements

This book is based on an opportunity to build a math-related learning portal – a national tutoring program to support online math teaching funded by the government. The Invitation To Tender (ITT) document outlines the following requirements:

Figure 1.3 – Example tender document

ITT documents can be written in a formal business language that can often seem impenetrable, so there are a few tricks we can use to get a sense of where the buyer’s focus lies. Besides simply searching the document for keywords and phrases, such as security or data protection, we can generate a word cloud:

Figure 1.4 – A word cloud can help make sense of a tender document

Here, we can see that the word security has a relatively strong presence. This ITT contains more than usual details on specific project security requirements. We have reproduced these in the following table:

Req ID	Description	Type
T.4.1	Compliance.	R
T.4.1.1	The tenderer’s security policy is reviewed annually by an independent party, and the outcome is shared with the customer.	R
T.4.1.2	The tenderer reports periodically about security and privacy assurance.	R
T.4.1.3	When signing into the application, a limited number of attempts are allowed before the account is blocked.	R
T.4.1.4	The application maintains an audit log of activities performed by administrators and all other users. Capturing user analytics activities for learning analytics must comply with European and US privacy laws.	R
T.4.1.5	The application supports the statutory right of access and allows for such a request to fall within a short period of days. The support may consist of an API, or facilitating a download containing all personal data.	R

Figure 1.5 – Sample project security requirements

As you have no doubt realized, security requirements change with the project and are a function of, among other things, the territory in which the inviter operates, its security posture, and its audience for the project. Ensure you note the type of security requirement. Typically, R indicates a mandatory requirement. There can be other non-mandatory requirements as well, which can be indicated by D, a weighted desire: for example, D2 would be relatively more important than D1.

The importance of showing you this example is less to explain tender documents and more to stress that security needs to be considered right from the very start. And this doesn’t mean you start to consider security when you’ve won the bid and you’re starting development but realistically when you’re thinking about bidding.

As an aside, continuity can be important here as often the team doing the bidding is different from the team doing the developing. The development team often hands over to an operations team for final deployment, which is a discontinuity a lot of security issues can arise from. Although more recent DevOps practices should blur the boundary between development and operations – hence the name DevOps – too often you’ll see the practice of handing over from one team to another ready for final deployment and ongoing support. These cracks in continuity are where security considerations can fall.

Key takeaway

Security must have a seat at the project table from the very beginning and continue to do so as the project progresses through to deployment.

With that, we have understood that it is never too early to start thinking about security. The more handovers we have in the development process, the more risk we let in through the cracks. But what is risk?

Understanding risk

How much risk are you willing to take on behalf of your business? Let’s start by trying to understand the Mathaholics project’s risk profile. There are three components to any risk profile (you may be familiar with the following if you work in the financial sector):

• Risk capacity: How much risk are we prepared to take on at the outset?
• Risk tolerance: How much risk are we prepared to take on over the long term?
• Risk requirements: Are there any risks we are required (for example, legally) to mitigate?

It is beyond the scope of this book to delve too deeply into each of these three aspects. Instead, we concentrate on the third aspect: risk requirements.

Recall from the introduction that protecting a Moodle installation is similar to protecting valuable jewelry. In the UK, just as there is no legal standard for door locks, there is no legal standard for protecting online applications. However, there are industry standards for door locks you are expected to adhere to – some managed by governmental/quasi-public sector bodies (for example, The British Standards Institute (BSI), which has a memorandum of understanding with the UK government) and some by the industry itself (for example, Association of British Insurers).

The same is true for application security standards. In the UK, there are standards outlined by the National Cyber Security Centre (a public sector body) as well as frameworks formulated by the Open Web Application Security Project (a not-for-profit). The security standards you will need to adhere to will depend on the type of data you need to protect. Generally speaking, application security problems can be categorized under the following headings:

• Networking
• Operating system
• Application
• Human

Tip

Before you begin, write these four headings on four sticky notes, and make some space on your office wall for these notes. As you read through this chapter, think about the risks your organization might face and add more sticky notes under each heading. Don’t forget to ask colleagues to add ideas too.

The regulatory environment

To understand our security risks, we need to understand the regulatory landscape in which the Mathaholics platform will operate. We are assuming the Mathaholics business will be managed in the UK and fall under the UK’s legal jurisdiction, but the general principles explored here will apply to any business or organizational environment. If significant variations occur within the US environment, the book will inform you of these. In this section, we will explore the following three requirements:

• Statutory requirements
• Insurance requirements
• Service License Agreement (SLA) requirements

Statutory requirements

Before reading this section, please be aware that what follows does not constitute legal advice. If you have any doubts about your legal position, then you must speak to a qualified specialist.

The Mathaholics website will be processing user data so, in the UK, our first step is to determine if we need to register with the Information Commissioner’s Office (ICO). Some organizations are exempt, so the ICO provides a handy online self-assessment tool to enable you to check – visit https://ico.org.uk/for-organisations/data-protection-fee/self-assessment/ for details.

We also need to determine if our organization will be a data controller or a data processor:

• Data controller: This decides what to do with a user’s data and how that data should be kept safe.
• Data processor: This processes data on behalf of the data controller. If we were to outsource emailing our students’ daily math problems to another organization, then they would comprise a data processor.

Note that your hosting company is not a data processor by default. We can take no comfort from outsourcing our Moodle hosting to a third-party supplier as our user’s data is still our responsibility. In the UK, if you need to register with the ICO, you will also need to nominate a data protection officer. At the time of writing, in the US, at the federal level, this is only mandatory if your organization is regulated by the Health Insurance Portability and Accountability Act (HIPAA). Do check any state-level requirements. As new data privacy and protection laws are being enacted across the globe, the requirement to nominate a data protection officer is increasingly being made mandatory. The International Association of Privacy Professionals (IAPP) has a guide available at https://iapp.org/resources/article/data-protection-officer-requirements-by-country/. Even if it’s not mandatory, if you have the capacity and resources to fill the data protection officer role, then it is considered good practice to do so. Luckily, Moodle provides baked-in functionality to support the data protection officer, which we will be investigating later in this book.

From a security perspective, of all the rights afforded to the individuals who will be using our Mathaholics platform, possibly the most important is the European Union’s GDPR. The GDPR applies to anyone living in the EU, which can also include non-EU citizens living in the EU. It provides the benchmark for similar legislation in the US, such as the California Consumer Privacy Act (CCPA). Given how rigorous the GDPR is, we will apply it as the benchmark for data protection in our platform. Luckily, Moodle has a full set of compliance tools that we will be exploring in later chapters.

At the time of writing, there is no single federal data protection authority in the US. At the federal level, enforcement is reactive (that is, it comes into effect only once a data breach has been identified). The Federal Trade Commission (FTC) is responsible for ensuring businesses have clear policies regarding data protection and that they expedite the response to a data breach (see https://www.ftc.gov/policy/advocacy-research/tech-at-ftc/2022/05/security-beyond-prevention-importance-effective-breach-disclosures). It’s worth noting that the Federal Communication Commission (FCC) is responsible for the resilience of the underlying communications network and provide their own cybersecurity guidance (see https://www.fcc.gov/network-reliability-resources). However, the FCC’s purview is the communication layer and this book is aimed at those working in the business layer, so the FTC’s influence is more pertinent. To complicate matters further, different states enact their own data protection laws in different domains, so it is vital to confirm security requirements in your jurisdiction. Security incident response plans and communication strategies will be covered in later chapters.

Finally, there are also statutory requirements that apply to child safeguarding. For example, in the US, the Children’s Online Privacy Protection Act (COPPA) applies to any child under 13.

Insurance requirements

As with the locks on your door, your insurers will influence your cybersecurity requirements. If you can’t demonstrate you have fulfilled your insurer’s cybersecurity requirements, they won’t cover you in the event of a breach. For example, your insurers may require you to take regular backups of your data and to make sure that you have a disaster recovery procedure in place so that data can be restored. They may well also insist that multi-factor authentication (MFA) is enabled on all cloud-based services.

Check with your organization’s insurance broker – or directly with the underwriter – to confirm what their cybersecurity requirements are.

Service License Agreement (SLA) requirements

An SLA isn’t just the agreement between you and your client but also the agreement between you and trusted third-party suppliers (a point that is often lost during contract negotiations). A typical SLA outlines what a provider promises to deliver, when, and what the remediation steps might be when things go wrong. For example, are you outsourcing hosting to a Moodle partner (or similar hosting company) or are you self-hosting in a cloud environment (for example, AWS, DigitalOcean, or Azure)? Have you checked the details contained in your hosting provider’s SLA? You will likely find that they take no responsibility for the loss of data of any kind – and that can come as an unpleasant surprise if data is lost. You will always be responsible for the activities that occur under your hosting account, as cloud hosting companies are providers of server space and bandwidth and not secure data repositories. There is typically a “Your Responsibilities” section in a hosting contract, so be sure to check this out.

The practical point is that the hosting provider will have no idea what you are doing on their servers, so they cannot take any responsibility for any data loss. It’s also worth realizing that a hosting provider will reserve the right to disconnect your server from the internet if they detect your server is running suspicious software – or even operating in a manner they deem to be out of the (or rather their) ordinary. This will be covered by your hosting provider’s Acceptable Use Policy (AUP).

Such restrictions can directly affect us. For example, because Moodle allows students to upload files, how do we mitigate the risk they might upload a virus or a rootkit? How we can protect our Moodle from these kinds of risks will be explored in Chapter 5.

Third-party supplier risk audit

Suppliers update their license agreements regularly. It is vital that, as a security advisor, you keep up to date with these updates. Schedule a regular third-party risk assessment so that you are aware of any risks that a supplier might be imposing (either intentionally or otherwise) on your business.

ITT requirements

Finally, ensure you read and re-read an ITT and confirm that the buyer isn’t trying to transfer unacceptable security risks onto your business before you bid. For example, does the ITT include insistence on shared indemnity for data loss? I treat this as a red flag and avoid these projects. But is this a risk you are willing to take? How much are you willing to charge a client for accepting that risk?

Having gained an understanding of the regulatory environment, we’ll now turn to techniques for capturing security risks. In the next section, we will start to build a risk register.

Creating a risk register

Right from its very inception, at the very least, ensure security is included in your project’s risk register. Consider each risk as a foreseeable harm. Perhaps add a separate security risk register to your task board. The following table is an example for the Mathaholics site:

ID	Description of risk	Probability	Impact	Severity	Mitigation action
1	A user will attempt a brute-force server SSH log-in.	1	HIGH	HIGH	1. Intrusion prevention software to be installed on the server. 2. Server access is only allowed from specified IP addresses.
2	A user will attempt a brute-force Moodle login.	0.75	HIGH	HIGH	1. The platform can only be accessed through SSO.

Figure 1.6 – An example of a risk register

In this section, we will focus on the following four columns:

• Description of risk
• Probability
• Impact
• Mitigation action

Description of risk

When discussing security risks, it is tempting to capture risks in sentences bookended with What if and ?. I would avoid this approach as discussions can quickly lead to motivation and, as far as we are concerned, what motivates a bad actor is irrelevant. It is far more constructive to consider how a bad actor might put your systems at risk, rather than why they might do so.

Key takeaway

When considering security risks ask how – don’t ask why.

If you are unsure where to start (or you are worried your team might disappear down security rabbit holes), then one approach is to frame sentences with a noun and a verb. Here are some examples:

• A user will attempt a brute-force Moodle login
• A user will attempt a brute-force server SSH login

Having captured a risk, we now need to gauge the likelihood of that event occurring.

Probability

Although the column is headed Probability, figures quoted on risk registers typically represent the expectation of an event occurring. If you’re mathematically minded, then you will be well aware that probability is not the same as expectation, so it’s important to understand what your project manager might mean by the word probability in their context. For risk measurement, probability is a measure of the likelihood of an event occurring, while expectation is a measure of the likelihood that this event will occur within a specific timeframe. For the risk identified in the preceding step, the probability of a brute-force Moodle login attack might be 0.75 (that is, more likely than not). However, the probability of a brute-force server SSH login attack is, at least in my experience, 1 – I’ve never known of a server where an SSH brute-force attack hasn’t happened.

As expectation values apply within a given timeframe, it is sensible to reassess expectations at regular intervals, such as during retrospectives or your quarterly planning meetings.

Key takeaway

The probability of an event occurring might be small but the expectation that it might occur within a given timeframe increases with the size of the timeframe and other events taking place within that timeframe.

Impact

The impact is often a rating, such as high, medium, or low. It could also be a number, in which case the probability and impact can be used to determine a severity score (typically, the severity is the product of the probability and the impact).

Slightly confusingly, I’ve also seen impact described as expectation, which leads to another important key takeaway.

Key takeaway

Ensure your team uses consistent words to refer to specific risk attributes. If there is any uncertainty, be sure your risk register includes a glossary.

Mitigation action

Exploring the steps we could take to mitigate the security risks is, of course, the purpose of this book.

In the introduction, I suggested clearing a space on your office wall so that you can begin capturing security risks. You can mark when that risk has been added to the risk register on each sticky note.

Before ending this section, we should stress that a risk register is not a static document. Remember not to confuse probability with expectation within a given period. For example, the festive holidays that straddle the end of one calendar year and the beginning of the next are likely times for cyber-attacks because those committing the attacks will assume that key IT staff are on holiday. It’s worth noting that there is an increasing underlying trend in the number of cyber attacks enterprise organizations suffer. For example, see the UK Government’s Cyber Security Breaches Survey for 2022 at https://www.gov.uk/government/statistics/cyber-security-breaches-survey-2022. So, the expectation that an attack will take place during this period is high but so is the impact if key staff are unavailable over the festive break.

Summary

We began this chapter by revealing how protecting an online platform such as Moodle is very similar to protecting any other asset. Security in both the real and digital worlds works within similar regulatory and operational constraints, as introduced here. As we have seen, the complexity of the security landscape can be hard to manage, so we also looked at simple methods we can apply to understand and measure risk tolerance.

By now, you should have some context about the security landscape Mathaholics will be operating within, in addition to knowing about the most important international regulatory frameworks and best practices. We learned that there are, essentially, four entities placing constraints on the Mathaholics Moodle platform we are building: the government, the client, our cloud hosting provider, and our insurers. As the Mathaholics Moodle Security Advisor, we must ensure we adhere to the frameworks and work within the constraints these agencies prescribe. We discussed simple techniques that can used to identify them and translate these into risks. Finally, we started to capture risks in a risk register.

In the next chapter, we will continue the theme of identifying security risks by introducing the concept of threat modeling. We will also explain how the STRIDE approach can help us capture security threats.