Blackboardは堅牢なセキュリティプログラムを備えており、セキュリティ上の問題発生を防止するだけでなく、そのような問題を根絶するべく動作します。コードレベル (静的解析) およびアプリケーションレベル (動的解析) での内部セキュリティテストを継続的に行い、Blackboardとお客様の両方の期待を確実に満たすようにしています。さらに、アプリケーションを常に新しい視点で見られるように、Blackboardではサードパーティのセキュリティベンダーによるセキュリティペネトレーションテストを受けています。問題が特定された場合は、ただちに修正が予定されます。

Blackboardのセキュリティプログラムは発展と充実の途上にあることを認識することが重要です。Blackboardでは、自社製品のセキュリティ機能と堅牢性を強化するよう、常に努めています。


セキュリティに留意した構築

Blackboardは、クライアントに安全なアプリケーションを提供するために努力を続けています。Blackboardは、OWASP (Open Web Application Security Project) を始めとする多くの組織のセキュリティエンジニアリングに関するガイドラインに基づき、製品を開発しています。この中には、OWASPの10大脆弱性への特定の対抗策も含まれます。Blackboardは、これらのセキュリティプラクティスを、ソフトウェア開発サイクル (SDLC) のすべてのフェーズに取り入れています。

Blackboardは、自社のアプリケーションを保護するために、静的分析、動的分析、手動侵入テストによりコードレベルで脅威を検出する「ボトムアップ」手法だけでなく、脅威をモデル化して分析する「トップダウン」のセキュリティアセスメントなど複数の手法を使用しています。

Blackboardは多くの組織のベストプラクティスガイダンスに従って、製品およびプログラムのセキュリティ強化に取り組んでいます。いくつかの組織をここに示します :

  • 米国国立標準技術研究所 (NIST)
  • 欧州ネットワーク情報セキュリティ庁 (ENISA)
  • SANS Institute
  • Open Web Application Security Project (OWASP)
  • クラウドセキュリティアライアンス (CSA)

脅威のモデル化

新規機能の開発に際し、セキュリティチームでは脅威のモデル化を行うことにより、要件とシステム設計を評価してリスクの軽減に役立てます。脅威のモデル化は構造化されたプロセスであり、ここではレビュー中の機能に関するセキュリティの脅威を特定することで、適切なセキュリティ対応策が特定され、適用されるようにします。


安全なコーディングとOWASPの10大脆弱性

Blackboard製品は、OWASPに由来する一連の開発ガイドラインに従って開発されます。具体的には、2013年のOWASPの10大脆弱性に対する固有の対応策が含まれます。

A1 :インジェクション (SQL/DOM/LDAPインジェクション)当社のコーディング規格では、バインド変数を使用し、SQL文に転記されるリテラルを避けることとしています。LDAP機能は認証に制限されています。
A2 :認証の不備とセッション管理Blackboard製品はTLS下でのみ動作するため、すべてのCookieは暗号化されます。
A3 :クロスサイトスクリプティング (XSS)ESAPIなどの共有ライブラリおよび開発標準を使用することにより、クロスサイトスクリプティングは軽減されます。エンドユーザが送信したテキスト入力はすべてsanitizerメソッドで渡されることが想定されています。その他の入力 (日付、選択/オプション値) はユーザ入力から直接転記されるのではなく、入力ドメインオブジェクトから生成されることが想定されます。
A4 :安全でないオブジェクトへの直接参照すべてのアプリケーションオブジェクトは、通常はプライマリキーにマップされる“ids”経由で参照されます。ただし、すべてのオブジェクトは「コンテキスト」にマップされ、すべてのセキュリティチェックは「コンテキスト」に対して実行されます。たとえば、あるリクエストで参照される「メッセージID」がコースの掲示板投稿である場合があります。Blackboardの規格では、ユーザロールに付加された権限に対して承認チェックを行うこととなっています。
この規格が正しく順守されていない場合でも、システム内の保護されたデータエンティティはすべてセキュリティコンテキスト (コースまたはドメイン) にマップされているため、改善は容易です。
A5 :不適切なセキュリティ設定Blackboardでは、システム管理者の特別な考慮が必要な場合に利用されるリリースノートおよびドキュメントに関し、Secure by Default (デフォルトで保護) ポリシーに従っています。Blackboardでは、セキュリティで保護された構成のベストプラクティスガイドが利用可能であり、特定のBlackboard製品に関連する場合、それに従うようお客様に勧めています。

セキュリティの監査
セキュリティイベントはセキュリティ固有のログに記録されます。

情報漏洩およびエラー処理
標準のエラー処理がすべてのページに適用され (標準ページテンプレートとタグライブラリによる)、すべてのエラー、特に未認識のエラーが標準出力に出力されます。標準出力にはスタックトレースが含まれる場合がありますが (軽微な情報漏洩)、リクエスト失敗時に処理中であったデータは全く出力されず、管理者レベルのアクセス権を持つユーザにのみ可視となります。権限のないユーザ (学生など) は詳細なスタックトレースを見ることができません。

A6 :機微な情報の露出Blackboard標準では、ユーザのパスワードにSHA-160によるハッシュおよびソルトを使用することになっています。

Blackboard製品はTLSでの実行がサポートされています。ただし、セルフホスト製品の場合、デプロイヤの責任でTLSを正しく構成する必要があります。

A7 :機能レベルのアクセス制御の不足これは業務ロジック実施で認証チェックを必要とすること、QAテストケースがさまざまな画面での認証要件を満たすようにすることの2つのレベルで管理されます。
A8 :クロスサイトリクエストフォージェリ (CSRF)当社のセキュリティフレームワークではOWASPの推奨に従い、リクエストごとのノンス値およびPOSTのみのセマンティックを導入しています。AJAXリクエストではセッションごとにノンス値を使用します。
A9 :既知の脆弱性のあるコンポーネントの使用この問題は、当社のインフラストラクチャとサードパーティのソフトウェアパッケージの両方で定期的に脆弱性のスキャンを実施して、既知の脆弱性を持つコンポーネントを特定し、利用可能なパッチによりコンポーネントをアップグレードするロードマップを開発することで軽減されます。
A10 :未検証のダイレクトと転送Blackboardセキュアコーディング規格では、リダイレクトおよび転送がローカルアドレスであることを検証するよう要求しています。この脆弱性は定期的にテストされています。

OWASPの10大脆弱性に以前含まれていたカテゴリ

悪意のあるファイルの実行特権のないエンドユーザがアップロードしたファイルは、実行可能ファイルとして使用されることはありません。ただし、特権ユーザ (つまりシステム管理者) は、システムの機能を拡張するBuilding Blockと呼ばれる実行可能パッケージをアップロードすることができます。システム管理者はリスクを理解し、サードパーティのBuilding Blockのインストールに関する健全なベンダーレビューと変更管理の慣行に従うことを前提とします。

Blackboardに対する将来的な期待、計画、展望に関する声明に、当社の最新の見解が示されています。実際の結果は、さまざまな重要要因により、大きく異なる可能性があります。今後のイベントや開発により、当社の見解が変化することが予想されます。ただし、当社ではこれらの声明を将来のいずれかの時点で更新することを決定する可能性があるものの、当社はそれを行う義務を明確に否認します。


脆弱性の管理方針および開示ポリシー

Blackboardの脆弱性管理プログラムは、公開されている以下の脆弱性の管理方針および開示ポリシーによって管理されています。完璧なソフトウェアベンダーは存在しません。リリースされた製品にセキュリティの脆弱性が見つかった場合、Blackboardのセキュリティチームはいつでも対応できるよう準備しています。

ログインを支援するために、教育機関のITヘルプデスクに連絡する必要があります。Blackboardは、教育機関のアカウント情報、Webサイト、コンテンツにアクセスすることができません。ヘルプデスクへの連絡方法が分からない場合は、Webで「所属教育機関名」+「ヘルプデスク」を検索してみるか、またはログインページにサポートリンクや連絡先情報がないか確認してみてください。

Blackboardでは、セキュリティの脆弱性を迅速かつ慎重に解決することに全力を注いでいます。このような解決策は、セキュリティアドバイザリ、またはお客様に対する必要な製品アップデートのリリースにつながる可能性があります。お客様とそのデータを保護するため、脆弱性に気づいたら、Blackboardが調査および対応を進められるよう、責任をもって内密に報告いただくようお願いします。当社が製品アップデートを開発して包括的にテストし、ライセンスをお持ちのお客様が利用できるようになるまで、脆弱性は公表されません。

Blackboardの製品は複雑です。多様なハードウェアとソフトウェアの構成で実行され、数多くのサードパーティ製アプリケーションに接続されます。すべてのソフトウェアの変更 (大小問わず) において、徹底的な分析と、複数の製品シリーズとバージョンにわたる開発および実装が必要です。また、ソフトウェアのローカライズやアクセシビリティと、その範囲、複雑性、重大度に応じたテストも必要です。お客様にとっての当社の製品の重要性を考えると、Blackboardでは、製品がテスト施設でだけでなく、お客様の環境でも正しく実行することを保証する必要があります。したがって、Blackboardでは規定のタイムラインに従って製品アップデートを提供することはできませんが、迅速に作業することをお約束します。

悪意のある者は、しばしば、公開されたセキュリティアドバイザリや製品アップデートをリバースエンジニアリングすることでソフトウェアの脆弱性を悪用します。お客様がソフトウェアを速やかにアップデートし、当社の重大度評価システムを指針として使用し、適切にアップグレードをスケジュールすることが重要です。したがって、脆弱性を公に議論することは、お客様が製品アップデートを取得する機会を得た後にのみ適切となります。

セキュリティの脆弱性テスト

データとサービスに対するリスクを最小限に抑えるため、すべての脆弱性テストは製品の本番環境以外のインスタンスに対して実施する必要があります。


脆弱性の報告方法

潜在的な脆弱性の詳細は、脆弱性提出フォームに記入することで、内密に共有します。

Blackboardセキュリティチームが問題をすばやく検証し、再現できるように、潜在的な脆弱性の詳細を提供してください。上記の情報がないと、潜在的な脆弱性に対処することは、不可能ではないまでも困難です。詳細を記述せず、大量の潜在的な脆弱性を羅列して報告しても、問題が明確化されるまで対処できません。詳細には、以下を含める必要があります。

  • 脆弱性のタイプ
  • 情報が公開された、または他の人に共有されたかどうか
  • 影響のある製品とバージョン
  • 影響のある構成
  • 問題を再現するためのステップごとの手順または概念実証コード

Blackboardのセキュリティに対する取り組み

このポリシーに従って脆弱性を報告するすべての人に対して、Blackboardでは以下を行います。

  • レポートを受領したことを通知する
  • 適時調査して、可能な限り潜在的な脆弱性を確認する
  • 適切な場合、脆弱性に対処するための計画とタイムフレームを知らせる
  • 脆弱性が解消されたとき、脆弱性の報告者に知らせる

貢献の認識

Blackboardには、脆弱性に関する報奨プログラムがありません。したがって、Blackboardはセキュリティの脆弱性の報告に対して表彰や報酬を提供していません。