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 調査レポート：攻撃対象領域の管理

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

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

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

クラウドへの移行でインフラを不要にし、メンテナンスコストを削減

Mon, 04 Nov 2024 15:50:11 Z

今日、企業は業務を効率化し、競争優位性を高める方法を絶えず模索しています。しかし、多くの企業はオンプレミスITインフラの負担とコストに悩まされています。そのため、クラウド移行のメリットを検討する企業が増えています。

この記事では、クラウド移行のメリットと、それがコスト削減、ビジネスの拡張、業務改善にどのように役立つかを見ていきます。オンサイトインフラの廃止、メンテナンスコストの削減、最新のセキュリティテクノロジーの活用が、あらゆる規模の企業にどのように貢献するかについて説明します。

コストを削減し、拡張性を高める

クラウドへ移行し、従量課金モデルを活用することで、企業はサーバー、ソフトウェア、データセンターなどのオンサイトインフラに多額の投資を行う必要を回避できます。これにより、ハードウェアやソフトウェアの購入・維持に伴う設備投資をなくし、貴重な財務リソースを事業の他の領域へ再配分できます。

拡張性も、クラウドへ移行する大きなメリットのひとつです。企業はニーズに応じてITリソースを容易に増減でき、使用したリソース分だけを支払うことができます。これは、ワークロードの変動が大きい企業や季節的な需要がある企業に特に有効です。インフラを過剰にプロビジョニングしないことで、IT支出を最適化し、不要なコストを回避できます。

さらに、クラウドは最新のハードウェアとソフトウェアを活用する機会を広げ、企業のパフォーマンスと俊敏性の向上を後押しします。クラウドプロバイダーがインフラの更新とメンテナンスを担うため、企業はシステムの管理や更新の負担から解放され、コアビジネスに集中できます。これにより、競争力と対応力を維持しながら、イノベーションと成長を促進できます。

オンサイトインフラを不要にしてコストを削減

クラウドへの移行は、ハードウェアの購入や保守が不要になるだけではありません。オンサイトインフラの継続的なコストも大幅に削減できます。クラウドへ移行することで、企業は物理サーバー、ストレージシステム、ネットワーク機器の維持にかかるコストを回避できます。つまり、ハードウェアへの設備投資、電力・冷却コスト、メンテナンス契約が不要になります。その代わりに、企業はその資金を成長とイノベーションを推進し、事業を前進させる取り組みに充てることができます。

さらに、オンサイトインフラの必要性を減らすことで、その維持やトラブルシューティングを行うIT担当者の採用も抑えられます。つまり、既存のITチームは日常的なメンテナンスに費やす時間を減らし、ビジネス価値を生み出す他のプロジェクトにより多くの時間を割けます。また、クラウドプロバイダーと連携すれば、専門家チームがクラウドインフラを常時監視・最適化し、高い信頼性と最高レベルのパフォーマンスを確保します。

また、クラウドプロバイダーは規模の経済を活かせるため、オンプレミスソリューションよりも低コストでインフラサービスを提供できます。これは、最先端のデータセンターへの大規模投資、エネルギー効率の高いテクノロジーの採用、リソース利用の最適化によって実現されています。その結果、企業は品質やパフォーマンスを犠牲にすることなくコストを削減できます。これは、競争の激しい今日の環境において特に重要です。

アップグレードやパッチ適用の心配が不要に

クラウドコンピューティングの大きなメリットは、オンプレミスでのアップグレードやパッチ適用が不要になることです。この移行により、人的ミスやアップグレードの遅延のリスクを低減しながら、ITリソースを戦略的なビジネス施策に集中させることができます。システム更新やパッチに関するベンダー管理の複雑さを取り除くことで、組織はIT運用を大幅に効率化できます。

さらに、クラウドコンピューティングプロバイダーは、信頼性と安全性に優れたデータバックアップおよび災害復旧ソリューションを提供します。つまり、自然災害やシステム障害が発生した場合でも、企業はデータを迅速かつ容易に復元し、大きな中断なく業務を継続できます。このレベルのデータ保護とレジリエンスは、オンプレミスシステムでは実現が難しく、コストも高くなりがちです。クラウドコンピューティングにより、企業は貴重なデータが常にバックアップされ、すぐにアクセスできる状態にあるという安心感を得られます。

オンプレミスのアップグレードによるダウンタイムを解消

クラウドへ移行する最も魅力的なメリットのひとつは、オンプレミスインフラのアップグレードに伴うダウンタイムをなくせることです。こうしたアップグレードは定期的に必要となる場合があり、多くの場合、長時間のダウンタイムや業務の中断を伴います。その結果、生産性や収益の損失に加え、顧客満足度の低下を招く可能性があります。

一方、クラウドコンピューティングでは、シームレスで継続的なアップグレードプロセスを利用できます。クラウドプロバイダーがすべてのインフラメンテナンスとアップグレードを担い、企業のダウンタイムを最小限、またはゼロに抑えます。これにより、組織はIT管理の複雑さを心配することなく、自社の中核業務に集中できます。ダウンタイムを解消することで、途切れない業務運営を維持し、顧客満足度を向上させ、競争優位性を獲得できます。

さらに、クラウドコンピューティングでは、最先端のセキュリティ対策やコンプライアンス認証を利用できます。クラウドプロバイダーは堅牢なセキュリティインフラに多額の投資を行い、専任のセキュリティチームを配置してデータとシステムを保護します。そのため、企業は自社のセキュリティインフラに大規模な投資を行うことなく、より高度なセキュリティを享受できます。これはコスト削減につながるだけでなく、業界の規制や標準への準拠も確実にします。

環境への配慮を示す

セキュリティに加えて、クラウドコンピューティングは環境の持続可能性にも貢献します。クラウドへ移行することで、企業はエネルギー消費を抑え、ハードウェア廃棄物を最小限にすることで、カーボンフットプリントを削減できます。持続可能性と責任あるリソース管理の重要性が高まる中、これは特に重要です。クラウドコンピューティングの導入は、賢明なビジネス判断であるだけでなく、より環境に配慮した未来への企業のコミットメントを示す方法でもあります。

まとめると、クラウド移行はダウンタイムを解消し、オンプレミスインフラのコストをなくし、セキュリティを強化します。クラウドへの移行は、効率性、拡張性、競争優位性を追求する企業に戦略的なメリットをもたらします。

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

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 環境への扉を開くテクノロジーはさらに増えていると言ってよいでしょう。

ITリスク管理プロセスを簡素化する方法

Mon, 08 Apr 2024 17:30:01 Z

それは、過ぎ去った時代の色あせたポラロイド写真のようなものです。中央集権型のソフトウェアを搭載したコンピューターが、オフィス内に安全に施錠されていた時代。ほとんどの組織にとって、それはすでに過去の時代であり、懐かしく思い出される一方で、現在の実態からは大きくかけ離れています。

今日、企業のITインフラストラクチャとどれほど多くのデバイス、資産、人が関わっているかを考えてみてください。

デバイス（デスクトップ、ノートPC、モバイル、IoTデバイス。会社所有および個人所有を含む）。
ソフトウェアとアプリケーション（クラウドベースが増え、組織の管理外に置かれることも多い）。
デジタル資産とドキュメント。
APIとインテグレーション。
社内担当者、リモート／ハイブリッド勤務の従業員、フリーランサー、請負業者、ベンダー。

さらに、これらのデバイス、アプリケーション、資産の多くは、IT部門やサイバーセキュリティチームから見えない、広範なシャドーIT環境の一部である可能性があります。

この拡大するエコシステムは、同様に複雑なITリスク環境を生み出しています。軽減されていないITリスクは、企業の財務、機能、士気、評判に大きな影響を及ぼす可能性があります。組織が直面するサイバーセキュリティ脅威の絶え間ない流れと、それらがもたらす現実的な影響により、堅牢なITリスク管理プロセスの必要性は極めて明確になっています。

この簡潔なITリスク管理ガイドでは、次の内容を取り上げます。

ITリスク管理とは何か。
ITにおけるリスク管理の5つのステップ。
従うべきITリスク管理プロセスと戦略。
ITリスク管理のベストプラクティス。

ITリスク管理とは何か

企業は、組織と業務のほぼあらゆる側面で、何らかの「リスク」に向き合っています。しかし、ITリスク管理について語るとき、私たちが意味するのはサイバーセキュリティリスクです。

これまで見てきたように、複雑なITプロセスやツールが組織の日常業務に組み込まれるにつれて、それに伴うリスクも増加しています。そこで登場するのがITリスク管理です。これは、リスク管理の原則をIT組織に適用する取り組みです。

ITリスク管理には、組織の資本と収益に対するリスクを特定、評価、優先順位付けすることが含まれます。また、それらのリスクの影響を最小化、監視、制御するための対策を講じることも含まれます。

簡単に言えば、重要なビジネス資産を保護し、ルールや標準への準拠を確保し、良好なイメージを維持し、十分な情報に基づく意思決定を行い、困難な状況においても円滑な運用とレジリエンスを確保することです。

リスク管理は組織にとって新しいものではありません。ここで重要なのは、よく知られたプロセスと手順を、拡大するIT関与のネットワークに適用することです。組織がITリスク管理計画を構築する際には、リスクマネージャーやリスク修復アナリストといった従来からある役割を配置することが多くあります。これらの役割には、一般的なリスク管理の実践に対する深い理解だけでなく、リスクを適切に評価し修復するためのITの背景知識も求められます。

新たなサイバーリスク環境

ただし、大きな課題は、ITチームとサイバーセキュリティチームが対処しなければならないリスクが止まっていないことです。実際、その絶えず変化する性質こそが特徴であり、最大のリスク源とも言えます。

過去5年間で、ITリスク管理の性質は大きく進化し、絶えず変化するサイバーリスク環境の課題に対応するために、その範囲と意味を広げてきました。

ITリスク管理を簡素化するという課題は、ますます複雑になっています。なぜなら、直面する脅威は多くの点で、従来の「リスク」の定義に当てはまらないからです。

ITリスクとそれが影響を及ぼす領域の定義

まずは基本的な問いから始めましょう。私たちは実際にどのようなリスクに対処しているのでしょうか。少し前のリスクとは、もはや同じではありません。

本質的には、ITリスクは、侵害されたデータセンター、個人のコンピューターの脆弱性、悪意のあるウイルスとして現れる可能性があります。しかし、今日のより多様で流動的な脅威に対しては、リスクベースの脆弱性管理（RBVM）を検討し、このプロセスを自動化する方法を探る必要があります。さらに、DevSecOpsの実践を採用することで、リスクを先回りして防止する必要があります。

前提を整えるために、ITリスクとセキュリティリスクの違いを整理しましょう。

ITリスクとは、ITの障害または不正使用に関わる潜在的なマイナスの結果を指します。
セキュリティリスクとは、安全性に対して潜在的な脅威となる、または組織に損害を与える可能性のある人や物事を指します。

サイバーセキュリティの環境が変容するにつれて、脅威と脆弱性に対する私たちの概念も形を変えてきました。組織は脅威に直面し、その脅威にさらされる状態が脆弱性です。その脆弱性が悪用されると、リスクになります。つまり、ITリスク管理はITの脆弱性を管理することにかかっています。脅威を完全に排除することはできないかもしれませんが、継続的な脆弱性管理によって、その影響を調整し抑制することはできます。

IT脆弱性管理の中核となる2つの領域が、IT資産管理（ITAM）とITサービス管理（ITSM）、そしてそれらが導入するテクノロジーです。

ITAMは、組織の物理的およびデジタル資産をライフサイクル全体にわたって追跡し最適化することで、重要なリソースの効率的な利用と適切な取り扱いを確保します。
ITAMツールは、ハードウェアやソフトウェア資産などの構成アイテム（CI）の管理を提供し、IT部門がCIをライフサイクル全体にわたって構成、最適化、追跡できるようにします。
ITSMは、組織のニーズを効率的かつ効果的に満たすために、ITサービスを設計、提供、管理、改善する実践です。そのツールとベストプラクティスにより、エンドユーザーやその他の社内クライアントからのテクノロジー関連の要求をIT部門が追跡し、対応し、サービス提供する能力が向上します。
ITSMツールでは、レベルゼロのヘルプデスクサポートを実現する取り組みの一環として、ユーザーが単純で一般的な技術的問題を自分で解決する「セルフサービス」も可能になります。
ITリスクの制御に関わるもう1つの領域があります。それはエクスポージャー管理です。これは、悪用される前に潜在的な脆弱性とセキュリティリスクをプロアクティブに特定し軽減する新興分野です。

ITネットワークとサイバー脅威がどれほど複雑になっているかを説明してきましたが、これらのツールはどのようにITリスク管理の簡素化に役立つのでしょうか。

適切な機能を備えたITAMおよびITSMのテクノロジープラットフォームは、組織がクローズドループ型のセキュリティプロセス内でIT運用を統合するのに役立ちます。そこでは、脆弱性の検出、評価、修復が自動化され、継続的かつプロアクティブに行われます。

もちろん、重要なキーワードは「自動化」です。脆弱性にパッチを適用したり、問題をユーザーに影響が及ぶ前に修復したりできれば、人による介入は不要です。これにより、セキュリティへの影響や、ヘルプデスクへの問い合わせの必要性さえも防ぐことができます。

ITセキュリティのワークロードをシフトレフトする

したがって、IT部門が使用するツール、特にITAMとITSMは、その自動化を活用することで、セキュリティ部門の「シフトレフト」を支援できます。これにより、より少ない労力とコストでより多くのセキュリティ対策を実行でき、プロアクティブなリスク修復へと発展させることができます。

ITAMとITSMの自動化を活用して、セキュリティチームの業務を軽減する方法にはどのようなものがあるでしょうか。

エンドユーザー向けセルフサービスオプションの改善

セキュリティ関連のリクエストや質問のトリアージを自動化し、低レベルのリクエストを下位層の担当者に振り分けることで、シニアアナリストをフィッシングの識別などの作業から解放します。セキュリティWiki内にファイルアクセスやポリシー例外のリクエストフォームを実装し、レベルゼロのセルフサービス型ユーザーサポートを可能にします。

セキュリティインシデント解決の統合

ITチケット管理ソフトウェアと優先順位付けキュー（リクエストフォームから入力されるもの）を転用し、優先順位付け、追跡、文脈把握を改善します。

バックグラウンドのIT自動化をセキュリティユースケースに転用する

特定の設定に基づいてトリガーされるITAMおよびITSM内の同じプロアクティブなIT自動化を複製し、調整することで、エンドポイント環境の保護や悪意ある活動の検知など、幅広いセキュリティ目的に対応できます。

自動化トリガーを設定する

セキュリティチームは、既存のCIを活用し、ITAMの構成管理データベース（CMDB）で追跡されるセキュリティ固有のカスタム変数を作成して、自動化式のトリガーおよび構成要素として使用できます。

セキュリティ適用の自動化

ユーザーに対して一般的なコンピューターポリシーを適用する同じIT機能で、セキュリティプロトコルのレポートと適用も行えます。たとえば、ポリシー違反の可能性や内部脅威が検出された際にアラートを送信できます。

ITリスク管理を効率化する5つの鍵

ITリスク管理の簡素化と最適化は、IT部門だけで実現するものではありません。導入するプロセスやツールの効率性と有効性を高めるためのあらゆる施策に対して、組織のサイバーセキュリティチームも当然ながら大きな関心を持っています。そのため、ITリスク管理を改善するうえでの重要なステップの多くは、IT部門、セキュリティ部門、その他の関係者の間のコミュニケーションとコラボレーションを中心に展開されます。

以下のポイントについてさらに詳しく知りたい場合は、当社のeBook「対立から協力へ」をご覧ください。

1. セキュリティチームは計画と依頼内容を説明する

一方的な指示は避け、セキュリティ計画、変更、依頼の背景にある戦略とメリットを組織の関係者に説明しましょう。セキュリティ計画を開始する前に、CISOはセキュリティ戦略とその実装計画を共有する必要があります。説明のないセキュリティ依頼は、IT部門の不満を招きやすいためです。

時間や対応能力の制約により、変更が求められる理由の説明なしにセキュリティ依頼が出されることがあります。これにより、IT部門が依頼を実装するのが難しくなる場合があります。セキュリティチームは、自分たちの依頼をIT部門がどのように実装できるかを考慮することが重要です。

2. IT部門の負担を意識する

セキュリティチームは、依頼を行う前にITチームのワークロードを常に考慮する必要があります。IT部門は大規模なプロジェクトに対応している最中かもしれず、そのタスクを処理するのに十分な人員がいない可能性もあります。ITチームがセキュリティポリシー、依頼、パッチを実装しやすくするツールやシステムを探すことが不可欠です。

リスクベースの脆弱性管理（RBVM）とITSMを組み合わせることで、重要なタスクを自動的に優先順位付けし、誤って優先順位付けされたタスクを除外できるため、IT部門の負担を軽減できます。

次の点を考えてみてください。任意の時点で、Common Vulnerability Scoring Systemによって約25万件の脆弱性が特定され、高、中、低のリスクに分類されています。そのうち約38,000件が武器化されており、約11,000件、つまり4%が危険と見なされています。RBVMの観点から見ると、CVSSによって「重大」とフラグ付けされたリスクの多くは実際には重大ではありません。高および中の脆弱性の中でも最も危険な4%まで絞り込めるからです。CVSS標準で特定された脆弱性をこのように再分類することで、ITチームが注力すべき真に重要な脆弱性へと注意を大きく向け直すことができます。

3. コラボレーションを受け入れる

ITリスク管理の効率化に向けて協力する部門は、互いに利益のある成果を達成するために連携する必要があります。結局のところ、それぞれに優先事項があります。IT部門は運用を円滑に進めたい一方で、セキュリティ部門は問題を可能な限り迅速に管理したいと考えています。

ITリスク管理のプロトコルとプロセスを構築する際に協力し、柔軟性を持たせることで、双方が成果を得ることができます。この柔軟性を生み出す方法の1つが、相互に合意されたサービスレベル契約（SLA）を確立することです。

4. 共通の目標を設定する

セキュリティ部門とIT部門には共通点があります。どちらも、組織、ユーザー、プロセスを円滑に稼働させ続けたいと考えています。そのため、ITとセキュリティのリーダーシップが目標をすり合わせ、主要業績評価指標（KPI）、ダッシュボード、その他の指標を設定して、それらを追跡し強化することが不可欠です。

また、組織が戦略目標を導入することの意味を理解し、製品、プロセス、人に及ぶ影響が、その目標を確定する前に把握されていることも重要です。

5. 助け合う

セキュリティチームとITチームの間で管理リソース、技術的専門知識、ツールを共有することで、コストを削減し、コラボレーションを促進できます。たとえば、セキュリティ部門が自分たちのユースケースのためにITツール、ポリシー、プロセスを借りる場合は、その見返りとなるものを提供すべきです。

共有されたツール、ダッシュボード、レポートは、両チームが互いの領域を理解するための文脈を生み出し、共感と信頼を築きます。

企業のデジタルネットワークに対して現在広がっている脅威を考えると、このようなコラボレーションは極めて重要です。

MDM 対 MDM：モバイルデバイス管理とモダンデバイス管理の違いとは？

Mon, 06 Nov 2023 19:40:47 Z

モバイルデバイス管理とモダンデバイス管理は、一見似て聞こえるかもしれませんが、両者には大きな違いがあります。企業内でこれらのデバイスが爆発的に増加していることにより、組織がそれらを監視・管理するための適切なプラットフォームを選択することが極めて重要になっています。

このブログ記事では、以下について見ていきます。

「モバイルデバイス管理」と「モダンデバイス管理」のそれぞれの意味。
2つのプラットフォームの違いと共通点。
多くの人が両者を混同する理由 — 共通する「MDM」という略語だけが理由ではありません。

モバイルデバイス管理とは？

モバイルデバイス管理 — この記事では「モバイル MDM」と呼びます — は、次のように定義できます。

モバイルデバイス管理とは、組織のITチームやセキュリティチームが、スマートフォン、ノートPC、タブレットなど企業のモバイルデバイスを、さまざまな場所、形式、オペレーティングシステム（OS）にわたって管理し、保護するためのテクノロジーです。

モバイル MDM ソリューションは、システム管理者が1つのダッシュボードから複数のモバイルデバイスのハードウェアおよびソフトウェア設定を効率的に構成、監視、更新できるようにします。

このように、モバイル MDM は、エンドユーザーのデバイス利用が、直接管理されている場合でも、Bring Your Own Device（BYOD）ポリシーに基づいて組織のアプリへのアクセスが許可されている場合でも、企業ポリシーに準拠し、エンドポイントに保存またはエンドポイント経由でアクセスされる機密データを保護できるようにします。

モバイル MDM ソリューションには、通常、次のような機能が含まれます。

ポリシーの適用。
ソフトウェアのインストール／更新管理。
リモートワイプ機能。
デバイスの追跡／監視。
ユーザー認証／認可の制御。
資産インベントリ管理。

管理者が、デバイスの種類やオペレーティングシステムに関係なく、単一のコンソールまたはダッシュボードから組織内のすべてのモバイルデバイスでこれらの設定をリモート管理できるようにすることで、モバイル MDM ソリューションは、組織が接続されたすべての資産に対して一貫したセキュリティポリシーを維持することを大幅に容易にします。

さらに、ほとんどのモバイル MDM ソリューションは、エンタープライズモビリティ管理（EMM）を強力にサポートしています。EMM は、管理者が特定のエンドユーザーごとに、どのアプリケーションをインストールまたはアクセスできるかについてきめ細かなアクセス制御を適用できるようにすることで、モバイルエンドポイントに追加のセキュリティ層を提供します。

このきめ細かさにより、特定の従業員ユーザープロファイルは、組織が承認したアプリストアを通じて承認済みアプリケーションのみにアクセスできるようになり、同時に各ユーザーのアプリケーション利用状況やデータ共有アクティビティを詳細に可視化できます。

これらのセキュリティ機能に加えて、多くのモバイルデバイス管理ソリューションは高度な分析機能も提供しており、組織は接続されたデバイス群全体におけるエンドポイントデバイスとデータ利用の傾向について、有益なインサイトを得ることができます。

これらのエンドポイント分析は、組織が次のことを行うのに役立ちます。

潜在的な問題領域を特定し、深刻な脅威になる前にプロアクティブに対処する。
ユーザーエクスペリエンスを向上させながら、ITおよびテクノロジーリソースを最適化する。

総じて、モバイル MDM ソリューションは、機密データ資産に対して高いレベルのセキュリティを維持しながら、複数のモバイルデバイス管理プロセスを効率化したい組織にとって強力なツールです。

モダンデバイス管理とは？

モダンデバイス管理 — この記事では「モダン MDM」と呼びます — ソリューションは、組織のデバイス管理における革新的な進化を表すもので、次のように定義できます。

モダンデバイス管理とは、組織のネットワーク環境内で従業員が使用するすべてのデバイスの標準化、追跡、制御に重点を置くエンドポイント管理テクノロジーの一形態です。

より具体的には、モダン MDM ソリューションは、組織がデータ、アプリケーション、ネットワークを悪意のある攻撃や不正アクセスから保護するのに役立ちます。また、すべてのデバイスを1つの統合システム内で一元管理できるようにします。

モダン MDM ソリューションは、企業が業務で使用するさまざまな種類のデバイス — スマートフォンやタブレットから、ノートPC、デスクトップコンピューター、サーバーまで — を制御できるように設計されています。

モダン MDM ソリューションは、システム管理者が次のことを行えるようにします。

各デバイスの設定をリモートで構成する。
利用アクティビティを監視する。
特定の機能またはアプリケーションに制限を適用する。
セキュリティポリシーを適用する。
アプリケーションの更新とパッチを展開する。
従業員の電話やその他のデバイスに保存されている、またはそれらを通じてアクセスされる組織データを保護する。

モダン MDM は、次のような高度な機能も提供します。

デバイスの紛失または盗難時に機密データをリモートで消去する機能。
所在不明のハードウェアを特定するためのジオフェンシング機能。
より優れた資産管理のための位置情報追跡。
複数のエンドポイントに新しいアプリケーションを迅速かつ容易にインストールするためのソフトウェア配布。

（もちろん、これらすべての機能は、すべての従業員のプライバシー権を法的に尊重する形で、責任を持って使用する必要があります。）

MDM と MDM の比較：モバイルデバイス管理とモダンデバイス管理の違いとは？

モダンデバイス管理とモバイルデバイス管理には、主に2つの違いがあります。

各 MDM が対象とするデバイスの種類。
各 MDM の主な重点領域。

MDM の違い #1：モダンデバイス管理ソリューションは、モバイルデバイス管理よりも多くの種類のエンドポイントを対象にする

モバイルデバイス管理とモダンデバイス管理（MDM）を比較すると、両者の最初で最も明確な違いは、対象範囲にあります。

モバイルデバイス管理は、スマートフォン、タブレット、ノートPCなどの従来型のモバイルデバイスを対象とします。
モダンデバイス管理は、以下を含む、ただしこれらに限定されない、より広範な接続ネットワークデバイスを対象とします。
- IoT センサー。
- ウェアラブル（例：スマートウォッチ）。
- 医療機器。
- 産業機械。
- デスクトップ。

MDM の違い #2：モバイルデバイス管理は構成の制御に重点を置き、モダンデバイス管理は主に利用データを収集・集約する

さらに、モバイルデバイス管理とモダンデバイス管理のどちらのプラットフォームも、組織の環境内で企業所有のモバイルデバイスまたは接続デバイスを管理するよう設計されていますが、それぞれの管理タイプが提供する制御範囲は大きく異なります。

モバイルデバイス管理は、IT管理者に対し、管理対象の各モバイルデバイスの構成設定について、アプリケーションや特定機能へのアクセス制限を含む包括的な制御を提供します。
一方、モダンデバイス管理は、ユーザーアクティビティの監視と、すべての管理対象デバイスにわたる利用傾向に関するインサイトの提供に重点を置いています。また、必要に応じて、デバイスに保存されている機密データをリモートで消去することもできます。

MDM の比較：モバイルデバイス管理とモダンデバイス管理の共通点とは？

対象範囲と重点領域にこうした根本的な違いはありますが、これら2種類のデバイス管理ソリューションにはいくつかの共通点があります。どちらも、次のことが可能です。

暗号化と認証技術を通じて、エンタープライズレベルのセキュリティ機能を提供する。
アプリケーションの迅速なパッチ適用を可能にする。
デバイスの位置情報追跡を提供する。
ジオフェンシング機能をサポートする。
ソフトウェア配布を可能にする。
インベントリ管理機能を備えている。
各管理対象デバイスに関する詳細なレポートインサイトを提供する。
自動バックアップを可能にする。
HIPAA や GDPR 規制など、業界のプライバシー基準への準拠を確保する。
手作業を自動化することで、大規模なデバイス群の管理に関連するコストを削減する。
その他の機能に加え、デバイス管理業務に関連するプロセスを効率化することで、生産性を向上させる。

モバイルデバイス管理とモダンデバイス管理をめぐる混同を解消する

2つの MDM プラットフォームには共通点が多いため、混同される余地があります — モダンデバイス管理ソリューションが、明らかにより広範なエンドポイントデバイスを対象としているとしてもです。

たとえば、どちらのシステムもデータセキュリティのための暗号化技術を提供します。ただし、

モバイル MDM は認証技術により重点を置いています。
モダン MDM はユーザーアクティビティをより詳細に監視できます。

同様に、どちらのシステムも位置情報追跡機能を提供しますが、

モバイル MDM は、リモート拠点にあるデバイス群や資産の管理により適しています。
モダン MDM は、個々のユーザーデバイスの挙動を追跡するのにより適しています。

混同が生じるもう1つの領域は、ソフトウェア配布です。どちらのシステムも、アプリケーションの更新やパッチをデバイスにリモートで展開できます。ただし、

モバイル MDM は OTA 展開のみに重点を置いています。
モダン MDM は構成設定に対して、より包括的な制御を提供します。

暗号化とセキュリティ

位置情報追跡

ソフトウェア配布

モバイルデバイス管理

認証技術により重点を置く。

リモート拠点にあるデバイス群または資産の管理により適している。

OTA 展開のみに重点を置く。

モダンデバイス管理

ユーザーアクティビティをより詳細に監視できる。

個々のユーザーデバイスの挙動を追跡するのにより適している。

構成設定に対して、より包括的な制御を提供する。

最後に、レポートインサイトと自動バックアップの面にも違いがあります。どちらのシステムも、デバイスの種類や利用要件に応じて程度の差はあるものの、これらの機能を提供しますが、意思決定を行う前に、どのシステムが自社のニーズに最も適しているかを理解することが重要です。

	モバイルデバイス管理	モダンデバイス管理
主な対象デバイス	電話、タブレット、PDA、COSU など。	モバイルと同じ対象に加え、サーバー、デスクトップ、ノートPC、IoT などの追加デバイス種別。
管理範囲	モバイルデバイス中心	ユーザー中心
アプリケーション展開	はい — MAM 経由	はい — 社内アプリストア経由
エンドポイントの構成とポリシー	モバイルのみ	はい
デバイス追跡	モバイルのみ	はい
レポートと傾向	限定的	はい
OS とアプリケーションの更新	OTA	包括的なパッチ適用と管理

自社に適した MDM はどちらか？

モバイルデバイス管理とモダンデバイス管理を比較すると、明確な違いがあります。そして、どちらもITインフラストラクチャを最適化しながら資産を常に安全に保つ方法を求める組織に、大きなメリットを提供します。

両者のどちらを選ぶべきかについてのベストプラクティスは何でしょうか。組織は、自社固有の要件に基づいて MDM システムを選択すべきです。たとえば、モバイルデバイス管理システムとモダンデバイス管理システムは、暗号化技術や認証技術などの類似機能を提供しますが、対象範囲と重点領域は大きく異なります。

現在のセキュリティプロトコルと求める機能セットに最も合致するソリューションを必ず選択してください。なぜなら、同じ略語を共有していても、その違いが企業にとって大きな差を生む可能性があるからです。

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　資産を安全に保つことができます。

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 攻撃

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

財務への影響

業務への影響

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

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

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

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

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

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