What

This page describes an approach to securing data for a small team, in fact this team. Its based on the setup for the FOSSIL source code manager completely but has some nice properties.

The basic assumptions are:

1. You need to share data between team members and customers with some limitations.
2. Each project needs to be accessible via the internet to remote team members and customers using a web site.
3. We need to be able track progress and releases.
4. The system needs to distributed and ideally capable of offline updates.

The skeptical part is that we assume:

1. Team member and customer machines are particularly vulnerable and we must assume they will be compromised.
2. The access to the servers needs to be severely restricted and we should assume a possible compromise here.

The proposed answer in short is based around the FOSSIL source code manager and uses a diverse range of OS types. One interesting property of FOSSIL is that it can be thought of as an append only database so:

1. If a single machine remains secure the compromised machines can only add data to it.
2. Which acts a block chained singed and timestamped.
3. Finally it provides per project Role Based Access Control, wiki, version, project timelines, ... (github in a single executable).

The rest of this document describes an few alternatives and then details the model and provides a summary of its security. This is mostly for review by the Masters students at CDU.

Anti Answers

There are a couple of anti-answers that are commonly deployed.

1. Shared files using a Cloud Service or your own server over a VPN: No version control, loss of work. You also need to add the various other services such as wikis, forums or forums.
2. Use Github to provide the one stop shop for your projects. This is certainly a valid answer but git isn't the easiest tool so we normally see this and the shared file answer.
3. Or just copy files between machines and do backups.

Proposed Answer

The single web site for each project looks just like this page and provides the customers overview of the project including wikis, ticketting, file versions.

The project server runs a OpenBSD host with limited access, in particular:

1. https is open and served by the small OpenBSD server.
2. Authentication is password based and uses per project Role Based Access Control.
3. All team access is via https using the fossil protocols.
4. One machine has network access via ssh to the server.

Each team member (or customer even) can clone the projects they are working on and so they have:

1. Own copy of the project
2. And they can do updates locally and publish them back via https to the project server.

The customers are the same as the team members except they may decide just to access the web interface which acts as the one stop shop.

Then the project is completely synced using fossil to the various archive servers including my laptop.

And of course we backup everything up.

So what?

Compromise of a team member or customers machine results in:

1. Loss of confidentiality for those projects.
2. But we maintain the project history and data intact.
3. And nothing else is compromised (well beyond the other projects they have acces to).

Compromise of the project server would result in the same outcome for all projects.

So for all single point attacks are protected since team members cannot rewrite history in fossil on the server.

There are some other benefits in that a customer can keep their record of the project timelines and events in sync with the project server and its all digitally signed and timestamped.