情報セキュリティ評価と基準

要点と定義

セキュリティ評価では、何を確かめたいかに合わせて評価方法を選びます。ペネトレーションテストは、対象の脆弱性を調べ、実際に侵入できるかを試して攻撃への耐性や影響を確認します。設計書やソースコードの確認、ファイルの完全性監視、通信の異常検知とは目的が異なります。

プログラムの内部構造や仕様を見て、脆弱性がありそうな処理への入力を変えながら検査する方法は、ホワイトボックステストです。ツールを使うかどうかではなく、内部情報を検査に使うかが判断の手掛かりです。

開発時の管理策は、開発環境の保護、委託先の監督・監視、パッケージソフトウェアの変更抑制、セキュリティ機能の試験などを扱います。出題の根拠であるJIS Q 27001:2014附属書Aでは、セキュリティ機能の試験は開発期間中に実施する管理策として示されていました。これは出題時点の規格に基づく説明です。

PCI DSSは、カード会員データを保護するための技術面・運用面の要件を含む基準です。カード情報を自社で扱う業務では、この基準への対応が判断に必要となる場合があります。 決済方法によって自社がカード情報を扱うかどうかが変わるため、事例では情報の保存・処理・伝送の担い手を確認します。

平成28年改正版の情報セキュリティ管理基準は、マネジメント基準と管理策基準から成ります。出題時点の説明では、前者はJIS Q 27001:2014を基にし、後者は同規格の附属書AとJIS Q 27002:2014に沿っています。マネジメント基準の事項は原則として全て実施し、管理策基準の管理策はリスク対応で選ぶ候補です。必要なら基準に挙げられていない管理目的や管理策を加えられます。

CVSS v3の現状評価基準は、攻撃コードの出現や利用可能な対策の状況を反映します。そのため、同じ脆弱性でも時間の経過に伴って評価結果が変化し得ます。

適用条件と例

たとえば、公開中の予約サイトに対し、許可された検査範囲で侵入可能性と影響を確かめるなら、ペネトレーションテストが目的に合います。一方、ソースコードの分岐を調べて入力値を変え、異常処理を探すならホワイトボックステストです。前者はシステムやネットワークへの侵入可能性、後者は内部構造を手掛かりにしたプログラム検査が焦点です。

監査で開発プロセスを確認するときは、試験をいつ行うか、開発環境を保護しているか、委託先を監督しているかなど、管理策ごとの条件に照らします。出題時点の規格に沿えば、セキュリティ機能の試験を開発完了後にだけ行う状態は指摘対象でした。

決済業務の例では、注文処理を自社システムで行っていても、カード情報を外部の決済サービスに直接入力し、自社が保持しない方式と、自社でカード情報を処理する方式では確認点が異なります。誰がカード情報を保存・処理・伝送するかを把握してから、PCI DSSとの関係を判断します。

CVSSの現状評価を時点Aと時点Bで比較する例を考えます。時点Aでは攻撃コードが確認されず有効な対策も限られていたが、時点Bでは攻撃コードが公開され対策が利用可能になったとします。現状評価はこうした変化を反映し得るので、評価を参照した時点も合わせて確認します。