Page MenuHomePhabricator

Spaces request for SIEM
Closed, ResolvedPublic

Description

  1. Please create space for SIEM (security information and event monitoring). The space needs to be private because it involves security work
  2. Please name the space SIEM
  3. Group lead is @dpatrick
  4. Specific Phabricator users who should be able to access objects in that space: @dpatrick, @bbogaert, and @ggellerman

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 4 2016, 6:21 PM
Krenair added a subscriber: Krenair.Nov 4 2016, 6:22 PM

How is this going to be different from Security ?

This task welcomes information where to find more info what "SIEM" is, and why these tasks need to be completely statically isolated from anyone else, instead of just restricting task access to Security members, authors, and subscribers.

Hi All,

I think it may be OK to leave under Security. @dpatrick thoughts?

More information on this project can be found here: https://office.wikimedia.org/wiki/Office_IT/Projects/SIEM_Project

Thanks,
Byron

We can't use officewiki links for such requests since officewiki is non-public

Well, in this case that's less relevant, as the Space would be non-public too (however the associated project description itself would be visible, but not its tasks if they are both in the project and the Space).

This should be separate from Security. We track vulnerability metrics using the Security tag and the tasks created for the SIEM project should not be included in those metrics. Additionally, at this point, the tag is being used to notate a specific project that requires some collaboration across teams. At this point, only Foundation employees are working on this project so it's fine to reference Office Wiki for more information.

Krenair added a comment.EditedNov 10 2016, 7:21 PM

So the information about what is private... is itself private? That seems somewhat untransparent, and I don't think we should grant such requests. As an example, the fact that the Security private tasks are set up to deal with security vulnerabilities is itself not private information, and I think we should expect the same standard for any kind of new private area to be created.

Aklapper claimed this task.Nov 16 2016, 6:33 PM
Aklapper triaged this task as Medium priority.
Aklapper moved this task from Backlog to November on the Developer-Advocacy (Oct-Dec-2016) board.
Aklapper closed this task as Resolved.Nov 16 2016, 7:56 PM
  • Regarding the project and its workboard:
  • Regarding the Space (a Space is not a project and hence there is no workboard):
    • For access control, created #acl*wmf_siem_policy_admins. This defines access to tasks in the private Space. Description says: "Policy Administrators for the private space S11 related to the public WMF-SIEM project".
    • Created the private Space S11 ("SIEM"). Its Join and Edit policy are intentionally set to #acl*wmf_siem_policy_admins and should not be changed.
    • @dpatrick can add/remove users (who can create and access tasks in S11) via editing the members of #acl*wmf_siem_policy_admins. Note that Phabricator admins could also add themselves (this is a fallback for when a team lead has left; we had that situation); if you watch #acl*wmf_siem_policy_admins project you'd get a notification about such an action.
    • Please do read Displaying and using a Space for more information. For example, when creating private tasks in that Space you must choose "Visible To: Space S11: Siem" in the task creation form to create private tasks only accessible to members of S11 and nobody else.
  • For convenience, created Herald Rule H205: If Space is set to S11, add project: WMF-SIEM.
  • Documented the creation of S11 on https://www.mediawiki.org/wiki/Phabricator/Spaces .
  • Please ask if things are unclear.
Qgil awarded a token.Nov 16 2016, 9:44 PM

@Aklapper, why did you grant this without addressing my concern?

@Krenair: Because minor problems like a description that can be improved do not block the creation of projects and because I am not the one to address your concern. The WMF-SIEM project is public and it has a public description that can be improved if more public info is wanted.

Krenair added a comment.EditedNov 17 2016, 11:18 AM

No, that problem needs to be sorted before project/space creation so we can discuss whether to grant a new private space or not. Right now this does not adequately describe the difference between this and Security. You do need to address it if you want to create it.

IMO the fact that a difference exists was addressed sufficiently in T150046#2786656. Describing the difference can still be done by editing the project description (space requesters are encouraged to do so) which does not block project or space creation as per guidelines.

That comment is nowhere near sufficient for this kind of thing, it doesn't describe the scope of contained tasks. ACL projects/spaces need serious community discussion, you just did this single-handedly without even addressing my concern beforehand, let alone solving it and waiting for any other comments. This needs to be closed down again until it is done properly.

That comment is nowhere near sufficient for this kind of thing, it doesn't describe the scope of contained tasks.

I am sure one of the Space members are happy to edit the description of the public project if a need for more info is seen.

ACL projects/spaces need serious community discussion

You are always welcome to encourage that discussion - I cannot enforce it though.

I don't see a "need" or even much sense in a "community discussion" whether parts of the Ukrainian chapter can have a private Space to handle their internal affairs, or whether parts of the WMF can have a private space to handle internal security information and internal event monitoring, or whether parts of $entity involved in the movement can have a private space to handle internal $stuff.

you just did this single-handedly

Indeed, after having this request lingering in public for nearly two weeks while everyone had the chance to take a look and provide feedback. At some point it's time to act on requests.

without even addressing my concern beforehand

As already explained, there was no need to address your concern beforehand, as per guidelines.

@Aklapper
Many thanks for your help! The SIEM project meets again tomorrow after a 2 week hiatus, so we'll discuss this in that meeting.

Krenair added a comment.EditedNov 22 2016, 11:43 PM

That comment is nowhere near sufficient for this kind of thing, it doesn't describe the scope of contained tasks.

I am sure one of the Space members are happy to edit the description of the public project if a need for more info is seen.

My point is this should be done *before* any private space is granted. The standards shown here are well below what I'd expect for a transparent, community-driven process.

ACL projects/spaces need serious community discussion

You are always welcome to encourage that discussion - I cannot enforce it though.

You can though. You can say you won't grant such a space without one. If need be we can amend the guidelines to explicitly require full community consensus for such a thing, but honestly we really shouldn't need to be having this conversation.

I don't see a "need" or even much sense in a "community discussion" whether parts of the Ukrainian chapter can have a private Space to handle their internal affairs, or whether parts of the WMF can have a private space to handle internal security information and internal event monitoring, or whether parts of $entity involved in the movement can have a private space to handle internal $stuff.

It would matter a lot less if members of private spaces didn't have the ability to steal tasks out of the public space without a trace. As it is, we need some serious scope pre-determined and the ability to enforce that.

without even addressing my concern beforehand

As already explained, there was no need to address your concern beforehand, as per guidelines.

I don't think we need to write into the guidelines that outstanding serious concerns must be addressed. If admins aren't dealing with that we should be revoking their flags.

Aklapper added a comment.EditedNov 23 2016, 9:45 AM

My point is this should be done *before* any private space is granted.

I don't agree.
(Edit: Well, I can agree on "should". Which is not "must". And has been explained various times in this task now already.)

I don't think we need to write into the guidelines that outstanding serious concerns must be addressed.

There was no outstanding serious concern.

My point is this should be done *before* any private space is granted.

I don't agree.
(Edit: Well, I can agree on "should". Which is not "must". And has been explained various times in this task now already.)

You agree on *should*, so why did you create it without that?

I don't think we need to write into the guidelines that outstanding serious concerns must be addressed.

There was no outstanding serious concern.

I said "I don't think we should grant such requests"...

Aklapper removed a subscriber: Aklapper.Nov 23 2016, 1:43 PM

I'm not sure how to phrase "should". Which is not "must". any clearer.
This task does not feel like a good use of my time. I've explained my views more than once, so I'm leaving this conversation.