WEB & SYSTEMS

脆弱性診断の後、直すところまで

脆弱性診断は、見つかった問題を直して初めて役に立ちます。直す順番の決め方、他社が作ったシステムを直すときの保守契約の確かめ方と話し合い、パッチの運用、再診断、規程と教育への落とし込みまでを順に説明します。

この記事の要点

  • 見つかった問題は、危険度と自社での影響の大きさから順番を決め、すぐに直せないものは期限と、それまでの守りを記録します。
  • 他社が作ったシステムは、保守契約の範囲を確かめたうえで作った会社と話し合い、直す担当と費用と期限を決めます。
  • 直した後は再診断で確かめ、同じ問題をくり返さないよう、開発と運用の決まりと教育に落とし込みます。

脆弱性診断の報告書を受け取った後は、直す順番を決め、誰が直すかを決め、直したことを確かめ、同じ問題をくり返さない仕組みにするところまでが一続きの仕事です。報告書を受け取って終わりにすると、診断にかけた時間と費用が守りにつながりません。

診断の頼み方と報告書の読み方は脆弱性診断の頼み方と、報告書の読み方で扱っています。この記事は、その続きです。

直す順番を決める

直す順番は、報告書の危険度と、自社のシステムでの影響の大きさをあわせて決めます。インターネットから直接届く箇所、個人の情報やお金に関わる処理、管理の画面に関わる問題を先にするのが一般的な考え方です。

すぐに直せない問題もあります。作りを大きく変える必要がある、提供元の更新を待つ必要がある、といった場合です。そのときは、直す期限と、それまでの間の守り(対象の機能を止める、届く範囲を絞る、WAFで手前の通信を止める、記録を細かく見る など)を決めて記録します。直さないと判断する場合も、その理由と、判断した人を残します。

誰が直すかを決める

直す担当は、システムを誰が作り、誰が保守しているかで変わります。社内で作ったシステムは社内の開発の担当、他社が作ったシステムは、まず作った会社や保守を受けている会社と話し合うのが基本です。

直す担当は、誰が作り、誰が保守しているかで変わる

  • 社内で作ったシステム社内の開発の担当が直す
  • 他社が作ったシステムまず、作った会社や保守を受けている会社と話し合う

他社が作ったシステムを直す場合

他社が作ったシステムでは、最初に保守契約の内容を確かめます。脆弱性への対応が保守の範囲に含まれているか、費用がかかる場合はどう決めるか、対応の期限の定めがあるか、を見ます。契約に書かれていない場合も多いため、報告書の該当の部分を共有し、直す内容、担当、費用、期限を話し合って書面に残します。

話し合いでは、問題を責める場にしないことが、早く直すための近道になります。作った時点では知られていなかった種類の問題や、その後の部品の更新で生じた問題もあるためです。報告書の再現の手順を共有すると、相手が問題を確かめやすくなります。

保守契約が切れている、作った会社と連絡がつかない、といった場合は、新たに保守を頼むか、別の会社に直す作業を頼むかを考えます。別の会社に頼む場合は、ソースコードや設定の情報を渡せるか、権利の扱いに問題がないかを先に確かめます。契約の解釈に迷う場合は、弁護士などの専門家にご確認ください。

委託先の管理の全体の考え方は委託先・クラウドサービスの管理をどう確かめるかで取り上げています。

パッチの運用を決める

診断で見つかる問題には、部品やOSの更新が当たっていないことによるものもあります。一つずつ直すだけでなく、更新の運用そのものを決めておきます。

  • 使っているOS、ミドルウェア、ライブラリ、クラウドのサービスの一覧と、その版
  • 更新の情報を誰が、どこで確かめるか
  • 当てる前にどの環境で確かめるか、急ぐ場合はどう判断するか
  • 提供の終わる時期と、その前の切り替えの計画

セキュリティパッチを当てる順番は、インターネットから届くもの、悪用が確認されているもの、重要な情報を扱うものを先にするのが基本です。

再診断で確かめる

直したら、直した箇所を再診断で確かめます。直したつもりでも、別の入り口から同じ問題が残っていたり、直したことで別の問題が生じたりすることがあるためです。

再診断は、直す作業をしていない担当が行うと、思い込みによる見落としを減らせます。作る人と確かめる人を分けるのは、診断に限らず、品質を保つための基本の考え方です。

自社が作ったシステムを、自社で診断する場合

自社が作ったシステムや、自社が運用しているシステムを、自社で診断することもあります。早く問題に気づくうえで役に立ちますが、作った側の見方から離れにくい面があります。そのため、こうした診断は第三者による診断ではなく、自己点検として扱うのが一つの考え方です。

取引先や投資家、M&Aの相手など、社外に結果を示す場面では、作ることにも運用することにも関わっていない会社による診断を検討します。第三者の立場で確かめるときの考え方はシステム監査の独立性。開発会社に監査を頼むときに考えることをご覧ください。

規程と教育に落とし込む

同じ種類の問題が何度も見つかる場合は、作り方や運用の決まりに原因があると考えられます。見つかった問題を種類ごとにまとめ、次のように決まりと教育に落とし込みます。

  1. 開発の決まり:よく見つかる種類の問題について、作るときの書き方と、確かめ方を決める
  2. 発注の決まり:委託先に頼むときの要件に、診断を受けることと、見つかった問題への対応を書く
  3. 運用の決まり:更新の確かめ方、アカウントの見直し、記録の確認の担当と頻度を決める
  4. 教育:開発の担当と運用の担当に、見つかった問題の種類と直し方を共有する

診断の指摘を改善につなげる進め方は、監査の指摘と同じ考え方で整理できます。詳しくは監査の指摘を改善につなげる。重要度・改善計画・フォローアップをご覧ください。

当社のご支援

アメリア・テクノロジーのセキュリティ診断と対策では、診断で見つかった問題を直す作業を、他社が作ったシステムも含めてお受けしています。直す作業と再診断は別の担当が受け持ち、規程づくりや社員の教育までご支援します。自社の状況をおおまかに確かめたい場合は、無料のセキュリティの自己診断をお使いください。

  • 脆弱性診断
  • セキュリティ
  • 保守契約
  • パッチ管理

この記事に出てくる用語

この記事を書いた人

石田 誠 グループCTO

インターネットの黎明期から、ホスティング事業の立ち上げや、インフラ・セキュリティのプロジェクトに携わってきました。現在は、AWS・Azure へのクラウド移行の支援と、業務アプリケーションの要件定義から実装までを担っています。

このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。

あわせて読みたい

Webとシステム開発のコラムを見る コラムの一覧に戻る

無料で相談する無料の診断