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. Chez Blackboard, nous effectuons continuellement des tests de sécurité internes au niveau du code (analyse statique) et des applications (analyse dynamique) pour vérifier qu'ils répondent à nos attentes, ainsi qu'à celles de nos clients. De plus, pour garder constamment un regard neuf sur nos applications, nous récupérons des tests de pénétration de sécurité de la part de fournisseurs tiers. Nous corrigeons rapidement chaque problème identifié.

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 de nos produits.


Sécurité intégrée

Blackboard s'est engagé à fournir à ses clients des applications sécurisées. Nous développons nos produits Blackboard 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.

Nous utilisons plusieurs méthodes pour protéger nos 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.

Nous adoptons les pratiques d'excellence de nombreux organismes pour renforcer la sécurité de nos produits et programmes, 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 10 principales vulnérabilités de l'OWASP

Les produits Blackboard sont développés 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. La fonctionnalité LDAP est limitée à l'authentification.
A2 : authentification interrompue et gestion des sessionsLes produits Blackboard fonctionnent uniquement sous TLS, donc tous les cookies sont chiffrés.
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 final 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 objets et toutes les vérifications de sécurité sont effectués dans le cadre d'un « contexte ». Par exemple, une requête peut faire référence à un « ID de message » qui est un message affiché sur le forum de discussion pour un cours. Conformément à la norme Blackboard, nous contrôlons l'autorisation du privilège lié à la fonction de l'utilisateur.
Dans les cas où cette norme n'est pas appliquée correctement, 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 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. Nous encourageons nos clients à suivre notre guide des meilleures pratiques de configuration sécurisée lorsqu'il est disponible et pertinent pour leurs produits Blackboard.

Audit de sécurité
Les événements de sécurité sont enregistrés dans des journaux de sécurité spécifiques.

Fuites d'information et traitement 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 peut inclure 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 sensiblesLa norme de Blackboard est de hacher et de saler les mots de passe des utilisateurs en utilisant le format SHA-160.

Les produits Blackboard peuvent fonctionner au format TLS ; cependant, il incombe au développeur de configurer correctement TLS lorsque son produit est auto-hébergé.

A7 : contrôle d'accès au niveau de fonction manquantCeci est géré à 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.
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.
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 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.

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.