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.