Software Sicherheit muss argumentativ durchgesetzt werden, da robuste Software nicht zum Nulltarif zu haben ist. Es gibt zwar viele öffentliche Fallbeispiele, es ist jedoch empfehlenswert, einen individuellen Business-Case zu rechnen. Dabei sollten die Gesamtkosten betrachtet werden. Zwei pragmatische Ansätze möchte ich kurz vorstellen:

1. Vermeidung von Kosten: ermitteln Sie, wie teuer es ist, eine Sicherheitslücke in einem produktiven System zu schließen. Sie müssen dazu Aufwände für Identifikation, Analyse und Beseitigung des Problems berücksichtigen. Ebenso müssen diverse Tests wiederholt werden. Nehmen wir an, Sie ermitteln auf diese Weise 1.000 EUR pro Sicherheitslücke. Wenn Sie also 100 Fehler in der Entwicklung verhindern würden,  würde dies Kosten von 100.000 EUR einsparen. Ein Teil davon könnte in die entsprechend präventiven Maßnahmen investiert werden. Problematisch ist hier allerdings das K.O.-Argument „es ist doch noch nie etwas passiert“. Daher könnte sich Variante 2) als zielführender erweisen.
2. Identifizieren Sie, welche Risiken es in den Business-Anwendung gibt. Bei einer Anwendung, die Personaldaten verarbeitet, ist dies beispielsweise die Offenlegung von Daten. Bei einer Finanz-Applikation die Manipulation von Daten. Bei einer Produktionssteuerung die Verfügbarkeit und Nachvollziehbarkeit.  Üblicherweise existieren für den Eintritt solcher Risiken auch Schadenserwartungen. Wenn Sie nun in einem weiteren Schritt zuordnen können, welche Klasse von Sicherheitslücken und Angriffen zum Eintritt eines Schadens führen, können Sie Testergebnisse aus Stichproben in ihrer Applikationslandschaft direkt auf das Risikomanagement abbilden. Sie haben dann vergleichsweise belastbare Zahlen (sprich: „echte“ Risiken und harte Fakten aus den Stichproben), mit den es u.U. leichter argumentieren lässt als mit eher hypothetisch vermiedenen Problemen.

Wenn Sicherheit von Anfang an berücksichtigt wird, gehen wir davon aus, dass nach initial höheren Investitionen zum Aufsetzen der notwendigen Prozesse, Erstellen der benötigten Inhalte (Training), sowie der Beschaffung geeigneter Tools, der Nutzen die Kosten deutlich überwiegen wird - nachweislich. Wir raten daher dazu, einen Business Case für Software Security Tests zu erstellen. Und diesen dann im Laufe der Zeit zu validieren.

We are in the 21st century and IT organizations largely operate in a 20th century model – that is they are usually built around silos operating in isolation from one another.

Focus on change within you quality assurance (QA) organization to break the silos that have been built up around development, QA and operations.  Focus on communication, collaboration and connectivity among the three main groups of IT.  Highly optimized IT organizations have included the role of architect for each of the three major areas – development, QA and operations.

A focus on change in the QA organization will help your organization be more focused, competitive and quality driven.

Start to think of the QA organization as a customer advocate and a strategic business partner who can work with the line of business to meet their needs.

Yesterday at the Software Quality Conference in Zurich, I gave a keynote about Measuring Security and discussed this very interesting topic from different points of view (attacker view, suit view, geek view, etc.). It was great to see that the Quality community has a very natural attitude to security and that many quality assurance concepts can be applied for measuring security aspects, too.

At the end of the talk, I was asked how much of the development budget should be spent for security. After a short pause for thinking, the simple answer was “2%”. An interesting discussion followed. How many people have planned more, exactly or less (including 0) than 2%. Another category was a few people that simply did not know the security budget.

The beauty of defining such a budget for security lies in 2 (maybe more) things. First, you make people think whether they considered security in the development lifecycle at all. Second, you can gather some experience, see whether (in this case) 2% are enough and adjust the value according to your needs.

I’d be interested in your thoughts and your experiences regarding the big question “how much security is enough?”.

Die Industrialisierung des Application Managements ist in aller Munde. Unter Industrialisierung im Bereich der Industrieproduktion kann sich jeder etwas vorstellen. Doch was heißt dies im übertragenen Sinne für die IT bzw. für das Application Management?
 

Unter Industrialisierung der IT versteht man die Automatisierung und Standardisierung des IT- Leistungsprozesses durch die Übertragung bewährter Methoden und Prozesse aus dem Bereich der industriellen Fertigung. Im Bereich des IT-Betriebes findet man heute den höchsten Grad der IT-Industrialisierung vor. Dieses wird u.a durch Prozesse wie ITIL vorangetrieben.
 

Doch wie steht es um die Industrialisierung in der Anwendungsentwicklung und dem Application Management ? Letzteres insbesondere vor dem Hintergrund des Hype-Themas Application Management Outsourcing und Offshoring.
 

Heerscharen von Informatikern, Mathematikern und Physikern haben sich im Verlauf der letzten 3 Jahrzehnte Mechanismen wie Lines of Code pro Entwicklertag, Zyclomatische Komplexität, Function Points, Wartbarkeitsindikatoren und vieles mehr einfallen lassen, um die qualitative und quantitative Leistungserbringung des Applikation Managements zu bewerten und zu beziffern. Gerade im Zeitalter von SOA, Mainframe, C/S, WebServices etc. ist die eindimensionale Bewertung im höchsten Masse überfordert. 
 

Da ist uns die klassische Fertigungsindustrie weit voraus. Hier ist zu jeder Zeit transparent, wer, was, wann, in welcher Qualität, mit welchen Aufwand erbracht hat.
 
Im Application Management sind wir zwar in der Lage die Funktionalität und Skalierbarkeit der Anwendung zu überprüfen: Doch bleibt es uns in den meisten Fällen - und ganz besonders beim Outsourcing und Offshoring - trotz ausgefeilter Entwicklungsprozesse im Verborgenen, die eigentliche Leistungserbringung zu bewerten. Fragen wie: Habe ich eine wartbare Software erhalten? Erfüllt diese meine Ansprüche hinsichtlich Flexibilität bei zukünftigen fachlichen Änderungen? Ist eine preislich gerechtfertigte Leistung erbracht worden? Ist die technische Qualität der Lieferung „state of the art“? Wurden meine Architekturvorgaben eingehalten? Ist meine Software nach Ablauf des Application-Management-Vertrages leicht nach intern oder auch extern übertragbar? Wie kann ich Entscheidungen auf höchster Ebene (IT Governance) treffen, ohne zu all den bestehenden Informationen wahre Transparenz über mein Application Management zu haben?
 

Zur Beantwortung all dieser quälenden Fragen ist es unabdingbar die BlackBox Softwarelieferung zu öffnen, zu röntgen und aus verschiedenen Blickwinkeln zu bewerten.
 

Projekte mit namhaften Konzernen und Systemintegratoren haben uns innerhalb der letzten Jahre in dem Vorgehen bestärkt, mit der CAST Application Intelligence Platform einen entscheidenden Beitrag zu Industrialisierung des Application Managements zu liefern.

Durch die ganzheitliche Analyse des Applikationsportfolios ist es beispielsweise großen europäischen Telekommunikatiosunternehmen gelungen, mehr Transparenz in die externe Applikation-Management-Leistung zu bringen und so genannte Best In Class Supplier Programme aufzulegen.
 

Im Umkehrschluss ist es auf Basis dieses Ansatzes der internen Anwendungsentwicklung sowie großen Applikation-Management-Providern gelungen, ihre Leistungsfähigkeit zu dokumentieren und anhand valider Kennzahlen aufzuzeigen. Transparenz auf beiden Seiten, der „Demand“ und „Deliver“ Seite, hat an vielen Stellen zu einer Entschärfung der Vorurteile und zu einem professionellerem Miteinander geführt.
 

Entscheidend für den Erfolg dieses KPI-Ansatzes ist ein offener und fairer Dialog beider Seiten im Vorfeld, um Missverständnissen und Fehlinterpretationen proaktiv zu begegnen.     
Fragen wie: Warum messen wir? Was messen wir? Welche Managementkennzahlen erheben wir? Welche Maßnahmen leiten wir ab? Wie priorisieren wir? etc. sollten im Vorfeld geklärt sein.
 

Auf diesen Erfahrungen basierend sind wir davon überzeugt, mit diesem Ansatz der Bewertung des Application Managements einen wichtigen Baustein zur Erreichung von mehr Transparenz und zur Industrialisierung der IT beizutragen.