The last few days I have looked at ways to track open security -issues here at my work with the University of Oslo. My idea is that -it should be possible to use the information about security issues -available on the Internet, and check our locally -maintained/distributed software against this information. It should -allow us to verify that no known security issues are forgotten. The -CVE database listing vulnerabilities seem like a great central point, -and by using the package lists from Debian mapped to CVEs provided by -the testing security team, I believed it should be possible to figure -out which security holes were present in our free software -collection.
- -After reading up on the topic, it became obvious that the first -building block is to be able to name software packages in a unique and -consistent way across data sources. I considered several ways to do -this, for example coming up with my own naming scheme like using URLs -to project home pages or URLs to the Freshmeat entries, or using some -existing naming scheme. And it seem like I am not the first one to -come across this problem, as MITRE already proposed and implemented a -solution. Enter the Common -Platform Enumeration dictionary, a vocabulary for referring to -software, hardware and other platform components. The CPE ids are -mapped to CVEs in the National -Vulnerability Database, allowing me to look up know security -issues for any CPE name. With this in place, all I need to do is to -locate the CPE id for the software packages we use at the university. -This is fairly trivial (I google for 'cve cpe $package' and check the -NVD entry if a CVE for the package exist).
- -To give you an example. The GNU gzip source package have the CPE -name cpe:/a:gnu:gzip. If the old version 1.3.3 was the package to -check out, one could look up -cpe:/a:gnu:gzip:1.3.3 -in NVD and get a list of 6 security holes with public CVE entries. -The most recent one is -CVE-2010-0001, -and at the bottom of the NVD page for this vulnerability the complete -list of affected versions is provided.
- -The NVD database of CVEs is also available as a XML dump, allowing -for offline processing of issues. Using this dump, I've written a -small script taking a list of CPEs as input and list all CVEs -affecting the packages represented by these CPEs. One give it CPEs -with version numbers as specified above and get a list of open -security issues out.
- -Of course for this approach to be useful, the quality of the NVD -information need to be high. For that to happen, I believe as many as -possible need to use and contribute to the NVD database. I notice -RHEL is providing -a -map from CVE to CPE, indicating that they are using the CPE -information. I'm not aware of Debian and Ubuntu doing the same.
- -To get an idea about the quality for free software, I spent some -time making it possible to compare the CVE database from Debian with -the CVE database in NVD. The result look fairly good, but there are -some inconsistencies in NVD (same software package having several -CPEs), and some inaccuracies (NVD not mentioning buggy packages that -Debian believe are affected by a CVE). Hope to find time to improve -the quality of NVD, but that require being able to get in touch with -someone maintaining it. So far my three emails with questions and -corrections have not seen any reply, but I hope contact can be -established soon.
+Etter mandagens lansering av +FiksGataMi har responsen vært +enorm, og de første 1000 problemene er allerede rapportert. Noen +saker er allerede løst, og responstiden til +Bø i Nordland og +Melhus imponerer +stort. Slikt burde gjøre innbyggerne der stolte. :)
+ +En utfordring for FiksGataMi er håndtering av fylkes- og riksveier +som ikke skal til kommunen men til fylket eller staten. Problemet er +at vi mangler en datakilde som kan brukes til å identifisere hvilket +geografisk område som administreres av fylket og staten (dvs. vei, +grøfter, gjerder og slikt). Det vi trenger er maskinlesbare +georefererte eiendomsgrenser over eiendommene som hører til fylkes- og +riksveier. Når vi har det, kan vi videreutvikle fiksgatami til å +håndtere eiendomsgrenser i tillegg til dagens kommune- og +fylkesgrenser. Så vi trenger datakilder uten bruksbegrensninger og +litt finansiering for å ta dem i bruk.
+ +Men noen kommuner håndterer denne utfordringen elegant likevel og +til det beste for innsender ved å sende saken videre til riktig +instans og notere dette i FiksGataMi. De første som gjorde dette var +så vidt jeg kan se +Lørenskog. All kudos +til dem!
+ +I morgen tidlig skal Christer pÃ¥ NRK Ãstlandssendingen og snakke om +FiksGataMi. Jeg gleder meg til Ã¥ høre opptaket og se hvilken respons +det fører til pÃ¥ innrapporteringen. Jeg forsøker Ã¥ holde +oversikt over omtalen +NUUG og FiksGataMi pÃ¥ NUUGs websider, og responsen sÃ¥ langt har vært +veldig god. De fleste kommunene er veldig positive til tjenesten. De +som hadde lignende løsninger er ikke sÃ¥ fornøyde, noe jeg kan forstÃ¥. +PÃ¥ den positive siden fÃ¥r innbyggerne i disse kommunene nÃ¥ et valg om +hvilken løsning de vil benytte seg av, og konkurranse er en fin ting +for Ã¥ dyrke frem de beste løsningene. :)
+