Cryptshare Sicherheitsmaßnahmen & Methoden: Unterschied zwischen den Versionen

Version vom 26. November 2021, 09:07 Uhr

Als Sicherheitsprodukt wurde Cryptshare unter Anwendung zahlreicher Methoden entwickelt, die darauf abzielen, funktionale Probleme sowie allgemeine Sicherheitsrisiken wie die OWASP Top Ten zu entschärfen, bzw. zu vermeiden.

Der Entwicklungsprozess für den Cryptshare Server, beginnend mit dem Produktdesign, über die Entwicklungs,- und Qualitätssicherungsphase ist ISO-27001 zertifiziert und beinhaltet die folgenden Maßnahmen[1]:

Agile Entwicklung in einem definierten und selbst optimierenden Scrum Prozess welche die Qualitätssicherung als festen Bestandteil beinhaltet: Entwickler und Mitglieder des Qualitätssicherungsteams arbeiten gemeinsam in einem iterativen Prozess mit dem Ziel Schwachstellen (In Bezug auf Sicherheit und Qualität) zum frühestmöglichen Zeitpunkt und bevor sie in die finale Produktversion gelangen können, innerhalb des Prozesses aufzudecken. Während dieser Phase machen die Entwickler Gebrauch von agilen Methoden wie:
- Test Driven Development (TDD)
- Pair Programming
Zusätzlich zu den zuvor genannten manuellen Tests während eines Sprints, kümmern sich Entwickler um die Wartung automatisierter Qualitätssicherungsmaßnahmen wie:
- Statische Codeanalyse
- Unit Tests
- Integrationstests
- Automatisierte Oberflächentests
Während der Releasevorbereitung werden die folgenden zusätzliche Maßnahmen umgesetzt:
- Regressionstests
- Schwachstellenscans mittels des Acunetix Vulnerability Scanners
- SSL checks unter Nutzung von Diensten wie Qualys SSL Labs

Ergänzend zu den Maßnahmen während des Entwicklungsprozesses existieren die folgenden internen Richtlinien zur Sicherstellung einer schnellen Reaktionszeit auf neue Schwachstellen und zur Verhinderung der Veröffentlichung von Releases mit bekannten Schwachstellen:

Aktualisierung von Bibliotheken in der letzten Phase des Releaseprozesses um neue Schwachstellen vor dem offiziellen Release zu beheben.
Bei Entdeckung einer neuen Schwachstelle im aktuellen Release eine 14-tägige interne Reaktionszeit zur Behebung der Schwachstelle und Vorbereitung eines Hotfix-Releases.

Darüber hinaus werden regelmäßige interne Security Risk Assessments abgehalten, zur Identifizierung von möglichen Angriffsszenarien auf das Produkt und zur Identifizierung, Priorisierung und Planung entsprechender Gegenmaßnahmen.

[1] Die Entwicklungsprozesse für andere Teile des Produktes sind nicht ISO 27001 zertifiziert. Dennoch folgen diese den hier beschriebenen Prozeduren.

@@ Zeile 1: / Zeile 1: @@
-As a security product, Cryptshare is developed using numerous methods aiming to mitigate and prevent functional issues as well as common security risks like the [https://owasp.org/www-project-top-ten/ OWASP Top Ten].
+Als Sicherheitsprodukt wurde Cryptshare unter Anwendung zahlreicher Methoden entwickelt, die darauf abzielen, funktionale Probleme sowie allgemeine Sicherheitsrisiken wie die [https://owasp.org/www-project-top-ten/ OWASP Top Ten] zu entschärfen, bzw. zu vermeiden.
-The Cryptshare Server development process, starting with the product design over the development and quality assurance phase is ISO-27001 certified and includes the following measures[1]:
+Der Entwicklungsprozess für den Cryptshare Server, beginnend mit dem Produktdesign, über die Entwicklungs,- und Qualitätssicherungsphase ist ISO-27001 zertifiziert und beinhaltet die folgenden Maßnahmen[1]:
-* Agile development in a defined and self-optimizing Scrum process including quality assurance as a constant part:  Developers and members of the QA team work together in an iterative process during Sprints with the goal to discover flaws (in terms of security and quality) at the earliest possible point in the process and before they can get into the final product version.  During this phase developers make use of agile methods such as:
+* Agile Entwicklung in einem definierten und selbst optimierenden Scrum Prozess welche die Qualitätssicherung als festen Bestandteil beinhaltet: Entwickler und Mitglieder des Qualitätssicherungsteams arbeiten gemeinsam in einem iterativen Prozess mit dem Ziel Schwachstellen (In Bezug auf Sicherheit und Qualität) zum frühestmöglichen Zeitpunkt und bevor sie in die finale Produktversion gelangen können, innerhalb des Prozesses aufzudecken. Während dieser Phase machen die Entwickler Gebrauch von agilen Methoden wie:
-** Test Driven Development (TDD)
+**Test Driven Development (TDD)
 ** Pair Programming
-* In addition to the forementioned manual tests during a sprint, developers take care of maintaining automated quality assurance measures such as:
+*Zusätzlich zu den zuvor genannten manuellen Tests während eines Sprints, kümmern sich Entwickler um die Wartung automatisierter Qualitätssicherungsmaßnahmen wie:
-** Static code analysis
+**Statische Codeanalyse
-** Unit Tests
+**Unit Tests
-** Integration Tests
+**Integrationstests
-** Automated UI Tests
+**Automatisierte Oberflächentests
-* During release preparation, additional measures are taken in the form of:
+*Während der Releasevorbereitung werden die folgenden zusätzliche Maßnahmen umgesetzt:
-** Regression Tests
+**Regressionstests
-** Vulnerability Scans using the Acunetix vulnerability scanner
+**Schwachstellenscans mittels des [https://www.acunetix.com Acunetix Vulnerability Scanners]
-** SSL checks using tools like the services provided by [https://www.ssllabs.com/ Qualys SSL Labs]
+**SSL checks unter Nutzung von Diensten wie [https://www.ssllabs.com/ Qualys SSL Labs]
+Ergänzend zu den Maßnahmen während des Entwicklungsprozesses existieren die folgenden internen Richtlinien zur Sicherstellung einer schnellen Reaktionszeit auf neue Schwachstellen und zur Verhinderung der Veröffentlichung von Releases mit bekannten Schwachstellen:
-Complementary to the measures taken during the development phase, the following internal guidelines exist to assure quick responses to discovered vulnerabilities and to prevent the publication of releases with known vulnerabilities:
+* Aktualisierung von Bibliotheken in der letzten Phase des Releaseprozesses um neue Schwachstellen vor dem offiziellen Release zu beheben.
+* Bei Entdeckung einer neuen Schwachstelle im aktuellen Release eine 14-tägige interne Reaktionszeit zur Behebung der Schwachstelle und Vorbereitung eines Hotfix-Releases.
-* Library updates in the last phase of the release process to fix discovered vulnerabilities before the official release.
+Darüber hinaus werden regelmäßige interne Security Risk Assessments abgehalten, zur Identifizierung von möglichen Angriffsszenarien auf das Produkt und zur Identifizierung, Priorisierung und Planung entsprechender Gegenmaßnahmen.
-* Upon discovery of a critical vulnerability in the current release, 14 days internal reaction time to fix the vulnerability and prepare a hotfix release.
+----[1] Die Entwicklungsprozesse für andere Teile des Produktes sind nicht ISO 27001 zertifiziert. Dennoch folgen diese den hier beschriebenen Prozeduren.
-Furthermore, regular internal Security Risk Assessments take place to identify possible attack vectors on the product and to identify, prioritize and plan appropriate countermeasures against them.
-----[1] The development processes for other parts of the product are not ISO 27001 certified. However, they follow the same procedures as described here.