In Auftrag gegebene Software

IT Sicherheitsanforderungen für in Auftrag gegebene Software Entwicklungen, welche ergänzend zu den Sicherheitsanforderungen für Standard-Software zu sehen sind.

Nachfolgende Anforderungen bilden eine Zusammenfassung der wichtigsten Sicherheitsanforderungen für in Auftrag gegebene Software Entwicklungen. Um zu der detaillierten Auflistung dieser Sicherheitsanforderungen zu gelangen, führen Sie bitte die Schutzbedarfsklassifizierung durch, oder klicken Sie hier für eine vollständige Liste ohne Klassifizierung.

Hinweis: Klicken Sie auf einzelne Anforderungstexte oder ganze Kategorien um diese an- oder abzuwählen. Am Ende dieser Seite können Sie die gefilterten Texte als PDF oder RTF exportieren lassen.



Initiale Software Beschreibung:
Der potentielle Anbieter verpflichtet sich, die Architektur der Software und andere Beschreibungen, die für die Struktur der Software von Relevanz sind, zu übermitteln, wie z.B. Applikationsdesign oder Dokumentation des Testplans. Dieses Dokument soll auch initiale Beschreibungen über Software-Komponenten und Schnittstellen enthalten, inklusive sicherheitsrelevanten Details.

Risiko- und Kostenverteilung:
Wie auch im OWASP Secure Software Contract Annex [16] vorgeschlagen, erscheint es zweckmäßig, die Kosten für Security unter den Partnern einer Ausschreibung aufzuteilen: Der Entwickler bzw. Anbieter der Software trägt die Risiken für Probleme, die vorab im Anforderungskatalog definiert wurden und durch geeignete Security-Reviews auf ein Minimum reduziert werden sollten. Der Einkäufer bzw. Kunde trägt die Kosten für die Bearbeitung bzw. Behebung neu aufgetretener Security-Probleme. Diese Aufteilung hat den Vorteil, dass der Anbieter der Software die erforderlichen Sicherheitsanforderungen vertraglich klar definiert und abgesteckt hat und somit sein Risiko überschaubar und konkret minimieren/behandeln kann. Der Kunde wiederum wird durch diese Vorgangsweise animiert, bereits im Vorfeld seine Sicherheitsbedürfnisse und -anforderungen möglichst konkret und vollständig zu definieren.
Dabei ist zu beachten, dass hierbei lediglich die Risiken behandelt werden, die mit der Behebung der Sicherheitslücken im Code verbunden sind, nicht aber die Kosten für Schäden und eventuelle Wiederherstellungsarbeiten, die durch die Ausnutzung dieser Lücken entstanden bzw. notwendig sind. Sind daher vorab definierte und vertraglich ausgeschlossene Sicherheitslücken vorhanden, die durch einen Angreifer ausgenutzt werden, ist der Anbieter für Schäden und eventuelle Folgeschäden, die dem Kunden dadurch entstehen, haftbar zu halten.

Aktualitätsklausel:
Es sollte vertraglich festgehalten werden, dass jegliche Ausführungen der Ausschreibung bzw. des Folgevertrags über die Software den letztgültigen Versionen aller angegebenen Standards entsprechen.

[16] OWASP, "Secure Software Contract Annex." [Online]. Available: https://www.owasp.org/index. php/OWASP_Secure_Software_Contract_Annex



Implementierung:
Der Entwickler verpflichtet sich, Richtlinien für sicheren Code aufzustellen sowie diese zu befolgen und zur Verfügung zu stellen. Außerdem sollen gängige Security-Control Programmier-Interfaces verwendet werden, wie z.B. OWASP Enterprise Security API (ESAPI) [6].
Die Richtlinien beinhalten dabei z.B. Vorgaben für die Formatierung, Struktur und das Kommentieren des Codes. Die Security-Control Programmier-Interfaces dienen der Unterstützung der unter Standardsoftware aufgelisteten Sicherheitsanforderungen, für die Vermeidung typischer Software-Schwachstellen. Sie definieren, wie Security Controls aufgerufen werden und diese funktionieren. Spezifische Leitlinien zur Vermeidung gängiger Sicherheitslücken sind dabei miteinzubeziehen.

3rd-party Code
Viele Software-Produkte enthalten einen beträchtlichen Anteil an Code eines Drittherstellers, wie z.B. Libraries, Frameworks oder bereits kompilierte Binaries/Produkte. Dieser Code unterliegt denselben Anforderungen wie der selbst geschriebene Code des Software-Anbieters und ist daher aus Security-Sicht genauso wichtig. Obwohl auch der Anbieter nicht immer die Möglichkeit hat, die Sicherheit dieses Codes zu garantieren, wird es als sinnvoll erachtet, dem Anbieter die alleinige Verantwortung dafür zu übertragen. Security muss Teil der sogenannten “build or buy”-Entscheidung sein, welche wiederum sehr wohl dem Software-Entwickler obliegt. Falls dies möglich sein sollte, kann der Anbieter natürlich die Sicherheitsverantwortung an den Hersteller des 3rd-party Codes übertragen. Außerdem hat er die Möglichkeit, den 3rd-party Code vorab selbst zu analysieren oder durch externe Security-Experten analysieren zu lassen.
Der Anbieter verpflichtet sich, jegliche für die Software verwendete 3rd-party Software bekanntzugeben. Dies inkludiert alle Libraries, Frameworks, Komponenten und andere Produkte, unabhängig davon, ob diese kommerziell, gratis, open-source oder closed-source sind. Der Anbieter verpflichtet sich außerdem, sämtliche binäre Executables, d.h. kompilierten oder Byte-Code (Source Code nicht zwingend erforderlich) der Software zu veröffentlichen.
Der Anbieter verpflichtet sich, die Entwicklungsherkunft sämtlicher Software-Komponenten bekanntzugeben, die in dem angebotenen Produkt verwendet wurden.
Der Anbieter versichert, dass die verwendete 3rd-party Software ebenso allen Sicherheitsanforderungen entspricht, und dass diese genauso sicher ist wie sein selbst entwickelter Code.

Security-Analyse und -Tests:Der Anbieter verpflichtet sich, im Entwicklungszyklus (automatisierte) Code- sowie Sicherheitsanalysen bezüglich Bedrohungen und Risiken durchzuführen und die Applikation hinsichtlich Security zu testen, im besten Fall in Anlehnung an die Verifizierungsanforderung eines festgelegten Standardverfahrens, wie z.B. OWASP Application Security Verification Standard (ASVS) [4]. Der Anbieter hat dabei die Erkenntnisse und Ergebnisse dieser Analysen zu dokumentieren und dem Kunden zur Verfügung zu stellen.

Schwachstellen, Risiken, Bedrohungen:
Der Anbieter verpflichtet sich zu seinem Bestreben, Schwachstellen, Risiken und Bedrohungen so früh wie möglich im Software-Lifecycle zu erkennen. “Software-Lifecycle” bedeutet dabei: Der Zeitraum beginnend von der Entwicklung der Software über das Betreiben (Auslieferung, Management, Updates) bis zur “Dekommissionierung” ebendieser. Dabei sollen Schlüsselrisiken gegenüber den wichtigsten Funktionen und Assets identifiziert werden. Außerdem sollen die “CWE/SANS TOP 25 Most Dangerous Software Errors” [5] und andere typische Programmierfehler analysiert und schriftlich dokumentiert werden, dass diese ausgemerzt wurden.

Sichere Auslieferung und Konfiguration:
Der Anbieter verpflichtet sich, eine Anleitung für die sichere Konfiguration zur Verfügung zu stellen, die alle sicherheitsrelevanten Optionen samt ihrer Auswirkungen auf die Security der Software enthält. Außerdem sollen die Abhängigkeiten der Software bzgl. Plattform, Betriebssystem, Web Server, Applikationsserver und dergleichen enthalten sein, und wie diese in Hinsicht aus den sicheren Betrieb zu konfigurieren sind. Wie bei Standardsoftware müssen Standardkonfiguration sowie die Standardeinstellungen “ab Werk” sicher sein. Ebenfalls muss auch eine Methode zur Verfügung gestellt werden, mit der die Authentizität und Integrität von Softwarekomponenten und Konfigurationsdaten verifizierbar ist. Zusätzlich soll das gelieferte Produkt aus dem Source Code identisch und überprüfbar reproduzierbar sein.

[4] OWASP, "Application Security Verification Standard (ASVS) 3.0", https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project, 2015. [Online]. Available: https://www.owasp.org/images/6/67/OWASPApplicationSecurityVerificationStandard3.0.pdf

[5] T. M. Corporation, "CWE/SANS Top 25 Most Dangerous Software Errors", http://cwe.mitre.org/top25/, 2011. [Online]. Available: http://cwe.mitre.org/top25/

[6] OWASP, "The OWASP Enterprise Security API (ESAPI)", https://www.owasp.org/index.php/ESAPI. [Online]. Available: https://www.owasp.org/index.php/ESAPI



Der Anbieter verpflichtet sich, die angebotene Software vor Auslieferung zum Kunden auf seine Kosten auf Sicherheitsmängel untersuchen zu lassen, idealerweise durch eine unabhängige Organisation, die auf Software-Security spezialisiert ist.

Recht auf Review:
Der Kunde hat das Recht, die Software auf seine Kosten nach Auslieferung auf Sicherheitsprobleme hin untersuchen zu lassen. Der Anbieter stimmt dabei zu, das Untersuchungsteam angemessen zu unterstützen, z.B. durch die Bereitstellung von Source Code oder den Zugang zu Testumgebungen.

Review Abdeckung:
Security Reviews sollen alle Aspekte der ausgelieferten Software abdecken, inklusive selbst entwickelten Code, 3rd-party Komponenten, Libraries, Produkte und Systemkonfigurationen.

Review Rahmen:
Security Reviews sollen mindestens auf alle vertraglich deklarierten Sicherheitsanforderungen prüfen und außerdem auf weitere gängige Schwachstellen untersuchen. Dabei können unterschiedlichste Methoden zum Einsatz kommen, wie z.B. Schwachstellen-Scanning, Penetration Testing, statische Source Code Analyse oder Expert Code Reviews.

Standard Benchmarks:
Um ein gemeinsames Verständnis der Sicherheitsprobleme zwischen den Parteien sicherzustellen, sollen diese – soweit möglich – nach Industriestandards bewertet werden, wie z.B. definiert in First’s “Common Vulnerability Scoring System (CVSS)” oder Mitre’s “Common Weakness Enumeration (CVE)”.

Häufigkeit von Reviews:
Zumindest bevor neue Releases (egal ob minor oder major) zum Kunden ausgeliefert werden, muss ein Review stattfinden.

Meldepflicht:
Bei erfolgreicher Aufdeckung von Sicherheitsproblemen werden diese sowohl dem Kunden als auch dem Anbieter gemeldet. Jegliche Sicherheitsprobleme sind zu dokumentieren, nachzuverfolgen und zu beheben.



Identifizierung:
Der Anbieter verpflichtet sich, sämtliche identifizierte Sicherheitsprobleme zu dokumentieren und während des gesamten Software Lifecycles nachzuverfolgen, unabhängig davon, ob es sich um Probleme in den Bereichen Anforderungen, Design, Implementierung, Tests, Auslieferung oder Betrieb handelt. Die mit dem Sicherheitsproblem verbundenen Risiken müssen evaluiert, dokumentiert und dem Kunden unmittelbar berichtet werden.

Schutz:
Der Anbieter verpflichtet sich, sämtliche Informationen über jegliche Sicherheitsprobleme angemessen nach bestem Wissen und Gewissen zu schützen, um die Wahrscheinlichkeit zu minimieren, dass Schwachstellen der bereits in Betrieb befindlichen Kunden-Software in falsche Hände geraten und ausgenutzt werden.

Wiederherstellung:
Jegliche Sicherheitsprobleme, die vor Auslieferung der Software identifiziert werden, müssen vom Anbieter/Entwickler behoben werden. Jene Sicherheitsprobleme, die nach Auslieferung entdeckt werden, sollen so behandelt werden, wie auch schon für allgemeine Bugs und Probleme der Software festgehalten. Eine gemeinsame Roadmap zu Behebung von Sicherheitsproblemen soll dabei zwischen Kunden und Anbieter definiert werden.



Personal und Organisation:
Der Anbieter ist verantwortlich dafür, dass alle Mitarbeiter seines Entwicklerteams in sicheren Programmiertechniken geschult wurden und diese beherrschen.
Die Mitglieder des Entwicklerteams sollen einer angemessenen Hintergrund-Überprüfung unterzogen werden. Der Anbieter garantiert die Vertrauenswürdigkeit aller an der Entwicklung der Software beteiligten Personen.
Der Anbieter soll alle für die Software-Entwicklung verwendeten Tools bekanntgeben. Außerdem soll ein “build” Prozess verwendet werden, der zuverlässig eine vollständige Distribution generiert. Die Integrität der Software soll außerdem nach der Auslieferung zum Kunden verifiziert werden können; auch dafür muss der Anbieter eine Methode vorsehen.

Zertifizierungspaket und Selbstzertifizierung:
Der Anbieter verpflichtet sich, ein “Zertifizierungspaket” bereitzustellen, in dem sich die gesamte Security-Dokumentation des Entwicklungsprozesses befindet. Darin soll schriftlich festgehalten werden, dass die Sicherheitsanforderungen erfolgreich erfüllt und getestet wurden, und eventuell identifizierte Sicherheitsprobleme sachgerecht behoben wurden. Dies sollte vom Security-Architekt der Software zertifiziert werden. Jegliche Ausnahmen bzw. Abweichungen von den Anforderungen müssen bei Auslieferung dokumentiert und bekanntgegeben werden.

Echtheitsgarantie:
Der Anbieter garantiert, dass der Source Code des Software-Produkts - sofern nicht anders angegeben sein eigener ist, und dieser nicht von anderen Quellen kopiert wurde.

Common Criteria:
Der Anbieter garantiert, dass das Software Produkt ausreichend unter “Common Criteria for Information Technology Security Evaluation” validiert wurde, und diese Validierung auch nach Updates oder Modifizierungen der Software aufrechterhalten bleibt.



Akzeptierung:
Die Software gilt erst als vom Kunden akzeptiert, wenn das Zertifizierungspaket vollständig ist und sämtliche Sicherheitsprobleme behoben wurden bzw. eine gemeinsame Roadmap für bestehende Sicherheitsprobleme erstellt wurde.
Außerdem muss der Anbieter demonstrieren/garantieren, dass die Software samt aller Funktionen korrekt funktioniert, wenn diese auf der Produktiv-Infrastruktur (Betriebssystem, Middleware, ...) des Kunden ausgeführt wird.

Sicherheitsprobleme nach Akzeptierung:
Sollten nach der Akzeptierung Sicherheitsprobleme entdeckt werden bzw. dringender Verdacht bestehen, dass ebensolche existieren, muss der Entwickler/Anbieter den Kunden dabei unterstützen, die Ursache und Art des Problems zu untersuchen. Dabei ist das Problem als “neuartig” anzusehen, wenn es nicht von den vertraglichen Sicherheitsanforderungen abgedeckt wird oder außerhalb des angemessenen Rahmens der Securitytests anzusiedeln ist.
Anbieter und Kunde willigen ein, den Aufwand für die Behebung der neuartigen Sicherheitsprobleme abzuschätzen, und in guter Absicht eine Übereinkunft für die Durchführung der notwendigen Arbeiten zur Behebung auszuhandeln.
Der Anbieter/Entwickler verpflichtet sich, alle wirtschaftlich sinnvollen Aufwendungen (abhängig von der Schwere des Risikos) im Einklang mit gängigen Software-Entwicklungspraktiken zu unternehmen, um sämtliche Sicherheitsprobleme so schnell wie möglich zu beheben, die nicht in die Kategorie “neuartige Sicherheitsprobleme” fallen.


Beschaffungsplattform für sichere IT von Fachhochschule St. Pölten.