Search icon CANCEL
Cart icon
Close icon
You have no products in your basket yet
Save more on your purchases!
Savings automatically calculated. No voucher code required
Arrow left icon
All Products
Best Sellers
New Releases
Learning Hub
Free Learning
Arrow right icon
Moodle 4 Security
Moodle 4 Security

Moodle 4 Security: Enhance security, regulation, and compliance within your Moodle infrastructure

By Ian Wild
€20.99 €13.99
Book Mar 2024 288 pages 1st Edition
€20.99 €13.99
€14.99 Monthly
€20.99 €13.99
€14.99 Monthly

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon AI Assistant (beta) to help accelerate your learning
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Buy Now
Table of content icon View table of contents Preview book icon Preview Book

Moodle 4 Security

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

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

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

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

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







The tenderer’s security policy is reviewed annually by an independent party, and the outcome is shared with the customer.



The tenderer reports periodically about security and privacy assurance.



When signing into the application, a limited number of attempts are allowed before the account is blocked.



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.



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.


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


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 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 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 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 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:


Description of risk




Mitigation action


A user will attempt a brute-force server SSH log-in.




1. Intrusion prevention software to be installed on the server.
2. Server access is only allowed from specified IP addresses.


A user will attempt a brute-force Moodle login.




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.


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.


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 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.


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.

Left arrow icon Right arrow icon
Download code icon Download Code

Key benefits

  • Demonstrate the security of your Moodle architecture for compliance purposes
  • Assess and strengthen the security of your Moodle platform proactively
  • Explore Moodle’s baked-in security framework and discover ways to enhance it with plugins
  • Purchase of the print or Kindle book includes a free PDF eBook


Online learning platforms have revolutionized the teaching landscape, but with this comes the imperative of securing your students' private data in the digital realm. Have you taken every measure to ensure their data's security? Are you aligned with your organization’s cybersecurity standards? What about your insurer and your country’s data protection regulations? This book offers practical insights through real-world examples to ensure compliance. Equipping you with tools, techniques, and approaches, Moodle 4 Security guides you in mitigating potential threats to your Moodle platform. Dedicated chapters on understanding vulnerabilities familiarize you with the threat landscape so that you can manage your server effectively, keeping bad actors at bay and configuring Moodle for optimal user and data protection. By the end of the book, you’ll have gained a comprehensive understanding of Moodle’s security issues and how to address them. You’ll also be able to demonstrate the safety of your Moodle platform, assuring stakeholders that their data is measurably safer.

What you will learn

Measure a tutoring company's security risk profile and build a threat model Explore data regulation frameworks and apply them to your organization's needs Implement the CIS Critical Security Controls effectively Create JMeter test scripts to simulate server load scenarios Analyze and enhance web server logs to identify rogue agents Investigate real-time application DOS protection using ModEvasive Incorporate ModSecurity and the OWASP Core Rule Set WAF rules into your server defenses Build custom infrastructure monitoring dashboards with Grafana

Product Details

Country selected

Publication date : Mar 8, 2024
Length 288 pages
Edition : 1st Edition
Language : English
ISBN-13 : 9781804611661
Vendor :
Category :

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon AI Assistant (beta) to help accelerate your learning
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Buy Now

Product Details

Publication date : Mar 8, 2024
Length 288 pages
Edition : 1st Edition
Language : English
ISBN-13 : 9781804611661
Vendor :
Category :

Table of Contents

18 Chapters
Preface Chevron down icon Chevron up icon
1. Part 1: Moodle Security Primer Chevron down icon Chevron up icon
2. Chapter 1: Moodle Security – First Steps Chevron down icon Chevron up icon
3. Chapter 2: Moodle Threat Modeling Chevron down icon Chevron up icon
4. Chapter 3: Security Industry Standards Chevron down icon Chevron up icon
5. Part 2: Moodle Server Security Chevron down icon Chevron up icon
6. Chapter 4: Building a Secure Linux Server Chevron down icon Chevron up icon
7. Chapter 5: Endpoint Protection Chevron down icon Chevron up icon
8. Chapter 6: Denial of Service Protection Chevron down icon Chevron up icon
9. Chapter 7: Backup and Disaster Recovery Chevron down icon Chevron up icon
10. Part 3: Moodle Application Security Chevron down icon Chevron up icon
11. Chapter 8: Meeting Data Protection Requirements Chevron down icon Chevron up icon
12. Chapter 9: Moodle Security Audit Chevron down icon Chevron up icon
13. Chapter 10: Understanding Vulnerabilities Chevron down icon Chevron up icon
14. Part 4: Moodle Infrastructure Monitoring Chevron down icon Chevron up icon
15. Chapter 11: Infrastructure Monitoring Chevron down icon Chevron up icon
16. Index Chevron down icon Chevron up icon
17. Other Books You May Enjoy Chevron down icon Chevron up icon

Customer reviews

Top Reviews
Rating distribution
Empty star icon Empty star icon Empty star icon Empty star icon Empty star icon 0
(0 Ratings)
5 star 0%
4 star 0%
3 star 0%
2 star 0%
1 star 0%
Top Reviews
No reviews found
Get free access to Packt library with over 7500+ books and video courses for 7 days!
Start Free Trial


How do I buy and download an eBook? Chevron down icon Chevron up icon

Where there is an eBook version of a title available, you can buy it from the book details for that title. Add either the standalone eBook or the eBook and print book bundle to your shopping cart. Your eBook will show in your cart as a product on its own. After completing checkout and payment in the normal way, you will receive your receipt on the screen containing a link to a personalised PDF download file. This link will remain active for 30 days. You can download backup copies of the file by logging in to your account at any time.

If you already have Adobe reader installed, then clicking on the link will download and open the PDF file directly. If you don't, then save the PDF file on your machine and download the Reader to view it.

Please Note: Packt eBooks are non-returnable and non-refundable.

Packt eBook and Licensing When you buy an eBook from Packt Publishing, completing your purchase means you accept the terms of our licence agreement. Please read the full text of the agreement. In it we have tried to balance the need for the ebook to be usable for you the reader with our needs to protect the rights of us as Publishers and of our authors. In summary, the agreement says:

  • You may make copies of your eBook for your own use onto any machine
  • You may not pass copies of the eBook on to anyone else
How can I make a purchase on your website? Chevron down icon Chevron up icon

If you want to purchase a video course, eBook or Bundle (Print+eBook) please follow below steps:

  1. Register on our website using your email address and the password.
  2. Search for the title by name or ISBN using the search option.
  3. Select the title you want to purchase.
  4. Choose the format you wish to purchase the title in; if you order the Print Book, you get a free eBook copy of the same title. 
  5. Proceed with the checkout process (payment to be made using Credit Card, Debit Cart, or PayPal)
Where can I access support around an eBook? Chevron down icon Chevron up icon
  • If you experience a problem with using or installing Adobe Reader, the contact Adobe directly.
  • To view the errata for the book, see and view the pages for the title you have.
  • To view your account details or to download a new copy of the book go to
  • To contact us directly if a problem is not resolved, use
What eBook formats do Packt support? Chevron down icon Chevron up icon

Our eBooks are currently available in a variety of formats such as PDF and ePubs. In the future, this may well change with trends and development in technology, but please note that our PDFs are not Adobe eBook Reader format, which has greater restrictions on security.

You will need to use Adobe Reader v9 or later in order to read Packt's PDF eBooks.

What are the benefits of eBooks? Chevron down icon Chevron up icon
  • You can get the information you need immediately
  • You can easily take them with you on a laptop
  • You can download them an unlimited number of times
  • You can print them out
  • They are copy-paste enabled
  • They are searchable
  • There is no password protection
  • They are lower price than print
  • They save resources and space
What is an eBook? Chevron down icon Chevron up icon

Packt eBooks are a complete electronic version of the print edition, available in PDF and ePub formats. Every piece of content down to the page numbering is the same. Because we save the costs of printing and shipping the book to you, we are able to offer eBooks at a lower cost than print editions.

When you have purchased an eBook, simply login to your account and click on the link in Your Download Area. We recommend you saving the file to your hard drive before opening it.

For optimal viewing of our eBooks, we recommend you download and install the free Adobe Reader version 9.