Project

General

Profile

Feature #16893

Move security policies to summit.git

Added by sajolida 5 months ago. Updated 19 days ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
Due date:
% Done:

0%

Feature Branch:
summit.git:contrib/16893-document-security-policies
Type of work:
Accounting
Blueprint:
Starter:
Affected tool:
Handbook

Description

Different teams have different security policies.

Right now they are each stored in the repo of each team.

This is slightly painful and opaque since:

  • Information is duplicated. Security policies are slightly different from one another.
  • Someone checking the compliance can't know what people are checking against. It's possible but feels weird.
  • There's no list of teams who have a security policy.
  • There's no possibility of some from outside of team to review the security policy of a team.

Why don't we move all security policies in summit.git? Everybody who has to follow such a policy would already have access to summit.git.

History

#1 Updated by intrigeri 5 months ago

  • Status changed from New to Confirmed

This makes lots of sense to me.

#2 Updated by sajolida 5 months ago

  • Type of work changed from Contributors documentation to Accounting

Setting "Type of work: Accounting", so it's listed together with other tickets related to the Handbook until we have #16908.

#4 Updated by sajolida 4 months ago

  • Affected tool set to Handbook

#5 Updated by muri about 1 month ago

I have asked all the teams to comment their concerns on this ticket 4 month ago. There have been no comments, so I think we can proceed with this.

#6 Updated by sajolida about 1 month ago

+1!

#7 Updated by sajolida 28 days ago

  • Status changed from Confirmed to Needs Validation
  • Assignee set to intrigeri
  • Feature Branch set to summit.git:contrib/16893-document-security-policies

Here is a branch, please have a look.

I'm missing the security policy from:

  • Foundations Team
  • Release Managers
  • Sysadmins
  • Translation Platform Maintainers

If they fit easily in one of the 3 levels that I've already defined. Please fix this in Teams.mdwn. Otherwise send me their security policies and I'll integrate them somehow :)

#8 Updated by sajolida 28 days ago

  • Target version set to Tails_4.1

#9 Updated by sajolida 28 days ago

Once the branch is merged in summit.git, I should also track the removal of the security policy from each of the team's repos.

#10 Updated by intrigeri 28 days ago

Here is a branch, please have a look.

Thanks.

I'm missing the security policy from:

  • Foundations Team

This team has no security policy.

But every current individual member of the FT is allowed to push stuff to Jenkins, so they had to report compliance with our "arbitrary code execution on our infra" security policy. Same for kurono. I've sent details about all this to muri a week or 2 ago.

  • Release Managers

Same policy as accounting and commit bit (is that one missing?).

  • Sysadmins

Meanwhile, my sysadmin team-mates have expressed they would like further discussion before moving the sysadmin team's security policy to summit.git.
I've asked them if the concern is about the text of said policy being there at all, or whether it's about the info "this policy is the one that applies to the sysadmin team".
I expect we'll discuss this at the sysadmin team meeting on Wednesday.
I'll wait for this to happen until I review this, because it affects the rest of the branch too :/

  • Translation Platform Maintainers

This team does not exist yet. Members will have to comply at least with the "arbitrary code execution on our infra" security policy. At this point I have no idea if further requirements will be set.

#11 Updated by sajolida 28 days ago

In c8c1631 I added a revision of internal.git:security-levels.fodg.

Please have a look as well.

I removed some bubbles that I think did't make sense anymore:

  • Split between "Wizards" and ""
  • Rsync server: RM have access to "Core repos" anyway
  • misc.lizard
  • Redmine: which included "private tickets" (as per security-levels.mdwn)

I'm not sure whether the companion document security-levels.mdwn is worth being kept at all.

#12 Updated by sajolida 28 days ago

  • Foundations Team

This team has no security policy.

But every current individual member of the FT is allowed to push stuff to Jenkins, so they had to report compliance with our "arbitrary code execution on our infra" security policy. Same for kurono. I've sent details about all this to muri a week or 2 ago.

What do you mean by the security policy for "arbitrary code execution on
our infra"? Is it the section "To protect yourself from remote exploits
and malware" or anything else?

  • Release Managers

Same policy as accounting and commit bit (is that one missing?).

I'm not sure either what you mean by the policy for the commit bit.

I'll wait for this to happen until I review this, because it affects the rest of the branch too :/

Ok.

This team does not exist yet. Members will have to comply at least with the "arbitrary code execution on our infra" security policy. At this point I have no idea if further requirements will be set.

Ok.

#13 Updated by intrigeri 28 days ago

What do you mean by the security policy for "arbitrary code execution on our infra"? Is it the section "To protect yourself from remote exploits and malware" or anything else?

It's something else. I believe you had to report compliance about it a few months ago (because you maintain Limesurvey). I'll send you a copy of that document privately right away.

  • Release Managers

Same policy as accounting and commit bit (is that one missing?).

I'm not sure either what you mean by the policy for the commit bit.

"commit bit" means "core repos" in the terminology from processes/security-levels.fodg. So these folks are subject to the same level of security policy as accounting and sysadmin.

#14 Updated by sajolida 26 days ago

I believe you had to report compliance about it a few months ago (because you maintain Limesurvey).

Now I remember! Documented in

"commit bit" means "core repos" in the terminology from processes/security-levels.fodg.

Ok, documented in bb710d3.

Please review again as of 864b84d.

#15 Updated by intrigeri 24 days ago

intrigeri wrote:

Meanwhile, my sysadmin team-mates have expressed they would like further discussion before moving the sysadmin team's security policy to summit.git.
I've asked them if the concern is about the text of said policy being there at all, or whether it's about the info "this policy is the one that applies to the sysadmin team".
I expect we'll discuss this at the sysadmin team meeting on Wednesday.
I'll wait for this to happen until I review this, because it affects the rest of the branch too :/

The sysadmin team agreed that we can move its security policy and sysadmin.git:processes/security_policies/code_exec/ to summit.git.

#16 Updated by intrigeri 24 days ago

  • Assignee changed from intrigeri to sajolida

In c8c1631 I added a revision of internal.git:security-levels.fodg.

LGTM. FTR this commit lives in summit.git.

I'm not sure whether the companion document security-levels.mdwn is worth being kept at all.

I would say the info in there is too scarce and outdated to be really useful. If/when we'll ever need this, it may be faster to start from scratch. Worst case, it'll still be in the Git history.

I've reviewed your work, looks good! I've merged and pushed a few fixes on top, please review them and then I guess we're done here :)

#17 Updated by sajolida 19 days ago

  • Status changed from Needs Validation to Resolved
  • Assignee deleted (sajolida)

All good!

Also available in: Atom PDF