Wie Sicherheit, Compliance und Transparenz erhöht werden können.

Im dritten Teil unserer Artikelserie zum Thema Application Lifecycle Management wollen wir die Aspekte Sicherheit, Compliance und Transparenz etwas genauer betrachten. Im Rahmen der App Release-Prozesse müssen immer wieder Daten und Dateien zwischen den beteiligten Stakeholdern in der Organisation ausgetauscht werden.

Dafür werden E-Mail, SharePoint, Fileshares oder auch Dateitransfer-Dienste verwendet. Hier stößt man schnell auf Limitierungen bei der Größe von Anhängen, Blockaden durch Virenscanner oder fehlende Berechtigungen. Spätestens bei der Einbindung von externen Dienstleistern, wie z.B. Entwickler- oder Grafik-Teams, scheidet der öffentliche Versand via E-Mail aus und Alternativen werden notwendig.

Incapptic Connect bietet die Möglichkeit, auf einer Weboberfläche Selfservices und Workflows mit den beteiligten Stakeholdern abzubilden, granulare Rechte zu vergeben und den Code der App sowie alle zugehörigen Metadaten an einer zentralen Stelle zu verwalten. Der Versand von Daten entfällt vollständig und alle Inhalte verbleiben sicher im Unternehmen.

Zentral verwaltete Zertifikate erhöhen die Sicherheit

Ein unverzichtbarer Bestandteil im App Release-Prozess sind Zertifikate. An oberster Stelle steht das sogenannte „Distribution Certificate“, das von Apple oder Google bereitgestellt wird. Es zeigt nach außen hin an, welchem Unternehmen eine App zugeordnet ist. Gerät dieses Zertifikat in die falschen Hände bzw. Apple oder Google vermuten einen Missbrauch, verlieren alle jemals damit signierten Applikationen ihre Funktionsfähigkeit. Dies stellt ein hohes Risiko dar und ist umso kritischer, wenn man sich die gängige Handhabung dieser Zertifikate vor Augen führt.

Üblicherweise beginnen Unternehmen die Mobilisierung von Geschäftsprozessen durch Apps mit kleinen Schritten und einem Proof of Concept. Das o.g. „Distribution Certificate“ wird daher oft kurzerhand von einem Mitarbeiter oder externen Berater erstellt und liegt dann künftig auf dem ungesicherten Arbeitsgerät eines oder mehrerer Mitarbeiter. Die Weitergabe dieses Zertifikates, um Kollegen mal schnell zu ermöglichen auch eine App zu signieren, ist durchaus gängige Praxis. Zu Beginn erlaubt diese „Start-Up“-Mentalität schnelle Ergebnisse, steht damit aber in völligem Gegensatz zu etablierten Handlungsweisen von z.B. SSL oder S/MIME Zertifikaten in größeren Organisationen. Hier hat nur eine sehr kleine Gruppe von Personen Zugriff auf das Zertifikatsmaterial und die angrenzenden Prozesse. Üblicherweise hat dieser Personenkreis aber keine Berührungspunkte mit den App Release Prozessen.

Abhilfe schafft hier incapptic Connect, in dem alle notwendigen Zertifikate zentral im System gekapselt sind und den einzelnen Stakeholdern nicht zur Verfügung stehen. Ein Punkt weniger auf der langen Liste des CISO.

Betreibt man den App Release Prozess „von Hand“ mit Skripten und Tools, wie z.B. Fastlane, fällt schnell das fehlende Rollenkonzept auf. Dies bezieht sich nicht nur auf die Abläufe innerhalb einer Organisation, sondern auch auf die benötigten Schnittstellen und Werkzeuge auf Seiten von Apple und Google. Die jeweiligen „Enterprise Developer Accounts“ erlauben keine granulare Vergabe von Rechten oder die Einbindung in Unternehmensverzeichnisse. Zudem reicht die Anzahl der möglichen Accounts für größere Organisationen nicht aus. Eine Abgrenzung zwischen verschiedenen Fachbereichen bzw. Apps ist nicht abbildbar.

Incapptic Connect kann diese Funktionen kapseln und als eine zentrale Instanz gegenüber Apple oder Google auftreten. Zugänge, Rollen und Rechte je Fachbereich oder externem Dienstleister lassen sich flexibel vergeben. Der Zugang zum Enterprise Developer Account (Apple) kann damit zentral verwaltet und muss nicht mit verschiedenen Beteiligten geteilt werden.

Security von Anfang an integriert statt teuer nachgerüstet

Durch den Einsatz einer integrierten Lösung erhöht sich sowohl Transparenz als auch Nachvollziehbarkeit. Für alle relevanten Prozesse existieren an einer zentralen Stelle Logfiles. Audit-Trails machen sämtliche Änderungen nachvollziehbar. Transparenz wird auch dadurch erzeugt, dass das System einen aktuellen Überblick über alle ausgerollten Apps und deren Versionen bietet und für die Produktverantwortlichen Installationszahlen bereithält. UEM-Teams schätzen in diesem Zusammenhang die automatische Überwachung der Gültigkeit von Zertifikaten und Provisioning-Profilen für eine große Anzahl an Apps.

Neben sicheren Prozessabläufen, Dateiablage und genau definierten Zugriffen spielt noch ein weiterer Aspekt eine zunehmend wichtige Rolle, die Sicherheit der App selbst. Hierbei gilt es z.B. zu prüfen, ob die App den internen Richtlinien zur Verarbeitung und Speicherung von Daten entspricht, Coding Guidelines einhält oder externe Entwickler z.B. unzulässige Module oder gar Schadsoftware eingebunden haben. Neben den Daten von Mitarbeitern und Kunden könnten hierbei auch Angriffe auf eine Organisation von innen heraus betrieben werden.

Je größer die Zielgruppe der Anwender, umso häufiger werden Apps daher einer Risikoanalyse bzw. einem Pen-Test unterzogen. Dies wird von sehr spezialisierten Teams oder externen Dienstleistern durchgeführt und stellt dadurch einen weiteren Flaschenhals im App Release Prozess dar. In Zeiten von agiler Entwicklung und ständigen Feature-Releases, Bug-Fixes und Security-Updates können In-House Apps praktisch nicht mehr durchgängig einer Prüfung unterzogen werden. Weder aus monetären Gesichtspunkten noch in Bezug auf die Verfügbarkeit der notwendigen Ressourcen.

Automatisierte Risikoanalysen beschleunigen den App Publishing Prozess

Die Integration von automatisierten Risiko- und Bedrohungsanalysen kann die Einhaltung von Richtlinien und Verordnungen deutlich erleichtern und Risiken lassen sich bereits vor dem Rollout erkennen und bewerten. Schnittstellen in incapptic Connect ermöglichen die Integration von z.B. zScan von Zimperium direkt in die Build Pipeline. So lassen sich schon beim Upload der App (z.B. durch den Entwickler) entsprechende Analysen durchführen, bevor die Daten überhaupt in den weiteren Prozessablauf gehen. Dabei wird der Code der App selbst geprüft, das Verhalten der App und welchen Kontext die App verwendet, wie z.B. Zertifikate, Netzwerke, Domains.

Die nachstehende Auflistung zeigt einige Beispiele für mögliche Ansätze auf:

• Prüfung gegen Best Practices im Entwicklungs- und Sicherheitsumfeld wie z.B. OWASP, NIAP
• Absicherung von Kommunikation und Schnittstellen
• Verwendung von SDK’s, welche die Privatsphäre gefährden
• Abfluss sensibler Daten, Nutzung von Cloud Services
• Richtige und sichere Compiler Settings
• Zugriff auf API-Keys
• URL Reputation
• Chain of Trust, SSL Validation, Certificate Pinning

Welche Phasen Applikationen während ihres Lifecycles durchlaufen und worauf es dabei ankommt, lesen Sie in Teil 4 Vom App Release zum App Lifcycle Management.

Lesen Sie hier Teil 1:

Wie Business-Apps schneller entwickelt, bereitgestellt und effizient verwaltet werden können

Teil 2:

Abläufe effizient gestalten und Durchlaufzeiten verkürzen

Teil 4:

Worauf es beim Onboarding, Deployment und Deprovisioning ankommt.