Differences between revisions 1 and 2
Revision 1 as of 2007-03-10 14:24:59
Size: 2913
Comment: Included full description
Revision 2 as of 2007-03-10 14:54:55
Size: 4682
Comment: Move around and added some more info
Deletions are marked like this. Additions are marked like this.
Line 8: Line 8:
  * GUI development knowledge (for the server), can be GTK or PHP based   * GUI development knowledge (for the monitor station) can be GTK or PHP based
Line 12: Line 12:
The goal of this project would be the development of a mechanism to manage the security updateness status of clusters of Debian systems. Although there are a host of tools to check for the availability of security updates locally (such as update-notifier, integrated with the GNOME desktop, or cron-apt, more info available in the [http://www.debian.org/doc/manuals/securing-debian-howto/ch10.en.html#s-keep-secure Securing Debian Manual]), there is no easy way to manage tens or hundreds of systems. The goal of this project would be the development of a mechanism to manage the security status of clusters of Debian systems. Although there are a host of tools to check for the availability of security updates locally (such as update-notifier, integrated with the GNOME desktop, or cron-apt, more info available in the [http://www.debian.org/doc/manuals/securing-debian-howto/ch10.en.html#s-keep-secure Securing Debian Manual]), there is no easy way to manage tens or hundreds of systems.   Also, the tools currently available require all systems to access the Internet (or a mirror server) which makes their deployment more difficult for systems which are not connected to the Internet, or have a restricted or limited connection (which is common for systems deployed inside companies and some organizations)

Moreover, most desktop oriented security update notifiers focus on stable systems, and are not applicable to "testing" or "sid" systems.
Line 16: Line 20:
Once done, the developer should work in a mechanism to automaticaly generate OVAL queries from the Debian Security Advisories published (there is already a beta version of that tool in the project's website, but it is not yet deployed). That would make it possible to provide all the information (in a single file) of udpates available that the central station would download. Once done, the developer should work in a mechanism to automatically generate OVAL queries from the Debian Security Advisories published (there is already a beta version of that tool in the project's website, but it is not yet deployed). That would make it possible to provide all the information (in a single file) of updates available that the central station would download.
Line 18: Line 22:
Optionally, it could also use the information available in the database managed by the [http://secure-testing-master.debian.net/ Debian Security Testing team] to generate OVAL information even for vulnerabilities that have not yet been patched in Debian. This information is currently available in the [http://security-tracker.debian.net/tracker/ Security bug Tracker] and there is only one tool (debsecan) that makes use of it. It would also use the information available in the database managed by the [http://secure-testing-master.debian.net/ Debian Security Testing team] to generate OVAL information even for vulnerabilities that have not yet been patched in a given Debian distribution. This information is currently available in the [http://security-tracker.debian.net/tracker/ Security bug Tracker] and there is only one tool (debsecan) that makes use of it. This would extend the system so that it would be much more than just a "patch management system" and it would also make it useful for "testing" and "sid" Debian systems.
Line 21: Line 25:
security updates. The administrator could check the central monitor and review systems which need to be patched, he should be able to mark updates as "not relevant" or "not considered for this system" so that the central station could be used as a tool to control when to update and patch systems or even what action to take in the system (if no updates are yet available from Debian) security updates. The administrator could check the central monitor and review systems which need to be patched, he should be able to mark updates as "not relevant" or "not considered for this system" so that the central station could be used as a tool to control when to update and patch systems or even what action to take in the system (if no updates are yet available from Debian).


Notice that there are different ways to obtain information related to security updates:

 * mailing list redistribution of advisories
 * the Debian web site (the HTML pages)
 * the RDF feed of the web site (limited to a number of advisories, not all
  are included)
 * security mirrors (apt sources)

A central server, which some organizations would like to located in an internal network (not connected to the Internet) should be able to use any of these. At the very minimum, a central server should be able to generate OVAL queries based on the e-mail messages it receives (when sent to the mailing list). Bandwidth usage should be taken into account: mail, RDF feeds and HTML parsing
might be better than updating the Packages file from remote mirrors.

With this system an administrator could answer the following questions:

 * is any of my critical services vulnerable?
 * should I disable the service to remove the risk? When is a patch going to be available?
 * is there any workaround I could implement while the patch is not available?
 * should I manually prepare a patch for the security fix?

OVAL Agent for Debian

  • Mentor: [JavierFernandezSanguino Javier Fernandez-Sanguino]

  • Summary: Agent to monitor security update status of clusters of Debian systems

  • Required skills:

    • C programming (for the agent)
    • Perl programming (for integration with the www.debian.org)
    • knowledge of security
    • GUI development knowledge (for the monitor station) can be GTK or PHP based

Description

The goal of this project would be the development of a mechanism to manage the security status of clusters of Debian systems. Although there are a host of tools to check for the availability of security updates locally (such as update-notifier, integrated with the GNOME desktop, or cron-apt, more info available in the [http://www.debian.org/doc/manuals/securing-debian-howto/ch10.en.html#s-keep-secure Securing Debian Manual]), there is no easy way to manage tens or hundreds of systems.

Also, the tools currently available require all systems to access the Internet (or a mirror server) which makes their deployment more difficult for systems which are not connected to the Internet, or have a restricted or limited connection (which is common for systems deployed inside companies and some organizations)

Moreover, most desktop oriented security update notifiers focus on stable systems, and are not applicable to "testing" or "sid" systems.

The project should start by developing an [http://oval.mitre.org OVAL] agent for Debian, since OVAL already provides a uniform mechanism to check for and report to a central server the status of security updates. Some other distributions (currently RedHat) are using OVAL and using a standard would make it easier to integrate with even third party tools.

Once done, the developer should work in a mechanism to automatically generate OVAL queries from the Debian Security Advisories published (there is already a beta version of that tool in the project's website, but it is not yet deployed). That would make it possible to provide all the information (in a single file) of updates available that the central station would download.

It would also use the information available in the database managed by the [http://secure-testing-master.debian.net/ Debian Security Testing team] to generate OVAL information even for vulnerabilities that have not yet been patched in a given Debian distribution. This information is currently available in the [http://security-tracker.debian.net/tracker/ Security bug Tracker] and there is only one tool (debsecan) that makes use of it. This would extend the system so that it would be much more than just a "patch management system" and it would also make it useful for "testing" and "sid" Debian systems.

Finally, a central monitor should be developed (an OVAL server). This server would distribute queries to OVAL agents in order to determine which systems need security updates. The administrator could check the central monitor and review systems which need to be patched, he should be able to mark updates as "not relevant" or "not considered for this system" so that the central station could be used as a tool to control when to update and patch systems or even what action to take in the system (if no updates are yet available from Debian).

Notice that there are different ways to obtain information related to security updates:

  • mailing list redistribution of advisories
  • the Debian web site (the HTML pages)
  • the RDF feed of the web site (limited to a number of advisories, not all
    • are included)
  • security mirrors (apt sources)

A central server, which some organizations would like to located in an internal network (not connected to the Internet) should be able to use any of these. At the very minimum, a central server should be able to generate OVAL queries based on the e-mail messages it receives (when sent to the mailing list). Bandwidth usage should be taken into account: mail, RDF feeds and HTML parsing might be better than updating the Packages file from remote mirrors.

With this system an administrator could answer the following questions:

  • is any of my critical services vulnerable?
  • should I disable the service to remove the risk? When is a patch going to be available?
  • is there any workaround I could implement while the patch is not available?
  • should I manually prepare a patch for the security fix?

Optionally, the central station could rate the urgency of the update using [http://www.first.org/cvss/ CVSS] (by using the CVE links available in the DSAs and extracting this information from the [http://nvd.nist.gov/ National Vulnerability Database]).