Software Bugs

Microsofts grosser Hoffnungsträger Windows 8 sei noch gar nicht fertig, mutmasst Intel Chef Paul Otellini. Das neue Betriebssystem benötige immer noch Verbesserungen. Vor allem ist Redmond dabei, möglichst viele Software-Bugs zu entfernen. Denn nichts schadet dem Image und zerstört das Vertrauen der Kunden mehr, als die fiesen Software-Fehler. Auch viele mobile Devices haben ein Sicherheitsproblem, die einen mehr, die anderen weniger. Wie testet man Software richtig, und worauf sollten Endkunden ein besonderes Augenmerk legen? CW sprach mit den SQS-Sicherheitsexperten Daniel Spirig und Karsten Pech. Daniel Spirig ist Managing Director Switzerland bei SQS Software Quality Systems (Schweiz), Karsten Pech verantwortet den Markt in der Schweiz und Deutschland.  

Spirig: Software-Testing ist heute effizienter und wirksamer als noch vor zehn Jahren. Heute verfolgt man einen risikobasierten Ansatz, priorisiert also sicherheitsrelevante Fehler und testet sie ab. Bei nicht kritischen Fehlern, die keine wesentlichen Auswirkungen auf das Image, Umsatz/Kosten oder die Kundenzufriedenheit haben, zeigen Firmen Mut zur Lücke. Je nachdem, wie geschäftskritisch die getestete Applikation ist.

Das läuft in Abhängigkeit von Applikation und Geschäftsfeld auf eine Anwendung der 80:20-Regel hinaus: Man konzentriert sich auf das grösste Risiko und fährt es entsprechend der Kritikalität der Anwendung auf ein vertretbares Mass herunter. Das Risiko wird minimiert. Die sicherheitssensitive Medizinbranche etwa deckt sämtliche Risiken ab und verfährt nach einer 100-Prozent-Regel. Unternehmen wie Online-Portale wenden die 80:20-Regel an.

Pech: Die Verfahrensweisen haben sich tatsächlich verfeinert. Ethical Hacking wird immer noch angewendet...

Pech: Heute beginnt man den Testprozess viel früher, als es vor fünf bis zehn Jahren zum Beispiel durch Penetrationstests üblich war. Heute startet man bereits während der Anforderungsanalyse, um Sicherheitslücken prospektiv auszuschliessen. Dann geht es weiter bei Design und Implementierung mit statischen Security-Analysen auf Basis des entwickelten Codes. Im nächsten Schritt folgt das sogenannte "Fuzzing". Darunter versteht man letztendlich Hacker-Angriffe, aber von innen aus dem Code heraus, gegen die Schnittstellen, also die möglichen Angriffspunkte. Am Ende des Testzyklus stehen die bewährten Penetrationstests, dass heisst Attacken von aussen. Nächste Seite: So testet Microsoft 

Spirig: Microsoft und andere Applikationssoftware-Anbieter testen heute sehr eingehend und nach bestem Wissen und Gewissen. Security hat heute ein viel grösseres Gewicht als früher. Sie haben vorhin das Katz-und-Maus-Spiel erwähnt. Ich glaube, die Distanz zwischen Katze und Maus ist heute kleiner geworden. Aber wer Software auf den Markt bringt, ist natürlich in einem proaktiven Modus und gibt dem anderen Zeit, zu investieren, Lücken zu suchen, daran zu arbeiten. Der Anbieter ist immer ein wenig hinten dran, das kann man glaube ich nicht verhindern.

Pech: Entscheidend ist der Zeitpunkt, wann diese Lücken entdeckt werden, um noch geeignete Gegenmassnahmen ergreifen zu können. Die typischen Gegenmassnahmen, wie man sie in der Software-Entwicklung heute noch anwendet, kommen eindeutig zu spät. Dazu gehört das "Fuzing", das sehr spät im Software-Entwicklungszyklus stattfindet, oder Penetrationstests nach Fertigstellung der Software.

Pech: Das ist State-of-the-Art, jedoch haben wir diese Methoden deutlich verfeinert. Die Software-Parser laufen entlang des Kompilerungs- und Build-Prozesses über Nacht mit. Die Grundsätze der SQS Security Services beginnen viel früher: durch Threat-Modelling während der Anforderungsanalyse, gefolgt von Architektur-Reviews...

Pech: Sie müssen bedenken, dass auch noch unternehmensinterne Policies hinzukommen, die beachtet werden müssen. Das von Ihnen erwähnte 2-Ways-Testing würden wir als dritte Stufe eines SQS Security Services sehen. In der ersten Stufe, dem Threat-Modelling, werden zukünftige Angriffsszenarien simuliert. Dadurch werden Sicherheitslücken geschlossen, bevor sie überhaupt entstehen können.

Nächste Seite: Vorsicht - riskanten Architekturen

Pech: Das wären zum Beispiel Logging-Mechanismen, also die ungefilterte Behandlung von Benutzereingaben, Verschlüsselung und Abkapselung. Modifikationen müssten in der dann zu ändernden Systemarchitektur abgebildet werden. An dritter Stelle steht bei uns die "static security analysis", dass heisst die Sourcecode-Analyse, ihre erste Stufe. Die statischen Analyzer prüfen den Code, der in einem Programmierzyklus, zum Beispiel einem Sprint, entsteht, gegen diverse Sicherheitskriterien. Danach kommt bei uns das oben erwähnte sogenannte "Fuzzing" von innen gegen die Schnittstellen, und als fünfte Stufe Penetrationstests, ausschliesslich von aussen und unter Realbedingungen. Wir empfehlen, Penetrationstests gegen die Produktivumgebung auszuf¨hren, nicht gegen eine Testumgebung.

Spirig: Wenn heute eine grosse Firma budgetiert, dann entfallen etwa 25 Prozent von Projektbudget auf das Testing. Vor fünf Jahren waren das noch 15 bis 18 Prozent, heute sind es definitiv 25 Prozent. Grossfirmen folgen diesem Richtwert.

Pech: Heute werden bereits gewisse Test-Ressourcen in der Cloud angeboten, zum Beispiel Lastgeneratoren für Performance-Tests. Eine Serverlast müssen Sie also nicht zwingend selbst bereitstellen. Das ist heute schon gängige Praxis.

Spirig: Aus meiner Sicht kann man das bejahen: Es gibt sicherere und unsicherere Plattformen. Der Kunde ist auch ein Stück weit selbst für die Sicherheit der Software, die er einsetzt, verantwortlich. Er sollte nicht Software unter einer Lizenz herunterladen und davon ausgehen: Alles ist ok. Sicherheit untersteht der Eigenverantwortung des Kunden.

Spirig: Es gibt sicher Unternehmen die testen besser, und andere testen schlechter. Der Bankenbereich zum Beispiel, also Anbieter von Bankenlösungen, stellt sehr hohe Anforderungen punkto Sicherheit und weist auch aus, was er getestet hat, und was nicht. Aber der Kunde ist auch in der Eigenverantwortung. Viele Kunden kommen auf uns zu und sagen: Unser Software-Lieferant hat geliefert, könnt ihr das fertige Produkt mal beurteilen. Auf der einen Seite gibt es die Dokumentation des Herstellers, auf der anderen Seite die Compliance-Anforderungen des Kunden, gegen die zusätzliche Security-Tests durchgeführt werden.

Nächste Seite: So sichern Sie ihre Software

Pech: Je nach Grad der Kritikalität und des Sicherheitsbedarfes empfehlen sich zusätzliche Penetrationstests, um den Nachweis zu erbringen, dass die Software tatsächlich sicher ist. Ausserdem das oben erwähnte "Fuzzing" gegen Systemschnittstellen. Wir als SQS bieten Test- und Beratungsdienstleistungen an, führen die Tests auch bis zur letzten Konsequenz durch.

Pech: Das Sicherheitsbewusstsein ist definitiv vorhanden, und im mitteleuropäischen Vergleich würde ich die Schweiz ganz weit vorne positionieren, nicht zuletzt wegen der Finanzindustrie und deren Regulatorien. Allerdings ist das Bewusstsein, Massnahmen weit vorne im Software-Entwicklungszyklus anzusiedeln, vielleicht noch nicht ganz so stark ausgeprägt.

Pech: Die Wahrscheinlichkeit, sicherheitskritische Fehler beseitigen zu können, ist dann deutlich höher.

Spirig: Die Schweizer Grossbank UBS hat kürzlich einen Vertrag mit einer Laufzeit von zunächst zweieinhalb Jahren bei SQS unterschrieben. SQS stellt ein Team von etwa 50 Experten zur Verfügung und führt qualitätssichernde Massnahmen vor Ort bei der UBS in Zürich durch.

Spirig: Totalkatastrophen dürfen wir ihnen nicht nennen. Aber der Umsatz- und vor allem der Imageverlust, der mit erfolgreich ausgeführten Angriffen einhergeht, hat die Firmen schon sehr stark sensibilisiert.

Pech: Bei mobilen Betriebssystemen könnte man eine solche Hierarchie aufstellen: Symbian etwa ist ein noch in Asien verbreitetes, sehr lange auf dem Markt befindliches Betriebssystem. Hacker hatten viel Zeit, Malware für Symbian zu programmieren. Symbian ist daher sehr unsicher. Als zweites, sicherheitskritisches mobiles OS würde ich, aufgrund der offenen Architektur, Android sehen. Auch sind die Sicherheitsprozeduren von Google Store noch nicht so ausgereift. Jeder kann seinen eigenen App Store betreiben. An dritter Stelle, nach oben aufsteigend, rangiert Apples iOS. Das originale Apple iOS ist sicher, aber Jailbreaks ermöglichen Veränderungen des Betriebssystem. Als sicherer als die bereits erwähnten drei Systeme beurteile ich Windows. Windows bietet zwar sehr viel Funktionalität, ist aber auch sehr gekapselt, was die Sicherheit erhöht. Sicherheitskritische Risiken beziehen sich jedoch zunehmend auf den Versand von SMS, die mein Adressbuch verwenden. Am sichersten ist Blackberry, auch wegen der aktuell geringeren Verbreitung. Insofern bewahrheitet sich ihre anfängliche Vermutung über exotische, sichere Systeme. Blackberry gilt mittlerweile als exotisch.