Cryptshare Sicherheitsmaßnahmen & Methoden

Aus Cryptshare Documentation
Version vom 26. November 2021, 07:09 Uhr von Hartwigr (Diskussion | Beiträge)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu:Navigation, Suche

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:

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.