Cryptshare Sicherheitsmaßnahmen & Methoden: Unterschied zwischen den Versionen

Aus Cryptshare Documentation
Wechseln zu:Navigation, Suche
Keine Bearbeitungszusammenfassung
(SSL Checks updated)
 
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
Zeile 1: Zeile 1:
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.
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.


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]:
Der Entwicklungsprozess für den Cryptshare Server, beginnend mit dem Produktdesign, über die Entwicklungs,- und Qualitätssicherungsphase 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:
* 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:
Zeile 13: Zeile 13:
*Während der Releasevorbereitung werden die folgenden zusätzliche Maßnahmen umgesetzt:
*Während der Releasevorbereitung werden die folgenden zusätzliche Maßnahmen umgesetzt:
**Regressionstests
**Regressionstests
**Schwachstellenscans mittels des [https://www.acunetix.com Acunetix Vulnerability Scanners]
**Automatisierte SSL checks unter Nutzung von Tools wie testssl.sh
**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:
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:


Zeile 21: Zeile 20:


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.
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.
----[1] Die Entwicklungsprozesse für andere Teile des Produktes folgen ebenfalls den hier beschriebenen Prozeduren.


[[en:Cryptshare Security Measures & Methods]]
[[en:Cryptshare Security Measures & Methods]]

Aktuelle Version vom 12. November 2025, 07:55 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 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
    • Automatisierte SSL checks unter Nutzung von Tools wie testssl.sh

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 folgen ebenfalls den hier beschriebenen Prozeduren.