CSOs face a dizzying array of bad options for their communications and information technology needs. Most groups settle on a mishmash of different services, often fulfilling their needs with different providers for mailing lists, document collaboration, group chat, relationship management, website publishing, and so on. This piecemeal approach is bad for usability, bad for security, and very complex for an organization to maintain. Worse, many of the core systems on which many groups rely are subject to levels of tracking and surveillance that are not compatible with the goals and principles of these organizations.
CSOs that want to start using more secure communications and collaborations tools, as developed by the Internet Freedom community, often find that they lack the required system administration skills and time to securely set up and maintain such systems from scratch. Software tools and services coming out of the Internet Freedom community today often rely on a barebone Linux server for installation, and assume a high level of technical competency to secure, maintain and update. As such, many organizations still rely on less secure and less open tools like Skype and Dropbox to get their work done, or — some lucky ones — require significant systems administrator resources to keep an alternative infrastructure running.
OpenAppStack will automate the secure deployment and maintenance of free and open tools, to provide more secure and specialized single-tenant online services. Using OpenAppStack, a moderately technical person from within the CSO can select the services the organization needs, and enable an instance of that service in seconds. The person can use the core OpenAppStack authentication service dashboard to manage users, enable and revoke access to specific services and manage the multi-factor authentication methods. Applications updates are provided automatically, thus providing a user experience more similar to popular hosted multi-tenant applications.
OpenAppStack is built around a single-tenant cloud model, which means that every organization will have its own OpenAppStack system setup, running on one or more cloud instances (using low-level virtualization). The individual applications within the stack are containerized (using Docker). This model optimizes between the cost efficiency of containerization and the security benefits of full virtualization (between tenants).
The initial OAS offering will provide a compelling and complete suite of online applications. Next to that, the project will be open for tool developers to use the reproducible deployment pipeline, consisting of CI/CD and (functional) testing hooks as well as APIs to integrate the setup process into the user interface.
This project bridges infrastructure and software for the Internet Freedom community and beyond. We aspire at liberating organizations and individuals from having to turn to proprietary solutions every time they ‘just need to get the job done’ by providing them a more robust alternative with the same or better usability, and extending the reach of open, more secure software.
If we want more organizations to use independent and federated open software and platform services, we need to change the process of delivery and automate maintenance, whilst making the process efficient and simple.
A successful implementation will see more CSOs migrate from proprietary software to robust alternatives built by the Internet Freedom community, translating into more used open cloud software. Additionally, by using existing open infrastructure to create a robust new alternative for CSOs, we demonstrate the benefit of collaboration among peers to the Internet Freedom community. Furthermore, this project will benefit the wider tool producing community by providing delivery mechanisms for software testing and continuous integration, that could be replicated in other infrastructure initiatives.
The project is aimed at CSOs and individual activists that require online solutions and are weary of the corporate offering (or are keen to move away from them). They want these services hosted on a system that they can rely on, but do not need to maintain. Our initial user base will consist of existing Eclips.is and Deflect users, numbering in the low thousands who would like to run their own online services for better communication and information management. Our second user base is the wider Internet Freedom community, whose members are often the technical point of entry to CSOs reliant on them for their technical needs.
Initially, OpenAppStack will introduce the most popular services used by CSOs: file sharing and shared calendars via Owncloud, Nextcloud, or Seafile, internal communications with Mattermost, conferencing with Jitsi, Janus or Jangouts, and web publication with Wordpress. Selecting applications that will be part of OpenAppStack will be done based on maintenance, activity, sustainability (security) track record and interoperability and their Best practices badge status.
Underlying network security
Research has shown that CSOs are targeted by state-sponsored hacking campaigns and cyber espionage. Many cases of malware are being reported, and it has become a major threat to the security of these already vulnerable and often insufficiently maintained systems. This problem is now even more acute than ever, as the spread of malicious malware has become prolific, in particular after a large trove of NSA hacking tools were leaked and released publicly. Some of these tools are already utilized for spreading malware and ransomware, something any organization wants to prevent, let alone the organizations working in the human rights field. Of course, it boils down to keeping systems updated as much as possible, but it is quite a lot of work to keep an eye on security patches; it is almost a full-time job nowadays. With OpenAppStack they will have a tool stack available that will secure many applications, and ensures a level of security and privacy, which is of pivotal importance.
OpenAppStack will be built to be agnostic of the cloud platform for its provisioning of services, this means it will function well on any major cloud platform like AWS or DigitalOcean, as well as on smaller offerings by other alternative infrastructure providers. Greenhost and Eclips.is will enable us to use additional security features at the underlying cloud level (with third party cloud providers, there would be no access to this layer). The collaboration between Greenhost and eQualit.ie provides integrated Deflect Labs technology to analyse, understand, and mitigate malicious behavior on the network, as an attack is happening. Deflect Labs enables a broader attack classification system, and will have anomaly detection mechanisms, which will broaden its scope from DDoS bots and botnets to a wider range of malicious activity and anomaly detection, including brute-force, probing and intrusion. Malicious IP addresses will be stored in the database according to the attack they have engaged with. This will help in the analysis and profiling of returning attackers. Collating and building a history of their targets may help us identify the intentions of the botnet over a longer period. The toolset built to integrate this tools into Eclips.is will be available for other alternative hosting providers too.
self-updating mechanism security
A self-updating mechanism can itself become part of the attack vector and needs to be carefully designed and vetted. OpenAppStack application images will be based on trusted third party sources with minimal patches from the OpenAppStack team. The update mechanism itself will use signed packages/images by the OpenAppStack maintainers. Additionally by using modern container techniques (docker) the update process of a single application does not have access to other applications or the base system.
On the backend part of our toolchain we expect trusted Debian apt repositories to be used in combination with trusted third party application sources. These would integrate to OAS upgrade images that are distributed through a dedicated repository. These images are signed.
For our upstream it is vital to have a very limited set of trusted repositories, and to watch which third party libraries the applications we want to ship will include. Especially in web development there is a tendency to include packages or libraries without too much vetting, using tools like Pypi or NPM. So even if a maintainer is trusted by OAS, there will still be additional vetting of the dependencies for such a project. Adding upstream updates will trigger an internal review of the changes before signing such changes for OpenAppStack use.
Software which is developed as part of the project itself (authentication broker, user manager) should be built according the The Best Practices Badge criteria.
If OpenAppStack is successful it makes sense to try to coordinate auditing efforts towards MOSS, FOSSA or CII. Regular audits are one of the criteria we are looking for in the inclusion of applications in OpenAppStack. At the same time new and better projects might not have been audited yet, so inclusion in OpenAppStack might become a reason for auditing. But in the first year OpenAppStack should focus on building the required software frameworks. When it is more notable it could fulfill such community roles.