Das robuste Sicherheitsprogramm von Blackboard verhindert nicht nur das Auftreten von Sicherheitsproblemen, sondern bekämpft diese Probleme an der Wurzel. Blackboard führt kontinuierliche interne Sicherheitstests auf Codeebene (statische Analysen) und Anwendungsebene (dynamische Analyse) durch. Damit erfüllt Blackboard nicht nur die eigenen Erwartungen, sondern auch die der Kunden. Darüber hinaus lässt Blackboard regelmäßig von Drittanbietern Sicherheits-Penetrationstests durchführen, um einen neuen Blick auf die eigenen Anwendungen zu gewinnen. Wenn Probleme ermittelt werden, wird sofort die Lösung geplant.

Das Sicherheitsprogramm von Blackboard befindet sich im Zustand der kontinuierlichen Weiterentwicklung. Wir arbeiten ununterbrochen daran, die Sicherheitsfunktionen und die Robustheit der Blackboard-Produkte weiter zu verbessern.


Auf Sicherheit ausgerichtet

Blackboard ist es wichtig, sichere Anwendungen für seine Kunden bereitzustellen. Blackboard orientiert sich bei der Produktentwicklung an einer Reihe von technischen Sicherheitsleitlinien, die von Organisationen wie dem Open Web Application Security Project (OWASP) abgeleitet sind. Hierunter fallen auch konkrete Gegenmaßnahmen für die in den OWASP Top Ten aufgeführten Sicherheitsrisiken. Blackboard integriert diese Sicherheitspraktiken in allen Phasen des Software-Entwicklungszyklus.

Blackboard setzt verschiedene Methoden zum Schutz Ihrer Anwendungen ein. Hier sind u. a. „Top-Down“-Sicherheitsbewertungen durch Bedrohungsmodellierung und -analyse zu nennen, aber auch „Bottom-Up“-Erkennung von Bedrohungen auf Codeebene durch statische Berechnungen, dynamische Analysen und manuelle Penetrationstests.

Zur Stärkung der Sicherheit der Produkte und Programme folgt Blackboard den Best-Practice-Anweisungen zahlreicher Organisationen. Im Folgenden sind einige dieser Organisationen aufgeführt:

  • National Institute of Standards and Technology (NIST)
  • Europäische Agentur für Netz- und Informationssicherheit (ENISA)
  • SANS Institute
  • Open Web Application Security Project (OWASP)
  • Cloud Security Alliance (CSA)

Bedrohungsmodelle

Im Rahmen der Entwicklung neuer Funktionen entwickelt das Sicherheitsteam ein Bedrohungsmodell, um die Anforderungen und das Systemdesign zu beurteilen und zu einer Reduzierung der Risiken beizutragen. Die Erstellung von Bedrohungsmodellen ist ein strukturierter Prozess, bei dem potenzielle Sicherheitsbedrohungen für die untersuchte Funktion ermittelt werden. Auf dieser Grundlage können angemessene Gegenmaßnahmen erarbeitet und ergriffen werden.


Sichere Codeerstellung und die OWASP Top 10 der Sicherheitsrisiken

Die Produktentwicklung bei Blackboard orientiert sich von einer Reihe von Entwicklungsleitlinien des Open Web Application Security Project (OWASP). Diese Leitlinien umfassen auch konkrete Gegenmaßnahmen für die in den OWASP Top Ten des Jahres 2013 aufgelisteten Sicherheitsrisiken .

A1: Injektion (Injektion von SQL-/DOM-/LDAP-Code)Unser Codestandard ist die Verwendung von Bind-Variablen. Außerdem sollen in SQL-Anweisungen transkribierte Literale vermieden werden. Die LDAP-Funktionen sind auf die Authentifizierung beschränkt.
A2: Probleme bei Authentifizierung und SitzungsmanagementBlackboard-Produkte werden ausschließlich unter TLS ausgeführt, d. h., sämtliche Cookies werden verschlüsselt.
A3: Siteübergreifende Skripterstellung (Cross-site Scripting, XSS)Die Auswirkungen von XSS werden durch die Nutzung gemeinsamer Bibliotheken wie ESAPI und gemeinsamer Entwicklungsstandards abgemildert. Sämtlicher von den Endbenutzern eingegebener Text soll bereinigt werden; alle anderen Arten von Input (Daten, Auswahl- und Optionswerte) sollen aus eingegebenen Domänenobjekten heraus erzeugt und nicht direkt aus der Benutzereingabe heraus transkribiert werden.
A4: Unsichere direkte ObjekteverweiseAuf sämtliche Anwendungsobjekte wird über „IDs“ verwiesen, die in der Regel dem Primärschlüssel zugeordnet werden. Alle Objekte werden jedoch einem „Kontext“ zugeordnet, und sämtliche Sicherheitsprüfungen erfolgen anhand dieses „Kontexts“. So verweist eine Anforderung beispielsweise unter Umständen auf eine „Nachrichten-ID“, bei der es sich um einen Diskussionsbeitrag für einen Kurs handelt. Der Standard bei Blackboard besteht darin, die Autorisierungsprüfung für die mit einer Benutzerrolle verknüpfte Berechtigung vorzunehmen.
Wenn dieser Standard nicht korrekt umgesetzt wird, ist eine Abhilfe einfach, weil alle geschützten Dateneinheiten im System einem Sicherheitskontext (Kurs oder Domäne) zugeordnet sind.
A5: Fehlerhafte SicherheitskonfigurationBlackboard verfolgt eine Strategie der standardmäßigen Sicherheit. Wenn eine besondere Berücksichtigung durch den Systemadministrator erforderlich ist, werden Versionshinweise und Dokumentation herangezogen. Blackboard ermutigt die Kunden, dem Best-Practice-Leitfaden für die sichere Konfiguration zu folgen, insofern ein solcher vorhanden und für das konkrete Blackboard-Produkt relevant ist.

Sicherheitsprüfungen
Sicherheitsereignisse werden in speziellen Protokollen festgehalten.

Informationslecks und Fehlerbehandlung
Die Standard-Fehlerbehandlung wird auf alle Seiten angewendet (über eine Standardseitenvorlage und eine Tag-Bibliothek). Hieraus ergibt sich ein Standard-Output für alle Fehler, insbesondere nicht erkannte Fehler. Der Standard-Output enthält unter Umständen ein Stacktrace (kleines Informationsleck), aber keine Daten, die beim Fehlschlag der Anforderung verarbeitet wurden. Der Output kann nur von Personen mit Administratorrechten eingesehen werden. Benutzer ohne derartige Berechtigungen (etwa Kursteilnehmer) können keine detaillierten Stacktraces aufrufen.

A6: Enthüllung vertraulicher DatenBlackboard verschlüsselt Benutzerkennwörter standardmäßig mit SHA-160.

Blackboard-Produkte können unter TLS ausgeführt werden, jedoch muss derjenige, der TLS bereitstellt, auch für die ordnungsgemäße TLS-Konfiguration sorgen, wenn er das Produkt selbst hostet.

A7: Fehlende Zugriffssteuerung auf FunktionsebeneDas Management findet auf zwei Ebenen statt. Zum einen werden Autorisierungsprüfungen erzwungen, zum anderen decken die QA-Tests die Autorisierungsanforderungen für unterschiedliche Bildschirme ab.
A8: Siteübergreifende Anfragenfälschung (Cross-site Request Forgery, CSRF)Unser Sicherheitsrahmen orientiert sich an den OWASP-Empfehlungen für anfrageneigene Nonce-Werte und reiner POST-Semantik. AJAX-Anfragen nutzen sitzungseigene Nonce-Werte.
A9: Verwendung von Komponenten mit bekannten SicherheitsrisikenHier können regelmäßige Risikoprüfungen der Infrastruktur und der Softwarepakete von Drittanbietern Abhilfe schaffen. Auf diese Weise lassen sich die Komponenten ermitteln, die ein Sicherheitsrisiko darstellen. Anschließend kann ein Fahrplan für das Upgrade aller Komponenten, für die entsprechende Patches verfügbar sind, aufgestellt werden.
A10: Nicht geprüfte Weiter- und UmleitungenGemäß Blackboard-Standard für die sichere Codeerstellung müssen Weiter- und Umleitungen daraufhin geprüft werden, ob es sich um lokale Adressen handelt. Dieses Sicherheitsrisiko wird regelmäßig überprüft.

Sämtliche Angaben zu zukünftigen Erwartungen, Plänen und potenziellen Kunden von Blackboard stellen die aktuelle Einschätzung des Unternehmens dar. Die tatsächliche Entwicklung kann aufgrund zahlreicher wichtiger Faktoren hiervon erheblich abweichen. Das Unternehmen geht davon aus, dass alle zukünftigen Ereignisse und Entwicklungen Auswirkungen auf die Ansichten des Unternehmens haben werden. Das Unternehmen nimmt daher unter Umständen in Zukunft Änderungen an diesen Aussagen vor. Hiermit weist das Unternehmen jedoch jedwede Verpflichtung zu einer solchen Aktualisierung explizit zurück.