ISO 27001: Input data validation and Control of internal processing

ISO 27001: Input data validation and Control of internal processing

by Gael Lams -
Number of replies: 6

Dear all,

We are preparing for an ISO 27001 certification.

As we are growingly using Moodle. I'm trying to get information regarding the following two ISO controls as they apply to Moodle also:

A.12.2.1 Input data validation: "Validate data input to application system to ensure that the data are correct and appropriate"

A.12.2.2 Control on internal processing: "Validate checks into the systems in order to detect corruption of the data processed"

where could I find information to understand how moodle deals with it?

Kind regards,

Gaël

Average of ratings: -
In reply to Gael Lams

Re: ISO 27001: Input data validation and Control of internal processing

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Obviously we can only speak for core Moodle and 'approved' plugins (those in the official plugin database). However, all Moodle code - as confident as I can be - follows the first one due to this recommendation...

http://docs.moodle.org/dev/Security#Don.27t_trust_any_input_from_users

This may also cover the second point but I don't really understand what it's saying - I'm not even sure it's a proper sentence wink

EDIT: 

Ahhh.... looked it up...

"Validation checks shall be incorporated into applications to detect any corruption of information through processing errors or deliberate acts"

I'm not sure how appropriate that is. The latter part is covered by the "don't trust input" bit above but I struggle to see how the former part applies to Moodle. 

In reply to Howard Miller

Re: ISO 27001: Input data validation and Control of internal processing

by Gael Lams -

Dear Howard,

Thanks for the reply, really appreciated

regarding the second control I will check with the person assisting us in the certification preparation and will come back to the forum if needed.

Best,

Gaël

In reply to Gael Lams

Re: ISO 27001: Input data validation and Control of internal processing

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Moodle doesn't really process information in such a way that there are likely to be errors. You could claim that unit tests are there to check that functions do what they say they are going to do. 

In reply to Gael Lams

Re: ISO 27001: Input data validation and Control of internal processing

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Trying to remember what I learned on M886 (OU course about Information Systems Security) - other than the fact that I never, ever want to be involved in a formal ISO27001 certification effort wink (Most of the things they suggest you do are quite sensible, but the amount of documentation required to say you have done so is gruesome.)

Regarding A.12.2.1. All input into Moodle is filtered in one of two ways:

All data input into forms in Moodle gets validated before use. Moodle has a forms library to facilitate creating forms, and validation is an important part of that.

Other data input (e.g. from URL parameters like /course/view.php?id=123) are process through the optional_param/required_param API, which always takes a paramter type (like PARAM_INT) to filter the data appropriately.

In addtion, the Moodle coding guidelines require the use of these techniques (http://docs.moodle.org/dev/Coding ) and the Moodle code review processes (http://docs.moodle.org/dev/Process ) esures that those guidelines are followed. 

Regarding A.12.2.2. One level or protection comes from that fact that all Moodle data (apart from uploaded files) are stored in a relational database (though let's gloss over the fact that for historical reasons, we don't create the foreign-key constraings). The code contains some other validation of values being processed, though often only in developer debug mode for performance reasons.

In reply to Tim Hunt

Re: ISO 27001: Input data validation and Control of internal processing

by Catherine Pinnell -

Hi all,

I am also in a similar position with trying to navigate the ISO requirements. You are correct, it is gruesome to document to their standards! I read through many of the links provided (thank you!) but I still have a question.

The Moodle site I am currently running will be expanded dramatically to accommodate training in every department of the company. I will not be able to support the needs of every trainer on my own. My initial plan is to have one or two individuals with the teacher role assigned in every department (separated by course category) so they have the ability to upload SCORM packages as they are updated and will not need to rely on me for uploads. I already understand and have a plan on how to assign roles by category.

I have not been able to find good log or record that identifies changes made to Moodle courses. We need to know who changes training content, including uploading new/replacing content, as these are audit artifacts. The logs are great for student activities, but not on the teacher/admin end from what I have found so far.

Am I looking in the wrong places?  Does anyone have any recommendations on how to meet this audit requirement?

Thank you in advance for your thoughts. 

In reply to Catherine Pinnell

Re: ISO 27001: Input data validation and Control of internal processing

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

You are right. The Moodle logs are limited. This may get fixed one day, but don't hold your breath.

There are also the web-server logs, but they may not include the user identities. They will include accurate time-stamps and IP addresses, which could be compared against the times in the Moodle logs.

Configuration changes on the admin screens are now logged, and a separate config log.