Zero-Day und Less-Than-Zero-Day Vulnerabilities und Exploits

Zero-Day und Less-Than-Zero-Day Vulnerabilities und Exploits
Risiken unveröffentlichter Sicherheitslücken
Hartmut Pohl
Fachhochschule Bonn-Rhein-Sieg, Fachbereich Informatik, Informationssicherheit
Forschungsschwerpunkt NEGSIT – Next Generation Services in Heterogeneous Network Infrastructures
Gegen unveröffentlichte – nur wenigen Personen bekannte – Sicherheitslücken (Less-Than-Zero-Day
Vulnerabilities) und diese ausnutzende Angriffsprogramme (Exploits) können IT-Systeme nicht geschützt
werden. In der Vergangenheit wurden Sicherheitslücken meist dem Hersteller gemeldet; dieser stellte
(allerdings nicht in allen Fällen) eine Fehlerkorrektur zur Verfügung. In jüngerer Zeit werden Sicherheitslücken systematisch (Tool-gestützt) gesucht und an Behörden, Unternehmen und an die organisierte
Kriminalität verkauft – und nicht oder nicht sofort dem Hersteller gemeldet.
Durch Ausnutzung dieser unveröffentlichten Sicherheitslücken ist Wirtschaftsspionage und Computersabotage (auch der Steuerungsrechner des Internet) unerkannt möglich [GI 2007]. Praktizierte Anwendungen sind – u.a. auch als Titan Rain – dokumentiert [BfDI 2007, Keizer 2006, NSTAC 2007, Pohl 2007,
Rath 2007].
Lebenslauf von Sicherheitslücken
Der Lebenslauf von Sicherheitslücken kann grundsätzlich in drei Zeitabschnitte gegliedert
werden – vgl. die Abb.: Lebenslauf von Sicherheitslücken:
• Einen scheinbar Sicherheitslücken -freien Abschnitt,
• einen Abschnitt, in dem die Sicherheitslücken erkannt und ggf. ausgenutzt wird und
• einen Abschnitt, in dem die Sicherheitslücke veröffentlicht ist und der Hersteller eine
Fehlerkorrektur entwickelt.
Vulnerability-free
Phase - seemingly
Product
Shipment
Vulnerability discovered
and used
Exploit published
published
Exploit
Vulnerability disclosed:
Manufacturer …
Patched
System
Patch
Zero
Vulnerability
Vulnerability
discovered
discovered
Vulnerability
Vulnerability Day
published
Black Risk
Grey Risk
White Risk
Fix, Patch, Update, Version …
Abb. Lebenslauf von Sicherheitslücken
Sicherheitslücken
Software kann nicht fehlerfrei hergestellt werden; Sicherheitslücken eines IT-Systems
(Betriebssysteme etc. bis hin zu Anwendungssoftware und Sicherheitsprogrammen wie
Firewalls, Virensuchprogrammen etc.) können zufällig erkannt werden. Meist werden sie
aber systematisch mit Tool-Unterstützung [Bachfeld 2006] gesucht und mit einem entsprechenden Exploit als Proof of Concept nachgewiesen [Eidenberg 2006, Martinez 2007,
Metasploit 2007] und (häufig) dem Hersteller mitgeteilt.
Herstelleraktivitäten
Je nach Bedeutung der Vulnerability entwickelt der Hersteller eine Fehlerkorrektur
(Patch) und veröffentlicht sie (ggf. zusammen mit der Vulnerability). Allerdings haben die
Hersteller Microsoft, Apple, Oracle, Cisco und Sun im ersten Halbjahr 2007 für 21% der
veröffentlichten Sicherheitslücken keinen Patch entwickelt; andere Herstellern sogar für
60% nicht [Fox 2007, IBM 2007, Symantec 2007].
Die (wohl durchschnittliche) Entwicklungszeit für einen Patch (und die zugehörigen Tests)
wird – nach früher erheblich längeren Zeiten [Krebs 2006] – inzwischen mit (kontinuierlich verkürzten) 21 Tagen (Microsoft), 101 (HP) und 122 Tagen (Sun) angegeben [Parson
2007].
Allerdings muss auch die (Sicherheits-)Qualität eines Patches bewertet werden [Arora et
al. 2004].
Zero-Day Vulnerabilities und Exploits
Der Tag der Veröffentlichung der Vulnerability wird als Zero-Day [Porter o.J., Shimel
2006] bezeichnet: Angreifer nutzen die Zeit zwischen Veröffentlichung der Vulnerability
und Installation des Patches, um Systeme mit so genannten Zero-Day Exploits zu penetrieren.
25% der Exploits wurden innerhalb von 24 Stunden nach der Veröffentlichung einer Vulnerability entwickelt; 31% binnen 6 Tagen [Parson 2007].
Less-Than-Zero-Day Vulnerabilities und Exploits
Das Zeitintervall zwischen dem Erkennen einer Vulnerability und ihrer Veröffentlichung
[Arbaugh et al. 2000, Browne et al. 2000, Jones 2007, Schneier 2000] wird als LessThan-Zero-Day [Arbeitskreis 2007, Ma Huijuan 2007, Shimel 2006] bezeichnet – vgl. die
Abb.: Lebenslauf von Sicherheitslücken. Nach Patchen des Systems beginnt der 'Lebenslauf' wieder beim Product Shipment. Andere Bezeichnungen finden sich [Browne et al.
2000, Rescorla 2004].
Less-Than-Zero-Day Vulnerabilities können mit einem zugehörigen Less-Than-Zero-Day
Exploit grundsätzlich erfolgreich angegriffen werden [Anderson 2001]: Für unveröffentlichte Sicherheitslücken existieren keine spezifischen Schutzmaßnahmen; der Angegriffene kann den Angriff jedenfalls nicht (direkt) erkennen [Shimel 2006].
Sicherheitsprogramme wie z.B. Virensuchprogramme, Intrusion-Detection-, IntrusionProtection-Systeme etc. können naturgemäß nur die Angriffe erkennen, deren Eigenschaften wie Bit-String (Signatur) oder Verhalten (Heuristik) sie kennen [iDefense
2007b].
Von den im 1. Halbjahr 2007 veröffentlichten 3.273 Sicherheitslücken können 90% erfolgreich über das Internet (remote) ausgenutzt werden; mehr als 50% dieser Sicherheitslücken ermöglichen Administratorrechte [IBM 2007]; entsprechendes dürfte für unveröffentlichte Sicherheitslücken gelten.
Markt für Sicherheitslücken
Einige Sicherheitslücken werden in Mailing- oder anderen Listen [Bugtraq 2007, Mitre
2007, SecurityFocus 2007, VulnWatch 2007, Zero Day Initiative 2007a, 2007b] veröffentlicht.
Zunehmend weniger werden dem Hersteller mitgeteilt – vielmehr bemühen sich Unternehmen, sie gegen Entgelt anzukaufen [IBM 2007, iDefense Labs 2007a, Immunity
2007, TippingPoint 2007], um ihren Kunden Schutzmaßnahmen empfehlen zu können.
Internet-Auktionen wurden vorgeschlagen [Ozment 2004] und realisiert [Heise 2006a,
2007, Wabisabilabi 2007].
Sicherheitslücken werden auch verdeckt von Behörden (Nachrichtendiensten) und Wirtschaftsspionage-Treibenden, von der Organisierten Kriminalität und auch von BotnetBetreibern [Bächer 2005] angekauft oder sogar in deren Auftrag gesucht [McAfee 2006,
Naraine 2006, Royal Canadian Mounted Police 2006, Stone 2007].
Für Sicherheitslücken existiert also ein offener und ein verdeckter Markt [Böhme 2005,
2006, Camp et al. 2004, Miller 2007]. Gerade der Untergrundmarkt entwickelt sich
schnell [Danchev o.J.].
Vielfach sind Überlegungen zur Verbesserung der Marktsituation angestellt worden [Arora
et al. 2004, 2005, Bonner 2002, Christey 2002, Kannan 2005, Schneier 2000, 2007] –
allerdings nur unter dem Aspekt des Herstellernutzens (z.B. durch geringe Preise) für do-
kumentierte Sicherheitslücken [Böhme 2006, Ozment 2004, Rescorla 2004, Schechter
2002].
In jüngerer Zeit wird in den USA für Less-Than-Zero-Day Vulnerabilities konsequenterweise eine Mitteilungspflicht an das Department of Homeland Security (DHS) diskutiert
[Rollins et al. 2007]. Entgegen öffentlichen Forderungen [GI 2007] plant das deutsche
Bundesministerium des Innern jedenfalls keine Mitteilungspflicht erkannter Sicherheitslücken an die Regierung oder auch nur eine Verpflichtung der Behörden zur Veröffentlichung behördenbekannter Sicherheitslücken [BMI 2008].
Durch die Geheimhaltung von Sicherheitslücken wird also Kriminalität wie Wirtschaftsspionage gegen deutsche Unternehmen und Terrorismus direkt gefördert.
Angriffsablauf
Exploits
Ein Exploit ist spezifisch für eine konkrete Vulnerability; daher muss die anzugreifende
Software mit Version, Update, Build bekannt sein; zu einer Vulnerability können mehrere
Exploits existieren.
Exploits bestehen aus Programm- oder Skriptcode (Payload) – einer Folge von Befehlen
und sind daher spezifisch für die benutzte Prozessorarchitektur oder das jeweilige Programm – sowie ggf. dem sog. Offset: Daten, die z.B. für einen Buffer Overflow übertragen werden wie der einzuschleusende Programmcode und die Rücksprungadresse [Breirer 2006]. Exploits können selbst Sicherheitslücken enthalten.
Anpassung an das Zielsystem
Sofern die Systemkonfiguration aus mehreren Rechnern (Mehrrechnersystem mit Servern, sequentiell angeordneten Firewalls etc.) besteht, muss zu jeder Hardware die anzugreifende Software ermittelt werden und es muss auch jeder Rechner mit einem (ggf.
anderen) Exploit erfolgreich angegriffen werden; für komplexe Hardware-/SoftwareKonfigurationen wird ein Analyseverfahren vorgeschlagen [Schneier 1999]. Allerdings
kann ein Angriff auch einen der ggf. durchgehend offenen Ports ausnutzen.
Angriffsziel
Angriffe zielen auf die Zuweisung von möglichst umfangreichen Zugriffsrechten (Administrator), um Daten zu lesen oder zu schreiben; dazu werden z.B. auch Rootkits eingeschleust, die eine Virtualisierungsschicht zwischen Hardware und Betriebssystem oder
über dem Betriebsystem installieren, um nicht-auditierbar arbeiten zu können [Garfinkel
2007, Heise 2006b, Rutkowska 2006].
Fehlender Schutz
Zwar kann Sicherheitssoftware bekannte Exploits erkennen – dies gilt jedoch nicht für
noch unveröffentlichte Sicherheitslücken und die zugehörigen Exploits. Ein Angreifer kann
evtl. hinterlassene Angriffsspuren (auch in Protokollen) löschen und die Software zurücksetzen, so dass der Benutzer den erfolgten Angriff auch im Nachhinein nicht erkennen
oder gar nachweisen kann.
Tools zur Erkennung von Sicherheitslücken und zur Entwicklung von
Exploits
Fuzzer sind Tools zur systematischen Generierung (brute force) von Eingabewerten für
Programme; durch Fehlverhalten des Programms können Sicherheitslücken entdeckt
werden, die mit Code-Audits noch nicht erkannt wurden [Miller 2007]. Beispiele für Fuzzer sind AxMan, FileFuzz, FTPStress Fuzzer, OWASP JBroFuzz, Smudge und Spikefile
[Bachfeld 2006].
Das Metasploit Framework [Metasploit 2007] enthält Informationen über Sicherheitslücken; es ist ein Werkzeug zur Entwicklung und Ausführung von Exploits und enthält ein
Shellcode-Archiv [Beirer 2005]. Weitere Tools sind CANVAS [Immunity 2007] und Core
Impact [Core Security Technology 2007]. Beispiel-Shellcode findet sich auch an anderen
Stellen [shellcode.org 2007].
Angriffe erkennende und erschwerende Maßnahmen
In jüngerer Zeit wird in den USA diskutiert, den durch unzureichende Sicherheitsmaßnahmen entstandenen Verlust 'sensitiver Daten' unter Strafe zu stellen [Rollins et al.
2007] und ein gesetzlich vorgeschriebenes Mindest-Sicherheitsniveau für Unternehmen
und Behörden durchzusetzen.
Zugriffskontrolle
Administratoren und Benutzern dürfen nur die unverzichtbar benötigten Zugriffsrechte
zugeteilt werden.
Firewalls (packet filter, stateful inspection, application level), Proxies und Verschlüsselung kontrollieren Zugriffe.
Virensuchprogramme und Intrusion Detection (IDS) und Intrusion Protection Systeme
(IPS) können alle vom Hersteller berücksichtigten Sicherheitslücken und Exploits erkennen.
Verbindungspolitik und Datenübertragungsrate
Zu den begrenzenden Faktoren gehört in erster Linie eine restriktive Verbindungspolitik
des Zielsystems zum Internet oder physisches Abschalten bei Nicht-Nutzung (der SleepModus ist unzureichend); weiterhin wirkt die zur Verfügung stehende Datenübertragungsrate des Zielsystems begrenzend.
Gegen unberechtigte Zugriffe aus lokalen Netzen, Intranets, Extranets und dem Internet
sind Stand-Alone-Systeme besser geschützt: Physisch von Netzen getrennt.
Sicherheitsqualität eingesetzter Software
Grundsätzlich kann bei Software (insbesondere Sicherheitssoftware) und Hardware durch
die Evaluierung und Zertifizierung nach ISO/IEC 15408 (Common Criteria) ein höheres
Sicherheitsniveau erreicht werden; dies gilt insbesondere für das Evaluation Assurance
Level EAL 4 ('methodisch entwickelt, getestet und durchgesehen') und höher [ISO
15408].
Fehlerkorrekturen
Bekannte Sicherheitslücken oder Exploits sollten durch überprüfte Fehlerkorrekturen (Bypass, Fix, Hotfix, Patch) behoben werden (Patch-Management). Automatische Fernwartung und automatisches Updating muss allerdings verhindert werden.
Arbeitsumgebung
Mit dem Booten von – und Abspeichern der Nutzdaten auf – portablen (ggf. read-only)
Datenträgern wie CD-ROM, Festplatten, USB-Sticks o.ä. kann eine festgelegte Arbeitsumgebung (Sandbox) geschaffen werden; diese Arbeitsumgebung ist schwerer manipulierbar.
Hardware-Komponenten
Die Geschwindigkeit der Komponenten Prozessor, Hauptspeicher und periphere Geräte
etc. kann begrenzend wirken.
Prüfsummen und Protokollierung
Änderungen an Programmen und Nutzdaten können mit wiederholtem Einsatz von Prüfsummenverfahren erkannt werden.
Mit forensischen Maßnahmen wie Protokollierung der Rechnernutzung und Auswertung
können Angriffe erkannt werden.
Quellcode-Analyse
Anwendungssoftware kann Tool-gestützt getestet werden und der Quellcode auf sicherheitsrelevante Fehler überprüft werden [debian 2007, Gerkis 2007, OWASP 2007].
Acknowledgments
Mein großer Dank gebührt allen engagierten Studierenden, die sich im Rahmen des Software Development Lifecycle intensiv mit der Bewertung des Sicherheitsniveaus von Software mit Hilfe von Exploiting
Frameworks, Fuzzern, Threat Modeling, Source Code Analysis etc. beschäftigt haben.
Für die kritische Durchsicht danke ich Herrn Dipl.-Inform. Gerd Hofemann.
Literatur
Anderson, R.:
Why Information Security is Hard. An Economic Perspective. London 2001
http://www.ftp.cl.cam.ac.uk/ftp/ users/rja14/econ.pdf
Arbeitskreis "Technische und organisatorische Datenschutzfragen" der Konferenz der Datenschutzbeauftragten
des Bundes und der Länder (Hrsg.): Technische Aspekte der Online-Durchsuchung. O.O. 2007
Arbaugh, W.A.; Fithen, W.L.; McHugh, J.: Windows of Vulnerability: A Case Study Analysis. IEEE Computer 12,
52 – 59, 2000
Arora, A., Telang, R., Xu, H.: Optimal Policy for Software Vulnerability Disclosure, Arbeitsbericht der H. John
Heinz III School of Public Policy and Management, Carnegie Mellon University, Pittsburgh 2004.
http://www.dtc.umn.edu/weis2004/xu.pdf
Arora, A.; Telang, R.: Economics of Software Vulnerability Disclosure. IEEE Security and Privacy, 3 (1), 20-25,
2005
Bachfeld, D.: Die Axt im Walde. Einführung in Fuzzing-Tools. Heise Security 18. Aug. 2006
http://www.heise.de/security/artikel/76512
Bächer, P.; Holz, T.; Kötter, M.; Wichersky, G.: Know your Enemy: Tracking Botnets. Using Honeynets to learn
more about Bots. 2005 http://www.honeynet.org/papers/bots/
Beirer, S.:
Metasploit Framework v3.0. In: GAI NetConsult GmbH (Hrsg.): Security Journal. Berlin 12/2006
http://www.gai-netconsult.de/download/ security/secjournal/SecJournal_0628.pdf
BfDI – Der Bundesbeauftragte für den Datenschutz und die Informationsfreiheit (Hrsg.): 21. Tätigkeitsbericht
2005 – 2006. Bonn 2007
BMI – Bundesministerium des Innern (Hrsg.): Entwurf eines IT-Sicherheitsgesetzes. Berlin 30. Mai 2008
Böhme, R.:
Vulnerability Markets. What is the economic value of a zero-day exploit? In: Proc. of 22C3. Berlin 2005 http://events.ccc.de/congress/2005/ fahrplan/attachments/542Boehme2005_22C3_VulnerabilityMarkets.pdf
Böhme, R.:
A comparison of market approaches to software vulnerability disclosure. In G. Müller (Hrsg.):
Proc. of ETRICS, Freiburg, 5. – 9. Juni 2006 298 – 311, Berlin 2006
http://www.springerlink.com/ link.asp?id=428k87mr2h103143
Bonner, E.:
Streit um Bugtraq-Eintrag: Aufklären oder schweigen. PC Welt 21. Nov. 2002
http://www.pcwelt.de/start/sicherheit/archiv/27470/
Browne, H.K.; McHugh, J.: A Trend analysis of Exploitations. CS-TR-4200, UMIACS-TR-2000-76, 2000
Camp, L.J.; Wolfram, C.D.: Pricing Security: Vulnerabilities as Externalities. Economics of Information Security
12, 2004
Christey, S.; Wysopal, C.: Responsible Vulnerability Disclosure Process. Internet-Draft. MITRE Bedford 2002
Clinton, N.:
How Windows Update Keeps Itself Up-to-Date. Microsoft TechNet 2007
http://blogs.technet.com/mu/archive/2007/09/13/how-windows-update-keeps-itself-up-todate.aspx
Core Security Technology (Ed.): Core Impact. Boston 2007 http://www.coresecurity.com/
Coverity Inc. (Ed.): [Homepage] San Francisco 2007 http://www.coverity.com/
Danchev, D.: Malware – future trends. o.O. 2006
http://www.packetstormsecurity.org/papers/general/malware-trends.pdf
Debian (Hrsg.): Werkzeuge für Sicherheit-Audits. http://www.de.debian.org/security/audit/tools
Eidenberg, A.: Exploits für alle. Heise Security 06.01.2006 http://www.heise.de/security/artikel/67984/
Fox, D. (Hrsg.): Secorvo Security News Juli 2007. Karlsruhe 2007 http://www.secorvo.de/securitynews/secorvo-ssn0707.pdf
Garfinkel, T.; Adams, K.; Warfield, A.; Franklin, J.: Compatibility is Not Transparency: VMM Detection Myths
and Realities. 11thWorkshop on Hot Topics in Operating Systems San Diego, CA May 7–9, 2007
http://www.stanford.edu/~talg/ papers/HOTOS07/vmm-detection-hotos07.pdf
Gerkis, A.; Danahy, J.: Software Security Governance in the Development Lifecycle. Boston 2007
GI – Gesellschaft für Informatik (Hrsg.): GI fordert Veröffentlichung von Sicherheitslücken in Software. Bonn
2007 http://www.gi-ev.de/aktuelles/meldungsdetails/meldung/167/
Heise Security (Hrsg.): Untergrundauktionen: Vista-Exploit 20.000 $, eBay-Konto 7 $. Hannover 2006a
http://www. heise.de/security/news/meldung/82679
Heise Security (Hrsg.): Rootkit verschiebt Windows in virtuelle Maschine. Hannover 2006b
http://www.heise.de/ security/news/meldung/79676
Heise Security (Hrsg.): Betreiber von Exploit-Auktionen spricht auf Microsofts Hacker-Konferenz. Hannover
2007 http://www.heise.de/ security/news/meldung/96800
IBM Internet Security Systems (Ed.): Cyber Attacks On The Rise: IBM 2007 Midyear Report. Somers 2007
http://www.iss.net/ documents/whitepapers/X-Force_Threat_Executive_Brief_Aug_07.pdf
iDefense Labs (Ed.): Vulnerability Contributor Program. Sterling Va. 2007a http://labs.idefense.com/vcp
iDefense Labs (Ed.): Major Threats and Trends Impacting the 2007 Cyber Security Landscape. Sterling Va.
2007b http://www.verisign. com/static/040800.pdf
Immunity (Ed.): CANVAS. Miami Beach 2007 http://www.immunitysec.com/
ISO/IEC 15408: Information technology -- Security techniques -- Evaluation criteria for IT security -- Parts 1,
2, 3 Genf 2005
Jones, J.R.:
Estimating Software Vulnerabilities. IEEE Security & Privacy 5, 4, 28 – 32, 2007
Kannan, K.; Telang, R.: Market For Software vulnerabilities? Think Again. Management Science, 51(5), 726-740
2005 http://www.heinz.cmu.edu/~rtelang/ MS_market.pdf
Keizer, G.:
UCLA admits Massive Data Hack. Informationweek Dec. 12, 2006
http://www.informationweek.com/shared/printableArticle.jhtml?articleID=196603485
Krebs, B.:
A Time to Patch. http://blog.washingtonpost. com/securityfix/2006/01/a_time_to_patch.html
2006
Ma Huijuan:
Handling Less Than Zero Day Attack – A Case Study. Seville 2007 http://www.first.org/ conference/2007/papers/huijuan-ma-slides.pdf
Martinez, V.: PandaLabs Report: Mpack uncovered. O.O. 2007
http://blogs.pandasoftware.com/blogs/images/PandaLabs/2007/05/11/MPack.pdf?sitepanda=p
articulares
McAfee (Hrsg.): Virtual Criminology Report. North American Study into Organized Crime and the Internet.
Hamburg 2006 http://www.mcafee.com/de/about/press/ corporate/2006/20061208_124141_v.html
Metasploit (Ed.): Bustin shells since 2003. 2007 http://www.metasploit.com/
Miller, B.P.:
Fuzz testing of Application Reliability. Madison 2007 http://pages.cs.wisc.edu/~bart/fuzz/
Miller, C.:
The legitimate vulnerability market: The secretive world of 0-day exploit sales. 2007
http://weis2007.econinfosec.org/papers/29.pdf
Mitre (Ed.):
Common Vulnerabilities and Exposures (CVE). The Standard for Information Security Vulnerability Names. 2007 http://www.cve.mitre.org/
Naraine, R.:
Researcher: WMF Exploit Sold Underground for $4,000. February 2, 2006
http://www.eweek.com/article2/0,1895,1918198,00.asp
NSTAC - The Presidents National Security Telecommunications Advisory Committee (Ed.): NSTAC Report to the
President on International Communications. Washington 2007
Ozment, A.:
Bug Auctions: Vulnerability Markets Reconsidered. In Workshop of Economics and Information
Security, Minneapolis 2004 http://www.dtc.umn.edu/weis2004/ozment.pdf
OWASP - Open Web Application Security Project (Ed.): Source Code Analysis Tools.
http://www.owasp.org/index.php/ Source_Code_Analysis_Tools
Parson, G.; Thorne, G.: Internet Security Threat Report Vol. XI. O.O. 2007 http://cio.vermont.gov/var/cio/ storage/ original/ application/ 6c785bbe879fc3ddd2c5741435669af6.ppt
Pohl, H.:
Zur Technik der heimlichen Online-Durchsuchung. Datenschutz und Datensicherung 31, 9, 684 688, 2007 http://www.dud.de/binary/DuD_Pohl_907.pdf
?sid=9f7bc909e95c652b86ebd9ae5344abba
Porter, B.:
Approaching Zero. A Study in Zero-Day Exploits. Origin, Cases, and Trends. Norwich o.J.
http://nujia.norwich.edu/ current/ 2_2_art01.pdf
Rath, C.:
Der Zoll ist schon drin. In: Kölner Stadt-Anzeiger 7. Okt. 2007 http://www.ksta.de/html/artikel/
1190968634161.shtml
Rescorla, E.:
Is finding security holes a good idea? In: Workshop on Economics and Information Security.
Minneapolis 2004 http://www.dtc.umn.edu/weis2004/rescorla.pdf
Rollins, J.; Wilson, C.: Terrorist Capabilities for Cyberattack: Overview and Policy Issues. CRS Report for Congress. Washington 2007
Royal Canadian Mounted Police (Ed.): Future Trends in Malicious Code – 2006 Report. Ottawa 2006
Rutkowska, J.: Subverting Vista Kernel for Fun and Profit. Black Hat Aug. 2006.
Schechter, S.E.: How to buy better testing: Using competition to get the most security and robustness for your
dollar. In: Proceedings of the Infrastructure Security Conference. Bristol 2002
Schneier, B.: Attack Trees. Dr. Dobb's Journal December 1999 http://www.schneier.com/paper-attacktreesddj-ft.html
Schneier, B.: Full Disclosure and the Window Exposure. Sept. 15, 2000 http://www.schneier.com/cryptogram-0009.html#1
Schneier, B.: Business Models for Discovering Security Vulnerabilities. Mountain View 2007
http://www.schneier.com/blog/archives/2007/02/business_models.html
SecurityFocus (Ed.): Bugtraq. 2007 http://www.securityfocus.com/archive/1
shellcode.org (Ed.): [Homepage] 2007. http://shellcode.org/
Shimel, A.:
Less Than Zero Threat. Oct. 19, 2006
http://www.stillsecureafteralltheseyears.com/ashimmy/2006/10/less_then_zero_.html
Stone, B.:
Moscow company scrutinizes computer code for flaws. International Herald Tribune January 29,
2007 http://www.iht.com/ articles/2007/01/29/business/bugs.php
Symantec (Ed.): Symantec Internet Security Threat Report. Trends for January – June 07. Vol. XII. Cupertino
2007 http://eval.symantec.com/mktginfo/enterprise/white_papers/entwhitepaper_internet_security_threat_report_xii_exec_summary_09_2007.en-us.pdf
TippingPoint (Ed.): Zero Day Initiative. 2007 http://www.zerodayinitiative.com/
VulnWatch (Ed.): [Homepage]. 2007 http://www.vulnwatch.org/index.html
Wabisabilabi (Ed.): Closer to zero risk. London 2007 http://www.wslabi.com/wabisabilabi/home.do?
Zero Day Initiative (Ed.): Published ZDI Advisories. Austin 2007a http://www.zerodayinitiative.com/ advisories.html
Zero Day Initiative (Ed.): Upcoming ZDI Advisories. Austin 2007b http://www.zerodayinitiative.com/ upcoming_advisories.html