Ivantiブログ

尾碕真花さんがIvanti SoftwareのタクシーCMに初登場!!

Tue, 30 Sep 2025 03:00:01 Z

この度、弊社では「見えるリスク、動ける経営。」というテーマでCM制作を決定し、オスカープロモーションに所属する尾碕真花さんにご出演いただきました。尾碕さん、ご関係者の皆様のお陰様で素晴らしいCM動画にしてくださり、社員一同感謝申し上げます。

尾碕さんからもコメントをいただいております！

「撮影時はグリーンバックでの撮影だったので、どんな風に仕上がっているのか私自身すごく楽しみです。『見えるリスク、動ける経営。』というメッセージとともに、クールに表現させていただいているので、そちらも注目しながら見ていただければと思います。」

今回の動画は期間限定でタクシー広告に表示されます。

東京都内（23区・武蔵野市・三鷹地区）：2025年10月6日～12日
関西エリア（大阪・京都・兵庫・滋賀・奈良・和歌山）：2025年10月20日～26日

今後もタクシー広告以外でも実施予定です。

動画はこちらからご覧いただけます。

尾碕真花さん　プロフィール

2000年12月2日生まれ。高知県出身。

2012年、第13回全日本国民的美少女コンテストで審査員特別賞を受賞し芸能界入り。

2016年に俳優デビュー。以降もドラマ、映画、舞台で活躍。主な出演作に、NHK大河ドラマ「鎌倉殿の１３人」、NHK連続テレビ小説「虎に翼」、「コールミー・バイ・ノーネーム」（MBS）、「介護スナックベルサイユ」（フジテレビ系）ほか。2025年7月期には2つのドラマに出演。

TBS「シンデレラクロゼット」では主人公・福永春香役、フジテレビ系月９「明日はもっと、いい日になる」ではシングルマザー安西夢乃役を演じ、無二の存在で注目を集める。

Apple Business Manager Device Migration：知っておくべきこと

Fri, 12 Sep 2025 17:27:33 Z

AppleのOS 26のリリースにより、Apple Business Manager（ABM）またはApple School Manager（ASM）を使用するIT管理者に、新しい強力なツールが提供されます：Device Migrationです。この機能により、MDMプラットフォーム間でのデバイスの切り替えが大幅に容易になり、エンドユーザーへの中断を最小限に抑えることができます。

本記事では、知っておくべき重要事項と、ABM Device MigrationがIvanti Neurons for MDMへの移行を非常に簡単にする方法についてご説明いたします。

ABM Device Migrationの主要機能

AppleのABM Device Migration機能により、手動の手順やユーザーへの中断なしに、異なるMDMソリューション間でのデバイス移行が容易になります。

手動での再登録が不要。デバイスを消去したり手動で再登録したりすることなく、あるMDMサーバーから別のサーバーへ、またはあるベンダーのMDMから別のベンダー（Ivanti Neurons for MDMを含む）へデバイスを転送できます。既存のすべてのユーザーデータとデバイス構成は、移行中に自動的に適用されます。エンドユーザーは、デバイスの再起動と新しいMDMへの再登録という、ガイド付きの2回のクリックで再登録を完了できます。

Enrollment Deadlines。これは、AppleがABMとASMに導入した最新機能です。デバイスを新しいMDMインスタンスに移行するための期限を設定し、適用することができます。デバイスが期限内に登録されない場合、ロックされ、ユーザーは登録を完了するよう求められます。この期限により、新しいMDMへの再登録の自動化プロセスをトリガーすることができます。エンドユーザーには、シームレスに再登録を完了するための画面が表示されます。

エンドユーザーエクスペリエンス。エンドユーザーエクスペリエンスは、enrollment deadlineが過ぎていない限り、移行中に変更を認識しません。移行が完了すると、ユーザーはデバイスを再起動するよう促されます。デバイスの再起動後、エンドユーザーは新しい管理ソリューションにデバイスを再登録するよう促され、これには1回のクリックが必要です。

API駆動。このプロセスは、Appleの新しいAPI（有効化が必要）を使用して、ABMまたはASMポータルを通じて管理することもできます。これは、APIインフラストラクチャを使用する顧客が、ABMコンソールにアクセスすることなく、新しいApple ABM APIを使用してデバイスを一括で割り当てまたは割り当て解除できることを意味します。

ABM Device Migrationのユースケース

この機能をいつ使用しますか？以下は、主要なユースケースです。

クラウド移行

ABM Device Migrationにより、デバイスを再登録することなく、オンプレミスMDMからクラウドベースのMDMに移行できます。Ivantiのお客様にとって、この機能により、Ivanti Endpoint Manager（macOS用）またはIvanti Endpoint Manager Mobile（すべてのAppleデバイス用）からIvanti Neurons for MDMへの移行が容易になります。

MDMプロバイダーの切り替え

ABM Device Migrationは、別のMDMプロバイダーからIvanti Neurons for MDMへの切り替え、またはJamfやKandjiなどのAppleデバイスのみを管理するMDMから、すべてのデバイスタイプ（Android、Windows、Apple）を単一のプラットフォームに統合することを簡素化します。

学区でのデバイスの再配置

教育機関は、すべてのApple管理および割り当て設定を維持しながら、部門またはキャンパス間でデバイスを再配置できます。

合併、買収、または組織再編

M&Aまたは組織再編によりITインフラストラクチャを統合または分離する場合、ユーザーへの中断を最小限に抑えながら、デバイスを新しいMDM環境に移行できます。

ABM Device Migrationの設定：ステップバイステップガイド

開始する前に

開始する前に考慮すべき2つの重要な点があります：

Device Migrationは、iOS 26、iPadOS 26、またはmacOS 26（またはそれ以降）を実行しているデバイスでのみ動作します。まずデバイスが更新されていることを確認してください。
Device Migrationをサポートするために、MDMサーバー側で変更を行う必要はありませんが、ターゲットMDMサーバーは新しいデバイス割り当てと登録リクエストを受信する準備ができている必要があります。

ABMコンソール経由でのDevice Migration

Apple Business Managerにサインインし、Devicesに移動します。ここから、検索バーを使用して、シリアル番号、注文番号、またはその他の識別子でターゲットデバイスを見つけます。次に、移行期限を設定するデバイスを選択します。

次に、デバイスの詳細を確認します：デバイスをクリックして詳細ビューを開き、正しいMDMサーバーに割り当てられていることを確認します。これで、移行期限を設定できます。

ここから、Assign Device Managementをクリックします。

ポップアップで、デバイスを割り当てる新しいMDM組織を選択できます。

次に、期限を選択します。

期限の希望する日時を選択します。これは、ユーザーが割り当てられたMDMサーバーにデバイスを移行する必要がある最終日です。ユーザーがプロンプトに従わない場合、デバイスからロックアウトされます。次に、Continueをクリックします。

デバイスで、ユーザーはデバイスを再起動するよう通知を受け取ります。

再起動後、デバイスはユーザーに新しい管理サービスへの登録を要求します。

API経由でのDevice Migration

API経由でABM Device Migrationを設定するのは簡単で、どのMDMに、またはどのMDMから切り替えるかに関係なく、ABM（またはASM）内で完全に実行されます。

まず、Apple Business ManagerまたはApple School Managerアカウントにログインし、Settings > Device Manager Settingsに移動します。

次に、Device Migrationを許可するために必要なAPIを確認して有効にします。（方法がわからない場合は、ステップバイステップのヘルプについてApple管理者ガイドを確認してください。）

APIが有効になると、Appleの移行ワークフローに従ってデバイスを選択し、新しいターゲットMDMサーバーを指定できます。オプションで、移行されたデバイスのenrollment deadlineを設定できます。

ABM Device Migrationの追加リソース

より詳細な情報が必要な場合は、以下を参照してください：

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

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

以前に開示された脆弱性に関連する進化する脅威アクター技術に対してお客様に追加の可視性と保護を提供する、拡張された外部Integrity Checking Tool

Thu, 29 Feb 2024 18:28:27 Z

CISAによる2月29日の勧告に関する情報を含むよう更新されました。これには、CISAのラボで観察された技術的な調査結果が含まれますが、これらは実環境では観察されておらず、実際の顧客環境では実行可能とは考えられていません。CISAおよび他の政府機関は、防御側が2月27日にリリースされたIvantiの更新された外部Integrity Checker Tool（ICT）を実行することを推奨しています。

お客様に対する最近の攻撃に関する徹底的な調査の一環として、IvantiとMandiantは本日、進化する脅威アクターのタクティクス、テクニック、およびプロシージャ（TTP）に関する調査結果を発表しました。これらの調査結果は、Ivanti Connect Secure、Policy Secure、およびZTAゲートウェイに影響を与える以前に開示された脆弱性の継続的な分析で特定されたもので、現在まで実環境で成功裏に展開されていないものの、当社が監視している潜在的な持続性技術が含まれています。

重要：これは新しいCVEではありません。また、当社およびセキュリティ・政府パートナーは、セキュリティアップデートと工場出荷時リセットの実装後の脅威アクターによる持続性成功の事例を把握していません。しかし、攻撃の積極的な性質を考慮し、お客様がこの高度に洗練された脅威に対して監視および更なる保護を行うための措置を講じることができるよう、関連情報を公開しています。

Ivantiは、お客様のアプライアンスとシステム上に存在するすべてのファイルに対する追加の可視性を提供する、外部Integrity Checker Tool（ICT）の新しい機能拡張をリリースしています。拡張された外部ICTは、お客様のスナップショットを復号化するためのサポートを必要としなくなります。新しいファイルおよび/または変更されたファイルが見つかった場合、外部ICTは、お客様自身のレビュー用に暗号化されていないスナップショットを提供します。スナップショットの内容を表示するためのガイダンスは、このナレッジベース記事（ログインが必要）にあり、スナップショットを解釈するためのリファレンスはこの記事にあります。念のため、ICTはデバイス上に存在するファイルのスナップショットです。これらのバイナリの変更を検出して、侵害の兆候を強調表示することができます。これはお客様のための追加のセキュリティレイヤーであり、常に継続的な監視ツールと併用することを意図しています。

Ivantiは、ナレッジベース記事で仮想アプライアンスに関する推奨事項も更新しました。これらの新しい手順は、以前に成功した工場出荷時リセットを完了していない、または新しいビルドを展開してアプライアンスにパッチを適用していない仮想アプライアンスを使用しているお客様にのみ適用されます。

Ivantiは、お客様が以下の措置を講じることを推奨します：

既に成功した工場出荷時リセットを完了し、アプライアンスにパッチを適用したお客様については、内部および更新された外部ICTを引き続き実行し、これらの進化する技術を反映するように更新する必要がある継続的な監視を行うことが唯一の措置です。
工場出荷時リセットを完了していない、または新しいビルドを展開してアプライアンスにパッチを適用していない仮想アプライアンスを使用しているお客様については、Ivantiは、工場出荷時リセットを実行するのではなく、Ivanti Connect Secureの新しいビルドを展開することを現在推奨しています。その理由は、仮想アプライアンスの工場出荷時リセットが一貫して成功していないため、推奨手順を更新したためです。
繰り返しになりますが、以前にIvantiの手順に従い、クリーンなICTスキャンを受けた場合、追加の工場出荷時リセットを完了したり、（仮想アプライアンスの）新しいビルドを展開したりする必要はありません。

お客様は、このブログおよびナレッジベース記事、FAQブログ、リカバリーナレッジベース記事で、最新の修復情報にアクセスできます。新しい情報が入手可能になり次第、これらのドキュメントを積極的に更新し続けます。

以前に開示された脆弱性の修復中にお客様が問題に遭遇した場合、当社のサポートチームが引き続きサポートいたします。

Ivantiのお客様は、Mandiantが公開したブログを確認してください。これには、工場出荷時リセットを通じて持続性を達成しようとする失敗した試みに関する追加のTTPおよび観察が概説されています。

更新：CISAおよび他の政府機関は、2月29日に、2月27日にIvantiとMandiantが発表した調査結果、およびCISAの技術ラボで開発された潜在的な持続性技術を含む以前の研究をまとめた共同勧告を発表しました。このラボベースの調査結果は、CISA、Ivanti、Mandiantのいずれも実環境で観察していないことに注意することが重要です。提示された証拠と当社チームによるさらなる分析に基づき、脅威アクターがこれをリモートで試みた場合、Ivanti Connect Secureへの接続が失われ、実際の顧客環境で持続性を獲得することはできないと考えています。さらに、パッチを適用し、成功した工場出荷時リセット（ハードウェア）を実行したか、新しいビルド（仮想）を展開したお客様は、CISAのレポートで概説されている活動によるリスクにさらされることはありません。

Ivanti、Mandiant、およびCISAは、既知の攻撃ベクトルを検出し、追加のファイルまたは変更されたファイルを検出するために、更新された外部ICTを使用することを推奨しています。Ivantiが強調してきたように、これは、他のセキュリティおよび監視ツールを補完するための、お客様の武器庫における有用で有益なセキュリティツールです。当社の推奨事項は、更新されたICTを継続的な監視と併用して使用することです。

当社は、リスクおよび進化する脅威アクターの技術を引き続き綿密にレビューしています。新しい調査結果が得られた場合、お客様の最善の利益のために情報を迅速に提供し、適切であれば修正をリリースしたり、ICTを強化したりします。この目的のために、当社はセキュリティおよび政府パートナーと積極的に連携し続けています。

当社は、お客様のセキュリティを非常に真剣に受け止めており、お客様とその業界が直面している増加する攻撃的な脅威に直面しても当社の製品が安全であり続けるよう、強化されたセキュリティプロセスとプロトコルを適用することに取り組んでいます。

主要なFAQ

2月27日および2月29日の勧告に続いて、お客様が講じるべき措置はありますか？

既に成功した工場出荷時リセット（ハードウェア）を完了したか、新しいビルド（仮想）を展開してアプライアンスにパッチを適用したお客様については、内部および更新された外部ICTを引き続き実行し、これらの進化する技術を反映するように更新する必要がある継続的な監視を行うために、IvantiとMandiantのガイダンスに従い続けることが唯一の措置です。

Ivantiおよび当社のセキュリティパートナーは、Ivantiが推奨するセキュリティアップデートおよび工場出荷時リセット（ハードウェア）/新しいビルド（仮想）の実装後の脅威アクターによる持続性成功の事例を把握していません。

まだパッチを適用していないお客様は、ナレッジベース記事に記載されている手順に直ちに従う必要があります。

繰り返しになりますが、以前にIvantiの手順に従い、引き続きクリーンなICTスキャンを受けている場合、追加の工場出荷時リセットを完了したり、（仮想アプライアンスの）新しいビルドを展開したりする必要はありません。

Integrity Checker Toolはお客様にとって効果的なツールですか？

はい、Ivanti、Mandiant、およびCISAは、既知の攻撃ベクトルを検出し、変更されたファイルおよび追加のファイルを検出するのに役立ち、継続的な監視と併用して使用する必要がある更新された外部ICTの使用を推奨しています。ICTは、既知の攻撃ベクトルに基づいて悪意のあるものが残されているかどうかを判断するのに効果的です。

Ivantiが強調してきたように、ICTは、他のツールと並行して活用すべき、お客様の武器庫における重要で有益なセキュリティツールです。継続的な監視は、潜在的な脅威を検出するために引き続き重要です。ICTは、アプライアンスの現在の状態のスナップショットとして意図的に設計されているため、アプライアンスがクリーンな状態に戻された場合、脅威アクターの活動を必ずしも検出できるわけではありません。スキャン間で行われた変更、マルウェア、およびその他のIndicators of Compromise（IoC）を監視するには、他のセキュリティツールを使用する必要があります。

ICTは、実環境で脅威アクターによって展開されている既知の脅威活動に特に焦点を当てるように設計されています。これにより、お客様にとって意味のある結果が最大化され、誤検出が最小化されます。これは、Mandiantがブログで効果的なツールとして検証しています。他の標準的なセキュリティ監視ツールは、他の活動を検出するように設計されています。

以前に開示されていない新しい脆弱性または侵害はありますか？

いいえ、新しいCVEはありません。Ivantiおよび当社のセキュリティおよび政府パートナーは、セキュリティアップデートおよび工場出荷時リセットの実装後の脅威アクターによる持続性成功の事例を把握していません。

Ivanti、Mandiant、およびCISAによって説明された新しい活動は、工場出荷時リセットを通じて持続性を維持しようとする限定的な試みに関連しており、これらは失敗に終わりました。また、CISAが開発した潜在的なラボベースの技術で、持続性を試みるために使用できると彼らが考えているものです。これらのいずれも実環境で成功裏に使用されていません。

提示された証拠と当社チームによるさらなる分析に基づき、CISAがその技術ラボで特定した技術では、脅威アクターが実際の顧客環境で検出されない持続性を成功裏に達成することはできないと考えていることに注意することが重要です。

Ivantiは、CISAがその技術ラボで特定した技術が実際の顧客環境で持続性を成功させることができないと結論付けたのはなぜですか？

Ivantiおよびその外部セキュリティ専門家は、CISAの技術的な調査結果を評価し、パッチが適用されていない実際の顧客環境に展開された場合、Ivanti Connect Secureへの接続が失われるため、リモートで実行することはできないと判断しました。したがって、この持続性のリスクは、実際の顧客展開では有効ではないと考えています。

持続性が失敗した場合、なぜIvantiとMandiantはこの情報を公開したのですか？

当社は、2月27日に、当社が監視している進化する脅威アクターの技術に関する関連情報を公開しました。これにより、防御側は、高度に洗練された攻撃的な攻撃に対してさらに自身を保護するための措置を講じることができます。お客様は、これらの技術が現在まで実環境で成功裏に展開されていないものの、この情報を自身の継続的な監視に組み込むことができます。

当社は、お客様が保護されていることを確認するための情報とツールを提供することに取り組んでおり、この目的のためにセキュリティおよび政府パートナーとも引き続き連携しています。

CISAは、Ivantiのお客様がマシンのプラグを抜くことを推奨していますか？

CISAは、組織にIvantiシステムを本番環境から永久に削除するよう指示したことはありません。連邦機関へのCISAの最初の指令は、手順の最初のステップのみを報告したメディアによって誤って解釈されました。CISAは、これを修正するために指令を更新し、その後2月9日に再度更新して、パッチ適用後に製品をオンにできることを絶対的に明確にしました。

CISAの2月29日の勧告は、以前の研究、および持続性を試みるために使用できると彼らが考えているラボベースの技術をまとめており、お客様にリスクを認識するよう助言しています。CISAのレポートで概説されている活動はリモートで実行できないと考えていることに注意することが重要です。

Ivanti Connect Secure製品に古いオープンソースパッケージバージョンが含まれているのはなぜですか？

製品の9.xバージョン用のハードウェアには、新しいLinuxカーネルを実行するのに十分なCPUがなく、そのため、カーネルの制限により古いオープンソースパッケージを使用する必要があります。当社はセキュリティ修正をバックポートしているため、製品はこれらの古いオープンソースパッケージに対して脆弱ではありません。CISAレポートの場合、バージョン番号は、バイナリパッケージの実際の表示または脆弱性があるかどうかの真の指標ではありません。セキュリティ修正のバックポートは、バイナリパッケージのバージョン番号を変更しないためです。

Ivanti Connect Secureのすべてのサポートされているバージョンは、The National Information Assurance Partnership（NIAP）によって認定されており、約20年間認定されています。これは、製品が米国国家安全保障システム調達のセキュリティ要件を満たしていることの検証です。

Ivanti Connect Secureの新しい22.xバージョンは、より強力なCPUを必要とする新しいLinuxカーネル上に構築されており、そのため、古いバージョンのオープンソースパッケージを含まず、追加のセキュリティ強化が可能な新しいプラットフォームであるISAを導入しました。

当社は、2022年7月に9.xハードウェアおよびソフトウェア製品のEnd-of-Life通知を正式にリリースしました。当社は、お客様がアプライアンスを22.xにリフレッシュするか、Ivanti Neurons for Zero Trust Accessでクラウドに移行するために積極的に取り組んでいます。

9.xの古いオープンソースコードを含む、Ivanti製品に存在するすべてのコードは、ivanti.comで入手可能な製品ドキュメントに含まれる当社のアトリビューションおよびSBOMに明確に記載されています。

すべてのよくある質問への回答はこちらでご覧いただけます。

人事ナレッジ管理が組織にとって重要な理由

Wed, 27 Sep 2023 18:17:26 Z

なぜ人事ナレッジ管理ソリューションが導入すべき重要なテクノロジーなのか。保険や福利厚生の情報から、会社の方針、入社手続きなど、人事部門は企業にとって最も重要な情報の管理者です。人事情報は、従業員が頻繁にアクセスする必要のある情報です。

適切な人事ナレッジ管理ソリューションがなければ、ナレッジの分散や質問への回答に、人事チームの膨大な時間が費やされてしまいます。その結果、より重要なタスクが後回しになってしまいます。

人事ナレッジ管理ソリューションを導入することで、従業員は求めている情報や回答を簡単かつ容易に自分で見つけることができるようになり、人事チームは貴重な時間を取り戻すことができます。適切な人事ナレッジ管理ソリューションが完全に導入され、賢く利用されれば、人事チームは今までナレッジ管理ソリューションなしで業務をこなしてきたことが信じられなくなるでしょう。

人事ナレッジ管理とは何か。

人事ナレッジ管理とは、すべての人事文書、方針、情報、知識を一元化し、社内の誰もがどこからでもその重要な情報にアクセスし、更新できるようにすることです。

この中央リポジトリの重要な点は、従業員が部署や勤務地、勤続年数に関係なく、24 時間 365 日使えるセルフサービスポータルを通じて必要な人事情報にすばやくアクセスできることです。これにより、従業員のフラストレーションが軽減され、古い情報や誤った情報を取得する可能性が減り、人事担当者は同じ質問に何度も（何度も！）答える必要がなくなります。

なぜ人事ナレッジ管理が重要なのか。

情報の分散はそれほど大きな問題ではないように思えるかもしれませんが、組織全体に広がると大きな影響を及ぼします。職場の知識と生産性に関する調査によると、従業員の 60% が週に 5 時間以上、他人からの情報を待っているという結果が出ています。

人事部は組織全体の従業員にとって重要な情報源であり、人事ナレッジ管理はそのボトルネックを解消する簡単な方法です。

今日のビジネスの世界では、人事管理はしばしば重要な質問に対する正しい答えをすばやく見つけることです。人事ナレッジ管理ソリューションは、増大する課題に対するシンプルで効果的、かつ合理的な答えです。

関連項目: Ivanti Neurons for HR の詳細

人事部門におけるナレッジ管理の 8 つの主要な事例

従業員が自分で見つけることができる、簡単にアクセスできる最新の情報は、組織によっては人事ナレッジ管理を導入する十分な動機になるかもしれません。しかし、賢明な企業は、うまく実装されたソリューションから、ハードとソフトの両方の付加的なメリットを実感しています。

1. 役割ベースのアクセス制御とカスタマイズ可能なアクセス許可を適用

人事ナレッジ管理の大きな利点は、従業員が人事の手を借りずに必要な情報を見つけ、アクセスできるようになることです。しかし、すべての従業員がすべての情報にアクセスできるようにすると、従業員が圧倒されてしまう可能性があります。あるいは、意図しない情報にアクセスするかもしれません。どうすればこの問題を軽減できるのでしょうか。適切なアクセス許可と役割ベースのアクセス制御を実装することです。

これは、実務的なビジネスの観点から重要です。すべての従業員が、会社の利用可能なすべての人事文書、方針、契約の閲覧を可能な状態であってはなりません。また、人事ナレッジ管理ポータルは、従業員が必要とする情報をすばやく表示することで、従業員にとって使いやすくなります。

カスタマイズされたアクセス許可は、大きな地理的拠点を持つ組織にとって特に重要です。一部の情報は、州や国の法律や規制に基づいて現地に合わせることが必要な場合があります。このような状況では、各拠点の従業員が適切な情報にすばやく、簡単に、明確にアクセスできるようにする必要があります。もし従業員が間違った文書にアクセスすれば（最悪の場合、送られてくれば）、ビジネスに大きな悪影響を及ぼしかねません。

役割ベースのアクセス制御とカスタマイズされたアクセス許可を導入することで、従業員が間違った情報を受け取る可能性を減らすことができます。プロセスを自動化することで、人事部の従業員が何度も書類を探し出す手間を省くこともできます。そして、そのために消費される人件費も削減できます。

2. 新入社員のオンボーディングを改善

オンボーディングは、新入社員の経験を左右します。オンボーディングパッケージは役に立つが、置き忘れやすいし、人事が更新するのも面倒です。最終的に、オンボーディングの非効率性は、1,000 人規模の組織で年間 25 万ドル以上のコストになる可能性があります。そして、組織が成長するにつれて、そのコストも増大します。

オンボーディングを人事ナレッジ管理プラットフォームに移行することで、人事は必要に応じて新しい情報を追加したり、既存のデータや文書を更新したりすることが容易になります。また、従業員がいつでも必要な情報にアクセスできる簡単な方法を提供します。たとえ入社日から数ヶ月後であっても、その頃には従来のオンボーディングパッケージは紛失しているかもしれません。

さらに、新入社員が今後組織や人事の知識を得るために利用するのと同じポータルサイトから入社時の情報にアクセスできるようにすることで、この重要なセルフサービスツールに慣れさせることができます。

その結果、DIY 人事ツールへの高まる要求が満たされるようになります。Paychex の調査によると、米国の従業員の 73% がセルフサービスの人事オプションを望んでいることがわかりました。

新入社員のオンボーディングの人事部分を簡素化することで、組織は従業員の経験を向上させ、オンボーディングにかかる時間を短縮し、オンボーディングの非効率なコストを最小限に抑えることができます。

3. 既存のナレッジの再作成に費やす時間を減らす

時間は貴重です。同じ質問に何度も答えたり、すでに作成した文書を掘り起こしたりするのに時間を費やす必要はありません。従業員がアクセスできる一元化されたリポジトリがなければ、ほとんどの人事チームはまさにそうなってしまいます。

さらに悪いことに、人事部の従業員は、そのことを知らなかったり、見つけられなかったりするために、すでに存在する文書を作り直してしまうかもしれません。一度だけなら大したことはないかもしれませんが、不必要に何度も文書や方針などを作成することは、貴重な人事資源の無駄遣いです。

適切に整理された人事ナレッジ管理ソリューションがあれば、チームは（たとえ分散しているチームであっても）、何が存在し、何を本当に作成する必要があるのかを正確に把握することが容易になります。新しい文書や方針を作成する必要がある場合でも、一からすべてを作成するのではなく、既存の文書を使って作業することで、労力と時間を最小限に抑えることができます。多くの場合、知識やはすでに存在しています。ある面では、単に微調整やアップデートが必要かもしれません。

4. 必要な情報をすばやく（そして頭痛の種を減らして）入手する

企業において、質問をしてから答えを待たなければならないことほどイライラすることはありません。しかし、多くの場合、あなたが質問し、待ち、リマインダーを送り、さらに待って、といったことが繰り返されます。 1 つの人事チームが組織全体を管理しているため、簡単な質問でも日々の業務に埋もれてしまい、従業員を待たせてしまいます。

人事ナレッジ管理システムは、この煩わしさをほとんど取り除きます。適切なプラットフォーム構成と適切な役割ベースのアクセス制御があれば、全従業員は人事を待たなくても、求めている情報をすばやく簡単に入手できます。人事部の社員にとっては、質問に答えたり、適切な書類を探したりする時間が大幅に短縮されることになります。

人事ナレッジ管理ソリューションが導入されていれば、分散している人事チームも必要な情報を入手しやすくなります。事業所固有のポリシーを作成する必要がある必要な情報を収集するために何通もメールを送る必要もなく、他の拠点がどのようなことを行っているかをすばやく確認したり、企業方針を参照したりして、組織全体と歩調を合わせることができます。

5. ミスを減らす

一元化された場所でアクセス可能な、明確で一貫性のある文書化により、情報の錯綜や伝達ミスのリスクを抑えることができます。全従業員が最新の情報、方針、文書に基づいて業務を遂行することが重要です。

組織全体ですばやく確実に情報を共有する方法がないまま、更新された文書が個人の手元に残っている場合、それを実行するのは困難です。人事ナレッジ管理プラットフォームが適切に管理されていなければ、問題は必ず発生します（特に、アップデートの配信を電子メールなどの不確実な手段に頼っている場合）。

定期的に更新される生きた文書では、最新のアクセスはより重要になり、より困難になります。すべての人事情報が、年に一度見直される公式方針という形になっているわけではありません。よくある質問に答えたり、会社の慣行を概説したりする一般的な文書かもしれません。これらは通常、生きた文書であり、従業員が新たな質問をしたり、新たなミスをしたりするにつれて成長していくものです。

この情報を文書化し、広く共有し、簡単にアクセスできるようにすることは、時間の節約になるだけでなく、異なる部署や場所で問題やミスが繰り返されるのを防ぐことにもつながります。

6. 迅速な意思決定

人事ナレッジ管理ソリューションは単なるライブラリではありません。その可能性を最大限に活用すれば、組織の健全性や潜在的なリスクについて貴重な洞察を得ることができます。アセットが最後にいつ更新されたかを可視化することで、人事チームはどの文書やポリシーの更新が必要かを追跡しやすくなります。

どの部署が人事ナレッジ管理システムに最も多く（または最も少なく）アクセスしているか、どのファイルが最も閲覧されているかなど、他の指標を見ることで、人事チームは追加トレーニングや説明が必要な場所を知ることができます。従業員が同じポータル内で質問したり、説明を求めたりできる人事ナレッジ管理システムがあれば、人事情報プロセスがさらに合理化され、不足している情報や混乱している情報をチームが把握できるようになります。

データに基づく情報に簡単にアクセスできることで、人事チームは、組織にとって真に有益な方法で、将来の文書化や更新をより正確に計画することができます。また、すでに表面化した問題に反応的に対処するのではなく、潜在的な問題領域に予防的に対処するのにも役立ちます。

7. プロセスの標準化

人事ナレッジ管理プラットフォームは、信頼できる唯一の情報源として機能します。誰もが同じ情報を簡単に入手できるようにすることで、ミスの可能性を減らし、コミュニケーションの行き違いを減らし、回答や情報を得るまでの期間を短縮することができます。また、情報収集のプロセスを標準化することで、従業員は企業の期待に沿って迅速に前進することができます。

単一のナレッジセンターから人事の回答を取得するための標準的なプロセスがなければ、組織は同じ質問に対して異なる従業員が異なる回答を得るというリスクを負うことになります。そして、それがどのような混乱を引き起こすかは想像に難くありません。特に機密性の高いトピックに関するものであればなおさらです。

人事部に質問する前に、社員が人事ナレッジ管理システムにアクセスして質問に答えるべきだという期待を組織が徹底すれば、そのプロセスは企業文化に根付き、人事の仕事は少し楽になります。

8. 従業員により良いサービスを提供する

私たちはオンデマンドで、今すぐ手に入れられる世界に生きています。「そのためのアプリがある」と言うのは日常的な冗談になっていますが、それは真理でもあるからです。人々は、欲しい情報をいつでも遅滞なく入手できることを期待しています。職場での質問への回答も含まれます。特に、福利厚生、保険、休暇、会社の休日、401kなどです。

人事ナレッジ管理の一元化は、人々が情報へのアクセスに慣れていることにつながります。メールでの返信を待つことなく、従業員自身が迅速かつ簡単に回答を得られるようにすることで、全体的なエクスペリエンスが向上します。これは、従業員のモラールを向上させるだけでなく、従業員が何日間も疑問について考え込むのではなく、すぐに答えを見つけて次に進むことができるため、生産性も向上させることができます。

人事ナレッジ管理が重要だと知っているだけでは十分ではありません。

ガイドラインやポリシーの絶え間ない変更に加え、従業員のさまざまな要望や期待が、ハイブリッドワーク、リモートワーク、オフィスワークの融合を複雑化させ、ロジスティクス上の頭痛の種やセキュリティ上の課題など、無限の可能性を引き起こしています。

幸運なことに、自動化された直感的なツールはプロセスの円滑化と最適化に役立ち、セルフサービスソリューションは従業員のエクスペリエンスを向上させ、革新的なテクノロジーはチームのパフォーマンスと帯域幅に関するより多くのコンテキストと洞察を提供します。

人事ナレッジ管理は従業員のセルフサービスポータルを強化し、従業員のステータス、地域、場所、役割など、パーソナライズされた検索のために従業員の要求をフィルタリングする機能を備えた、常に最新の情報源でスマートな人事業務をサポートします。これにより、従業員を迅速な業務に従事させ、冗長な問題解決を過去のものとすることができます。

適切な人事ナレッジ管理ソリューションを見つける

成功する人事ナレッジ管理プラットフォームは、高度なソリューションであり、人事チームが必要とする機能のすべてとは言わないまでも、そのほとんどをすぐに利用することができます。あるいは、人事の正確なニーズを満たすために、プラグイン、カスタマイズ、APIを提供しています。

基本的なポータルを社内で構築するために貴重な時間とリソースを費やす代わりに、優れた人事ナレッジ管理プラットフォームの仕組みをすでに理解している実績あるサービスプロバイダーと提携することをお勧めします。

クラウドを活用する: クラウドにおけるITSMの5つの戦略的利点

Tue, 22 Aug 2023 19:00:46 Z

クラウドコンピューティングはもはや未来ではなく、私たちの現実です。つまり、ITSMをクラウドに移行するという決断は、単なる選択肢ではないということです。戦略的に必要なことです。この変革の初期段階にあるビジネスリーダーやITリーダーにとって、クラウドベースのITSMの利点を理解することは極めて重要です。この転換が組織にもたらす5つの利点を紹介します。

1. 圧倒的な拡張性と柔軟性

組織のITシステムが物理的なインフラに縛られている場合、適応性と拡張性との継続的な葛藤に直面します。クラウドコンピューティングは、オンプレミスでは決してかなわない拡張性と柔軟性を環境にもたらします。ビジネスニーズに応じてリソースを迅速に調整できるため、コストの最適化と業務効率の向上につながります。

ダイナミックなビジネス状況にすばやく適応する能力は、経営面でも競争面でも大きな追い風となります。クラウドが提供するダイナミックな適応性により、サービス管理プロセスは常に最適な効率で運用され、ビジネスニーズや変動にシームレスに対応します。

2. ユニバーサルなアクセシビリティとコラボレーションの改善

クラウドコンピューティングは、ITSMツールやサービスへのアクセスを民主化し、安定したインターネット接続さえあれば、いつでもどこでも利用できるようにします。この無制限のアクセシビリティは、シームレスなサービス提供を促進し、ITチームがどこにいても効率的に業務を遂行できるようにします。今日では、この柔軟性が特に重要になっています。再びフルタイムでオフィスで働きたいと考えているのは、IT従業員のわずか16%です。

さらに、クラウドベースのITSMソリューションは、コラボレーションを促進します。リアルタイムの更新、サービスチケットの簡単な追跡、シームレスな情報共有により、すべてのステークホルダーが確実に同期され、生産性と迅速な意思決定が促進されます。

3. 高度な自動化と統合機能

クラウドコンピューティングは、ITSMの自動化における次の進化を可能にし、オンプロミス自動化で達成可能な、単純な反復作業や手作業の排除を超えるものです。新世代のクラウドベースの自動化されたITSMソリューションは、高度なチケットルーティングとインシデント管理を、時には開始から終了まで可能にします。

クラウドがオンプレミスよりも自動化のインフラとして優れている理由はいくつかあります。

クラウドソリューションは、近代的で柔軟なアーキテクチャに構築されており、自動化を推進するツールである機械学習とAIのパワーを活用するために特別に設計されています。たとえば、機械学習はサポートチケットの自動分類と自動ルーティングを可能にします。システムは過去のデータから学習し、受信チケットのカテゴリを予測し、自動的に最適なチームまたはエージェントにルーティングします。

クラウドベースのITSMツールは、高度な自動化機能を含む、最新の機能や特徴でより頻繁に更新されます。たとえば、自然言語処理（NLP）の進歩は、チャットボットがユーザーのクエリを理解し、より人間に近い方法で応答する能力を大幅に向上させることができます。オンプレミスのシステムでは、同様のアップグレードを実施するために多大な時間とリソースを必要とします。

クラウドベースのツールは、他のクラウドベースのアプリケーションと簡単に相互運用できるため、異なるプラットフォーム間で自動化されたワークフローの可能性が大きく広がります。クラウドベースのITSMでは、これは個々のアプリケーションにとどまらず、ITエコシステム全体を包含し、イベント管理、構成管理、エンドポイントやセキュリティソリューションなどの他のITOMツールとITSMの統合を簡素化します。その結果、クラウドベースのITSMは、データ、洞察、制御メカニズムの中央リポジトリとして機能し、IT状況を一元的に把握できます。

統合が鍵です。クラウドでは、戦略的なプランニングと、高い質の情報に基づいた意思決定が推進されます。

4. セキュリティとコンプライアンスの強化

クラウドベースのITSMソリューションは、従来のオンプレミスシステムと比較して優れたセキュリティを提供します。クラウドプロバイダーは、暗号化、侵入検知、定期的な監査など、最先端のセキュリティ対策に多額の投資を行っています。

さらに、通常、業界特有の規制を遵守するための強固なコンプライアンス管理ツールを提供し、コンプライアンス違反による罰則のリスクを軽減しています。

5. コスト削減

クラウドベースのソリューションでは、ITインフラに多額の先行投資をする必要がなく、一般的にシステムの拡張に関しては従量課金モデルを採用しています。

さらに、多くの場合、メンテナンス、アップグレード、人材育成に関連するコストも低く抑えられます。この削減分を他の戦略的イニシアチブに振り向けることで、組織全体の財務効率を高めることができます。

クラウドベースのITSMへの移行は、拡張性、コラボレーション、コスト削減、セキュリティ強化など、組織に明確かつ大きな利点をもたらします。急速に進化するビジネス環境の中で競争力を維持しようと努力する組織にとって、クラウドベースのITSMの採用は、ビジネスパフォーマンスと回復力を大幅に強化できる戦略的な動きとして浮上しています。

ビジネスリーダーやITリーダーにとって、クラウドへの移行は単なる技術的な転換ではなく、効率性、革新性、成長性の新時代への戦略的飛躍です。

このeBookを読んで、より迅速でシンプルな、より優れたITサポートのためにITSMを最新化する方法を学びましょう。

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

WWDC23: Apple デバイスを管理するために IT 管理者が知っておくべきこと

Tue, 25 Jul 2023 19:51:36 Z

Apple が毎年開催する開発者会議 (WWDC) は、Apple のデバイスを管理するすべての人にとって情報の宝庫です。

新しいオペレーティングシステム（特にiOS 17、iPadOS 17、macOS 14、watchOS 10）と新製品（15インチMacBook Airとアップル Vision Pro）が大きな注目を集めたかもしれませんが、WWDC23は、企業のデバイス管理にとっても、それに劣らない重要な多数の新機能をもたらしました。

では、IT 管理者はこの秋の OS アップデートを前に、何に注意を払うべきなのでしょうか。

宣言型デバイス管理の大きな前進

Apple は 2021 年、MDM プロトコルの拡張機能として宣言的管理を導入しました。そして今年は、段階的な移行の一環として、MDM と宣言型管理の共存が可能な構成を同時にリリースする傾向が続きました。 Apple は、今日の MDM プロトコルから宣言型管理への移行パスを発表しました。これにより、エンドユーザーにとってシームレスな切り替えが可能になります。

今年の注目点は、Apple が宣言型管理によってのみサポートできる機能（パスキー と Apple Watch 管理）もリリースしていることです。 Ivanti の UEM 製品は、今後数四半期で宣言型デバイス管理、つまりこれらの新機能をサポートする予定です。

IT部門にとっても、エンドユーザーにとっても、よりシンプルなデバイス登録

今年リリースされたデバイス登録機能強化の明確なテーマは、手作業からの脱却です。

Return to Service は、デバイスを管理下に戻すための新機能で、IT 管理者はコマンドを送信してデバイスを消去し、自動的に再登録することができます。これまでは手作業で行われていたプロセスです。この機能は、手動による作業を行わずにリモートで再設定する必要がある、専用ユーザーのいない機器で特に有効です。たとえば、退院後にiPad をリセットする必要がある場合などです。

アカウント駆動型デバイス登録（すでに利用可能なアカウント駆動型ユーザー登録の拡張機能）は、ユーザーがプロファイルを手動でインストールするのではなく、職場や学校のアカウントでサインインしたときに自動的にデバイスを登録します。この余分なステップを省くことで、デバイスのオンボーディングを効率化できます。

デバイス登録のテーマでは、Setup Assistant においても、OS の最小要件を満たすデバイスに登録を制限する機能、セットアップ中に FileVault を設定する機能など、注目すべき機能強化が見られました。これらの機能により、企業は、基本的なセキュリティ機能がコンプライアンスに適合していることを確認するための手動の設定を必要とせずに、サプライヤーからエンドユーザーへ直接デバイスを配送することができます。

優れたエンドユーザー体験の実現に向けた簡単なエンドユーザー認証

Managed Apple ID の更新により、組織は、エンドユーザが自社のデバイスやサービスにアクセスしやすくなるよう改善されたさまざまな認証機能を利用できるようになります。 Managed Apple ID には、iCloud Keychain、Apple Wallet、およびアクセス管理制御のサポートが含まれ、組織は特定のサービスへのアクセスを制限したり、ユーザがサインインした際のデバイスの管理状態を指示したりできるようになります。さらに、管理対象デバイス間でパスキーを同期できるようになったため、さらに安全な認証が可能になりました。

プラットフォームシングルサインオン (SSO) では、ID プロバイダー (IdP) からの資格情報を使用して、共有された Mac でローカルユーザーアカウントを作成できるようになりました。

最後に、Managed Device Attestation が macOS で利用可能になり、デバイスのセキュリティ態勢とプロパティについて強力な保証を提供します。

デバイスとアプリケーションの接続に関する有用な更新

VPN の代わりに、HTTP/3 または HTTP/2 トンネルを使用してトラフィックを保護するために、新しいビルトインリレーを使用できるようになりました。構成はドメインベースで、管理対象アプリ、ドメイン、またはデバイス全体に適用できます。

また、Apple　はイーサネットの　802.1X　サポートを拡張しました。これにより、WiFi に頼ることなく、認証を必要とする制限されたネットワークに iPhone、iPad、Apple TV を接続することができます。

プライベートネットワークとネットワークスライシングのサポート

待望のプライベート 5G および LTE ネットワークのサポートが、ついに iOS 17 および iPadOS 17 で実現しました。

管理者は、Wi-Fi よりも携帯電話を優先させるために、デバイスがジオフェンスに入ったときに自動的にプライベート SIM をアクティブ化できます。

また、5G ネットワークスライシングにより、モバイルネットワーク事業者は、ネットワーク遅延、スループット、パケットロスに対する特定のサービス品質要件を持つ 5G スタンドアロンネットワークを通じてトラフィックをカスタマイズできます。

職場におけるウェアラブルの新しい使用例

Apple Watch が新たに管理対象デバイスとしてサポートされました。監視対象の iPhone とペアリングされた Apple Watch は、watchOS 10 で登録、管理できるようになりました。ただし、宣言型の管理構成が有効でなければならないという非常に重要な要件があります。。

今秋の OS アップデートに向けた計画

Ivanti は iOS 17 と macOS 14 のベータ版を積極的にテストしており、優れたエンドユーザー・エクスペリエンスと合理化された IT プロセスのために、これらの新機能を活用できるようにしています。

Ivanti 製品のゼロデイサポートを計画しているため、互換性に関するコミュニケーションに注意してください。

月例パッチにありがちな 2 つの問題を回避する方法

Tue, 25 Jul 2023 14:02:27 Z

エンドポイントにパッチを適用する時がやってきました。もしかしたら、楽しいことかもしれませんが、私の推測では、おそらくそうではないでしょう。パッチを適用するのは大変な作業で、多くの組織ではいまだに手作業で行っています。パッチの適用には、誰もが考えたくないほど多くの時間とリソースを費やしています。

パッチの適用にすべての時間とリソースを費やすのであれば、せめてそれがスムーズに行われるようにしたいところです。パッチ管理にエネルギーを費やして、混乱と失敗のもつれた網の目の中に身を置きたいと思う人はいません。

そこで、月例パッチの問題で最もよくある 2 つの問題に陥らないように気を付けましょう。

パッチは機能していますか？
環境でパッチをテストしましたか？

パッチの問題 1：パッチは機能していますか？

セキュリティパッチや更新に失敗することは珍しいことではありません。時には、独特の環境問題が原因であることもあります。また、パッチ自体に問題があることもあります。

やみくもにデプロイする前に、パッチをチェックしようと決めたのは正しい判断です。しかし、失敗している今、どのような対処ができるのでしょうか。もちろん、それは状況によって異なります。

解決策 1: サードパーティのパッチ管理会社に問い合わせる

サードパーティのパッチ会社を利用してパッチの更新を管理しているのであれば、最初に連絡を取りたいのはその会社です。

サードパーティのパッチを管理する企業は、顧客にプッシュするコンテンツを精力的にテストしていますが、すべてのユースケースのシナリオをテストすることはできません。エッジケースがセットアップされているか、エンドポイントがサードパーティのパッチ会社の予想とは異なるパッチを処理している可能性があります。

どのような理由であれ、ベンダーは常に最初に行動するべき相手です。障害を報告することは、修正してもらうために重要なだけでなく、サードパーティのパッチ会社にとっても有益です。

システム的な問題を見つけた可能性もあります。あなたは、今、パッチ管理会社が一丸となって迅速に解決できるような大きな問題を警告したヒーローなのです。

もしかしたらシステム的な問題ではないかもしれませんが、一般的な問題であるため、パッチ会社は、将来、他の顧客から問い合わせがあったときのために、より効果的に準備を整えることができるのです。言うまでもなく、パッチ会社のデフォルトテストプロトコルに追加できる新しいユースケースシナリオの可能性を提供したのです。

解決策 2: パッチの問題の可能性について、より広範なオンラインコミュニティに確認する

しかし、サードパーティのパッチ適用会社を利用していない場合はどうでしょうか。組織が手作業でこれらのパッチを選別しているとします。

他の組織も同じ問題を抱えているかどうかを調べるには、以下のような素晴らしいオンラインリソースがあります。

PatchManagement.org: 「パッチ管理の議論に特化した業界初のメーリングリスト」
r/sysadmin、infosec.exchangeなどのさまざまなRedditやMastodonコミュニティ、またはベンダー固有のコミュニティ。
Ivanti の Patch Tuesday リソース: どのようなパッチがリリースされ、そこから何が予想されるかを議論するために設計されています。

どの方法を取るにしても、失敗したパッチの何が問題だったのかを特定するためには、多くの選択肢から選ぶことができます。

パッチの問題 2: 環境でパッチをテストしましたか？

さて、あなたはすべてのパッチをテストすることを決めました。もう大丈夫ですよね。

だめです。

また、組織全体から試験的にデバイスにプッシュするパッチをテストすることも忘れてはなりません。

なぜでしょうか。結局のところ、それは単なる Chrome の更新です。しかし、本当にそうなのでしょうか。

システムに新しいパッチを導入することは、家で新しいペットを飼うことと変わりません。ペットを飼ったことがあり、世話の仕方は心得ているつもりでも、部屋や人に対しては、前のペットにはなかった反応を示すものです。

同じように、各パッチには独自のニュアンスの変更と更新があります。これらは多くの場合、システムやプログラムが設計されている目的と矛盾し、たとえ以前のテストに合格していたとしても、環境やパッチの有効性を損ねる可能性があります。

結局のところ、ソフトウェア会社はシステムを念頭に置いて製品にパッチを当てることはありません。むしろ、自分たちのアプリケーションの更新とパッチの適用に集中しており、すべてのユースケースに対応できるわけではありません。

パッチ問題のドミノ効果を解決する

これらの更新をテストする専用の試験的なエンドポイントグループを設定することで、企業が依存しているシステム、プログラム、あるいはプロセスを壊していないことを確認することができます。小さなパッチの更新がもたらすドミノ効果は、企業の経営に悪影響を及ぼす可能性があります。

たとえば、4 月上旬に、Chrome はいくつかのバグに対処するためのパッチを配布しました。しかし、新たなバグも導入され、そのうちの 1 つは Chrome の印刷機能に影響を及ぼしました。

もしあなたの組織が印刷を多用する環境で、Chrome で印刷できることが業務に必須のオプションだとしたらどうでしょうか。

このように、すべてのパッチをテストすることで、小さな些細なものであっても、大惨事を避けることができます。

覚えておいてほしいのは、何か問題が発生すると、エラーは最初に影響を受けた部門やユーザーに波及するということです。ほとんどのユーザーや組織は、小さなパッチが十分にテストされていない場合、それが下流に及ぼす影響について考えていません。結局のところ、障害や停電の後始末をするのは IT 部門であることがほとんどです。

だから、パッチを適用するときには、成功するように準備したいものです。そのために、パッチをテストするための様々なエンドポイントを見つけ、回避可能なダウンストリームへの影響を生じさせないことを確認します。また、パッチが失敗した場合に備えて、コミュニティのリソースも準備しています。

こちらもご覧ください。

リスクベースのパッチ管理ガイドブック: パイロットグループの作成、優先順位付けされたパッチ管理、その他のパッチの基本。
ポッドキャスト「セキュリティインサイト」: 単に新しいパッチを展開する前に、資産を可視化することの重要性を語っています。
Patch Tuesday シリーズ: これまでのパッチの推奨と警告がすべて記載されています。毎月 Patch Tuesday の直後の水曜日に開催される次回をお見逃しなく。

時には、最善のパッチ管理戦略とは、単なる古き良き準備であることもあります。幸運を祈ります！

ITサービスのマッピングによりビジネスとITの連携を改善

Thu, 20 Jul 2023 15:01:05 Z

今日のデジタル化された世界でビジネスを運営するには、業界規制、ビジネスの成長に伴うコストの増大、事業継続計画など、多くの課題が伴います。 ITサービスを効果的に管理しビジネス目標に合わせて調整するために、組織はリソース、予算、部門間のコラボレーションを最適化するサービス管理のソリューションへの取り組みを始めています。

ITサービスの管理を自動化することで、企業は時間とコストを節約し、手作業による潜在的エラーの数を減らすと同時に、ITサービスを効率的かつ確実に提供できるようになります。

正しいサービス管理ソリューションを適切に使えば、組織は自動化ルーツを活用し、効率の最大化とリソース稼働率の改善を実現できます。

ITサービスマッピングの重要性

サービスマッピングのプロセスは、手動で行うことも、ネットワークスキャンから集めたデータを使用してプロセスと目的を結びつけるサービスマッピングツールを使って自動で行うこともできます。

最終的に、このプロセスの結果として、ご使用の物理的コンピューターとバーチャルコンピューター、ネットワークとストレージ資産の間の依存関係をくまなく視覚化するマッピング図が作成されます。すべての依存関係の文書化は、銀行など、監査が必要な業界にとっても極めて高い価値があります。

ITインフラストラクチャーの関係、アプリケーションの依存関係、通信フロー、ゴーストデバイス、ネットワークトポロジー、クラウドの関係、そしてITサービス管理のインシデントや変更を示すマッピング図により、影響、リスク、根本原因の迅速な分析を正確に行うことができます。これらの図では、サービスの提供が顧客満足度やコスト削減にどのように結び付いているかの洞察を得たり、改善が可能な分野を特定したりすることもできます。

Gartnerの調査によると、組織の80%近くが、ITサービスマッピングがITサービスとビジネスの成果を調整し、両立させるのに役立つと考えていることがわかりました。

- “A Guide to IT Service Mapping Aligned with Business Outcomes” [ITサービスマッピングとビジネスの成果の調整へのガイド], 2020

異なるシステム間の依存関係を文書化することは、サービスの供給の全体像を把握したり、ひとつのシステムが別のシステムに影響を与えた場合に発生し得る供給の停止やその他の問題を予測するのにも重要です。

これらの詳細を把握することで、問題が発生した際には、組織は業務を中断することなく迅速かつ効率的に行動でき、最終的には予期しないダウンタイムやセキュリティ侵害に伴うリスクを軽減できます。しかしながら、重要な成功要因は、事前対応的に継続して更新される堅牢な CMDB (構成管理データベース) です。

Gartnerによると、CMDBイニシアチブの80%は、主に手動での更新、限られたリソース、不完全または信頼できないデータ、自己満足またはガバナンスの欠如が原因で失敗しています。

- “Renovating your CMDB to Improve Business Outcomes” [CMDBの刷新によるビジネスの成果の向上], 2019

CMDBイニシアチブ改善のプロセスを開発

自動化されたITサービスマッピングは、管理者がCMDB内の問題をより効率的に特定・解決し、ITサービスのパフォーマンスと可用性を向上させるのに役立ちます。上で説明したサービスマップの視覚化により、チームはCMDB内のさまざまなコンポーネント間の関係性を迅速に特定し、分析できるようになります。

自動検出ツールとサービスマッピングツールの使用に加えて、イニシアチブが従うことになるコアプロセスを確立することも重要です。これにより、データが安全かつ一貫した方法で管理され、イニシアチブが組織としてゴールに合致する方法で確実に前進します。プロセスには、次のステップが含まれているようにしてください (順序は関係ありません):

評価
現在の状況を評価し、不足な点を特定し、ギャップをに対処する計画を考え出すことは、イニシアチブを確実に成功させる上で不可欠です。
測定 & 改善
30日/60日/90日ごとにタッチポイントを設け、進捗状況を追跡し修正を加えるようにしてください。
自動化を念頭に置いた設計
進捗目標に確実に達成するようにするには、自動化されたデータ収集やプロセスを使用したイニシアチブを設計することが重要となります。
ガバナンスを確立
すべてのデータを一貫性を持って安全な方法で確実に管理するには、データ管理と意思決定のための手順、ポリシー、プロセスが必要となります。
目標と指標
目標と指標を特定することで成功の追跡と測定がし易くなり、利害関係者にイニシアチブの進捗状況を知らせ、改善すべき領域を特定し易くなります。指標の例には、次のようなものがあります：
- 構成アイテム (CI) の精度：組織のCMDBにおけるCIの精度を決定します。
- ユーザー受け入れ：システムをロールアウトし、従業員に使用を促す成功率を測定します。
- インシデント解決：インシデントの開発にかかった時間を経時的に追跡します。

全体として、CMDBイニシアチブはこの5段階のプロセスで大幅に改善できます。チームと定期的に会合を持って進捗状況を追跡し、プロセスの自動化、ガバナンス手順の確立、目標および指標の特定、そしてと現在の状況の評価を行うことで、イニシアチブの成功率を向上させることができます。

最良のサービス管理ソリューションを見つける

ITサービスマッピングと正確なCMDBにより、サービス管理のための組織立った構造が提供され、供給されるサービスとサービス間の関係性を明確に可視化することが可能となります。これは、サービス管理のための唯一の信頼できるソースを提供するものであり、ITチームがより効率的か積極的に活動できるパワーを与えるキーとなります。

「Everywhere Work」の時代において、リソース利用率の向上、予算の最適化とチームとのコラボレーションに役立つサービス管理ソリューションに対する組織の関心はどんどん高まっています。しかし、組織にとって最適なソリューションを見つけるにはどうすればよいでしょうか？

利用可能なITSMソリューションを評価する

最初のステップでは、さまざまなサービス管理ソリューションを吟味して評価し、互いに比較してください。それぞれのオプションを評価する際には、コスト、機能、使い易さ、拡張性、カスタマーサポートといった要因を考慮してください。

効率性の向上、コストの低減、サービス供給の改善、スタッフによる学習時間の減少、顧客満足度の向上といった、サービス管理ソリューションがもたらす恩恵を最大化するには、サービス管理ソリューションが既存のシステムやプロセスとどれくらいうまく統合できるかも見ることが重要です。加えて、さまざまなソリューションで提供されているカスタマイズオプションも考慮してください。

自動化を活用する

自分の組織にぴったり合った、適切なサービス管理ソリューションを選んだ後は？今こそ、ソリューションがもたらす大きなメリットを活用するときです。

自動化ツールはプロセスを合理化し、手作業を軽減するのに役立ちます。また、強化された分析能力により、潜在的な問題やリスクを迅速かつ正確に特定することがより簡単になっています。リソース使用率が改善されることで長期的なコストの節約が実現すると同時に、リアルタイムのデータへアクセスにより、ITサービスは確実にビジネスの目標を達成できます。

さらに詳しく知りたいですか？ The First Bank社がサービスマッピングにIvanti Neuronsを活用し、プロセスの自動化、手作業タスクに割り当てられる時間や人数の削減、コストの最適化や継続的計画を実現した方法をご覧ください。

ナレッジ管理で生成AIを活用する方法

Fri, 14 Jul 2023 10:04:44 Z

ブログ「生成 AI によってナレッジ管理にもたらされる利点」では、AI がナレッジ管理にもたらす、コンテンツ作成の自動化、より魅力的なコンテンツの実現という利点について、考察しました。生成 AI をナレッジ管理のフレームワークの一部にすることで、正確さ、データの偏り、プライバシー、セキュリティに関する懸案事項が懸念が生じます。

そこで、次は、どのようにして効果的に機能させられるのかについて

ナレッジ管理で生成AIを活用する方法

日常業務で生成 AI を使用することへの懸念はあるものの、このテクノロジーはナレッジ管理を最適化する強力なツールとなる可能性を秘めています。潜在的な欠点を注意深く検討し、それを軽減する手段を講じることで、組織は生成 AI を利用してナレッジ管理の慣行を改善することができます。

ナレッジ管理に生成 AI を活用する際に考慮すべき 5 つのポイントを説明します。

必ず生成 AI モデルの学習に使用するデータの種類を特定します。データの種類を特定することは、使用されるデータが正確で信頼できることを保証するのに役立ちます。既存のナレッジ記事、インシデントデータ、問題データ、あるいはそれらの組み合わせを使うのか。
データの種類を特定した後、生成 AI は学習したデータと同程度のパフォーマンスしか発揮できません。「garbage in, garbage out (ごみを入れればごみしか出てこない)」という古いことわざは今でも当てはまります。上記で確認したデータが、正確かつ完全で、最新であることを確認してください。
生成 AI モデルの出力を監視し、偏り、誤情報、完全性、正確性の兆候を確認します。これにより、モデルによって生成された情報の信頼性を
ナレッジ管理で生成 AI をすることに伴うリスクを管理するための、方針と手順を策定します。これはプロジェクトの成功を保証するための重要なステップです。これらの方針および手続きは、データセキュリティ、プライバシー、倫理的な考慮事項などの問題に対処する必要があります。また、ナレッジ管理での生成 AI の利用が、責任ある倫理的な方法で行われることを保証するように設計される必要があります。
ナレッジ情報が公開される前に、承認プロセスを導入し、生成された出力がレビューされ、承認されることを保証します。

これらのステップを踏むことで、組織はリスクを最小限に抑えながら、生成 AI を利用してナレッジ管理の慣行を改善できます。

生成AIとナレッジ管理の組み合わせは慎重に

ナレッジ管理における生成 AI の効果と影響は、それがどのように使われ、実装されるかにかかっています。取り入れるかどうかを決める前に、利点とリスクを慎重に評価することが重要です。

利点と課題をいくつか確認します。

利点

1. 関連コンテンツの自動生成

生成 AI を使用すると、製品ドキュメント、カスタマーサポートチケット、従業員研修資料など、既存のデータソースからナレッジ記事を自動的に作成できます。

IT 専門家の 32% は、リモートワークへの移行以来、ヘルプデスクのチケットが増加していると報告しています。このため、より迅速で効果的な問題解決を可能になり、IT 専門家は、新たなナレッジ管理イニシアチブの開発や、既存のナレッジ記事の質の向上など、より戦略的な業務に専念できるようになり、ナレッジベースの強化には大きな機会となります。

2. 検索の精度の改善

生成 AI は、各従業員のニーズや好みに基づいて、ナレッジの提供をパーソナライズすることで、検索の精度を改善できます。平均的な従業員は 1 日に 3.6 時間を情報検索に費やしているため、ナレッジの提供方法における時間の節約は大きな利点です。

情報への容易で迅速なアクセスを可能にすることは、最終的に従業員のデジタル体験の向上につながります。

3. 自動化の強化

生成 AI は、ナレッジ管理記事の作成とは直接関係がなくても、ルーチンタスクの自動化を支援できます。

IT担当者の85% は、自動化と AI への投資を収益性の高い事業と評価しており、プロセスを合理化する新しい方法を特定することで、IT担当者はより複雑な問題に集中する時間を確保することができます。

利点

1. 誤情報のリスク

生成 AI は、誤った情報や誤解を招く情報を潜在的に生成する可能性があり、IT 分野で深刻な事態を招きかねません。たとえば、マルウェアの侵入や、悪意のある主体から IT 環境を守るために使用されている機能をオフにすることを誤って推奨するといった問題があります。

2. AIが生成コンテンツへの依存

AI が生成したコンテンツに依存しすぎると、人間が生成したコンテンツや批判的の思考の能力を優先しなくなり、専門が知識が失われる可能性があります。生成 AI をめぐるすべての議論にもかかわらず、正確性を検証し、生成された情報を承認するには、人間の監視が必要です。

3. 倫理的な懸案事項

生成 AI の使用には倫理的な懸案事項があります。たとえば、モデルの学習に使用されるデータに偏りがある可能性があり、それが既存の不平等を永続させる可能性があります。

生成 AI が IT ナレッジ管理の貴重なツールになることは間違いありません。しかし、新しく、興味深い技術ですが、生成 AI のもたらしうる利点と落とし穴については、まだ学ぶべき点が多数あります。

各組織は、潜在的な影響を個別に検討し、プライバシー、正確性、セキュリティのニーズを満たす適切な AI ソリューションを選択する必要があります。

ナレッジ管理のための生成AI導入のヒント

小規模から始めて、拡張する

規模なパイロットプロジェクトから始めて、経験を積みながら生成 AI を使って規模を拡大することをお勧めします。

ステークホルダーの賛同を得る

生成AIを本番に導入する前に、ステークホルダーの賛同を得ることが重要これにより、モデルが効果的に使用され、出力が信頼できることが保証されます。

モデルのパフォーマンスを監視する

モデルを本番にデプロイした後、モデルのパフォーマンスを監視することが重要です。これにより、モデルの潜在的な問題を特定し、モデルの精度を改善できます。

モデルを継続的に改善する

生成 AI モデルは常に改良されています。新しいデータで再学習し、潜在的問題に対処することで、継続的にモデルを強化することが重要です。

技術スタックの統合によってどのように DEX の結果が推進されるのか

Tue, 04 Jul 2023 11:58:23 Z

毎月のように、新しい「必携」のツールが市場化されています。結局のところ、IT チームはさまざまなツールの寄せ集めのようなものを与えられ、不必要なフラストレーションと作業負荷の増大に直面しています。

「問題は、このような体験をするための技術や方法があまりにも多く、ツールが多すぎることで、体験が希薄になり、フラストレーションが溜まるという罠に陥りやすいことです。SharePoint サイト、Teams、Yammer、Service Now、One Drive など、複数のサイトに情報があり、ほかに何があるのか誰もわかりません。さらに、どこを探せばよいのかわからず、どのチャンネルもフォローしていない場合は見逃してしまうので、非常に悪い経験をしています。自分の基準を選び、その月の流行に流されないようにすることです。」

- Emerson Electric Co チームリーダー

あまりにも多数の分散したツールを使用して、デジタル環境を拡大すると、さまざまなデバイスや場所でデジタル体験の最適化が失敗し、組織が効果的に Everywhere Work に適応する能力が損なわれます。

デジタル従業員体験 (DEX) を向上させるための基盤を構築するには、技術スタックを統合することが重要な要素になります。

管理されていないツールと資産が DEX を阻害する理由

一部の組織では、2020 年以降、デジタル変革が 3～5 年加速されたと報告されています。 2、3 年前とは異なり、資産はもはやオフィスに存在するだけではありません。資産は世界中に分散し、その数も増えています。最近の報告では、平均的な従業員は業務を遂行ために 2.6 台のデバイスを使用しています。

しかし、資産が増えれば問題も増えるわけです。2020 年以降、従業員の 45% がより多くの技術的問題を経験しており、平均的な従業員は 1 日に 3.67 件のエンドポイントの問題に遭遇しています。

毎日の問題の件数がこれほど多いことは、価値あるインサイトがさまざまな場所で急増していることを意味します。

このような複雑な環境にタイムリーに対処し、あらゆる問題に能動的に対応するためには、ツールやシステムが相互に連携していないと困難です。

適切なツールがないまま、より複雑な環境になったことで、IT とセキュリティの専門家は圧力を感じています。73% が、ハイブリッド/リモートワークを導入して以来、仕事量が増えたと回答しています。実際、IT およびセキュリティ担当者の 3 人に 1 人が、燃え尽き症候群のために少なくとも 1 人のチームメンバーを失ったと報告しています。

そして、このような職場環境は、すぐにはなくならないでしょう。当社の Everywhere Work 調査では、次のことが明らかになりました。

· 71% のオフィス勤務の従業員は、ハイブリッド (出社する日を自分で決められる) かリモートで働きたいと考えています。

· 66% の従業員が、リモートワークによる否定的な影響を経験したことがあると回答しました。

· 経営幹部の 71% がハイブリッド勤務は従業員のモラールに好ましい影響を及ぼしていると認めました。

一部の組織では、すでに対応が取られています。 EMA が最近実施した調査によると、回答者の 86% が資産関連ツールの統合を検討しており、18% はすべての資産タイプを 1 つのプラットフォームで管理することを積極的に計画しています。

「一元管理がきわめて重要です。ツールが多すぎるというのは課題です。」

- CFCU Community Credit Union システム管理者

技術スタックを統合することで、自動化の基礎ができ、作業負荷が軽減されます。そして、最終的に、IT およびセキュリティチームのデジタル燃え尽き症候群を抑制できるようになります。技術が従業員の日常業務とより密接に関わるようになった今、IT チームがこの環境を管理、保護、サポートする効率的な方法を提供することは、より良い体験を提供するために極めて重要です。

技術スタックを統合する利点

技術スタックの統合は、さまざまな方法で、次のように DEX の取り組みを支援します。

1. IT 担当者にとっての複雑さを低減する

今こそ、手作業のプロセスや非効率な作業に終止符を打つ時です。組織のワークフローをつなぎ、シンプルにすることで、IT 環境を合理化し、自動化できます。これにより、不必要な複雑さを取り除き、IT チームの体験を向上させることができます。

2. より対応力があり、効率的な IT サポート

28% の従業員が、より対応力の高い IT サービスデスクを望んでいます。 IT 部門がすべての情報を一元的に把握することで、より迅速かつ効果的にチケットに対処し解決することができます。

3. 顕在化する前に問題を予防する

問題を素早く解決し、理想的には問題を未然に防ぐことで、より良い体験が生まれます。調査によると、作業者が作業に集中できるようになるには、最大で 20 分かかると言われています。技術スタックを簡素化し、貴重なインサイトに一度にアクセスできるようにすれば、問題を未然に防ぐことができるようになります。従業員をサービスキューから解放して業務に集中させることができるため、組織全体で失われた数千時間の生産性を取り戻せます。

Everywhere Work 時代において、より良い従業員体験を実現するためには、技術スタックを統合することは避けて通れないステップです。 IT 構造の簡素化と合理化により、IT チームとセキュリティチームの業務が容易になります。そして、これにより、従業員の感情を理解し、時間をかけて体験を追跡、最適化し、問題が発生する前に予防するための時間を確保することができます。

DEX の詳細については、オンデマンドウェビナーの A step-by-step guide to planning and measuring digital employee experience (デジタル従業員体験を計画して測定するための段階的なガイド) をご覧ください。

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 プログラムのベストプラクティスの詳細については、このディスカッションの続きをご覧ください。

クラウド移行が従業員体験の向上にどのように役立つか

Mon, 26 Jun 2023 15:06:19 Z

古い格言で、「practice what you preach) 人に言うことは自分も実行せよ」というものがあります。Ivanti が「カスタマーゼロ」イニシアチブを開始したとき、最高情報責任者の Bob Grazioli は、顧客が消費する製品やサービスをテストする絶好の機会だと考えました。

たとえば、Ivanti がクラウドに移行する際、Grazioli のチームは、顧客が移行プロセスで経験するのと同じ問題を経験しました。この実体験によって、途中で改善することができました。 Grazioli が詳しく語る、カスタマーゼロイニシアチブのその他の重要な発見や、ITSM の拡大が従業員体験を向上させる方法について、お聴きください。

Ivanti の「カスタマーゼロ」プログラムからの主な教訓

「実際にとても誇りに思っているので、カスタマーゼロプログラムを称賛してもらえるのは光栄です。私たちは Ivanti で最初の顧客です。 IT や SaaS に明らかに適用可能なすべてのツールを、お客様よりも先に導入し、プロダクトマネージャーやエンジニアリングチームにフィードバックを提供します。そして、そのフィードバックを製品に反映させるか、テスト中に明らかに発見できなかった場合は、お客様で発生する潜在的な問題を排除します。  

しかし、そうは言っても、実際にオンプレミスから SaaS に移行するにあたっては、非常に多くのことを学びました。カスタマーゼロで行われた内容を見ると、Ivanti のオンプレミス製品を見直し、クラウドに移行することに重点を置いています。もちろん、私は　SaaS　を管理しているので、クラウドに非常に偏っていますし、今はクラウドに重点を置いています。だから、パッチを取って、オンプレミスからクラウドに移行しました。

私たちは現在、ワークフロー管理と ITSM コンバージド製品を、ローコード、コードなしで、ITSM のための IT に移行しました。私たちは、Discovery に対して実行している独自の CMDB を持っています。データセンターに目を向けると、私たちが管理している地域の数は世界全体で 40 箇所近くあり、そのすべてのデータセンターで何千、何万もの資産を管理しています。それらはすべて私たち自身の CMBD に配置され、管理されています。  

私たちは今、コンプライアンスのために GRC を導入しています。私たちのところでは、多くの企業が SOC2（SOC2 タイプ 2）で苦労しているように、成果物は特定のリポジトリに保管されました。私たちはそれらの資産を管理しました。現在では GRC があり、これらの成果物はすべて ITSM で管理されています。それらは適切な統制に関連付けられています。監査プロセスが非常にシンプルになり、毎年のコンプライアンス遵守が非常に容易になりました。    

オンプレミスから SaaS へのクラウド移行による効率化によって、時間の節約、事業運営費 - 設備投資の式という点での ROI の向上が実現されることを学んでいます。CIOの多くがこのような経験をすれば、設備投資と運用コストの面で大きな利点があります。」

より広範な組織をサポートするために ITSM を活用する

「そして、ITSM のすべてのデータをクラウドに置くことで、先ほど説明したように、パッチ、検出、RiskSense [現在はリスクベースの脆弱性管理として知られている] 脆弱性のための信頼できる唯一の情報源そして明らかに、主な焦点は、顧客と向き合う側で作成されるすべてのチケットであり、顧客が何を使っているか、あるいは何を使っていないかについて、顧客に関する洞察が得られます。つまり、SaaS で管理する必要があるのは、本当の意味でのユーザー体験なのです。  

すべての製品をオンプレミスから SaaS に移行させ、自社のクラウドで SaaS 製品を活用し、その経験を積んでプロダクトマネージャーに還元し、エンジニアリングに還元することで、クラウドに移行するすべての顧客に対してより質の高い製品とサービスを提供することができました。  

そのため、オンプレミスからクラウドに移行する際に顧客が経験するような特別な問題は、私たちが一掃することができます。カスタマーゼロ - オンプレミスから SaaS に移行することで、顧客が抱えていたであろう多くの問題が解消されることは間違いありません。そして、製品を改良し、顧客に対する品質とサービスを向上させるために、貴重なテレメトリを提供しています。」

Ivanti のカスタマーゼロイニシアチブの重要な要点

「サービス申請のカタログなどを改良しました。それこそが、ITSM がなすべきことの進化です。しかし、DEX が重要です。顧客の問題や顧客の成功、あるいは顧客が当社の製品を使っていることなどを示すチケットがすべて、ITSM にあります。

というのも、先ほど説明したように、DEX があることで、すべてのチケットを見て、チケットを分析し、デバイスの問題や、潜在的に顧客が私たちが環境に押し出した特定のテクノロジーを採用する方法をプロアクティブに予測することができるからです。

これらのチケットは、顧客により良い体験を提供するために必要な洞察を得ることを可能にする、そのレベルのテレメトリにとって非常にす。価値があります。チケットの管理は本当に大変だと思います。明らかに、チケットの数が多いのは、良くない場合もあるので、多数のチケットは望ましくありません。しかし、これらのチケットは、顧客に関する知識という点で、私たちが物事を改善し、サービスの質を向上し、顧客がより良い経験をするために本当に役立っています。」

DEX を使ってカルチャーに変革を促す方法

「つまり、私たちは文化という言葉を使いますが、現実を直視してください。今日の顧客の世代はテクノロジーとともに成長し、多くのテクノロジーを自由にコントロールする能力を持っています。それこそが、本当に対応しようとしていることなのです。

従業員として入社してきた人に、同じような経験をさせたくはありません。家庭や市場以外の場所でも、同じようにテクノロジーと関わることはできません。それが、私たちが目指しているものであり、その顧客のためのものなのです。  

なぜなら、今日、私たちは製品にプロアクティブな性質を持たせているからです。プロアクティブな特性。それが DEX です。

それは、共感をもって顧客に関わり、顧客が抱えているどんな問題に対しても解決策を提供する積極的なアプローチをとるためのあらゆるインテリジェンスを持つことです。それは、顧客が経験していることに共感し、どのような経験で電話をかけてきたとしても、迅速で信頼できる解決策を積極的に提供することです。

それが私たちの目標であり、ITSM はそれに向けて進化していると思います。なぜなら、私たちが適用している AI や ML を駆使して収集、利用できる情報量が増え、社内外にいる非常にインテリジェントでテクノロジーに精通した顧客に対して、よりプロアクティブな体験を提供できるようになったからです。  

そして、今それが起こっています。それが私の目に映る文化であり、私が関わっている文化です。私たちの製品が満足できるものであることを確かめたいと思います。 "

ITSM を他の分野にも広げることで、新たなレベルのプロアクティブなトラブルシューティングと共感がもたらされ、より良いデジタル従業員体験を促進することができます。

さらに詳しくお知りになりたい方は、ITSM + ツールキットをご覧いただき、ITSM の拡張: 接続された企業ワークフローを構築するための主な学習事項に関するオンデマンドウェビナーを視聴してください。