Ivantiブログ: セキュリティ

パッチ・アポカリプスの時代です。IT部門のこの3つの言い訳は、もはや通用しません。

Wed, 29 Apr 2026 14:00:07 Z

4月7日、Anthropicは、同社のClaude Mythos Previewモデルが、主要なすべてのオペレーティングシステムと主要なすべてのWebブラウザーにわたり、重大度が高またはクリティカルのゼロデイ脆弱性を数千件、自律的に特定したと発表しました。その99%以上は、開示当日に未パッチの状態でした。

その2週間後の4月21日、Mozillaは、同じモデルを使用してFirefoxの最新リリースに含まれる271件の脆弱性を発見し、パッチを適用したと述べました。Mozilla自身の評価は次のとおりです。「これまでのところ、人間が発見できる脆弱性のカテゴリや複雑さで、このモデルが発見できないものは見つかっていません。」

271件は第一波にすぎません。Chrome、Edge、Windows、macOS、Linux、FreeBSD——Anthropicのレッドチームが開示したFreeBSDにおける17年前のリモートコード実行の欠陥（CVE-2026-4747）は、今後起こることを示す初期の例です。AnthropicのProject Glasswingの傘下にあるすべてのベンダーは、業界がこれまで経験したことのないテンポで修正を提供できる立場にあります。これらの修正はすべて、パッチが提供される公開CVEとなり、最終的に同じ場所、つまりお客様の環境に到達します。

封じ込めに関する説明にも綻びがあります。4月21日、Bloombergは報じました。Discordに関連するグループが、サードパーティベンダーの環境を通じてMythosに不正アクセスしたというものです。Anthropicは、この活動は当該ベンダーの範囲を超えていないとしています。同様の能力がすでに攻撃者の手に渡っているかどうかにかかわらず、防御側に残された時間は、4月7日の発表が示唆していたよりも短くなっています。

Mythosは、すでにこの方向へ向かっていた世界に登場しました。CrowdStrikeの2026年版グローバル脅威レポートでは、2025年にAIを活用した攻撃が前年比89%増加したことが示されています。この傾向線は、Mythos以前から存在していました。

これはパッチ・アポカリプスと呼ぶべき状況です。パッチが提供される公開CVEの量と発生頻度が、多くのITチームやセキュリティチームの現在の業務手法を上回ろうとしている、極めて実務的な意味での危機です。

NISTはすでに、パッチ・アポカリプスの影響を受けています。4月、同機関は、提出件数が263%急増したことを受け、National Vulnerability Database（NVD）の運用を大きく変更すると発表しました。NISTは今後、提出されたすべての脆弱性に詳細なエンリッチメントを提供することをやめ、CISA Known Exploited Vulnerabilitiesカタログに掲載されているものや、重要な政府ソフトウェアに影響するものなど、高リスク基準を満たす脆弱性に限定して提供します。NISTは独自の評価を行うのではなく、IvantiのようなCVE Numbering Authorities（CNA）に依拠することになります。

この発表以降、私はお客様や同業者から、同じ反応の3つのバリエーションを耳にしてきました。いずれも、もっとゆっくりした世界を前提に設計されたプログラムの延長線上にあります。

「当社には脆弱性スキャナーがあります」

Qualys、Rapid7、Tenableは、脆弱性の検出に優れています。スキャナーは発見し、フラグを立て、スコアを付け、一覧化します。展開、検証、再起動の処理、ロールバックは、その範囲外です。その作業はどこかで実行しなければなりません。多くのプログラムでは、それは別のツール、別のチーム、別のサイクルで行われています。

エクスプロイト可能な時間枠がいまや数時間単位になり、Glasswingのキューによってバックログが倍増しようとしている状況では、587件のクリティカルな脆弱性を出力して、そのリストを人間のチームに渡すだけのスキャナーはリスク要因になります。現実的な対策は、すでに保有しているスキャナーを、その検出結果に基づいて自動的に対応できる修復エンジンに接続することです。自律型エンドポイント管理（AEM）プラットフォームであれば、リングベースの展開とロールバック、そして脆弱性インテリジェンスにより、効率的な修復判断に必要なリスクベースのコンテキストを提供できるため、人がすべての判断を下さなくてもリストを削減できます。

「当社はチケットシステムで承認を回しています」

人間が判断しなければならない、という話に関連しますが、長く直線的な承認プロセスは修復プロセスを大幅に遅らせます。最新のOSやブラウザーの更新を展開するかどうか、最後に判断が必要だったのはいつでしょうか。

組織は、これらの更新を展開することをすでに分かっています。承認プロセスは、多くの場合、複雑な社内政治やセキュリティ成果に対する認識のずれに起因します。その結果どうなるでしょうか。前述の脆弱性スキャナーが必要になり、すでに実行すべきと分かっている作業をアナリストが承認し、承認のためのチケットがビジネスオーナーに送られて受信トレイで待機し、最終的には、実質的にすでに理解されていて改めて下す必要のない判断に貴重な時間が費やされます。

市場では、エクスポージャー管理への移行が進んでおり、組織のリスク許容度を定義し、リスク態勢を監視することに重点を置くことで、このプロセスにまったく異なるアプローチを取っています。次にWindows OSの更新がリリースされたとき、展開すること、展開するスケジュール、そして成功を測定するSLAやコンプライアンス指標は、すでに分かっているはずです。本当に知りたいのは次の点です。

1. その更新に既知の悪用済み脆弱性が含まれているため、より迅速に対応する必要があるのか。

または

2. その更新が業務に影響しており、ペースを落とす必要があるのか（自律型エンドポイント管理プラットフォームにロールバック付きのリング展開が含まれていてよかった、という場面です）。

「当社にはIntuneがあります」

Microsoft Intuneには、ここで重要になる2つの範囲上の制限があります。

第1に、Intuneが管理できるのは、Intuneに登録されたデバイスだけです。未登録または未管理のエンドポイント——サーバー、請負業者のノートPC、シャドーIT、放置されたエッジデバイス——は、その可視性の範囲外に完全に置かれます。脆弱性の量が増加する時期には、こうした死角は、チームが手作業で対応できる速度を上回って増えていきます。

第2に、Intuneはアプリケーションの展開と更新を簡素化しますが、サードパーティアプリケーションの対応範囲と優先順位付けの深さは、多くの管理者が考えるより限定的です。Intuneが示せるのは何が古くなっているかであり、何が実際にエクスポージャーを高めているかではありません。そのため、時間が限られる中で、チームはすべてを後追いでパッチ適用するか、推測に頼らざるを得なくなります。

多くのエンタープライズ環境は、Windowsだけで構成されているわけでも、完全に登録されているわけでも、小規模で均質なアプリケーションスタックだけを実行しているわけでもありません。脆弱性の開示が急増すると、パッチ適用を限定的な経路に任せることはギャップを生み、システム全体のリスクへと発展します。

Intuneは維持してください。その上で、Intuneが認識できない資産を検出し、最も重要な脆弱性に優先順位を付け、Intuneがカバーしないアプリケーション全体に自信を持ってパッチを適用できる、検出と修復のレイヤーを組み合わせてください。

どう対応すべきか

自動化こそが運用モデルです。ワークフローに組み込まれていなければなりません。

実務担当者は、この原則を以前から理解しています。それは次の3つの領域に現れます。

継続的なトリアージ。既知の悪用済み脆弱性は、特にエンドユーザーシステムのように組織内でセキュリティが相対的に弱い領域では、ゼロデイ対応トラックに乗せることができます。さらに、ブラウザーや通信アプリなど特定のアプリケーションを設定・定義し、毎週、場合によっては毎日確認される優先トラックで更新するようにします。それ以外は、通常のメンテナンスウィンドウが来るまで待つことができます。
自動ロールバックを備えたリング展開。テストリング、早期導入者リング、広範な本番環境、ミッションクリティカル。順序としては地味ですが、多くのメンテナンスでは機能します。変わったのは、一定の更新については、月次メンテナンスを待つのではなく、エクスプロイト可能な時間枠に合わせて期間を圧縮する必要があることです。テストリングは自動化され、計測可能でなければなりません。人間によるチェックリストでは、そのスピードには追いつけません。
クローズドループ検証。パッチは、エンドポイントにインストールされたことが検証されるまで展開済みとは言えず、CVEは、再スキャンで確認されるまでクローズとは言えません。多くのチームはこのステップを省略しています。そのため、監査の前週になってコンプライアンス証跡の準備が火消し対応になります。だからこそ、当社は今週、プラットフォームに継続的コンプライアンスを搭載しました。パッチの展開に合わせてコンプライアンス証跡が継続的かつ自動的に生成され、多くのチームが対応する余力のない優先順位付けの判断を自動化が担えるようにするためです。

Mozillaの271件のFirefox脆弱性は、予告編にすぎません。Glasswing傘下の主要なソフトウェアベンダーは、より多くの脆弱性を、加速したペースで修正し始めようとしています。そして同種の能力を持つ攻撃者は、同様のモデルにアクセスできるようになれば、そのような隙を正確に狙ってくるでしょう。その結果として生じるAI軍拡競争は、組織が加速したペースで修復しなければならない更新の数と頻度に直接影響します。プログラムを支えるのは自動化です。いまだに月次のみのパッチ適用を行っているチームには、厳しい時期が待っています。

ITまたはセキュリティプログラムを運用しているなら、今こそ自己評価を行う価値があります。直近で展開したクリティカルなパッチを取り上げてみてください。さらに言えば、金曜日にゼロデイが公開された場合、月曜日までに修復できるでしょうか。CVEの公開から最後のエンドポイントでインストールが検証されるまでの時間を測ってください。その数値が週単位であるなら、パッチ・アポカリプスは確実にお客様の組織に迫ってきます。

Trusted Ownership：Ivanti Application Control が許可リストを超えて拡張できる理由

Wed, 25 Feb 2026 14:25:15 Z

アプリケーション制御は、多くの人が古い思い込みを抱いているセキュリティトピックの一つです。従来の許可リストは安全に見えますが、すぐにメンテナンスの負担になります。ブロックリストは事後対応的で不完全に感じられます。また、Microsoft AppLocker のようなツールによって、厳格な許可リストこそがゴールドスタンダードだと多くの人が考えるようになりましたが、最新の攻撃はそうではないことを証明しています。攻撃者はますます 正規の署名済みツール を不適切なコンテキストで使用し、リストベースの制御を完全に回避するようになっています。

そのため、組織が Ivanti Application Control や Ivanti Neurons for App Control を評価し、Trusted Ownership に出会うと、明示的なブロックが可能であるため、最初はブロックリストに似ているように見えるかもしれません。実際には、Trusted Ownership は、単なる同一性ではなく出所に基づいて実行を制御する、はるかに広範で運用負荷の軽い、プロビナンスに着想を得た強制モデルです。

増え続けるリストを管理するのではなく、システムにソフトウェアを配置した主体に基づいてセキュリティを適用し、最新のソフトウェア配布プラクティスやゼロトラストの原則と自然に整合します。これは、別のリスト機構としてではなく、単なる同一性ではなく出所に基づいて実行を制御する、プロビナンスに着想を得た強制モデルとして理解するのが最適です。

この発想の転換により、最新のアプリケーション制御においてより適切な問いが生まれます。ファイルが何であるかだけでなく、どのようにそこに到達したのか

リストを超えて：プロビナンス制御が今重要な理由

ファイルがどのようにシステムに到達したのかという問いは、プロビナンス制御の中核です。プロビナンス制御では、発行元、パス、ハッシュだけに基づいてファイルを信頼するのではなく、そのファイルを持ち込んだ出所とプロセスを評価します。誰がそのファイルをディスクに書き込んだのか。どの仕組みを通じて行われたのか。インストールは管理された IT ワークフローに従っていたのか。この評価により、アプリケーション制御はオブジェクトの信頼からプロセスの信頼へと移行し、はるかに強固なセキュリティ境界を構築します。

Ivanti Application Control では、プロビナンス制御は Trusted Ownership として実装されています。信頼された所有者が配置したファイルはすべて許可され、ユーザーが持ち込んだものはデフォルトで拒否されます。これは、実行ファイル、DLL、インストーラー、スクリプトに一貫して適用されます。SYSTEM、TrustedInstaller、Administrators などの ID はデフォルトで信頼されるため、MS Intune、MECM、Ivanti Endpoint Manager（EPM）やその他のエンタープライズツールなどの標準的な展開チャネルを通じて提供されるソフトウェアは、ルールのメンテナンスや例外なしですぐに実行されます。

これは、従来の許可リストからの根本的な転換を示しています。AppLocker ルールの成否は、正確な発行元、パス、ハッシュの定義に依存します。インストール元を評価せず、展開メカニズムを自動的に信頼することもありません。Intune で提供されるソフトウェアであっても、事前に許可ルールが必要であり、多くの場合、Program Files や Windows ディレクトリを許可する広範な既定設定に依存します。

この違いが重要なのは、最新の攻撃では、正規のツールが不適切なコンテキストで武器化されるケースが増えているためです。プロビナンス制御は、ソフトウェアがどのように到達したかを信頼の基準として強制し、それが何であるかだけに頼らないことで、そのリスクの多くを無力化します。これはゼロトラストの原則に沿い、サプライチェーンの露出を減らし、Living off the Land（LotL）悪用の機会をデフォルトで大幅に狭めます。

出所の重要性を理解すると、次の問いは「それをどのように大規模に適用するか」です。

答えは、ソフトウェアが実行されるあらゆる方法と、提供されるあらゆる方法に対して、プロビナンスを一貫して適用することです。

ブロックリストを超えて：最新のソフトウェア展開に対応する広範なカバレッジ

プロビナンス制御は、アプリケーションセキュリティを、終わりのないリスト管理から、ソフトウェアがシステムに到達するプロセスの検証へと移行させます。この視点を取り入れると、Trusted Ownership がブロックリスト方式ではないことが明確になります。これは出所に基づく信頼境界であり、従来の許可リストとは大きく異なる動作をします。

Trusted Ownership は、管理者がよく知られた Windows ツールに対して対象を絞った拒否ルールを追加することがあるため、ブロックリストに似ているという誤解があります。実際には、これらの拒否ルールは Living off the Land 技法に対する防御的な強化策です。本格的なアプリケーション制御手法では、いずれもこのような対象を絞った制限を使用します。Trusted Ownership の本質は、ブロックリストの反対です。管理され信頼されたプロセスを通じて提供されたソフトウェアはデフォルトで許可され、ユーザーが持ち込んだコンテンツはデフォルトで拒否されます。

より重要な差別化要因はカバレッジです。従来の許可リストに依存している多くの組織は、ほぼ実行ファイルだけに注力することになりがちです。DLL、スクリプト、MSI パッケージに同じ強制を適用すると、ルールのメンテナンスがはるかに複雑になるため、避けられることが少なくありません。その結果、最新の攻撃者が頻繁に悪用するギャップが生まれます。

Trusted Ownership は、実行チェーン全体に同じ出所ベースの強制を適用することで、こうしたギャップを回避します。実行ファイル、DLL、スクリプト、MSI インストーラー、および関連コンポーネントは、同じ信頼モデルで評価されます。信頼はファイルを持ち込んだ主体によって決まるため、ファイルタイプごとに別個のポリシーを用意する必要はありません。Downloads フォルダー内のスクリプト、一時ビルドディレクトリで作成された DLL、ユーザープロファイルから実行される EXE はいずれも、管理されたインストールプロセスの外部から発生した場合、同じデフォルト拒否の扱いを受けます。

この信頼モデルは、最新のエンドポイント管理プラットフォームがソフトウェアを提供する方法とも自然に整合します。Intune、MECM、Ivanti Neurons for MDM、Ivanti Endpoint Manager などのソリューションや類似システムでは、通常、SYSTEM ID または別の信頼されたサービスアカウントを使用してアプリケーションをインストールします。

これらの ID はすでに Trusted Owners であるため、これらのチャネルを通じて展開されたソフトウェアは、許可ルールの作成、ファイルパスの管理、ポリシーの更新を行わなくてもすぐに実行されます。カスタム DevOps エージェントやユーザーコンテキストでのスクリプトインストールなど、代替のインストールアカウントを意図的に使用する場合にのみ、その ID を Trusted Owner として識別する必要があります。

その結果、関連するすべてのファイルタイプに対して広範で一貫したカバレッジを提供するモデルが実現します。最新のソフトウェア配布とシームレスに連携し、主に実行ファイルに焦点を当てる従来の許可リストに伴う運用オーバーヘッドを回避できます。

Trusted Ownership は、個々のオブジェクトではなく、ソフトウェアが提供される管理されたプロセスを信頼することで、アプリケーション制御に対して、よりスケーラブルでより安全なアプローチを実現します。

WDAC（App Control for Business）の位置付け

Microsoft は、AppLocker と App Control for Business（旧 WDAC）という 2 つのアプリケーション制御テクノロジーを維持しています。どちらも現在も存在していますが、Microsoft はその役割を明確にしています。AppLocker は、ユーザーが未承認のアプリケーションを実行するのを防ぐのに役立ちますが、最新のセキュリティ機能のサービス基準を満たしていないため、戦略的なセキュリティ制御ではなく多層防御メカニズムとして分類されています。

Microsoft がアプリケーション制御の今後の方向性として位置付けているのは App Control for Business であり、AppLocker は機能完了済みで、重要なセキュリティ更新を除いて積極的な開発は行われていないと明示しています。つまり、新機能はすべて WDAC のみに提供され、AppLocker には提供されません。

App Control for Business では、Managed Installer の概念が導入されています。これにより Windows は、Intune や MECM などの指定された展開プラットフォームを通じてインストールされたアプリケーションを自動的に信頼できます。信頼は個々のファイルではなく配布チャネルから導き出されるため、ルールのメンテナンスが大幅に削減されます。

これは、Ivanti Application Control の Trusted Ownership モデルと密接に一致しています。どちらのアプローチも、個別のファイル属性ではなく、ソフトウェアをインストールした管理されたプロセスに基づいてソフトウェアを信頼します。ただし、Trusted Ownership はこの概念をよりシンプルで運用しやすい形で適用します。Ivanti は、複雑なポリシーレイヤー、XML 定義、深い WDAC の専門知識を必要とせずに、SYSTEM や指定されたサービスアカウントなどの ID を信頼します。

Ivanti には、多くの組織が WDAC の運用化に苦労しているという声が寄せられています。WDAC ポリシーには、慎重な設計、監査モードでの長期間のテスト、ドライバーおよびカーネル例外の管理、複数のポリシーセットの継続的なメンテナンスが必要です。そのため、組織は WDAC と AppLocker を組み合わせることが多く、低レベルの強制と日常的なユーザー空間の制御の両方をカバーしようとして、結果的に管理オーバーヘッドを抱えることになります。

Ivanti Application Control は、統合された代替手段を提供します。Trusted Ownership、Trusted Vendors、デジタル署名検証を通じて、実行ファイル、DLL、スクリプト、MSI パッケージにわたって一貫したカバレッジを備えた、プロビナンスベースのデフォルト拒否モデルを実現します。

範囲の異なる 2 つの MS 制御プレーンを維持する代わりに、組織は、ソフトウェアがシステムにどのように導入されたかに基づいて信頼を強制する、単一の合理化されたポリシーを管理します。これにより、WDAC と AppLocker を組み合わせた展開でお客様が達成しようとする実務上の目標の多くを、より低い運用複雑性と一貫した 1 つの信頼モデルで実現できます。

LOLBins と引数レベルの制御

広範なカバレッジが確立されると、次の課題は、攻撃者が悪用しがちな、すべてのマシンにすでに存在する正規のツールをどのように扱うかです。

最新の攻撃者は、従来型のマルウェアの使用を避け、すべての Windows デバイスにすでに存在するツールに依存することがよくあります。これらの Living off the Land ツール（LOLBins）は正規のものであり、通常業務に必要なため、生産性に影響を与えずにブロックすることは困難です。従来の許可リストは、広範にブロックするとワークフローが壊れ、広範に許可すると危険なギャップが残るため、この領域で課題を抱えます。

Trusted Ownership のようなプロビナンスベースのモデルは、この力学を変えます。攻撃者が組み込みツールを使用しようとしても、実行しようとするコンテンツは通常、信頼されたインストールプロセスから来たものではありません。Ivanti はそのコンテンツの出所を評価するため、不正使用の試みの多くは自動的に失敗します。ツール自体は正規のものであっても、実行を求められているコンテンツは正規ではなく、Trusted Ownership は実行前にそれを阻止します。

どのツールが実行されるかだけでなく、それらに何を実行させようとしているのかを理解することも重要です。PowerShell、Python、Java などの多くのインタープリターやランタイムは、あるコンテキストでは完全に安全でも、別のコンテキストではリスクを伴う可能性があります。業務アプリケーションが、特定の承認済みプロセスを開始するために Java に依存している場合と、ユーザーがダウンロードした JAR ファイルの場合とでは、まったく異なるシナリオです。

Ivanti は、階層型のアプローチでこれに対応します。JAR ファイルはまず Trusted Ownership を使用して評価され、管理された展開プロセスではなくユーザーによって持ち込まれたものであれば、直ちにブロックされます。さらに管理者は、許可される Java コマンドを正確に指定するシンプルな許可ルールを作成できるため、正規の Java ベースアプリケーションのみを実行し、未承認の JAR ファイルの起動試行を静かに拒否できます。

同じ原則は、他のツールにも適用されます。ポリシーでは、組織に必要な正確な動作を承認し、その境界を外れるアクティビティをブロックできます。これにより、広範で壊れやすいルールを避けながら、日常業務を円滑に維持できます。

その結果、バランスの取れた最新のアプローチが実現します。Trusted Ownership は、信頼されていないコンテンツをデフォルトで阻止します。重点的な強化は、living off the land の悪用を減らすための政府機関およびコミュニティのベストプラクティスに沿っており、意図を認識する制御により、攻撃者に侵入口を開くことなく正規のプロセスを継続して機能させることができます。

このアプローチは、living off the land 技法の軽減に関する現在のコミュニティおよび政府機関のガイダンスと密接に一致しています。CISA、NSA、FBI、オーストラリアサイバーセキュリティセンターなどの機関は、組み込みツールの使用方法を制御し、それらが作用する信頼されていないコンテンツを制限することで、攻撃者が組み込みツールを利用する機会を減らすことを重視しています。共同ガイダンスでは、LOTL 攻撃がネイティブツールの悪用に依存していることを強調し、正規のシステムプロセスをブロックせずにこうした悪用を制限する制御の必要性を訴えています。

Ivanti のモデルは、このガイダンスを反映しています。Trusted Ownership は、攻撃者が依存する信頼されていないコンテンツを自動的にブロックし、少数の重点的な制限によって、追加の注意が必要な少数のツールに対応します。

Trusted Ownership の実践：実際のシナリオ

Ivanti Application Control と Trusted Ownership が実際の運用でどのように機能するかを示す例をいくつか紹介します。

ポータブルアプリケーションがユーザープロファイルにコピーされます。Ivanti は、それがユーザー所有であるためブロックします。AppLocker は一致するルールがある場合にのみブロックします。適切なパスまたは発行元ルールがなければ、動作が異なる可能性があります。
メール添付ファイルが Downloads から PowerShell スクリプトを起動します。Ivanti はユーザー所有であるため拒否します。AppLocker はスクリプトルールに依存し、ブロックイベント時には PowerShell を制限付き言語モードに強制しますが、それでもスクリプトは実行されます。
rundll32 や mshta などの OS ツールの悪用。どちらのモデルでも、対象を絞った拒否による強化が必要です。Ivanti はこれをプロビナンス制御と組み合わせることで、一般的に必要な例外の数を削減します。AppLocker は精選された拒否セットに依存し、定期的な調整が必要です。
ベンダーのアップデートによって新しい署名済みファイルが配布されます。Ivanti は、Trusted Ownership により、信頼された展開チャネル経由で到着したアップデートを許可します。AppLocker は発行元ルールでこれに対応できますが、複数製品間での署名の再利用や通常とは異なるインストールパスにより、追加のメンテナンスや意図した以上に広範な信頼につながることがよくあります。
ユーザーが JAR をダウンロードし、Java で実行しようとします。Ivanti は、その JAR がユーザーによって持ち込まれ、Trusted Ownership に合格しないため、その試行をブロックします。必要に応じて、管理者は完全なコマンドラインとの照合により、承認済みの正確な呼び出しだけを許可できます。AppLocker は引数を照合できず、発行元、パス、ハッシュのルールに依存します。

まとめ

プロビナンス制御は、アプリケーション制御を管理上の問題から信頼モデルへと移行させます。個々のファイルではなく、ソフトウェアがシステムに到達するプロセスを信頼することで、セキュリティをスケーラブルかつ実運用可能なものにします。

Trusted Ownership は、このアプローチにまさに合致します。これはブロックリストでも従来の許可リストでもなく、管理された IT プロセスを通じて到達したソフトウェアはデフォルトで許可され、そのプロセスの外部にあるものはすべてデフォルトで拒否されるモデルです。場当たり的なファイルではなく、出所と所有権に基づいて強制することで、Ivanti Application Control と Ivanti Neurons for App Control は、最新の攻撃手法や今日のソフトウェア配布とより適切に整合します。

アプリケーション制御をリスト管理の作業として扱い続ければ、管理負担を感じることになります。信頼境界として扱えば、スケーラビリティ、セキュリティ、運用上の実行可能性を得られます。

CEOがCISOに求めるサイバーセキュリティリスク管理戦略の伝え方

Tue, 17 Feb 2026 13:00:01 Z

ほとんどのCEOは、四半期のベンチマークや売上を小数点以下まで正確に述べることができます。しかし、自社のサイバーリスクエクスポージャーについて尋ねると、回答は途端に曖昧になります。今日のCEOがセキュリティを重視していないわけではありません。サイバーセキュリティは、取締役会や経営幹部にとって最重要課題の一つです。問題はより根深く、セキュリティリスクをビジネスリーダーに説明する方法が根本的に機能しておらず、事業成果への影響が見落とされている点にあります。

CISOとCEOの間で起こるコミュニケーション上の問題の多くは、能力不足が原因ではありません。よくある課題、すなわち「知識の呪い」から生じています。知識の呪いとは、専門家（この場合はセキュリティリーダー）が、会議に参加している全員が技術情報や用語について一定の理解を持っていると思い込んでしまう認知バイアスです。その結果、複雑なリスクを平易な言葉に分解し、現実のビジネス文脈で説明することができなくなります。

Ivantiの2026年サイバーセキュリティの現状レポートは、この認識のずれを浮き彫りにしています。セキュリティ専門家の約6割が、自社チームによる経営層へのリスクエクスポージャーの伝達は「ある程度有効」にとどまると回答しています。

CEOとCISOが同じ言葉で話していないと、事業上重大な脆弱性が技術用語の陰に隠れてしまう可能性があります。コミュニケーションが機能しなくなると、組織は的外れな投資に時間とコストを費やし、侵害が発生して初めて対話を余儀なくされるまで、防御上のギャップに気づけないことがあります。

脅威レベルが高まり、AIを活用した攻撃が高度化し、データ侵害が毎週のように報じられるなか、CISOと経営層の間で明確にコミュニケーションを取ることの重要性は、かつてないほど高まっています。

このコミュニケーションギャップがなぜ続くのかを理解するには、根本的な課題と、成功を測定するために使われている指標の両方を検証する必要があります。

サイバーリスクのコミュニケーションが失敗する理由：知識の呪い

CEOとCISOの間にあるこの認識のずれは、データ不足が原因ではありません。むしろその逆です。CEOの立場から見ると、課題は注意力や意図の欠如ではありません。ダッシュボード、指標、略語、深刻度スコアを見せられても、それらの結果が事業全体にどのような影響を及ぼすのかを理解できないことが問題なのです。

セキュリティリーダーは、会議の参加者の多くが、CVSSスコア、攻撃対象領域、ゼロデイ脆弱性といった用語が持つ意味を理解していない可能性があると考える必要があります。CEOが求めているのは、指標、略語、深刻度スコアで埋め尽くされたダッシュボード以上のものです。

サイバーセキュリティの説明では、さらに一歩踏み込み、これらの結果が事業に及ぼす財務面、法務面、評判面の影響を示す必要があります。CISOは「今月587件の重大な脆弱性を検出しました」と報告するかもしれません。しかしCEOが本当に知る必要があるのは、「そのうちどれが顧客へのサービス提供能力を脅かしており、それに対処する計画は何か」ということです。

CEOにとって重要なサイバーセキュリティKPI

有用なKPIは、脆弱性管理の取り組みとビジネスリスクを明確に結び付けます。しかし、Ivantiのサイバーセキュリティ調査によると、セキュリティチームが最もよく使用しているKPIは、リスクの文脈を反映できていません。

現在、サイバーセキュリティのエクスポージャースコアやその他のリスクベースの指標を追跡している企業は半数（51%）にとどまります。多くのセキュリティチームは、平均修復時間（47%）や修復済みエクスポージャーの割合（41%）といったプロセス指標に依然として依存しています。

MTTR、パッチ適用速度、修復率といった指標はセキュリティチームにとって重要ですが、測定しているのは運用効率であり、事業上のエクスポージャーや潜在的な財務影響ではありません。これらを単独で見ると安心材料のように見える一方で、本当に問うべきことを覆い隠してしまいます。それは、私たちはリスクを効果的に管理できているのか。

という問いです。速度とカバー範囲に焦点を当てたこれらの指標は、それ自体では良好に見えるかもしれません。しかし、現在の修復活動が実際にリスクポスチャーを改善しているかを示すには不十分です。脆弱性をどれだけ早く修復したか、どれだけ多く対処したかは、それほど重要ではありません。より重要なのは、適切な問題に対処しているかどうかです。

セキュリティチーム、取締役会、経営幹部の間で共通理解を得るには、分かりにくい指標を現実の利害に結び付ける必要があります。CEOにとってこれは、自社に特有の最重要リスクについてCISOと認識を合わせることを意味します。たとえば、高度な不正手口、PCI-DSSやSOXのような厳格なコンプライアンス要件、顧客の金融データを狙うランサムウェアの絶え間ない脅威に頻繁に直面している金融機関なのか。機密性の高い患者データを保護するために厳格なコンプライアンス基準を維持しながら、拡大する接続医療機器ネットワークの安全確保に取り組む医療機関なのか。

技術的な指標だけに依存した経営層向けセキュリティブリーフィングと、文脈やビジネスへの影響を加えたブリーフィングの違いを見てみましょう。

CISOが伝えること：

「11,000件の脆弱性を発見しました。」
「MTTRは25日から15日に短縮されました。」
「重大なCVEの修復率は88%に達しました。」

CEOが実際に知る必要があること：

「収益を生み出すシステムに影響を及ぼす可能性のある重大な脆弱性を10件特定しました。」
「今日攻撃を受けた場合でも、昨年は48時間かかっていた重要業務の復旧を6時間で実施できます。」
「この保護により、追加のコンプライアンスリスクを負うことなくEUへの事業拡大を進められます。」

経営層レベルのリスクアペタイト・フレームワークの構築

経営層とのコミュニケーションには、リスクをどのように定義し、測定し、議論するかについて、共有されたフレームワークと共通の参照点が必要です。一貫性の欠如や混乱をなくすには、すべてのステークホルダーがリスクアペタイト・フレームワークの策定と運用に関与する必要があります。

こうした対話の大きな目的の一つは、サイバーセキュリティプログラムの目標は完全に「リスクゼロ」になることではない、とビジネスリーダーに理解してもらうことです。現代のどの組織にとっても、完全にリスクのない状態になることは不可能です。つまりCEOは、自社のリスクアペタイトとリスクポスチャーを区別できなければなりません。

1. リスクアペタイト：組織が全体的な目標を追求するうえで、現時点でどの程度のリスクを許容する意思があるか。

2. リスクポスチャー：組織が現在さらされているリスクエクスポージャーの実態。

現在ではほとんどの組織が、どの程度のサイバーリスクを受け入れる意思があるのかを正式に定義する必要性を認識しています。Ivantiの調査では、80%を超える組織が文書化されたリスクアペタイト・フレームワークを持っていることが示されています。

しかし、日々の業務でこうしたフレームワークが厳密に守られていると回答した組織は半数未満です。フレームワークが文書上は存在していても、実際の意思決定を導いていない場合、組織のリスクアペタイトとリスクポスチャーが一致していない可能性が非常に高くなります。

エクスポージャー管理がコミュニケーションギャップを埋める仕組み

エクスポージャー管理とは、攻撃対象領域全体にわたる潜在的な脅威の範囲を継続的に特定し、優先順位付けし、検証するリスクベースのアプローチです。エクスポージャー管理を実践することで、セキュリティリーダーと経営層は、サイバーセキュリティをビジネスクリティカルなリスク中心に再構築する、単一の包括的な戦略のもとで連携できます。

すべての脆弱性を同等に扱うのではなく、エクスポージャー管理では、次の問いを通じて、組織にとって最も高いリスクを特定し、優先順位を付けることに焦点を当てます。

現在のエクスポージャーのうち、脅威アクターが実際に悪用しているものはどれか。
現在の事業運営に基づいて、どの資産を優先すべきか。
侵害された場合、評判、顧客、法務面の損害という観点で最も大きな影響を及ぼす資産はどれか。

Ivantiの調査レポートによると、現在では約3分の2の組織がエクスポージャー管理に投資しており、リーダー層の理解も前年比で高まっています。しかし、実行面では依然として遅れがあります。自社のリスクエクスポージャー評価能力を「優れている」と評価している組織は、約4分の1にすぎません。

このギャップを解消し、エクスポージャー管理を効果的に運用に組み込むには、CISOは経営層とのコミュニケーションを次の3つの原則に基づけるべきです。

1. 技術的なシグナルをビジネス文脈に置き換える。脆弱性の件数を報告するのではなく、どのエクスポージャーが収益を生み出すシステム、顧客データ、規制対象環境に影響するのかを説明します。

2. 新たな脅威は量ではなく影響度で優先順位付けする。経営層は、新しい攻撃手法を一つひとつ追跡する必要はありません。事業に実質的な混乱をもたらす可能性のある状況と、それに対応する組織の準備状況を理解する必要があります。

3. スプレッドシートではなくシナリオを使う。データに裏付けられ、原因、影響、結果を結び付けるストーリーは、リーダーがリスクを腹落ちさせ、より迅速に意思決定する助けになります。

このアプローチにより、リスク軽減戦略は受動的な防御から、先回りした意思決定へと移行します。

今後の方向性

経営層とセキュリティリーダーが同じ言葉で話せるようになれば、知識の呪いを打ち破ることができます。そしてサイバーセキュリティは、事業価値を守り、成長を可能にし、セキュリティの強みを競争優位へと変える戦略的な推進力になります。

知識の呪いは打ち破ることができます。一つの指標をビジネスの言葉に置き換え、一つのビジネス視点の対話を重ね、一つの明確な意思決定を行うことから始まります。

エクスポージャー管理と脆弱性管理：真のリスク低減を実現するのはどちらか？

Thu, 29 Jan 2026 13:00:01 Z

脆弱性管理は長年にわたり、組織とサイバーセキュリティ業界を支えてきました。これは有効な取り組みであり、企業が攻撃対象領域を守り、脅威アクターによる脆弱性の悪用を防ぐうえで役立ってきました。

しかし、テクノロジーとITインフラは進化しています。脆弱性管理だけでは、この進化に伴う課題に対応しきれなくなっています。今、エクスポージャー管理は、脆弱性管理ではカバーしきれない領域を補い、エンドポイントセキュリティに対してさらに包括的なアプローチを提供します。

両者の違いを詳しく見て、組織をどのように保護すべきかを検討しましょう。

脆弱性管理とは何か？

脆弱性管理とは、攻撃者が組織への侵入に利用し得る脆弱性を、継続的かつプロアクティブに特定、評価、優先順位付け、修復するサイバーセキュリティの取り組みです。

ただし、脆弱性管理には次の2種類がある点を理解しておくことが重要です。

従来型の脆弱性管理	リスクベースの脆弱性管理
できるだけ多くの脆弱性を修復しようとするアプローチです。多くの場合、多大な労力を要し、成功に対する現実的でない期待を生む一方で、誤った安心感をもたらします。	脆弱性の優先順位付けにリスクを考慮する、進化した脆弱性管理の取り組みです。これにより、組織は現実世界で脅威となる重大な脆弱性にパッチを適用でき、脅威アクターから組織を保護しながら、強固なセキュリティ態勢を維持し、リソースを効果的に管理できます。

リスクベースの脆弱性管理のアプローチは、従来型の脆弱性管理を上回り、組織に次のようなメリットをもたらします。

プロアクティブなセキュリティのために脆弱性を継続的に監視します。
実際に悪用されているエクスポージャーを特定します。
効果的な修復作業を可能にします。
リスクを低減します。
組織のコンプライアンス達成を支援します。

リスクベースの脆弱性管理は多くの領域をカバーしますが、組織が安全を維持するために必要なサイバーセキュリティへの包括的なアプローチまでは提供できません。そこで重要になるのがエクスポージャー管理です。

エクスポージャー管理とは何か？

エクスポージャー管理とは、攻撃対象領域全体にわたる包括的な可視性を提供する、進化し続けるサイバーセキュリティの取り組みです。リスクベースの優先順位付けや修復などを含め、組織がどこでエクスポージャーを抱えている可能性があるかを、IT部門とセキュリティ部門が正確に把握できるようにします。エクスポージャー管理は、組織が自ら定めたリスク許容度を維持することに重点を置きます。そのため、次の4つの段階で構成されます。

リスクベースの脆弱性管理と同様に、エクスポージャー管理は、現実世界のリスクに基づいて、どの脆弱性やエクスポージャーに最初に対処すべきかを優先順位付けするのに役立ちます。さらに、各組織のビジネスに最も関連性の高い要素も考慮します。このサイバーセキュリティアプローチにより、最もリスクの高いエクスポージャーを、攻撃者に悪用される前にプロアクティブに修復できます。

エクスポージャー管理と脆弱性管理：違いは何か？

エクスポージャー管理は、従来の脆弱性管理の先にある次の進化形です。脆弱性管理が主にサーバーやエンドポイントの弱点を特定し対処することに重点を置くのに対し、エクスポージャー管理は攻撃対象領域全体にわたる完全な可視性を提供することで、その範囲を拡張します。

主な違いには、次のようなものがあります。

エクスポージャー管理は、より新しい種類の資産を対象に設計されています：現代のIT環境はますます複雑化しており、Software-as-a-Service（SaaS）アプリケーション、IoTデバイス、クラウドインフラなどの資産も含まれるようになっています。エクスポージャー管理は、こうした新しい種類の資産を考慮するように設計されており、IT部門とセキュリティ部門が組織内のあらゆる場所に存在するリスクを特定できるようにします。これにより、エクスポージャー管理は、すべての潜在的な侵入口を包括的に理解できるようにします。その結果、組織はこれまで以上に効果的にリスクを管理し、低減できます。
エクスポージャー管理は現実を踏まえ、リスク許容度に基づくアプローチを推進します：繰り返しになりますが、脆弱性管理は脆弱性へのパッチ適用を中心としています。リスクベースの脆弱性管理はリスクの優先順位付けと修復のオーケストレーションを提供しますが、組織がすべての脆弱性にパッチを適用することは現実的ではないという事実までは十分に考慮していません。リスク許容度とは、組織がどれだけのリスクを受け入れる意思があるかを自ら定めた指標です。これははるかに現実的なアプローチであり、チーム全体で成功を一貫して測定するための共通KPIを達成できるよう、組織全体を結束させます。
エクスポージャー管理はCVEとCVSSを超えます：脆弱性管理は主に共通脆弱性識別子（CVE）に重点を置きます。CVEはほとんどの組織にとって重要な対象ですが、脅威アクターが組織に被害を与えるために利用できる要因はそれだけではありません。ハッカーは、脆弱性管理ではカバーされない次のようなエクスポージャーも利用して、組織に侵入する可能性があります。
設定ミス。
アプリケーションセキュリティの問題。
ITシステムポリシー。
特権アクセス制御。

包括的なアプローチに立ち返ると、エクスポージャー管理はこうした最新の資産をすべてカバーします。さらに、脆弱性管理は修復の優先順位付けにおいて、共通脆弱性評価システム（CVSS）に大きく依存しています。CVSSは重大度を測る有効な指標ではありますが、リスクを調整した視点としては十分とはいえません。

リスクは、脆弱性が悪用されているか、ランサムウェアやマルウェアとの関連があるか、現在注目を集めているかといった要素を含むため、念頭に置くべき重要な要因です。リスクを考慮しないと、CVSSによって誤った緊急性が生まれ、IT部門とセキュリティ部門は実際には緊急性の高くない脆弱性に時間とリソースを浪費してしまいます。

組織を保護する方法

ここまで、エクスポージャー管理と脆弱性管理の違いを見てきました。次は、エクスポージャー管理がもたらす利点を活用する段階です。Ivantiのエクスポージャー管理ポートフォリオが、IT部門とセキュリティ部門をどのように強化できるかをご覧ください。

DLLハイジャック：リスク、実例、攻撃を防ぐ方法

Wed, 17 Dec 2025 14:00:02 Z

最近、CVE-2025-56383（2025年9月26日公開）をめぐって注目が集まっています。これはNotepad++ v8.8.3におけるハイジャックの脆弱性で、DLLファイルが差し替えられることで悪意のあるコードが実行される可能性があります。

このCVEについては複数の関係者から異議が唱えられていますが、ここではその是非についてコメントするものではありません。本稿では、DLLハイジャックに焦点を当て、組織に及ぼす現実的な脅威について解説します。DLLハイジャックとは何か、そしてDLLを安全に保つために取れる対策を見ていきましょう。

DLLハイジャックとは何か、どのように発生するのか

DLLハイジャック（DLLプリロード攻撃とも呼ばれます）とは、Windowsアプリケーション内の正規で信頼されたダイナミックリンクライブラリ（DLL）ファイルが、悪意のあるファイルに置き換えられるセキュリティ上の脆弱性です。

この手法は、複数のプログラムで使用されるコードやデータを含むDLLファイルをアプリケーションが読み込む仕組みを悪用します。悪意のあるDLLを読み込ませることで、脅威アクターは正規アプリケーションと同じ権限で独自のコードを実行でき、権限昇格、永続化、防御回避につながる可能性があります。

プログラムの起動時には、特定の機能を実行するために、通常は信頼されたシステムディレクトリから複数のDLLを読み込む必要があります。しかし、アプリケーションがDLLの検索場所を適切に管理していない場合、安全でない場所や予測可能な場所（現在の作業ディレクトリやネットワーク共有など）から悪意のあるDLLを読み込んでしまう可能性があります。これは、アプリケーションがDLLへのフルパスを指定していない場合や、攻撃者がアクセスまたは変更できるディレクトリ内でDLLを検索する場合に発生し得ます。

この種の攻撃は新しいものではありませんが、手法がシンプルであるため、現在も有効です。また、この特定の問題はWindowsアプリケーションに関するものですが、同様の脆弱性は他のオペレーティングシステム（共有ライブラリの動的読み込みを使用するLinuxやmacOSなど）にも影響する可能性がある点に注意が必要です。

DLLハイジャックは、次のような複数のセキュリティリスクをもたらします。

データ窃取：悪意のあるDLLは、パスワードや個人情報などの機密データを傍受し、盗み出す可能性があります。
システム侵害：攻撃者がシステムを制御し、さらなる攻撃や追加のマルウェアのインストールにつながる可能性があります。
マルウェア：悪意のあるDLLがマルウェア拡散の経路となり、システムやネットワークの他の部分に感染を広げる可能性があります。

DLLはさまざまな方法でハイジャックされる可能性があります。代表的な手法は次のとおりです。

安全でないDLL検索順序：攻撃者は、正規DLLの場所よりも先に検索されるディレクトリに悪意のあるDLLを配置します。
相対パスの操作：アプリケーションが相対パスを使用する場合に、悪意のあるDLLが読み込まれます。
DLLリダイレクト：パス操作などの手法により、DLLの読み込みプロセスをリダイレクトします。
脆弱な権限設定：攻撃者は、権限設定が不十分なディレクトリ内で正規DLLを悪意のあるDLLに置き換えます。
ファントムDLLハイジャック：攻撃者は、存在しないDLLを読み込もうとするアプリケーションを悪用し、検索対象のディレクトリに同名の悪意のあるDLLを配置します。

こうした潜在的な脆弱性は、この種の攻撃を防ぐうえで、安全なコーディング手法とディレクトリ権限管理がいかに重要であるかを示しています。

DLLハイジャックを防ぎ、DLLを安全に保護する方法

DLLハイジャックは依然として脅威ですが、より安全でセキュアなIT環境を実現するために、リスクを軽減できるベストプラクティスを導入できます。

安全なDLL読み込み：

フルパスを使用する：DLLを読み込む際は、必ずDLLへのフルパスを指定します。これにより、アプリケーションは安全でないディレクトリではなく、信頼された場所からDLLを読み込むようになります。
安全な検索パスを設定する：WindowsのSetDllDirectory関数を使用して、信頼されたディレクトリを検索パスに追加し、安全でないディレクトリを除外します。これにより、アプリケーションが想定外の場所からDLLを読み込むことを防ぎやすくなります。

ファイル整合性チェック：

デジタル署名：DLLがデジタル署名されていることを確認し、DLLを読み込む前に署名を検証します。これにより、DLLが改ざんされていないことを確認しやすくなります。
ハッシュ検証：暗号学的ハッシュ関数を使用して、DLLファイルの整合性を検証します。DLLのハッシュが期待値と一致しない場合、そのファイルは変更されている可能性があります。

ユーザー権限：

最小権限の原則：アプリケーションは必要最小限の権限で実行します。これにより、悪意のあるコードが有害な操作を実行するために使用できる権限が少なくなるため、DLLハイジャックによる潜在的な被害を抑えられます。
ユーザーアカウント制御（UAC）：WindowsシステムでUACを有効にし、昇格された権限でアプリケーションを実行する前にユーザーへ許可を求めるようにします。これにより、システムファイルへの不正な変更を防ぎやすくなります。

アプリケーション制御と権限管理：

既知で信頼されたアプリケーション：アプリケーション制御により、既知で信頼されたアプリケーションのみを起動可能にし、未承認アプリケーションが持ち込まれるリスクを排除します。
権限制御：効果的な権限管理は、DLLハイジャックを防ぐうえで重要です。アプリケーションが起動に必要な適切な権利と権限を持つようにすることで、未承認ユーザーが悪意のあるファイルを持ち込む能力を制限できます。この制御は重要な障壁として機能し、攻撃者がDLL検索メカニズムを悪用するために必要なアクセスを制限することで、環境のセキュリティを強化します。

セキュリティソフトウェア：

アンチウイルスおよびアンチマルウェア：信頼できるアンチウイルスおよびアンチマルウェアソフトウェアを使用して、悪意のあるDLLの読み込みを検知・防止します。これらのツールは、既知の悪意のあるファイルや挙動をスキャンできます。
侵入検知システム（IDS）：IDSを導入し、DLLファイルへの予期しない変更や、安全でない場所からDLLを読み込もうとする試みなど、通常とは異なるアクティビティを監視します。

パッチ管理：

ソフトウェアを最新の状態に保つ：アプリケーションとオペレーティングシステムを最新のセキュリティパッチで定期的に更新します。多くのDLLハイジャック脆弱性は更新によって修正されるため、最新の状態を維持することで既知の脅威から保護しやすくなります。
パッチ適用の自動化：すべてのシステムを手動介入なしで最新の状態に保つには、自動パッチ管理ツールを使用します。これにより、攻撃者が既知の脆弱性（DLLハイジャックに利用され得るものを含む）を悪用できる機会を減らせます。このプロアクティブなアプローチは、アプリケーションとオペレーティングシステムの整合性維持に役立ち、攻撃者が悪意のあるDLLを挿入することをはるかに困難にします。

これらのベストプラクティスを導入することで、DLLハイジャックのリスクを大幅に低減し、アプリケーションとシステム全体のセキュリティを強化できます。

適切なツールと対策を組み合わせてDLLハイジャックを防ぐ

DLLハイジャックは長年にわたって継続的に使われてきた攻撃手法であり、今なお有効であることから、今後も組織にとって課題であり続けるでしょう。

上記のベストプラクティスに、Ivanti Neurons for App Controlのような実績あるソリューションを組み合わせることで、組織を将来の脅威に備えさせ、DLLの保護を支援できます。Trusted Ownershipのような機能は、項目の所有者が承認済みの信頼できる所有者リストと一致することを確認し、ハイジャックされたDLLの実行を検知して拒否します。

また、アプリを最新の状態に保ち、既知の脆弱性への露出を抑えましょう。Ivanti Neurons for Patch Managementでパッチ適用を自動化することで、人為的ミスのリスクを排除し、システムが自動的に更新され保護されるようにします。

ITAM：サイバー脅威防御における想定外の第一線

Tue, 16 Dec 2025 14:00:02 Z

サイバーセキュリティの話題になると、多くの人はファイアウォール、侵入検知システム、最先端のエンドポイント保護を思い浮かべます。しかし、こうした高度な防御の土台には、不可欠でありながら見過ごされがちな基盤があります。それが、堅牢なIT資産管理（ITAM）です。

危険性が高まるデジタル環境の中で中堅企業や大企業を導くCIOにとって、ITAMは運用上の明確性をもたらすだけでなく、サイバー脅威防御の強力な第一線となります。

以下では、包括的なITAMが組織のテクノロジー環境に対する重要な可視性をどのように提供し、進化するサイバー脅威に対する防御を強化し、規制コンプライアンスを支援し、セキュリティ運用を加速するのかを見ていきます。ITAMを戦略の中核に据えることで、高額なコストを伴う侵害を防ぎ、真のサイバーレジリエンスを構築する方法をご確認ください。

世界のサイバー攻撃は前年比で30%増加し、ランサムウェア攻撃は現在、1日平均20～25件の重大インシデントに達しています。

ITAMが重要な理由：サイバーセキュリティの課題は不十分な可視性から始まる

サイバー脅威はほぼ例外なく、組織が把握できていない弱点を悪用します。シャドーIT、旧式のデバイス、不正なソフトウェア、未承認のアクセスポイントは、従来のセキュリティでは見落とされがちな目に見えない脆弱性です。包括的な資産インベントリは、単なる管理の徹底ではありません。効果的なサイバーリスク管理の出発点です。

組織の90%が強力な検知能力を有していると主張しているにもかかわらず、57%は完全な可視性の欠如により重大なセキュリティインシデントを経験しています。

次の点を考えてみてください。2023年データ侵害調査レポートで、Verizonは侵入インシデントの相当な割合が放置された資産に起因していると指摘しました。忘れられていたためにサーバーにパッチが適用されず、エンドポイントはライフサイクルを可視化できないままプロビジョニングされる、といった状況です。

ここでITAMは、非常に価値の高い早期警戒システムとして機能します。すべてのハードウェア、ソフトウェア、クラウド資産をリアルタイムで継続的に更新されるマップとして提供することで、ITリーダーは攻撃者より先にリスクを発見できます。

サイバーレジリエンスにおけるITAMのメリット

以下では、堅牢なITAMがもたらすさまざまなメリットが、組織のセキュリティ体制をどのように強化するのかを見ていきます。

ライフサイクル管理により弱点を排除

資産がリスクをもたらすのは、取得時だけではありません。オンボーディング、保守、更新から最終的な廃棄に至るライフサイクル全体には、管理不備が発生しやすく、サイバー攻撃者の侵入口となり得る機会が数多く存在します。ベンダーサポートのない旧式システム、ミッションクリティカルなアプリを稼働し続けるサポート終了ソフトウェア、データ消去なしで廃棄されたデバイスなどは、複雑な環境でよく見られます。

組織の45%は、自信を持てておらず、使用中のすべてのアプリケーションを把握できていないため、攻撃者に悪用される死角が生じています。

堅牢なITAMにより、すべての資産が追跡され、定期的に評価され、安全に廃棄されます。これにより、偶発的な露出だけでなく、レガシーインフラを標的とする高度な攻撃も防ぐことができます。

規制コンプライアンスにより統制を証明し、罰則を回避

CIOは、IT資産に対する統制を実証することを求める規制環境に、ますます直面しています。NIST、ISO 27001、GDPRなどのフレームワークはいずれも、機密データと重要インフラを効果的に管理するための前提条件として、資産の可視性を重視しています。成熟したITAMの実践はこれらの要件に直接対応し、監査や規制当局からの照会に必要な文書化と証明可能な監督を提供します。

侵害の80%以上は攻撃対象領域管理のギャップに関連しており、その背景には脆弱なインターネット公開資産や不十分な資産インベントリ運用があります。

たとえばGDPRでは、個人データを処理する脆弱な資産を迅速に特定して修正できることは、優れたセキュリティ対策であるだけでなく、法的な必要条件でもあります。

ITAMとセキュリティの連携：単なるインベントリ追跡を超えて

真のITAMは、リストを管理するだけにとどまりません。統合された資産管理は、コンテキストをセキュリティ運用ツールに直接提供します。脆弱性スキャナーは、露出を検出するために正確なインベントリに依存しています。インシデント対応では、どのシステムが関係しているかを正確に把握することが不可欠です。セキュリティポリシーの適用には、資産の役割と関係性を明確に理解することが求められます。

一例として、ある金融機関ではITAMデータをSIEMプラットフォームに統合したことで、侵害発生時にセキュリティチームが影響を受けた資産を即座に特定して隔離できるようになり、インシデント対応時間が半減しました。この価値は測定可能であり、再現性があります。

レジリエントなサイバー防御には堅牢な資産管理が不可欠

IT資産管理は、単なる運用上の衛生管理ではありません。プロアクティブでレジリエントなサイバーセキュリティ戦略に不可欠な要素です。CIOにとって、堅牢なITAMソリューションへの投資は、表面的なセキュリティと真のリスク低減を分ける要因となり得ます。

当社のITAMソリューションが、組織のセキュリティ体制を基盤からどのように強化できるかをご確認になりたい場合は、今すぐ当社チームにお問い合わせいただき、真のサイバーレジリエンス構築に向けた第一歩を踏み出してください。

シャドーAIは職場のセキュリティ態勢を静かに変えつつあるのか？

Mon, 15 Dec 2025 14:00:01 Z

職場におけるAIツールの利用は急速に拡大しています。かつては高度に専門化された技術職の領域だったものが、今では一般的になっています。Ivantiの2025年版Technology at Workレポートによると、オフィスワーカーの42%がChatGPTなどの生成AIツールを職場で使用していると回答しており、前年から16ポイント増加しています。

問題は、こうした生産性向上が非公式な形で起きていることです。生成AIツールを使用していると回答した人のうち46%は、使用しているツールの一部または全部が雇用主から提供されたものではないと述べています。また、3人に1人の従業員は、AI生産性ツールの利用を雇用主に知らせていません。

生成AIツールは生産性を大きく高める可能性があります。しかし、特に雇用主の監督なしに使用される場合、データセキュリティ上のリスクにもなります。

シャドーAIとは

承認されていないAIの利用は、シャドーIT（IT部門の承認なしにテクノロジーを使用すること）の一種にほかなりません。

シャドーAIがもたらすリスクは、他のシャドーITリスクと似ていますが、そこに懸念がさらに加わります。それは、生成AIが効果を発揮するために必要とする膨大な量の専有データです。無料の生成AIツール（一部の有料ツールも同様）は、モデルのトレーニングに組織のデータや従業員の検索内容を使用する場合があり、データ漏えいやコンプライアンス違反のリスクを増幅させます。

共有されたChatGPTの会話が検索エンジンにクロール可能だったという最近の発覚（OpenAIはすぐに方針を変更しました）は、適切な管理がなければ、第三者が望ましくない形でデータを使用し得ることへの警鐘となるはずです。ChatGPTを含む一部の無料ツールはセキュリティポリシーに準拠するよう設定できますが、従業員がそれらをひそかに使用している場合、それは不可能です。

ChatGPTのような無料ツールだけがシャドーAIのリスクではありません。意外な発生源は、実は既存のソフトウェアです。AI機能の追加が急速に進む中、以前はIT部門が承認していたツールが新たなリスクをもたらす可能性があります。情報セキュリティチームがこれらの新機能を把握し評価していなければ、実質的にサードパーティリスク管理プロセスを迂回してしまうことになります。

AIにリスク優先アプローチが不可欠な理由

生成AIであれ他のツールであれ、シャドーITは、ツールをテストしたり業務を遂行したりするための明確で合理的な方法がないことから生じます。AIがなくなることはない以上、企業は導入に先回りして取り組む必要があります。ツールを禁止しても、従業員が生産性を高め、仕事をしやすくするために使おうとすることを止められるわけではないからです。

私は業務時間の大半を、AIツールがもたらすリスクを含め、リスク評価に費やしています。多くの場合、ビジネスを改善する機会に関連してリスクを評価する必要があります。今回で言えば、従業員の生産性向上と、従業員満足度やより戦略的なプロジェクトに取り組む時間の確保といった二次的な影響です。

要するに、私たちが問うべきなのは、従業員が求めているツールを導入し、そのメリットを得ながら、リスクを許容可能なレベルに抑える方法はあるのか、ということです。

そこで重要になるのが、リスク優先アプローチです。AI導入におけるリスク優先アプローチでは、AIに入力する必要があるデータと、第三者がそのデータをどのように扱うかに焦点を当てます。このアプローチはベンダーリスク管理に似ており、組織は確立された手法やプロセスを活用しつつ、AIに特化した質問に合わせて調整できます。

確認すべき主な質問は次のとおりです。

私たちのデータはAIモデルのトレーニングに使用されるのか。
私たちのデータはどのくらいの期間保持されるのか。
私たちのデータが公開されるリスクを低減するために、どのような保護策があるのか。
AIを使用して生成された知的財産の権利は誰に帰属するのか。

AIの無秩序な拡散を最小限に抑えることは、この取り組みにおいて極めて重要です。専門化されたAIツールを導入するベンダーが増え、さらにベンダーを追加してそのAIツールに自社データへのアクセスを許可するほど、リスクは高まります。これは、コストや契約の変更なしに突然AIを導入する既存ツールにも当てはまり、AIツールの正確なインベントリを維持することを難しくします。

IvantiにおけるAIガバナンスフレームワークの導入

Ivantiでは、従業員エンゲージメントを出発点かつ到達点とするリスク優先アプローチで、シャドーAIに対処しています。

AI利用を見える化する

シャドーAIを推奨することは決してありませんが、それを使用している従業員は、AIをワークフローに統合する方法について共有すべき貴重な知見を持っています。そのため、すべてのAI利用を禁止するのではなく、従業員が業務で使用するAIツールを申請する明確な手段を確保し、オープンな対話の機会を定期的に設ける必要があります。

オープンな対話を促進することで、従業員は自分たちの成功に役立つツールについて安心して話し合えるようになり、最終的にはそれらのツール（または同等のツール）を安全に使用するようになります。これは、制限を回避しようとするのではなく、従業員が適切なガバナンスの策定に積極的なパートナーとして関わる機会になります。

AIの実装と導入に対する慎重なアプローチ

ツールが承認されたら、適切に実装されていること、そしてどのデータへのアクセスを許可したのかを把握していることが重要です。これは、生成AIツールが組織にもたらすデータガバナンスとセキュリティリスクを考えると、特に重要です。データガバナンスの観点からAIを見ることで、AIリスクの多くの側面に対処しやすくなります。

Ivantiでは慎重なアプローチを採用しています。専任チームを置き、他のチームと連携して生成AIツールの管理されたテストを実施します。その後、フィードバックループを確立し、混乱を避けるため導入を段階的に進めます。

AIツールのフィードバックループを構築する

継続的に確認すべきことは次のとおりです。

Ivantiの従業員はAIをどのように使用しているのか。
そのAIを有用だと感じているのか。
どのようなフィードバックがあるのか。
そのツールをどのように改善できるのか。

こうした継続的な対話により、従業員の生産性ニーズを満たしながら、責任ある形でAIを使用できるようになります。

AIブームに安易に乗ることが目的ではありません。重要なのは、それがビジネスにとって、そして利用する人々にとって価値があるかを見極めることです。シャドーAIは一人の生産性を高めます。しかし、その生産性を組織全体に広げることができれば、会社全体にとって意味のある改善につながります。

シャドーAIに先回りして対処する

ここで一貫しているテーマは、AI、特にシャドーAIが新たで懸念すべきリスクをもたらす一方で、今後も存在し続けるということです。見えないところでAIを使用している従業員に悪意があるわけではありません。むしろ、たとえ方法が適切でないとしても、ビジネスに貢献しようとしているのです。

先回りしたAI導入へのリスク優先アプローチは、この現実を認識するものです。回避を促すだけの事後的な禁止ではなく、従業員がAIで解決しようとしている課題を理解するために関わり、当社のセキュリティおよびデータプライバシー要件を満たす安全な選択肢を提供する必要があります。

エンタープライズセキュリティにおいて SELinux が重要な理由

Thu, 23 Oct 2025 14:03:35 Z

サイバーセキュリティ製品を評価する際、ダッシュボード、アラート、連携機能といった表面的な機能に目が向きがちです。しかし本当の強さは、多くの場合さらに深い、アーキテクチャそのものにあります。厳格なセキュリティ設計原則を体現する組み込み機能の一つが、Security-Enhanced Linux（SELinux）です。

SELinux は、もともと米国国家安全保障局（NSA）によって開発され、オープンソースコミュニティに公開された、Linux カーネルに組み込まれた強制アクセス制御（MAC）フレームワークです。アプリケーション、サービス、ユーザーがシステムリソースとどのように相互作用するかを管理する、ポリシー主導の厳格なルールを適用し、権限昇格、ラテラルムーブメント、ゼロデイエクスプロイトに対する強力な防御となります。

評価しているサイバーセキュリティ製品に SELinux が含まれている場合、特に強制モードで動作している場合は、アーキテクチャの成熟度とプロアクティブな脅威封じ込めを示す有力な指標となります。

SELinux の違いと優位性

SELinux はすべてのプロセスとファイルにセキュリティコンテキストのラベルを付与し、事前定義されたポリシーを使用して、それらがどのように相互作用するかを制御します。ユーザー権限に依存する従来のアクセス制御とは異なり、SELinux は root（管理者）権限を持つユーザーやプロセスを含め、すべてのユーザーとプロセスにセキュリティポリシーを適用します。

これは非常に重要です。攻撃者が root アクセスを悪用してラテラルムーブメントを行ったり、データを持ち出したり、セキュリティ制御を無効化したりすることを防ぐためです。SELinux は、root の「万能権限」のような立場を実質的に取り除き、権限ではなくポリシーによって定義されたセキュリティ境界を適用します。

つまり、攻撃者が特権（つまり root）アクセスを取得した場合でも、SELinux は事前設定されたポリシーから逸脱する不正な操作の実行を防ぐことができます。このレベルのセキュリティは検知にとどまらず、オペレーティングシステムレベルでの防止までを包含します。

SELinux の仕組み

SELinux は複数のモードで動作します。

無効: アクティブではなく、セキュリティの強制は行われません。
許容: 違反をログに記録しますがブロックはしません。テストに有用です。
強制: ポリシーに基づいて不正な操作を能動的にブロックします。
厳格な強制: デフォルトで適用される厳格なポリシーと組み合わせた強制モードを指します。

SELinux を厳格な強制モードで実行する製品は、システムのプロセスとリソースをリアルタイムで保護します。攻撃対象領域が最小化されるため、攻撃者がシステム内を移動することは大幅に困難になります。すべてのユーザー、サービス、デーモンは、強制的な最小権限アクセス制御の対象となります。厳格な強制は通常、政府、金融、防衛などの高セキュリティ環境で使用されます。こうした環境では、デフォルトで信頼されるプロセスはなく、すべての相互作用がポリシーによって明示的に許可される必要があります。

お客様自身が SELinux を設定することはありませんが、Ivanti のようなベンダーが製品の強化に SELinux をどのように活用しているかを理解しておくことは有益です。

1. 許容モードから開始: まず、何もブロックせずに SELinux ポリシー下でのシステムの挙動を観察します。

2. 広範なテスト: 違反をログに記録し、正当な操作を特定し、誤検知を避けるためにポリシーを改善します。

3. カスタムポリシーの開発: ポリシーは製品のアーキテクチャとユースケースに合わせて調整されます。

4. 強制モードでのラボ検証: リリース前に、実環境を想定した条件下で、SELinux を強制モードおよび厳格な強制モードでテストします。

このプロセスにより、SELinux は機能を妨げることなくセキュリティを強化し、ユーザーはパフォーマンスを犠牲にせずに最適な保護を得られます。さらに、上記のプロセスはリリースごとに実施されます。つまり、ソフトウェアが新しいバージョンへ進化するたびに、SELinux ポリシーのテスト、調整、反復をソフトウェア製品の新バージョンごとに行う必要があります。

このプロセスには時間がかかり、適切に実行するには相当な開発リソースが必要です。SELinux を厳格な強制で構成するのは、セキュリティに最も真摯に取り組み、先進的な姿勢を持つベンダーだけです。

実例：Oracle Linux の導入

Oracle Linux は SELinux の強制モードをサポートしており、Oracle データベース環境や Oracle Cloud Infrastructure 上のワークロードを保護するために広く使用されています。SELinux は、複雑なエンタープライズ導入環境においても、プロセスの分離、最小権限の適用、機密データの不正アクセスからの保護を支援します。

購入を検討する側にとって、これは SELinux が有効化された Oracle Linux 上に構築された製品（Ivanti Connect Secure を含む）が、多くの種類の攻撃に対してすでに強化されていることを意味します。（詳細については Oracle 公式ガイドを参照してください。）

ビジネス価値をもたらすセキュリティテクノロジー

SELinux がサイバーセキュリティソリューションに組み込まれている場合、そのテクノロジーはエンタープライズの優先事項に合致する戦略的メリットをもたらします。

監査とコンプライアンス対応: SELinux は、成功したか拒否されたかにかかわらず、すべてのアクセス試行をログに記録し、充実した監査証跡を作成します。SELinux の強制適用と監査証跡は、CIS Level-1/2 Hardening、STIG、NIST-800、およびシステム強化を求めるその他の規制要件への対応に役立ちます。
きめ細かなアクセス制御: プロセスレベルできめ細かなルールが適用され、root ユーザーであってもアクセスが制限されます。これにより、権限昇格や内部脅威のリスクが低減されます。これは、機密データや複雑なユーザーロールを扱う環境では特に重要です。
攻撃対象領域の削減: SELinux はプロセスを分離し、最小権限アクセスを適用することで、システム内のラテラルムーブメントを防ぎます。この封じ込め戦略は、侵害が発生した場合の被害範囲を限定するうえで重要です。SELinux は OS レベルで不正な操作をブロックするため、ゼロデイを含む脆弱性を攻撃者が悪用することを困難にします。
エンタープライズグレードの保証: Ivanti のように製品で SELinux を使用するベンダーは、セキュリティのベストプラクティスに対する強いコミットメントを示しています。このアプローチはリスク管理を支援し、信頼性を高め、競争の激しい市場でソリューションを明確に差別化します。
運用の安定性: ポリシーが適切に調整されていれば、SELinux はバックグラウンドで静かに動作し、パフォーマンスに影響を与えることなくセキュリティを適用します。これは、稼働時間が重要なミッションクリティカルな環境に最適です。

SELinux の価値に関するまとめ

サイバーセキュリティ製品を評価する購入者は、表面的な機能にとどまらず、システムの中核で何が保護しているのかを確認する必要があります。SELinux は、内部で静かに実効性のある保護を適用するテクノロジーの一つであり、不正な操作（特権ユーザーによるものを含む）をブロックし、脅威が拡大する前に封じ込めます。

製品に SELinux が搭載されていることは、強化されたアーキテクチャ、プロアクティブな脅威封じ込め、そしてシステムの完全性を真剣に重視するベンダーであることを示します。お客様自身が設定することはありませんが、エクスプロイトの試みが展開に至らず阻止されるたびに、その恩恵を受けることになります。

セキュリティに対する Ivanti のコミットメント

Ivanti は、2024 年に CISA の「Secure by Design」誓約に最初期に署名した企業の一つです。この取り組みの一環として、Ivanti は Connect Secure 製品の強化、オペレーティングシステムの最新化、開発のあらゆるレイヤーへのセキュリティの組み込みに大きく投資してきました。

Ivanti の開発理念の中核にあるのが Secure Software Development Lifecycle（SSDLC）であり、Secure Software Design の 7 つの重要要素である Security as Code（SaC）、Secure by Default、Least Privilege、Separation of Duties（SoD）、Minimize Attack Surface Area（ASA）、Complete Mediation、Failing Securely を実現します。さらに Ivanti は、OWASP Application Security Verification Standards（ASVS）への準拠を義務付ける、独自の厳格な Secure Application Development Standard にも従っています。これらの厳格なフレームワークにより、すべての製品機能がセキュリティを主要な考慮事項として設計・実装され、お客様に業界最高水準のベンチマークを満たすソリューションを提供できます。

プロアクティブなサイバーセキュリティとは？組織を守るための対策

Mon, 04 Aug 2025 19:26:10 Z

Ivanti の 2025 年版サイバーセキュリティ状況レポートでは、まったく意外ではない事実が明らかになりました。それは、当社が調査したすべての脅威ベクトルと脆弱性において、組織が大きな準備態勢のギャップを報告しているということです。つまり、認識している脅威レベルと準備態勢の度合いとの間にギャップがあるということです。

セキュリティチームが攻撃に迅速に対応し、復旧できるようレジリエンスの構築にリソースを割くのは当然ですが、こうした準備態勢のギャップを埋めるには、プロアクティブなサイバーセキュリティ対策が必要です。

事後対応型とプロアクティブなサイバーセキュリティの違いとは？

プロアクティブなサイバーセキュリティとは、サイバー攻撃が発生する前にセキュリティ態勢を強化し、攻撃対象領域を縮小するために行う取り組みを指します。一方、事後対応型のサイバーセキュリティは、すでにシステムに侵入した攻撃を中断し、封じ込め、発生し得る被害を最小限に抑えるものです。

この 2 つは決して相反するものではありません。プロアクティブなセキュリティはリスクを低減しますが、完全に排除するわけではありません。「事後対応型」という言葉にはやや否定的な響きがあるかもしれませんが、リスクにさらされる範囲をどれだけ絞り込んだとしても、攻撃に対応できる能力は極めて重要です。

プロアクティブなサイバーセキュリティ対策の例

プロアクティブなセキュリティは、設計図というよりも考え方です。リスクが現実化するはるか前からエクスポージャーを最小限に抑えるための手を打つことが、セキュリティにかける時間とリソースの最も有効な使い方である、という考え方です。

とはいえ、その考え方を実践するために構築できる具体的な機能があります。たとえば、脆弱性スキャン、攻撃対象領域管理、脆弱性管理、エクスポージャー検証、パッチ管理、構成管理、ユーザー教育などです。ただし、これらに限定されるわけではありません。

攻撃対象領域管理

攻撃対象領域管理の目的は、ハッカーが組織の IT 環境にアクセスするために利用し得る、デジタル、物理、人に関するすべての侵入口を把握することです。

この攻撃対象領域には、既知および未知のデバイスが含まれますが、環境はデバイスだけにとどまりません。企業に関係する人々が使用するアプリケーション、ソフトウェア、ソーシャルメディアアカウント、その他のデジタル空間や資産も含まれます。

関連情報：攻撃対象領域チェックリスト

脆弱性スキャン

脆弱性スキャンは、その名のとおりです。専用のスキャナーがネットワークや IT 資産を評価して悪用され得る脆弱性を検出し、セキュリティチームが対応できるよう通知します。既知の脆弱性は数千にのぼり、日々新たに発見されているため、脆弱性スキャンは自動化されている場合に最も効果を発揮します。

外部脆弱性スキャンでは、ネットワークを外部から評価し、ハッカーがネットワークに侵入する可能性のある経路を特定しようとします。内部スキャンでは、すでにネットワークに侵入した人物の視点に立ち、内部から悪用できる脆弱性を洗い出します。

脆弱性管理

脆弱性スキャンと攻撃対象領域管理は、より長期的で包括的なサイクルである脆弱性管理に情報を提供します。脆弱性管理は、脆弱性を特定し、一定の優先度レベルに分類したうえで、チームが最適な解決方法を判断する継続的なプロセスです。

脆弱性管理の一般的なアプローチは、深刻度に基づいて優先順位を付けることですが、この方法では一部の脆弱性が過度に重視される一方で、別の脆弱性が見落とされる可能性があります。脅威のコンテキスト、つまり「この脆弱性は現在悪用されているか？」と、リスクのコンテキスト、つまり「この脆弱性が悪用された場合、自社にどれほどの悪影響があるか？」を重ね合わせることで、真の優先度がより明確に見えてきます。

エクスポージャー検証

エクスポージャー検証は、攻撃シナリオを実行することで、攻撃の実行可能性と対策の強度をテストします。このアプローチはオフェンシブセキュリティとも呼ばれます。最も一般的な方法は、ペネトレーションテストとレッドチーミングです。

ペネトレーションテスト（またはペンテスト）では、倫理的ハッカーがシステムへの侵入を試み、うまく機能している点やさらなる改善が必要な領域についてフィードバックを提供します。ペンテストは、自動化ツールを使用して実施することもできます。
レッドチーミングは、ペンテストと同様に、倫理的ハッカーに計画的なサイバー攻撃を実施させ、防御を改善できる箇所を見つけることを目的とします。レッドチーミングはシナリオベースのシミュレーションであるのに対し、ペンテストはできるだけ多くの異なる脆弱性を探すものです。

敵対的エクスポージャー検証（AEV）も新たな実践手法として登場しています。これは、ソフトウェアを使用して攻撃シミュレーションを継続的かつ自律的に実行し、エクスポージャーの存在を証明するものです。

パッチ管理

攻撃対象領域管理と脆弱性スキャンによって脆弱性を特定し、脆弱性管理によって優先順位を付け、さらにエクスポージャー検証で検証した後に問題となるのは、どのように対応するかパッチ管理は、脆弱性、特にパッチが存在するソフトウェア脆弱性に対応し、それを解消する方法の 1 つです。

パッチ管理は自動化に非常に適した領域であり、特にリスクベースの脆弱性管理と組み合わせると効果的です。検出から意思決定、展開までを自動的に進めるワークフローにより、修復までの平均時間を短縮し、人的ミスを最小限に抑えられます。

パッチ管理には、重要な死角が 1 つあります。それはシャドー IT です。従業員が使用しているソフトウェアを正確に把握していなければ、パッチ適用のコンプライアンスを徹底することはできません。だからこそ、攻撃対象領域管理における検出の要素が極めて重要なのです。

構成管理

構成管理は、パッチ管理と同様に、特定された脆弱性に対応する方法です。ただしこの場合は、デバイス上で実行されるソフトウェアではなく、デバイス自体に関わる脆弱性が対象となります。構成とは、多要素認証や暗号化の強制など、デバイスレベルで設定されるプロアクティブなサイバーセキュリティ対策を指します。これらの対策はエンドユーザーが個別に適用することもできますが、最も効果的なのは、エンドポイント管理ソフトウェアを使用して適用を徹底することです。

ここでも、パッチ管理と同様に、シャドー IT が状況を複雑にします。未知の未管理デバイスが組織のセキュリティ基準に準拠しているかどうかは、確認する術がありません。そしてパッチ管理と同じく、攻撃対象領域管理における検出の要素が重要です。これまで把握されていなかったデバイスを特定して管理下に置くことで、IT チームはコンプライアンスを徹底できます。

ユーザー教育

攻撃対象領域はデジタルだけではありません。人という要素も含まれます。フィッシングやその他のソーシャルエンジニアリングは、人の脆弱性を悪用し、しばしばデジタル上のエクスポージャー（ソフトウェア脆弱性、不適切な構成など）と組み合わせて攻撃を仕掛けます。デジタル脆弱性を修復するのと同じように、従業員を教育することはエクスポージャーの最小化に役立ちます。

プロアクティブなサイバーセキュリティ対策への支持を得る

プロアクティブなサイバーセキュリティ対策への支持を得ることは、ある意味では事後対応型のサイバーセキュリティ対策よりも難しいものです。脅威がまだ現実化していないため、一時的な業務中断や、少なくとも短期的には生産性を妨げるその他の事柄など、必要なトレードオフをセキュリティ部門以外の関係者が理解しにくいからです。ユーザー教育は多忙なスケジュールから時間を割く必要があります。パッチの展開によってアプリケーションが一時的に利用できなくなったり、トラブルシューティングが必要になったりすることもあります。

こうした対策への支持を獲得し維持するために、セキュリティチームは修復によって生じ得る混乱を最小限に抑えることを意識する必要があります。たとえば、リング展開を使用する方法があります。これは、ソフトウェア更新を段階的に大きな「リング」へ展開し、各段階で問題を特定してトラブルシューティングを行ったうえで、最終的に全ユーザーベースへ拡大する手法です。

リスク評価演習も、まだ現実化していない脅威を他の関係者に実感してもらううえで有効です。自社のエクスポージャーと関連リスクのコストを客観的に測定すること、特にそのエクスポージャーを金額で定量化できる場合には、プロアクティブなセキュリティに対する渋々の受け入れと真の支持を分ける決め手になる可能性があります。

関連情報：サイバーリスクを客観的に評価する：データドリブンなリスク評価ガイド

プロアクティブなサイバーセキュリティが重要な理由

プロアクティブなサイバーセキュリティ戦略は、事後対応型セキュリティと対立するものではありません。健全な組織は、リスクが現実化する前と後の双方でリスクに対処する強固な能力を備えています。しかし、予防的な取り組みはリスク態勢を改善し、リスクが現実化する機会をより少なく、より遠ざけることにつながります。攻撃対象領域の管理、パッチ適用、適切な構成、ユーザーの意識向上といったプロアクティブなサイバーセキュリティ対策は、組織の長期的なセキュリティへの明確な投資です。

ソフトウェアサプライチェーン攻撃を無視できない理由

Mon, 05 May 2025 12:34:43 Z

Ivanti の 2025 年サイバーセキュリティステータスレポートは、ソフトウェアサプライチェーンの脅威に対する防御策を整備していると考える組織は、3 社のうち 1 社のみであることを明らかにしています。サードパーティとの依存関係を攻撃者が狙うケースが増えています。組織がサプライチェーン攻撃を放置していると、それがサイバーセキュリティにとって大きな弱点となるおそれがあります。

増加するソフトウェアサプライチェーン攻撃のリスク

攻撃対象領域は急速に広がっています。そのターゲットとなっているのは主に組織のソフトウェアサプライチェーンです。現代の企業では、社内の技術的なインフラストラクチャが多くのソフトウェアアプリケーション、ツール、依存関係に依拠しています。 BetterCloud の 2024 年レポートによると、1 つの組織につき平均 112 の SaaS アプリケーションが使用されています。そしてウェブはますます複雑になっています。各ソフトウェアアプリケーションには平均して 150 の依存関係があります（そのうち 90% は間接的な依存関係です）。これが脆弱性の大部分を占めているのです。

過去数年間でサードパーティとの依存関係を標的とする脅威アクターの数は急増しており、2024 年にはすべてのソフトウェアサプライチェーンの 75% が攻撃を報告しています。攻撃者がサプライヤーのコードに悪用できる弱点を探すようになり、ソフトウェアサプライチェーンの脅威もより巧妙化しているにもかかわらず、セキュリティチームは、すべてのソフトウェアコンポーネントを適切に検査するのに苦労することがよくあります。

Ivanti のサイバーセキュリティ調査によると、組織のリーダーの 84% がソフトウェアサプライチェーンの監視は「非常に重要」であると考えているのに対し、ほぼ半数 (48%) は、自社のサプライチェーンで最も脆弱なコンポーネントを依然として特定できていないと答えています。デューデリジェンスがこのように欠如していると、企業は大きな金銭的リスクおよびレピュテーションリスクを負うことになります。

一般的なソフトウェアサプライチェーン攻撃の種類

調査会社

ガートナーによると、ソフトウェアサプライチェーン攻撃を経験する組織は 2025 年には 45% に上ると見られています。ここでは、攻撃者が標的とする最も一般的な種類のソフトウェアサプライチェーンの脆弱性の概要を説明しましょう。

アップストリームサーバー攻撃は、最も一般的なサプライチェーン攻撃です。ハッカーが、コードリポジトリなどユーザーの「アップストリーム（上流）」に位置するシステムを侵害し、悪意のあるペイロード/マルウェアを注入する場合に発生します。このペイロードは、ソフトウェアアップデートなどを通じて「ダウンストリーム（下流）」のユーザーに拡散されます。
ミッドストリーム攻撃とは、攻撃者が元のコードベースではなく、ソフトウェア開発ツールなどの中間システムを侵害するインシデントを指します。
依存関係かく乱攻撃は、開発者またはシステムを騙して、外部ソースから侵害されたソフトウェア依存関係をダウンロードさせようとするものです。一般的な攻撃方法の中には、信頼できる内部ライブラリに似た名前を持つ、悪意のあるソフトウェアをアップロードさせるものもあり、正当な依存関係の代わりに悪意のあるバージョンがソフトウェアのビルドに組み込まれることが多くあります。
コード署名証明書攻撃は、ソフトウェアのセキュリティと信頼性を検証するためのデジタルコード署名証明書に、ハッカーが悪意のあるソフトウェアを挿入したときに発生します。これらの攻撃は、脅威アクターがソーシャルエンジニアリングやその他の戦術を使用して開発環境を侵害したときに発生します。
CI/CD インフラストラクチャ攻撃は、悪意のある目的で本物の GitHub リポジトリを複製するなど、マルウェアを導入して自動化された開発パイプラインを標的にするものです。

サプライチェーン攻撃の最近の事例

こうした種類の攻撃が実際に発生した事例は、ニュースを深掘りせずとも枚挙に暇がありません。過去数年間に世界的な注目を集めたサプライチェーン攻撃の事例をいくつかご紹介しましょう。

Okta 社へのソーシャルエンジニアリング攻撃
- 2023 年 10 月、ID およびアクセス管理を行うサービスプロバイダー Okta は、顧客サポートシステムへの重大なデータ侵害を経験しています。これは、Okta の顧客 4 名が同社の IT サービスデスクを狙ったソーシャルエンジニアリング攻撃の被害に遭ったというものです。攻撃者は、これらの管理者の資格情報を使用して複数のダウンストリーム攻撃を開始し、1Password、BeyondTrust、Cloudflare など、何千もの Okta 顧客のデータに不正アクセスを行っています。
Kaseya 社へのランサムウェア攻撃
- 2021 年 7 月のこの事件では、ハッカーが Kaseya 社のリモート管理ツールに存在する 6 つのゼロデイ脆弱性を悪用しています。これらの脆弱性を利用し、ソフトウェア更新に乗じて悪意のあるランサムウェアペイロードを送り込み、数百のマネージドサービスプロバイダー (MSP) とその顧客を感染させました。この攻撃により、世界中で約 2,000 社の業務が停止し、攻撃者が 7,000 万ドルという巨額の身代金 (最終的には支払われませんでした) を要求したことが話題になりました。
Codecov 社への CI/CD 攻撃
- 2021 年 1 月、当時 29,000 人以上の顧客が使用していた人気のコードテストツール Codecov に悪意のある人物が侵入しました。攻撃者は Codecov の Bash Uploader スクリプトに不正アクセスし、悪意のあるコードを挿入し、このコードが Codecov の顧客によって CI/CD パイプラインで使用されました。 Codecov 社は攻撃を 2021 年 4 月になるまで検知せず、報告もなされませんでした。つまり、悪意のあるこの人物は数か月にわたって顧客システムに含まれる数千の機密データにアクセスしていた可能性があります。
- これらのサプライチェーン侵害はいずれも、攻撃を受けたプロバイダーとその何千もの顧客とそれ以外の人々に、連鎖的かつ広範囲にわたる損害を引き起こしました。

サプライチェーン攻撃が及ぼす深刻な影響

ソフトウェアサプライチェーン攻撃によって生じる被害の規模は見過ごすことができません。上記の攻撃はいずれも、重大な経済的損害と評判の悪化をもたらし、多くの組織がベンダーのセキュリティに対するアプローチを再検討するきっかけとなりました。

財務への影響

調査会社

Cybersecurity Ventures では、ソフトウェアサプライチェーン攻撃によって企業が被る世界全体の年間コストについて、2025 年には 600 億ドル、 2031 年には 1,380 億ドルという驚異的な数字に達すると予測しています。これらの損失には、収益の損失、修復費用、訴訟費用、コンプライアンス違反に対する罰金の可能性など、あらゆる損失が含まれます。 2023 年のデータ侵害を受けて、Okta 社の株価は11％下落しています。 2022 年に別の大規模なデータ侵害が発生した後、影響を受けた株主が訴訟を起こし、Okta 社は 6,000 万ドルの支払いを余儀なくされました。

業務への影響

サプライチェーン攻撃では、何千もの顧客が混乱やシステムの停止に見舞われ、重要な業務が停止し、遅延が発生して他のベンダーにも影響が及ぶ可能性があります。 Kaseya 社への侵害の影響を受けた機関をいくつか見てみましょう。スウェーデンでは、その週末に食品大手小売業者が800店舗の閉鎖を余儀なくされ、国鉄も混乱に見舞われました。ニュージーランドでは、学校 11 校と 100 以上の保育園のオンライン業務がすべて停止し、問題が解決するまで紙とペンに頼らざるを得なくなりました。

風評被害

事件が公となって企業の評判が損なわれると、顧客や株主からの信頼が失われる可能性があります。企業が何年もかけて築き上げたベンダーや顧客の忠誠心を失う可能性もあるのです。 2023年3月、ハッカーがアプリケーションに悪意のあるコードを挿入したために人気のビジネスコミュニケーションソフトウェア「3CX」が侵害を受けました。60 万人以上の顧客の機密データが漏洩した可能性があったことから、数か月にわたって悪い意味でメディアの注目を集め、世論の反発を招きました。

責任の所在は？技術上の負債と共同責任

ソフトウェアサプライチェーンの脅威は頻度と深刻度を増すと予想されています。企業は明確な説明責任を確立し、サードパーティベンダーとソフトウェアサプライチェーンにもサイバーセキュリティに関する厳格なセキュリティベストプラクティスの遵守を求めることが重要になっています。

ソフトウェアセキュリティの所有者は？

現時点では、サードパーティベンダーのセキュリティを評価するための厳格で標準化されたプロセスを持たない組織が数多く存在します。さらに、多くの顧客とベンダーの間では、サードパーティ製ソフトウェアのセキュリティ管理の責任を誰が負うかについてさえコンセンサスが得られていません。

サイバーセキュリティ動向ステータスレポートでは、さまざまなレベルのサイバーセキュリティ能力を持つ組織を分析し、サイバーセキュリティの成熟度を測る「Cybersecurity Maturity Scale（成熟度スケール）」を作成しています。このスケールは、成熟度の低い組織 (レベル 1 およびレベル 2) から、より高度なサイバーセキュリティ機能を備えた組織までをカバーしています。 (レベル 4)

この調査を通じて、成熟度の低い組織ではサイバーセキュリティはベンダーのみの責任であると考えていることが分かっています。それに対して、サイバーセキュリティ対策のレベルが高い企業では、ソフトウェアベンダーと顧客の間で責任を共有することが提案されています。

ソフトウェアサプライチェーンの脅威に対する防御方法

ソフトウェアサプライチェーンのセキュリティは、包括的かつ積極的なサイバーセキュリティ戦略において重要な位置を占めます。

ソフトウェアサプライチェーンを強化し、潜在的な攻撃から防御するには、攻撃対象領域をすべてのサードパーティベンダーとコンポーネントまで拡大して組織全体の一部として扱うことが必要です。ここでは、組織がサプライチェーン攻撃をより効果的に防止し、潜在的なサプライチェーンの脅威を検出して対応する準備を整えるための重要な推奨事項について説明しましょう。

1. 厳格なベンダー管理とリスク評価

ソフトウェアベンダーと提携する前に、十分な調査を行いましょう。業界の規格に適合し、脆弱性開示ポリシーを公開しているベンダーを見つけましょう。定期的な監査、コードレビュー、ベンダーと顧客の双方による積極的な評価が、リスクを軽減するための鍵となります。

Ivanti の調査では、最高レベルのサイバーセキュリティを備える組織は、サードパーティベンダーのサイバーセキュリティを評価する際に次の点についてデューデリジェンスを実施する可能性が高いことが分かりました。

セキュリティ評価質問票（SAQ）を評価に組み込む
ISO 27001 や SOC 2 など、ベンダーのセキュリティ認証を検討する
業界固有のコンプライアンス標準を見直す
ベンダーが潜在的なセキュリティ侵害に対処するためのインシデント対応計画およびプロセスを備えていることを確認する
ソフトウェア部品表 (SBOM) を求めて、ソフトウェアで使用されているオープンソースおよびサードパーティのコンポーネントを把握する

2. すべての依存関係について継続的な監視とプロアクティブな修復を行う

自動化された脅威検出ツールおよびプロセスを採用し、すべてのソフトウェアコンポーネントを監視および評価することが重要です。特にオープンソースソフトウェアコンポーネントの依存関係は見落とされることが多く、定期的に監視・更新しないと大きな脆弱性リスクとなります。

AI と自動化ツールは、デバイス、アプリケーション、ネットワークのパフォーマンスに関するリアルタイムの分析情報を提供し、潜在的な問題を検出することができます。自己修復および自動修復ソリューションは、人間の介入を最小限に抑えるか、人間がまったく介入せずに問題を効果的に解決する方法となります。

3. サードパーティベンダーとの定期的なコミュニケーション

ソフトウェアサプライチェーンのセキュリティに対する相互責任を確立するための基礎となるのは、顧客とサードパーティベンダー間の頻繁でオープンなコミュニケーションです。セキュリティチームと IT チームは、ソフトウェアの更新、既知の脆弱性を修正するパッチ、新たなセキュリティの脅威について常に最新情報を把握しておかなければなりません。

ソフトウェアサプライチェーンのセキュリティについて詳しく知る

さらに詳しく知るには？サイバーセキュリティ動向ステータスレポートの全文をお読みください。現時点でのサイバーセキュリティの喫緊の脅威と積極的なリスク管理戦略に関する詳細な情報を把握することができます。

定量的リスク評価からアクションへと移行するには

Tue, 15 Apr 2025 13:50:58 Z

定量的リスク評価は、リスク分析に対する客観的なアプローチとなります。ただし、リスクを理解することは最初のステップにすぎません。ここでは、評価の結果を解釈し、その洞察を現実の環境で意味のある意思決定にどのように変換するかについて詳しく説明します。

（ここでは定量的リスク分析の実行方法については取り上げません。このプロセスは、Ivanti の「データ駆動型リスク評価ガイド」で詳しく説明されています。）

リスクの定量化について理解する

もとより、定量的リスク評価とは？

リスクの定量化とは？

定量的リスク評価（QRA と略されることもあります）は、サイバーセキュリティリスクの潜在的な影響と発生可能性に基づいて、リスクにドル換算の価値を割り当てるというもので、次のような疑問を投げかけます。「この脆弱性によってこの資産がリスクに晒された場合に発生する損害は？」 リスクを重大度ごとにカテゴリー分類する定性的手法とは対照的に、定量的なアプローチでは、より客観的な実像を把握します。

なぜこれが重要なのでしょうか？定性的なサイバーセキュリティリスク評価では、解釈に大きな幅があります。リスクをビジネスの尺度であるドルとセントに置き換えると、こうした曖昧さの多くが解消されます。セキュリティ責任者以外の人にとって、「高い」リスクが実際にどのような意味を持つのか理解しやすくなるのです。

より広範なサイバーセキュリティ戦略にリスク定量化を適用するには？

リスクの定量化は、リスク管理に不可欠なツールですが、最終目標ではなく、リスク軽減の意思決定を行うための基盤となるものです。

たとえば、「ベンダーが暗号化されていないクラウド通信を使用することで 150 万ドルの損害が発生する可能性がある」といったリスク露出を提示できれば、そうしたリスクに対応するための選択肢が検討できるようになります。この点については、後半でさらに詳しく説明します。

定量的リスク分析の解釈：重要な要素

定量的リスク分析では、結果を解釈するために理解しておくべき重要な要素がいくつかあります。

資産価値 (AV)： 保護されている資産が組織にとってどれだけの価値があるか。
エクスポージャー係数 (EF)： リスクが顕在化した場合に失われる、または損なわれる可能性のある資産価値の割合。
年間発生率 (ARO)： そのリスクが年間を通じて発生すると予想される頻度。（発生頻度が 1 年に 1 回未満のリスクの場合、この値は 1 未満とすることができます。）

これら 3 つの数値を使って次の計算を行います。

単一損失予測 (SLE)： リスクが現実化した場合に 1 回の脅威で失われる金銭的価値。この値は、式 資産価値 (AV) x エクスポージャー係数 (EF) から算出されます。
年間予想損失額 (ALE)： リスクが現実化した場合に 1 年間で失われる金銭的価値。この値は、式 単一損失予測 (SLE) x 年間発生率 (ARO) から算出されます。
残余年間予想損失額 (ALE)：リスク軽減策を適用した後、リスクが現実化した場合に 1 年間で失われる金銭的価値。緩和策を講じることによりエクスポージャー係数 (EF)、年間発生率 (ARO)、またはその両方が削減されますが、それ以外の計算は同じままです。

年間予想損失額 (ALE) はリスク分析における主要な結果で、リスク対策オプションを評価するために使用される最も重要な数値です。ただし、年間予想損失額 (ALE) は完璧な数字ではなく、もう 1 つの重要な要素、つまり不確実性が存在します。

資産価値 (AV)、エクスポージャー係数 (EF)、年間発生率 (ARO) はすべて推定値です。慎重な調査に基づいた非常に近い推定値であることが理想的ですが、それでも推定値であることには変わりありません。これらの推定値に対する信頼度は、通常、信頼度レベル (例: 80%) とそれに続く未知数のリストで表されます。

実践へ：リスク対応

ここまで、定量的リスク評価の解釈方法について説明しましたが、リスク分析の最終的な目的は、そのリスクに対して何をすべきかを決定することです。

すべてのリスク対応は、「避ける（回避）」、「受け入れる」、「移転する」、「軽減する」の 4 つのカテゴリーのいずれかに大別されます。

避ける（回避）

リスクの回避とは、リスクへのエクスポージャーを完全に排除することを意味します。これは、実際にリスクをゼロにまで低減する唯一のリスク対応策となっています。実際には、リスクを伴うプロセスまたはシステムをシャットダウンすることになります。

回避は、基本的に究極の選択肢であり、これを実現する可能性はほとんどありません。たとえば、外部との電子メールのやり取りをすべて停止することで、フィッシングのリスクをゼロにすることができます。国家安全保障の問題に取り組んでいる人には、これは価値のある方法かもしれませんが、その他の人にとっては、事業の運営が急停止することになるでしょう。

リスク分析では、このような対応が支持される状況が2 つあります。年間予想損失額 (ALE) がきわめて極端であり、緩和戦略ではそれを許容レベルまで下げることができない場合、または、リスクを負うプロセスまたはシステムを 1：1 で代替できる手段があり、エクスポージャー係数 (EF) または年間発生率 (ARO) をゼロにすることが可能な場合です。

受け入れる

リスクを受け入れるということは、無策を選択することを意味します。一見すると非合理的に思えるかもしれませんが、真剣に検討する価値のある選択肢です。

リスクを受け入れることが最善の選択肢となる非常に単純なシナリオが 1 つあります。それは、リスク軽減のコストが残余 ALE (つまり、リスク軽減後の年間予想損失額 (ALE)) を上回る場合です。このような状況では、組織を保護するためのコストが、組織の損失よりも大きくなります。

また、微妙な状況においては、リスク受け入れが合理的である場合もあります。これらは、リスク軽減のための機会費用を考慮します。セキュリティチームに限定される場合でも、ビジネス全体の機会費用でも同じです

セキュリティチームは、無限のリソースを有するわけではありません。そのリスクを軽減することを選択すると、より懸念されるリスク対応からリソースを転用することになる場合、リスク受け入れは（たとえ不快であっても）合理的な選択肢となります。特に、リスク緩和戦略に多くの手作業を要し、実装に多くのスタッフの作業時間が必要な場合、この取り組みに時間を取られて手薄になる作業があるはずです。

より広範な機会費用も考慮する必要があります。これは、リスクを軽減または回避するために、企業が諦めなければならない機会なのです。つまり、ビジネスチャンスが年間予想損失額 (ALE) よりも大きければ、リスク受け入れが合理的である場合もあるのです。新しい市場にクラウドサービスを提供するために国外にデータセンターを開設する場合などは、これに該当します。新たなセキュリティリスクが発生する可能性はありますが、ビジネス上のメリットは明らかです。

移転する

リスクの移転とは、通常はサイバーセキュリティ保険など、別の当事者に負担を負わせることを意味します。リスクを保険に移転することは、概して、保険料が年間予想損失額 (ALE) よりも低い場合の選択肢となりますが、いくつか注意点があります。

まず、保険でカバーされるのはセキュリティインシデントの金銭的コストのみです。セキュリティインシデントには、法的損害や風評被害も伴います。あなたの組織の年間予想損失額 (ALE) がこれらの損害を考慮に入れて（これが理想的な方法です）ドル建てで換算値を割り出している場合、その数字を細分化して、当面の金銭的コストのみを対象とする必要があります。金銭的リスクは高いが、法的リスクと風評被害のリスクは低い場合、リスクの移転は理にかなっています。

第二に、保険では、何らかのセキュリティ制御を実施することが間違いなく求められます。繰り返し発生するインシデントに対しては保険の適用が停止される可能性もあります。つまり、保険料に加えて、これらを管理するためのコストが必要となるため、計算が異なる可能性があります。また、リスクを保険に移転することは、年間発生率 (ARO) が高いリスクに対しては一時的な措置でしかないと言えます。

軽減する

リスク軽減は最も積極的な対応であり、セキュリティ制御の適用、脆弱性の修正、誤った構成の修正などによってリスクを軽減します。

軽減策を講じてもリスクを完全に排除することはできません。リスクを完全に排除するには、リスクをすべて回避するしか方法はありません。それに対して軽減策では、エクスポージャー係数 (EF)、年間発生率 (ARO)、またはその両方を削減する手順を実行することでリスクを軽減し、それを踏まえて、残余 ALE と呼ばれる新たな ALE (年間予想損失額) を算出します。

一般的に、元の ALE と残余 ALE の差がリスク軽減策のコストよりも大きい場合、軽減策は強力な選択肢となります。

リスク許容度の組み込み（またはエッジケースの処理方法）

リスク評価を行なっても、必ずしも明確な対応策を選択できるようになるわけではありません。 2 つの選択肢にわずかな差しかなかったり、不確実性のレベルが高かったりするケースは常に存在します。リスク許容を取り入れると、こうしたエッジケースを理解できるようになります。リスク許容は、リスク分析に通常は含まれませんが、その分析を解釈するための便利な枠組みとなります。

（組織でまだリスク選好度を文書化していない場合、編集可能なこのリスク許容度ステートメントテンプレートを使用して開始することができます。）

リスク許容度とは、組織がその目的を遂行するために受け入れるリスクのレベルのことです。 リスク許容度が高いということは、より大きな利益を得るために大きなリスクを受け入れる用意があることを意味します。一方、リスク許容度が低いということは、リスクを可能な限り減らすことを好むことです。リスク許容には複数の側面があります。運用リスクに対する許容度は高くとも、コンプライアンスリスクに対する許容度は低いこともあります。

これらの各側面（セキュリティリスク、コンプライアンスリスク、イノベーションリスクなど）には、考慮すべき重要な要素がいくつかあります。

リスクキャパシティは、組織が許容できる最大リスク量であり、通常は財務上のリソース、運営能力、規制上の制約によって決まります。
リスク許容度は、目標に対して許容可能な偏差のことです。
リスク閾値は、戦略の変更が必要であることを示す「越えてはならない一線」です。

リスク許容度とキャパシティの間のしきい値、または異なる許容度間のしきい値でも、それを使用することで、適切なリスク対応がわかりにくいグレーゾーンを整理するのに役立ちます。

洞察をアクションに変換

定量的リスク評価を理解することは最初のステップに過ぎません。真の価値は、こうした洞察を活用してアクションを起こすことから生まれます。リスクの回避、受け入れ、移転、軽減のいずれの場合でも、目標は同じです。つまり、セキュリティリスクとビジネスの優先順位のバランスを取り、決定的なアクションを講じられるようにすることです。

リスク許容度を理解する – エクスポージャー管理の重要な要素

Mon, 10 Feb 2025 14:44:03 Z

リスクはビジネスにつきものです。組織がリスクをどのように理解し、管理するかがすべてを左右するのです。

運用上の課題から市場の変動、規制の変更、技術の進歩まで、会社は、成長を生み出す可能性も損失につながる可能性もあるさまざまな不確実性に直面しています。

リスクを効果的に管理するには、企業は目標達成のためにどの程度のリスクを受け入れるかを判断できるような枠組みを確立しなければなりません。そこで「リスク許容度」という概念が役に立つのです。

ただし、リスク許容度を定義するには、会社が直面するすべてのリスクを把握し、理解する必要があります。エクスポージャー管理戦略のための基盤を築くセキュリティチームにとっても、その組織のリスク許容度を定義することは重要なステップとなります。

リスク許容度とは？

リスク許容度とは、組織がその目的を遂行するために受け入れるリスクのレベルのことです。これを定義することで、組織がどのようなリスクをどの程度取るかについて、境界が設定されます。 A リスク許容度が高いということは、より大きな利益を得るために大きなリスクを受け入れる用意があることを意味します。一方、リスク許容度が低いということは、その組織がリスクを可能な限り減らすことを好むことを意味します。

最先端の研究開発に投資を行おうとするテクノロジー系スタートアップ企業について考えてみましょう。不確実でも、潜在的な利益にそれだけの価値があると考えれば、斬新で画期的なイノベーションを実現するために高いリスク許容度を採用するかもしれません。逆に、すでに世に認められた大企業では、リスク許容度が低いかもしれません。市場での地位や評判を大きく損なう可能性のあるプロジェクトを避け、着実な成長に重点を置く可能性があります。

リスク許容度は定量的かつ定性的

リスク許容度は決して静的なものではありません。業界、会社の規模と健全性、戦略目標、規制要件、市場全体の環境などの要因に基づいて調整されるべき動的な尺度です。

リスク許容度は数字だけで測る問題でもありません。リスク選好度は定量的要因と定性的要因の両方を組み合わせたものなのです。

許容できる損失の額、負債比率、目指す投資収益率（ROI）などの測定可能な要素を企業が有する場合もあれば、企業の評判に影響が及ぶ可能性、倫理的な配慮、その決定が企業理念とどの程度一致しているかなど、主観的な側面も検討しなければならないかもしれません。

リスク許容度を定義することは、なぜ重要なのでしょうか？

組織が成功を望むなら、計算したうえでリスクを負うべきです。ただし、リスク許容度を明確に理解していなければ、意思決定が一貫性を欠いたり、後手に回ったり過度に慎重になったりして、機会損失やビジネスの損失につながる可能性があります。リスク許容度を定義することがなぜ重要なのか、その理由を挙げましょう。

戦略とリスク管理を整合化するため

リスク許容度を明確に定義することで、リスク管理の実践を事業全体の目標に一致させた戦略的枠組みが実現します。企業がどの程度のリスクを受け入れる意思があるかを把握していれば、自社のリスク許容度に見合った機会を追求し、過度のリスクを負う可能性を回避することができます。

意思決定を改善するため

リスク許容度を定義することで、責任者や管理者が許容可能なリスクを明確に理解し、情報に基づいた意思決定を行うことができるようになります。また、リスクを取る行動/リスクを回避する行動の両方に対して期待されることを組織全体で設定し、管理者がさまざまなシナリオを使ってリスクと報酬のトレードオフを評価することができます。

ステークホルダーの信頼を築くため

リスク許容度が明確に定義されていれば、組織がリスク管理を重視していることを示すことができ、投資家、規制当局、従業員、その他の利害関係者に安心感を与えます。また、リスクと報酬のバランスをとるための系統的かつ信頼できるアプローチを示すことで、ステークホルダーの信頼がさらに強化されます。

一貫性を促進するため

組織内の全員が、どの程度のリスクが許容されるのかについて「情報を得る」ことで、許容される行動を把握して一貫した意思決定が可能になります。つまり、目的がくい違ったり、反対方向に進んだりする可能性が低くなります。たとえば、法務部門とマーケティングチームが許容可能なリスクについて同じ考えを共有していなければ、法務部門はマーケティングチームの素晴らしいアイデアにブレーキをかけてしまう可能性があります。

効果的なリスク監視を支援するため

会社がリスク許容度を定義すると、財務から運用までを含めた企業全体でリスクレベルを監視するシステムを構築できます。こうすれば、潜在的な問題を早期に発見し、活動が安全と見なされる範囲内、あるいは少なくとも許容範囲内にとどまるようにすることができます。重要リスク指標（KRI）を設定して監視すると、誰かがその境界に接近している場合に早期に警告を発することができます。

会社はどのようにリスク許容度を定義するのでしょうか？

リスク許容度の定義にあたって、組織は通常、「リスク選好度ステートメント（RAS）」を作成します。リスク許容度ステートメント（RAS）の導入部では、会社の戦略目標およびそれに関連するリスクが説明されます。

業界をリードするようなソフトウェアプロバイダーを目指す会社について考えてみましょう。ここでは、目標を達成するために不可欠な戦略目標のリストとともに、それに関連するリスクもリストアップしなければなりません。たとえば、Ivanti の事業は、クラウドベースの IT サービスとセキュリティ管理ソリューションを提供することであり、リスク許容度ステートメントでは、この事業分野に関わるすべてのリスクを列挙し、それらをどのように管理するかを会社として説明しなければなりません。

あるソフトウェアプロバイダーのリスク許容度ステートメントの一部を例示しましょう。

一般的なリスク許容度

[XYZ 社]は、リスクに対してバランスの取れたアプローチを採用し、すべてのリスクが等しいわけではなく、戦略目標を達成するためにはある程度のリスクが必要であることを認識しています。

イノベーション・リスク私たちは、競争環境において製品を差別化する先進技術や革新的なソリューションへの投資に対して、高いリスク許容度を備えています。そのためには、研究&開発や製品開発においてある程度の不確実性を受け入れる必要があることを、私たちは理解しています。

運用リスク私たちは、低～中程度のリスク選好度を維持しています。オペレーショナル・エクセレンスを追求する一方で、私たちは提供基準を損なうことなく効率性とサービス品質を向上させる取り組みを優先しています。

セキュリティリスクセキュリティ上の脅威や侵害に対する私たちのリスク許容度は極めて低くなっています。ネットワーク・セキュリティとデータ保護に対する当社のコミットメントは最重要であり、当社のシステムとお客様のデータを保護するために多額の投資を行っています。

コンプライアンス・リスク私たちは、法的・規制的要件に対するコンプライアンス違反に対するリスク許容度を低くしています。すべての業務分野において、関連する法律、基準、ベストプラクティスを確実に遵守することが重要です。

一般的なリスク許容度 [XYZ 社]は、リスクに対してバランスの取れたアプローチを採用し、すべてのリスクが等しいわけではなく、戦略目標を達成するためにはある程度のリスクが必要であることを認識しています。
イノベーション・リスク	私たちは、競争環境において製品を差別化する先進技術や革新的なソリューションへの投資に対して、高いリスク許容度を備えています。そのためには、研究&開発や製品開発においてある程度の不確実性を受け入れる必要があることを、私たちは理解しています。
運用リスク	私たちは、低～中程度のリスク選好度を維持しています。オペレーショナル・エクセレンスを追求する一方で、私たちは提供基準を損なうことなく効率性とサービス品質を向上させる取り組みを優先しています。
セキュリティリスク	セキュリティ上の脅威や侵害に対する私たちのリスク許容度は極めて低くなっています。ネットワーク・セキュリティとデータ保護に対する当社のコミットメントは最重要であり、当社のシステムとお客様のデータを保護するために多額の投資を行っています。
コンプライアンス・リスク	私たちは、法的・規制的要件に対するコンプライアンス違反に対するリスク許容度を低くしています。すべての業務分野において、関連する法律、基準、ベストプラクティスを確実に遵守することが重要です。

リスク許容度ステートメント（RAS）では、ビジネスを行う上で発生する日常的なリスクではなく、組織に最も大きな影響を与えるリスクを定義します。そこで、複数のリスクシナリオを検討しなければなりません。たとえば、特定の戦略にはサプライチェーンリスクが伴う場合があります。ベンダーに縛られることによる影響や、サプライヤーが顧客データを適切に処理しなかった場合の規制違反の危険性などがこれに当たります。

また、企業が引き受けることができる財務リスクの量も定義しなければなりません。新しい製品やサービスを提供することが目的である場合、市場で失敗する可能性は常に存在します。

リスク許容度の構成要素

リスク許容度を定義する際に考慮すべき重要な要素を挙げましょう。

リスクキャパシティ（許容可能な最大リスク量）

これは、組織が負うことができるリスクの最大量を指し、通常は財務上のリソース、運営能力、規制上の制約によって決まります。リスクキャパシティはリスク選好度とは異なります。一定レベルのリスクを負うだけの能力を持つ組織でも、リスク選好度に基づいてリスクを負わないことを選択する可能性があるのです。

リスク許容度

リスクキャパシティが、組織が耐えられるリスクの量を示すものであるのに対し、リスク許容度は目標に対して許容可能な偏差のことであり、分野ごとに異なる許容度を設定することもできます。たとえば、新製品に対するリスクは負っても、顧客データの管理に関してはリスクを回避する組織もあるかもしれません。

リスク閾値

リスク監視と重要リスク指標（KRI）についてz前述しましたが、これらは会社がリスク閾値、つまり「越えてはならない一線」を超えないようにするために使用されます。リスク閾値を超えると、計画の変更、安全対策の強化、あるいは業務を完全に停止することが必要になる場合があります。

関連：Ivanti 調査レポート：認識を一致させる：経営幹部陣におけるサイバーリスク管理

エクスポージャー管理にリスク許容度が重要である理由は？

かつて、デジタルリスクを軽減することは現在よりもはるかに簡単でした。時は経過し、今や多くの大規模組織では攻撃対象領域が著しく拡大していています。従業員が使用するデバイス/アプリケーション数とその使用場所が増えて職場環境が変化し、デジタル脅威の対象も拡大しています。

Ivantiの調査では、IT専門家の半数以上が、今後12 か月の間に損害となるセキュリティインシデントを阻止できるようには思えないと回答していますが、攻撃対象領域の拡大もその一因となっています。また、3人に1人以上が、1年前に比べると脅威を検出してインシデントに対応する備えが不十分であると回答しています。

従来型の脆弱性管理では、長期にわたってソフトウェアやハードウェアの脆弱性やその他の共通脆弱性識別子（CVE）を事後的に修復することに重点を置いてきました。ただし、通常は断続的にスキャンを適用するのみにとどまります。現在のサイバー脅威のシナリオにおいては、新たなアプローチが求められています。

最新のエクスポージャー管理では、デジタル攻撃対象領域全体にわたってリスクと脆弱性を継続的かつ積極的に発見して修復することに重点を置いています。リスクと脆弱性は、公開された IT 資産、セキュリティ保護がなされていないエンドポイントとアプリケーション、クラウドベースのリソース、その他あらゆるベクトルから発生するのです。エクスポージャー管理とリスク選好度がこれほど密接に関係する理由は？

許容可能なリスクレベルに基づいてエクスポージャーを評価する：エクスポージャー管理には、さまざまなエクスポージャーに関連するリスクレベルを定量化することが含まれます。許容可能なリスクを定義することで、組織はさまざまなリスクが及ぼしうる影響をリスク選好度になぞらえることができます。
リスクに基づいてリソースを配備する：組織は、自社の戦略にとって最大の脅威となるエクスポージャーに優先順位を付ける必要があります。こうした評価は、リスク選好度を明確に理解してはじめて行えるようになります。優先順位を付けることによって、最も重要な問題を緩和するためにリソースを集中できるようになります。これには多くの場合、高度なリスクベースの脆弱性管理（RBVM）ツールが用いられます。
リスク選好度を調整する：ビジネス環境の変化や新たなリスクの発生で、リスク選好度を調整しなければならない場合もあります。こうした調整を行うにあたって、組織がエクスポージャー管理業務の中から得られるデータと洞察は、情報に基づいた意思決定を行うのに役立ちます。
コンプライアンスの確保：多くの業界ではリスク管理に関連する規制要件があり、それが組織のリスク選好度に影響を及ぼします。エクスポージャー管理には、コンプライアンスへの不適合を引き起こす可能性のあるリスクを特定し、対処することが含まれます。

関連：Ivanti 調査レポート：攻撃対象領域の管理

エクスポージャー管理の観点からセキュリティリスクを見る

エクスポージャー管理と他のセキュリティ慣行との顕著な違いは、エクスポージャー管理では、組織に最も大きなリスクをもたらすリスクの修復を優先するだけでなく、どのリスクが組織のリスク許容度の範囲内に収まるかを積極的に定義することが含まれるという点です。たとえば、ブラックフライデーに自社サイトを稼働させ続けるために、セキュリティリスクの増大を受け入れる電子商取引企業もあるかもしれません。その企業にとっては、価値あるトレードオフなのです。

組織は、潜在的なすべてのリスクを即時に修復すべき危機と見なすのではなく、ビジネスニーズに基づいて優先順位を付けなければなりません。この枠組みでは、大部分のリスクは悪いものではありません。重要なのは、リスクにどのように対応・制御・軽減して許容可能なレベルにまで引き下げるかということです。

セキュリティ・バイ・デフォルト: セキュア・バイ・デザインの重要な補完対策

Fri, 13 Sep 2024 12:00:00 Z

サイバーセキュリティのためのレガシーシステム (多くは 10 年以上前に設計されたものです) は、新しいタイプの攻撃者の能力や脆弱性に対応していません。また、人間が設定に依存しているという、多くのソフトウェアの弱点も考慮されていません。

この新たな現実に対する答えは、米国サイバーセキュリティ&・インフラセキュリティ庁 (CISA) が定めた「セキュア・バイ・デザイン」の原則を補完する「セキュリティ・バイ・デフォルト」と呼ばれるソフトウェア開発コンセプトです。

セキュア・バイ・デザインの原則では、ソフトウェアの設計と開発全体にわたってセキュリティを組み込むことを重視します。デフォルトでセキュリティが確保されているため、製品は追加設定せずとも、そのままで本質的に安全です。安全なログ管理や認証などのコアセキュリティ機能が事前に構成されているため、複雑な設定は必要ありません。

脅威は進化し、加速しています

最近まで、大部分のシステムの「被害の範囲」は限定的でした。ファイアウォールで包まれ、守られていたため、アクセスは組織内の少数の選ばれたユーザーに限定されていました。攻撃者が弱点を探し出すために忍び寄り入り込める開かれた領域はなかったのです。攻撃を自動化することはできませんでした。脆弱性を発見し、その脆弱性を突いたエクスプロイトを作成して武器に変え、その武器を用いた攻撃を展開するという攻撃プロセス全体には少なくとも数週間、多くの場合は数か月かかっていました。

つまり、攻撃の速度だけでなく規模も制限されていたのです。攻撃者は組織を1つずつ標的にして、特定の制御を回避する方法を見つける必要がありました。全体的な攻撃率は低く、攻撃が発生したとしても、攻撃者が費やさざるを得ない時間と労力のために、その影響は比較的抑えられていました。

「進化するサイバー脅威の状況」と言われますが、これは控えめな表現であると言わざるを得ません。自然や技術の進化がこれほど急速だったことはかつてなかったからです。わずか数年で、この領域はデジタル版「サンダードーム」闘技場へと変貌を遂げ、無防備な人々がかつてないほど危険にさらされる場所となったのです。

これは、攻撃者が以下の 3 つの重要な開発を利用できるようになったためです。

現在の攻撃者は、脆弱性をすぐに武器に変えることができ、人工知能ツールによってそれがさらに簡単になっています。情報を長く開示する時代は終わりました。ダークウェブで簡単に入手できる自動スキャンツールやエクスプロイトキットにより、技術に詳しくない攻撃者でもマルウェア攻撃に参加できるようになっています。攻撃者が脆弱性を悪用する手口が巧妙化しているため、パッチがリリースされるよりも前にゼロデイ攻撃が発生する懸念が高まっています。
クラウドが導入されたことによって、分散型クラウドインフラストラクチャがデータの保護と監視を困難なものにし、攻撃対象領域が拡大しています。クラウドプロバイダーとユーザー間のセキュリティ責任共有モデルは、構成が誤っていたり、十分に理解されていなかったりすると、脆弱性につながる可能性があります。さらに、クラウドアプリケーションでの通信は API に依存することが多く、適切に保護されていない場合は脆弱性が生じる可能性があります。
ファイアウォールやウイルス対策などの従来のセキュリティ対策では対応できません。ウイルス対策ソフトがまったく新しいゼロデイ脅威の検出に苦労しているときでも、ソーシャルエンジニアリングでファイアウォールが回避される可能性があります。境界型セキュリティアプローチはクラウド時代では時代遅れであり、IT インフラストラクチャ全体にわたってセキュア・バイ・デザインの原則を実装する必要があります。

悪意ある人物は、製品が起動した瞬間に弱点を探ったり、攻撃を開始したりする準備ができているのです。製品は、電源がオンになって組織のネットワークに接続された瞬間から、強力なゼロデイ防御を備えていなければならないのです。

セキュリティ・バイ・デフォルトの3つの柱

セキュリティ・バイ・デフォルトの適切な実行は、3 つの基本的な柱に基づいています。

「シフトレフト」セキュリティ

シフトレフトは、開発プロセスの早い段階での脆弱性検出に重点を置くことです。開発者は、OWASP Top 10 (Web アプリケーションのセキュリティ脆弱性) や CWE Top 25 (一般的なソフトウェアの弱点) などの資料で特定されている一般的な落とし穴を回避して、安全なコードを作成しなければなりません。

これは、健康習慣と予防接種によって病気から人を守る予防医学に例えることができます。開発者は最初から安全なコーディング手法に重点を置くことで、ソフトウェアに耐性と回復力を構築できるのです。

安全な構成の実現

人間が新しいソフトウェアを構成すると、ハッカーは喜びます。誤った構成エラーを排除するために、ソフトウェアプロバイダーはデフォルトで安全な構成を実現しなければなりません。これには、多要素認証 (MFA) やシングルサインオン (SSO)、およびハードコードされた資格情報 (パスワードやトークン) や、攻撃者に既に知られている脆弱性を持つデフォルト構成を避けることが含まれます。

安全な構成を実施することで、ユーザーの経験や技術的な専門知識に関係なく、開発を通じて一貫したセキュリティが確保されます。また、構成に関する決定を行う必要がないため、ユーザーエクスペリエンスも簡素化されます。

ソフトウェアのサプライチェーンのセキュリティ確保

自動車や航空宇宙部門での製造と同様に、現代のソフトウェア開発は、サードパーティのライブラリとオープンソースコードに大きく依存する組立ラインになっています。セキュリティ・バイ・デフォルトでは、開発者はこれらのコンポーネントのセキュリティに厳重な注意を払い、脆弱性が生じないようにしなければなりません。

セキュリティ・バイ・デフォルトの評価

現在、プロバイダーは計測器具とテレメトリを活用して、セキュリティ・バイ・デフォルト機能の性能を監視できます。製品がオンプレミスの場合、テレメトリを有効にするには、ユーザーのネットワークからデータが出られるようにファイアウォールに穴を開ける必要があります。クラウド内にあるデータは、テレメトリでプロバイダーに簡単に戻すことができます。

いずれの場合も、相互同意が必要です。ソフトウェアのユーザーは、プロバイダーがソフトウェアの動作を確認し、組み込まれたセキュリティ制御が実装されているかどうかを確認できるように、デフォルトのテレメトリを有効にする必要があります。幸いなことに、これは、ユーザーがセキュリティ機能を有効にする必要がないことも意味します。プロバイダーは、顧客の同意があればリモートでこれを行うことができます。

進化する脅威に先手を打つ

好意的かつ熱心なサイバーセキュリティ専門家でも、活用できるデータと見識に頼らざるを得ません。たとえば、OWASP Top 10 や CWE Top 25 などの従来の脆弱性リストは、セキュリティを認識するための鍵となりますが、以下のような限界があります。

これらのリストが更新されても、発見から緩和策が講じられるまでには一定の脆弱性が残ります。攻撃者は、まだリストに掲載されていない「外れた」脆弱性を標的にして、このギャップを悪用します。
従来のリストは既知の脆弱性に焦点を当てているため、組織は「既知の未知」、つまり悪用される可能性があるがまだ特定されていない弱点の影響を受けやすくなります。

とはいえ、AIと機械学習は、これらのギャップを埋めることで、セキュリティ・バイ・デフォルトに革命を起こす可能性を秘めています。

機械学習アルゴリズムは、膨大な量のセキュリティデータを分析してパターンを識別し、従来のリストにまだ含まれていないものも含め、潜在的な脆弱性を予測できます。
機械学習は、エクスプロイトの傾向とソフトウェアの動作を分析することで、まだ文書化されていなくとも悪用される可能性が高い「既知の未知」の脆弱性を特定できます。

ソフトウェア開発ライフサイクル (SDLC) にAIを追加する

AIと機械学習によって、セキュリティ・バイ・デフォルトの原則をソフトウェア開発サイクルに組み込む方法を変えることもできます。

自動化された脆弱性検出: AI ツールは、既知の脆弱性と未知の脆弱性のいずれについてもコードを継続的にスキャンできるため、ソフトウェア開発ライフサイクル (SDLC) の早い段階で対処できます。
プロアクティブなセキュリティモデリング: AI は攻撃パターンを分析することで脅威を予測できます。これによって、プロアクティブなセキュリティモデリングを用いて、こうした脅威に対する防御機能が組み込まれたソフトウェアを構築できます。
インテリジェントな開発者支援: AI はコードを分析し、開発チームに安全なコーディング手法についてリアルタイムで提案を行うことができます。

自己修復ソフトウェアによるセキュリティ・バイ・デフォルト

セキュリティ・バイ・デフォルトに関心を持つ開発者の目標の 1 つは、それ自身が脆弱性を積極的に識別して修正する機能を内包するソフトウェアを作成することです。このコンセプトは、製造業で使用される遺伝的アルゴリズムにヒントを得たもので、システムが時間の経過とともに自己最適化し、改善できるようにします。

これによって「セキュリティ・バイ・デフォルト」は、静的コンセプトから動的で自己監視、自己修復の機能を備える動的コンセプトへと変化し、エンタープライズソフトウェアに組み込まれます。そして自ら脆弱性を修正し、脅威を阻止し、さらには新たな攻撃を開発者に報告する能力さえも獲得することになります。

正しい方向へと踏み出す

少し前に、私は「デジタルセキュリティ問題を解決するために産業界と政府が協力する官民パートナーシップ」が必要であることについて書きました。セキュア・バイ・デザインの原則の作成と、それを推進するための CISA と産業界のリーダーによる取り組みは、サイバー脅威に対して緊急に必要とされる共同防御を構築する上で大きな前進です。

これらの対策を実行するかどうかは、個々のソフトウェアプロバイダーと開発者次第ではありますが。セキュリティ・バイ・デフォルトの実践に従うことは、より安全なソフトウェアの開発と提供、そしてサイバーセキュリティの戦いで優位に立つために重要な役割を果たします。

これまでになく重要なセキュア・バイ・デザインの原則

Thu, 18 Jul 2024 07:36:39 Z

セキュア・バイ・デザインの概念は、ソフトウェアを設計する以前にセキュリティを組み込むことを意味します。この概念はソフトウェア開発の方法を抜本的に変革しています。

従来ソフトウェアは、多くの場合、製品の開発後に「ボルトオンセキュリティ」と呼ばれる機能を追加する設計になっていますが、それはソリューションにセキュリティが組み込まれていないことを意味します。コアとなる製品と追加機能が結合している場合、その箇所が変曲点となって攻撃の対象となります。

ソフトウェアプロバイダーがセキュア・バイ・デザインの原則に取り組むのが非常に重要なのはこのためです。Ivanti は、米国サイバーセキュリティ &・インフラセキュリティ庁 (CISA) のセキュア・バイ・デザインの誓約に初めて署名した企業です。

誓約書に署名したプロバイダーは、CISA が定めた原則に従うことを約束します。これらの原則は、初期の構想から最終的な展開まで、ソリューションの中核にセキュリティ対策を組み込むことに重点を置いています。こうすることで、ソリューションは使用開始と同時に攻撃に対する本質的な耐性を備え、顧客による導入後に脆弱性を修正する必要がなくなります。被害を食い止めるには手遅れという、ありがちな状況を回避します。

安全なデザインの基本原則

デジタル技術の進歩につきまとう脅威、それはサイバー攻撃が進化してデジタル技術を巧妙に利用してきたことです。現在、サイバー攻撃はハイブリッドネットワーク全体に広がり、企業を脅かし、混乱させ、顧客の信頼を損ない、企業の収益に大きな打撃を与える脅威となっています。 CISA の立場からすると、サイバー攻撃は国家安全保障に対するきわめて現実的な脅威でもあります。

セキュア・バイ・デザインは、セキュリティはソフトウェアの最も初期の計画段階から設計されるべきであるという新しい基本的なセキュリティ設計原則を重視します。これは、利益や政治、あるいはその両方を動機とする現代の攻撃者に対するより強力な防御につながります。

誓約署名企業としての観点から、Ivanti はセキュア・バイ・デザインの原則に適合するために求められるあらゆる措置を講じることが重要であると考えます。プロバイダーは、以下の点について自問する必要があります。メモリ安全性のためにセキュアソフトウェア開発フレームワーク (SSDF) の観点から設計されたプログラミング言語を使用しているか？潜在的な脆弱性を特定するために、定期的に脅威モデリングを実行しているか？サードパーティのライブラリまたはコンポーネントを使用しているか？それらのセキュリティ体制は？

これらの問いに答えるには、ソフトウェア開発ライフサイクル (SDLC) 全体を通じてセキュリティに重点を置く必要があります。これには以下が含まれます。

コードが記述されるまで待つのではなく、プロセス全体にセキュア・バイ・デザインの原則を取り入れることで、計画と設計全体を通じてセキュリティに重点が置かれるようにします。これは、潜在的な脅威について考え、ソフトウェアに防御を設計することを意味します。
開発を通じて包括的なセキュリティテストを組み込むことで、脆弱性を早期に発見します。これにより、ソフトウェア開発ライフサイクル (SDLC) 中またはリリース後に行うコストと複雑さを回避します。

これは、早期のセキュリティテストを行う「シフトレフト」アプローチ以上の対策となります。 Secure by Design の原則を適用することで、開発者はコードセット内で静的アプリケーションセキュリティテストと動的アプリケーションセキュリティテストを実行し、テストや脅威モデリングを最後に行うのではなく、SDLC プロセス全体でユニットテストと統合テストを実施できるようになっています。開発者はこのようにして、ほぼ毎日テストツールを使用することに慣れていきます。

安全なソフトウェア以上のもの

セキュア・バイ・デザインの原則を実践することは、セキュアコードの作成とテスト以上のことを意味します。安全な組織の上に強力な防御を構築し、サイバーセキュリティに対する総合的なアプローチを取ることなのです。これには以下のような対策が含まれます。

弱点の特定: ソフトウェアコードだけでなく、組織内のどこに脆弱性が存在するかを理解することが重要です。これは、従業員のトレーニングプログラムからセキュリティソフトウェアのパッチ適用、企業全体のセキュリティ体制に至るまで、サイバーセキュリティのさまざまな側面を分析し、最適化することを意味します。
保護と監視: 組織は、リスクを積極的に、さらには予防的に管理するために、強力なサイバーセキュリティツールを導入する必要があります。これには、疑わしい活動を検出するための監視システムや、サイバー攻撃を最初から拒否するためのファイアウォールなどの安全対策が含まれます。
インシデント対応: サイバー攻撃に対処するための明確な計画が不可欠です。攻撃を検出し、その影響を評価し、セキュリティ対策を回復および改善するための手順をまとめておく必要があります。

セキュア・バイ・デザインの原則に基づいて安全なソフトウェアシステムを実装することは、さらに他の意味もあります。セキュア・バイ・デザインが話題に上るとき、多くの場合、事実上の「セキュリティ・バイ・デフォルト」アプローチを指しています。これらは補完的な概念です。セキュア・バイ・デザインが開発ライフサイクル全体にわたってセキュリティの上で考慮すべき事項が製品に組み込まれていることを意味するのに対し、「セキュリティ・バイ・デフォルト」は、ユーザーが詳細な構成を行う必要がなく、最終製品に安全のための設定が施されていることを意味します。安全なログ管理やソフトウェア認証プロファイルなどの対策がすでに設定されており、下位互換性よりも将来を見据えたセキュリティを優先しています。

関連項目: 実践デモ: 安全な UEM 対策ですべてのエンドポイントを保護する

セキュア・バイ・デザインによる顧客のメリット

ソフトウェアプロバイダーがセキュア・バイ・デザインの原則に従ったソリューションとプラットフォームを提供する場合、最も重要なメリットは顧客が体験するメリットです。

保護の強化: セキュリティ機能が最初からソフトウェアに組み込まれていると、ソフトウェアはより強力になり、脆弱性も低減します。また、ソフトウェアが稼働しているネットワークも同様です。
DEXの強化: 開発中からセキュリティとテストに重点を置くことによって、より安定感があり、中断に強く、より最適化された製品が実現し、従業員のエクスペリエンスが向上します。
最大投資収益率 (ROI) 向上: より安全な製品により、ダウンタイムとパッチ適用が最小限に抑えられ、ユーザーの生産性を保つことができます。
合理化されたコンプライアンス: セキュア・バイ・デザインソフトウェアを使用すると、厳格なデータプライバシーとセキュリティ要件を簡単に遵守できるようになり、コンプライアンス適合のために必要な時間とリソースが削減され、制裁を回避できます。
評判の向上: セキュリティを最優先に考える企業は信頼性があるとみなされ、顧客の信頼と忠誠心を高めることができます。

組織の攻撃対象領域を減らすための 8 つのベストプラクティス

Thu, 16 May 2024 19:58:14 Z

攻撃対象領域の拡大がサイバーセキュリティリスクの増大につながります。したがって、論理的には、攻撃対象領域の縮小はサイバーセキュリティリスクの低減につながります。

攻撃対象領域管理ソリューションの中には、この取り組みを支援する修正機能を備えているものもありますが、修正は反応的な行動です。セキュリティやリスク管理に関するあらゆることと同様に、能動的であることが理想的です。

良い点は、攻撃対象領域の戦いにおいて、ASM ソリューションだけがセキュリティチームの武器ではないということです。 IT 環境の露出を減らし、サイバー攻撃を未然に防ぐために、組織が講じることのできる手段は数多くあります。

組織の攻撃対象領域を減らす方法

悪意ある主体以外のすべての人にとって残念なことですが、攻撃対象領域をすべてなくすことはできません。しかし、この投稿で詳しく説明する以下のベストプラクティスのセキュリティ統制は、攻撃対象領域を大幅に縮小するのに役立つでしょう。

複雑さを低減する
論理的、物理的アクセス制御にゼロトラスト戦略を採用する
リスクに基づく脆弱性管理へと進化する
ネットワークセグメンテーションとマイクロセグメンテーションを導入する
ソフトウェアおよび資産の構成を強化する
ポリシーコンプライアンスを施行する
サイバーセキュリティのポリシーとベストプラクティスについて全従業員を教育する
デジタル従業員体験 (DEX) を改善する

攻撃対象領域用語集で述べたように、異なる攻撃ベクトルは、技術的には複数の種類の攻撃対象領域 (デジタル、物理的、人的) に該当する可能性があります。同様に、この記事のベストプラクティスの多くは、複数の種類の攻撃対象領域を減らすのに役立ちます。

そのため、各ベストプラクティスには、特定のベストプラクティスが主にどの種類の攻撃対象に対応しているかを示すチェックリストが付属しています。

#1: 複雑さを低減する

デジタル攻撃対象領域	物理攻撃対象領域	人的攻撃対象領域
X	X

複雑さを軽減することで、サイバーセキュリティの攻撃対象領域を減らします。当然だとそして、そうなのです。しかし、多くの企業はこの一見単純なステップで長い間失敗してきました。不明瞭だったからではなく、常に簡単なことではなかったからです。

Randori と ESG の調査によると、過去 1 年間に 10 社に 7 社の組織が、インターネットに接続した不明な、管理されていない、または管理が不十分な資産によって危険にさらされていたことが明らかになりました。サイバー資産攻撃対象領域管理 (CAASM) ソリューションにより、このような組織は、未承認、未管理の資産も含め、すべての資産を特定し、このような資産のセキュリティ保護、管理、さらには企業ネットワークからの削除もできるようになります。

エンドポイントデバイスからネットワークインフラストラクチャに至るまで、未使用または不要な資産もネットワークから削除し、適切に除却するべきです。

ソフトウェアアプリケーションを構成するコードもまた、複雑さが攻撃対象領域の拡大に寄与する領域です。開発チームと協力して、悪意のある主体にさらされる実行コードの量を最小限に抑える機会がどこにあるのかを特定し、それによって攻撃対象領域を減らします。

#2: 論理的、物理的アクセス制御にゼロトラスト戦略を採用する

デジタル攻撃対象領域	物理攻撃対象領域	人的攻撃対象領域
X	X

米国国立標準技術研究所 (NIST) は、ゼロトラストを以下のように定義しています。

「危険にさらされていると見なされているネットワークで、情報システムやサービスにおいて、正確で最小特権の要求ごとのアクセス決定を実施する際の不確実性を最小化するために設計された概念とアイデアの集合。」

言い換えれば、すべてのアクセス要求に対して、「決して信用せず、常に検証する」ということです。

Ivanti がどのように NIST CSF in The NIST Cybersecurity Framework (CSF): CSF Controls　に対する Ivanti のソリューションを採用するお手伝いができるのかをご覧ください。

論理アクセス制御へのゼロトラストアプローチを取ることは、継続的に態勢とコンプライアンスを検証し、最小限の特権アクセスを提供することにより、組織の攻撃対象領域を縮小し、データ侵害の可能性を低減します。

ゼロトラストは製品ではなく戦略ですが、ゼロトラスト戦略を導入するのに役立つ製品もあります。これらの製品の中で最も重要なものは、セキュアアクセスサービスエッジ (SASE) フレームワークに含まれる製品です。

ソフトウェア定義ワイドエリアネットワーク (SD-WAN)
セキュア Web ゲートウェイ (SWG)
クラウドアクセスセキュリティブローカー (CASB)
次世代ファイアウォール (NGFW)
ゼロトラストネットワークアクセス (ZTNA)

また、一般的にはこのような見方はされていませんが、ゼロトラスト戦略は論理的なアクセス制御にとどまらず、物理的なアクセス制御にまで拡大できます。施設の保護された区域に誰かを立ち入らせるときは、決して信用せず、常に検証することを忘れないでください。この目的のために、アクセスカードやバイオメトリクスのようなメカニズムを使用できます。

リスクに基づく脆弱性管理へと進化する

デジタル攻撃対象領域	物理攻撃対象領域	人的攻撃対象領域
X

まず、悪い点です。US National Vulnerability Database (US NVD) には 16 万件以上の脆弱性が含まれており、毎日数十件が追加されています。しかし、朗報があります。脆弱性の大半は悪用されたことがありません。つまり、サイバー攻撃に使われることはなく、攻撃対象領域にはならないということです。

実際、Securin、Cyber Security Works (CSW)、Ivanti、Cyware によるランサムウェアの調査レポートでは、16 万件以上の脆弱性のうち、アクティブなエクスプロイトのトレンドにあったのはわずか 180 件でした。

NVD の全脆弱性と組織を危険にさらす脆弱性の比較

米国 NVD に含まれる全脆弱性のうち、組織に直接的なリスクをもたらすアクティブなエクスプロイトのトレンドは約 0.1% に過ぎない

脆弱性管理へのレガシーなアプローチは、共通脆弱性スコアリングシステム（CVSS）の陳腐で静的なリスクスコアに依存しているため、悪用される脆弱性を正確に分類することはできません。また、Cybersecurity & Infrastructure Security Agency Known Exploited Vulnerabilities (CISA KEV) Catalog は正しい方向への一歩ではありますが、不完全であり、組織の環境における資産の重要性を考慮していません。

真のリスクベースのアプローチが必要です。リスクベースの脆弱性管理（RBVM）は、その名前が示すように、組織にもたらすリスクに基づいて、脆弱性を修正するための優先順位を決定するサイバーセキュリティ戦略です。

究極のリスクベースパッチガイドを読んで、リスクベースのアプローチへと修復戦略を進化させる方法を発見してください。

RBVM ツールは、脆弱性スキャナー、侵入テスト、脅威インテリジェンスツール、およびその他のセキュリティソースからデータを取り込み、それを使用してリスクを測定し、修正活動の優先順位を決定します。

RBVM ツールのインテリジェンスを手にした組織は、最もリスクの高い脆弱性を修正することで、攻撃対象領域を縮小ほとんどの場合、インフラストラクチャ側では悪用された脆弱性にパッチを適用し、アプリケーションスタックでは脆弱なコードを修正する。

ネットワークセグメンテーションとマイクロセグメンテーションを導入する

デジタル攻撃対象領域	物理攻撃対象領域	人的攻撃対象領域
X

もう一度、NIST の用語集から引用すると、ネットワークセグメンテーションは次のように定義されます。

たとえば、不要なトラフィックを拒否するように設定されたファイアウォールで保護された、ネットワーク上の個別のエリアを作成することによって、ネットワークをサブネットワークに分割します。ネットワークセグメンテーションは、マルウェアやその他の脅威をネットワークの限られた部分に隔離することで、その被害を最小限に抑えます。

この定義から、セグメンテーションによって攻撃者をネットワークの特定の部分からブロックすることで、攻撃対象領域をいかに減らせるのかがわかります。従来のネットワークセグメンテーションがネットワークレベルでの攻撃者の垂直移動を阻止するのに対し、マイクロセグメンテーションはワークロードレベルでの攻撃者の水平移動を阻止します。

具体的には、マイクロセグメンテーションは、ネットワークのセグメンテーションを超え、ネットワーク別ではなく、アプリケーションやデバイス別といった、より粒度の高い方法でポリシーを施行します。

たとえば、ある IoT デバイスがアプリケーションサーバーとしか通信できず、他の IoT デバイスとは通信できないように制限をかけたり、ある部署の誰かが他の部署のシステムにアクセスできないようにしたりできます。

#5: ソフトウェアおよび資産の構成を強化する

デジタル攻撃対象領域	物理攻撃対象領域	人的攻撃対象領域
X

オペレーティングシステム、アプリケーション、およびサーバーやエンドユーザー、ネットワーク、IoT デバイスなどの企業資産は、通常、未設定か、セキュリティよりも導入や利用のしやすさを優先したデフォルトの設定で提供されます。 CIS Critical Security Controls (CIS Controls) v8 によると、デフォルトの状態のままにしておくと、次のような悪用が可能です。

基本的な
開いているサービスとポート
デフォルトのアカウントまたはパスワード
構成済みのドメインネームシステム（DNS）設定
古い (脆弱性) プロトコル
不要なソフトウェアのプリインストール

このような構成は攻撃対象領域を拡大することは明らかです。この状況を改善するために、CIS Controls v8 の「Control 4: 企業資産とソフトウェアの安全な構成」では、ソフトウェアと資産のセキュリティが低下しないように、強力な初期構成を開発、適用し、その構成を継続的に管理維持することを推奨しています。

この取り組みを支援するために、チームが活用できる無料のリソースやツールを紹介します。

CIS ベンチマークリスト - 25 以上のベンダー製品ファミリーの推奨構成
NIST National Checklist Program (NCP) - ソフトウェアのセキュリティ構成を設定するためのガイダンスを提供するチェックリストの集合。
CIS-CAT Lite - さまざまな技術に対応したセキュアな設定の実装を支援する評価ツール。

#6: ポリシーコンプライアンスを施行する

デジタル攻撃対象領域	物理攻撃対象領域	人的攻撃対象領域
X	X

特に、Everywhere Work の時代には、これまで以上に多くの従業員がハイブリッドやリモートで働くようになっており、エンドポイントがほとんどの攻撃サーフェスの規模に大きく寄与していることは周知の事実です。現在、政府職員の 10 人に 7 人が、少なくとも一部の時間、バーチャル勤務をしています。

オフィスの中にいる従業員に IT とセキュリティのポリシーを守らせるのは大変なことです。その 70% が世界中に散らばっているのならなおさらです。

統合エンドポイント管理 (UEM) ツールは、ポリシーを自動的に実施することにより、普遍的なポリシーコンプライアンスを保証します。この事実は、IT やセキュリティの専門家にとって驚くべきことではなく、多くの専門家は現時点では UEM を商品と考えています。実際、Gartner は、2025 年までに顧客の 90% がクラウドベースの UEM ツールで資産の大半を管理するようになると予測しています。

とはいえ、UEM は IT およびセキュリティポリシーコンプライアンスを実施するための最良の選択肢です。だから、このリストから外すのは惜しいと思われます。

統合エンドポイント管理の究極ガイドを読んで、最新の UEM ソリューションの主なビジネス上の利点とエンドポイントセキュリティのユースケースについて学んでください。

さらに、最新の UEM ツールは、コンプライアンス以外にも、攻撃対象領域の特定、管理、削減に役立ついくつかの機能を提供しています。

ネットワーク上のすべてのデバイスを検出することで、IT 資産を完全に可視化します。これは、CAASM ソリューションを持たない組織のための ASM 機能です。
適切なソフトウェアとアクセス許可をデバイスに提供し、必要に応じてソフトウェアを自動的に更新します。ユーザーによる操作は必要ありません。
あらゆる種類のデバイスを、入社から退職までのライフサイクル全体にわたって管理し、使用されなくなったデバイスが適切に処分されるようにします。
デバイスの構成を自動的に強化します (この機能の重要性については、#5: ソフトウェアと資産の構成強化を参照してください)。
ゼロトラストアクセス、および ID、セキュリティ、およびリモートアクセスツールとの統合による、コンテキスト認証、脆弱性、ポリシー、構成、およびデータ管理をサポートします。たとえば、UEM とモバイル脅威防御（MTD）ツールを統合することで、モバイルデバイスが企業ネットワークやその資産を侵害しないように、リスクベースのポリシーを制定することができます。

#7: サイバーセキュリティのポリシーとベストプラクティスについて全従業員を教育する

デジタル攻撃対象領域	物理攻撃対象領域	人的攻撃対象領域
		X

2023 年 Verizon データ侵害調査報告書（DBIR）のために分析された侵害の 74% には人的要素が関与していました。

したがって、Ivanti の 2023 年版サイバーセキュリティステータスレポートのデータを確認し、世界中の従業員のうち、自分の行動がサイバー攻撃を回避する組織の能力に影響を及ぼすとは考えていない人の割合を見ても、驚くには値しません。

職員は自分の行動を重要視しているのでしょうか。

多くの従業員は、自分の行動がサイバー攻撃から組織を守ることに影響するとは思っていません。

アレキサンダー・ポープの不朽の名言「To err is human...」（誤りを犯すのは人間である）。サイバーセキュリティの用語で言えば、AI が正式に支配するまで、人間は攻撃対象領域の重要な一部であり続けます。そしてそれまでは、可能な限り人間の攻撃面を管理し、減らさなければなりません。

これまでのところ、そのための最善の方法は、一般的なベストプラクティスと企業固有のポリシーの両方に関するサイバーセキュリティトレーニングであることが証明されています。ソーシャルエンジニアリングモジュールを含めることを絶対に忘れないでください。

多くのサイバーセキュリティ専門家がそう考えています。経験上、サイバー攻撃やデータ漏洩を防ぐために最も成功したセキュリティ対策は何ですか」という質問が、Reddit の r/cybersecurity subreddit で投げかけられたとき、上位コメントの多くがユーザー教育の必要性に言及しました。

Reddit / u/Forbesington

Reddit / u/slybythenighttothecape

Reddit / u/_DudeWhat

Reddit / u/onneseen

再び CIS Controls v8 から引用すると、Control 14: セキュリティ意識とスキルのトレーニングは、組織に対して次のことを行うよう奨励しています。「企業に対するサイバーセキュリティリスクを低減するために、従業員がセキュリティを意識し、適切なスキルを身につけるよう、従業員の行動に影響を与えるセキュリティ意識向上プログラムを確立し、維持する。」

CIS (Center for Internet Security) は、次のリソースを活用して、セキュリティ意識プログラムの構築を支援することを推奨しています。

非技術職だけでなく、セキュリティおよび IT スタッフも、それぞれの役割に関連したサイバーセキュリティトレーニングを受けるべきです。実際、Randori と ESG が 2022 年に発行したレポート The State of Attack Surface Management で調査した IT およびセキュリティの意思決定者によると、セキュリティおよび IT 担当者に ASM のトレーニングを提供することは、ASM を改善するための 3 番目に効果的な方法です。

パートナー、ベンダー、その他のサードパーティ請負業者にもセキュリティトレーニングを受けさせることで、人的な攻撃対象領域を抑制できます。

#8: デジタル従業員体験 (DEX) を改善する

デジタル攻撃対象領域	物理攻撃対象領域	人的攻撃対象領域
X		X

従業員にいくらサイバーセキュリティ教育を施しても、セキュリティ対策が複雑になればなるほど、従業員がそれを回避する可能性は高まります。エンドユーザーの 69% は、複雑すぎるセキュリティ対策の操作に苦労していると報告しています。そのような不満を抱えたユーザーは、安全でない経路でデータを配布したり、セキュリティ更新プログラムのインストールを妨げたり、シャドー IT を導入したりしがちです。

IT リーダーは、セキュリティを犠牲にしてデジタル従業員体験（DEX）を向上させるか、体験よりもセキュリティを優先させるか、という不可能な選択を迫られているようです。実は、セキュリティと DEX は、組織の成功と回復力にとって等しく重要なのです。実際、Enterprise Management Associates（EMA）の調査によると、セキュリティ上の摩擦を減らすことで、侵害の発生件数を大幅に減らすことができます。

では、どうすればよいのでしょうか。 Ivanti の「2022 Digital Employee Experience Report」によると、IT リーダーは経営幹部の支援を受けて、セキュア・バイ・デザインデジタル従業員体験の提供に力を入れる必要があります。かつてはそれが不可能に思えたかもしれませんが、従業員のテクノロジーエクスペリエンスを測定し、継続的に改善するのに役立つ DEX ツールの新興市場のおかげで、今ではかつてないほど簡単になりました。

2022 年デジタル従業員体験レポートを読んで、DEX がサイバーセキュリティに果たす役割について詳細をご覧ください。

組織がセキュリティと従業員体験の両方を容易に改善できる分野の1つは、認証です。覚えたり、入力したり、リセットしたりするのが面倒で非効率的なパスワードは、長い間エンドユーザーの悩みの種でした。

その上、極めて安全性に欠けていました。 2023 年 Verizon DBIR で分析された、内部での悪意ある行為を伴わない 4,291 件のデータ漏えいのうち、およそ半数が資格情報によるものであり、フィッシングによるものの約 4 倍でした。つまり、組織のIT資産に参入するための最も一般的な経路となっています。

パスワードレス認証ソフトウェアはこの問題を解決します。エンドユーザーのエクスペリエンスを向上させ、攻撃対象を一挙に減らしたいのであれば、パスワードレス認証ソリューションを導入し、FIDO2 認証プロトコルを使用します。付箋に書かれたパスワードに永遠に別れを告げることができれば、あなたもユーザーも喜ぶことでしょう。

DEX とセキュリティのバランスをとる方法については、以下のリソースを参照してください。

無料リソースからの追加ガイダンス

Ivanti が提案する攻撃対象領域を減らすためのベストプラクティスは、私たちの実体験から得た学びと、権威あるリソースから得た二次知識を組み合わせたものです。

これらのベストプラクティスは、確かに攻撃対象領域のサイズを大幅に縮小させる思われます拡大し続ける現代の攻撃対象領域のサイズと複雑さに対抗するために、組織が取るべき他の手段には事欠きません。

攻撃対象領域を縮小するための追加ガイダンスについては、以下の無料リソースを確認してください。

次のステップ

上記のベストプラクティスをすべて実施し、次はどうしようかと考えているところでしょう。サイバーセキュリティのすべてに言えることですが、立ち止まっている時間はありません。攻撃面は常に監視が必要です。

いつ次の管理されていない BYOD デバイスがネットワークに接続されるか、いつ CRM ソフトウェアの次の脆弱性が悪用されるか、いつ次の従業員がチームのハッピーアワーの後のバーに iPhone を忘れるかはわかりません。

既存の攻撃ベクトルを追跡するだけでなく、新たな攻撃ベクトルについても常に情報を得る必要があります。たとえば、最近の AI モデルの爆発的な普及は、攻撃対象の大幅な拡大を推進しており、IT 環境への扉を開くテクノロジーはさらに増えていると言ってよいでしょう。

ITAM が CAASMを越える: IT 資産管理が CAASM 戦略の必要条件である理由

Mon, 21 Aug 2023 19:43:51 Z

サイバー資産攻撃対象領域管理 (CAASM) は、サイバーセキュリティ戦略の基本的な部分に対する新たなアプローチです。サイバー資産を完全に把握することで、悪質な業者が悪用する可能性のある脆弱性を特定できます。

IT 運用担当者にとって、CAASM はきっと IT 資産管理 (ITAM) のように聞こえるでしょう。それは、この 2 つの分野が密接に関連しているからです。セキュリティ部門と IT 部門が、いかに共有のツールやプロセスを活用できるか、またどのようにそれらを活用すべきかを明確に示しています。

ITAM と CAASM の比較: 違いは何か

ITAM は、ハードウェアとソフトウェアを含むすべての IT 資産を、そのライフサイクルを通じて管理するための一連のプロセスとツールです。通常、資産の検出、在庫管理、サービスマッピング、資産の追跡と監視、資産のライフサイクル管理など、幅広いワークフローが含まれています。

CAASM は、組織のシステム、ネットワーク、アプリケーションに対する潜在的な脆弱性と脅威を特定し、軽減することで、ITAM を進化させます。通常、このプロセスでは、IT 環境内のすべての資産を特定し、これらの資産間の相互依存関係をマッピングし、侵害の潜在的な影響を評価します。

その目的は、潜在的な攻撃対象領域を明確に理解し、最も重大なリスクに基づいて修正作業の優先順位をつけることです。確かにそれは求められていることです。サイバーセキュリティチームの 44% が、資産情報が攻撃対象の特定と保護に不可欠であると考えています。

ITAM のセキュリティ上の利点

セキュリティにおける ITAM の重要性は、IT リーダーにとっては新しいことではありません。 EMA が 2022 年に IT リーダーを対象に行った調査によると、半数近くが ITAM プログラムの成功をセキュリティリスクの最小化によって測っていることが明らかになりました。セキュリティの視点から ITAM を見ると、CAASM に直接結びつく多くの利点があります。

資産の特定

完全に実装された ITAM ソリューションによって、組織はすべての IT 資産を識別し、追跡できます。環境にどのような資産があるかを知ることは、潜在的な脆弱性と脅威を特定するための第一歩です。

脆弱性の管理

IT 資産の包括的なインベントリがなければ、組織は定期的な脆弱性評価を実施し、潜在的な脆弱性を特定し、能動的に対処しようとする際にギャップに遭遇することになります。

セキュリティ対策の優先順位

すべての資産の内容と、存在している場所を把握することは、有効な出発点ですが、リスク管理を支援するためにリソースを効果的に配分することは、どの資産が最も重要かを知ることを意味します。明確に定義された ITAM プロセスと有能 ITAM システムは、セキュリティ対策の優先順位付けに必要な情報を組織に提供します。

資産を種類別に分類することで、サイバーセキュリティチームはクラウドや SaaS のようなリスクの高い資産により重点を置きながら、エッジデバイスのような比較的リスクの低い資産を適切に管理できます。

また、CAASM との直接的な関係は薄いものの、ITAM は他の分野のセキュリティ強化でも役割を果たしています。

Compliance

CCPA、GDPR、POPI、Castle など、さまざまな規制があり、企業は IT 資産の正確なインベントリを維持し、さまざまなセキュリティ基準に準拠していることを証明することが求められています。

コスト削減

IT 資産に関しては、コストの管理は使用状況の管理と密接な関係があります。たとえば、調査対象となった IT リーダーの約 3 分の 1 が、未使用または十分に使用されていないクラウドリソースに予算を浪費していると考えています。誤った支出管理は、それ自体が IT 組織にとってのリスクであり、セキュリティ問題に対処するための利用可能なリソースを制限することで、サイバーセキュリティを悪化させます。

資産のセキュリティを確保する CAASM ソリューションの構築

ITAM とサイバー資産リスク管理を融合させた CAASM ソリューションは、個々の資産だけでなく、サイバー資産全体をさまざまな脅威や脆弱性から保護できます。それでは、効果的な CAASM ソリューションスタックを構成するコンポーネントを詳しく見ていきましょう。

資産の検出と管理

ITAM が CAASM ソリューションの重要な構成要素であることはすでに見てきたとおりです。 ITAM の導入を成功させるには、ネットワークをスキャンして、隠れていたり未知のデバイスも含めて、接続されているすべてのデバイスを特定する検出ツールが必要です。

ITAM ソリューションの資産データベースは、多くの場合 CMDB（下記参照）に関連付けられ、資産属性、構成、関係と依存関係のマッピングを含むすべての資産情報を管理するための中央リポジトリを提供できます。

脆弱性管理

脆弱性管理には、組織が IT 資産内の脆弱性を特定し、優先順位をつけることを可能にするツールと技術が含まれます。脆弱性スキャンツールは、ハードウェア、ソフトウェア、および構成に潜在する脆弱性を特定するために、環境を定期的にスキャンします。これらのツールは、重要度に基づいて脆弱性に優先順位を付け、予防的に対処するための修正案を提示します。

脅威インテリジェンス

脅威インテリジェンスには、新たな脅威や傾向に関する情報をリアルタイムで提供するツールや技術が含まれます。これらのツールは、公開・非公開のフィード、ソーシャルメディア、ダークWebフォーラムなど幅広い情報源を監視し、潜在的な脅威や攻撃ベクトルを特定します。この情報は、セキュリティ対策に優先順位をつけ、潜在的な脅威に能動的に対処するために利用することができます。

構成管理データベース (CMDB)

CMDB　は、IT　資産内のすべてのサービス、資産、その他の構成項目の中央リポジトリです。これらの項目のインベントリだけでなく、それらの関係や依存関係も含まれています。 CMDB　は、すべての資産変更を追跡・管理し、変更が管理された文書化された方法で行われることを保証します。

CMDB を脆弱性管理ツールや脅威インテリジェンスツールと統合することで、資産とその関係の重要性に基づいてセキュリティ対策の優先順位を決めることができます。

CAASM　ソリューションスタックは、企業が　IT　資産の潜在的な脆弱性を能動的に特定し、軽減することを可能にするツールと技術の包括的なセットです。資産の検出とインベントリ管理、脆弱性管理、脅威インテリジェンス、CMDB を組み合わせることで、潜在的なサイバー脅威に先手を打ち、重要な　IT　資産を安全に保つことができます。

IT 資産検出がリスクベースの脆弱性管理プログラムの基盤となる理由

Tue, 04 Jul 2023 11:43:36 Z

現在、236,000 件以上の脆弱性が確認されています。NVD には毎日平均 61件の新しい脆弱性が追加されているため、出現するすべての CVE や脅威ベクトルを改善することは不可能です。では、特に Everywhere Workplace のハイブリッド化とリモート化が進む中、日常的な組織はエンドユーザー、顧客、データに対する増大し続ける脅威にどのように対処すればよいのでしょうか。

第一に、ネットワークに常時接続されている資産を把握することで、リスク面をマッピングすることが重要です。 TAG Cyber のシニアセキュリティアナリストである John J. Masserini 氏と、Ivanti のセキュリティ製品管理担当部長である Chris Goettl の 2 人の専門家に、脆弱性の優先順位付けのために組織独自のサイバーリスク要因を把握する方法を聞きました。

以下のインタビューの一部をご覧ください。また、実際の RBVM プログラムでのベストプラクティスの詳細を紹介したディスカッションの全文を視聴するには、ウェビナーの録画をご覧ください。

ネットワークのすべての (確認済みの) エンドポイントを検出

Chris Goettl: サイバーセキュリティのロードマップを理解し、策定するために、誰もがセキュリティフレームワークを頼りにしていると思います。 NIST、CIS、地域別、サイバーエッセンシャル、ASD トップ 20 など、主要なサイバーセキュリティフレームワークをすべて見てみると、そのすべてに、検出と資産管理に関する要素が含まれていることがわかります。その理由は、環境に何があるのかがわからなければ、セキュリティを確保できないからです。アクティブ、パッシブ、複数のデータソースに接続し、環境に関する多くの情報を集約する能力など、検出はあらゆるセキュリティプログラムの基礎となる部分です。

Ivanti は検出に関する多数の機能を備えています。お客様との関わりやセキュリティに関する調査を通じてわかったことは、ほとんどの組織では、実際に環境で管理されているすべてのデバイスに関する理解に 20～30% のギャップがあるということです。

エンドポイント管理ソリューション、資産管理ソリューション、エンドポイント保護 (EDR や何らかの種類の脅威保護プラットフォーム) といった環境全体で 6、7 個のデータポイントを取ると、それぞれに管理対象コンピューターのセットがあります。それを調達チームと照らし合わせると、異なるデータソース間で、あるコンピューターで管理され、別のコンピューター管理されていないコンピューター割合が 2 桁になることを保証します。そのため、1 つのデータソースからでは、環境の30% 以上が見えなくなってしまいます。

サイバーセキュリティフレームワークの基礎となる最も重要な理由の 1 つは、環境における死角の 30% 以上を把握する必要があるからです。把握しなければ、脅威の脅威にさらされることになるからです。

不明な IoT デバイスが IT 環境にとって脅威となりうる理由

Chris Goettl: 懸案事項となりうる点がいくつかあります。 1 つは、そのデバイスに脆弱性がある場合です。私は、広範な DDoS 攻撃で電球が使用されているのを見たことがあります。これは、誰も脅威になるとは思っていないシンプルな IoT デバイスが、はるかに大規模な攻撃の一部になる可能性があることの一例に過ぎません。

そのデバイスに欠陥があった場合、誰かが遠隔操作で強制的に、そのデバイスを発熱体がオンになる状態にして、火災を発生させる可能性があります。デバイスがそのような方法で使用されるさまざまな可能性があります。

最近、医療関連の種類の IoT デバイスがありました。このロボットは病院内にあり、動き回り、患者の治療に必要なものを運んできたり、研究室に何かを届けたり、さまざまなことをするスタッフをサポートすることができます。これらのデバイスで、そのデバイスが近接している会話を誰かが傍受できるという脆弱性群が発見されました。デバイスは強制的に停止させることができました。デバイスは出入り口を塞いでしまうほどの大きさでした。医療施設では、重要な出入り口をふさぐと、そのデバイスが基本的にロックされ、障壁となるため、時に不利になることがあります。

これらのデバイスは、無害であるように思われても、環境に対して潜在的なリスクをもたらします。この場合、検出によって、本来あるべきデバイスを特定しましたが、管理できないものであるため、セグメント化される可能性があります。では、パッチを適用できるのでしょうか。実際にはそうではありません。ファームウェア更新はあるかもしれませんが、そこまでして管理するものでもないでしょう。それらをセグメント化しますが、環境に何があるのか、何が不利になるのか、きちんと理解しておく必要があります。

資産情報がどのようにパッチの優先順位付けに役立つのか

John Masserini 氏: 所有している資産を把握することは、脆弱性管理プログラムを構築するための基礎のようなものです。しかし、次のステップでは、組織の収益源にとってのこれらのデバイスの重要性を理解する必要があると思います。

パッチの内容や適用方法については、すべて、プログラムに関係なく、どの程度の停止を許容できるか、そのデバイスやデバイスの流れから生み出される収益はどの程度か、停止をどのように管理するか、脆弱性を解消しない場合のリスクを誰が引き受けるかという点が重要になります。そのため、業務にとってデバイスがどれだけ重要であるかを理解することは、あらゆる種類のリスク測定において大きな原動力となると考えています。リスクに基づく脆弱性管理について話すときには、個々のデバイスや個々のワークストリームでどのようにリスクを活用できるかを理解することが重要です。

私は、そのために、いつも BCP プログラムを活用しています。事業継続プログラムにとって重要なビジネスインパクト分析の実施も、アプリケーションや環境などのリスクを理解するうえで、脆弱性管理プログラムにとっても同様に重要です。ビジネスインパクト分析を行うと、ビジネスにとって非常に優れた知見が得られるのと同時に、IT 側にとっても貴重なものとなります。

ビジネスに足を踏み入れるたびに、「すぐに対応してほしい。停止は絶対に避けたい。顧客満足度を保証したい」などと言われます。そして、「それなら、これがかかるコストです」と言うと、「そんな予算はない」と返されます。すぐにこのような議論に突入してしまいますが、その際の最低限、許容できる基準は何でしょうか。隔週金曜日の午前 2 時から 4 時までの 2 時間の停止枠を確保できるのかなどと言うことができるのでしょうか。そして、これが会社の収益の 80% を支えていることを理解し、それに対して非常に敏感でなければならないのです。四半期ごとにパッチを適用することもありますが、そのような環境では、ミームなどを共有するための社内サイトとは異なるレベルのテストが行われるのは確かです。

インフラストラクチャにあるさまざまなデバイスの重要性は根本的に異なり、リスク分析を正しく行うために評価、測定する必要があります。

信じられないかもしれませんが、そのようなものの多くは、レガシーなものばかりです。古いメインフレームを運用していても、AS/400を運用していても、最先端のデバイスを運用していても、しかし、脆弱性は、ライブラリにパッチを展開するのではなく、新しいファームウェアフラッシュでなければなりません。これらはまったく異なるモデルであり、まったく異なるリスク分析の断片です。アプリケーションにパッチを適用する。WindowsのノートパソコンでChromeにパッチを適用する必要がある場合は、「この重要なルーターまで行って、夜間にファームウェアをフラッシュする」と言うのとはまったく異なるリスクプロファイルがあります。まるで異なるリスクなのです。

そこで、これらすべてがどのように連携しているかを理解することで、 BIA から得られる資産の検出とリスク分析の間に、この 2 つが、リスクに基づく脆弱性管理を中心としたあらゆる種類の長期戦略を構築するための驚異的な基礎となるのだと考えています。

ネットワークに何があるのかを知ることは、セキュリティ対策にどのような優先順位をつけるべきかを理解するための第一歩です。リスクベースのアプローチで脆弱性管理を行うことで、最も弱い部分に集中できます。資産検出では、隠れた部分まで含めてすべてを特定することができます。

実際の RBVM プログラムのベストプラクティスの詳細については、このディスカッションの続きをご覧ください。

リスクベースのパッチ管理を導入することで、アクティブなエクスプロイトに優先順位付けする方法

Tue, 20 Jun 2023 15:01:46 Z

特に実行中であり効率的で有効と考えている処理についての変更には、常に抵抗があります。セキュリティの違反もしくは事故が発生し、何が間違っていたかについて疑問に思うまでは、多くの組織がそのソフトウェア管理手順についてこう思います。

現実には、ほとんどのパッチ管理プログラムが、活発にエクスポロイとされている脆弱性についての事実ではなく、推定と推奨に基づいていると言う事です。リスクベースのパッチ管理がこの問題に対する答えです。

この記事でご覧下さい、

典型的な優先順位に従う事にどんな問題があるのか
リスクベースのパッチ管理とは
リスクベースのパッチ管理を採用する最適な時である理由

典型的な優先順位付けに従う事にどんな問題があるのか

ソフトウェア産業が始まって以来、ソフトウェア特性の更新、セキュリティー修正、バグ修正、パフォーマンスの向上、および多くのその他のタイプのソフトウェアリリースがありました。ベンダーはしばしば、それぞれに強度評価やその他のスコアを付けて、顧客に何が重要と考えられているかを伝えます。

残念ながら、これ等の評価には紐づけられた業界の水準が無く、我々は推奨に基づいてシステムでの展開についてリリースされたものを比較し優先順位を付けなければならないのです。この上に、その様な評価は脆弱性が変化してもアクティブな脅威の環境に対応するために更新される事が先ず無いのです。

悪用される脆弱性の見落とし

全く何も無いよりはましであっても、ベンダーの強度評価は余り良いものでもありません。 Follina脆弱性(CVE-2022-30190) 2022年5月公表について考えて下さい。このMicrosoft Windows Support Diagnostic Tool (MSDT)の脆弱性は、リモートコード実行を許容します。

マイクロソフトが最終的に幾つかの更新により対応するまでに、Follinaは数か月間攻撃を受けました。驚いた事に、マイクロソフトはこの脆弱性には通常の脆弱性スコアシステム（CVSS）v3にて7.8の評価と重大性を付けました。最大深刻度に基づいてパッチをするのみの場合は、あなたはこれを落とす事により重大な隙間を残してしまいます。

さらに悪い事に、FollinaのCVSSスコアは脆弱性が7.8のままとなり、活発にエクスポロイとされBisamwareランサムウェアの配布用に積極的に悪用され、これを見落とした組織をこれ以上のリスクに露呈するのです.。

Ivanti Neurons for VULN KBに表示された、CVE-2022-30190関連のランサムウェアの脅威に関連する情報があります

CVSSの短所

深刻度評価は、FIRSTのCVSSスコアで「補強」されます。各CVEにはCVSS番号が割り当てられており、上の例ではCVE-2022-30190に7.8が与えられています。

実際のCVSS番号を算出する主な目的の1つは、すべてのCVEが一貫してスコア付けされ、正確に比較できるように標準化を確実にすることです。脆弱性と関連するパッチのCVSSスコアが高ければ高いほど、ほとんどの環境において、そのパッチはよりクリティカルであることを意味します。

複数のCVEに対応するソフトウェアアップデートの場合、通常は最も高いCVSS値が優先順位付けのために考慮されます。しかしながら、この値は正確でしょうか？

最近の記事でCVSSスコアの分析の結果が発表され、CVSSスコアの20%近く(25,000)に不一致があった事が示されました。この分析はNIST National Vulnerability Database（NVD）に報告されたスコアとベンダーが直接報告したスコアの比較に基づいています。

ベンダーの脅威度についての不一致

留意すべき重要な点の1つは、ベンダーが従来より脅威度について独自の用語を割り当てている事です（例えば、クリティカル、重要）。ベンダーの重大度スコアリングを優先順位のメカニズムとして使用することは、あるベンダーのすべてのパッチを比較する場合にはうまくいくかもしれませんが、ベンダー間のパッチを必ずしも正確に比較できるわけではありません。実際、多くのベンダーはまったく異なる用語を使用しています。

同様に、ベンダーの脅威度は必ずしも肯定的な指標とはならないのです。ゼロデイ脆弱性の多くは、マイクロソフトによって「重要（Important）」としか評価されていませんが、これには高いCVSSの数値が付いています。重要度やCVSSを優先順位付けに使用したパッチ適用が、いかに仮定や推奨を使用しており、脆弱な環境をもたらす可能性があることが分かります。

何故その他の優先順位方法を取らずに、アクティブなエクスプロイトを優先するのでしょうか？

米国のCybersecurity and Infrastructure Security Agency (CISA)によると、積極的に悪用される脆弱性は、「システム所有者の許可なく、システム上でアクターによって悪意のあるコードの実行が行われたという信頼できる証拠があるもの」を指します。平たく言えば、積極的に悪用されている脆弱性とは、脅威アクターがサイバー攻撃を仕掛けるために利用した脆弱性です。

したがって、組織への攻撃のリスクを最小限化する為に、その他の全てよりアクティブにエクスポロイトされている脆弱性を優先すべきなのです。ほとんどの脆弱性はアクティブにエクスプロイトされておらず、組織へのリスクも小さいので良い知らせです。リスクベースのパッチ管理を通じてエクスプロイトされたものは識別可能です。

リスクベースのパッチ管理とは

によると、リスクベースのパッチ管理におけるガイドブック:

「リスクベースのパッチ管理は、ベンダーの脅威度と組織に対する最も重要なリスクとなる特定の脆弱性を識別し判別する為の基本のCVSSスコアに勝ります。

このリスクベースの脆弱性管理の拡張により、組織のセキュリティ態勢にとって最も重要である悪用された既知の脆弱性の更新を取り入れることで、現実のリスク状況をパッチマネジメントプロセスに反映させることができます。

組織はどの様にリスクベースのパッチ管理を取り入れる事が出来るのでしょうか？

パッチ管理についてリスクベースのアプローチを採用可能な組織については、CISA から始めると良いでしょう、既知のエクスポロイトされた脆弱性 (KEV) カタログ。 CISAは脆弱性と優先順位付けについて手助けをする為に大きな一歩を踏み出しました、拘束力のある運用指令22–01 、と共にKEV カタログであり、先ず発行された時に、カタログには約200のアクティブにエクスプロイトされた脆弱性があります。以降これは約900に増えました。

CISAは、含まれた脆弱性がアクティブな脅威にエクスプロイトされている知識を持ち、リストを作成しています。しかし、リストには短所も有り現在はランサムウェアに関連した131の脆弱性が除外されています。

CISA　KEVカタログのみがリスクベースのパッチ管理用のリソースでしょうか？

より熟成したリスクベースのパッチ管理方法を持つ組織は、この代わりにあるいは、CVSSに追加した高度なリスク評価方法でレバレッジしています。これ等の方法は組織環境で識別された全ての脆弱性についてスコアを与え、これ等の組織のCISA KEVを超えるリスクベースへの拡張を許容します。

リスクベースの脆弱性管理領域の多くのベンダーは、脆弱性がもたらす本当のリスクを表す独自の採点方法を開発しました。ベンダーは、積極的にエクスプロイトされたリスクに重みを付ける事により、動的なリスク評価を出します。

例えば、Ivantiの脆弱性リスク評価 (VRR) 、はFollinaに7.8のCVSSスコアよりも脆弱性のリスクを表す10のスコアを付けています。

VRRとCVSSｖ３スコア間とIvanti Neurons for VULN KBに示されたCVE-2022-30190の脅威度レベルの差です

リスクベースのパッチ管理を採用する最適な時である理由

システム更新が遅れたり、御社の新しいシステムやアプリケーションに圧倒されたと感じたら、リスクベースのパッチ管理. を採用する丁度良いタイミングです。

脅威度のレーティングやCVSSスコアに基づいた実質的なプログラムを持ち、変化への抵抗を捨ててて事業がエクスプロイトされた脆弱性. からのデータ侵害により途方に暮れる前に、新しいプロセスを開始して下さい。

CISA KEVを使用して更新と、割り当て、予算、リスクと脆弱性のパッチ管理ソリューションを優先して下さい。適切なツールの使用で、迅速で最も高度なリスクシステムを識別し、パッチを行い、システムをセキュアな状態するためにリストに従って下さい。

最初の一歩を踏み出そうとしていますか？リスクベースのパッチ管理におけるガイドブックをご覧ください。

エンドポイントセキュリティがパッチだけではない3つの理由

Wed, 14 Jun 2023 20:56:25 Z

リモートワークが一般的になった現在、優れたサイバー衛生プログラムを導入することは、今日の脅威の状況で生き残りを賭ける組織にとってきわめて重要です。これには、個人のサイバーセキュリティに対する意識を高める文化の推進と、適切なセキュリティツールの導入が含まれ、これらのいずれもプログラムの成功に不可欠です。

これらのツールには、エンドポイントパッチ、EDR (Endpoint Detection and Response: エンドポイント検出および対応) ソリューション、ウイルス対策ソフトウェアが含まれます。しかし、最近のサイバーセキュリティに関する報告書を見ると、組織の外部攻撃面を減らすには、これらのツールだけではもはや十分ではありません。

ここでは、この脅威に真剣に取り組まなかった組織に起こった、3つの理由と実際の状況を説明します。

AI が生成したポリモーフィック型エクスプロイトは、主要なセキュリティツールを回避できる
パッチの失敗とパッチの疲労がセキュリティチームを息苦しくしている
エンドポイントパッチは、既知のデバイスとアプリに対してのみ機能する
組織はどのようにして外部攻撃面を減らすことができるのか

1. AI が生成したポリモーフィック型エクスプロイトは、主要なセキュリティツールを回避できる

最近では、EDR やウイルス対策を回避するために、AI で生成されるポリモーフィック型マルウェアが開発され、セキュリティチームに脅威や脆弱性の死角を残しています。

事例: ChatGPT ポリモーフィック型マルウェアが「主要な」EDR およびウイルス対策ソリューションを回避

ある報告では、ChatGPT プロンプトを悪用して、ウイルス対策ソフトウェアによる検出を回避するポリモーフィック型マルウェアが開発されました。同様の報告において、研究者は、業界をリードする自動 EDR ソリューションを回避するポリモーフィック型キーロギングマルウェアを作成しました。

これらのエクスプロイトは、反復するたびにコードを少しずつ変化させ、コマンド&コントロール (C2) 通信チャネルを使わずに悪意のあるコードを暗号化することでこれを実現しました。

この変異は、従来のシグネチャベースや低レベルのヒューリスティック検出エンジンでは検出できません。つまり、パッチの開発およびリリース、パッチの有効性のテスト、セキュリティチームによる脆弱性の優先順位付け、IT (情報技術) チームによる影響を受けるシステムへのパッチの展開の理由で、セキュリティ上の時間差が生じるのです。

このため、パッチ適用が完了するまで、重要な資産を保護するために他のセキュリティツールに頼らざるを得ない状況が数週間から数か月間続く可能性があります。

2. パッチの失敗とパッチの疲労がセキュリティチームを息苦しくしている

残念ながら、パッチが厳密にテストされていないために、更新が原因でシステムが壊れてしまうということが頻繁に起こっています。また、一部の更新では、すべての脆弱性が完全に修正されないため、システムはより多くの攻撃に対して脆弱な状態のままで、完全に修正するためには追加のパッチが必要になります。

事例: サフォーク郡のランサムウェア攻撃

ニューヨーク州サフォーク郡は、最近、データ漏洩とランサムウェア攻撃 (Log4j 脆弱性が脅威主体の入口となり、システムが侵害されたインシデント) に関するフォレンジック調査の結果を発表しました。この攻撃は、2021 年 12 月に始まり、Apache がこれらの脆弱性に対するセキュリティパッチをリリースしたのと同じ時期でした。

更新が利用可能であったにもかかわらず、パッチが適用されたことは一度もありませんでした。その結果、数千件の社会保障番号を含む 400 ギガバイトのデータが盗まれ、最初の身代金要求額は 250 万ドルでした。

身代金は支払われませんでしたが、個人データの損失、職員の生産性の低下、その後の調査のコストは、サイバー衛生アプライアンスとツールの更新コストと最終的な身代金の要求額である 50 万ドルを上回っていました。同郡では、すでに 550 万ドルを費やして、今日もまだすべてのシステムの復旧および復元に取り組んでいます。

事例: Windows サーバーの更新エラーのため業務が 24 時間連続で停止

個人的な経験ですが、ある Patch Tuesday で、Microsoft Windows サーバーの更新プログラムが自動的にダウンロードされ、インストールされた結果、IoT (モノのインターネット) クライアントとAAA (認証、認可、アカウンティング) サーバー間の認証サービスが破損し、生産が大幅に停止してしまい、24 時間連続で対応に当たらなければならなかったことがありました。

当社の最大規模のお客様が導入した社内顧客リファレンスネットワークでは、Active Directory Certificate Services (ADCS) と、無線で管理された IoT ネットワーク機器の 802.1x EAP-TLS 認証に用いる Network Policy Servers (NPS) に Microsoft サーバーを導入していました。

これは 10 年前に起こったことですが、この 2017年7月の更新 (無線クライアントの NPS 認証が壊れる問題が昨年5月に繰り返されたなど) その後数年間も同様の問題が再発しています。

当時は、エラーのあるパッチをすぐに修正することができなかったため、私はその後 22 時間かけて、企業の公開鍵基盤 (PKI) と AAA サービスの Microsoft サーバーを再構築し、通常の運用を復旧させました。救いは、元のルート認証局をオフラインにしたことで、サーバーが問題のある更新の影響を受けなかったことです。

しかし、結局、ルーター、スイッチ、ファイアウォール、アクセスポイントなど数千台の機器に対して下位認証局が発行した　ID　証明書をすべて失効させ、新しい　ID　証明書で　AAA　サービスに再登録する必要がありました。

この経験を教訓に、すべての Windows サーバーの自動更新を無効にし、重要なサービスやデータのバックアップをより頻繁に取るようにしました。

3. エンドポイントパッチは、既知のデバイスとアプリに対してのみ機能する

パンデミックに伴い、従業員が自宅や会社のネットワークに個人所有のデバイスを接続して仕事をする、Everywhere Work というスタイルに移行しました。このため、セキュリティチームはシャドー IT となる盲点を抱えていました。シャドー IT では、資産は管理されず、最新の状態ではない可能性があり、個人のデバイスが危険にさらされたり、アプリケーションからの情報漏洩の原因となっています。

BYOD (Bring Your Own Device: 個人デバイスの業務使用) ポリシーの復活と、会社公認の安全なリモートアクセスの欠如は、組織の外部攻撃面を急速に拡大し、脅威主体が悪用する他の攻撃ベクトルを露出させました。

事例: LastPass の最近の侵害

LastPass は、パスワードをオンライン格納域に保管する、非常に人気のあるパスワードマネージャーです。 2,500 万人以上のユーザーと 10 万社以上の企業が利用しています。昨年、LastPass は 2 件のセキュリティインシデントを含む大規模なデータ侵害を経験しました。

2 件目のインシデントでは、最初の侵害で盗まれたデータが利用され、4 人の DevOps エンジニア (特にホームコンピューター) が標的にされました。ある上級ソフトウェア開発者は、個人の Windows デスクトップを使用して、企業の開発用サンドボックスにアクセスしていました。また、このデスクトップには、パッチが適用されていないバージョンのPlex Media Server (CVE-2020-5741) がインストールされていました。

Plex は 3 年前にこの脆弱性に対するパッチを提供していました。脅威主体はこの脆弱性を利用してマルウェアを配信し、特権昇格 (PE)、リモートコード実行 (RCE) を行い、LastPass のクラウドベースストレージにアクセスして DevOps のシークレットや多要素 (MFA) およびフェデレーションデータベースを盗み出しました。

Plex は次のように述べています。「残念ながら、LastPass の従業員は、パッチを有効にするためにソフトウェアをアップグレードすることは決してありませんでした。参考までに、このエクスプロイトに対応したバージョンは、およそ 75 バージョン前です。」

パッチでは十分でない場合、組織はどのようにして外部攻撃面を減らすことができるのか

サイバーハイジーン

従業員は、組織のサイバーハイジーンプログラムにとって最も弱いリンクです。また、必然的に、個人所有のデバイスの更新を忘れたり、異なるインターネットサイトで同じ弱いパスワードを使い回したり、情報漏洩の原因となるアプリケーションをインストールしたり、電子メールや添付ファイル、テキストメッセージに含まれるフィッシングリンクをクリックしたりタップしたりすることがあります。

このような事態に対処するため、以下のようなサイバーセキュリティに対する認識と警戒を促す企業文化を推進します。

- 個人および会社のデバイスに最新のソフトウェア更新がインストールされていることを確認する。

-フィッシング攻撃など、ソーシャルエンジニアリングの攻撃手法を認識する。

-可能な限り多要素認証を使用する。

- デスクトップ向けのウイルス対策ソフトやモバイルデバイス向けのモバイル脅威対策に関するデータベースのインストールと自動更新を行う。

特にフィッシング対策については、継続的な教育が組織内のサイバー衛生を向上させる鍵となります。

推奨されるサイバー衛生ツール

サイバーセキュリティでは、「見えないものは守れない」と言われています。シャドー IT資産を含む、ネットワークに接続されたすべてのハードウェア、ソフトウェア、データについて、完全かつ正確なインベントリを確立し、把握することは、組織の脆弱性リスクプロファイルを評価するための重要な第一歩となるものです。資産データは、企業のエンドポイントパッチ管理システムに入力する必要があります。

また、リスクベースの脆弱性管理アプローチを導入し、圧倒的な数の脆弱性の中から、組織にとって最大のリスクをもたらすものだけに優先順位をつけることも検討してください。リスクベースの脆弱性管理ソリューションには、脅威インテリジェンスをパッチ管理システムに取り込むことがよくあります。

脅威情報とは、組織に対する既知の脅威や潜在的な脅威に関する情報です。これらの脅威は、セキュリティ研究者、政府機関、インフラの脆弱性やアプリケーションのセキュリティスキャナー、社内外の侵入テストの結果、さらには脅威主体自身など、さまざまな情報源からもたらされます。

さまざまなクラウドから取得されたフィードから報告される具体的なパッチの失敗や信頼性を含むこの情報は、組織が内部のパッチテストの要件を取り除き、重要な資産へのパッチ展開の時間差を短縮するのに役立ちます。

シャドー IT や BYOD などのモバイルデバイスをリモートで管理し、エンドポイントセキュリティを提供するためには、統合エンドポイント管理 (UEM) プラットフォームが必要です。

このソリューションは、最新のモバイルオペレーティングシステム (OS) やアプリケーションへのパッチ適用、電子メールのプロビジョニング、生体認証、スマートカード、セキュリティキー、証明書やトークンに基づく認証などの ID 資格情報や多要素認証 (MFA) 方式を含む安全なリモートアクセスプロファイルの提供を行うことができます。

UEM ソリューションは、モバイルデバイス向けの AI 機械学習ベースのモバイル脅威防御 (MTD) ソリューションも統合する必要があります。デスクトップには、リアルタイムのフィッシング対策でデバイス、ネットワーク、アプリの脅威を検出して修復する堅牢なヒューリスティックを備えた次世代ウイルス対策 (NGAV) が求められます。

そして最後に、AI が生成するマルウェアと闘うために、サイバー衛生ツールは、AI ガイダンスを活用して迅速に進化し、より巧妙なポリモーフィック攻撃に対応する必要があります。

上記のようなソリューションを追加することで、脅威主体の前に障害物を置き、脅威主体を食い止め、被害を受けやすい標的を探し出すことで、サイバー攻撃を抑止することができます。

Ivantiブログ: セキュリティ

パッチ・アポカリプスの時代です。IT部門のこの3つの言い訳は、もはや通用しません。

「当社には脆弱性スキャナーがあります」

「当社はチケットシステムで承認を回しています」

「当社にはIntuneがあります」

どう対応すべきか

Trusted Ownership：Ivanti Application Control が許可リストを超えて拡張できる理由

リストを超えて：プロビナンス制御が今重要な理由

ブロックリストを超えて：最新のソフトウェア展開に対応する広範なカバレッジ

WDAC（App Control for Business）の位置付け

LOLBins と引数レベルの制御

Trusted Ownership の実践：実際のシナリオ

まとめ

CEOがCISOに求めるサイバーセキュリティリスク管理戦略の伝え方

サイバーリスクのコミュニケーションが失敗する理由：知識の呪い

CEOにとって重要なサイバーセキュリティKPI

CISOが伝えること：

CEOが実際に知る必要があること：

経営層レベルのリスクアペタイト・フレームワークの構築

エクスポージャー管理がコミュニケーションギャップを埋める仕組み

今後の方向性

エクスポージャー管理と脆弱性管理：真のリスク低減を実現するのはどちらか？

脆弱性管理とは何か？

エクスポージャー管理とは何か？

エクスポージャー管理と脆弱性管理：違いは何か？

組織を保護する方法

DLLハイジャック：リスク、実例、攻撃を防ぐ方法

DLLハイジャックとは何か、どのように発生するのか

DLLハイジャックを防ぎ、DLLを安全に保護する方法

安全なDLL読み込み：

ファイル整合性チェック：

ユーザー権限：

アプリケーション制御と権限管理：

セキュリティソフトウェア：

パッチ管理：

適切なツールと対策を組み合わせてDLLハイジャックを防ぐ

ITAM：サイバー脅威防御における想定外の第一線

ITAMが重要な理由：サイバーセキュリティの課題は不十分な可視性から始まる

サイバーレジリエンスにおけるITAMのメリット

ライフサイクル管理により弱点を排除

規制コンプライアンスにより統制を証明し、罰則を回避

ITAMとセキュリティの連携：単なるインベントリ追跡を超えて

レジリエントなサイバー防御には堅牢な資産管理が不可欠

シャドーAIは職場のセキュリティ態勢を静かに変えつつあるのか？

シャドーAIとは

AIにリスク優先アプローチが不可欠な理由

IvantiにおけるAIガバナンスフレームワークの導入

AI利用を見える化する

AIの実装と導入に対する慎重なアプローチ

AIツールのフィードバックループを構築する

シャドーAIに先回りして対処する

エンタープライズセキュリティにおいて SELinux が重要な理由

SELinux の違いと優位性

SELinux の仕組み

実例：Oracle Linux の導入

ビジネス価値をもたらすセキュリティテクノロジー

SELinux の価値に関するまとめ

セキュリティに対する Ivanti のコミットメント

プロアクティブなサイバーセキュリティとは？組織を守るための対策

事後対応型とプロアクティブなサイバーセキュリティの違いとは？

プロアクティブなサイバーセキュリティ対策の例

攻撃対象領域管理

脆弱性スキャン

脆弱性管理

エクスポージャー検証

パッチ管理

構成管理

ユーザー教育

プロアクティブなサイバーセキュリティ対策への支持を得る

プロアクティブなサイバーセキュリティが重要な理由

ソフトウェア サプライチェーン攻撃を無視できない理由

増加するソフトウェア サプライチェーン攻撃のリスク

一般的なソフトウェア サプライチェーン攻撃の種類

サプライチェーン攻撃の最近の事例

Okta 社へのソーシャルエンジニアリング攻撃

Kaseya 社へのランサムウェア攻撃

Codecov 社への CI/CD 攻撃

サプライチェーン攻撃が及ぼす深刻な影響

財務への影響

業務への影響

ソフトウェアサプライチェーン攻撃を無視できない理由

増加するソフトウェアサプライチェーン攻撃のリスク

一般的なソフトウェアサプライチェーン攻撃の種類

責任の所在は？技術上の負債と共同責任

ソフトウェアサプライチェーンの脅威に対する防御方法

ソフトウェアサプライチェーンのセキュリティについて詳しく知る