Company Topimage

Parasoft® Deutschland GmbH

https://www.parasoft.de
Firma bearbeiten

10.06.2021

Auswahl und Implementierung des richtigen sicheren Codierstandards

Es gibt in der Softwareindustrie eine große Zahl von Security-Standards. Einige davon bieten ganzheitliche Leitlinien über systemweite Security-Praktiken und -Prozeduren, aber nicht unbedingt codespezifische Richtlinien. Andere dagegen warten mit spezifischen Empfehlungen zu sicheren Codierstandards auf. Wenn in Ihrem Unternehmen die Notwendigkeit eines sicheren Codierstandards festgestellt und die entsprechenden statischen Codeanalyse-Tools beschafft wurden, Sie also startbereit sind, stellt sich die Frage, welcher Codierstandard für Ihr Projekt am sinnvollsten ist.

Explizite Standards

CWE - Common Weakness Enumeration

CWE ist eine Liste aufgedeckter Software-Schwachstellen und basiert auf der Analyse gemeldeter Anfälligkeiten (CVEs). Die von der Software-Community entwickelte Initiative wird von der US-Regierung finanziert und von der MITRE-Organisation gemanagt. Die CWE-Liste umfasst mehr als 800 Einträge. Aufgelistet sind Exploits mit einer hohen Auftretenswahrscheinlichkeit und weitreichenden Auswirkungen. CWE Top 25 und der weniger bekannte Ableger „On-the-Cusp“ sind per se keine Codierstandards, sondern eine Aufstellung von Schwachstellen, die es zu vermeiden gilt, um die Sicherheit zu verbessern. Für ein CWE-konformes Projekt sollte man nachweisen können, dass geeignete Maßnahmen zur Erkennung und Vermeidung gängiger Schwachstellen ergriffen wurden. CWE Top 25 und On-the-Cusp wurden 2019 aktualisiert.

Die CWE nutzt eine Risikobewertungs-Methode zur Ermittlung der Top 25 (und On-the-Cusp). Darin fließt die Gefährlichkeit einer Schwachstelle in der realen Welt nach CWSS-Messung (Common Weakness Scoring System) ein. Folgewirkungen können Denial of Service (DoS, DDoS), der Lese- oder Schreibzugriff auf geschützte Informationen, unbefugter Zugang usw. sein.

OWASP

Im Fokus des Open Web Application Security Projects (OWASP) steht die Verbesserung der Sicherheit von Web-Applikationen. Dementsprechend erstellt das OWASP Top 10 Projekt eine Liste der gängigsten und folgenreichsten Sicherheits-Schwachstellen von Web-Applikationen. Die neueste Version der OWASP Top 10 ist direkt mit bestimmten CWE-IDs korreliert, was die Implementierung als Codierstandard deutlich vereinfacht, während gleichzeitig die Nutzung für Penetration Tests und DAST-Tools möglich ist.

SEI/CERT

Das Computer Emergency Response Team (CERT) des Software Engineering Institute (SEI) hält eine Reihe von Richtlinien bereit, die Entwicklern bei der Realisierung von Software hilft, die mehr Safety, Security und Zuverlässigkeit bietet. Im Jahr 2006 anlässlich einer Versammlung des C Standard Committee begonnen, wurde der erste CERT C Standard 2008 publiziert und anschließend fortlaufend weiterentwickelt. Die CERT Secure Coding Standards zielen auf die Vermeidung der Grundursachen von Sicherheits-Schwachstellen.

Zu CERT gehört ein Risikobewertungs-System, das die Wahrscheinlichkeit des Auftretens, den Schweregrad und die relative Schwierigkeit der Entschärfung einbezieht und den Entwicklern beim Aufstellen einer Prioritätsrangfolge hilft. Die Einbeziehung des Entschärfungsaufwands in die Prioritätsbewertung stellt eine wichtige Ergänzung zu den CERT Secure Coding Standards dar. Es handelt sich bei ihnen um echte, sprachlich formulierte Codierrichtlinien, für die es Querverweise zu anderen Codierstandards wie MISRA C gibt, sodass sie sich sehr gut für sicherheitskritische Software eignen.

 PCI DSS

Beim Payment Card Industry Data Security Standard (PCI DSS) handelt es sich um einen Informationssicherheits-Standard für Unternehmen, die in irgendeiner Form mit Kreditkartendaten zu tun haben. Er enthält allgemeine Sicherheitskontrollen zum Absichern von Applikationen und insbesondere zum Schutz privater Informationen. Der Standard ist allgemein gehalten, deckt einen großen Bereich ab und bezieht Ops-Aspekte ebenso ein wie den Datenschutz. Speziell Abschnitt 6 skizziert die Notwendigkeit eines Schwachstellenmanagement-Programms, zu dem ein Teilabschnitt sicherer Codierstandards gehört. Abschnitt 6.5 des PCI DSS-Standards fordert die Berücksichtigung gängiger Codier-Schwachstellen und listet ähnlich wie die OWASP Top 10 zehn gängige Schwachstellen auf.

 

Implizite Standards

Es gibt Sicherheitsnormen, die nicht explizit einen Codierstandard verlangen, auch wenn sie ausdrücklich einen oder mehrere der oben genannten Standards empfehlen. Diese Richtlinien dienen der Verbesserung der Sicherheit auf der System-Ebene und enthalten beispielsweise Sicherheitskontrollen, die den Rahmen der Quellcode-Entwicklung sprengen. Allerdings müssen Softwareteams – je nach Markt, auf den ihr Produkt zielt - diese Standards erfüllen. Eine Diskussion der Auswirkungen auf die Entwickler ist somit wichtig.

 

UL 2900

Das Underwriter’s Laboratory (UL) ist bekannt für seine Tests zur funktionalen Sicherheit elektronischer Geräte. Mit der Entwicklung der Norm UL 2900, einer Reihe von Standards, die das Cybersecurity Assurance Program (CAP) der UL bilden, hat die Organisation einen Vorstoß in den Security-Sektor unternommen. Der Zweck dieser Standards ist die Verbesserung der Sicherheit netzwerkfähiger Produkte (z. B. IoT-Geräte), mit Varianten für Geräte aus dem Medizin- und Nuklearbereich. Die medizinische Variante der UL 2900 wurde von der amerikanischen FDA als geeignet zur Absicherung von medizinischen Geräten und Software anerkannt.

UL 2900 ist ein Zertifizierungs-Standard. Anders als bei einigen der übrigen hier erwähnten Standards muss die Konformität nachgewiesen und ein Audit bestanden werden. Er verlangt den Einsatz statischer Analysetools, um die Sicherheit zu verbessern und die Konformität zu Codierstandards zu automatisieren.

 

GDPR/DSGVO

Die Datenschutz-Grundverordnung (DSGVO) bzw. englisch General Data Protection Regulation (GPDR) ist Bestandteil von EU-Gesetzen zum Schutz der Daten und Privatsphäre von EU-Bürgern. Dazu schreibt sie vor, dass Unternehmen, die private Daten verwenden und speichern, die entsprechenden technischen und verwaltungsmäßigen Prinzipien zum Schutz dieser Daten befolgen. Diese Regelungen sind mit empfindlichen Strafen belegt und gelten für Unternehmen auf der ganzen Welt, sofern sie Informationen über EU-Bürger speichern. Der kritische Aspekt der DSGVO für Softwareentwickler ist das Konzept des eingebauten und durch Voreinstellungen gegebenen Datenschutzes (Privacy by Design and By Default). Der Datenschutz ist also von Anfang an in die Software eingebaut und behandelt die Software aller personenbezogenen Daten normalerweise als geschützt und privat. Auf Anfrage müssen die Daten von Personen gelöscht werden.

 

Auswahl und Umsetzung eines Codierstandards

Die vielen Sicherheits- und Datenschutz-Richtlinien erschweren die Entscheidung, welche die richtige für ein zu entwickelndes Produkt ist. Sofern es für einen bestimmten Markt keine etablierten Richtlinien gibt, beginnt man am besten mit einer einfach anwendbaren Richtlinie, die problemlos mit der statischen Analyse eingesetzt werden kann und großen Einfluss auf die Anwendungssicherheit hat.

Oftmals versuchen Softwareteams einen Codierstandard zu strikt durchzusetzen und sehen sich dann von den Ergebnissen und dem Arbeitsaufwand überfordert. Entscheidend ist ein pragmatischer Ansatz:

 

Abdeckung eines möglichst großen Teils des Standards mit statischer Analyse: Der Schlüssel zum Erfolg ist die Automatisierung, denn die Richtlinien können damit auf einen großen Codeumfang angewendet werden, und die Abhängigkeit von Peer Reviews verringert sich. Je mehr ein Tool leistet, umso weniger Zeit muss man aufwenden, und umso stimmiger, objektiver und reproduzierbarer (wichtig für Audits) werden die Resultate sein. Außerdem sollte das statische Analysetool unbedingt möglichst viele Richtlinien des gewählten Codierstandards abdecken.

 

Feinabstimmung der Konfiguration: Die ausgewählten Checker und die Konfiguration des statischen Analysetools sollten auf die Anforderungen des jeweiligen Projekts abgestimmt werden. Man sollte die Tools zudem korrekt in den täglichen Arbeitsablauf einbinden, damit sie einfach zugänglich sind und problemlos genutzt werden können. Die Ergebnisse müssen dort zu finden sein, wo sie die Entwickler benötigen – also in der IDE und nicht in ihrer E-Mail oder ihrem Browser. Außerdem muss die Analyse sowohl in der IDE als auch im Rahmen der Build- und CI/CD-Pipelines erfolgen können.

 

Präventive Checker zum Eliminieren bestimmter Probleme: Einige Probleme, wie etwa SQL-Injektionen, lassen sich bereits vorab mit bestimmten Checker-Konfigurationen abwenden. Es ist hilfreich, zu diesem Zweck Checker zu aktivieren, die bei der Vermeidung ganzer Klassen folgenreicher Sicherheitsprobleme helfen. Man sollte sich die Mühe machen, Sicherheitsprobleme dieser Art sofort bei deren Aufdeckung zu vermeiden. Vorbeugen ist besser als frühzeitige Erkennung.

 

So klein anfangen wie nötig und dann steigern:

Bei großen Codebasen kann die statische Analyse eine große Zahl von Warnmeldungen generieren, was das Entwicklungsteam überfordern und gelegentlich sogar vor der Nutzung dieser Tools zurückschrecken lässt. Ein Sortieren und Ausfiltern der gravierendsten Schwachstellen ist ebenso sinnvoll wie das Eingrenzen des Umfangs der Analyse. Man kann beispielsweise die statische Analyse auf neu hinzugekommenen Code beschränken oder existierende Warnungen ausfiltern, um neue Warnmeldungen während der Entwicklung sofort bei ihrem Erscheinen abzuarbeiten. Klein anzufangen und den Umfang der Analyse Schritt für Schritt zu vergrößern ist besser als möglicherweise überfordert zu werden und zu scheitern.

 

Wichtige Eigenschaften von statischen Analysetools, die ihren Einsatz erleichtern

Statische Analysetools sind nicht alle gleich, und sie sind mehr als nur die reine Analyse-Engine. Es kommt nicht nur auf die Qualität und Tiefe der Analyse an, sondern auch auf die Speicherung, die Auswertung der Ergebnisse und die Integration mit anderen Entwicklungs-Tools wie etwa IDEs und CI/CD-Pipeline-Tools.

 Unterstützung für den Betrieb in der IDE

Die statische Analyse funktioniert am besten, wenn sie Regelverletzungen, Bugs und Sicherheits-Schwachstellen sofort beim Schreiben des Codes abfängt. Ebenso müssen die Entwickler Zugang zu den Ergebnissen der Analyse des kompletten Builds haben.

 

Unterstützung für den Betrieb auf Build-Servern und CI-Systemen

Genauso wichtig ist die statische Analyse auf der Projektebene, da die Analyse hier den Quellcode komplett oder zumindest zum Großteil erfasst. Komplexe Analysen wie etwa die Datenfluss-Analyse funktionieren in diesem Modus am besten. Überdies sollte die Analyse in eine bestehende Continuous-Integration- und Deployment-Toolchain sowie den zugehörigen Workflow integriert sein. Die Tools müssen darüber hinaus die einzelnen Analysen für jede Datei und jeden Build verfolgen. Zusammen mit dem Betrieb in der IDE erlaubt dies die Implementierung einer Vorgehensweise nach dem Prinzip „Vertrauen ist gut, Kontrolle ist besser“. Diese ist am effektivsten und beeinflusst den eigenen Arbeitsablauf nicht so negativ, wie es einige strikt abgegrenzte CI-Security-Implementierungen versuchen.

 

Zentralisierte Konfigurationskontrolle

Eine zentrale Kontrolle der Test- und Analyse-Konfiguration ist nicht nur entscheidend für das Deployment der Standards bei allen Entwicklern im Team. Es stellt auch die beste Möglichkeit dar, Einstellungen feinabzustimmen und einheitlich im gesamten Team vorzunehmen. Ein zentralisiertes System setzt stets denselben Standard durch, damit alle Teammitglieder sicher mit dem richtigen Standard arbeiten.

 

Zentralisierung von Reporting, Audit und Analytik

Die Reporting- und Analytik-Funktionen gehören zu den kritischen Aspekten der statischen Analysetools. Projekte erzeugen große Datenmengen, die mit jedem Build weiter wachsen. Der Umgang mit diesen Daten ist entscheidend für die erfolgreiche Nutzung und Rentabilität eines statischen Analysetools. Genau auf jeden Codierstandard und jede Sicherheitsrichtlinie abgestimmte Dashboards, Reports und Konformität sind von kritischer Bedeutung. Analysen, die sich auf Risikomodelle stützen und bei der Priorisierung helfen, verkleinern ganz erheblich den Berg an Regelverstößen, die ein Tool ohne weitere Vorverarbeitung liefert.

Lückenlose Checker-Palette

Eine umfassende Auswahl an Checkern ist entscheidend, um unterschiedliche Anwendungsfälle für die statische Analyse zu unterstützen. Benötigt werden Checker, die Fehler und Schwachstellen detektieren, präventive Checker und auch solche für Code, der beim ersten Hinsehen nicht korrekt aussieht und eine nähere Betrachtung erfordert. Auch wichtig ist die Unterstützung komplexer, fortschrittlicher Checker mithilfe der Datenfluss-Analyse, sie hilft beim Aufdecken schwierig zu findender Fehler.

 

Erforderlich sind darüber hinaus Checker, die Probleme von vornherein vermeiden, indem beispielsweise die Validierung von Eingangsdaten erzwungen wird, anstatt zu versuchen, alle möglichen Arten zum Verfälschen von Daten aufzudecken. Man benötigt nicht zuletzt eine umfassende Palette an präventiven Checkern, beispielsweise für die als Industriestandard etablierten Safety- und Security-Richtlinien wie CERT, MISRA, OWASP und CWE.

 

Zusammenfassung

Ein solides Softwareentwicklungs-Konzept soll qualitativ hochwertigen Code entwickeln, der den etablierten Best Practices entspricht. Für bestimmte Produkte oder Märkte wird die Frage, welche Best Practices man befolgen soll, durch bereits bestehende Industriestandards beantwortet. Fehlt es jedoch an solchen Standards, ist die Entscheidung für das richtige Konzept nicht unbedingt leicht.

Damit Entwickler sicheren und privaten Code ‚by design‘ entwickeln können, erhalten sie bei modernen Tool-Anbietern wie Parasoft Guidelines, die die Anwendung bestehender Standards und Richtlinien erläutern. Darin enthalten ist komplette Unterstützung für die wichtigen Standards mit Hilfe verschiedener Methoden und Checkertypen, die sowohl Frühwarnung als auch Vermeidung ermöglichen. Die durchgängigen Testlösungen von Parasoft für C/C++, Java und .NET bieten bislang unerreicht breite Unterstützung für die Security-Standards AUTOSAR C++14, CWE Top 25 und „On the Cusp”.

Die Optimierung des Auditverfahrens ermöglicht das detaillierte Konformitätsreporting über web-basierte, standardspezifische Dashboards mit Checkern für verschiedene Standards (u.a. OWASP, CWE, AUTOSAR C, CERT C, MISRA C), die einen schnellen Gesamtüberblick über den Projektstatus liefern ebenso wie zu Regelverletzungen und mehr. Das spezielle, auf CWE ausgerichtete Modell von Parasoft erlaubt es Anwendern zudem, die Ergebnisse der statischen Analyse mit jenen von CWE zu verknüpfen, ohne dass wie bei anderen Tools mühsame Zuordnungen oder zusätzliche Arbeit erforderlich sind. So lässt sich schneller nachvollziehen, wie die Konformität erzielt wurde, außerdem sind die Auditreports als PDF-Downloads verfügbar.

 

Ein solides Softwareentwicklungs-Konzept soll qualitativ hochwertigen Code entwickeln, der den etablierten Best Practices entspricht. Für bestimmte Produkte oder Märkte wird die Frage, welche Best Practices man befolgen soll, durch bereits bestehende Industriestandards beantwortet. Fehlt es jedoch an solchen Standards, ist die Entscheidung für das richtige Konzept nicht unbedingt leicht.