Security needs
Security needs are generally classified in terms of:
- Availability: servers availability, load balancing ensuring good performances of the service (quick reactivity of the application)
-
Integrity: you want to make sure no one can replace your page by a viagra business website
- Confidentiality: you want to make sure no one can steal your data
Availability is easy to evaluate as we got calculable criteria (% of disponibility, time of response, etc.). Integrity and confidentiality are harder to describe objectively, they depend on your needs.
Protecting the infrastructure
On top of calibrating and setting up an infrastructure that ensures that the website remains available at all times (with web servers, data servers, load balancer, etc. > see infrastructure section), we need to verify other security parameters that can influence security and integrity.
Since the OFN has been used in production for a while, a lot of security concerns have been addressed already. It also benefits from best practices already implemented in the used frameworks (we are in the process of upgrading those framework, this will increase security, see below)
But let’s start with default protection standards as a discussion base.
1- Software protection
Website identification
The domain name of the website has a x509 certificate ensuring the visitor that the website has not been falsified.
Data exchange with the visitor
All access to servers is encrypted, regarding web traffic we use today HTTPS. No use of unencrypted FTP or SMTP services. Data exchange between the client and the server are fully encrypted in TLS to protect users data confidentiality.
Data exchange from the system administrator
Regarding system admin access, you need to use SSH keys (asymetric key RSA4096 (or ECDSA) AES256-CBC) and authentication (login) with a password is disabled. An additional protection by a symmetric key AES256 is not required.
Data protection and backup
The data of the website (database like customer infos, products, etc. + files like images, etc.) should be backed-up daily with a one month retention to ensure we can get back an older version of the website (and the clients as well). To ensure availability and integrity, backups are stored on a distant server (and eventually in multiple locations) with a security level which is at least the same of the production server. Backups data are exchanged following the data exchange policy described above. This is to make sure that the website can be restored in case of emergency. If needed you can implement a mechanism of daily verification of the integrity of the backups.
OS security update on the flow
Security system patchs are automatically applied as soon as released using the security update management system for the operating system (Windows/MacOS/Ubuntu). The integrity of the system is then ensured against known vulnerabilities. Application upgrades are not affected.
Other general protection features
Depending on your security needs you can go more deeply into other general security features like strong authentication for application administrators, logging of each actions, debugging informations, etc. The list can’t be exhaustive, you need to clarify your needs in terms of security and the perimeter, and run an audit to see what to keep and what is missing.
2- Material protection
Physical protection
Servers should be hosted by a hosting provider in a datacenter whose access is only possible by employees via biometric authentication, in order to protect physical integrity of the servers. You will need to check that with the hosting provider chosen to host the infrastructure.
Redundancy of easements
The datacenter of the hosting provider should have planned redundancy for his easements (climatisation, electricity, internet connexion). You will need to check that with the hosting provider chosen to host the infrastructure.
3- Application protection mechanisms
Data entries control
All entries filled in by users are validated conform to the expected format, in order to protect against code injection (SQL, XSS,…). From our knowledge we never had any issue on that, but we need to check in an audit that there is no breach.
Password storage
The application uses personal logins via email address and password.
Passwords are stored hashed with salt. Even system administrators can not read them.
All cryptographic features use industry standard code published as free software.
Backoffice specific protection
A graphic crypton token must be set up to validate requests made on the backoffice. This is to fight CSRF.
Data access permission
The application has a detailed permission system allowing people working together while protecting information about customers and enterprises.
- Administrator: only the very few super-administrators have access to all informations in the platform, to be able to give support to the users. A super restricted number of people have this permission, and they use strong password.
- User:
- Producer enterprise owner/manager: he can only see his product catalog and informations regarding his profile
- Hub enterprise owner/manager: he can see and modify his profile information & his customers informations
If a producer has granted him permission, he can see the producer’s product catalog and add the items to his order cycle (P-OC)…
… add the producer’s products to his inventory (= shop catalog) (P-I)
… and even the producer can allow a hub manager to manage his product catalog for him (P-P)…
… and manage his profile for him (P-PROFILE)
(more information here)
So basically, a hub’s manager cannot see any information regarding another hub. Particular care has been taken around ensuring that customer information is only available to the enterprise they have actually purchased through.
Access levels for your admin/staff can be agreed with the instance host, but at a minimum you would be able to easily see and manage all Hubs and Producers that are part of your network.
Upgrading Our Frameworks
OFN is built upon two frameworks: Ruby on Rails and Spree Commerce. Each of these continually release security updates. Open Food Network is a number of releases behind on each of these, so some work is required to upgrade our system. This work will allow us to leverage the security improvements made by each of these platforms. These upgrades are currently in progress but additional resourcing will enable them to happen much faster. You can contribute to this work.
Security Audit
All code of the OFN and used by the OFN is open source and available for security audits by the public.
Once OFN is running the most recent versions of these frameworks, a security audit of the system could be done. This could look broadly at two areas:
- A penetration test to search for security issues through which a hacker could gain access to the system.
- A review of OFN’s access control system, to ensure that no user can access data in the site that they’re not permitted to. After 4 years of use we are confident that this system is pretty solid.
An audit can be done following the security needs expressed by the client, or can be defined by the auditor and validated by the client. The objective is to make sure the security measures chosen are sufficient and well applied. The auditor gives a deliverable and states the potential inconsistencies between what is done and what is recommended, and add recommendations on how to improve the security level and the associated costs.
OFN has access to experienced experts who could do a security audit in order to check the security assets and validate the application of the security requirements.
The OFN community can support you in defining your security needs
Contact us at hello@openfoodnetwork.org