Security by Design (SbD) erklärt
Security by Design ist ein Softwareentwicklungsansatz, der darauf abzielt, Sicherheit als Säule und nicht als nachträglichen Einfall zu etablieren, d. h. Sicherheitskontrollen bereits in der Entwurfsphase in Softwareprodukte zu integrieren. SbD entwickelt sichere Software, die Unternehmen sofort bereitstellen können, ohne dass zusätzliche Kosten für Sicherheitsfunktionen anfallen.
Um SbD besser zu verstehen, stellen Sie sich ein Szenario vor, in dem Sie ein sicheres Lager für Ihre Multimillionen-Dollar-Waren aufbauen müssen. Sie könnten ein Gebäude aus leicht zu durchbrechendem Holz errichten, es mit Sicherheitsmerkmalen wie Sensoren und Videoüberwachung verstärken und sogar eine Sicherheitsfirma beauftragen. Oder Sie bauen Ihr Lager aus Ziegeln, verwenden schwere Metalltüren und installieren die gleichen Sicherheitsfunktionen.
Das Ziegellager wird natürlich sicherer sein, denn unabhängig von Ihren Sicherheitsmerkmalen ist es besser, ein unantastbares System zu haben, und das ist der Ansatz, der SbD veranschaulicht.
The Secure Coding Best Practices [Cheat Sheet]
With curated insights and easy-to-follow code snippets, this 11-page cheat sheet simplifies complex security concepts, empowering every developer to build secure, reliable applications.
Download Cheat Sheet
Warum Security by Design?
Früher waren webbasierte Apps durch Design (VbD) anfällig, da Softwareanbieter Software auslieferten, bevor sie Sicherheit in sie integrierten. Das bedeutete, dass Unternehmen Sicherheitsfunktionen als Add-ons kaufen und größere Schwachstellen patchen mussten, sobald sie auftauchten – ein profitabler Ansatz für Anbieter, da mehr Funktionen mehr Geld bedeuteten.
Aber als Hauptziele von Angriffen auf die Lieferkette sind Unternehmen diejenigen, die mit rechtlichen, finanziellen und reputationsschädigenden Konsequenzen konfrontiert sind, wenn es zu Verstößen kommt (und das tun sie oft).
SbD geht dieses Problem "Benachteiligung des Unternehmensbenutzers, Schonung des Anbieters" an, indem es eine Kultur der Softwareentwicklung fördert, in der sowohl der Benutzer als auch der Anbieter für ihre Handlungen oder Unterlassungen verantwortlich gemacht werden. Dies verbessert sowohl die Software der Anbieter als auch die der Benutzer Sicherheitslage indem sie ihre Angriffsfläche reduzieren und andere wichtige Ergebnisse ermöglichen.
Einfacheres und kostengünstigeres Patchen
Das schnelle Anwenden von Sicherheitskorrekturen, während die Software verwendet wird (um Datenschutzverletzungen und damit verbundene finanzielle und Reputationsschäden zu verhindern), kann mühsam, kostspielig und fehleranfällig sein.
Produkte, die von Anfang an sicher sind, benötigen weniger und weniger kritische Patches, was den Prozess viel billiger und einfacher macht.
Kostengünstige Produkte
Die einzige Möglichkeit, Systeme zu sichern, die von vornherein anfällig sind, besteht darin, mehrere Add-ons hinzuzufügen. Angreifer können jedoch immer noch die Hintertüren die durch die VbD-Schwachstelle erstellt wurde, um Systeme zu infiltrieren.
Die standardmäßige Sicherung von Systemen ist kostengünstiger als ein höheres Risiko von Datenschutzverletzungen und den damit verbundenen Kosten, Klagen und Bußgeldern.
Einhaltung
Da bei Software, die mit dem SbD-Ansatz entwickelt wurde, die Sicherheit im Mittelpunkt steht, ist es wahrscheinlicher, dass sie standardmäßig konform ist. Dies erleichtert die Überprüfung verschiedener Softwarekomponenten, um sicherzustellen, dass Beachtung mit verschiedenen Vorschriften.
Wie funktioniert Security by Design?
Der SbD-Ansatz besteht aus vier Hauptphasen, die wir im Folgenden untersuchen.
Phase 1: Definieren der Sicherheitsanforderungen
SbD beginnt mit einer klaren Auseinandersetzung mit der zu entwickelnden Software, ihren potenziellen Schwachstellen und den entsprechenden Sicherheitsanforderungen. Zu den Sicherheitsanforderungen für einen Datenbankdienst gehören Verschlüsselung, rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) und andere Autorisierungstechniken.
Phase 2: Durchführung von Risikobewertungen und Bedrohungsmodellierung
In diesem Schritt müssen Sie einen kontextsensitiven Schwachstellen-Scanner , um die potenziellen Angriffspfade der Software abzubilden.
Beispielsweise ist ein Datenbankdienstanbieter möglichen Angriffspfaden wie öffentlichen IP-Adressen oder privilegierten Konten ausgesetzt, da in seinen Datenbanken vertrauliche personenbezogene Daten (PII) und geschützte Gesundheitsinformationen (PHI) gespeichert sind.
Free Cloud Risk Assessment
Connect with a Wiz expert for a personal walkthrough of the critical risks in each layer of your environment.
Request Assessment
Phase 3: Gleichzeitiges Schreiben von Code und Erstellen von Sicherheitsmaßnahmen
In dieser Phase wirft das Engineering-Team herkömmliche Codierungsverfahren über Bord, um Software mit nativen Sicherheitsmaßnahmen. Für den Datenbankanbieter könnte dies das Schreiben von Code umfassen, der folgende Anforderungen erfüllt:
Verhindert, dass Datenbanken standardmäßig für die Öffentlichkeit zugänglich sind
Automatische Validierung von Benutzereingaben, ohne dass Unternehmensbenutzer Add-ons erwerben müssen
Erfordert mehrere Authentifizierungsmechanismen, bevor eine Form des Zugriffs gewährt wird
Begrenzt Zugriffspunkte für privilegierte Konten
Stufe 4: Kontinuierliche Überwachung und Patching
Schließlich wird die Software getestet und, wenn sie sich als sicher erweist, ausgeliefert. Während Benutzer die Software bereitstellen, überwacht, prüft und versendet der Anbieter kontinuierlich SbD-Updates, sobald neue Bedrohungen und Bedrohungen auftreten. Schwachstellen auftauchen.
Prinzipien der eingebauten Sicherheit
Die Cybersecurity and Infrastructure Security Agency (CISA) ermutigt Softwarehersteller, bei der Entwicklung eines Produkts drei Kernprinzipien zu befolgen.
Geteilte Verantwortung
Sowohl der Lieferant als auch der Kunde sollte die Last der Sicherheit teilen. Von Softwareherstellern wird erwartet, dass sie sichere Produkte entwickeln und ihre Software regelmäßig patchen, wenn sich die Bedrohungslandschaft weiterentwickelt. Von den Kunden wird erwartet, dass sie ihre Produkte mit dieser Software sicher konfigurieren und ihre Daten sicher aufbewahren.
Radikale Transparenz
Softwarehersteller sollten Informationen darüber austauschen, was ihre Produkte von vornherein sicher macht. Sie sind gegenüber ihren Kunden für genaue Schwachstellenempfehlungen, die zugehörigen CVE-Einträge (Common Vulnerability and Exposure) und Authentifizierungsmechanismen verantwortlich, um nur einige der Dinge zu nennen, die von einem SbD-Produkt erwartet werden.
Aufbauorganisation
SbD erfordert das Engagement der C-Suite und die Kommunikation zwischen allen Beteiligten, die Zusammenarbeit ist der Schlüssel zwischen Anbietern und Kunden sowie Entwicklern und Sicherheitsteams. Dies wird die Implementierung nahezu undurchdringlicher Sicherheitskontrollen erleichtern und eine erkenntnisbasierte Budgetplanung und Ressourcenzuweisung ermöglichen.
Herausforderungen bei der Implementierung von Security by Design
Lassen Sie uns die drei größten Herausforderungen bei der Einführung von SbD besprechen.
| Challenge | Description |
|---|---|
| Short-term costs vs. long-term profits | The cost of restructuring legacy software and switching programming languages to embed security—rather than bolt it on—is discouraging for most vendors. Even in modern systems, embedding security is a complex and costly process. Still, in the long run, fewer and less complicated patches, fewer attacks, etc. will mean the initial cost pays for itself. |
| Marketability | The motivation—for cloud vendors—to implement SbD is low, as there are no direct monetary returns for them. It is difficult to market restructured SbD products on the “now secure-by-design” premise, as this will leave enterprise users with the presupposition that the products weren’t properly built and secured earlier on. It is easier to sell legacy software as is, alongside aftersales/add-on security products like firewalls and antivirus. |
| Third-party vendor liability | An important implication of SbD is that software vendors are liable for supply chain vulnerabilities. For example, a single security flaw can affect several enterprise customers who would want the vendor to take the blame, i.e., face the financial and reputational consequences. Getting all parties onboard with the shared responsibility model is thus critical, as discussed above. This makes it clear that security is in fact a shared burden between the vendor and the customer. |
Best Practices für die eingebaute Sicherheit
CISA bietet einige SbD-Taktiken an, die aus dem Sicheres Softwareentwicklungs-Framework (SSDF) des National Institute of Standards and Technology (NIST): Die SP 800-218. Unternehmen sollten diese Praktiken in jede Phase ihres Softwareentwicklungslebenszyklus (SDLC) integrieren.
Verwenden Sie sichere Softwarekomponenten
Stellen Sie gut gesicherte Softwarekomponenten, einschließlich Bibliotheken, Frameworks und Middleware, nur von verifizierten Anbietern bereit. Vermeiden Sie außerdem Software mit bekannten Schwachstellen, einschließlich Kryptografie- und Authentifizierungsfehlern, fehlerhaften Zugriffskontrollen, Injektionsschwachstellen und Protokollierungsproblemen.
Eine Cloud-native Plattform zum Schutz von Anwendungen (CNAPP) wird sich als nützlich erweisen, um ungesicherte Komponenten zu erkennen.
Übernehmen Sie bewährte Designpraktiken
Unternehmen können das Risiko für ihre Softwaresysteme reduzieren, indem sie eine tiefgehende Defense implementieren, d. h. mit mehr als einer Ebene von Sicherheitsmaßnahmen. In der Zwischenzeit isoliert Sandboxing Software- und Sicherheitskomponenten, um zu verhindern, dass die Kompromittierung einer einzelnen Komponente das gesamte System beeinträchtigt.
Anbieter sollten auch Software entwickeln, die das Patchen erleichtert. Die Minimierung von Ausfallzeiten, die sich aus Software-Updates ergeben, wird Unternehmensanwender dazu ermutigen, Patches schneller anzuwenden.
Verwenden Sie speichersichere Programmiersprachen
NIST ermutigt Entwickler um allgemeine speicherorientierte Gegenmaßnahmen wie Control-Flow-Integrität (CFI) und TAddress Space Layout Randomization (ASLR) zu implementieren. Darüber hinaus weist NIST jedoch auch darauf hin, dass sie moderne, speichersichere Sprachen wie Rust, Go, Java, C#, Swift und Python verwenden sollten, während sie ihre speicherunsicheren Gegenstücke C und C++ meiden.
Dies wird dazu beitragen, Sicherheitslücken im Speicher wie SlammerWorm, Ghost Engine und Stagefright zu minimieren.
Übernehmen Sie parametrisierte Abfragen und Web Template-Frameworks
Parametrisierte Abfragen sind SQL-Abfragen mit Parametern, die Benutzereingaben von der Abfrage selbst trennen. Web Template-Frameworks enthalten kontextsensitive Informationen, die verdächtige Benutzereingaben automatisch verhindern. Zusammen tragen diese Mechanismen dazu bei, SQL-Injection zu verhindern und Cross-Site-Scripting-Angriffe (XSS).
SBOMs bereitstellen
Softwareanbieter sollten den Benutzern eine Liste der proprietären Softwarekomponenten, Bibliotheken und Tools von Drittanbietern zur Verfügung stellen, die sie zur Entwicklung von Software verwendet haben. Diese Liste, die über eine agentenloser SBOM-Scanner– Ermöglicht eine einfache Behebung von Schwachstellen.
Eliminieren Sie Standardpasswörter
Anbieter müssen die Einführung von Produkten mit Standardpasswörtern vermeiden. Stattdessen sollten sie eine Multi-Faktor-Authentifizierung einführen und von den Benutzern verlangen, dass sie sofort nach der Konfiguration der Software sichere Passwörter festlegen.
Bereitstellen von Softwareautorisierungsprofilen
Diese Profile legen Benutzerrollen und Anwendungsfälle fest, um unnötigen Zugriff auf Benutzerdaten und privilegierte Konten einzuschränken. Softwarehersteller sollten detaillierte Software-Autorisierungsprofile bereitstellen, das Prinzip der geringsten Rechte implementieren und Warnungen vor Abweichungen von den festgelegten Grenzwerten ausgeben.
Schlussfolgerung
Security by Design implementiert proaktiv Sicherheitsprotokolle bereits in der Phase des Softwaredesigns. SbD wird von der CISA und anderen wichtigen Akteuren der Branche befürwortet und fördert die Durchführung von Schwachstellenbewertungen, Angriffspfadanalysen und Analysen von Softwarekomponenten, um potenzielle Software-Schwachstellen vor der Auslieferung von Anwendungen und in jeder Phase des SDLC zu ermitteln und zu beheben.
Ziel ist es, teure Sicherheitstools und komplizierte Codeänderungen nach dem Verkauf zu vermeiden, die Systeme nicht ausreichend vor Angriffen schützen, da sie bereits von vornherein verwundbar sind.
SbD ist ein günstigerer, schnellerer und robusterer Ansatz zum Erstellen und Sichern von Apps. Aus diesem Grund ist Wiz ein führender Befürworter von Sicherer Code für den Versand. Die Lösung:
Erleichtert die End-to-End-Transparenz der Software
Bietet aktuelle SBOMs
Ermöglicht Analyse von Angriffspfaden
Melden Sie sich für eine an Personalisierte Demo um zu sehen, wie Wiz dir helfen kann, deine Reise zu Secure-by-Design-Produkten zu beginnen.
See for yourself...
Learn what makes Wiz the platform to enable your cloud security operation
