Pavel Kankovsky wrote:
On Tue, 16 Jan 2007, Josh Bressers wrote:
Initially, we're going to ignore embargoed issues. Every time a security
conversation comes up, people start creating overly complex processes to
handle them. Once there is a concrete team and process, this can be
investigated. In the meantime, we'll just deal with issues once they're
public.
The process is quite straightforward imho:
1. Data acquisition
- keep track of vulnerabilities
- CVE (a good start but it should not be the only source of data)
- vulnerability databases (Bugtraq, OSVDB, Secunia...)
- mailing lists (Bugtraq, Full-disclosure, Vendor-sec...)
- other distros (they might have caught something we missed)
- Oval?
- weed out bogus reports (false reports, issues for MS Windows...)
- merge duplicate reports
- update existing reports when needed (exploit availability...)
2. Triage
- assess new and updated reports
- eliminate irrelevant reports (package not included in distro...)
- assign score to relevant reports (see below)
- reassess reports considered irrelevant when they become relevant
(new package added to distro...)
- prioritize reports according to their score
3. Remediation
- select a report/issue to work on
- find or develop patches
- check whether the patches fix the vulnerabilities
- deploy fixed packages
It has been awhile since I have done much here. Got lots of questions.
My concern here is how does someone new to this process come about
fairly easily and quickly knowing the status of any given vulnerability?
And how does someone know where to pitch in?
How many security issues might we have that could be open at the same time?
In order for any kind of orderly work to get done, a diverse and
geographically-spread team would need to know what area of work needs
the most work, and how to find out what issues are ones that they can
work on, plus some way of flagging issues so someone else five minutes
later signing on the the system to do some work won't start working on
the very same thing (avoiding duplication of effort, if possible).
If we have, for example, people identifying issues -- how do we make it
so a team of three identifiers don't identify the same issue three
times? (Or is that not a problem?) Do we have a quick 'n dirty way of
telling Joe Blow, a fellow scanning the Internet for vulnerabilities,
that CVE-2007-yyyy is already in the database and needs triage (which I
assume means "prioritization" = do we worry about this flaw today,
tomorrow, or next Wednesday)? Or of telling John Q. Public that
CVE-2007-xxxx has been triaged and now needs patches to be found and
published somewhere for Jim-Billy Bobb to go into the package CVS and
build a new package? How do we know when who does what and who has
access to which information where to get work done?
And how does the QA process fit in with all of this? Er, do we have
some kind of package QA process for security vulnerabilities? Would
community members be welcome to pitch in on this if there is a QA
process in place?
A good start might be a breakdown for those of us here who don't know --
who *now* does what for Core packages and for extras packages? What
does a security issue look like walked through the entire process, from
identifying the vulnerability to the release of a fixed package? What
does the process *now* look like and how do Red Hat people envision
opening up the process to let others in? How is information going to be
shared outside of the Security Response Team so it will be able to be
efficiently known about by your community contributors (excluding
embargoed issues, of course, for now)? And are embargoed issues for
former core packages now going to be ignored until the embargo is
lifted, or are they going to be able to be worked on by trusted
individuals inside Red Hat while embargoed, just as they are now?
If today I wanted to start being a security bug watcher, where do I
report them? Bugzilla? Or is there a person or a group of people that
already does this as a paid job inside of Red Hat?
Does the Fedora Security Team maintain a database (or "flat file")
stored out in a Fedora CVS server somewhere that indicates status of any
given CVE issue? If it is there, is the "how to use it" documented
anywhere? Is manipulating this flat file the best way to get security
bugs "into the system" for review?
If there are things that people know tacitly how to do, I would be more
than happy to help document current processes.
Is there any estimate of an ideal level of manpower doing things? And
what levels of expertise are needed for each of the security tasks,
especially when dealing with former Core packages by community members?
Thanks.
-David
--
Fedora-security-list mailing list
Fedora-security-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-security-list
