Bugzilla – Full Text Bug Listing
| Summary: | [Security] Establish a Security Team | ||
|---|---|---|---|
| Product: | Community | Reporter: | Wayne Beaton <wayne.beaton> |
| Component: | Architecture Council | Assignee: | eclipse.org-architecture-council |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | caniszczyk, david_williams, d_a_carver, jesse.mcconnell, neil.hauge, pwebster, remy.suen, tjwatson, werner.keil |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| URL: | http://wiki.eclipse.org/Drafts/Security_Policy#Eclipse_Security_Team | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 337004, 337005 | ||
|
Description
Wayne Beaton
>Do we provide a mechanism for adding additional people to the Security Team?
>(e.g. subject matter experts)
Sounds like a good idea.
(In reply to comment #0) > To make a security policy meaningful, we need a team of people who are > concerned with security issues. These people many not necessarily have all the > answers, but they can provide triage, liason, and other services. > > I propose that the "Eclipse Security Team" include the Webmaster, Director of > Open Source Projects (i.e. me), and at least one representative from each PMC. > What is your thought process around having one rep from each PMC? Is it more about work distribution or knowledge transfer, or perhaps some of both? Upon adding a few subject matter experts this team is around 20 people, which may be fine, but is getting on the big side. > The security team can be contacted via the security@eclipse.org address. > Anybody can send email to this address, but only members of the Security Team > can receive messages. All members of the team will receive the email. The email > will *not* be encrypted (this is true of the security address for Bugzilla and > Apache). We will provide a guarantee of response within three business days. I > expect that the back-and-forth discussion on issues reported via this address > will be relatively short and result in the creation of a bug. In some cases, > the security address may be included in the cc for bugs. > > Does this make sense? Sounds reasonable to me. > > Do we provide a mechanism for adding additional people to the Security Team? > (e.g. subject matter experts) +1 > a Security Team in place will--at a minimum--provide a valuable channel for > communication of vulnerabilities within the project structure. Can anybody see > a flaw in my logic? I think the concept of having a team is a very good idea. +1 (In reply to comment #2) > What is your thought process around having one rep from each PMC? Is it more > about work distribution or knowledge transfer, or perhaps some of both? Upon > adding a few subject matter experts this team is around 20 people, which may be > fine, but is getting on the big side. The main idea is communication and awareness. A vulnerability reported in an RT project, for example, has downstream implications: consuming projects may be impacted and establishing awareness early is--IMHO--a good thing. I envision this to be a small team. 20 is way too many. I like the idea of assembling the team to tow the line and back up the security@eclipse.org address...however I don't particularly like the breakdown of one person per PMC, and I don't see how having one person from each pmc is going to really going to help resolution here. I'll add this as an agenda topic for the next rt-pmc call to discuss with the group before I go off half-cocked here though :) cheers (In reply to comment #4) > I like the idea of assembling the team to tow the line and back up the > security@eclipse.org address...however I don't particularly like the breakdown > of one person per PMC, and I don't see how having one person from each pmc is > going to really going to help resolution here. I'll add this as an agenda > topic for the next rt-pmc call to discuss with the group before I go off > half-cocked here though :) FWIW, this is my starting point. I am open to feedback. Another reason for having representation from each PMC is that it will help identify the projects that own the issue. I don't see this body as necessarily being the ones who provide the actual resolution. In some cases, the representative to the Security Group may well be the one who does the actual work. But I envision this group's responsibilities being that of triaging the request, opening bugs, assembling experts, and making sure that progress is made. (In reply to comment #5) > (In reply to comment #4) > > I like the idea of assembling the team to tow the line and back up the > > security@eclipse.org address...however I don't particularly like the breakdown > > of one person per PMC, and I don't see how having one person from each pmc is > > going to really going to help resolution here. I'll add this as an agenda > > topic for the next rt-pmc call to discuss with the group before I go off > > half-cocked here though :) > > FWIW, this is my starting point. I am open to feedback. > > Another reason for having representation from each PMC is that it will help > identify the projects that own the issue. > > I don't see this body as necessarily being the ones who provide the actual > resolution. In some cases, the representative to the Security Group may well be > the one who does the actual work. But I envision this group's responsibilities > being that of triaging the request, opening bugs, assembling experts, and > making sure that progress is made. Just curious, doesn't this type of thing just fall naturally under the Architecture Council's responsibility? You already have PMC reps required to be on the AC anyways. (In reply to comment #6) > Just curious, doesn't this type of thing just fall naturally under the > Architecture Council's responsibility? You already have PMC reps required to > be on the AC anyways. Seems like a good responsibility for the existing members on the AC imho. I think it makes some sense to have a dedicated, but small, team in place. Maybe ask for 3 to 5 volunteers who have security expertise ... making sure "runtime" and "platform" teams have participants (under the assumption they'd have the most vulnerability, and most impact on avoiding problems?). The reason for suggesting the dedicated team, is that sometimes (if I understand your purpose for this team) is that a security issue or vulnerability should be known/discussed by a very small group of very trusted people ... until the issue is understood or fixed. This team could "pull in" others as needed for specific issues. And, of course, when it comes to "general eduction", then I think the small team could work through the architecture council to distribute the information. And, maybe, if there were "in between" cases, the small team could just work with PMC leads via email (instead of having dedicated PMC rep) ... such as "we've found this one vulnerability that is/will be fixed ... but could you get someone to see if your code has a similar problem before we make the information public". [And, btw, I'm not saying the architecture council is not "trusted" ... just there are a lot of us and there's an automatic insecurity in large numbers ... and no particular "private" communication channel for sensitive issues]. Just suggestions ... no answers :) And if I've misunderstood what this Security Team is for or what they'd do, then ... nevermind :) +1(In reply to comment #8) > I think it makes some sense to have a dedicated, but small, team in place. Maybe > ask for 3 to 5 volunteers who have security expertise ... making sure "runtime" > and "platform" teams have participants (under the assumption they'd have the > most vulnerability, and most impact on avoiding problems?). +1 We'll have to see how the RT and Eclipse PMCs feel about this :-) > The reason for suggesting the dedicated team, is that sometimes (if I understand > your purpose for this team) is that a security issue or vulnerability should be > known/discussed by a very small group of very trusted people ... until the issue > is understood or fixed. This team could "pull in" others as needed for specific > issues. And, of course, when it comes to "general eduction", then I think the > small team could work through the architecture council to distribute the > information. And, maybe, if there were "in between" cases, the small team could > just work with PMC leads via email (instead of having dedicated PMC rep) ... > such as "we've found this one vulnerability that is/will be fixed ... but could > you get someone to see if your code has a similar problem before we make the > information public". +1 I think that "small team" is important. If we do need involvement from the other PMCs, we can contact them easily enough. I feel that it's important that an Eclipse Foundation staff member be on the Security team to be a liaison between the team and the Foundation to help with things like priorized CQs (Bug 342608) for example. Any thoughts on how we might select that initial group of 3-5? Any volunteers? (In reply to comment #9) > Any thoughts on how we might select that initial group of 3-5? Any volunteers? Email the architecture council and ask. (In reply to comment #10) > (In reply to comment #9) > > Any thoughts on how we might select that initial group of 3-5? Any volunteers? > > Email the architecture council and ask. This bug is assigned to eclipse.org-architecture-council@eclipse.org I'm pretty sure that I did just ask. :-) I volunteer, representing the Eclipse top-level project. Our help component often deals with security issues. Someone else from RT would certainly be helpful - Jetty for example is a big source of issues. (In reply to comment #12) > Someone else from RT would certainly be > helpful - Jetty for example is a big source of issues. That was a poor choice of words - I didn't mean to imply Jetty has a bad security record. I just meant that, being a web server, it has a good chance of being involved in security problems from time to time. I know the Jetty team has also been helpful in tracking down security problems related to equinox servlet bridge so their expertise in this area would be valuable. thanks, and this is on the agenda for next weeks rt-pmc call where we will try and hammer out some sort of representation...off the top of my head I would think one equinox person and one jetty person, perhaps a virgo/gemini....anyway, its on the agenda cheers I've updated the draft Security Policy document to reflect David's comments. http://wiki.eclipse.org/Drafts/Security_Policy#Eclipse_Security_Team I decided to pick an arbitrary maximum of seven members. I think the role of the Architecture Council suggested by David is a good one. I'm not sure if it needs to be codified. Does anybody have a different opinion? we discussed on the rt pmc call and for the time being it looks like I'll be on the email list representing the rt group and we'll play it by ear on whether we attempt to increase the RT presence or not based on what sort of things crop up on the list. cheers The concept of a Security Team has been established [1]. I have created a relationship in the Foundation database for this and have assigned that relationship to Jesse, John, and myself. I have asked Webmaster to join as well. Anybody else? [1] http://www.eclipse.org/security/policy.php Security team is established. Marking as FIXED. |