Blackboard 提供一项强有力的安全性计划,其不仅能防止出现安全问题,还能对问题加以解决。Blackboard 在代码级别(静态分析)和应用程序级别(动态分析)执行持续内部安全性测试,以确保其符合 Blackboard 和客户的期望。此外,为了定期了解应用程序的最新情况,Blackboard 会从第三方安全供应商处获得安全性渗透测试。发现的任何问题都会得到快速修复。

Blackboard 的安全性计划实践在不断发展,且日趋成熟,认识到这一点非常重要。我们会持续不断地做出改进,从而提升 Blackboard 产品的安全特性和稳定性。


设计中考虑了安全性

Blackboard 致力于向我们的客户提供安全的应用程序。Blackboard 根据许多组织(如开放 Web 应用程序安全性项目 (OWASP))生成的一组安全性工程准则(包括针对 OWASP 前十大漏洞的特定对策)来开发我们的产品。Blackboard 将这些安全性实践溶入软件开发生命周期 (SDLC) 的每一阶段中。

Blackboard 利用多种方法来保护我们的应用程序,包括通过威胁建模和分析进行的“自顶向下”安全评估,以及通过静态分析、动态分析和手动渗透测试进行的“自底向上”代码级别威胁检测。

Blackboard 遵循许多组织的最佳实践指导,帮助增强产品和方案的安全性。我们在下方列出了其中一些组织:

  • 美国国家标准技术局 (NIST)
  • 欧洲网络与信息安全局 (ENISA)
  • SANS Institute
  • 开放 Web 应用程序安全性项目 (OWASP)
  • 云安全联盟 (CSA)

威胁建模

在开发新功能时,安全性团队通过执行威胁建模来评估需求和系统设计,从而帮助降低风险。威胁建模是一个结构化过程,在这个过程中会发现与正在审核的功能相关的安全性威胁,以便识别和应用相应的安全对策。


安全编码和 OWASP 前 10 大漏洞

Blackboard 产品是根据 OWASP 生成的一组开发准则(包括针对 2013 年 OWASP 前十大漏洞的特定对策)开发出来的。

A1:注入(SQL/DOM/LDAP 注入)我们的编码标准是,使用绑定变量并避免转录为 SQL 语句的文本。LDAP 功能仅限于验证。
A2:中断的验证和会话管理Blackboard 产品仅通过 TLS 运行,因此,所有 Cookie 都经过加密。
A3:跨站点脚本 (XSS)通过使用共享库(如 ESAPI 和开发标准)降低跨站点脚本攻击风险。所有最终用户提交的文本输入都通过杀毒软件进行传递;任何其他类型的输入(日期、选择/选项值)都通过键入的域对象生成,而不是直接通过用户输入进行转录。
A4:不安全的直接对象引用所有应用程序对象都通过经常映射到主键的“ID”进行引用。但是,所有对象都映射“上下文”且所有安全检查都针对“上下文”执行。例如,请求可能会引用是课程讨论区帖子的“消息 ID”。Blackboard 标准是,对附加到用户角色的权限执行授权检查。
如果该标准未能正确执行,则补救措施非常简单,因为系统中所有受保护的数据实体均会映射到安全上下文(课程或域)。
A5:错误的安全配置需要系统管理员引起特别考虑时,Blackboard 会采用版本说明和文档来遵循安全默认的策略。如果 Blackboard 提供可用的安全配置最佳实践指南且其与您的特定 Blackboard 产品相关,则 Blackboard 建议客户遵循该最佳实践指南。

安全审核
安全事件会记录到特定于安全的日志中。

信息泄露和错误处理
标准错误处理适用于所有页面(通过标准页面模板和标记库),从而导致所有错误的标准输出,特别是未被识别的错误。标准输出可能包括堆栈跟踪(少量信息泄漏),但是此类数据在请求失败时不会得到处理,只有具有管理员级别访问权限的人员才能看到此类数据。未授权用户(如学生)无法看到详细的堆栈跟踪。

A6:敏感数据暴露Blackboard 的标准是通过 SHA-160 对用户密码进行哈希处理与加盐加密处理。

Blackboard 产品支持通过 TLS 运行;但是,部署人员应负责在自托管其产品时正确配置 TLS。

A7:缺失功能级别访问控制这在两个级别进行管理,以要求业务逻辑执行授权检查,并确保 QA 测试用例涵盖不同屏幕的授权需求。
A8:跨站点请求伪造 (CSRF)我们的安全框架遵循 OWASP 对每个请求 nonce 值和仅 POST 语义的建议。AJAX 请求使用每个会话的 nonce 值。
A9:使用含有已知漏洞的组件通过对我们的基础结构和第三方软件包执行常规漏洞扫描,发现含有已知漏洞的组件并制定路线图来升级含可用补丁的此类软件包,从而降低该漏洞风险。
A10:未经验证的重定向和转发Blackboard 安全编码标准要求重定向和转发验证其是否为本地地址。我们定期测试该漏洞。

以前的 OWASP 前十大漏洞类别

恶意文件执行从不将非特权最终用户上传的文件用作可执行文件。但是,特权用户(如系统管理员)可以上传用于扩展系统功能的可执行文件包(名称为 Building Block)。我们假定,系统管理员了解风险,并遵循有关任何第三方 Building Block 安装的可靠供应商审核和更改管理实践。

关于未来预期的任何声明、Blackboard 的计划和前景均代表公司当前的观点。由于各种重要因素的影响,实际结果可能会有很大的不同。公司预计,随后的事件和发展将使公司的观点发生变化。然而,尽管公司可能会在未来的某个时候选择更新这些声明,但公司明确表示没有任何义务这样做。


漏洞管理承诺和披露策略

Blackboard 的漏洞管理计划受以下面向公众的漏洞管理承诺和披露策略的管制。任何软件供应商都不是完美无缺的,在发布的产品中发现安全漏洞时,Blackboard 的安全性团队随时准备好予以应对。

为了帮助登录,您需要联系您机构的 IT 帮助台。Blackboard 无权访问您机构的帐户信息、网站或内容。如果您不知道如何联系帮助台,请尝试在 Web 上搜索您机构的名称 + 帮助台,或查看您的登录页面以获取支持链接或联系信息。

Blackboard 致力于快速而认真地解决安全漏洞。此类解决方案可能会导致向客户发布安全公告和/或任何所需的产品更新。为了保护我们的客户及其数据,我们要求负责且保密地向我们报告漏洞,以便我们进行调查和应对。在我们开发并全面测试产品更新并将其设为对许可客户可用之前,不应发布漏洞。

Blackboard 的产品非常复杂。它们在不同的硬件和软件配置中运行,并连接到许多第三方应用程序。所有软件修改(大或小)都需要经过彻底分析,以及跨多个产品系列和版本进行开发和实施。该软件还必须经过本地化,支持无障碍访问,并对其范围、复杂性和严重性进行适当的测试。考虑到我们的产品对客户的重要性,Blackboard 必须确保他们不仅能在测试机构中正确运行,还能在客户环境中正确运行。因此,Blackboard 无法根据设定的时间线提供产品更新,但我们致力于快速地进行工作。

恶意方通常通过对发布的安全公告和产品更新进行逆向工程来利用软件漏洞进行攻击。客户必须立即更新软件,并使用我们的严重性等级系统作为指导来更好地安排升级。因此,仅在客户有机会获得产品更新之后,才适合公开讨论漏洞。

测试安全漏洞

您应该针对我们产品的非生产实例进行所有漏洞测试,以最大限度降低数据和服务风险。


如何报告漏洞

通过填写漏洞提交表单保密地分享潜在漏洞的详细信息。

提供潜在漏洞的详细信息,以便 Blackboard 安全性团队可以快速验证和重现该问题。如果没有上述信息,则可能很难甚至无法解决潜在漏洞。列出许多潜在漏洞而没有详细信息的报告在没有进一步的阐释之前将不会得到解决。详细信息应包括:

  • 漏洞类型;
  • 该信息是否已发布或与其他合作伙伴共享;
  • 受影响的产品和版本;
  • 受影响的配置;以及
  • 重现该问题的分步说明或概念验证代码。

Blackboard 安全承诺

对于遵循此策略的所有漏洞报告者,Blackboard 将尝试执行以下操作:

  • 确认已收到您的报告;
  • 及时调查,确认可能出现潜在漏洞的位置;
  • 根据需要,提供解决该漏洞的计划和时间安排;以及
  • 在解决该漏洞时,通知漏洞报告者。

确认贡献

Blackboard 没有漏洞奖金方案。因此,Blackboard 将不会为报告安全漏洞的人员提供奖赏或补偿。