Bei der Software-Entwicklung kommt es sowohl auf Kreativität und komplexe Anforderungen zur Problemlösung an als auch auf hohe Qualität. Das alles auch unter permanenten Zeitdruck. Ein Aspekt, der zunehmend von Kunden gefordert wird ist außerdem Security. Damit das nicht zum ungeliebten Störfaktor wird braucht es eine praxisgerechte Integration der Sicherheitsmaßnahmen in den Entwicklungsprozess. Mit welchen Mitteln sich dies umsetzen lässt, zeigt die BSIMM12-Studie.

Funktionale Anforderungen für moderne Prozesse

Moderne Prozesse zu Software-Entwicklung beruhen häufig auf funktionalen Anforderungen, die aus Märkten kommen, die eine schnelle Umsetzung verlangen. Das liegt zum einen an der immer rasanter fortschreitenden Digitalisierung und zum anderen an den Erwartungen der Endkunden mit ihrer ganz eigenen Dynamik. Wer als IT-Anbieter bestimmte Funktionen nicht anbieten kann, gerät gegenüber der Konkurrenz schnell ins Hintertreffen. Gestern kam die Etagenheizung mit Thermostaten und einer einfachen Zeitsteuerung aus, heute muss sie übers Internet und Mobilfunk-Apps fernsteuerbar sein. Gestern noch konnte die Schweißmaschine im Betrieb autark ihre Programme abarbeiten, heute soll sie in Echtzeit statistische Daten über den Schweißdrahtverbrauch und mögliche Umwelteinflüsse ans Management liefern. Das zweite Beispiel zeigt: Neben den funktionalen Wünschen sind zudem schärfere Compliance-Anforderungen im Spiel, mit denen zuerst die Anwender in ihrem Tätigkeitsbereich zu tun bekommen. Den daraus resultierenden Druck reichen sie an ihre Zulieferer durch. Das zentrale Thema allerdings ist die Umsetzungsgeschwindigkeit. Eine Anforderung, die sich häufig in der abstrakten Forderung nach agilem Vorgehen äußert – auch bei der Software-Entwicklung. Wer das nicht leisten kann oder Bedenken anmeldet, wird schnell als rückständig eingestuft und läuft Gefahr, die Gunst des Kunden zu verlieren.

Software-Entwicklung stützt Digitalisierung

Die Funktionalität moderner Systeme geht zu einem großen Teil auf die Leistung von Software-entwicklern zurück. Die Schere zwischen Zeit- und Qualitätsvorgaben bei dieser durchaus anspruchsvollen Problemlösungstätigkeit klafft allerdings immer weiter auseinander. Mit der Digitalisierung und einer zunehmenden Konnektivität steigen aber nicht nur die Vorgaben in Sachen Sicherheit und Datenschutz. Auch die Auswirkungen im Schadensfall sind potenziell nicht absehbar. Das klassische Qualitätssicherungssystem der Softwareentwicklung aus zentralisierten passiven und aktiven Tests, passt vor diesem Hintergrund kaum noch zur modernen Arbeitspraxis. Dieses System greift dann, wenn die Entwickler Fortschritte gemacht und „Meilensteine“ erreicht haben – und wirft sie im Fall von aufgedeckten Schwachstellen oder Verwundbarkeiten mitunter weit zurück. Das zähe Vor und Zurück und gegebenenfalls das wiederholte Durchdenken bereits überwunden geglaubter Herausforderungen macht Sicherheitstests in den Augen der Entwickler zu einem schlecht kalkulierbaren Störfaktor. Was aus Sicht der Kunden die Problemlösung ist, wird für die Programmierer selbst zum Problem. Aus arbeitspsychologischer Sicht, aber auch unter Effizienzgesichtspunkten ist das gewohnte Testmodell in größeren Abständen fragwürdig geworden und erweist sich sogar als kontraproduktiv – auf jeden Fall kann eine Qualitätssicherungsmaßnahme unter diesen Bedingungen kaum ihre eigentliche Wirkung entfalten.

Security als Zukunftsstandard

Es stellt sich die Frage, ob sich der Störfaktor Sicherheit als solcher überhaupt eliminieren lässt. Moderne DevSecOps-Verfahren neutralisieren zumindest unschöne Nebenwirkungen und machen Security zu einem akzeptierten Bestandteil des Entwickleralltags. Ziel ist es, Sicherheit aus dem nicht funktionalen in den Bereich der funktionalen (und akzeptierten) Anforderungen zu rücken. Der „BSIMM12 – 2021 Insights & Trends Report“ belegt, dass entsprechende Strategien bereits von Softwareentwicklern in spezialisierten Unternehmen und Abteilungen angenommen werden und sich zu einer Art Zukunftsstandard für die Branche entwickeln könnten. In vielen Lebens- und Arbeitsbereichen war und ist Sicherheit integraler Bestandteil. Dort tritt sie aber nicht nur hin und wieder als drohende Prüfung auf den Plan, sondern ist Teil jedes einzelnen beruflichen oder privaten Schritts: Umgebung prüfen, Ausrüstung prüfen, den nächsten Schritt genau planen – hier operieren die Akteure mit permanenter Aufmerksamkeit und kleinen Zwischen-Checks, die ihr Fortkommen aber nicht unterbrechen. Das bedeutet: Sicherheit ist integriert und gehört genau zu den Praktiken, die weiterführen.

Security-Strategien für die Software-Entwicklung

Im Bereich der Softwareproduktion lässt sich das Prinzip der integrierten Sicherheit mit speziellen Vorgehensweisen und Werkzeugen erreichen. Laut BSIMM12 setzen sich derzeit in der Praxis vor allem folgende Strategien durch:

• Bereits vor Projektbeginn ermitteln die Entwicklerteams die mit dem jeweiligen Projekt verbundenen und möglichst auch die für den späteren Betrieb wichtigsten Risiken. Die Ergebnisse bilden einen Orientierungsrahmen für den gesamten Entwicklungsprozess, so dass kritische Schwächen gezielt und frühzeitig angegangen werden können.
• Die Entwickler klären zusätzlich mit den Incident-Response-Teams im eigenen Haus und/oder beim Kunden die reale Bedrohungslage gleich zu Beginn so weit wie möglich, sprechen Security-Funktionen und -Maßnahmen mit dem Kunden ab, sondieren die Akzeptanz für ihre Vorschläge und spezielle Compliance-Anforderungen wie etwa solche aus dem Schutzbedarf personenbezogener Daten. Vorgaben, die sich aus diesen Themenfeldern ergeben, werden danach auf die gleiche Weise ins Zielspektrum aufgenommen wie funktionale Anforderungen.
• Man legt viel Wert darauf, geeignete Tool-Sets für Tests aufzubauen und diese so weit wie möglich zu automatisieren und zu orchestrieren. Es gibt eine ganze Reihe von bewährten Application Security (AppSec)Tools, die Teilbereiche der Applikationstests abdecken. Je nach Einsatzzweck eines Softwareprodukts sollten diese Werkzeuge passend kombiniert und die Ergebnisse zueinander in Beziehung gesetzt werden. Außerdem gilt es, die Ergebnisse für alle am Projekt Beteiligten aufzubereiten und das Beheben von Schwachstellen mit Rücksicht auf geplante Einsatzszenarien zu priorisieren. Auch das Tracking von Maßnahmen, die sich aus Testergebnissen ergeben, sollte automatisiert erfolgen, um die produktiven Teams nicht mit quasi buchhalterischen Aufgaben zu belasten.
• Integriertes, schrittweises Testen nimmt zu: Die Entwickler setzen eher auf kleinteilige, häufiger stattfindende und aktivitätsbezogene Tests und Security-Betrachtungen statt auf groß angelegte, seltene Milestone-Assessments. Ein gutes Beispiel ist die Entscheidung, für einen bestimmten Funktionsbereich Open-Source-Module heranzuziehen und einzubinden, um Zeit zu sparen. Die entsprechenden Komponenten sollten in solch einen Fall sofort auf bekannte Risiken abgeklopft und gegebenenfalls passiven und/oder aktiven Tests unterzogen werden. Auch das reduziert unliebsame Überraschungen zu einem späteren Zeitpunkt. Überraschungen, die eventuell zu einer Neuentwicklung größerer Softwarebausteine unter dann noch größerem Zeitdruck führen.
• Die Entwickler stellen sicher, dass das zu erreichende Sicherheitsniveau nicht nur von ihrer Arbeit abhängt. Netzwerk- und Host-Sicherheitsmaßnahmen für die Entwicklungs- und Betriebsumgebung werden bewertet und – soweit sie im Einflussbereich der Entwickler liegen – gezielt optimiert, um die Software während der Entstehungsphase und möglichst auch im Betrieb angemessen zu schützen.
• Externe Tests nehmen zu: Externe sehen manchmal mehr als (zuweilen betriebsblinde) Insider. Entwicklerteams ziehen deshalb häufiger als früher externe Testspezialisten hinzu, um ihre Produkte auf den Prüfstand zu stellen, und adaptieren so eine in anderen Security-Bereichen längst gängige, bewährte und von Regularien zuweilen schon explizit eingeforderte Praxis.

Zusammengenommen erlauben derartige Maßnahmen eine Softwareentwicklung, die Security-Anforderungen als gegebene Rahmenbedingung annimmt und die damit verbundenen Maßnahmen so tauglich und so wenig disruptiv wie möglich zu gestalten. Vor allem die kleinteiligen, automatischen Tests verhindern, dass während eines Entwicklungsprozess allzuoft das demotivierende Gefühl des Scheiterns und der Abwertung der erzielten Ergebnisse auftritt. Sicherheit ist bei diesem Modellen allgegenwärtig, aber nicht als Störfaktor, sondern auf der Idee des „shift everywhere“. Den Entwicklern und ihren Resultaten kann dieses Konzept nur gut tun.

Mehr Informationen finden Sie hier.