(Closed) Information Security Principles for Kiez Burn

# Proposer

## Proposer (name, handle, etc.):

@kris

## Proposer’s role:

I do things. Lately ticketing.

# The advice process

## Information gathered before posting

This is not a technical proposal, but it's easy to get bogged down in technical minutiae. Let's try to avoid that.

It is about our general stance towards managing information, and about empowering people to do things.

This AP is essentially a comment I made to a technical proposal about securing Kiez Burn services, reformulated and generalized. See that discussion (link to post here when I can find it) for some confused back-and-forth about minutiae.

## People/roles most affected by this proposal

* Robots

* Board

* Everyone

## People/roles with the most knowledge and experience relevant to this proposal:

- Me

- Robots

- Board

- Everyone

# The proposal

## Background

There are two parallel situations currently obstructing getting shit done with computers:

### 1. Gatekeeping

Access to almost everything things are held tightly by people who are not realizing anything.

Contents on Google Drive is nowhere to be found, seemingly nobody has access to fix the website when it's down, two Discords(!!) are created and remain unmoderated, and so on. When access is granted it's often too low to be effective, leading to more rounds of asking for access.

### 2. Abuse

There have been recent incidents of people locking each other out, deleting data. I'm not going to rehash that here, but a secondary goal of this AP is to handle that.

## The proposal

Adopt clear principles and procedures when it comes to information management.

### The Principles

1. Default Open

2. Empower Doers

3. A reasonable time to recovery

Being transparent makes it easy for people to participate. We should default to most of our tools being open to examination and participation.

The time from expressing the want to do something to actually doing it should be a short as possible.

If shit goes sideways, it shouldn't take us weeks to get back up and running again.

## How would the proposal be implemented

### Set strict requirements for services not managed by us

Even with stuff we manage ourselves, like the ticketing platform or Talk, it's in the end always running on something we do not directly operate.

These services must be required to fulfill, at minimum, these criteria:

* Multiple user accounts

* No "admin@kiezburn.org" accounts. No shared accounts. Each user must be able to log in as their own user.

* Role Based Authorization

* Access to a resource is granted and revoked by giving a user a role. These roles will reflect what the user is currently doing.

* Clear path to recovery

* We should be able to get all our data off the platform.

### Define clear security boundaries and policies

Each service or component of a service should have a clearly defined security boundary. That is, each service should fit into either of these levels, with attached policies:

#### 1. Administrative secure access

Potentially permanently destructive, or otherwise time consuming to fix.

This applies to as far as I know two things:

* The DNS registrar

* Backups

This should be reserved to a couple of trusted people.

#### 2. Sensitive Information

Very little of what we store is sensitive. There's Personally Identifiable Information in:

* The ticketing system

* A couple of documents on Google Drive

Access should only be given for the time it's needed to the people that need it.

This level is also infectious: some roles on the cloud provider will have direct access to the ticketing database, and the same restrictions should apply.

#### 3. Potentially temporarily destructive

This is basically all "admin" levels of access. For instance if I'm an admin on Talk I can delete all your posts. It's fortunately easy to recover from. In other words, the risk is worth it.

It should be:

* Given on an as needed basis

* Quick to allocate without much hassle

* Periodically reviewed (for instance yearly, as roles rotate in the first quarter)

#### 4. Everything else

Full access as much as possible. Writing a Google Doc about toilets? Go ahead and put it in a folder with everything else, and let everyone edit. There's a button to scroll through the history if someone dickbutts it.

## Who would implement this proposal

Security is an ongoing process, and we'd phase things out rather than do a big-bang migration.

It's done by everyone who manages information, Robots first perhaps, but most of this is done by "non-technical" realizers.

## When would this proposal be implemented

This would inform the next things I do (or if I do them) straight away.

## What would be the cost (time, money, effort, etc.) of this proposal

This might cost more, and we can afford it. A lot of services in use at the moment seem to be chosen because they have a "free" tier or similar. As we have new criteria for selection we might end up picking services that cost a little more, but it's going to be well worth it.

## What are the advantages of this proposal (relative to the current situation and/or counter-proposals)

This is how you do civic responsibility I guess, and it will enable us to move better.

## What are the disadvantages of this proposal (relative to the current situation and/or counter-proposals)

Someone needs to make sure our backups work, and that's hard.

# Decision

Doin' it! This is all on the robotic roadmap, will move this to a living document in the future.