Applikationen auf den Zahn gefühlt
SECURITY: Applikationen auf den Zahn gefühlt
3. Funktionalität geht vor Sicherheit.
Richtig ist:
Eine gute Projektplanung lässt den Entwicklern genügend Zeit, sich um die Sicherheitsaspekte zu kümmern. Übermüdete und gehetzte Programmierer erweisen der Sicherheit keine guten Dienste.
Aufwand
Eine gute Projektplanung lässt den Entwicklern genügend Zeit, sich um die Sicherheitsaspekte zu kümmern. Übermüdete und gehetzte Programmierer erweisen der Sicherheit keine guten Dienste.
Aufwand
Der Aufwand für einen Application-Security-Audit variiert stark, da jede Applikation einzigartig ist. Die Komplexität und die Verwendung von Standardkomponenten erhöhen oder verkleinern den zeitlichen Aufwand, welcher typischerweise zwischen zehn und zwanzig Personentagen liegt. Um sich vor unliebsamen Überraschungen zu schützen, macht es manchmal Sinn, bereits während der Konzeptphase eine unbeteiligte Instanz beizuziehen und damit eine neue Perspektive zu gewinnen.
Welche Module untersucht werden, hängt ebenfalls von der Applikation ab. Oft wird zur Schonung des Projektbudgets auf einen kompletten Review des Quellcodes verzichtet, und nur die sicherheitsrelevanten Klassen untersucht. Ein dokumentenbezogener Review bildet meist die Grundlage und gibt dem Auditor die Zeit, sich in die Applikation einzuarbeiten. Daraus resultieren eventuell Mängel in der Dokumentation oder weitere zu untersuchende Schnittstellen und Prozesse. Auf technischer Ebene wird der Soll/Ist-Zustand manuell oder mittels Tools überprüft und neben dem analytischen auch ein kreativer Ansatz verfolgt.
Für den Projektablauf kann auch ein iteratives Modell gewählt werden, welches aufgedeckte Sicherheitslücken schliessen und erneut kontrollieren lässt. Dies kann das Projekt um Wochen hinaus verzögern. Bei zahlreichen Veränderungen besteht eine andere Möglichkeit darin, die Nachkontrolle in einem kleinen Folgeprojekt durchzuführen. Diesen Review könnte gar ein neuer Security-Anbieter durchführen.
Das Projekt sollte in einem unabhängigen, fairen Bericht resultieren, der die konzeptionell-organisatorischen sowie die technischen Sicherheitsmängel der Anwendung ausweist und praktikable Verbesserungsvorschläge liefert.
Welche Module untersucht werden, hängt ebenfalls von der Applikation ab. Oft wird zur Schonung des Projektbudgets auf einen kompletten Review des Quellcodes verzichtet, und nur die sicherheitsrelevanten Klassen untersucht. Ein dokumentenbezogener Review bildet meist die Grundlage und gibt dem Auditor die Zeit, sich in die Applikation einzuarbeiten. Daraus resultieren eventuell Mängel in der Dokumentation oder weitere zu untersuchende Schnittstellen und Prozesse. Auf technischer Ebene wird der Soll/Ist-Zustand manuell oder mittels Tools überprüft und neben dem analytischen auch ein kreativer Ansatz verfolgt.
Für den Projektablauf kann auch ein iteratives Modell gewählt werden, welches aufgedeckte Sicherheitslücken schliessen und erneut kontrollieren lässt. Dies kann das Projekt um Wochen hinaus verzögern. Bei zahlreichen Veränderungen besteht eine andere Möglichkeit darin, die Nachkontrolle in einem kleinen Folgeprojekt durchzuführen. Diesen Review könnte gar ein neuer Security-Anbieter durchführen.
Das Projekt sollte in einem unabhängigen, fairen Bericht resultieren, der die konzeptionell-organisatorischen sowie die technischen Sicherheitsmängel der Anwendung ausweist und praktikable Verbesserungsvorschläge liefert.
Simon Wepfer
