Security Incident Handling

From openSUSE

The SUSE Security Team handles the security incidents in the SUSE Linux based distributions.

Marcus has given a lecture on this topic on FOSDEM2006, if you want to look at it check out the FOSDEM page, for slides, videos and audio.

Getting knowledge of the incident

We monitor various sources of information for security problems. These include mailinglists, both public and non public, our main contact address (security@suse.de), bugzilla, package version updates, and the Mitre CVE database.

Also problems can be found by our own source code audits.

Once an incident is known, it is added to the Novell Bugzilla. (As bug usually not visible to the public.) If you want to see samples of those bugs and our handling, check this link.

The bugreport contains:

• description and where we got the report from
• possible patches (if any)
• possible exploits (if any)
• disclosure timelines
• any CVE / CERT VU# ids (if any)

It is then assigned to the packager. (The security team itself fixes the packages only rarely themselves, because the packagers knows his package (and the surrounding community) best.)

Packager

The packager takes the patches (or creates them) and applies them to packages in all old supported distributions.

He communicates with the upstream developers if necessary.

He updates the current development tree usually with the new upstream version that is released after security problems.

When he is done, he submits the packages to the checkin staging directories of the affected distributions.

Buildsystem inclusion

The buildsystem team reviews the submitted packages (to avoid bugs during package work, bugs in the fixes or similar) and checks in the packages into the buildsystem.

The buildsystem then builds the package automatically.

The buildsystem team also checks in a metapatch information into the system, which then generates a set of YOU patch sources for QA.

QA

The QA team takes those generated patch sources and tests the update like the customer would see it:

• Integration test

If the update works correctly and the program works afterwards.

• Regression test

The testcases existing for the package are run and checked for regressions.

• Security test

The exploit (if any) is tested before and after the update. It must be reproducable before,

and not reproducable afterwards.

If everything has passed, QA approval of the update is given.

Release

The security team gives approval to release the update (honoring disclosure timelines).

The security team also writes the security advisory for issues with higher impact.

For the other issues a summary reports is released approximately weekly.