Authoring tool security
by Sven Laux - Friday, 7 February 2014, 4:04 PM


taken from Darren's requirements feedback:

"Adherence to latest coding standards/security protocols. Once fully adopted we (and I’m sure many other users) will have a significant investment of IP residing on the hosted environment. Knowing this will be as secure as possible i.e. from hackers etc. will allow me to sleep at night! I know much of this will be covered by the set-up/lock down on servers/hosting arrangements but the coding of the tool will also be very important."

Anyone (esp. Dennis and Ryan), do we have any thoughts or documentation on how we approach the architecture and development in terms of security? I think it would be good to document the key principles to keep us mindful of this as we progress.

Relevant references:

In our experience, it's also worth having a specialist penetration test done before releasing version 1.0. This may require some funding (~£5-7K), which we can broach nearer the time. Either way, it would be good to work with security in mind so that we save ourselves having to plug too many gaps later on. While the developers do this, I think we need to document that 'what and how', especially as the node stack is still relatively new to a lot of us.

Are there any takers for this task?



Picture of Darren Hockley
Re: Authoring tool security
by Darren Hockley - Friday, 7 February 2014, 6:27 PM

Hi Sven

We've (DeltaNet) had a couple of projects where clients have carried out pen testing. Dan was our technical lead working with the consultants and responding to their feedback. So I'm sure he would be able contribute here. 

We also partner with a IT security/pen testing company and might be able to 'do a deal' when it comes to needing to get one done; but I'd certainly agree it's needed and confirm we'd contribute towards this financially, if required.

There are also some government grants available (cyber security), although I'm not sure of the legal status of adapt learning and if the bureaucracy would be too much work.

Might be worth a look though. Here is a link for more information.



Re: Authoring tool security
by Sven Laux - Friday, 7 February 2014, 10:15 PM

Thanks for this, Darren.

Great that Dan brings experience in dealing with pen testing and I very much appreciate your thoughts around contribution and funding. Likewise, we bring experience, contacts and would certainly contribute. In summary, I'm sure this is no obstacle and I look forward to getting to the point of commissioning the pen test!

In the meantime, we'll try to document our thoughts and development principles in order to make that test run smoothly when it happens.

All the best,

Picture of Ryan Adams
Re: Authoring tool security
by Ryan Adams - Friday, 7 February 2014, 11:54 PM

We have some documentation currently written about our development standards. It's definitely lacking in scope at present (developers have a reputation of hating anything that looks like management) but we have recognised that it needs updated.

The pull request is here:

I have previously had experience of performing Information Security reviews of software, explicitly refererncing OWASP.  It makes sense to include this type of review as part of our development process.  I'll spend some time during this coming week reviewing security options and how much we need to adhere to. If anyone has a sense of the requirements of industry for security compliance please do comment on this thread (I'm guessing government has a more stringent requirement than private enterprise for example).



Picture of Dennis Heaney
Re: Authoring tool security
by Dennis Heaney - Monday, 10 February 2014, 9:12 AM

Hi all,

As Ryan highlights, it's crucial to have a formal security review integrated into our review process. We're a small enough team at the moment that I think it should be easy to get everyone into the habit of keeping OWASP in mind when reviewing submitted code (and, indeed, when writing code), but a dedicated security reviewer would be a fantastic addition.

Our development team should be particularly vigilant when dealing with functionality involving user input, storing information about the system or the user, and parts of the the system that expose data.

As the backend is a NodeJS app, we are naturally using many community contributed modules. This is another area we need to be careful to monitor so that we make sensible choices, although I'd say that auditing the source code of all the modules in use is unfeasible. I wonder if anyone has any suggestions on the best way to manage this particular issue? To begin with, I think it's important that we choose modules: that have a proven track record; that have a lively development community; where support is ongoing; that have already had several releases. Also, while we may not be able to review the code of all submitted modules, perhaps we can review the code of some - particularly those modules that we use in user authentication, data storage etc.