(Closed) Information Security Principles for Kiez Burn
## Proposer (name, handle, etc.):
## 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
## People/roles with the most knowledge and experience relevant to this proposal:
# The proposal
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 "firstname.lastname@example.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
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.
Doin' it! This is all on the robotic roadmap, will move this to a living document in the future.
Alex Kaos Sat 26 Feb 2022 5:53PM
Most of these criteria are already in place, but not managed. There are google groups giving role-based access to the drive (which is in it's own disarray). Talkt to @Jan-Christian Kaspareit who I believe has the controls for that feature.
We only have a handful of services, the newsletter being the only one that needs more access imo, which does have multiple log-ins, but must be handed out carefully for GDPR purposes.
@Henrik 🤖 is implementing the password security network, of which some of these topics are addressed.
CJ Yetman Sun 27 Feb 2022 10:46AM
I think most of these principles are in place, in principle. Particularly the Google Drive got much less than "default open" due to someone in particular making rather sweeping changes with little oversight. It used to be that the Kiez Burn general organization folder was world readable, and only certain files we're shared only on a need-to-know basis.
While the event is run as a "do-ocracy", the verein is a legal entity that is not, and the verein should likely have primary control over some of these things, like the domain registrar.
Veroca R. Sala Tue 1 Mar 2022 9:08AM
so I basically have to say about this, the same as Caro T has said. There is a system already thought through, I cant translate all that here now, but basically, there will be a few people in power of the passwords: the president, a robot minister, and two board members vault. This way either the board member or the robot minister can be contacted and they could give access.
The google groups, should be ( IMO) be deactivated and all documents open to anyone except for the ones that contain data and for a limited time ( not for eternity).
The Gdrive is messy indeed, I have put some time mapping the current google drive, to spot where files are located and where is the "data" stored (it is not finished thou) https://docs.google.com/spreadsheets/d/1HpXnbHllDvfEiVN0za6Un6xUL3Z0gSS9Aq8RSOG8PSk/edit?usp=sharing
note: the board doesnt have free access to edit and move folders and documents within the kb drive because all documents have their own "owner" ( realizers, participants).
I think it would be nicer, clearer, and more rewarding to do a workshop day and work together on to implement improvements. I happily attend.
Saskia Tue 29 Mar 2022 8:08AM
Passwords have been shared via a password manager back ‘in my days’- that meant I didn’t see the Passwort, it was stored in my vault but I couldn’t read it. That way I had access to the drive without knowing the password and I could / and was / kicked out of the manager.
Idk if that’s valuable information on how we shared the passwords. But it read like we’re talking just literally sharing passwords and I don’t know of thats what it meant.
Kris Sun 3 Apr 2022 11:34PM
Ok babies, continuing my experimentation in ⭐ alternative ⭐ media ⭐, here's, like, a ... follow up to one to five of the advice processes I've started:
(Warning I'm sleep deprived and occasionally use words wrong, but I think it's kind of cute. Talk belongs in the upper left quadrant, my brain was doing a malfunction.
I also don't talk about it at all but it fits well with the principles outlined in the context here.)
Kaliope Mon 4 Apr 2022 11:26AM
I am neither for nor against, looks quite cute. Can all entries be edited only by invited & registered users or also by random people from outside? How about if we move Google Docs with sensitive data here – we still shouldn't, yes? Would you be the one to implement and move all that? I can imagine this is also a good spot for our documentation.
Kris Mon 4 Apr 2022 1:50PM
Oh yeah, go play with it. In it’s current state roles aren’t perpetuated from Discord so you have to do a little extra clicking to make groups, but imagine we can fix that easily. The access model is like gdrive: none/view/edit.
Cris Mon 11 Apr 2022 10:46AM
I love wikis!
I was just trying this out with a test (Burn Night 2019 folder) and I think it could work out great for the upgrade of the GDrive, but it needs some rethinking and, imo, that the group of people involved agree on the same methodology.
Tagging here @Kathleen Stoeckel @Mareike @Veroca R. Sala @Caro T @Professor Kaos and @walto for that reason. We are discussing in Telegram, so ping me if you, or anyone else, wants to join.
CJ Yetman Sun 27 Feb 2022 1:30PM
Not opposed to clear rules at all.
Some of those things you’ve mentioned I think are ideally managed by the Verein, not by a/the event coordinators. Others of those things were probably setup by someone on their own without any control… that’s kind of how it goes in a chaotic, “do-cratic” system. Even if those were brought under some central control, there’s nothing to prevent someone from opening yet another Discord server, or Telegram group.
Kris Sun 27 Feb 2022 12:06PM
If the principles are there in principle you’re not opposed to writing the principles down?
Again I can’t say much about drive since I don’t have access to it it.
I don’t care that much about the Verein, that’s basically general assemblies and membership rolls. I’m talking about the other stuff and how we are failing at “doocracy” because we’re not enabling people to do.
Kris Sat 26 Feb 2022 8:09PM
I know nothing about how drive is implemented, because I have access to absolutely zilch of it. So can't really comment on that one, but I do see it as an issue that the history of a lot of previous events is effectively unavailable for most people.
Zoho is a good example of another one that's a mess. Namecheap as well should be better organised as it crosses boundaries. A through survey would be the next step if we want things to get in alignment.
This proposal does not align with the password security thing. It goes against any kind of shared accounts.
Kris Sun 27 Feb 2022 12:48PM
I think you might have a narrow view then, because there's Mailchimp, Zoho, Hetzner, Pretix, Fly, Discord, Namecheap, and probably a few others I can't think of. Also when deploying new things it helps to have clear rules.
Kris Sun 27 Feb 2022 4:49PM
Who is the Verein? It is its membership, which includes amongst others you and I.
Just to be clear, the reason I'm bringing this up is that it's really hard for me to get shit done quite often.
If the Verein should manage something it is the name Kiez Burn, so no, I disagree, the Verein should step in if someone makes another Discord. The individual people having access to the services using the name, and that the Verein rely on, should enable the rest of the Verein to use them.
CJ Yetman Sun 27 Feb 2022 7:18PM
What I'm saying is, I don't think it would make sense that any random person on Talk and/or ostensibly working on an event should be able to demand administrative access to any of the critical tech services. Neither do I think it makes sense to decide who should or should not have admin access to them on Talk/in an AP. Neither do I think it makes sense to call a General Assembly so that we (yes, assuming we're both actual Verein members) can make that decision. So, the Board, which acts on behalf of the Verein, should probably make some sensitive decisions about/like that.
Cris Mon 28 Feb 2022 7:58PM
Indeed, the whole Google Drive was per default open for everyone (with little exceptions) for the reasons you list up here. Right now, those google groups set in place last year are role-managing it, but since no one is apparently managing those Google Groups, most files are unavailable for almost everyone. These Google groups were set in place unilaterally.
CJ Yetman Sun 27 Feb 2022 12:10PM
I guess the point is, there's not much to "do" here other than get the Google Drive back under control.
Kris Sat 26 Feb 2022 8:14PM
These are principles and not so much of a plan that needs a time-frame, we'd it would be up to each group that services these to figure out how to conform to it. It is laying the groundwork so to speak, and hopefully contributing to which options to choose going forward.
Kris Sun 27 Feb 2022 7:49PM
I don’t understand what you’re saying. You want the board to be more hands on?
CJ Yetman Sun 27 Feb 2022 8:38PM
The Board is legally obliged to be hands on with matters that concern the Verein.
Kris Sun 27 Feb 2022 8:42PM
Yeah, they’re a board though, they’re not legally obliged to be the executive.
Kris Mon 21 Mar 2022 11:39AM
Then my reply is pretty much the same as to Caro:
Sharing passwords is the worst, they should be personal
I don't know how Drive is organised, but there are alternatives that fit within these principles without paying $5 per seat (which is what Gsuite costs)
Caro T · Sat 26 Feb 2022 4:55PM
GDPR, Data & Account Security, and "the messy GDrive" have been ongoing discussions for the last few months with some progress and proposals being implemented at the moment (see @Jan-Christian Kaspareit for GDPR, @Henrik 🤖 for Security, and @board for GDrive).
If we want to re-examine and reinvent from the ground up, as you suggest, we could form a Task Force, that workshops an efficient, secure and ethical proposal and can implement it. Next to the @robots and Tech-wiz burners (like yourself), it could include experienced Korgis/Realizers who have successfully used and/or struggled with the existing systems/structures as that gives you valuable UX-Design input.
My question is time-related: what's a realistic timeframe to implement your proposal?