A Blackboard tem um programa de segurança robusto que atua para prevenir o surgimento de problemas de segurança, bem como para eliminá-los. A Blackboard executa testes contínuos de segurança interna no nível de código (análise estática) e no nível de aplicativo (análise dinâmica) para garantir que atenda às expectativas da Blackboard e de nossos clientes.

Além disso, para monitorar com frequência o aplicativo, a Blackboard obtém testes de penetração de segurança de fornecedores de segurança. Quaisquer problemas identificados são rapidamente designados para serem reparados.

É importante perceber que o programa de segurança da Blackboard é uma prática crescente e consolidada. Operamos com uma melhoria contínua para elevarmos o nível no que diz respeito aos recursos de segurança e robustez no Blackboard Learn.


Desenvolvido com foco em segurança

A Blackboard tem o compromisso de fornecer aplicativos seguros aos nossos clientes. Desenvolvemos o Blackboard Learn de acordo com um conjunto de diretrizes de engenharia de segurança derivadas de muitas organizações, como o Projeto Aberto para Segurança em Aplicações Web (OWASP, Open Web Application Security Project), que inclui contramedidas específicas para as dez principais vulnerabilidades do OWASP. A Blackboard incorpora essas práticas de segurança em todas as etapas do ciclo de vida do desenvolvimento de software (SDLC, na sigla em inglês).

A Blackboard utiliza vários métodos para proteger nossos aplicativos, incluindo avaliações de segurança" de cima para baixo" por meio de análises e Modelagem de ameaças, além de detecção de ameaças "de baixo para cima" no nível do código, por meio de análise estática, análise dinâmica e testes manuais de penetração.

A Blackboard segue práticas recomendadas de muitas organizações para ajudar a fortalecer a segurança do produto e do programa Blackboard Learn. Vale destacar algumas organizações:

  • Instituto Nacional de Padrões e Tecnologia (NIST, National Institute of Standards and Technology)
  • Agência Europeia para a Segurança das Redes e da Informação (ENISA, European Network and Information Security Agency)
  • SANS Institute
  • OWASP (Open Web Application Security Project)
  • Aliança para Segurança na Nuvem (CSA, Cloud Security Alliance)

Modelagem de ameaças

À medida que novos recursos são desenvolvidos, a Equipe de segurança avalia os requisitos e o design do sistema para ajudar a mitigar os riscos ao realizar Modelagem de ameaças. A Modelagem de ameaças é um processo estruturado em que as ameaças de segurança pertinentes ao recurso em análise são identificadas para que as contramedidas de segurança adequadas possam ser identificadas e aplicadas.


Codificação segura e as dez principais vulnerabilidades do OWASP

Os produtos da Blackboard são desenvolvidos de acordo com um conjunto de diretrizes de engenharia de segurança derivadas do OWASP, incluindo contramedidas específicas para as dez principais vulnerabilidades do OWASP para 2013.

A1: Injeção (Injeção de SQL/DOM/LDAP)Nosso padrão de codificação é usar variáveis de ligação e evitar expressões literais transcritas em instruções SQL. Xpath não é usado em nenhum lugar no aplicativo; a funcionalidade LDAP é restrita à autenticação.
A2: Autenticação quebrada e gerenciamento de sessãoTomamos diversas medidas para evitar o comprometimento dos cookies da sessão. O Learn só é executado via TLS desde abril de 2014, portanto todos os cookies têm o conjunto de sinalizadores seguros. Além disso, tentamos detectar mudanças inesperadas no estado do cliente (como uma sessão proveniente de endereços IP inesperados). Os cookies relacionados ao Gerenciamento de sessão são definidos como HttpOnly (observação: JSESSIONID não é usado para o gerenciamento de sessão e, portanto, não se espera que tenha o sinalizador HttpOnly).
A3: Cross-site Scripting (XSS)Os scripts entre sites, ou cross-site scripting, são reduzidos por meio do uso de bibliotecas compartilhadas, como ESAPI e padrões de desenvolvimento. Toda a entrada de texto enviada pelo usuário deverá passar por métodos de limpeza. Espera-se que quaisquer outros tipos de entrada (datas, valores de seleção/opção) sejam gerados a partir de objetos de domínio digitados, em vez de transcritos diretamente da entrada do usuário.
A4: Referências diretas de objetos insegurosTodos os objetos do aplicativo são referenciados através de "ids" que normalmente são mapeados para a chave primária. No entanto, todos os objetos fazem o mapeamento e todas as verificações de segurança são executadas com base em um "contexto". Por exemplo, uma solicitação pode fazer referência a um "id de mensagem" que é uma postagem do fórum de discussão para um curso. O padrão da Blackboard é executar a verificação de autorização para o privilégio associado à função de um usuário no curso. Nos casos em que esse padrão não é aplicado incorretamente, a correção é simples, pois todas as entidades de dados protegidas no sistema mapeiam para um contexto de segurança (curso ou domínio).
A5: Configuração incorreta de segurançaO Blackboard Learn segue uma política segura por padrão com notas de versão e documentação utilizadas quando se exige a consideração especial do Administrador do sistema. A Blackboard incentiva os clientes a seguir o guia de melhores práticas de Configuração segura.

Infraestrutura

Os clientes são incentivados a usar o Apache™ 2.x com recomendações documentadas, permitindo apenas códigos de alta resistência para proteção de camada de transporte. A Blackboard revisa regularmente os relatórios de segurança relacionados à infraestrutura que o Blackboard Learn oferece para garantir que eles estejam protegidos contra problemas de segurança.

Auditoria de segurança

Os eventos de segurança são registrados em um dos três registrosespecíficos de segurança. O framework de eventos de segurança (Security Event Framework) fornece um conjunto de códigos de eventos padrão, formato de log padrão, detalhamento de campo e responsabilidade. O conjunto de eventos registrados em cada código de evento está sempre em expansão.

Credenciais

Na instalação, os Administradores do sistema precisam definir senhas.

Vazamento de informações e tratamento de erros

O tratamento de erros padrão é aplicado a todas as páginas (por meio de um modelo de página padrão e uma biblioteca de tags), resultando em uma saída padrão para todos os erros, especialmente erros não reconhecidos. A saída padrão inclui um rastreamento de pilha (vazamento de informações mínimo), mas não inclui nenhum dos dados que estavam sendo processados quando a solicitação falhou e só é visível para aqueles com acesso no nível de administrador. Usuários não privilegiados (como alunos) não conseguem ver rastreamentos de pilha detalhados.
A6: Exposição de dados confidenciaisAs senhas dos usuários são aplicadas em hash, não criptografadas. Iniciando no Blackboard Learn, versão 9.1 Service Pack 12, as senhas do usuário passam por hash e são salgadas por padrão com o SHA-512. O roteiro de segurança do produto Blackboard Learn tem planos para o tratamento de senhas do sistema usadas para o início do aplicativo, as quais são protegidas por padrão pelo controle de acesso ao sistema operacional e ao sistema de arquivos. O Blackboard Learn suporta a execução via SSL. No entanto, é responsabilidade do implementador configurar corretamente o SSL. O descarregamento de SSL também é suportado pelo Blackboard Learn, versão 9.1 Service Pack 8 e em versões superiores.
A7: Controle de acesso de nível de função ausenteIsso é gerenciado em dois níveis, exigindo que a lógica de negócios imponha verificações de autorização e assegurando que os casos de teste de QA cubram os requisitos de autorização para diferentes telas. Todas as telas/links são potencialmente renderizadas; não há URLs "ocultos" que exijam a entrada manual. Como resultado, espera-se que o aplicativo exiba o acesso aos URLs antes de tentar renderizá-los.
A8: Falsificação de solicitação entre sites (CSRF, Cross-site Request Forgery)Nossa estrutura de segurança segue as recomendações da OWASP para os valores de nonce por solicitação e apenas semântica de publicação (POST). As solicitações AJAX usam valores de nonce por sessão. O DWR usa o envio de cookie duplo de um valor de nonce por sessão.
A9: Uso de componentes com vulnerabilidades conhecidasIsso é mitigado pela realização de verificações de vulnerabilidades regulares da nossa infraestrutura e dos pacotes de software de terceiros para identificar componentes com vulnerabilidades conhecidas e para desenvolver um roteiro para atualizar aqueles com patches disponíveis.
A10: Redirecionamentos e encaminhamentos não validadosO padrão de codificação seguro do Blackboard Learn requer redirecionamentos e encaminhamentos para verificar se são endereços locais. Essa vulnerabilidade é testada regularmente.

As dez principais categorias de vulnerabilidades anteriores da OWASP

Execução de arquivos mal-intencionadosOs arquivos carregados por usuários finais não privilegiados nunca são usados como executáveis. Usuários privilegiados (ou seja, Administradores do sistema) podem, no entanto, carregar pacotes executáveis chamados de Building Blocks que estendem a funcionalidade do sistema. Assume-se que os Administradores do sistema entendem os riscos e seguem as revisões adequadas do fornecedor de som e as práticas de gerenciamento de mudanças em torno da instalação de qualquer Building Block de terceiros.

Qualquer declaração sobre expectativas, planos e perspectivas futuros para a Blackboard representa os pontos de vista atuais da Empresa. Os resultados reais podem diferir materialmente como resultado de vários fatores importantes. A Empresa antecipa desde já que eventos e desenvolvimentos subsequentes farão com que os pontos de vista da Empresa mudem. No entanto, embora a Empresa possa optar por atualizar essas declarações em algum momento no futuro, a Empresa renuncia, especificamente, a qualquer obrigação de fazê-lo.