Skip to main content

Secure Development Lifecycle

Was brauche ich, um ein sicheres Produkt zu entwickeln?

Wir begleiten und unterstützen Sie über den ganzen Entwicklungsprozess hinweg.

Sichere Softwareentwicklung beginnt bereits früh im Entwicklungsprozess: Fehlen Security-Elemente schon am Anfang der Entwicklung, steigt die Wahrscheinlichkeit, dass die Softwaresysteme oder Produkte bei der Auslieferung kritische Sicherheitsschwachstellen beinhalten, die sowohl für den Hersteller als auch für den Systembetreiber Security-Risiken erzeugen. Sie können sich am gesamtem Weg zu einem Secure Software Development Lifecycle auf die Unterstützung durch Limes Security verlassen. Sei es, um Softwaresysteme auf kritische Sicherheitsschwachstellen zu testen, bei der Ursachenermittlung und Behebung zu unterstützen, den bestehenden Softwareentwicklungsprozess zu analysieren oder die Integration von Security-Aktivitäten in die Entwicklungsabläufe voranzutreiben. Limes Security hat langjährige Erfahrung in der Unterstützung von Entwicklern und Herstellern bei der Einführung und Verbesserung von Security in der Softwareentwicklung, gestützt durch den Standardteil IEC 62443-4-1.

Analyze and improve your secure development lifecycle

Define and measure security-related activities

Build a balanced software security assurance program

|

Unsere Dienstleistungen

Secure Development Consulting

Durch die Integration von Security in die Organisation und Entwicklungsprozesse sowie der Definition von realistischen und anwendbaren Vorgaben wird für die Mitarbeiter eine Grundlage geschaffen, um sichere Software zu entwickeln. Mithilfe von gemeinsamen Workshops und der Unterstützung bei der Erstellung und dem Review von Dokumenten können Maßnahmen für einen sicheren Entwicklungsprozess entwickelt und eingeführt werden.

IEC 62443-4-1 Gap-Analyse

Bei der Unterstützung durch Limes Security wird auf Vorgaben aus der Normen IEC 62443-4-1 "Anforderungen an den Lebenszyklus für eine sichere Produktentwicklung" aufgesetzt. Im Rahmen einer Gap-Analyse wird der Status-Quo bzgl. der Security-
Aktivitäten im Produktentstehungsprozess und der Entwicklungsabteilung erfasst, sowie das Verständnis über die Anforderungen der Norm IEC 62443-4-1 und deren Umsetzungsmöglichkeiten gestärkt.

Secure Coding und Secure Development Training

Limes Security schult Entwickler, Architekten und andere am Entwicklungsprozess beteiligten Personen hinsichtlich den Prozessen und Maßnahmen zur sicheren Softwareentwicklung, um so Schwachstellen auf Design- und Code-Ebene langfristig zu verhindern

Test der umgesetzten Maßnahmen

Entdecken Sie Risiken, bevor Ihr Gerät auf den Markt kommt und lassen Sie durch Limes Security die spezifischen Security-Aspekte des Geräts auf der Grundlage der erwarteten Nutzung testen. Unter Berücksichtigung der spezifischen Anforderungen besteht das Ziel darin, die Wirksamkeit der Sicherheitskontrollen auf verschiedenen Ebenen zu bewerten: Hardwareplattform, Softwareplattform, Kommunikationskomponenten und Schnittstellen.

Warum wir scheitern, sichere Software zu entwickeln

Wird Security in einem Produkt umgesetzt, sieht sich die Entwicklung in den meisten Fällen von zumindest einem der folgenden fünf Probleme betroffen, die durch die Einführung eines Secure Software Development Lifecycle adressiert und kompensiert werden können.

1

Stand der Technik Definition fehlt

Welche Sicherheitsanforderungen und -voraussetzungen bei der Entwicklung eines Produktes in einem Unternehmen berücksichtigt werden müssen, ist oft unvollständig oder nicht definiert. Unter solchen Umständen liegt es bei der Umsetzung eines Produktes natürlich nahe den Weg des geringsten Aufwandes zu gehen, um schnell zu einem lieferbaren Produkt zu kommen.
2

Security als Feature Add-On

Security ist in vielen Fällen nicht von Grund auf im Produkt verankert, sondern wird erst hinzugefügt, wenn die Grundfunktionen bereits implementiert wurden oder ein Kunde spezifische Security-Funktionen fordert. Somit muss das Produkt im Nachhinein angepasst werden, damit dieses auch "mit Sicherheit funktioniert".
3

Verwendung von unbekannten Technologien

Getrieben durch den Technikwandel und dem Zwang zur Innovation wird bei Produkten oft auf neue Technologien gesetzt, deren Ausmaße und Konsequenzen nur schwer eingeschätzt werden können. Dadurch entsteht die Gefahr, Probleme und Schwachstellen in die Software zu integrieren, die sehr schwer abschätzbar oder gar unbekannt sind.
4

Test, ob Produkt trotz Security noch funktioniert, nicht ob die Security-Features funktionieren

Wird das Produkt nach der Implementierung von Security-Features getestet, wird ein erfolgreicher Test meist daran gemessen, ob alle Funktionen des Produkts noch einwandfrei und ohne Probleme funktionieren. Ob das Security-Feature selbst korrekt umgesetzt wurde, und damit seinen Zweck erfüllt wird nicht selten außen vor gelassen.
5

Einstellen von Security-Personal, aber keine Schulung der Entwickler hinsichtlich Security

Ohne des Aufbaus oder der Weitergabe von Security Know-How an die Entwickler und Architekten können diese keine sichere Software entwickeln.

FAQs

Brauche ich einen definierten Development Lifecycle um Security machen zu können?

Nein, Sie können Ihre Kunden auch so lange über Schwachstellen stolpern lassen, bis das Produkt durch viele Korrekturen endlich einen halbwegs sicheren Zustand erreicht hat. Oder Sie nehmen das Thema Security für Ihre Produktentwicklung ernst und betrachten es als einen wichtigen Qualitätsbestandteil, der nur durch ein wohldefiniertes Vorgehen (also einen Secure Development Lifecycle) effizient und nachhaltig für Ihre Produkte erreicht werden kann.

Ich bin bereits ISO27001 zertifiziert. Brauche ich das noch zusätzlich?

Auch wenn es manchmal fälschlicherweise damit in Zusammenhang gebracht wird, ist die ISO 27001 keine Norm für die Entwicklung sicherer Produkte. Die ISO 27001 hat Ihre Stärke bei der Errichtung eines Information Security Management Systems (ISMS) zum Schutz der eigenen IT-Landschaft und Informationen. Sie streift dabei nur am Rande das Vorgehen bei der Entwicklung sicherer Produkte. Die IEC 62443-4-1 hingegen unterstützt bei der Umsetzung von Maßnahmen und beschreibt Anforderungen an die Entwicklung sicherer (in Form von: secure, nicht safety) Produkte.

Ich mache bereits Security Testing. Warum muss ich mir über einen Secure Development Lifecycle Gedanken machen?

Security Testing ist zwar ein wichtiger Schritt zur Entwicklung sicherer Produkte, Security kann aber nicht in ein Produkt „hineingetestet“ werden. Vor allem ist es sehr teuer, Schwachstellen erst spät durch Tests zu entdecken, an Stelle sie proaktiv zu vermeiden. Deshalb gilt das Gleiche wie z.B. bei Qualität und Safety: Security muss ein geplanter, integrierter Bestandteil der Produktentwicklung sein, bei dem in jeder Phase der Entwicklung die richtigen Maßnahmen ergriffen werden.