Blackboard tiene un programa de seguridad sólido que no solo actúa para evitar los problemas de seguridad, sino que también determina sus causas. Blackboard realiza pruebas continuas a la seguridad interna a nivel del código (análisis estático) y de la aplicación (análisis dinámico) para garantizar la satisfacción de las expectativas de Blackboard y de nuestros clientes.

Además, para tener otro punto de vista de la aplicación, Blackboard utiliza regularmente los servicios de pruebas de penetración de la seguridad de proveedores externos. Se toma nota de cualquier problema identificado para proceder a su reparación.

Es importante comprender que el programa de seguridad de Blackboard es una práctica en crecimiento y desarrollo. Trabajamos para mejorar continuamente a fin de elevar los estándares de las funciones de seguridad y solidez de Blackboard Learn.


Desarrollado pensando en la seguridad

Blackboard asume el compromiso de ofrecer a nuestros clientes aplicaciones seguras. Desarrollamos Blackboard Learn de acuerdo con una serie de pautas de ingeniería de la seguridad derivadas del Proyecto de seguridad de aplicaciones web abiertas (OWASP), entre las que se incluyen contramedidas específicas para las diez principales vulnerabilidades de OWASP. Blackboard incorpora estas prácticas de seguridad en todas las fases del ciclo de vida del desarrollo del software (SDLC).

Blackboard utiliza varios métodos para proteger nuestras aplicaciones, como las evaluaciones de seguridad de arriba a abajo mediante modelos de amenazas y análisis, así como la detección de amenazas a nivel de código de abajo a arriba a través de análisis estático, análisis dinámico y pruebas de penetración manual.

Blackboard sigue la guía de mejores prácticas de muchas organizaciones para ayudar a fortalecer la seguridad del producto y el programa de Blackboard Learn. Estas son algunas de las organizaciones:

  • National Institute of Standards and Technology (NIST)
  • European Network and Information Security Agency (ENISA)
  • SANS Institute
  • Open Web Application Security Project (OWASP)
  • Cloud Security Alliance (CSA)

Modelos de amenazas

A medida que se desarrollan funciones nuevas, el equipo de seguridad evalúa los requisitos y el diseño del sistema para mitigar los riesgos a través de un modelo de amenazas. El modelo de amenazas es un proceso estructurado en el que se identifican las amenazas a la seguridad correspondientes a la característica que se está revisando de modo de poder detectar y aplicar las contramedidas adecuadas.


Código seguro y las diez principales vulnerabilidades de OWASP

Blackboard desarrolla productos de acuerdo con una serie de pautas de desarrollo derivadas de OWASP, entre las que se incluyen contramedidas específicas para las diez principales vulnerabilidades de OWASP de 2013.

A1: inyección (inyección SQL/DOM/LDAP)Se utiliza nuestro estándar de códigos para enlazar las variables y evitar que se transcriban valores literales a las instrucciones SQL. Xpath no se utiliza en cualquier lugar de la aplicación; la funcionalidad de LDAP se limita a la autenticación.
A2: administración de la sesión y autenticación incorrectaAdoptamos varias medidas para evitar las cookies de sesión que ponen en riesgo la seguridad. Desde abril de 2014, Learn se ejecuta únicamente con el protocolo TLS, de modo que está activada la marca de seguridad para todas las cookies. Además, intentamos detectar los cambios inesperados en el estado de los clientes (como el inicio de sesión desde direcciones IP no previstas). Las cookies relacionadas con la administración de la sesión se establecen en HttpOnly (nota: JSESSIONID no se utiliza para la administración de la sesión y, por lo tanto, no se prevé que tenga la marca HttpOnly).
A3: Scripts de sitios (XSS)Los scripts de sitios se reducen con el uso de las bibliotecas compartidas, como ESAPI y los estándares de desarrollo. Se prevé que todas las entradas de texto de los usuarios se sometan a métodos de depuración; en cambio, se supone que cualquier otro tipo de entrada (fechas, valores de selección/opción) será generada por objetos de dominio escritos, en vez de utilizarse una transcripción directa de la entrada del usuario.
A4: referencias a objetos directos no segurosSe hace referencia a todos los objetos de la aplicación a través de "ids", que por lo general se asigna a la clave principal. Sin embargo, se asignan todos los objetos y se resuelven todas las verificaciones de seguridad en "contexto". Por ejemplo, una solicitud puede hacer referencia a una "id del mensaje" que se encuentra en una publicación en el tablero de debate del curso. El estándar de Blackboard es verificar la autorización del privilegio adjunto al rol de un usuario en el curso. En los casos en que el estándar no se exige correctamente, la corrección es sencilla, ya que todas las entidades de datos protegidos en el sistema se asignan a un contexto de seguridad (curso o dominio).
A5: configuración incorrecta de la seguridadBlackboard Learn respeta la política de seguridad de forma predeterminada, y las notas de la versión y la documentación se pueden aprovechar en los casos en los que es necesaria la consideración del administrador del sistema. Blackboard recomienda a los clientes que sigan la Guía de prácticas recomendadas para la configuración segura.

Infraestructura

Sugerimos a los clientes que utilicen Apache™ 2.x con las recomendaciones documentadas sobre cómo permitir únicamente cifrados de alta resistencia para la protección de la capa de transporte. Blackboard revisa con regularidad las advertencias de seguridad relacionadas con la infraestructura que Blackboard Learn envía para garantizar su protección de los problemas de seguridad.

Auditoría de seguridad

Los eventos de seguridad se guardan en uno de los tres registros de seguridad específicos. El marco de trabajo de los eventos de seguridad proporciona un conjunto de códigos de eventos estándar, formato de registros estándar, nivel de detalle de los campos y responsabilidad. El conjunto de eventos que se registra en cada código de evento se amplía constantemente.

Credenciales

Durante la instalación, los administradores del sistema deben establecer las contraseñas.

Filtración de la información y tratamiento de los errores

El tratamiento estándar de los errores se aplica a todas las páginas (mediante un plantilla de páginas estándar y una biblioteca de etiquetas), lo que produce un resultado estándar para todos los errores, en especial aquellos no reconocidos. El resultado estándar incluye un seguimiento de la pila (filtración de información menos importante), pero no abarca los datos que se estaban procesando cuando se produjo el error en la solicitud y solo pueden ver quienes tienen acceso a nivel del administrador. Los usuarios sin privilegios (como los alumnos) no pueden ver los seguimientos detallados de la pila.
A6: exposición de datos sensiblesLas contraseñas de los usuarios no están cifradas sino verificadas. A partir de la versión 9.1 Service Pack 12 de Blackboard Learn, las contraseñas de los usuarios se verifican y aleatorizan con SHA-512 de forma predeterminada. En la Guía de seguridad de productos de Blackboard Learn encontrará instrucciones para el manejo de las contraseñas del sistema que se utilizan en el inicio de la aplicación y que están protegidas por el control de acceso al sistema de archivos y al sistema operativo de forma predeterminada. Blackboard Learn puede ejecutarse mediante SSL; sin embargo, la configuración correcta de SSL es responsabilidad del implementador. La descarga de SSL también es compatible con la versión 9.1 Service Pack 8 y versiones posteriores de Blackboard Learn.
A7: falta de control de acceso al nivel de la funciónEste problema se trata en dos niveles: al requerir que la lógica de negocios exija los controles de la autorización y garantizar que los casos de pruebas de control de calidad abarquen los requisitos de autorización para las diversas pantallas. Se representan todas las pantallas y los enlaces posibles; no hay URL "ocultas" que requieran la entrada manual. Como consecuencia, se prevé que la aplicación muestre en pantalla el acceso a las URL antes de intentar proporcionarlas.
A8: falsificación de solicitud entre sitios (CSRF)Nuestro marco de trabajo de seguridad sigue las recomendaciones de OWASP para los valores de uso único por solicitud y las semántica exclusiva de POST. Las solicitudes AJAX utilizan los valores de uso único por sesión. DWR utiliza el envío de un valor de uso único por sesión con cookie doble.
A9: uso de los componentes con vulnerabilidades conocidasEsto puede reducirse mediante la realización de análisis de vulnerabilidades frecuentes de nuestra infraestructura y los paquetes de software de terceros para identificar los componentes con vulnerabilidades conocidas y desarrollar una guía para actualizarlos con las revisiones disponibles.
A10: redireccionamientos y reenvíos no validadosEl estándar de código seguro de Blackboard Learn exige la verificación de que los redireccionamientos y reenvíos se realicen a direcciones locales. Esta vulnerabilidad se prueba con frecuencia.

Categorías de vulnerabilidades anteriores a las diez principales vulnerabilidades de OWASP

Ejecución de archivos maliciososLos archivos que cargan los usuarios finales sin privilegios nunca se utilizan como archivos ejecutables. No obstante, los usuarios con privilegios (Como los administradores del sistema) pueden cargar paquetes ejecutables denominados Building Blocks que amplían la funcionalidad del sistema. Se presume que los administradores del sistema comprenden los riesgos y siguen las prácticas de administración de cambios y revisiones de proveedores de confianza con respecto a la instalación de cualquier Building Block de terceros.

Cualquier declaración sobre expectativas, planes y perspectivas para el futuro de Blackboard representan el punto de vista actual de la empresa. Los resultados reales pueden diferir de forma sustancial debido a varios factores importantes. La empresa prevé que los eventos y desarrollos posteriores hará que el punto de vista de la empresa cambie. No obstante, si bien la empresa puede optar por actualizar oportunamente estas declaraciones, no está específicamente obligada a hacerlo.