Inhaltsübersicht

• Satire: Der Wahn nach Features
• Haftung und Gewährleistung für Software!
• Was kann der Software-Benutzer machen?
• Sichere Software beginnt mit der Programmier-Ausbildung
• Die Entwicklung von Qualitätssoftware - The Joel Test
• Augen zu und durch
• Satire: Custom-developed Software
• Weitere Informationen

 

Lausige Software

Letzte Änderungen: März 2018

Zu einem verwandten Thema, hier ein neuer Artikel zu den dümmsten Ideen der Computer-Sicherheit.

Der Wahn nach Features

Philipp Schaumann, Christian Reiser, Sommer 2004

Im Original veröffentlicht in der Computerwelt Österreich, Frühjahr 2004

Die Frage „Warum kann eine Frau nicht so sein wie ein Mann?“, die sich Mr. Henry Higgins im Musical My Fair Lady stellt, macht unser Leben spannend. Die Frage „Warum kann ein Computer nicht so bedienungsfreundlich, zuverlässig und sicher sein wie eine Stereoanlage“ aber macht unser Leben sicher nicht spannend sondern nur schwer.

Vor 25 Jahren haben Branchenkollegen ihren Kunden erzählt, dass Computer irgendwann einmal so leicht zu bedienen sein würden, wie Telefone. Auch wenn sie es wahrscheinlich nicht so gemeint haben, sie hatten recht. Zumindest Mobiltelefone sind mittlerweile so kompliziert wie Computer.

Doch wie entsteht dieser Trend, dass elektronische Geräte im Allgemeinen und Computer im Besonderen immer komplizierter zu bedienen sind, statt dass sie benutzerfreundlicher werden?

Zu einem gewissen Teil sind wir alle schuld; alle, die einen Computer nutzen, und sich über die Jahre mit schlechter Software abgefunden haben. Es gab Zeiten, wo wir es akzeptiert haben, dass sich unser Computer mindestens einmal täglich mit der himmlischen Farbe Blau am Bildschirm verabschiedet hat. Und wir haben uns auch damit abgefunden, dass wir für die Installation neuer Software auf unserem Privat-PC einen "Wissenden" aus dem Bekanntenkreis mit einem Essen oder Bier bezahlen mussten, weil ein Normalsterblicher dazu oft nicht in der Lage ist.

Der "Wissende" aus dem Bekanntenkreis hat sich längst damit abgefunden, dass er sich mit seiner Hilfestellung bei den Freunden und Bekannten auf ein sehr gewagtes Spiel einlässt. Wir haben uns nämlich auch damit abgefunden, dass bei der Installation neuer Software plötzlich ganz andere Programm-Pakete nicht mehr funktionieren oder ihre Parameter verstellt sind. So öffnet nach der Installation eines neuen Webbrowsers manchmal die Musikdatei nun in einem anderen Programm als dem gewohnten. Das ist etwa so, als würde beim Auto der Einbau eines Autoradios die Einspritzpumpen des Motors verstellen.

Auch die Chefs großer Firmen haben ihren Teil zu dieser Situation beigetragen. Sie haben sich nämlich schon längst damit abgefunden, dass sie viel Geld für Help-Desk und Benutzer-Support ausgeben oder ihre Mitarbeiter viel unproduktive Arbeit mit den Computern haben.

Aber wieso hat die Software-Industrie dem nicht entgegengewirkt? Wieso hätte sie sollen? Über Jahrzehnte war es immer nur wichtig, möglichst schnell am Markt zu sein und möglichst viele neue Features anzubieten. Egal, ob die Produkte zuverlässig funktioniert haben und egal, wie leicht Benutzer damit umgehen konnten. Außerdem ist es für Software-Entwickler viel spannender, neue Funktionalität zu bauen, als bestehende Systeme stabil, sicher und benutzerfreundlich zu machen.

Wahrscheinlich gehören Sie zu dem sehr hohen Prozentsatz an Computerbenutzern, die für ihre Texte WinWord verwenden. Aber auch wenn sie schon zu den wenigen gehören, die eine Alternative, wie zum Beispiel StarOffice oder OpenOffice, einsetzen, so gilt das selbe: Wie viele Features ihres Textverarbeitungsprogrammes verwenden sie und wie viele kennen sie überhaupt? Der durchschnittliche Anwender nutzt 15% der Features, die restlichen 85% bezahlt er nur.

Wie wäre es zur Abwechslung mit einem Mobiltelefon, mit dem man nur telefonieren und vielleicht noch SMS empfangen und schicken kann? Das müsste extrem leicht zu bedienen sein, und auch noch viel weniger kosten. So etwas können Sie aber nirgends kaufen, angeblich weil es keiner verlangt.

Wie wäre es zur Abwechslung mit einem Gerät, mit dem man ausschließlich Mails lesen und schreiben kann? So etwas gibt es. Über ein eingebautes Handy werden Mails geholt und versendet, aber man kann nicht damit telefonieren. Es ist ja Blackberry, das Gerät, das nur für E-Mails da ist, und nicht einmal für Viren. Interesse?

Konsumenten sind mächtig und wir sind alle Konsumenten von Software, egal ob zu Hause für den Privat-PC, oder im kleinen oder großen Unternehmen. Nur wenn wir benutzerfreundliche, zuverlässige und sichere Software verlangen, werden wir sie auch irgendwann bekommen - hoffentlich.

Haftung und Gewährleistung für Software !

Im Original veröffentlicht in der Computerwelt Österreich, Sommer 2004

Philipp Schaumann, Christian Reiser

Die Anwender von Software, insbesondere Firmen, haben sich längst daran gewöhnt, dass jede Software Fehler hat, und dass diese Fehler auch sicherheitskritisch sein können. Laut dem Computer Emergency Response Team (CERT) steigen die Sicherheitsprobleme aufgrund von fehlerhafter Software exponentiell. Und die Zeit zwischen der Entdeckung eines Sicherheitsproblems und entsprechenden Angriffstools wird immer kürzer.

Die Software-Industrie bietet zur Fehlerbehebung immer wieder so genannte Patches an. Das sind Software-Teile, die die bestehenden Fehler ausbessern sollen. Leider sind auch diese Patches nicht immer fehlerfrei oder haben unbekannte Nebeneffekte. Daher müssen vor einer an sich schon zeitaufwändigen Installation der Patches diese erst auf Testsystemen ausprobiert werden. Diese Aufwände werden bei der Betrachtung einer Total Cost of Ownership (TCO) fast nie berücksichtigt.

Berechnet man die Kosten von Software, so sind neben dem Anschaffungspreis noch folgende Komponenten zu betrachten:

• Kosten des Wartungsvertrages
• Kosten der Administration und des Einspielens von Patches
• Kosten des Testsystems und der Tests von Patches
• Kosten von Rollout-Software wie zum Beispiel SMS oder onCommand
• Kosten der Stillstände aufgrund von Fehlersuche und Fehlerbehebung
• Diverse Folgekosten

Betrachtet man die damit verbundenen Summen, könnte fehlerarme Software gern in der Anschaffung teurer sein.

Aus den Reihen der Software-Industrie hört man immer wieder, dass Haftung für Software oder durch Software verursachte Schäden nicht möglich sei, weil es unmöglich sei, fehlerfreie Software zu erstellen. Es ist wahrscheinlich auch richtig, dass gänzlich fehlerfreie Software nicht möglich ist, aber ebenso wenig ist es möglich, ein fehlerfreies Flugzeug zu bauen. Aber die Flugzeug- und auch die Automobilindustrie testen ihre Produkte so gut, dass die Versicherungen sie mit einer akzeptablen Prämie gegen die Haftungsschäden und die Kosten von Rückrufaktionen versichern. Davon ist die Softwareindustrie weit weg, warum eigentlich?

Warum ist Software so oft fehlerhaft?

Software wird von Menschen geschrieben, und natürlich ist irren menschlich. Allerdings sind Mechanismen bekannt, wie diese menschlichen Irrtümer verringert und zum größten Teil verhindert werden können.

Zunächst ist es für ein Team von Programmierern sehr hilfreich, wenn sie von Anfang an wissen, was sie programmieren sollen, das heißt, dass sie eine eindeutige und während der Zeit der Entwicklung unveränderte Spezifikation haben. Alle späteren Änderungen bringen zusätzliche Fehlerquellen.

Aber es gibt auch andere Hilfsmittel für die Erstellung von fehlerarmer Software. Allein die Auswahl der richtigen Programmiersprache kann den Fehleranteil um einen Faktor 10 verringern. Zum Beispiel durch Sprachen, die strukturierte Programmierung fordern, und die Konsistenz von Datenstrukturen überprüfen.

Der heute häufigste Fehler ist der so genannte Buffer-Overflow. Es gibt aber Programmiersprachen, in denen solche Buffer-Overflows nicht möglich sind. Auch der Mechanismus des "strong typing" hilft, indem überprüft wird, dass jedem Speicherplatz nur Werte aus dem für ihn gültigen Wertebereich zugeordnet werden. Und saubere Strukturen in den Programmen erleichtern deren Verständlichkeit und verhindern Denkfehler.

Da sich nie alle Fehler verhindern lassen, müssen die restlichen durch Testen gesucht und möglichst viele der Fehler gefunden werden. Dazu ist gründliches und gut organisiertes Testen nötig. Das heißt aber, dass jemand anderes als der Programmierer selbst testen muss. Im Kasten werden verschiedene Testmethoden beschrieben.

Das Problem ist aber viel grundlegender. In der Regel werden Konventionalstrafen auf verspätete Auslieferung von Programmen gesetzt, oder die Zeit zum Markt als wichtigstes Kriterium gesehen. Es lässt sich aber jedes Programm in beliebig kurzer Zeit schreiben, einzig die Qualität und Sicherheit wird reduziert. Es ist daher essentiell, dass die Software-Qualität zum Abnahme-Kriterium wird.

Eine alte Ingenieursweisheit lautet: "Möchten Sie das Produkt billig, schnell oder gut. Bitte wählen sie höchstens 2 der Kriterien".

Aber wieso sollten Software-Firmen mehr Aufwand in die Fehlersuche stecken, der Kunde macht es sowieso gratis.

Was kann der Software-Benutzer machen?

Hier noch ein interessanter Link zur Website von Bruce Schneier. Er schreibt hier über die spezielle Problematik von Softwarefehlern in Wahlcomputern und hier noch ein Artikel aus news.com zum Thema Haftung und weitere Artikel zum Thema Haftung auf dieser Website.

Humoriges zum Thema "lausige Software" in einer ganz alten legendären EDV/IT-Persiflage: Real Programmers Don't Use Pascal (Pascal ist eine Programmiersprache, die dafür entwickelt worden war, dass weniger fehlerhaft programmiert wurde, nicht so schlampig wie heute fast überall mit der Programmiersprache C). Die deutsche Version heißt Echte Programierer meiden PASCAL (PDF, 220 KB).

Aktualisierung August 2010:
Ein interessanter Artikel mit einigen guten Punkten: Understanding the market for buggy software.

Aktualisierung Aug. 2011:
Ein interessanter Artikel So sue me: are lawyers really the key to computer security? sieht Licht am Ende des Tunnels: in den USA stellt die FTC (Federal Trade Comission, die Behörde gegen den unlauteren Wettbewerb) eine wichtige Kraft in diesem Bereich dar, da sie (korrterweise) davon ausgeht, dass das Ausliefern von noch-fehlerhafter Software einen Wettbewerbsvorteil verschaffen kann, weil sichere Software immer teurer sein wird. Sie bestraft derzeit Unternehmen sehr kräftig wenn deren Software oder deren IT-Infrastruktur zu unsicher war und die Sicherheitsverletzungen geführt hat. Sie macht z.B. Auflagen wie Security Audits durch unabhängige Firmen für die nächsten 20 Jahre, ein recht kostspielige Aktion.

Der Artikel verweist auch auf derzeit noch laufende Schadenersatzprozesse, z.B. gegen Sony oder gegen Dropbox. Auch das kann teuer werden. Ziel muss sein, die Entwicklung von unsicherer Software kostspielig zu machen.

Aktualisierung Okt. 2012:
Die NY Times weißt auf Probleme bei den elektronischen Krankenakten in den USA hin: The Ups and Downs of Electronic Medical Records. Die Systeme sind geprägt von Inkompatibilitäten und es kommt dadurch manchmal zu Behandlungsfehlern. Speziell problematisch ist eine übliche Klausel in den Verträgen mit den Software-Lieferanten, die diese von jeglichen Haftungen ausschließt und verhindert, dass die Krankenhäuser über solche Fehler öffentlich reden dürfen.

Sichere Software beginnt mit der Programmier-Ausbildung

Es finden sich jetzt (2008, 2009) immer mehr Initiativen, die versuchen, das Ausbildungsdefizit bei der Programmierung anzugehen. Dazu hier einige Bemerkungen und Ressourcen.

Aktualisierung Nov. 2007:
Auf einer Microsoft Veranstaltung habe ich ein interessantes Buch bekommen: 750 Seiten, "Writing Secure Code", mit einem Coverspruch von Bill Gates "Required reading at Microsoft". Vom ersten Durchschauen her scheint es ein sehr gutes Buch zu sein, die ersten 120 Seiten mehr theoretisch über Dinge wie Threat Modelling, denn 440 Seiten Secure Coding Practices, mit vielen Programmbeispielen, in denen alle wichtigen Themen wie Buffer Overrun, Fehler beim Einsatz von Cryptographie, Input Checking, Datenbankfehlnutzungen, Internationalisierungsfehler, aber auch MS spezifische Probleme wie ActiveX, DCOM und .NET ausführlich behandelt werden. Der Rest ist dann über Testen in Bezug auf Sicherheit. So ein Buch sollte Lehrbuch an den Programmierschulen, FHs und Unis sein.

Weitere Infos zu sehr guten Initiativen von Microsoft weiter unten.

Aktualisierung Jan. 2009:
Das SANS Institute veröffentlicht TOP 25 Most Dangerous Programming Errors, zusammengestellt von einem hochkarätigen Team von Software-Experten. Ziel ist, dass diese typischen Programmierfehler bei der Ausbildung stärker berücksichtigt werden und automatisierte Tools entwickelt werden die sich auf genau diese Programmierfehler konzentrieren. Im Bereich .NET Entwicklung gibt es dazu z.B. den FxCop.

Kurze Zeit später, eine sehr gute Replik zu "top nn Buglisten": Software [In]security: Top 11 Reasons Why Top 10 (or Top 25) Lists Don’t Work . Die Argumente klingen eigentlich alle recht einleuchtend, z.B. 50% der Verwundbarkeiten sind Design-Fehler, nicht Programmierfehler, Bugs sind nichts, was man Managern vermitteln kann. Manager verstehen (maximal) Risiken, aber nicht Details wie SQL-Injektion. Dieser kurze Text ist sehr lesenwert.

Joel Spolski schreibt regelmäßig über Probleme der Software-Entwicklung. Hier ein Link zu seinem Joel Test (englisch), der dazu dienen soll, die Qualität eines Software-Entwicklungsteams zu testen. Er hat dabei in sehr schöner Form seine 12 Hauptregeln für Software-Entwicklung zusammengestellt, Regeln, die ich gern unterschreibe.

• 1. Benutzt des Team eine Source Control Software, z.B. cvs ?
• 2. Kann ein „build“ in einem einzigen Schritt durchgeführt werden ? (jeder zusätzlich nötige Schritt ist eine weitere Fehlerquelle)
• 3. Werden „builds“ täglich durchgeführt ? (Fehler sollten so früh wie möglich entdeckt werden)
• 4. Gibt es eine Bug-Datenbank ?

  Wie reproduziere ich den Fehler?

  Wie sollte sich das Programm verhalten, wie verhält es sich wirklich?

  Wer ist verantwortlich dafür, den Fehler zu beheben?

  Was ist der Status des Fehlers?

• 5. Werden alle Fehler behoben, bevor weiterprogrammiert wird?

  Frühe Fehlerbehebung ist billiger

  Vermeidung von Folgefehlern, weil andere auf dem falschen Verhalten aufsetzen

  Der Projektfortschritt ist nur dann abzuschätzen, wenn ich nicht einen back-log von unbekannten Fehlern habe, deren Behebungsaufwand weitgehend unbestimmt ist

• 6. Wird der Projektfortschritt penibel verfolgt?

  Tricks dazu auf Projekt-Schedule

  Erlaubt z.B. frühzeitige Entscheidungen, welche Feature bei Zeitknappheit weggelassen werden

• 7. Gibt es immer schriftliche Spezifikationen?

  in diesem Stadium ist das Beheben von Fehlern am einfachsten

  Tricks dazu auf Progamm-Spezifikationen

• 8. Haben die Entwickler eine ruhige, ungestörte Arbeitsumgebung?

• 9. Wird in vernünftige Werkzeuge investiert ?

  große Bildschirme für viele offene Fenster !!

  gute Debugging-Software

  vernünftig schnelle Rechner für Compilierungen

  keine Belästigungen bez. „zu viel Plattenplatz verbraucht“

  „Bestechung“ durch „coole“ Technologie

• 10. Gibt es spezielle Tester?

  Selbst-testen ist die unproduktivste Art der Fehlersuche

• 11. Ist Programmieren Teil des Job-Interviews?

  Tipps dazu Job Interviews

• 12. Gibt es „Usability Tests“ mit absoluten Laien?

  ein gutes User Interface entsteht durch Feedback der User

  eine intuitive Nutzung der Software vermeidet viele der Benutzerfehler
  („Nein, das ist kein Bug, das ist ein Benutzerfehler“ - oder doch ?!?)

  Gute Tipps dazu UI Design

Ergänzungen von Philipp Schaumann:
Bei Microsoft hat sich in den letzten 5-7 Jahren auf dem Gebiet der Softwaresicherheit und -qualität einiges getan. Sie haben eine ganze Reihe von führenden Wissenschaftlern auf diesem Gebiet eingestellt und alle Programmierer mussten durch eine zusätzliche Ausbildung, die wohl recht gut ist. Jetzt wurde wieder (April 2007) die aktualisierte Version seines erstmals Ende 2004 vorgestellten Leitfadens "Trustworthy Computing Security Development Lifecycle" auf seinen Seiten verfügbar gemacht. Hier eine zusammenfassende Bewertung des Microsoft SDL process.

Auch in einer Information-Security Policy sollte (falls für das Unternehmen relevant) ein Kapitel zu Software-Entwicklung und Quellcode-Verwaltung sein.

Ein Link zu einem sehr interessanten 103-Seiten Dokument zu Aspekten der Fehlersuche und (vor allem) Fehlerbehebung - Bug Advocacy von Cem Kaner (pdf, 740 KB). Es ist so etwas wie ein "Guerilla-Handbuch für Software-Tester", wie bringe ich als Tester den Programmierer dazu, den von mir gefundenen Bug wirklich ernst zu nehmen und zu beheben?

Mai 2008:
Nachdem Tausende von Websites über SQL-Injektion mit Schadsoftware infiziert sind, die diese dann an ihre Besucher weiterverteilen, weist Microsoft auf ihre Best Practise Dokumente zur Webprogrammierung hin. Sehr empfehlenswert für Entwickler von Websites.

Dez. 2008:
Ein sehr hilfreiches Dokument für alle, die sichere Software entwickeln (lassen müssen) ist Fundamental Practises for Secure Software Development der Organisation SafeCode (pdf). Es enthält jede Menge Tipps (genereller Art, nicht auf programmier-technischer Ebene) und viele Links zu Ressourcen und Tools, z.B. für Code Quality Checking, etc.

Feb. 2010:
Microsoft hat jetzt als Ergänzung zu ihrem SDL Prozessen eine Simplified Implementation of the Microsoft SDL herausgebracht und damit den Lesestoff auf 18 Seiten reduziert, damit die Hemmschwelle zu besserer Programmierung gesenkt wird. Sehr lobenswert.

Aktualisierung Okt. 2012:
Microsoft hat eine hilfreiche Anleitung verfasst zur Security Usability bei Sicherheitsabfragen: Microsoft's NEAT und SPRUCE.

Im Original veröffentlicht in der Computerwelt Österreich

Augen zu und durch

Autor: Johannes Bergsmann

Als EDV-Sachverständiger muss ich bei der Erstellung von IT-Project-Reviews und Gutachten immer wieder feststellen, dass im begleitenden Qualitätsmanagement und besonders in der Anfangsphase eines Projekts schwerwiegende Fehler gemacht werden. Sehr oft sind Spezifikationen vorhanden, die diese Bezeichnung nicht verdienen oder inkonsistent und unklar verfasst sind. Und das ist vielfach der Grund, warum es im Projekt in späteren Phasen zu massiven Problemen kommt. Viele Projektverantwortliche auf Auftraggeberseite handeln in frühen Phasen nach dem Motto »Augen zu und durch!«. In späteren Phasen kommt dann das böse Erwachen!

Wenn ich in Gesprächen mit meinen Kunden die Mängel in den Spezifikationen aufzeige, kommen oft die Fragen: »Warum hat sich denn keiner diese Spezifikation vorher kritisch angesehen? Hat das denn keiner bemerkt?«. Und spätestens da taucht die Frage auf, wer denn diese Spezifikationen testet. Meine Erfahrung: Es gibt zwar in vielen IT-Unternehmen und auch Auftraggeber-Organisationen klare Regelungen für die Freigabe von Dokumenten (z.B. ISO 9000). Doch die Prüfer unterschreiben vielfach, ohne sich mit den Inhalten selbst auseinander gesetzt zu haben. Kaum eine Software-Spezifikation wird einem intensiven und strukturierten Review unterzogen!!

Dabei könnten durch Reviews, die in frühen Phasen des Projekts durch einen qualifizierten Reviewer durchgeführt werden, sehr viele Probleme und auch Zusatzkosten im Projekt vermieden werden.

Die durch Fehlersuche und Fehlerbehebung entstehenden Kosten innerhalb der Entwicklung werden mittlerweile auf 30-50% der Gesamtkosten geschätzt. Mehrere Untersuchungen zeigen auch auf, dass die Ursache für mehr als die Hälfte aller Fehler in Software-Projekten im Bereich der Spezifikation liegt! Der überwiegende Teil dieser Fehler in der Spezifikationsphase wird jedoch erst in der Abnahme oder Betriebsphase gefunden. Dadurch sind diese Fehler meist auch die Teuersten. Es ist notwendig, auf Methoden zu setzen, die helfen, diese Fehler zu vermeiden oder zu reduzieren. Spezifikations-Reviews sind eine geeignete Methode, um auch schon in sehr frühen Phasen der Software-Entwicklung die Spezifikationen einer kritischen Prüfung und Beurteilung zu unterziehen.

Eine Faustregel der Software-Entwicklung besagt, dass man sich für jeden Euro, der in der Spezifikations-Phase investiert wird, 10 Euro an zusätzlichen, nicht notwendigen Projektkosten erspart.

Netter Text von Joel Spolsky, hier der Gesamttext

Satire: Custom-developed Software

"Custom development is that murky world where a customer tells you what to build, and you say, 'are you sure?' and they say yes,

and you make an absolutely beautiful spec, and say, 'is this what you want?' and they say yes,

and you make them sign the spec in indelible ink, nay, blood, and they do,

and then you build that thing they signed off on, promptly, precisely and exactly,

and they see it and they are horrified and shocked,

and you spend the rest of the week reading up on whether your E&O insurance is going to cover the legal fees for the lawsuit you've gotten yourself into or merely the settlement cost.

Or, if you're really lucky, the customer will smile wanly and put your code in a drawer and never use it again and never call you back."

Hier mein Kommentar: ein sehr bekanntes Problem, das eine ganze Reihe von Ursachen hat. U.a. die Schwierigkeiten der Kommunikation zwischen den Entwicklern und den Anwendern.

• Haben die Anwender/der Kunde der die Spezifikationen mit "Blut" unterschrieben hat wirklich verstanden, was sie da bestellt haben?

• Hat der Kunde die Möglichkeit gehabt, an einem Prototypen/Mock-up zu testen, ob die Software den gewohnten Arbeitsweisen der Mitarbeiter gerecht wird?

• Hat der Entwickler wirklich verstanden, was der Kunde an Anforderungen in die Spezifikationen hineingeschrieben hat?

• Hat es wenigstens Screen-Mock-Ups oder Workflow-Ablauf-Diagramme gegeben, und zwar in einer Form, die beide Parteien verstanden haben?

So viele Möglichkeiten zur Miss-Kommunikation. :-(

Weitere Informationen

Hier ist ein Link zu einem sehr guten Text: Some thoughts on security after ten years of qmail 1.0 (pdf), in dem viele Prinzipien der Entwicklung von sicherer Software sehr kompakt dargestellt werden.

In meinen Notizen berichte ich über eine dramatisches Beispiel für schlechte Webprogrammierung: eine Behörde nutzt die vollständigen SQL-commands als URLs.

Ein sehr empfehlenswertes Buch und vollständig online verfügbar: David A. Wheeler - Secure Programming for Linux and Unix HOWTO. Und hier ein kurzer Überblick über die zur Zeit effektivsten Methoden zur sicheren Entwicklung von Software (pdf).

Wenn es um Web Applikationen geht, so ist OWASP eine Autorität und eine Fundgrube für hilfreiche Informationen. Z.B. der OWASP Testing Guide (pdf, 350 Seiten Testfälle, detailliert ausgeführt, inkl. AJAX).

Für Entwickler, die noch nicht so ganz mit den verschiedenen Angriffen vertraut sind, sind die OWASP Top Ten sehr zu empfehlen. Die Dokumentation enthält nicht nur einen Überblick über die wichtigsten Angriffe und Programmierfehler, sondern verweist auch auf entsprechende Resourcen, mit deren Hilfe Tester und Entwickler diese Schwachstellen vermeiden können.

Aktualisierung Juli 2011:

Software on the Witness Stand: What Should It Take for Us to Trust It?. Bei dieser Studie geht es darum, dass Software genutzt wird um Beweise zu erzeugen, und dass die möglichen Fehler oft nicht hinterfragt werden können, sondern dass oft von einer Objektivität des technisch erzeugten Beweises ausgegangen wird. Hier die PPT-Version des Artikels.

Ein gutes Beispiel für diese Fehlannahme ist der in dem Artikel nur beiläufig erwähnte Fall der Dräger Alcotest-Geräte aus 2009. Ein Amerikaner hat erzwungen dass man ihm den Quellcode vorlegt. Und der was dann atemberaubend: Der Mittelwert aus vielen Messungen wird gebildet in dem der 1. und der 2. Wert addiert wird, dann durch 2 geteilt, dann der 3. Wert dazu addiert, wieder durch 2, usw. Dabei wird nicht der Mittelwert über die Messreihe gebildet, sondern es werden nur die letzten paar Werte berücksichtig. Solch offensichtliche Fehler können sich in Software verstecken, die vom Gericht als objektiv herangezogen werden. Mehr zum Alkotest.

Interessant zu diesem Thema sind auch die monatlichen Zusammenfassungen der eklatentesten Computerfehler in Forum On Risks To The Public In Computers And Related Systems.

Philipp Schaumann, http://sicherheitskultur.at/

Home

Copyright-Hinweis:
Das Copyright des Materials auf diesen Webseiten liegt, falls kein anderer Autor genannt wird, bei Philipp Schaumann.
Diese Texte sind lizensiert unter der Create Commons Attribution-Noncommercial-Share Alike 2.0 Austria Lizenz. Natürlich gelten auch die Regeln des Fair Use und über Ausnahmen bzgl. der Lizenz kann jederzeit mit den Autoren gesprochen werden.