企業とホワイトハッカーを結ぶ 日本初のバグ報奨金プラットフォーム BugBounty.jp

サイバーセキュリティエンジニアブログ

bugbounty.jp

バグバウンティについて

自社サービス/製品のセキュリティは本当に大丈夫?脆弱性がないかどうかを確認するための効果的な施策とは

May 15, 2017 08:00 by 山口 達也

「自社のサービス・製品に脆弱性があったらどうしよう」「セキュリティ観点で診断を実施したいけど、どういう施策があるの?」といった疑問をお持ちのIT担当者は意外と多いのではないでしょうか。
そんな方のために、本記事はセキュリティ対策にはどのようなものがあり※1、何を基準に選択すればよいのか解説します。

※1 本記事は具体的なソリューション・サービスは取り扱いません。世の中にある様々なサービスを大きな括りで分類し、それぞれの特徴やどのように選ぶべきかの考え方をお伝えします。

なぜセキュリティ検査を実施する必要があるのか

開発したサービス・製品を安全に提供するためには、リリース前に脆弱性を排除し、リリース後も定期的に改修していく必要があります。そのためには、脆弱性が存在するかどうかを検査しなければなりませんが、検査にはセキュリティに関する専門知識が必要です。そのため、開発者自身で検査を行うことや社内で専門部隊を用意して検査することは容易ではありません。

セキュリティ検査を実施していないサービス・製品は、ハッカーにより数分のうちに複数の脆弱性を発見される可能性があります。悪意のあるハッカー(クラッカーやブラックハット・ハッカーと呼ばれる)がそれらの脆弱性を見つけて悪用した場合、顧客の個人情報が漏洩してしまったり、ウェブサイトが改ざんされるなどの被害に遭う危険性があります。

個人情報の漏洩が発生すると、多額の金銭的損失だけでなく社会的な信用も失ってしまいます。サービス・製品の全てに脆弱性は存在すると考えるべきであり、自社は大丈夫とは思わない方がよいでしょう。

マイクロソフトが提案するセキュリティ開発ライフサイクル(Security Development Lifecycle : SDL)では脆弱性を最小限にするため、開発サイクルの各フェーズで取り組むセキュリティ対策を文書化していますが、SDLの中で「現在の開発技術では完全に脆弱性のないソフトウェアを出荷することはできません」と記載されています。
マイクロソフトでは出荷(リリース)後の対策として、ユーザー、ハッカー、研究者に脆弱性を発見してもらい、報告の対価として報奨金を支払うバグ報奨金プログラムを実施しています。

しかし、SDLやバグ報奨金プログラムを全て実施するためのリソースを準備できない企業も多いのではないでしょうか。企業のIT担当者は自社の状況に合わせて、現実的に実施可能なセキュリティ対策を考える必要があります。社内にセキュリティ診断を実施できるリソースがない場合には、外部のサービスを利用します。

セキュリティ検査手法の種類

サービス・製品の脆弱性を発見するためのセキュリティ検査手法として以下が挙げられます。

  • 診断会社による手動セキュリティ診断を依頼する※2
  • スキャンツールを利用する
  • バグ報奨金プログラムを実施する
  •  

    手動セキュリティ診断 スキャンツール バグ報奨金制度
    コスト 成果にかかわらず一定 成果にかかわらず一定
    (期間中何度も実施可能な定額サービスも多い)
    成果報酬制
    網羅性 高い 特定の脆弱性のみ※3 不透明
    属人性 担当の診断員に依存しがち 診断員に依存しない 世界中不特定多数のハッカーが実施
    継続性 コストの観点から低い 定額サービスの場合は継続しやすい 成果報酬のため継続しやすい
    監査性 監査証明として有効 ツールの性能次第 監査証明としては弱い

    ※2 セキュリティ診断サービスの中には診断会社側でスキャンツールを回すものもあります。その場合、本記事ではスキャンツールの分類とします。
    ※3 特定のアルゴリズムにより機械的に検出するため、XSS(クロスサイトスクリプティング)やSQLインジェクションなど検出できる脆弱性が決まっています。多くのツール開発元サイトでは、検出可能な脆弱性一覧が公開されています。

    手動セキュリティ診断ほど知られていないスキャンツール、バグ報奨金制度について補足説明します。

    スキャンツール
    「オープンソースによりコストを抑えることができるもの」「クラウドからの診断により検査対象環境へ事前にソフトウェアをインストールすることなく手軽に実施できるもの」「有償だが高機能なもの」などスキャンツールには様々なものがあります。
    また、ソースコードから解析を行う「静的分析」と、サービス・製品の動作から解析を行う「動的分析」があります。静的分析ではバッファ オーバーランなどのコーディングに起因する脆弱性を発見できます。動的分析では正常値、異常値を含む入力(リクエスト)に対する出力(レスポンス)から脆弱性の存在を調査します。

    バグ報奨金制度
    脆弱性報告窓口を設け、報告者に対価として報奨金を支払う制度です。
    費用は報告数とその内容により変動します。脆弱性が悪用された場合の影響度合いや攻撃容易性を検討して企業が支払う報奨金額を決定します。第3者からの脆弱性受付フォームを準備している企業は多くありません。情報を受け取る仕組みがないと、企業が知らない場所で流通、悪用されてしまうかもしれません。

    中国のポータルサイトに日本のウェブサイトの脆弱性が、約400件登録されていたという事例もあります。

    【注意喚起】SQLインジェクションをはじめとしたウェブサイトの脆弱性の再点検と速やかな改修を
    https://www.ipa.go.jp/security/announce/website_vuln.html

    上記で登場しているWooYunというポータルサイトは、「発見者同士の技術力向上などを目的とした、発見者同士のコミュニティ」「脆弱性情報を収集し、ウェブサイト運営者や製品開発者へ情報を提供するための脆弱性情報ポータルサイト」という側面を持つ※4と説明されています。

    ウェブサイト運営者や製品開発者へ情報を提供したいユーザーに対し、企業が脆弱性報告窓口を用意し、報告者に対価を払うのであれば、企業への報告は増えるでしょう。

    ※4 ただし、不正アクセス禁止法に抵触する方法で脆弱性を確認することは許されません。(参考:ホワイトハッカー入門 (2) ホワイトハッカーとして守るべきルールとは

    何を選択すべきか

    スキャンツールや診断会社ごとに強みにしている部分や検査内容が異なるため、「各診断手法はこの場合に適している」と断言できません。
    そこで視点を変えて、開発サイクルの各期間※5で適切な検査手法をまとめました。

    特徴 適切な検査手法
    開発期間 ソースコードを頻繁に更新 テストを自動化して、検査を定期的に短い周期で実施
    テスト期間
    (リリース前)
    バグ対応時のみソースコードを修正 全ての機能に対して厳密な検査
    運用期間
    (リリース後)
    悪意のあるユーザーから攻撃を受ける可能性あり 定期的な検査、バグ報告受取窓口を開設

    ※5 要件・設計期間においても、セキュリティ対策に取り組むことは大事です。本記事は「脆弱性がないかどうかを確認するための効果的な施策」に焦点を当てているため、開発期間以降のみを取り扱います。

    開発期間
    開発期間の検査において考慮するポイントは2つあります。

  • 任意のタイミングで何度でも検査が実施できる
  • 次のように、コードの追加・変更のたびに検査して、脆弱性が新しく作られていないかを確認します。

    コード追加→検査→修正→検査→コード変更→検査

  • 開発者は開発(コーディング)に集中できる環境を作る
  • 新しい機能を開発するためのスキルと、セキュリティ検査のスキルは別物です。開発者に開発とセキュリティ対策を全て任せるのではなく※6、別々に対策を準備しましょう。

    ※6 セキュリティを意識しつつ開発はするものの、脆弱性がある程度作り込まれることは前提にします。

    この2点を考慮して、定額プランかつサービス期間中は何度でも実施できる検査サービスを利用し、開発者が毎回セキュリティチェックを自身で行わなくて済むように事前に登録した環境情報を基に検査を自動化できるようにしましょう。スキャンツールの中には、このポイントを意識して開発者に寄り添ったサービスがあります。一方、手動セキュリティ診断やバグ報奨金制度は開発期間中には向きません。

    テスト期間(リリース前)
    リリース前の検査では次のポイントを考慮しましょう。

  • 網羅的に検査を実施する
  • 1カ所脆弱性があることで、全ての機能を悪用されるケースもあります※7。そのため、網羅的な検査が必要です。リリースした後で脆弱性を発見した場合は「既に脆弱性が悪用されていないか?」といった追加調査が発生し、コストは膨れ上がる可能性が出てきます。そうならないため、リリース前に可能な限り脆弱性を把握する必要があります。

    ※7 例えば、ウェブサイトでセッションIDを盗み出せるページがあると、利用者がログインした後、悪意のある第三者によりセッションIDを不正に取得され、利用者になりすましてアクセスされる可能性があります。

    網羅性の観点では、診断会社による手動セキュリティ診断を実施した方がよいでしょう。もし、顧客の個人情報を取り扱わないサービスでコストを安く抑えたい場合は、スキャンツールを活用する、もしくは一部の重要な機能のみを診断会社に依頼するという選択肢もあります。
一方、クレジットカード情報など重要な情報を取り扱うため、手動セキュリティ診断を1社のみで実施するだけでは不安な場合は、多人数の視点での調査が可能なバグ報奨金制度と組み合わせることも有効な施策です。

    運用期間(リリース後)
    リリース後の検査において次の2つを考えます。

  • 継続的に検査を実施する
  • 「リリース後も脆弱性は存在しているものとして考える必要がある」「改修時に新しくバグが入り込む」「新しく発見された攻撃手法により狙われる可能性がある」を考慮して1年に1度といった定期的な検査を行う必要があります。

  • 利用ユーザーからの報告窓口を用意する
  • 問題を見つけたユーザーが報告をしやすいシステムや、報告を受け付けた時の体制を整えておきましょう。

    大きな改修時にはスキャンツールや手動診断を実施し、その他の期間はバグ報奨金制度を行うと費用対効果は大きくなります。

    スキャンツールや診断で脆弱性を短期的に発見し、バグ報奨金制度により多数の目から残った脆弱性を長期的に発見していくことで、それぞれの検査手法のメリットを活かせます。

    最後に

    今回は脆弱性を発見するためのセキュリティ検査手法の種類を比較し、それらを選ぶ上での考え方をご紹介しました。

    セキュリティ検査サービスは診断会社による手動セキュリティ診断、スキャンツール、バグ報奨金制度の3つを挙げました。どれか一つがいいというわけではなく、各サービスの特徴(コスト・網羅制・属人性・継続性など)を理解して、状況(本記事では開発期間、リリース前、リリース後という区分で説明)からどのサービスが最も適しているのかを判断して選択する必要があります。さらに、各サービスの強みをうまく組み合わせることができれば、効果を最大限に発揮できると思います。

    本記事が少しでも皆様のセキュリティ対策実施の参考になれば幸いです。

    この記事をシェアしませんか?

    • 0

    この記事のライター

    山口 達也

    山口 達也

    趣味はドローンです。

    同じカテゴリーの記事