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

Produkte von Blackboard werden gemäß einer Reihe von Entwicklungsrichtlinien entwickelt, die aus OWASP stammen, darunter bestimmte Gegenmaßnahmen für die OWASP Top 10 der Sicherheitsrisiken von 2013.

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.

Frühere Kategorien von Sicherheitsrisiken in den OWASP Top 10

Ausführen schadhafter DateienDateien, die von nicht privilegierten Endverbrauchern hochgeladen werden, werden nie als ausführbare Datei verwendet. Privilegierte Benutzer (d. h. Systemadministratoren), können jedoch ausführbare Pakete hochladen, die als Building Blocks bezeichnet werden und die Funktionalität des Systems erweitern. Es wird davon ausgegangen, dass Systemadministratoren die Risiken, eine eingehende Prüfung durchführen und Verwaltungspraktiken bei der Installation von Building Blocks von Drittanbietern ändern.

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.


Verpflichtungs- und Offenlegungspolitik für Vulnerability-Management

Das Verwaltungsprogramm für Sicherheitsrisiken von Blackboard unterliegt der unten stehenden öffentlichen Verpflichtungs- und Offenlegungspolitik für Vulnerability-Management. Kein Softwarehersteller ist perfekt – falls in einem veröffentlichten Produkt eine Sicherheitslücke festgestellt wird, ist das Sicherheits-Team von Blackboard bereit, darauf zu reagieren.

Hilfe bei der Anmeldung erhalten Sie vom IT-Helpdesk Ihrer Institution. Blackboard hat keinen Zugriff auf Kontoinformationen, Websites oder Inhalte Ihrer Institution. Wenn Sie nicht wissen, wie Sie den Helpdesk kontaktieren können, suchen Sie im Internet nach dem Namen Ihrer Institution und dem Helpdesk oder schauen Sie auf der Anmeldeseite nach einem Supportlink oder nach Kontaktinformationen.

Blackboard ist darauf bedacht, Sicherheitslücken schnell und sorgfältig zu beheben. Derartige Behebungen können dazu führen, dass Sicherheitsanweisungen und/oder eine erforderliche Produktaktualisierung für unsere Kunden freigegeben wird/werden. Um unsere Kunden und ihre Daten zu schützen, bitten wir darum, dass Schwachstellen verantwortungsbewusst und vertraulich gemeldet werden, damit wir diese untersuchen darauf reagieren können. Sicherheitsrisiken sollten erst bekannt gegeben werden, wenn ein Produkt-Update entwickelt und umfassend getestet wurde und dieses für lizenzierte Kunden verfügbar ist.

Die Produkte von Blackboard sind komplex. Sie laufen mit diversen Hard- und Software-Konfigurationen und sind mit vielen Anwendungen von Drittanbietern verbunden. Alle Software-Modifikationen – ob groß oder klein – erfordern eine gründliche Analyse sowie die Entwicklung und Implementierung über mehrere Produktlinien und Versionen hinweg. Die Software muss entsprechend ihrem Zweck, ihrer Komplexität und ihres Schweregrads der Lokalisierung, Barrierefreiheit und Prüfung unterzogen werden. Angesichts der hohen Bedeutung unserer Produkte für unsere Kunden muss Blackboard sicherstellen, dass diese nicht nur in unseren Testanlagen, sondern auch in Kundenumgebungen ordnungsgemäß ausgeführt werden. Daher kann Blackboard keine Produktaktualisierungen gemäß einem festgelegten Zeitrahmen bereitstellen, wir sind jedoch bestrebt, schnell zu reagieren.

Böswillige Parteien nutzen häufig Software-Sicherheitsrisiken aus, indem sie Sicherheitsrisiken anhand von veröffentlichten Sicherheitsanweisungen und Produktaktualisierungen rekonstruieren. Es ist wichtig, dass Kunden ihre Software umgehend aktualisieren und unser Bewertungssystem für den Schweregrad als Richtlinie verwenden, um Aktualisierungen besser zu planen. Daher ist die Bekanntmachung von Sicherheitsrisiken nur dann angemessen, wenn Kunden die Möglichkeit haben, Produkt-Updates zu erhalten.

Tests auf Sicherheitslücken

Sie sollten alle Tests in Bezug auf Sicherheitsrisiken auf nicht-produktiven Instanzen unserer Produkte durchführen, um das Risiko für Daten und Dienste zu minimieren.


So melden Sie ein Sicherheitsrisiko

Teilen Sie Details zu einem potenziellen Sicherheitsrisiko vertraulich, indem Sie ein Meldeformular für Sicherheitsrisiken ausfüllen.

Geben Sie Details zu potenziellen Sicherheitsrisiken an, damit das Blackboard-Sicherheitsteam das Problem schnell validieren und reproduzieren kann. Ohne die oben genannten Informationen ist es möglicherweise schwierig, wenn nicht gar unmöglich, das potenzielle Sicherheitsrisiko zu beheben. Berichte, in denen zahlreiche mögliche Sicherheitsrisiken ohne Details aufgelistet sind, werden ohne weitere Klärung nicht berücksichtigt. Details sollten Folgendes beinhalten:

  • Art des Sicherheitsrisikos;
  • Ob die Informationen veröffentlicht oder mit anderen Parteien geteilt wurden;
  • Betroffene Produkte und Versionen;
  • Betroffene Konfigurationen; und
  • Schritt-für-Schritt-Anweisungen oder einen Code des Wirksamkeitsnachweises zur Reproduktion des Problems.

Sicherheitsversprechen von Blackboard

Allen, die Sicherheitsrisiken unter Einhaltung dieser Richtlinie melden, versucht Blackboard Folgendes zu garantieren:

  • Eingangsbestätigung Ihres Berichts;
  • Untersuchung innerhalb eines angemessenen Zeitrahmens und Bestätigung des potenziellen Sicherheitsrisikos, falls zutreffend;
  • Bereitstellung eines Plans und Zeitrahmens für die Behebung des Sicherheitsrisikos, falls zutreffend; und
  • Benachrichtigung an den Berichterstatter, sobald das Sicherheitsrisiko behoben wurde.

Anerkennung von Beiträgen

Blackboard verfügt nicht über ein Prämien-Programm für das Melden von Sicherheitsrisiken. Daher stellt Blackboard keine Anerkennungen oder Entschädigungen für die Meldung von Sicherheitsrisiken bereit.