Security Vulnerability Management Mark J Cox Responsibility & Accountability Ï Unique challenges Ï cThe vulnerabilities are there. The fact that somebody in the middle of the night in China who you don't know, quote, "patched" it and you don't know the quality of that, I mean, there's nothing per se that says that there should be integrity that come out of that process. d Steve Ballmer October 2003 3 Many vendors all ship the same thing Ï But not exactly the same thing 3 sometimes not even close Ï and then they backport security fixes too 3 Press and researchers often get the facts wrong or deliberately over-sensationalize Managing vulnerabilities Ï Bugs occur across all software applications 3 Some subset have security implications 3 the number and type of vulnerabilities is pretty similar 3 some code is well written and designed for security and some code isn 9t Ï The role of vendors is to add accountability to the process 3 a layer of insulation to provide a stable, secure, platform based on open source technologies 3 Whilst the ability to react is essential, we have to get out of the vulnerability patch cycle Apache Apache web server Ï Mature ... more. less.
project, over 10 years old Ï Managed under the legal framework of the Apache Software Foundation Ï Powers over half of the Internet web server edge infrastructure 3 (around two-thirds according to Netcraft) 3 (that 9s over 53 million web sites) Ï A critical security flaw would have a significant impact on critical infrastructure 3 at least an impact on consumer confidence ca loose confederation of programmers & working in their spare time over gin and tonics at home d -- Wall Street Journal Apache quality Ï Engineers for security 3 You don't find buffer overflow vulnerabilities Ï Manages over 1000 contributors Ï Standard accountability processes 3 Peer review, Contribution Licenses, release teams, code signing, automated testing and regression tools Ï Many vendors ship Apache 8OEM 9 3 Apple, HP, IBM, Red Hat, Debian.... increases testing coverage by adding diversity Ï Dedicated Security Response Team Policy Role of vendors Ï An open source architecture is built around a number of applications 3 Red Hat Enterprise Linux provides a complete open source operating environment with web servers, mail servers and client applications such as Open Office 3 (A secure web server is more than just Apache) Ï A single point of contact for the security issues affecting every part of that environment 3 Accountability for fixing vulnerabilities that are found with a clear and established response process 3 A single update mechanism for the operating system kernel and applications 3 A single source of advisories Red Hat Enterprise Linux Errata Life cycle Ï 7 years of security errata 3 Asynchronous updates for the highest severity issues 3 Update releases capture lower severity issues Ï Each package gets an individual security advisory 3 Asynchronous updates may fix multiple Red Hat Enterprise Linux versions Backporting Apache httpd 2.0.54 Apache httpd 2.0.55 NEW!<br><br> NEW! httpd-2.0.52-12.ent httpd-2.0.52-12.1.ent RHSA-2005:582 httpd-2.0.52-12.2.ent RHSA-2005:608 Enterprise Linux 4 Fedora Policy Ï A policy of moving upstream, not backporting 3 Might affect the cdays of risk d a little 3 Still need some backports for issues not fixed upstream 3 Fedora Core 5 for vulnerabilities Jan 2003 to release (1361 CVE) Unfixed 1% Backport 9% Upstream 90% 0 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1225 122 14 Upstream 90% Backport 9% Unfixed 1% Severity Rating Setting a severity rating Ï Based on a technical assessment of the flaw, not the threat 3 Unique to each Red Hat Enterprise Linux distribution 3 Sets the priority through Engineering and QA 3 Trend tracking (source, reported, public) Ï Public in bugzilla cwhiteboard d status line Ï Used by internal and external status tools Ï Compatible with ranking used by Microsoft and Apache cA vulnerability whose exploitation could allow the propagation of an Internet worm without user action. d Severity Rating Ï Critical ceasily compromise the Confidentiality, Integrity or Availability of resources d Severity Rating Ï Important charder or more unlikely to be exploitable d Severity Rating Ï Moderate cunlikely circumstances .. or where a successful exploit would lead to minimal consequences d Severity Rating Ï Low Critical Vulnerabilities Ï We don 9t get many Ï Those that we get have the potential to create significant risk for customers Ï We aim to respond within one working day Ï Sometimes this is hard 3 But we are accountable Ï Lots of metrics on how many issues and how fast we fixed them in the next session Where to find our severity ratings Ï For advisories 3 In the advisory, Red Hat Network notifications Ï For individual vulnerabilities 3 In bugzilla How to get notifications Ï Red Hat Network will notify you of updates needed to packages installed on your systems 3 By email 3 By the up2date applet 3 By logging in Ï Subscribing to email@example.com Ï From the web https://rhn.redhat.com/errata/ Ï RSS feed Security Response Team Security Response Team Ï Accountable for vulnerabilities that affect Red Hat products and services 3 Monitoring 3 Triage 3 Escalation and troubleshooting through life cycle 3 Communication with other affected vendors 3 Internal communication, documentation, advisory 3 Responsible for errata release 3 Metrics and feedback to Engineering Monitoring for vulnerabilities Ï We find out about security issues in a number of ways (%, March 05-March 06) 05101520253035 33 23 14 11 7 5 4 2 1 other peer FLOSS distributors via vendor-sec relationship with upstream package developers monitoring of public mailing lists relationship with Mitre CVE project Red Hat internal an individual (issuetracker, bugzilla, secalert) other OSS distributors via their bugzilla external security research company (iDefense...) vulnerability clearing centers (CERT, NISCC...) firstname.lastname@example.org Ï Address used for internal and external customers to ask security vulnerability related questions 3 Reporting new vulnerabilities 3 Asking how we addressed various vulnerabilities Ï Charter to respond within 3 business days 3 For fiscal year 2006 (ending March 2006) Ï 92% responded within one business day Ï 99% by two business days Triage Ï Separate out those issues that matter the most 3 Used to prioritize Engineering, QA, documentation...<br><br> Ï Figure out what we ship that is affected 3 Across all product lines, across all supported products and architectures (and including Fedora). 3 Investigate if any of our security innovations help mitigate Ï Issues then have individual bugs generated in bugzilla for tracking Ï ~18 incoming vulnerabilities per month Release Policy Ï For critical vulnerabilities 3 Will be pushed immediately an embargo is lifted, or when passed QE 3 Will be pushed at any time or day Ï For important vulnerabilities 3 May be held until reasonable time or day Ï For moderate or low vulnerabilities 3 May be held until other issues come up in the same package, or the next Update release Outreach Ï Help Open Source projects deal with vulnerabilities 3 Promote the use of intermediates like NISCC 3 Involvement in industry threat assessment bodies Ï Improve quality of projects 3 Working with groups on testing and auditing tools Ï Protocol testing, prioritizing for critical infrastructure Ï Red Hat worked with NISCC and Codenomicon in testing and fixing OpenSSL Ï To work with our competitors for common good Misleading messaging Ï However, using the Microsoft severity scale: 3 Windows Server 2003 had three critical vulnerabilities 3 In Red Hat Enterprise Linux 3 full install had zero critical vulnerabilities Ï And this only counts their vulnerabilities that actually got disclosed cYear-to-date for 2005, Microsoft has fixed 15 vulnerabilities affecting Windows Server 2003. In the same time period, for just this year, [Red Hat] Enterprise Linux 3 users have had to patch over 34 vulnerabilities and SuSE Enterprise Linux 9 users have had to patch over 78 vulnerabilities d -- Mike Nash, Microsoft, Feb 2005.<br><br> http://www.techweb.com/wire/security/60300209 CVE and OVAL Review: Backporting Apache httpd 2.0.54 Apache httpd 2.0.55 NEW! NEW! httpd-2.0.52-12.ent httpd-2.0.52-12.1.ent RHSA-2005:582 httpd-2.0.52-12.2.ent RHSA-2005:608 Enterprise Linux 4 CVE-2005-1268 CVE-2005-2088 CVE-2005-2700 CVE-2005-2728 Auditing Ï Red Hat Network takes care of figuring out what updates you need Ï But sometimes you need to use third party tools 3 Local version number comparisons don't work Ï httpd 2.0.55 vs httpd 2.0.52 3 Remote version comparisons are worse Ï Screen-scraping our advisories isn't a complete solution Ï A machine-readable, standard way to express how to detect vulnerabilities and patch issues 3 Definitions contain details of how to test for the presence of vulnerable software Ï can also look for vulnerable uses or configuration 3 XML based standard 3 Modular Ï Designed to deal with heterogeneous environments Ï Interoperability testing of tools and processes OVAL Compatibility Ï From today Red Hat is producing OVAL 5 definitions for all Red Hat Enterprise Linux 3 and 4 security advisories 3 includes definitions for all security advisories to date 3 uses latest (OVAL 5, June 16 2006) schema 3 available on the same day as the advisory (hours) Ï Working with MITRE on official compatibility Ï http://oval.mitre.org/ OVAL example More information Ï This is just the reactive side.<br><br> Ï For proactive 3 See the papers from Ulrich Drepper and Dan Walsh from this summit and on the web Ï How well did we do? 3 Metrics on our performance, exploits, where the critical flaws were, compromises, and worms in my next presentation in 15 minutes. Ï http://people.redhat.com/mjc/oval/<br><br>