Security Service Level Agreement Entwicklung (SSLA-D)

Transkript

1 Security Service Level Agreement Entwicklung (SSLA-D) ALLGEMEINE DOKUMENTENINFORMATIONEN Dokumenten Titel Security Service Level Agreement Entwicklung (SSLA-D) Dokumentenverantwortliche Seiten Version Nächste Aktualitätsprüfung: Dr. Amir Alsbih Versionsverlauf Datum /Veränderung Version Beschreibung verändert durch Initiale Version A. Alsbih Secuity Service Level Agreement Entwicklung (SSLA-D) Seite 1 von 8

2 INHALTSVERZEICHNIS ALLGEMEINE DOKUMENTENINFORMATIONEN 1 SICHERHEITSGARANTIEN Softwareentwicklung Kryptographische Standards 7 Secuity Service Level Agreement Entwicklung (SSLA-D) Seite 2 von 8

3 SICHERHEITSGARANTIEN Die im Folgenden aufgeführten Garantien sind explizit vereinbarte Anforderungen, die seitens Auftragnehmers umzusetzen sind. Es liegt in der Verantwortung des Auftragnehmers, über die hier vereinbarten expliziten Maßnahmen hinaus alle Sicherheitsmaßnahmen umzusetzen, die erforderlich sind, die nachfolgend definierten Sicherheitsgarantien zu implementieren. Überdies sind die folgenden Sicherheitsgarantien eigenverantwortlich und auf eigene Kosten vom Auftragnehmer zu erfüllen, soweit diese nach den nachfolgenden Regelungen für ihn anwendbar sind. Besteht auf Seiten des Auftragnehmers Unsicherheit darüber, ob einzelne Bestimmungen auf ihn anwendbar sind, so hat er hierzu unverzüglich die Abstimmung mit dem Auftraggeber zu suchen. 1.1 Softwareentwicklung Auftragnehmer, die selbst oder durch Dritte Software für den Auftraggeber entwickeln oder modifizieren oder hieran mitwirken oder Software entwickeln oder modifizieren, die bei der Erbringung von IT-Dienstleistungen für den Auftraggeber zur Anwendung gelangt, sichern Folgendes zu: Beachtung an Entwicklungsrichtlinien (Guidelines) und anderen Vorgaben des Auftraggebers SSLA-konformer Programmiercode Genehmigte Funktionalitäten der Softwareprogramme Verbot von Einschränkungen von Funktionalitäten bei Software Umsetzung der Sicherheitsanforderungen Der Auftragnehmer wird Richtlinien und andere Vorgaben des Auftraggebers bezüglich der Entwicklung oder Modifikationen von Software beachten. Diese sind rechtzeitig vor Beginn der Entwicklung oder Modifikation bei dem Auftraggeber anzufragen, mit dem dann auch abzustimmen ist, welche Richtlinien/Vorgaben für die jeweilige Entwicklung/Modifikation im Einzelnen maßgeblich sind. Die Secure Coding Principles des Auftraggebers sind umzusetzen, die auf Anfrage ebenfalls zur Verfügung gestellt werden. Der Auftragnehmer stellt sicher, dass der erstellte Programmiercode, die in diesem Security SLA enthaltenen Vorgaben umsetzt. Der Auftragnehmer erstellt Software nur mit den vom Auftraggeber genannten Funktionalitäten, insbesondere unterlässt er die Aufnahme nicht explizit genannter Funktionalitäten, wie z.b. Schadcodes, unabgestimmte sog. Hintertüren (Backdoors) oder Remote-Zugänge. Niemals wird Software unautorisierte Zugänge zum oder vom internen Netzwerk des Auftraggebers vorhalten oder ermöglichen. Sofern zwischen den Parteien nicht ausdrücklich etwas Abweichendes vereinbart wird, enthält die vom Auftragnehmer für den Auftraggeber erstellte Software keine Funktionen, die Zugang zu oder Zugriff auf die entsprechende Software für den Auftraggeber einschränken oder in der Zukunft einschränken könnten (z.b. Serial-Key, Node Lock, Timeout, etc.) und die eine Limitierung der Konfiguration, Nutzungsdauer oder -häufigkeit oder andere Limitierungen beinhalten. Jegliche Sicherheitsanforderung aus den Bereichen Sicherheitsmanagement, Datensicherung, Desaster Recovery Pläne/Prozeduren des Auftraggebers müssen durch die Software umgesetzt werden können. Sofern diese Anforderungen dem Auftragnehmer nicht bekannt sein sollten oder er sich nicht sicher ist, ob es sich hierbei um aktuelle Fassungen handelt, wird er diese rechtzeitig vor der Erstellung oder Modifikation der Software bei dem Auftraggeber anfragen Secuity Service Level Agreement Entwicklung (SSLA-D) Seite 3 von 8

4 Testprozeduren Testen Testprotokolle Release-Management Prüfen gültiger Werte Berichte über Schwachstellen Sicherheitskonzept für Softwareentwicklung Verpflichtung zum Vulnerability Management Automatisierte Qualitätsund Sicherheitsprüfungen Testprozeduren werden entwickelt und eingehalten. Dabei wird Folgendes umgesetzt: Definition der funktionalen, technischen und sicherheitstechnischen Anforderungen, Entwickeln von Testfällen und vergleichen der Ergebnisse von Testfällen. Für Tests dürfen keine produktiven Daten bzw. Datenbanken genutzt werden. Personenbezogene Daten werden nur verwendet, wenn dies unabdingbar ist und zuvor mit dem Auftraggeber abgestimmt wurde. Es werden für alle durchgeführten Tests Protokolle erstellt, wobei folgende Informationen mindestens enthalten sind: Überblick der Testprozedur, Beschreibung der Inputdaten, genutzte Systeme und Programme, Beschreibung des Userinterface und Beschreibung der Testergebnisse. Neue Releases werden nur nach rechtzeitiger vorheriger Ankündigung gegenüber dem Auftraggeber eingespielt. Ergeben sich Nachteile in der Funktionalität, wird vorab eine Abstimmung mit dem Auftraggeber erfolgen. Es findet eine Inputvalidierung und Output-Encoding statt, das sicherstellt, dass keine unautorisierten Datenzugriffe, -verarbeitungen oder -veränderungen stattfinden, z.b. durch SQL-Injection, Cross- Site-Scripting. Der Auftragnehmer informiert den Auftraggeber unverzüglich über jede entdeckte Sicherheitslücke der Software. Weiterhin informiert der Auftragnehmer den Auftraggeber über Maßnahmen, welche der Auftraggeber implementieren kann, um die Sicherheitslücke(n) zu schließen oder zumindest das Risiko des Missbrauchs zu reduzieren, bis die Ursache durch den Auftragnehmer gänzlich behoben wurde. Für jede Softwareanwendung existiert ein Sicherheitskonzept, das klare technische und wirtschaftliche Spezifikationen beinhaltet. Zudem sind die folgenden Informationen Bestandteil: Risikoanalyse, Sicherheitsklassifizierung, Systembeschreibung und Schnittstellen, Schutzbedarfsanalyse der verarbeiteten Daten, organisatorische und technische Sicherheitsmaßnahmen, Restrisikobetrachtungen und eine Erklärung zur Risikoakzeptanz. Der Auftragnehmer dokumentiert seine Prozesse und Praktiken, die Sicherheitslücken bei der Software verhindern sollen. Dies schließt insbesondere sichere Codierungspraktiken (z.b. Coding Guidelines und Source Code Reviews), Schwachstellen-Scans und Software- Qualitätssicherung ein. Überdies wird er diese Prozesse und Praktiken regelmäßig auf ihre hinreichende Ausgestaltung hin überprüfen. Die Durchführung und das Ergebnis werden dokumentiert. Der Auftraggeber kann Einsicht in diese Prozesse und Praktiken nehmen. Im Falle von Softwareentwicklungen für den Auftraggeber wird der Auftragnehmer dem Auftraggeber unmittelbar nach Erklärung der Abnahmereife und noch vor Beginn der eigentlichen Funktionsprüfung die Möglichkeit einräumen, das zur Abnahme bereitgestellte Erstellungsprodukt automatisierten Qualitäts- und Sicherheitsprüfungen zu unterziehen, um die Einhaltung der entsprechenden Qualitäts- und Sicherheitsvorgaben zu überprüfen. Hierzu zählen insbesondere Source Code Reviews, Schwachstellen-Scans und Penetrationstests. Dafür übergibt der Auftragnehmer dem Auftraggeber den Secuity Service Level Agreement Entwicklung (SSLA-D) Seite 4 von 8

5 Durchführen einer Bedrohungsmodellierung Passwort-Speicherung Session Management Quellcode in einer baubarer Form, also einschließlich sämtlicher Abhängigkeiten von 3rd-Party Bibliotheken. Soweit bei diesen automatisierten Tests Schwachstellen und Sicherheitslücken nach O- WASP Top Ten festgestellt werden, ist der Auftraggeber berechtigt, die Abnahme ohne weitere Funktionsprüfung zu verweigern. Der Auftragnehmer führt eine Bedrohungsanalyse z.b. nach STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service und Elevation of Privilege) durch. Diesbezüglich wird für jede Software-Komponente (insbes. Datenbank, Business-Logik, Datenübertragung, Frontend) ihre Anfälligkeit für die Bedrohungen analysiert und Abwehrmaßnahmen implementiert. Sofern die Software Benutzerpasswörter speichert, dürfen diesbezüglich ausschließlich das PBKDF2 oder bcypt Verfahren zur Anwendung gelangen. Dabei muss für jedes Passwort ein zufälliger und individueller 32bit oder 64bit salt verwendet werden. Ist eine SaaS-Anwendung Gegenstand der auftragsgegenständlichen Leistung, stellt der Auftragnehmer hinsichtlich des Session- Managements der Software Folgender sicher: Session IDs werden unter Verwendung eines gängigen Standards generiert (Session- Identifier dürfen nicht vorhersehbar oder berechenbar sein) und weisen eine Mindestlänge von 128-bit auf. Authentisierte Verbindungen werden nach spätestens 30 Minuten Inaktivität getrennt werden. Zum Schutz des Session-Cookies werden des Weiteren das "Secure" flag sowie das "HTTP-Only" flag gesetzt werden. Abschließend wird für jeden Login eine neue Session ID erstellt werden und analog die alte Session ID bei einem Logout-Vorgang auch ungültig gemacht werden. Jeder Session-Identifier wird innerhalb des Session Managements der Anwendung zu jedem beliebigen Zeitpunkt eindeutig sein. Nach erfolgreicher Authentifizierung wird ein neuer Session-Identifier erzeugt werden. Zur Realisierung eines Session-Managements, d.h. zur Übertragung eines Session-Identifiers, werden in der Regel Session- Cookies verwendet. Input Validierung Output Encoding Die entwickelte/angepasste Software ist nicht anfällig gegenüber Injektion-, Überlauf-, oder anderen Arten von Eingabe-Angriffen. Es wird eine Eingabevalidierung für alle Eingaben durchgeführt, die durch den Benutzer kontrolliert werden kann. Standardmäßig werden dabei sämtliche Eingaben als ungültig betrachtet, wenn diese nicht mit der Spezifikation der erlaubten Daten übereinstimmt. Die entwickelte/angepasste Software ist nicht anfällig für die Ausführung von schadhaften Daten (z.b. XSS). Sämtliche Daten, die durch den Benutzer kontrollierbar sind, müssen einem Output-Encoding unterzogen werden, wenn diese auf einer HTML Seite zurückgegeben werden. Wenn immer Daten angezeigt werden, werden diese als Daten angezeigt ohne im Browser ausgeführt zu werden. Secuity Service Level Agreement Entwicklung (SSLA-D) Seite 5 von 8

6 Protokollierung Upload-Verifizierung Einsatz von Transportverschlüsselung Cookie-Sicherheit Authentifizierung Soweit möglich nutzt die Software ein Standard-Format zur Protokollierung wie das Common Event Format (CEF). Sämtliche sicherheitsrelevanten Ereignisse werden protokolliert. Zu jedem Ereignis wird dabei mindestens das folgende protokolliert: - Wann (Zeitstempel) - Wo (Anwendungskennung, IPv4 Adresse, URL, http-methode, etc.) - Wer (Quell-IP-Adresse, Username, Lizenznummer, etc.) - Was (Art des Eintrags) Ist eine SaaS-Anwendung Gegenstand der auftragsgegenständlichen Leistung, die Uploads des jeweiligen Benutzers ermöglicht, wird die entsprechende Anwendung alle Uploads unter folgenden Aspekten überprüfen: - Die Dateigröße überschreitet nicht den maximal erlaubten Wert, - Die Applikation wählt einen eigenen Dateinamen für das Speichern der Datei (auch für temporäre Datenspeicherungen) - Die Applikation prüft, ob es sich bei dem Upload um einen zulässigen Upload handelt. Die Validierung erfolgt nicht auf Basis der Dateiendung. - Soweit möglich wird der Benutzeruploads durch ein Anti-Viren- Programm auf Schadcode überprüft. Sensible sowie Authentifizierungsdaten im Allgemeinen werden mittels der Software nur unter Verwendung von Transport Layer Security (TLS) im Perfect Forwad Secrecy (PFS) Modus verschlüsselt übertragen, sofern die entwickelte Software eine Datenübertragungsfunktion enthält bzw. die Softwareanpassung die Übertragungsfunktion betrifft. Ist eine SaaS-Anwendung Gegenstand der auftragsgegenständlichen Leistung, so ist sichergestellt, dass persistente Cookies keine sensiblen Daten enthalten. Bei Verwendung von Session-Cookies wird das Attribut httponly sowie secure gesetzt sein. Des Weiteren wird das Attribut path nur möglichst restriktiv gesetzt werden. Ist eine SaaS-Anwendung Gegenstand der auftragsgegenständlichen Leistung, so wird, soweit möglich, sichergestellt, dass die Standard- Systeme des Auftraggebers zur Authentifizierung verwendet werden. Ist dies nicht möglich, so ist im Vorfeld die Abstimmung mit dem Auftraggeber zu suchen. Sofern im Einzelfall schlussendlich gleichwohl eigene Authentisierungsmechanismen zum Einsatz kommen, so wird sichergestellt, dass - die Applikation generische Fehlermeldungen ausgibt, sofern das Passwort und/oder der Username falsch waren (z.b. Fehlerhafter Login, der Username oder das Passwort sind ungültig ), - Brute-Force Angriffe unterbunden werden, - sofern auf ein Passwort verzichtet wird, lediglich OAuth2, OpenID oder SAML V. 2.0 erlaubt sind. Secuity Service Level Agreement Entwicklung (SSLA-D) Seite 6 von 8

7 1.2 Kryptographische Standards Auftragnehmer, die IT-Dienstleistungen für den Auftraggeber erbringen, sichern Folgendes zu: Speichern von Passwörtern Als Standard für die Speicherung von Passwörtern des Auftraggebers oder seinen Kunden werden ausschließlich das PBKDF2 oder bcrypt Verfahren zur Anwendung gelangen. Dabei muss für jedes Passwort ein zufälliger und individueller 32bit oder 64bit salt verwendet werden. Für den Einsatz einer Transportverschlüsselung wird lediglich das Transport Layer Security (TLS) Protokoll 1.2 und höher in Kombination mit Perfect Forwad Secrecy verwendet. Nur die folgenden Cipher suites gelangen zur Anwendung: Server mit ECDSA-Zertifikat: Transportverschlüsselung TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 Server mit RSA-Zertifikat: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 Pre-Shared-Key Authentisierung: TLS_RSA_PSK_WITH_AES_128_CBC_SHA256 TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256 Symmetrische Verschlüsselungsverfahren Asymmetrische Verschlüsselungsverfahren Hash-Funktionen Nur die folgenden Blockchiffren werden eingesetzt: -AES 128, - AES 192 und - AES 256. in den Betriebsarten: - Galois-Counter-Mode (GCM), - Cipher-Block Chaining (CBC) und - Counter Mode (CTR). Nur die folgenden asymmetrischen Verschlüsselungsverfahren sowie Schüssellängen gelangen zur Anwendung: -ECIES ab 250 bit, -DLIES ab 3000 bit und -RSA ab 3000 bit. Nur die folgenden Hashfunktionen gelangen zur Anwendung: - SHA-256, - SHA-384, - SHA-512 und - SHA-512/256. Secuity Service Level Agreement Entwicklung (SSLA-D) Seite 7 von 8

8 Message Authentication Codes Signaturverfahren Nur die folgenden Message Authentication Codes (MAC) gelangen zur Anwendung: -CMAC, -HMAC und -GMAC. Diesbezüglich wird eine Schlüssellänge von mindestens 128 Bit sowie einer Taglänger von mindestens 96 Bit verwendet werden. Nur die folgenden Signaturverfahren gelangen zur Anwendung: - RSA mit mindestens 3000 Bits Länge - DSA mit mindestens 3000 Bits Länge für die Primzahl p sowie mindestens einer Bitlänge von 250 für q. - DSA-Varianten auf elliptischen Kurven: a) ECDSA b) ECKDSA sowie c) ECGDSA mit einer Kurvengröße von mindestens 256 sowie einer Bitlänge von mindestens 250 für q. Secuity Service Level Agreement Entwicklung (SSLA-D) Seite 8 von 8