Blackboard dispose d'un solide programme de sécurité qui agit non seulement pour empêcher l'apparition de problèmes de sécurité, mais également pour les éliminer. Blackboard effectue des tests de sécurité internes continus au niveau du code (analyse statique) et des applications (analyse dynamique) pour s'assurer qu'ils répondent aux attentes de Blackboard et de nos clients.

De plus, pour garder constamment un regard neuf sur l'application, Blackboard récupère des tests de pénétration de sécurité de la part de fournisseurs tiers. Tout problème identifié est rapidement corrigé.

Il est important de réaliser que le programme de sécurité de Blackboard est une pratique de plus en plus répandue et évolutive. Nous sommes engagés dans un processus d'amélioration constante pour renforcer les dispositifs de sécurité et la robustesse dans Blackboard Learn.


Sécurité intégrée

Blackboard s'est engagé à fournir à ses clients des applications sécurisées. Nous développons Blackboard Learn conformément à des instructions techniques de sécurité provenant de nombreux organismes, tels que la communauté OWASP (Open Web Application Security Project), notamment des mesures de protection spécifiques contre les 10 principales vulnérabilités OWASP. Blackboard incorpore ces pratiques de sécurité dans toutes les phases du cycle de développement de ses logiciels.

Blackboard utilise plusieurs méthodes pour protéger ses applications, notamment en effectuant des évaluations de sécurité « descendantes » via des analyses et une modélisation des menaces, et en réalisant une détection « ascendante » des menaces au niveau du code via des analyses statiques, des analyses dynamiques et des tests de pénétration manuels.

Blackboard suit les pratiques d'excellence de nombreux organismes pour renforcer la sécurité du produit et du programme Blackboard Learn, notamment les suivants :

  • National Institute of Standards and Technology (NIST)
  • Agence européenne chargée de la sécurité des réseaux et de l’information (ENISA)
  • SANS Institute
  • Open Web Application Security Project (OWASP)
  • Cloud Security Alliance (CSA)

Modélisation des menaces

Au fur et à mesure que de nouvelles fonctionnalités sont mises au point, l'équipe de sécurité évalue les exigences et la conception du système pour faciliter l'atténuation des risques en effectuant la modélisation des menaces. La modélisation des menaces est un processus structuré dans lequel les menaces de sécurité portant sur la fonctionnalité étudiée sont identifiées afin que des mesures de sécurité appropriées puissent être identifiées et appliquées.


Codage sécurisé et les dix principales vulnérabilités de l'OWASP

Blackboard développe des produits en tenant compte d'un ensemble d'instructions techniques de développement émises par le projet de sécurité communautaire OWASP (Open Web Application Security Project), y compris des mesures de protection contre les 10 principales vulnérabilités OWASP pour 2013.

A1 : injection (injection SQL/DOM/LDAP)Notre norme de codage consiste à utiliser des variables bind et à éviter les littéraux transcrits en instructions SQL. Xpath n'est utilisé nulle part dans l'application ; la fonctionnalité LDAP est limitée à l'authentification.
A2 : authentification interrompue et gestion des sessionsNous prenons différentes mesures pour éviter de compromettre les cookies de session. Learn fonctionne uniquement sous TLS depuis avril 2014. L'indicateur Sécurisé est donc activé pour tous les cookies. De plus, nous essayons de détecter des changements inattendus dans l'état du client (comme une session provenant d'adresses IP inattendues). Les cookies liés à la gestion des sessions sont définis sur HttpOnly (remarque : JSESSIONID n'est pas utilisé pour la gestion des sessions et n'est donc pas destiné à être signalé par l'indicateur HttpOnly).
A3 : script de site à site (XSS)Les scripts de site à site sont atténués par l'utilisation de bibliothèques partagées, telles que ESAPI et les normes de développement. Toutes les saisies soumises par l'utilisateur doivent normalement être transmises par des méthodes d'assainissement. Tous les autres types de saisie (dates, valeurs de sélection/d'option) doivent être générés à partir d'objets de domaine saisis, plutôt que transcrits directement à partir des saisies utilisateur.
A4 : références d'objets directs non sécurisésTous les objets applicatifs sont référencés via des ID qui correspondent généralement à la clé primaire. Cependant, tous les mappages d'objets et toutes les vérifications de sécurité sont effectués par rapport à un « contexte ». Par exemple, une demande peut faire référence à un « ID de message » qui est un message envoyé sur le forum de discussion d'un cours. Conformément à la norme Blackboard, nous contrôlons l'autorisation du privilège lié au rôle de l'utilisateur dans le cours. Dans les cas où cette norme n'est pas appliquée de manière correcte, la réparation est simple puisque toutes les entités de données protégées dans le système sont associées à un contexte de sécurité (cours ou domaine).
A5 : erreur de configuration de la sécuritéBlackboard Learn applique une politique de sécurité par défaut avec des notes de mise à jour et l'utilisation d'une documentation lorsque l'attention de l'administrateur système est nécessaire. Blackboard encourage ses clients à suivre son guide des meilleures pratiques de configuration sécurisée.

Infrastructure

Les clients sont encouragés à utiliser Apache™ 2.x avec des recommandations documentées concernant l'autorisation exclusive de chiffrements très complexes pour la protection des couches de transport. Blackboard examine régulièrement les avis de sécurité relatifs à l'infrastructure de Blackboard Learn pour s'assurer qu'elle est protégée contre les failles de sécurité.

Audit de sécurité

Les événements de sécurité sont consignés dans l'un des trois journaux de sécurité prévus à cet effet. Le cadre des événements de sécurité fournit un ensemble de codes d'événement standard, le format de journalisation standard, la verbosité des champs et le niveau de responsabilité. L'ensemble des événements consignés dans chaque code d'événement est en constante expansion.

Données d'identification

Lors de l'installation, les administrateurs système doivent définir des mots de passe.

Fuites d'informations et gestion des erreurs

La gestion des erreurs standard est appliquée à toutes les pages (via un modèle de page standard et une bibliothèque de balises). Il en résulte une sortie standard pour toutes les erreurs, en particulier les erreurs non reconnues. La sortie standard inclut une trace de pile (fuite d'informations mineures), mais aucune des données traitées lors de l'échec de la requête, et n'est visible que pour ceux qui ont un accès au niveau administrateur. Les utilisateurs non privilégiés (comme les étudiants) ne peuvent pas consulter les traces détaillées de la pile.
A6 : exposition aux données sensiblesLes mots de passe utilisateur font l'objet d'un hachage, pas d'un chiffrage. À partir de Blackboard Learn, version 9.1 Service Pack 12, les mots de passe des utilisateurs sont, par défaut, hachés et remplacés par une valeur SALT avec SHA-512. La feuille de route de sécurité des produits Blackboard Learn propose des plans pour gérer les mots de passe système qui sont utilisés pour le démarrage des applications, et qui sont protégés par défaut par le système d'exploitation et le contrôle d'accès au système de fichiers. Blackboard Learn prend en charge SSL. Cependant, il appartient au responsable du déploiement de configurer correctement SSL. SSL Offloading est également pris en charge par Blackboard Learn, version 9.1 Service Pack 8 et version supérieure.
A7 : contrôle d'accès au niveau de fonction manquantEn raison d'une gestion à deux niveaux, la logique métier doit appliquer des contrôles d'autorisation et veiller à ce que les cas de test d'assurance-qualité couvrent les exigences d'autorisation pour différents écrans. Tous les écrans/liens sont potentiellement affichés. Il n'existe aucune d'URL « masquée » nécessitant une saisie manuelle. Par conséquent, l'application doit filtrer l'accès des écrans aux URL avant d'essayer de les afficher.
A8 : falsification de requête intersites (CSRF)Notre cadre de sécurité suit les recommandations de l'OWASP pour les valeurs uniques (nonce) à la demande et la sémantique POST-Only. Les demandes AJAX utilisent des valeurs uniques (nonce) par session. DWR utilise un envoi à double cookies d'une valeur unique (nonce) par session.
A9 : utilisation de composants présentant des vulnérabilités connuesCe problème est atténué par la réalisation d'analyses régulières des vulnérabilités de notre infrastructure et des paquets logiciels tiers afin d'identifier les composants présentant des vulnérabilités connues et d'élaborer une feuille de route pour mettre à niveau les composants avec les correctifs disponibles.
A10 : redirections et transferts non validésLa norme de codage sécurisé de Blackboard Learn requiert des redirections et des transferts pour vérifier qu'il s'agit bien d'adresses locales. Cette vulnérabilité est testée régulièrement.

Catégories de vulnérabilités antérieures dans les dix principales vulnérabilités de l'OWASP

Exécution de fichiers malveillantsLes fichiers téléchargés par les utilisateurs finaux sans privilège ne sont jamais utilisés comme exécutables. Les utilisateurs bénéficiant de privilèges (par exemple, les administrateurs système) peuvent toutefois télécharger des paquets exécutables, appelés Building Blocks, qui étendent les fonctionnalités du système. Il est supposé que les administrateurs système comprennent les risques et suivent des pratiques saines d'examen des fournisseurs et de gestion du changement en ce qui a trait à l'installation des Building Blocks tiers.

Toute déclaration concernant les attentes futures, les plans et les prospects de Blackboard reflète les opinions actuelles de la Société. Les résultats réels peuvent différer sensiblement en raison de divers facteurs importants. La Société s'attend à ce que des événements et des faits nouveaux ultérieurs l'amènent à modifier son point de vue. Toutefois, bien que la Société puisse, à terme, actualiser ces déclarations, elle décline expressément toute obligation de le faire.