Lausige Software

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

 

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

Computerwelt, 3. 4. 2015: Software-Unternehmen zu 150.000,- Schadenersatz verurteilt. - Produktionsausfall von 5 Tagen aufgrund von Daten-Beschädigung durch diese Software.

Kann das auch heute schon passieren? Leider nein!

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 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.

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.

Hier zurerst ein bissiger Artikel, der eine sehr ähnliche Message hat: das eigentliche Sicherheitsproblem sind die Programmierer, die in ihrer Programmierung die Sicherheit vernachlässigen. Der Vorschlag hier: Die Ausbildung verbessern, in dem sichere Programmierung als Teil der Ausbildung aufgenommen wird.

Security Wire Perspectives, Vol. 6, No. 86, November 15, 2004

SOUND BYTES

*MICROSOFT TOSSING MONEY AWAY

In its pursuit of more secure software, Microsoft announces $1 million in grants to support development advances, but it's unlikely to make a difference.
By Ira Winkler, CISSP

Microsoft recently held a get-together for educators, and it was refreshing to see that a key focus was on security. This is not overly surprising as Microsoft does have a major focus on security. They also used this opportunity to announce that they were giving away $1 million in grants to support advances in secure software development. At face value, that sounds great. The reality is that this is likely going to be a big waste of money.

Let's face it, little research actually makes a measurable improvement in its targeted field. As a matter of fact, it isn't supposed to. Optimistically, academic research is generally to examine previous research in some other way. There are some great innovations, but almost all of them rot in some obscure journal, read by a few hundred researchers and students.

However, this money from Microsoft seems to be intended to create a few "centers of excellence" for secure software development. These centers will supposedly turn out experts in secure software implementation. In my opinion, even if you assume that this will accomplish such a noble goal, it's still a waste of money.

Yes, I know. My statements are sacrilege to the security community and especially the academic community. However, think about it: Does the problem of generally poorly written software, from a security perspective, result from not having enough security experts? You security experts may think so, but the reality is that the problem results from the hundreds of thousands of software developers out there who have no clue about writing secure software.

Do you think that a few dozen experts in writing secure software are going to make significant improvements to the overall problem? You have to be delusional to think so.

What will significantly improve the overall state of security is getting the average programmer to write secure software. Centers of excellence do not do that. They sound good for PR purposes, and maybe they will make a few notable improvements in design principles. However, unless they can scale to reach every possible software development effort, or even a measurable number of them, they have little practical value.

So what should Microsoft do with its $1 million? First, don't give it to experts in the security field. Now I moved from sacrilege to heresy. To teach the largest number of people how to develop secure software, you have to get to the people who write software engineering textbooks for college courses. Since it seems like there are probably less than a dozen books on the subject commonly used in colleges, a very small set of authors can be targeted.

It is my strong recommendation that Microsoft find those authors and give them a "grant" to update their textbooks. The grant would mandate adding a new chapter to their book specifically on secure software development.

This is actually a double win. Students can no longer buy used textbooks because of the new version, so the authors will get more royalties. For the profession, more software developers will have the appropriate basic training. Yes, I know this isn't perfect. But it does reach exponentially more programmers than any center of excellence ever will.

The fact is we don't need revolutionary research to improve poor development practices. We need to get the software developers to apply the best practices that have been around for more than a decade.

IRA WINKLER, CISSP, CISM, has almost 20 years of experience in the intelligence and security fields and has consulted to many of the largest corporations in the world. He is also author of the forthcoming book, Spies Among Us.

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?

Aktualisierung Dez. 2006:
Die Initiative "Deutschland sicher in Netz", DSIN, bietet u.a. auch eine recht gute Anleitung für sicheres Programmieren.

Aktualisierung 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.

Aktualisierung 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.

Aktualisierung 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.

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.

Ergänzung April 2008:
Hier ein Link zu interessanten Studien zu den Themen Softwareentwicklung, Software-Projekte und Entwicklungstools

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

An anderer Stelle mehr zum Thema Sicherheit von Webservern.

Aktualisierung Juli 2008: Einige interessante Ressourcen zum Thema sichere Programmierung.

Aktualisierung März 2007: SANS hat ein neues Programm zur Zertifizierung der Sicherheitsskills von Software Entwicklung aufgesetzt - das Software Security Institute. Das ist ein sehr guter Schritt in die richtige Richtung, noch besser wäre allerdings, wenn Sicherheitsfragen und die Techniken zur Entwicklung sicherer Software ein integraler Bestandteil jeder Programmierausbildung wären. Die Kosten für die Zertifizierung sind mit 400 US$ durchaus erträglich.

Hier ein Artikel zu Fuzzing, der automatisierten Technik, mit der heute die Angreifer die vielen Verwundbarkeiten in der Software finden können.

Und noch was von den Angreifern (Nov. 2007): ein Artikel in DarkReading erklärt, wie man den Browsing für Angriffe verwenden kann, bzw. welche Browser-Plugins der Software-Tester oder der Sicherheitsspezialist verwenden sollte, um zu sehen, welche Daten eine Web-Anwendung wirklich mit dem Browser austauscht. Speziell wenn es um AJAX-Anwendungen geht, so ist ohne solche Hilfsmittel kaum noch zu erkennen, was wirklich an Daten ausgetauscht wird.

Diese Geschichte aus dem Jahre 2005 ist eine gute Illustration der Forderungen eines NSA Mitarbeiters auf einer Sicherheitskonferenz, nämlich, dass er Assurance von den Sicherheitsprodukten erwartet (PDF, englisch). Was er damit meint, ist, dass ein Sicherheitsprodukt (und eigentlich jede kommerzielle Software) nicht nur die Funktionalität bieten sollte, die der Hersteller propagiert, sondern auch dagegen gefeit sein muss, dass ein böswilliger Angreifer nicht andere, nicht erwünschte Funktionalitäten (d.h. "bugs") für seine bösen Zwecke missbrauchen kann. Zu diesem Zweck müssen diese bösen Intentionen bereits im Design-Prozess, bei der Entwicklung selbst und vor allem beim Testen bereits einkalkuliert werden. Dies geschieht ganz offensichtlich nicht, siehe oben.

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.

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.