Incident Response Permissions (DRAFT)

Terms

System Admin - Mattermost server system admin. Full control and visibility over all incidents.

Incident Commander - The current designated commander of the incident.

Incident Participant - A user that is considered to be an active participant in the incident that needs to make changes to the incident.

Incident Observer - A user with an interest in the incident but does not need to make changes.

Others - Other users on the MM server.

Incident Channel - The primary channel assigned to the incident.

Channel Based Incident Permissions

Channel based permissions uses the primary Mattermost channel assigned to the incident as a proxy for access to the incident.

From the users' perspective there are two kinds of incidents. Public incidents, where the incident channel is created as a public channel, and private incidents where the incident channel is created as a private channel. Users are given the option of which team the primary channel is created in at creation time (defaulting to the current team that user is viewing) so there is no confusion.

In this system incidents are directly tied to a specific team and channel.

This can be implemented with existing permissions constructs without requiring extension of the Mattermost server. Further extension is talked about below.

Public Incidents

Public incidents are incidents where anyone with access to the team the incident channel is created on can join the incident as a participant by joining the channel the incident is in. Anyone on the team can join the primary channel and become an incident participant. Just like public channels, public incidents appear for everyone in the team they are created in.

Private Incidents

Private incidents are invite only. Incident participants can be added by inviting them to the incidents primary channel. Like private channels, private incidents do not appear on the incident list of users who are not participants.

Creation

When an incident is created the appropriate channel type is created on the team selected and the creator becomes the incident commander. This user is made the admin of the created channel.

Grid

	System + Team Admins	In Channel	In Team, Public Incident	In Team, Private Incident	Not in Team
See incident in lists	Yes	Yes	Yes	No	No
Join Incident	Yes		Yes	No	No
View checklist items	Yes	Yes	Yes	No	No
Modify Incident Properties	Yes	Yes	No (until you join)	No	No

Enhancement: Incident Observer

Adding incident observers to the base is simple. The rules above about public and private channels hold with the addition of two new rules.

Channel administrator → Incident Participant

Channel administrators in the incident channel become the incident participants. They are allowed full read-write access to modify channel properties as normal, but also to modify properties of the incident such as checking checklists.

Channel member → Incident Observer

Regular channel members in the incident channel become incident observers. They are able to interact with the channel normally, however they are unable to modify properties of the incident such as checking checklist items. Note that because they are regular channel members, the new E20 channel moderation features would work normally, allowing for these channels to be marked as read-only for them.

Enable/Disable observers

This enhancement can be cumbersome as each user added to the incident that uses this feature must be added as a channel administrator to be able to edit the incident.

Enhance MM UI

One option is to enhance the MM UI with the ability to specify if you want to add them as a participant or observer. We could add hooks to give plugins the ability to modify the add users dialog to have two buttons for add as participant and add as observer. We would also add a slash command specifically for adding to incidents with these options.

Provide as an option for every incident

Allow the commander to determine if this feature is enabled or disabled for every incident. Something like “Enable Incident Observers”

Grid

	System + Team Admins	Incident Participant	Incident Observer	In Team, Public Incident	In Team, Private Incident	Not in Team
See incident in lists	Yes	Yes	Yes	Yes	No	No
Join Incident	Yes			Yes	No	No
View checklist items	Yes	Yes	Yes	Yes	No	No
Modify Incident Properties	Yes	Yes	No	No	No	No

Playbook Permissions

Playbook permissions can follow a similar model as incident permissions. When a playbook is created, a channel is created with the playbook name on a specified team. Anyone with access to that channel can edit the playbook. The channel can be a public or private as above. This encourages orderly discussion about the playbook and allows for features like linking back the channel every time the playbook is used.

In addition you can also create a “draft” playbook that only the author can access that has no channel attached. Later the draft can be published for others to use.

Analytics Permissions

A class of users that may be a target is users that want to analyze statistics on incidents without necessarily having permissions to see the details of those incidents in the channels.

This would be implemented as a global or team based list of users. These users would be able to view some overview information on every incident on the server along with bulk statistics.

Advanced Permissions (Extending ABAC)

Enterprise team is currently developing a new permissions model for the Mattermost server. The latest draft of this design can be found here: https://gist.github.com/mkraft/b3469299204c1d766eebe08c28f3ce27

It would be an inefficient use of time to deeply integrate with the current permissions system while the new one is under development.

The advantages given by using the new ABAC system are extreme flexibility and convenient implementation. See that proposal for more details.

Extending the ABAC proposal will involve providing a number of components:

Default policies (rego files)
Data for the policy agent to act on. Such as the primary incident channel and who are the commanders.
Registration of “operations” and “resources”

Plugin API Additions

Some very draft ideas of what extensions to the new ABAC system might look like. Terminology surrounding ABAC is still in development.

addDefaultPolicy(regofile string) error Adds the plugin’s default policy to the MM server’s default policy. Alternatively this may be added to the plugin manifest.

setPolicyAgentData(data interface{}) error Adds plugin specific data for the policy agent to act on. For example the list of incidents with details like state and commander.

setOperations(op []model.Operation) error adds possible operations that could be performed on resources provided by the plugin. For example the MM server might provide read and write but not end_incident. Not required for use by rego files, may be required for UI extension.

setResources(op []model.Resource) error adds resources that the plugin provides. In incident responce case it might be things like incidents and playbooks. Not required for use by rego files, may be required for UI extension.

Example policy

https://play.openpolicyagent.org/p/BgXLUOlcBN

package app.abac

default allow = false

allow {
	user_is_commander
}

user_is_commander {
	data.incident_attributes[input.resource].commander = input.user
}

action_is_read {
	input.action == "read"
}

action_is_write {
	input.action == "write"
}

Data:

{
    "user_attributes": {
        "alice": {
            "title": "owner"
        },
        "bob": {
            "title": "employee"
        }
    },
    "incident_attributes": {
        "myincident": {
            "commander": "bob",
            "channel": "channel1"
        }
    }
}