Critical Security Update
To help protect your systems, customers using NI driver software 2026 Q2 or earlier should visit ni.com/ni-pal-update and follow the recommended actions.
Sicherheit in einer Softwareanwendung erfordert eine formale Methodik, um eine sichere Denkweise während des gesamten Entwicklungslebenszyklus hinzuzufügen. Dieser Software Development Lifecycle (SDLC) beginnt vor Beginn der Entwicklung mit der Vorbereitung des Teams, dem Einrichten von Schutzmaßnahmen für die Entwicklung der Software, dem Befolgen bewährter Sicherheitspraktiken bei der Entwicklung der Software und der Unterstützung der Software nach der Veröffentlichung. Dieses Dokument enthält Empfehlungen für NI-LabVIEW-Teams, einen formalen SDLC zu übernehmen, der ein Framework für sichere Softwareentwicklung in ihre Projekte integriert.
Ein Software Development Life Cycle (SDLC) ist eine formelle oder informelle Methode zum Entwerfen, Erstellen und Warten von Software (einschließlich in Hardware integriertem Code).
Jedes Softwareteam hat bereits einen Entwicklungsprozess, unabhängig davon, ob dieser formal dokumentiert ist oder nicht. Die absichtliche sichere Entwicklung fügt Aktivitäten während dieses Prozesses hinzu, um Sicherheitslücken zu reduzieren, die Wartbarkeit zu verbessern und die Kosten für die Behebung von Sicherheitsproblemen zu reduzieren. Zu den Sicherheitslücken gehören nicht nur Fehler aufgrund von Programmierfehlern, sondern auch Schwachstellen aufgrund von Sicherheitseinstellungen, falschen Vertrauensvoraussetzungen und veralteten Risikoanalysen.
Je früher im SDLC auf Sicherheit berücksichtigt wird, desto weniger Aufwand und Kosten sind letztlich erforderlich, um das gleiche Sicherheitsniveau zu erreichen. Unabhängig vom SDLC-Modell ist dieses Prinzip (Shifting Left) von entscheidender Bedeutung. Das Prinzip der Linksverschiebung gilt für jede Programmierumgebung, einschließlich LabVIEW – eine sichere Programmierumgebung, mit der sichere Anwendungen entwickelt werden können. Ein Großteil der Sicherheit der fertigen Anwendung hängt vom SDLC ab, der vom Entwicklerteam angenommen wird.
Ein wichtiger Hinweis zu SDLC und Compliance: Die meisten regulatorischen Programme wie der European Cyber Resilience Act (CRA), die US Cybersecurity Maturity Model Certification (CMMC), die UK Defence Cyber Certification (DCC) und andere erfordern Nachweise dafür, dass ein System nach sicheren Methoden wie in diesem SDLC entwickelt wurde. Diese Programme erfordern jedoch weit mehr als nur einen SDLC. Weitere Einzelheiten finden Sie in der Dokumentation zu diesen Programmen.
Diese Anleitung basiert in erster Linie auf den Grundsätzen und Methoden, die im NIST Special Publication 800-218, Secure Software Development Framework (SSDF) definiert sind, das einen technologieneutralen Rahmen für die Entwicklung sicherer Software bietet und allgemein als Unterstützung der Sicherheitsanforderungen der US-Regierung anerkannt ist. Jede SSDF-Praxis wurde speziell auf die Anforderungen von LabVIEW-Entwicklungsteams ausgelegt und angewendet, wobei der Schwerpunkt auf der praktischen Implementierung in Test-, Mess-, Automatisierungs- und Engineeringumgebungen liegt.
Die in diesem Dokument vorgestellten Empfehlungen wurden auch mit anderen etablierten sicheren Entwicklungs-Frameworks und Bewährte Methoden der Branche verglichen, einschließlich der JKI Security Suite und Microsoft Security Development Lifecycle (SDL), um die Konsistenz mit bewährten Ansätzen in Bezug auf Softwaresicherheit, Risikomanagement und Schutz der Softwarelieferkette sicherzustellen. Ziel ist es, LabVIEW-Organisationen einen praktischen Fahrplan für die Integration von Cybersicherheit in ihre Entwicklungsprozesse zu bieten und gleichzeitig die Nachweise und Rückverfolgbarkeit zu generieren, die zunehmend von Kunden, Regulierungsbehörden und staatlichen Beschaffungsprogrammen benötigt werden.
Der in NIST 800-218 beschriebene Prozess umfasst diese vier Bereiche der Softwareentwicklung:
In diesem Beitrag werden diese Themen als Anleitung für die Entwicklung einer LabVIEW SSDF verwendet.
Bevor Sie mit der Entwicklung beginnen, ist es wichtig, Schritte zu unternehmen, um Ihrem Team bei der Umsetzung sicherer Entwicklungsprinzipien zu helfen, die notwendigen Schulungen durchzuführen und die Prozesse und Werkzeuge festzulegen, die eine sichere Entwicklung unterstützen. In dieser Phase nehmen Sie sich Zeit, um folgende Ziele zu erreichen:
Diese Anforderungen gelten allgemein für jedes Softwareentwicklungsteam, aber es gibt einige Schritte, um sie an Testteams und LabVIEW Teams anzupassen.
Viele Testteams sind vom Sicherheitsteam ihres Unternehmens isoliert. Koordinieren Sie sich mit ihnen, um ein Vertrauensverhältnis aufzubauen, damit sie wissen, dass Sie Sicherheit ernst nehmen. Treffen Sie sich mit Ihrem Sicherheitsteam, um deren Anforderungen an entwickelten Code zu verstehen. Zeigen Sie ihnen Ihre Projekte und Ihre Testbereiche und führen Sie sie durch Ihre Prozesse. Es ist hilfreich für sie zu verstehen, wie ein Testlabor funktioniert und welche Einschränkungen Sie haben. Ihre Herausforderungen sind einzigartig gegenüber anderen IT-Systemen und es hilft, wenn das Sicherheitsteam diese Unterschiede versteht.
Es ist auch wichtig, dass Sie die Bedenken des Sicherheitsteams verstehen. Wenn Sie wissen, welche Programme sie erfüllen müssen, können Sie Sicherheitsaufträge auf Anforderungen zurückführen und die Absicht des ursprünglichen Programms besser erfüllen.
Die Nachverfolgung von Anforderungen ist ein wichtiger Teil der Vorbereitung Ihres Teams auf die Bereitstellung sicheren Programmcodes. Ein guter Tracking-Prozess bietet mehr als nur das Speichern von Anforderungen, sondern auch die Rückverfolgbarkeit dieser Anforderungen. Ihr Team sollte in der Lage sein, eine Anforderung während des gesamten Lebenszyklus nachzuvollziehen:
Anforderungsdefinition → Entwurf → Implementierung → Test → Fehlerbehebung → Freigabe
Diese Rückverfolgbarkeit dient bei Kundenaudits, Sicherheitserklärungen (wie CRA), Bewertungen (wie CMMC) oder Lieferantensicherheitsprüfungen als Nachweis.
GitHub Issues + Projects + Milestones ist der häufigste Ansatz zur Anforderungsverfolgung für die meisten kleineren Teams. Weitere Optionen zur Nachverfolgung sind GitLab (mit kostenlosen und kostenpflichtigen Tarifen), Azure DevOps, JIRA und andere professionelle Softwareentwicklungswerkzeuge. Mit diesen Tools können Sie Probleme erstellen und diese bis zur Lösung verfolgen.
Verfolgen Sie systematisch die Sicherheitsanforderungen in Ihrem ausgewählten Tool. Jede Anforderung sollte folgende Kriterien erfüllen:
Nachdem Sie ein Tool zur Nachverfolgung von Anforderungen identifiziert haben, dokumentieren Sie Ihren Prozess, um die Verwendung dieser Tools in Ihre Entwicklung einzubeziehen. Verwenden Sie den Prozess für die Nachverfolgung von Anforderungen und Problemen während des gesamten Lebenszyklus des Systems. Ihr Prozess kann folgende Schritte umfassen:
Planen Sie, Ihren Code modular zu gestalten. In LabVIEW ist dieser Schritt besonders hilfreich, da Sie einzelne Module testen können. Planen Sie bei der Planung Ihrer modularen Architektur auch die Entwicklung von Unit-Tests. Diese verbessern die Codequalität und bieten eine schnellere Möglichkeit, Programmcode nach Updates zu validieren, auch nachdem das System bereitgestellt wurde.
Weitere Informationen zur Verwendung des NI Unit Test Frameworks
Die Testwerkzeuge von Drittanbietern bieten zusätzlichen Nutzen. So erweitern beispielsweise die Produkte Caraya und LUnit von JKI die Softwaretests für LabVIEW Teams.
Definieren eines Prozesses zum Prüfen und Genehmigen von Unteraufträgen, Software von Drittanbietern und Open-Source-Komponenten Ihr Prozess sollte öffentliche Datenbanken wie Common Vulnerabilities and Exposures (CVE) überprüfen, um bekannte Sicherheitslücken in den verwendeten Komponenten zu identifizieren.
Wenn Sie Open-Source-Komponenten verwenden, sind Sie dafür verantwortlich, Sicherheitslücken zu scannen, bevor Sie den Code in Ihrer Anwendung verwenden.
Definieren Sie spezifische Rollen in Ihrem Team, einschließlich sicherheitsspezifischer Rollen. Bestimmen Sie die Verantwortlichkeiten und den Zugriff auf jede dieser Rollen. Definieren Sie mindestens Rollen mit privilegiertem Zugriff (Administratoren) getrennt von Benutzerrollen (Entwickler und Operatoren).
Erstellen Sie Sicherheitsschulungen für diese Rollen. Weisen Sie das Training den Teammitgliedern zu und verfolgen Sie den Abschluss des Trainings. Diese Datensätze werden als Nachweise in einer Zertifizierungsprüfung verwendet.
Nutzen Sie das Online-Sicherheitstraining von NI: Kurs zu Sicherheitsaspekten bei der Integration von Testsystemen.
Branchenzertifizierungsprogramme wie ISC2 bieten kostengünstige Einführungszertifikate. Der Wert dieser Programme für ein Testteam besteht darin, eine gemeinsame Sprache für die Kommunikation mit Sicherheitsteams bereitzustellen.
Nachdem Sie Ihr SDLC definiert haben, legen Sie es der Unternehmensführung vor und erhalten Sie deren formelle Unterstützung. Es sollte mindestens von der Ebene genehmigt werden, die das Sicherheitsbudget genehmigt, um ihr Engagement für das Programm zu zeigen.
Identifizieren Sie als Unternehmen die möglichen Datentypen und erstellen Sie ein Beschriftungssystem. Folgende Datentypen sollten berücksichtigt werden:
Mit einem klaren Datenmanagement- und Beschriftungssystem können Sie die Daten angemessen schützen und die richtigen Beschränkungen auf jede Datenklassifizierung anwenden. Wenn Sie dies als Organisation definieren, bevor Sie mit der Systementwicklung beginnen, sparen Sie Zeit, indem Sie die richtigen Kontrollen auf die richtigen Risikobereiche anwenden. Die Zuordnung in bestehende Unternehmens- und IT-Kennzeichnungssysteme vereinfacht den Datenaustausch zwischen Systemen.
Bestimmen Sie die Software- und Treiberversionen und -konfigurationen, auf die Sie zur Sicherheit standardisieren möchten. Geben Sie in LabVIEW die Version an, die Sie für die Entwicklung verwenden möchten. Richten Sie eine sichere Konfiguration für Ihre Installationen ein. Sie können dem Leitfaden zur sicheren Konfiguration von LabVIEW folgen. Weitere sichere Konfigurationshinweise finden Sie auf ni.com/security.
Automatisieren Sie für die Überprüfbarkeit und das schnelle Einrichten neuer Systeme, wie Entwicklungs- und Build-Computer eingerichtet werden. Erstellen Sie eine Basisinstallation und erstellen Sie ein Image von dieser Installation.
Richten Sie Tools ein, die während Ihrer gesamten Entwicklung für Sicherheitsprüfungen verwendet werden. Zum Analysieren Ihres Quellcodes ohne Ausführen des Programms benötigen Sie ein Tool für statische Anwendungssicherheitstests (SAST), um potenzielle Sicherheitslücken zu finden. Für grafischen LabVIEW-Code empfehlen wir die JKI Security Suite, die speziell für die statische Analyse von LabVIEW-Code entwickelt wurde. Alternativ können Sie eine manuelle statische Codeanalyse durchführen, um nach Sicherheitsproblemen zu suchen.
SAST-Tools sind ein wichtiges Sicherheitswerkzeug, um Programmcode auf Schwachstellen zu analysieren. Dynamische Tools für Anwendungssicherheitstests (DAST) sind ebenfalls wichtig und werden verwendet, um den laufenden Code während des Tests zu scannen. Die Softwarezusammensetzungsanalyse (SCA) identifiziert die Verwendung von Open-Source-Bibliotheken, Paketen von Drittanbietern und Softwarekomponenten und durchsucht diese auf bekannte Schwachstellen und Lizenzprobleme.
Es gibt viele andere Arten von Tools zum Scannen von Programmcode auf Sicherheitsprobleme. Das richtige Tool für Ihr Projekt hängt von Ihrem Toolset, der Art Ihres Projekts und den verwendeten Code-Arten ab. In dieser Phase des sicheren Entwicklungslebenszyklus ist es wichtig, die Tools zu untersuchen und zu identifizieren, die Ihr Team verwenden wird.
Die sichere Entwicklung erfordert, dass Quellcode mit mehreren Versionen gespeichert wird, so dass Teams auf vorherige Versionen zurückgreifen können, falls etwas im Programmcode fehlerhaft ist. Im Rahmen der Vorbereitung der Organisation auf die sichere Entwicklung sollten Sie ein Code-Repository einrichten, das Programmcode speichert, Code für die Entwicklung auscheckt und die Versionsverwaltung des Quellcodes übernimmt.
Verzweigungen im Code-Repository erleichtern die parallele Entwicklung und stabile Releases. Definieren Sie die Zweigtypen, die Sie in Ihrem Unternehmen verwenden möchten. Diese Verzweigungstypen sind Standard, können aber an Ihre Bedürfnisse angepasst werden:
Verwenden Sie ein Repository, das ordnungsgemäße Sicherheitskontrollen bereitstellt. Stellen Sie sicher, dass das Repository für die Rückverfolgbarkeit eine vollständige Historie der Commits und Änderungen speichert.
Vergewissern Sie sich, dass die für die Entwicklung von Programmcode verwendeten Computer grundlegenden Cybersicherheitsrichtlinien folgen. Diese grundlegenden Elemente umfassen Passwortschutz, Schutz vor schädlichem Code und andere grundlegende Cyberhygiene. Ein Beispiel für diese grundlegenden Kontrollen finden Sie unter https://www.acquisition.gov/far/52.204-21.
Erfassen Sie zur Rückverfolgbarkeit die Konfigurationseinstellungen des Computers, auf dem das System entwickelt wurde. Zu erfassende Konfigurationseinstellungen umfassen die folgenden Beispiele:
Die meisten Sicherheitsprogramme erfordern Nachweise, dass Ihr Team die im Rahmen der SSDF festgelegten Methoden befolgt hat. Richten Sie ein Repository ein, um Nachweise nachzuverfolgen und diese während der Entwicklung und Bereitstellung des Systems aktuell zu halten. Das System sollte die folgenden Elemente nachverfolgen:
Viele Teams führen diese Sicherheitsmaßnahmen durch, können jedoch nicht nachweisen, dass sie sie durchgeführt haben. Compliance-Teams werden beides sehen wollen: dass Ihr Team Prozesse eingerichtet hat und dass Sie diese befolgen. Diese Dokumente an einem Ort zu haben, vereinfacht Audits und Compliance-Prüfungen erheblich.
Wenn das Unternehmen darauf vorbereitet ist, Programmcode sicher zu entwickeln, ist die nächste Aufgabe der Schutz der Software. Dieser Schritt stellt sicher, dass das Team den Code während der Entwicklung und Veröffentlichung sicher verwahrt.
Der Schutz von Software während des Entwicklungsprozesses ist für jede Software unabhängig von der verwendeten Programmiersprache von entscheidender Bedeutung. Da LabVIEW Teams professionelle Workflow-Tools für die Softwareentwicklung verwenden, müssen diese Teams auch sichere Entwicklungsprozesse und -werkzeuge verwenden.
Verwenden Sie die in der vorherigen Phase identifizierten sicheren Code-Repositorys, um Ihren Code zu speichern und zu verwalten. Ein gutes Repository kann mehr als nur den Quellcode verwalten. Es enthält außerdem die Anforderungen, Dokumentation, Build-Skripte, Testartefakte und Versionshistorien. Da das Repository so viel Code und Unterstützung enthält, ist es wichtig, ein sicheres Repository zu verwenden. Wenn das Repository kompromittiert ist, ist Ihre Software kompromittiert.
Innerhalb des Repositorys ist Ihr Hauptzweig ein wichtiges Gut, das geschützt werden muss. Ihr Team sollte Richtlinien zum Schutz des Programmcodes festlegen und befolgen. Diese Richtlinien können die folgenden Beispiele enthalten:
Das Repository sollte außerdem Rückverfolgbarkeit von der Erstellung einer Anforderung, über die Entwicklung bis hin zur Produktfreigabe bieten. Einige Repositorys erlauben das Signieren von Commits (z. B. in Git).
Das Repository sollte einen Audit-Trail bereitstellen, indem Softwareänderungen aufgezeichnet werden. Was hat sich geändert, wer hat es geändert, warum wurde es geändert, wer hat es genehmigt und wann wurde es freigegeben? Darüber hinaus sollten Release-Images in einem sicheren Archiv gesichert werden, so dass Programmcode abgerufen werden kann, auch wenn das Repository kompromittiert ist.
Ein SBOM enthält eine Liste von Software und Komponenten, die bei der Entwicklung des Codes verwendet werden. Durch das Erzeugen eines SBOM als Teil des Build-Prozesses wird sichergestellt, dass Sie ein Protokoll darüber haben, welche Komponenten im Programmcode verwendet werden, wodurch der Prozess zum Erkennen und Beheben von Sicherheitslücken optimiert wird.
Ab LabVIEW 2026 Q3 können Sie SBOMs als Teil des Build-Prozesses von Anwendungen erzeugen. Weitere Informationen finden Sie unter Erstellen einer Software-Stückliste für eine eigenständige Anwendung.
Mit der Code-Signierung können Benutzer überprüfen, ob Software von einer bekannten Organisation erstellt wurde, seit der Veröffentlichung nicht verändert wurde und für den Vertrieb freigegeben wurde. In einer LabVIEW-Anwendung sollte die Codesignierung auf ausführbare Dateien, Installationsprogramme, Bereitstellungspakete, DLLs, Treiber und Update-Pakete angewendet werden.
Sie können Ihre Anwendung während des Build-Prozesses signieren, indem Sie diese Anweisungen befolgen. Sie können Software auch mit SignTool.exe von Microsoft signieren, was genauso ist wie das Signieren von Anwendungen oder Dateien.
Anwendungen erfordern häufig Secrets wie Passwörter, API-Schlüssel, Zertifikate, Token, Verschlüsselungsschlüssel, Datenbank-Zugangsdaten und Zugangsdaten für Dienstkonten. Diese Secrets bieten Zugriff auf Systeme und Daten und müssen während des gesamten Softwarelebenszyklus geschützt werden.
Codieren Sie Passwörter, API-Schlüssel, Zertifikate oder Verschlüsselungsschlüssel niemals direkt in Quellcode, Konfigurationsdateien, Build-Skripte oder Testprogramme fest. Hardkodierte Secrets sind schwierig zu rotieren, können in Repositories kopiert werden und können durch Quellcodeprüfungen, Backups oder Reverse Engineering von verteilten Anwendungen aufgedeckt werden.
Speichern Sie Secrets nach Möglichkeit mithilfe eines sicheren, durch das Betriebssystem oder Hardware geschützten Speichers. Beispiele für sicheren oder geschützten Speicher umfassen die folgenden Optionen:
Wenden Sie bei der Gewährung des Zugriffs auf Secrets das Prinzip der kleinsten Berechtigungen an. Nur Benutzer, Systeme und Dienste, die Zugriff auf ein Secret benötigen, sollten es abrufen können. Administrative Zugangsdaten sollten von Benutzerzugangsdaten getrennt werden und gemeinsam genutzte Konten sollten nach Möglichkeit vermieden werden.
Passwörter, Zertifikate, API-Schlüssel und Verschlüsselungsschlüssel sollten entsprechend der Organisationsrichtlinie regelmäßig ersetzt werden. Erstellen Sie einen Prozess, der definiert, wie Secrets erzeugt werden, wo sie gespeichert werden, wer darauf zugreifen kann und wie kompromittierte Secrets widerrufen werden.
Testsysteme verwenden häufig reale Netzwerkverbindungen, Datenbanken, Cloud-Dienste und Instrumente. Testteams benötigen während des Tests Zugriff auf diese Systeme. Verwenden Sie nach Möglichkeit spezielle Test-Zugangsdaten anstelle von Produktions-Zugangsdaten. Getrennte Testumgebungen reduzieren das Risiko, operative Systeme während der Entwicklung und Validierung zu gefährden.
Diese Phase konzentriert sich auf das sichere Entwerfen, Implementieren, Testen und Validieren von Software. Um diese Aufgabe effektiv zu erfüllen, muss ein Team die Risiken und Anforderungen der beabsichtigten Softwarenutzung bewerten und auf diese Risiken hin entwerfen. Bewährte Methode sind nach Möglichkeit die Wiederverwendung bekannter sicherer Komponenten, Tests während der Entwicklung und das Scannen von Entwicklungscode auf Schwachstellen. Teams planen eine sichere Verwendung, einschließlich der Verwendung von sicheren Standardeinstellungen.
Test- und Messanwendungen stehen vor anderen Sicherheitsherausforderungen als allgemeine Softwareanwendungen. LabVIEW Teams sind in der Lage, diese Herausforderungen zu verstehen und Software zu entwickeln, die vor Angriffen auf ihre Anwendungen schützt. LabVIEW bietet eine Reihe von inhärenten Sicherheitsvorkehrungen, aber Teams müssen die möglichen Angriffe in Betracht ziehen und eine Verteidigung gegen sie vorbereiten.
OWASP (Open Worldwide Application Security Project) ist eine gemeinnützige Stiftung, die kostenlose Tools, Anleitungen und Standards zum Erstellen sicherer Software bereitstellt. OWASP bietet einen Community-basierten Leitfaden zur Bedrohungsmodellierung. Das Modell umfasst eine strukturierte Reihe von Schritten, um Ihre Arbeit abzugrenzen, Bedrohungen sowie Gegen- und Minderungsmaßnahmen zu bestimmen und Ihre Arbeit zu bewerten.
Für Testteams beginnt dies mit einem Gespräch, um den beabsichtigten Einsatz und die Bedrohungen für das in der Entwicklung befindliche System zu verstehen. Das Gespräch sollte den Lead-Entwickler, Testarchitekten, Systemingenieur, Produktinhaber, Cybersicherheitsbeauftragten und Betriebspersonal umfassen.
Der OWASP-Ansatz umfasst eine Bedrohungsliste, die Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service und Elevation of Privilege enthält (STRIDE). STRIDE-Bedrohungskategorien helfen einem Team, alle Arten von Bedrohungen zu berücksichtigen.
Testteams sollten auf ihre Erfahrungen in Brainstorming-Sessions zurückgreifen, um speziell zu untersuchen, wie sich Bedrohungen auf ihre Systeme in einer Testumgebung auswirken:
Durch Hinzufügen dieser testspezifischen Risiken zu herkömmlichen Cyberbedrohungen können Sie geeignete Verteidigungsstrategien für das Testsystem identifizieren. Das Ergebnis der Bedrohungsmodellierung sollte eine Reihe priorisierter Risiken sowie die Sicherheitsanforderungen sein, die zur Minderung dieser Risiken erforderlich sind. Diese Anforderungen werden zu Inputs für den Systementwurf und die Entwicklung, die im nächsten Abschnitt beschrieben werden. Regelmäßige Bedrohungsprüfungen können Teams dabei helfen, neue und neu auftretende Bedrohungen im Laufe der Zeit zu identifizieren und können eine Überprüfung von Problemen beinhalten, die vorherige Bedrohungen nicht erfasst haben.
Die Bedrohungsmodellierung identifiziert Risiken für das System. Der nächste Schritt besteht darin, diese Risiken in messbare Sicherheitsanforderungen umzusetzen, die während des gesamten Lebenszyklus implementiert, getestet und nachverfolgt werden können. Sicherheitsanforderungen sollten genauso streng behandelt werden wie funktionale Anforderungen.
Eine Sicherheitsanforderung definiert eine Sicherheitskontrolle oder ein Sicherheitsverhalten, das vom System bereitgestellt werden muss. Gute Sicherheitsanforderungen sind spezifisch, messbar, überprüfbar und nachvollziehbar. In der folgenden Tabelle finden Sie einige Beispiele.
Sicherheitsanforderungen sollten eindeutige Kennungen erhalten und über dieselben Anforderungsmanagement-Tools nachverfolgt werden, die für funktionale Anforderungen verwendet werden.
Eine klar definierte Sicherheitsanforderung sollte über den gesamten Entwicklungszyklus hinweg nachvollziehbar sein. Die Rückverfolgbarkeit zeigt, dass identifizierte Risiken adressiert wurden, und liefert wertvolle Hinweise bei Kundenaudits, Lieferantensicherheitsbewertungen und behördlichen Überprüfungen.
Test- und Messsysteme haben Sicherheitsanforderungen, die in Unternehmenssoftwareprojekten oft übersehen werden. Verwenden Sie bei der Entwicklung von Sicherheitsanforderungen Standardsicherheitskategorien, berücksichtigen Sie aber auch die folgenden Daten:
Da ungenaue Messungen und fehlerhafte Testergebnisse erhebliche geschäftliche Konsequenzen haben können, sind Sicherheitsanforderungen an die Integrität oft genauso wichtig wie Anforderungen an die Vertraulichkeit.
Modularer Programmcode schränkt die Auswirkungen von Fehlern und Sicherheitslücken ein, indem er Funktionen in wohldefinierte Komponenten mit gesteuerten Schnittstellen isoliert. Bei einem guten modularen Aufbau stellt jedes Modul nur die Funktionen bereit, die andere Module benötigen. Dadurch gibt es weniger Eintrittspunkte und weniger Möglichkeiten für Missbrauch. Modularer Code hat außerdem den Vorteil, dass er einfacher getestet werden kann, so dass Updates einfacher angewendet und validiert werden können.
Beachten Sie beim Erstellen modularen Programmcodes das Prinzip der kleinsten Berechtigungen. Ein Modul sollte nur die Berechtigungen haben, die für die Ausführung seiner Funktion erforderlich sind. So benötigt z. B. eine Gerätekommunikationsfunktion keinen Zugriff auf eine Datenbank, da dies von einem anderen Modul verarbeitet wird. Vermeiden Sie das Weiterleiten des Datenbank-Handles an das Instrumentenkommunikationsmodul.
Beurteilen Sie das Vertrauen in die Kommunikation, wenn Daten zwischen Modulen ausgetauscht werden. Prüfen Sie ggf. die Quelle, bevor Sie Daten von einer anderen Komponente annehmen.
Modularer Code soll die Sicherheitsüberprüfung erleichtern. Jedes Modul kann überprüft werden, anstatt den gesamten Programmcode bei jeder Überprüfung zu überprüfen. Der Codeprüfer muss nicht den gesamten Code verstehen, um zur Sicherheit einer einzelnen Komponente beizutragen.
Codemodule vereinfachen auch die Wiederverwendung von Code. Ein Modul, das sicher entwickelt und getestet wurde, kann mit der Gewissheit, dass es bestimmungsgemäß funktioniert, in anderen Anwendungen wiederverwendet werden.
Erstellen Sie Bewährte Methoden und folgen Sie diesen. Ihre Codeprüfungen sollten die Einhaltung dieser Methoden überprüfen. Eine vollständige Überprüfung bewährter Methoden fällt zwar nicht in den Anwendungsbereich dieses Dokuments, sollte jedoch mindestens folgende Bereiche umfassen:
Verwenden Sie ein anerkanntes LabVIEW Unit Test Framework (NI Unit Test Framework, JKI Caraya oder LUnit). Mit diesen Tools können Entwickler Ein- und Ausgänge definieren und überprüfen, ob der Programmcode ordnungsgemäß funktioniert. Dies kann ohne Ausführung der gesamten Anwendung erfolgen, was die Codevalidierung vereinfacht.
Unit-Tests schützen sensible Funktionen wie die Steuerung teurer Geräte, da Module isoliert getestet werden können. Unit-Tests sollten für die wiederholbare Ausführung konzipiert sein und idealerweise in ein kontinuierliches Integrationssystem integriert werden, um sicherzustellen, dass sie automatisch bei Codeänderungen ausgeführt werden.
Häufige Sicherheitsüberprüfungen sind ein wichtiger Teil der Etablierung einer sicherheitsgerichteten Entwicklungskultur. Überprüfungen bieten Teams die Möglichkeit, sichere Praktiken zu etablieren, voneinander zu lernen und sichere Prozesse zu stärken. Sicherheitsüberprüfungen beginnen vor der Entwicklung – Überprüfung der geplanten Architektur und Methoden. Die Bewertungen sollten dann während des gesamten Entwicklungsprozesses fortgesetzt werden, um sicherzustellen, dass Programmcode sicher entwickelt wird. Die Häufigkeit sollte sich nach der Größe der Entwicklung richten; Überprüfungen sollten so häufig stattfinden, dass Probleme behoben werden können, bevor eine signifikante nachgelagerte Entwicklung stattgefunden hat. Bewertungen sollten bei jeder Merge-Anfrage, Pull-Anfrage oder einem anderen wichtigen Code-Integrationsereignis durchgeführt werden. Für große Projekte können zusätzliche geplante Überprüfungen angebracht sein.
Sicherheitsüberprüfungen werden erheblich verbessert, wenn ein Team anhand einer Checkliste arbeitet. Diese Checklisten sollten von der Organisation erstellt und zu Beginn jedes Projekts basierend auf der Bedrohungs- und Risikoanalyse angepasst werden.
Führen Sie zusätzlich zu manuellen Codeprüfungen automatisierte Codeprüfungen durch. Wenn Sie einen kontinuierlichen Integrations- und kontinuierlichen Bereitstellungsprozess (CI/CD) verwenden, fügen Sie Ihrem Aufnahmeprozess Sicherheits-Scans hinzu, so dass Programmcode bei jedem Code-Check-in gescannt wird. Richten Sie zusätzliche Scan-Tools ein, die täglich oder wöchentlich ausgeführt werden können, um neu eingeführte Sicherheitslücken zu finden, bevor sie zu einem festen Bestandteil des Codes werden. Verwenden Sie statische Analysen, Einheitentests und andere Sicherheits-Scan-Tools, um eine Vielzahl von Überprüfungstypen einzuschließen.
Verwenden Sie nach Möglichkeit die neueste Version der Entwicklungssoftwaretreiber. Fast täglich werden neue Sicherheitsbedrohungen erkannt und Entwickler erstellen Sicherheitskorrekturen in Patches und neuen Softwareversionen. Wenn Sie die neueste Version nicht verwenden können, verwenden Sie Software, die noch Sicherheits-Updates vom Hersteller erhält und diese für die gesamte Lebensdauer des Systems erhält.
Konfigurieren Sie Ihre Werkzeuge für die Sicherheit mit Hilfe der Konfigurationshinweise des Herstellers.
Siehe die Liste der unterstützten Softwareversionen für NI-Produkte
Finden Sie Anleitungen zu NI-Produkten
Führen Sie vor der Veröffentlichung des Produkts Tests basierend auf den zu Beginn des Projekts erkannten Bedrohungen und Risiken durch. Diese Liste kann folgende Tests enthalten:
Da LabVIEW eine grafische Programmiersprache ist, können einige traditionelle Sicherheitswerkzeuge LabVIEW Code nicht testen. Tools wie die JKI Security Suite bieten sicherheitsorientierte statische Analysefunktionen für LabVIEW Entwickler, mit denen LabVIEW Code durchsucht und auf die spezifischen Sicherheitsanforderungen einer grafischen Programmiersprache abgestimmt werden kann.
Weitere Informationen zur JKI Security Suite
Eine Version sollte nur genehmigt werden, wenn das Entwicklerteam nachweisen kann, dass das Bedrohungsmodell überprüft wurde, kritische Sicherheitslücken behoben wurden, Einheitentests durchgeführt und bestanden wurden, statische Analysen durchgeführt wurden, ein SBOM erstellt wurde, Codeprüfungen durchgeführt wurden und das Versionspaket signiert wurde. Durch die Durchsetzung eines formellen Release-Gate-Prozesses kann das Management prüfen, ob Prozesse befolgt wurden und die Software sicher ist.
Die Entwicklung sicherer Software ist nur ein Teil des Prozesses. Eine sichere Anwendung kann verwundbar werden, wenn sie falsch bereitgestellt wird oder wenn Sicherheitskontrollen während der Installation und Konfiguration entfernt werden. Der Bereitstellungsprozess sollte daher als Teil des sicheren Softwareentwicklungslebenszyklus mit definierten Verfahren, Überprüfungen und Validierungsaktivitäten behandelt werden, bevor Software für Benutzer freigegeben wird.
Sichere Standardkonfiguration
Anwendungen sollten mit sicheren Standardeinstellungen bereitgestellt werden. Benutzer gehen häufig davon aus, dass Standardeinstellungen die empfohlene Konfiguration darstellen. Alle sicherheitsrelevanten Optionen, die standardmäßig deaktiviert sind, können während der gesamten Lebensdauer des Systems deaktiviert bleiben.
Sichere Standardeinstellungen können folgende Beispiele enthalten:
Benutzer sollten aufgefordert werden, Sicherheitseinstellungen bewusst zu schwächen, anstatt manuell Sicherheitsschutz zu aktivieren.
Produktionshärtung
Entfernen Sie vor der Veröffentlichung Entwicklungsartefakte und -funktionen, die während der Entwicklung nützlich sind, aber unnötige Risiken in Produktionsumgebungen verursachen. Prüfen Sie die Anwendung auf folgende Kriterien:
Produktionssysteme sollten nur die für den Betrieb des Systems erforderlichen Funktionen bereitstellen.
Konto- und Berechtigungsverwaltung
Überprüfen Sie die vom System benötigten Berechtigungen und weisen Sie sie den entsprechenden Rollen zu. Systeme sollten nur Administratorrechte erteilen, wenn ein dokumentierter betrieblicher Bedarf besteht. Dienstkonten sollten nur mit den Berechtigungen konfiguriert werden, die für die Ausführung ihrer beabsichtigten Funktion erforderlich sind. Wenn Sie rollenbasierte Berechtigungen in Betracht ziehen, beachten Sie:
Wenn das System vertrauliche Informationen speichert, prüfen Sie, ob die Zugriffskontrollen diese Informationen angemessen schützen.
Netzwerksicherheitskonfiguration
Dokumentieren Sie alle erforderlichen Netzwerkkommunikationen vor der Bereitstellung. Betrachten Sie für jede Verbindung, die vom System hergestellt wird:
Wenn Daten Netzwerkgrenzen überschreiten, müssen sie geschützt werden. Treffen Sie für jede Datenübertragung folgende Vorsichtsmaßnahmen:
Testsysteme sind oft gleichzeitig mit Unternehmensnetzwerken, Fertigungsnetzwerken, Cloud-Diensten und Messgeräten verbunden. Das Verstehen und Dokumentieren dieser Vertrauensgrenzen ist eine wichtige Bereitstellungsaktivität.
Secret- und Zugangsdatenverwaltung
Anwendungen erfordern oft Passwörter, API-Schlüssel, Zertifikate, Token oder Verschlüsselungsschlüssel. Achten Sie beim Umgang mit diesen geheimen Token darauf, nicht:
Verwenden Sie stattdessen eines der folgenden Werkzeuge oder Technologien:
Dokumentieren Sie, wie Secrets erstellt, gespeichert, rotiert, gesichert und widerrufen werden. Folgen Sie diesem Prozess.
Protokollierung und Auditierung
Anwendungen sollten wichtige betriebliche und sicherheitsrelevante Ereignisse aufzeichnen. Zu protokollierende Ereignisse umfassen die folgenden Beispiele:
Vergewissern Sie sich, dass die Protokollierung keine Secrets wie Passwörter und persönliche oder vertrauliche Informationen umfasst, da Protokolle für Zielgruppen sichtbar sein können, die nicht für diese Informationen vorgesehen sind.
Protokolle helfen bei der Fehlersuche, untersuchen Vorfälle und zeigen die Einhaltung von Kunden- und behördlichen Anforderungen.
Integrieren Sie Anwendungsprotokolle nach Möglichkeit in Plattformprotokollierungsmechanismen wie Windows Event Viewer oder Linux Syslog, um die Überwachung, Untersuchung von Vorfällen und Compliance-Berichte zu vereinfachen. Prüfen Sie, ob das Senden von Protokollen an einen sicheren Server Schutz und Zugänglichkeit bietet.
Schützen Sie Audit-Protokolle vor unbefugtem Zugriff und unbefugter Änderung und legen Sie fest, wie lange Protokolle gespeichert werden.
Freigabegenehmigung
Führen Sie vor der Veröffentlichung von Software eine letzte Sicherheitsüberprüfung durch, um sicherzustellen, dass die Anwendung die Release-Anforderungen des Teams erfüllt. Fügen Sie als Teil dieser abschließenden Überprüfung Folgendes ein:
Der Freigabeprozess sollte Nachweise dafür liefern, dass diese Tätigkeiten abgeschlossen wurden. Diese Nachweise sollten nach der Freigabe vor Manipulationen geschützt werden, um die Integrität zu erhalten.
Code-Signierung und Paketintegrität
Benutzer sollten überprüfen können, ob veröffentlichte Software von der erwarteten Organisation stammt und seit der Veröffentlichung nicht verändert wurde.
Codesignierung sollte auf alle folgenden Softwaretypen angewendet werden:
Die Code-Signierung verhindert keine Software-Änderungen, bietet aber eine starke Erkennung von nicht autorisierten Änderungen und die Gewissheit, dass Software vom erwarteten Herausgeber stammt.
Bereitstellungsvalidierung
Vergewissern Sie sich nach der Installation, dass das bereitgestellte System in seiner vorgesehenen Umgebung sicher funktioniert. Validierungsaktivitäten sollten folgende Funktionen bestätigen:
Die Sicherheitsvalidierung sollte immer dann durchgeführt werden, wenn wesentliche Konfigurationsänderungen vorgenommen werden.
Bereitstellungsnachweise
Führen Sie Aufzeichnungen, die belegen, dass die Bereitstellung gemäß dem definierten Prozess durchgeführt wurde. Diese Datensätze enthalten die folgenden Beispiele:
Diese Aufzeichnungen bieten wertvolle Rückverfolgbarkeit bei Kundenaudits, Lieferantenbewertungen, behördlichen Überprüfungen und internen Sicherheitsuntersuchungen.
Eine Software-Schwachstelle ist eine Schwachstelle, ein Fehler oder ein Defekt im Softwareentwurf, in der Implementierung, Konfiguration oder in betrieblichen Prozessen, die ausgenutzt werden kann, um die Vertraulichkeit, Integrität oder Verfügbarkeit eines Systems oder seiner Daten zu beeinträchtigen. Eine Sicherheitslücke kann im vom Team entwickelten Code oder in einer der in der Software verwendeten Komponenten erkannt werden. Da Sicherheitslücken böswilligen Akteuren eine Möglichkeit bieten, ein System zu beschädigen, ist es wichtig, dass diese Sicherheitslücken behoben und Patches auf betroffenen Systemen bereitgestellt werden.
Die Testbranche steht vor einer historischen Herausforderung, wenn sie auf Schwachstellen reagiert. Viele Testprojekte werden über ein einziges Vorfinanzierungsmodell finanziert – ohne Finanzierung für die laufende Wartung der Systeme. Das bedeutet, dass Testteams nicht über die Ressourcen verfügen, um Systeme zu aktualisieren, selbst um Sicherheits-Updates bereitzustellen. Dies stellt einen direkten Konflikt mit den Sicherheitsanforderungen dar, um Systeme auf dem neuesten Stand zu halten.
Eine große Herausforderung ist die Validierung, die für Aktualisierungen erforderlich ist. Auch wenn die Software- und Hardware-Tools keine Kosten verursachen, kann ein Update sehr teuer sein, um zu überprüfen, ob das System nach dem Update wie beabsichtigt funktioniert.
Im Zuge des Wandels in der Sicherheitsbranche muss auch die Testbranche beginnen, Testsysteme während ihres gesamten Lebenszyklus besser zu planen und zu finanzieren. Es gibt einige Schritte, die Testteams unternehmen können, um zu einem vollständigen Lifecycle-Management-Ansatz zu wechseln, einschließlich:
Schwachstellen in NI-Produkten, einschließlich LabVIEW, Treibern und anderer Software, werden auf ni.com/security bekannt gegeben. Patches werden auch über das System Common Vulnerabilities and Exposures (CVE) gemeldet. Mit diesen Patches können Sicherheitslücken im von NI-Ingenieuren entwickelten Softwarecode oder in den von uns verwendeten Komponenten behoben werden. Sie können sich auf ni.com/security für Benachrichtigungen über neue Patches anmelden.
Ein SBOM kann auch verwendet werden, um Scans der Software zu automatisieren. Wenn Sie aus Ihrer LabVIEW Anwendung eine SBOM erzeugen, können Sie Scan-Software einrichten, um die CVE-Datenbank auf gemeldete Probleme zu überprüfen und Sie zu benachrichtigen. Es gibt eine Vielzahl von Software-Kompositionsanalyse-Tools (SCA), die SBOMs scannen und mit der CVE-Datenbank abgleichen.
Wenn Ihr Endnutzer eine Sicherheitslücke erkennt, kann er Ihnen dies direkt melden. Wenn sich das Problem in der NI-Software befindet, können Sie dies auf ni.com/security melden.
Es ist wichtig, Schwachstellenberichte ernst zu nehmen. Wenn Ihr Benutzer ein Problem meldet oder wenn eine Sicherheitslücke in Ihrem Softwarestapel gemeldet wird, analysieren Sie die Sicherheitslücke, um die Auswirkungen und die Wahrscheinlichkeit zu ermitteln, dass sie ausgenutzt wird. Diese Probleme hängen von der Art der Sicherheitslücke und der Art und Weise ab, wie Sie die betroffene Softwarekomponente verwendet haben. Wenn Sie feststellen, dass das Risiko einer Ausnutzung erheblich ist, müssen Sie Ihre Software aktualisieren und Ihrem Endnutzer einen Patch bereitstellen.
Einige Vorschriften, wie der European Cybersecurity Resilience Act (CRA), schreiben vor, dass Sie Sicherheits-Patches für mindestens fünf Jahre bereitstellen müssen. Einige Verträge können längere oder kürzere Unterstützungsverpflichtungen enthalten. Planen Sie für dieses Maß an Unterstützung in Ihrem ursprünglichen Projektvorschlag, um Überraschungen nach der Bereitstellung des Projekts zu vermeiden.
Führen Sie im Rahmen Ihres Prozesses zur Behebung von Sicherheitslücken eine Ursachenanalyse der Sicherheitslücke durch, um Ihren Entwicklungsprozess zu verbessern und ähnliche Probleme in zukünftigen Projekten zu vermeiden.
Sichere Softwareentwicklung ist keine separate Aktivität, die am Ende eines Projekts ausgeführt wird. Es handelt sich um eine Reihe von Praktiken, die während des gesamten Lebenszyklus eines Systems integriert sind. LabVIEW Teams können Sicherheitslücken reduzieren, die Wartbarkeit verbessern, Compliance-Maßnahmen vereinfachen und die ihnen anvertrauten Systeme und Daten besser schützen. Sicherheit ist ein Prozess und Ihr Team wird mit der Zeit reifen. Beginnen Sie jetzt mit der Einrichtung eines wiederholbaren und nachhaltigen Prozesses, der die Sicherheit während der Lebensdauer der Produkte kontinuierlich verbessert.
| Bedrohung | Sicherheitsanforderung |
|---|---|
| Unzulässige Änderung von Testergebnissen | Nur authentifizierte Benutzer mit der entsprechenden Rolle dürfen gespeicherte Testergebnisse bearbeiten. |
| Abfangen des Netzwerkverkehrs | Die gesamte Kommunikation zwischen der Anwendung und externen Systemen muss verschlüsselte Protokolle verwenden. |
| Beschädigung von Kalibrierdaten | Kalibrierdaten sind vor unbefugten Änderungen zu schützen und alle Änderungen sind zu protokollieren. |
| Nicht autorisierte Gerätesteuerung | Administrative oder gefährliche Ausrüstungen erfordern authentifizierte und autorisierte Benutzer. |