脆弱性管理とIT資産管理
-サイバー攻撃から組織を守る取り組み-

Share

日々報告される脆弱性に対してサイバー攻撃から自組織を守るために、「脆弱性管理」と「IT資産管理」を適切に実施することが重要です。本記事では、その脆弱性管理とIT資産の目的や必要性またどのように取り組んでいくのかについて解説します。

増え続ける脆弱性

脆弱性は、攻撃者によって利用され、システム侵害の足掛かりとされる可能性がありますので、これに対処することは組織のセキュリティ強化に不可欠です。

システムやソフトウェアに存在するセキュリティ上の弱点である脆弱性は、日々新しく発見・公表されており、その数は増える一方です(下グラフ参照)。脆弱性が報告される製品は、OS、ミドルウェア、アプリケーション、プログラム言語、ライブラリなど多岐にわたり、商用かオープンソースかを問いません。

また、新たな脆弱性ばかりでなく、VPN機器のような広く利用されている製品がアップデートされないまま放置されている、という実情に目をつけられて、古い脆弱性を悪用した攻撃活動による被害が報告される、といったことも少なくありません。

脆弱性管理とその目的

情報資産を守るためには、サイバー攻撃からシステムやソフトウェアを保護する必要があります。そのために重要となるのが脆弱性管理です。脆弱性管理とは、システムやソフトウェアに存在する脆弱性を継続的に把握し、適切な対策を講じることで、セキュリティ上のリスクを低減するための取り組みです。

脆弱性が放置されたままであれば、それを悪用したサイバー攻撃による情報漏洩や改竄、システム停止といった被害が発生し、企業・組織の信用失墜や業務中断による損失、取引先や顧客からの損害賠償請求、個人情報保護法等による罰則などの事態を招きかねません。脆弱性管理は、これらのリスクに適切に対処するための重要な手段となります。

脆弱性管理の必要性

しかしながら、脆弱性対策の予算・人員・時間などのリソースは有限であり、やみくもにすべての脆弱性に対処する、というのは現実的ではありません。無秩序に脆弱性対策をしていては、不必要なコストがかかるばかりでなく、十分な対策を講じられない恐れがあるでしょう。

脆弱性対策は、限られたリソースで的確かつ効率的に行わなければなりません。自組織に存在する脆弱性を的確に把握し、実態に即したリスクごとに優先度をつけて対応する必要があるのです。「脆弱性管理」は、こうした適切な脆弱性対策を実現するための一連のプロセスと言えます。

脆弱性管理のライフサイクル

脆弱性管理の標準的な流れは以下の4つのプロセスになります。

脆弱性管理のライフサイクル画像

各プロセスの概要とポイント

プロセス概要ポイント・留意点
資産の把握・管理IPアドレス、OS/ソフトウェアとバージョン、稼働中のサービスとその状況などを漏れなく記録。・機器・ソフトウェア単体だけでなく、製品に含まれるOSS、プラグインなど、相互の依存関係にも注意。
・常にアップデートできていること、管理外の資産(シャドーIT)がないこと。
脆弱性情報の収集資産管理情報をもとに、自組織に関係する脆弱性情報を収集。・必要に応じて適切なタイミングで実施。
・政府機関や製品ベンダといった信頼できるソースから収集。
脆弱性のリスク評価脆弱性の危険度を確認した上で、自組織への影響を分析し、対応の難易度やコストも勘案して、対応要否・優先度を決定。・まずはCVEなどの脆弱性に関する標準的な指標で各脆弱性の危険度を確認。
・自組織に即した評価としては、①攻撃を受けやすい状況か、②攻撃された場合はどの程度影響があるか、③脆弱性解消に要するリソースはどれくらいか、といった要素をなるべく定量的に分析・評価。
解消策の実行実行計画を策定し、検証環境に適用して問題がなければ、本番環境に適用。・必要な期間の確保、環境の整備、関係者との調整、事業状況の加味などにより、安全・確実に実行できるよう計画。
・適用にあたって発生したトラブルなども含め、作業内容は必ず記録。

脆弱性管理におけるIT資産管理

脆弱性管理プロセスは、資産の把握と管理から始まりますが、ここで、IT資産管理について考えてみましょう。IT資産管理の主な目的は、ライセンス管理やデータ保護によるコンプライアンスの遵守、資産を正確に把握・追跡することによるセキュリティ事故の防止、資産の効率的な使用を管理することによるコスト削減などとなります。

IT資産管理では、組織が所有するすべてのIT資産について、以下のような項目を可視化して管理する取り組みです。

・ハードウェア : PC、サーバ、ネットワーク機器 等
・ソフトウェア : OS、ミドルウェア、アプリケーション 等
・ライセンス情報、購入・保守情報、廃棄情報
・利用者(利用部門)、利用状況

IT資産の把握は、システム担当者より資産情報を取得するというのが一般的でしょう。また、システム構築を委託している場合は委託先に資産情報を確認する必要があります。

方法としては、IT資産管理ツールによって自動化するのがよいでしょう。アプリケーションやクラウドサービスなど、様々なIT資産管理ツールがリリースされていますので、予算や機能に応じて自組織に合うものを選択してください。

脆弱性管理とIT資産管理の連携

IT資産管理を整備・強化すると、先に挙げた脆弱性管理の管理プロセスにおいて、以下のようにIT資産管理を有効に連携させることができるでしょう。

脆弱性管理とIT資産管理の連携画像

両者を連携することで、セキュリティの確保がより確実に行えるようになることがわかります。

適切な脆弱性管理のためのポイント

前段まで脆弱性管理の目的や必要性、プロセス、そしてIT資産管理との連携について確認してきましたが、ここで、適切な脆弱性管理を実現するために必要なポイントについてまとめます。

漏れなく適時に一元管理実態に即した評価と対応プロセスの標準化と見直し
脆弱性管理を統括する部門に情報が集約されていること
資産管理、脆弱性情報に漏れがないこと
資産管理、脆弱性、対応状況といった各情報が常にアップデートされていること 等
脆弱性情報とその解消策が信頼できる内容であること
自組織への影響評価と解消策の要否・優先度の決定が適正に行われること
解消策の実施が安全・確実な方法で行われること 等
脆弱性管理の各プロセスに一貫性があり、組織内で標準化されていること
各プロセスでのトラブル発生時には適宜協議できる状態であること
定期的、あるいは必要に応じて適宜手順の見直しを行うこと 等

“漏れなく”管理するには

ここからは、上記で挙げたポイントのうち、「漏れなく」に焦点を当てていきます。資産情報や脆弱性情報に漏れがあると、どんなにリスク評価や解消策の実施体制を整えていても、結局は非効率かつ不十分な対応結果になりかねません。そのため、IT資産を漏れなく管理することは、脆弱性管理のベースとなる重要なポイントと考えられます。脆弱性管理のライフサイクルでいうと、「資産の把握・管理」プロセスで漏れなく資産情報が収集できているか、「脆弱性情報の収集」プロセスでも漏れなく関連する脆弱性情報が収集できているか、といった点です。

資産の把握・管理:ソフトウェアコンポーネントの管理

見落としがちな資産として、様々な製品に組み込まれているコンポーネントがあります。

■組み込みソフトウェアに起因する脆弱性が問題となった例:

2021年12月 Javaのログ出力ライブラリApache Log4jにおける脆弱性「Log4Shell」公開された*1
悪用されるとリモートコード実行の恐れがあるとして、注意喚起された。
Apache Log4jは国内でも広く利用されているが、様々な製品に組み込まれていることから、国内大手電機メーカーのOT/IoT製品でも影響があることが確認される*2など、脆弱性の影響を受けるシステムの特定が困難だった。
2023年12月Sierra Wireless社の「AirLink」にバンドルされているALEOSや一部のオープンソースコンポーネントについて計21件の脆弱性が特定された*3
リモートコード実行、クロスサイトスクリプティング、DoS、認証バイパスなど深刻度の高い脆弱性が含まれているとのこと。
世界中の政府やインフラなど、ミッションクリティカルな産業で多く利用されているOT/IoTルータであるため、対応不備による影響が懸念される。

OT/IoT機器には、ファームウェア等のソフトウェアコンポーネントが含まれます。これらの機器の脆弱性管理には「ソフトウェア部品表(SBOM)」の活用が有効です。

SBOM (Software Bill of Materials)
特定の製品に含まれるソフトウェアコンポーネントや相互の依存関係の情報などを機械処理できるリストとして一覧化したもの。導入することで、脆弱性対応期間の短縮、ライセンス管理にかかるコストの低減や開発生産性向上などのメリットがある。
参考情報:https://www.meti.go.jp/press/2023/07/20230728004/20230728004.html

SBOMの導入にあたっては、経済産業省より「ソフトウェア管理に向けたSBOM(Software Bill of Materials)の導入に関する手引 Ver. 1.0」(令和5年7月28日)が発行されていますので、参考にしていただくとよいでしょう。

資産の把握・管理:シャドーITの撲滅

先ほど述べた「”漏れなく”管理する」を実現するためには、管理外の資産、すなわち「シャドーIT」がないようにすることが重要です。

組織が認識していないサーバやアプリケーションが稼働していると、その製品自体が組織のセキュリティポリシーの対象外である可能性があり、パッチ適用などのセキュリティ対応が行き届かず、サイバー攻撃の足掛かりとされる恐れが高まります。そもそもその存在を認識していないため、対策の取りようがない、というところが脅威につながります。

■シャドーITに起因する脆弱性が問題となった例:

2024年 2月著名ブランドや組織のサブドメインを乗っ取る大規模な攻撃キャンペーン「SubdoMailing」が報告*4された。
8,000以上の正規ドメインと13,000以上のサブドメインを使用して、一日あたり最大500万件のスパムメールが送信され、詐欺やマルバタイジングによる攻撃者の収益源に。
根本的な原因は、自組織で管理すべきCNAMEレコード(ドメインの別名を定義する情報)が、放棄されたドメインを指定したまま放置されていたこと。

シャドーITを発見するには、ASM(Attack Surface Management)が有効です(下イメージ)。インターネット上に意図せず公開されている資産がないか確認する手段として活用できます。

一般的なASMの特徴とイメージ

インターネットから直接アクセス可能なIT資産の調査—アタックサーフェス調査を実施するには、各種ASMツールもリリースされていますし、専門家によるサービスも提供されているので、自組織に合った方法でシャドーITの存在有無を検査できる方法を検討することをおすすめします。

脆弱性情報の収集:脆弱性診断で補完

資産の把握・管理が漏れなく適切に実施できたとしても、関連する脆弱性情報の収集に漏れがあっては意味がありません。シャドーITの場合と同様、そもそもそこに脆弱性が存在することを認識できていなかった、ということがないようにする必要があります。とはいえ、脆弱性診断にはそれなりのリソースがかかるため、サイバー攻撃を受けた場合の影響が特に大きいと考えられるシステム(下記例)に関しては、脆弱性管理プロセスの一環として脆弱性診断を実施することを推奨します。

・外部に公開されているネットワークセグメント
・個人情報の取り扱いや決済機能といった重要な処理に係るシステム
・主力業務に直結するミッションクリティカルなシステム 等

ASMや脆弱性診断の実施頻度

漏れのない脆弱性管理を行い、サイバー攻撃から組織を守るためには、ASMや脆弱性診断をできるだけ高頻度で実施するのが理想です。しかし、負荷やコストがかかるため、自組織のセキュリティポリシーやサイバー攻撃の流行、システムの状況などに応じて決めることがおすすめです。業務への支障とリスク低減効果を考慮した上で、自組織にとって現実的な実施頻度を検討しましょう。

BBSecでは

BBSecでは以下のようなご支援が可能です。 お客様のご状況に合わせて最適なご提案をいたします。

アタックサーフェス調査サービス

インターネット上で「攻撃者にとって対象組織はどう見えているか」調査・報告するサービスです。攻撃者と同じ観点に立ち、企業ドメイン情報をはじめとする、公開情報(OSINT)を利用して攻撃可能なポイントの有無を、弊社セキュリティエンジニアが調査いたします。

詳細・お見積りについてのご相談は、お問い合わせフォームからお気軽にお問い合わせください。お問い合わせはこちら。後ほど、担当者よりご連絡いたします。

SQAT脆弱性診断サービス

自ステムの状態を知る

サイバー攻撃に対する備えとして、BBSecが提供する、SQAT脆弱性診断サービスでは、攻撃者の侵入を許す脆弱性の存在が見逃されていないかどうかを定期的に確認することができます。自組織の状態を知り、適切な脆弱性対策をすることが重要です。

ウェビナー開催のお知らせ

最新情報はこちら

Security Report TOPに戻る
TOP-更新情報に戻る


資料ダウンロードボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
お問い合わせボタン
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

クロスサイトリクエストフォージェリ(CSRF/XSRF)とは?狙われやすいWebアプリケーションの脆弱性対策

Share

今回は、クロスサイトスクリプティング(XSS)のような「大物の脆弱性」と比較すると、一見地味に見えてしまう「CSRF」の意外な危険性について取り上げます。CSRFの脆弱性リスクやXSSとの違い、さらに実際の診断の現場での検出頻度や、見つかった際に行うべき対応、予防策についてもご紹介します。安全なWebサイト運用のために必読です。

クロスサイトリクエストフォージェリとは

クロスサイトリクエストフォージェリ(Cross Site Request Forgery)は、Webアプリケーションの脆弱性の一つで、略称「CSRF」とも呼ばれます。読み方は「シーサーフ」です。英語で「Cross」は「X」と表記することがあるため、CSRFを「XSRF」と表記することもあります。

「クロスサイト」は「Webサイトをまたぐ」という意味で、「リクエスト」はユーザがWebアプリケーションなどに処理を要求すること、「フォージェリ」には「偽造品」などの意味があります。CSRFの脆弱性を悪用することで、ユーザが意図していないリクエストを強制的に行わせることが可能になります。攻撃者は罠として用意した偽造サイトを用いてユーザーに意図しないリクエストを強制的に送信させます。結果として、ユーザーの認証情報を利用した不正な操作や、個人情報の流出が引き起こされる可能性があります。

クロスサイトリクエストフォージェリとクロスサイトスクリプティングの違い

クロスサイトリクエストフォージェリと似た名前の脆弱性に「クロスサイトスクリプティング(XSS:Cross Site Scripting)」があります。クロスサイトリクエストフォージェリとクロスサイトスクリプティングは、どちらもサイトを横断(Cross Site)してサイバー攻撃が行われる点が共通していますが、発見される頻度や攻撃による影響、対策方法は異なります。

  • XSS:Webサイトに悪意のあるスクリプトを埋め込む
  • CSRF:ユーザの意図しないリクエストを強制的に実行させる

脆弱性診断の現場にみるCSRFの実態

あなたがいまご覧になっているサイト「SQAT.jp」を運営する株式会社ブロードバンドセキュリティでは、日々、さまざまなお客様のシステムに対して脆弱性診断を行っています。

ブロードバンドセキュリティが2024年上半期に総数3,536のシステムに対して行った脆弱性診断の結果、CSRFを含む「セッション管理関連の脆弱性」は15%のシステムで検出され、その中にCSRFは44%含まれていました。つまりCSRFの脆弱性が存在したシステムは全体の6%になります。ここの数字をどうとらえたらよいのか、このあと、CSRFの攻撃例やリスクを紹介しながら考えていきます。

CSRFによる攻撃と被害例

CSRFの脆弱性を悪用した攻撃事例としては、掲示板等に本人が全く意図していない書き込みをさせた例(「遠隔操作ウイルス事件」や「はまちちゃん事件」が有名)があります。

もしCSRFが脆弱性診断で見つかったら、すぐに対応が必要な場合もあります。特に、個人情報の登録や変更などに関わるログイン後のページで発見された場合は、すぐに修正を行わなければなりません。

意図しない掲示板の書き込み以外にも、CSRFの脆弱性を悪用すれば、たとえば「サイトAにログインして会員登録を行っているつもりが、実際には攻撃者が罠として用意したサイトBにログインしており、そこで個人情報を抜き取られる」ような攻撃が行われる危険性もあります。もしそうなれば、サイト運営者としての責任が厳しく問われることは間違いありません。

対策を怠ると他サイトへの遷移ができなくなる可能性も

また、主要なWebブラウザは、XSSやCSRFなどからの保護のために、脆弱性のあるWebサイトをブラウザに表示させない仕様を整えつつあります。たとえばGoogle Chromeは、Chrome 80以降、サイトを越えてCookie情報をやり取りするためのSameSite属性に対して制限を加え、CSRFを防御可能な設定値のみを許容する方向へと段階的に進んでいます*5 。CSRFを防御可能な設定値については他の主要ブラウザも同様の方向に進んでおり、Webアプリケーション開発においてCSRF対策は(他の対策とともに)取らないわけにはいかないものの一つとなりつつあります。

セキュリティ企業が見るCSRFのリスクとは

なお、わたしたちセキュリティ診断サービス会社にとってCSRFとは、一定頻度で検出されるものの、CSRF単体ではそれほどリスクは大きくない脆弱性です。事実、CSRFだけを使った攻撃事例はあまり多くないのです。

CSRFで注意すべきは、他のサイバー攻撃手法と組み合わされることでリスクや被害が大きくなることです。

たとえば「セッションフィクセーション」と呼ばれるセッションIDを強制・固定化する攻撃と、CSRFの脆弱性を悪用した攻撃を組み合わせることで、「セッションハイジャック」と呼ばれるサイバー攻撃が成立すれば、セッションの乗っ取りが行われ、オンラインバンキングでの不正送金などにつながる可能性があります。

CSRFのリスクは低い? 高い?

CSRFだけを考えてしまうとリスクはそれほど高くないため、対応は後回しにされがちです。しかし実際のサイバー攻撃はそう単純ではなく、いくつもの方法が複合されて行われます。「見つかったらすぐに対応が必要な脆弱性のひとつ」とわたしたちが考える理由がそこにあります。

CSRFは、単体では攻撃者にとってそれほど使い勝手の良い脆弱性ではありません。しかし、CSRFはいわば、自身では主役は張れないものの、サイバー攻撃の主役を引き立てるために機能する、名脇役のような脆弱性と言えるかもしれません。

CSRF脆弱性への対策

最も効果的な対策は「トークン」呼ばれる推測困難な文字列の使用です。

  • ユニークな推測困難な文字列を生成
  • リクエスト時に追加検証
  • PHP、Java、ASP.NETの主要フレームワークで実装可能

CSRFの脆弱性を悪用した攻撃で最も警戒すべきはログインしたユーザをターゲットとした攻撃になります。この場合、ログインしたユーザからの正しいリクエストであることを証明するために、「トークン」を使って確認を行うことや再度の認証を行うこと*2などで攻撃を防ぐことができます。

事実、PHP、Java、ASP.NET等の開発言語で提供されている、Webアプリケーションフレームワーク(Laravel、Spring等)は、CSRFの脆弱性を悪用した攻撃を防ぐために、ユニークなトークンを発行する仕組みを持つようになっています。しかし、それでもなおCSRFの脆弱性が見つかることがあるのです。これはどうしてでしょう。

注意!トークン実装の落とし穴

フレームワークに機能があっても、実際のコーディング時に1行追加することを忘れがちです。「機能がある=安全」ではありません。

開発フレームワークがトークンを発行する機能を持っているのにWebアプリケーションでCSRFの脆弱性が発見される理由は、単純そのもので「そもそもトークンを発行するための1行がかかれていない」*3から、ということが多いのです。「機能があるから大丈夫だろう」という思い込みが思わぬリスクを招きます。

前半で、ブロードバンドセキュリティが行った脆弱性診断の結果、約6%でCSRFの脆弱性が検出されたとお伝えしましたが、リスクを知り、適切な対策を確実に実装することで、この数字をもっと少なくすることができるでしょう。

まとめ:CSRFは名脇役、されど油断大敵

  • CSRFとは、「シーサーフ」と呼ばれる、攻撃者が罠として用意したサイトを用いて、ユーザが意図しないリクエストを強制的に行わせることを可能にする脆弱性です。
  • CSRFは単独では大きな脅威ではありませんが、他の攻撃手法と組み合わさることで深刻なセキュリティリスクになり得ます。
  • CSRFとXSSは、どちらもサイトを横断してサイバー攻撃を行う点だけは共通していますが、発見頻度やリスク、対策方法は異なります。
  • 定期的な脆弱性診断と、最新のセキュリティ対策が何より重要です。

Security Report TOPに戻る
TOP-更新情報に戻る


資料ダウンロードボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
お問い合わせボタン
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像