LiquidFiles Secure Development Practices
Overview
LiquidFiles is built using mainly Ruby on Rails and JavaScript on a Ubuntu operating system platform. LiquidFiles is built from the ground up to be secure and that starts with secure development practices.
Design & Architecture
LiquidFiles is built to be secure by default, this is true both from the company's point of as well as the LiquidFiles product. What that means in practice is that you can run a default configured LiquidFiles system on the Internet with no other firewalls or security measures deployed if you want, with no additional hardening required. Internally, we've been running several test systems on the public Internet with only very basic filters in Amazon AWS and Microsoft Azure since 2008 without compromise. This wouldn't be possible if LiquidFiles wasn't built using a modern web application framework (Ruby on Rails) with lots of security features enabled on default, as well as being designed from the ground up with security in mind and with common web security practices integrated into the product as it comes.
Monolithic Architecture & Privacy
Each LiquidFiles system is designed as a completely standalone monolithic application. Everything needed to run LiquidFiles is included in the LiquidFiles virtual appliance itself. LiquidFiles is not a Cloud Service that is centrally managed by us as a company. We, LiquidFiles the company, does not have access to any of our customers LiquidFiles installation and have no visibility of any files sent or to whom, any users you may have configured, any administrators that can access the system with administrative privileges and so on. LiquidFiles a completely private, isolated system.
The only thing we (LiquidFiles the company) knows about you and your LiquidFiles system is the Public Hostname and the number of users for licensing purposes. You can if you want add your organizations contact information to be added on quotes and invoices, but this is not something we request or require for you to run LiquidFiles.
There is a support function where if a system is not behaving as expected, we can request that you enable support access. This is something that is completely in your control, we cannot enable access to any LiquidFiles system. If we access your system, we will only look at logs and potentially manually add code fixes and similar to address a certain issue. We will never reset passwords, add or change any authentication, remove any access limitation you have configured and similar. Should you lock yourself completely out of your LiquidFiles system, there are processes that can be performed to regain access. The process will require booting the system off an ISO image, ensuring that whomever can perform the recovery process has physical access to the LiquidFiles system in question and it will need be performed by each customer themselves.
Development Methodology
LiquidFiles is developed using a TDD — Test Driven Development methodology. This process starts when new features are developed. When we develop new features, these are developed using different git branches in GitHub. After sufficient testing using a combination of manual functionality testing as well as writing automated tests following the Ruby on Rails testing framework with unit, functional and integration testing to make sure they not only work but not interfere with the rest of the product.
When a feature is ready to be merged into the main code branch, Git Pull Requests are used at which point the code is again manually validated that it follows current security guidelines.
The methodology for fixing potential security or functionality issues is largely the same. After manual verification that the issue exist, a (unit, functional or integration) test is written that will trigger the issue and ensure the fix actually fixes the issue. Not only does this ensure code quality, it ensures that issues will not reappear further down the track.
Please also see the Responding to Vulnerability Assessments section below for more information specifically related to how fixes are handled when responding to Vulnerability Assessments.
Following Vendor Recommendations
Ruby on Rails
Ruby on Rails is the main web application framework that's used in LiquidFiles. Ruby on Rails is a modern web application framework built from the ground up to be secure and to follow current web development methodologies. That means that a lot of security features that can be hard to build using older frameworks like PHP, we get "for free" with Ruby on Rails. An example of this is Cross Site Request Forgery protection that gets automatically added to every form vs in something like PHP that would have to be manually added and tested.
To ensure that the security features that are available in Ruby on Rails are used properly, the LiquidFiles development team continually monitor and follows the security development practices described in the Ruby on Rails Security Guidelines. To further ensure that the security guidelines are used, automated code scanning tools are used
Ruby on Rails Code Scanning
Brakeman is a vulnerability scanner specifically designed for Ruby on Rails applications. It statically analyzes Rails application code to find potential security issues. The LiquidFiles development team manually runs the Brakeman scanner before any code is committed as well as being run using the automated build and continuous integratation testing process.
For the Ruby on Rails side of things LiquidFiles also uses Rubocop. Rubocop is primarily a Linter and it also has plugins (cops) that targets potentially security issues. The LiquidFiles development team runs RuboCop manually before committing code as well as being run using the automated build and continuous integratation testing process.
JavaScript code Scanning
For JavaScript, LiquidFiles uses ESLint as a code scanner/linter to ensure code quality. ESLint scans all JavaScript code and analyzes for both security and functionality issues as well as validating the code is gramatically correct to minimize any potential issues. The LiquidFiles development team runs ESLint manually before committing any JavaScript code as well as being run using the automated build and continuous integratation testing process.
Ubuntu
LiquidFiles uses Ubuntu is the underlying operating system that LiquidFiles runs on. Since its inception in 2004, Ubuntu has been built on a foundation of enterprise-grade, industry leading security practices.
The Ubuntu operating system is installed using a minimal package strategy. As far as possible, addional required components such as PostgreSQL, ProFTPd, OpenSSL, OpenSSH and installed directly from Ubuntu supplied repositories. This ensures both that these components are configured for optimum compatibility as well as it ensures that security updates are automatically made available to LiquidFiles. On default, all LiquidFiles systems are configured to install security updates daily to ensure the latest system functions are installed and up to date.
Ubuntu Pro
If you're interested in security or compliance, we recommend that you sign up for and enable an Ubuntu Pro license to enable commercial support from Ubuntu as well as additional security mesures for compliance with certifications such as: DISA-STIG, FedRamp, NIST, Sarbanes-Oxley (SOX), HIPAA, FISMA, Center for Internet Security (CIS), Common Criteria, PCI, ISO 27001, FIPS 140 and Cyber Essentials.
Automated Testing & Building Releases
Continuous testing
LiquidFiles uses GitHub Actions to run through the suite or automated tests, including the Ruby on Rails unit, functional and integration tests, followed by the Brakeman, Rubocop and ESLint scans described above. If any test fails, the build process will not complete, meaning that it's impossible to create a LiquidFiles release that hasn't passed all the required tests.
Building Releases
In addition to running the continous testing suite describe above, GitHub Actions are also used to build any LiquidFiles release. Having a well tested and automated build process ensures release integrity in that there is no manual process involved in building LiquidFiles releases.
3rd Party Libraries and Functions
The following section outlines how LiquidFiles keep up-to-date with required 3rd party Libraries and functions to ensure there's no supply-chain issues with LiquidFiles or related functions.
Application — Ruby on Rails & JavaScript Libraries and functions
Any application will have various libraries or depencies it requires to function. In the Ruby, or Ruby on Rails world, these are called gems. These include functions such as ruby-saml, that is the library (or gem) that performs SAML authentication in LiquidFiles.
The first tools that's being used in LiquidFiles to keep Libraries and functions up to date is a development tool called Bundler. Bundler has a list of libraries and functions that LiquidFiles uses and it installs the latest possible version of each library, as well as any dependencies that any of the libraries relies upon. Bundler will alert if there's any library in the application that has any known security issues. The LiquidFiles development team runs Bundler before any LiquidFiles release to ensure the latest possible version of each library is installed for that LiquidFiles release.
Almost all libraries and functions uses GitHub these days to store and distribute their code. The LiquidFiles development has added alerts for all required functions to be alerted whenever there's any security related issues and subsequent releases being released, to ensure that these gets updated in LiquidFiles as soon as possible.
In addition to GitHub alerts, GitHub also has a function called Dependabot that is an automated tool that keeps track of gems, libraries and functions that has been added to LiquidFiles and will send alerts if it detects a gem or library that has a security issue and needs to be updated. This further ensures that LiquidFiles will get alerted to any potential issue with any gem or Library.
System — Ubuntu & Ubuntu distributed applications, libraries and functions
On default, all LiquidFiles system are configured to update both the LiquidFiles, the Ubuntu system and any required application, library or function on a daily basis. The Ubuntu team will test and release updates peridiocally and installing updates daily ensure maximum protection against new threats.
LiquidFiles aim to follow Ubuntu LTS (Long Term Support) releases. When Ubuntu releases upgrade tools from one LTS release to the next, LiquidFiles aim to move to the next Ubuntu LTS release as part of the next major LiquidFiles release.
External Scanners & Validation
SSL Labs — SSL Test
LiquidFiles uses SSL Labs — SSL test to validate the web server configuration, including TLS ciphers and similar. Our aim is that a default LiquidFiles system will achieve an A+ rating, which it does. SSL Labs — SSL test is also our reference for what TLS ciphers and similar to include in the default configuration and only ciphers deemed strong by SSL Labs are included in the default SSL/TLS configuration.
Example SSL Labs — SSL Test Scan of a default LiquidFiles system: ssllabs-2024-12-12.pdf
Security Headers
In addition to the SSL Labs test above, LiquidFiles uses Securityheaders specifically to scan for various web related security headers. Our aim is that a default LiquidFiles installation shoud achieve an A+ rating, which it does. We use Securityheaders.com as our reference for when to add additional security headers in LiquidFiles.
Example SecurityHeaders Scan of a default LiquidFiles system: securityheaders-2024-12-12.pdf
OpenVAS
To ensure system integrity, a few live test systems are scanned using OpenVAS. OpenVAS checks for more than 50,000 vulnerabilities. These scans runs periodically using HostedScan for continuous ensurance that no new vulnerabilities are discovered on default LiquidFiles systems.
Example OpenVAS Scan of a default LiquidFiles system: openvas-2024-12-12.pdf
Customer Initiated Vulnerability Scanning and Assessments
We're lucky in a sense that we have a lot of security consious customers from sectors such as banks, financial institutes, governments and defence. These customers all have rigourous security requirements that LiquidFiles will need to comply with. One of the things that happen regularly is that our customers will perform vulnerability scanning of their environment which then include their LiquidFiles system(s). When they do, they will often share the result with us and ask for commentary around certain issues that they may have uncovered. Please see the next section for more details around this.
The good thing from our (and yours) perspective is that we know that LiquidFiles gets exposed to a wide verity of security scans and vulnerability assessments on an ongoing basis, and its rare that anyone discovers anything more than minor issues every so often.
Responding to Vulnerability Assessments
A part of developing software that's used by various organizations is to respond to security vulnerability assessments. Since launching LiquidFiles in 2008, we have responded to hundreds of such vulnerability assessments over the years. The overwhelmingly majority of these include nothing but false positives, configuration issues and sometimes scans of insecurely configured reverse proxies in front of LiquidFiles and similar where the results are not directly related to LiquidFiles. This happens often enough that we've compiled a Frequent Responses after security reviews that covers the most freqently raised false positives from vulnerability assessments.
Every so often though, there is a legitimate vulnerability discovered in LiquidFiles. The process for reporting a potential vulnerability to LiquidFiles is the same as any other question you may have, please open a Support Ticket at support.liquidfiles.com. We will then manually verify if there's a legitimate vulnerability or a false positive. If it's a legitimate vulnerability we will write a test that triggers the vulnerability, fix the vulnerability and report back to whomever has reported the issue. The turnaround time for this is usually 24h. This surprises many, and has even annoyed a few. A lot of security professionals and companies are heavily invested in a vulnerability lifecycle management process and it messes with this process if we just turn around and fix the issue. But anyway, with our robust test suite we can almost always turn around with a fix in 24h, we then wait for whomever has reported the issue to verify that our fix indeed fixes their reported issue. Once confirmed we release a public minor release of LiquidFiles with the fix included. This is usually another 24h later, or within 48h since the issue was reported. The main difference between security related issues and functional issues is that we create a minor release instantly vs with a functional or cosmetic issue, we usually bundle them up and typically release a minor update to LiquidFiles once per month.
Notifying LiquidFiles Customers
As a LiquidFiles customer, we recommend adding yourself to the LiquidFiles Announcement Maillist. The LiquidFiles Accouncement Maillist is a low volume mailing list that announces updates to the LiquidFiles application, updates to the LiquidFiles End User License Agreement, Privacy Policy and similar. It is recommended that all LiquidFiles customers sign themselves up to the Maillist and you will be prompted when you create an account on the LiquidFiles license server https://license.liquidfiles.com.
In addition to the Maillist, all LiquidFiles releases are documented on the Release Notes section.
Security Best Practices
The LiquidFiles development team continously monitor resources like OWASP Top 10, SANS Top 25 and similar online resources to stay up-to-date with industry security best practices.
External Vendors
While not strictly related to coding practices, these are the external vendors used by LiquidFiles for our internal source code and data and their respective security profiles.
GitHub
All LiquidFiles source code is stored in GitHub. We also use GitHub Actions for continous testing and building all LiquidFiles releases. GitHub is also used to host this documentation site https://docs.liquidfiles.com.
Please see https://github.com/security for detailed information about GitHub security.
Amazon AWS
LiquidFiles uses AWS to host the LiquidFiles license server and data, the GeoIP lookup service and support access systems. It's also used to host and distribute the LiquidFiles public website https://www.liquidfiles.com as well as the system update files.
Please see https://aws.amazon.com/security/ for detailed information about AWS security.
Zendesk
LiquidFiles uses Zendesk to host our Support ticketing system https://support.liquidfiles.com / support@liquidfiles.com (using support@liquidfiles.com creates and updates tickets on https://support.liqudifiles.com).
Please see https://www.zendesk.com/trust-center/ for detailed information about Zendesk security.