セキュリティの統合

組織において、セキュリティは、ビジネス要件、パフォーマンス、信頼性と同様に、すべての人の仕事の一部である必要があります。 セキュリティは、すべてのレベルで、組織の全体的なビジネスの優先順位、IT イニシアティブ、リスク選好度に通じている必要があります。 セキュリティは、ビジネスのあらゆる側面に織り込まれた糸のようなものです。 セキュリティをビジネスの本質的な部分だと感じる必要があります。 ビジネスをセキュリティの本質的な部分だと感じる必要があります。

組織では、ビジネス プロセスとの摩擦を最小限に抑えながら、セキュリティ保証を維持する必要があります。

組織内では、内部摩擦やチーム間の低レベルの対立が発生する可能性があります。 このような対立は持続可能なものではありません。 クラウド、デジタル ビジネス、ゼロ トラスト セキュリティの時代には、すべてのチームが連携することが不可欠です。 各チームが異なる目標、カルチャ、言語で活動すると、組織の効率と有効性は低下します。

セキュリティ チームの活動がサイロ化していないことを確認してください。 各チームが、円滑にプロセスを運用し、知識を共有できるように、緊密に連携する必要があります。

次のビデオを視聴して、ビジネスのあらゆる領域でのセキュリティの統合に関する詳細を確認してください。

このガイダンスでは、ビジネスおよび IT チームとセキュリティの統合、およびセキュリティ チーム間の統合を促進する方法について説明します。

関係を正規化する

多くの組織にまん延しているサイロ アプローチを克服することは、困難な課題ですが、不可能ではありません。 主な要素は、最終状態を十分に理解し、プロセスを明確化し、具体的な目標とカルチャや行動の変化に対して継続的なリーダーシップ サポートを提供することです。 プロセスには次の要素が不可欠です。

• 共有の目標と成果を特定する。
• 適切なレベルのセキュリティを特定する。

共有の目標と成果を特定する

すべてのチームが関与する目標について、共通認識があることを確認します。 セキュリティ チームは、ビジネスと IT の機能に対する品質管理として定義される場合があります。 このアプローチでは、敵対的な力が生まれ、摩擦が起きます。 ビジネスの生産性、IT の目標、セキュリティの目標は、この力の影響を受ける可能性があります。

セキュリティ チームが対応する IT およびビジネスチームと密接に統合されていることを確認してください。 セキュリティ チームは、あらゆるイニシアティブのビジネス、IT、セキュリティの成果に対して共同で責任を負います。 ビジネスと IT の目標を満たすシステムを設計するという課題を共有します。 セキュリティの観点と専門知識を適切なタイミングで共有します。

システムの設計、実装、運用、継続的な改善を行う際に、ビジネス、IT、またはセキュリティに関連する "すべての決定が 1 つの声に支配されない" ように、ガードレールを設定する必要があります。

適切なレベルのセキュリティを特定する

Windows Hello for Business を使用した生体認証サインインなどのセキュリティ制御には、ユーザー エクスペリエンスを向上させ、セキュリティを強化するという二重の利点があります。 多くのセキュリティ対策は、ビジネス プロセスに摩擦を与え、その進行を遅らせる可能性があります。 私たちはまず、簡単で、ユーザーや開発者には見えないセキュリティ対策を見つけようと努力します。 場合によっては、トレードオフが必要であることを受け入れなければなりません。

こうした共同チームでは、適切なタイミングで批判的な思考を促すことで価値を生み出す健全なレベルの摩擦をプロセス内で常に生み出すように努力する必要があります。 たとえば、攻撃者が新しい機能を利用してどのような攻撃を行うか、あるデータの改ざんがビジネスにどの程度影響するか、などを検討します。

各チームは、次の 2 つの絶対的真理の間で最適なバランスを取る必要があります。

• セキュリティは省略できない。 セキュリティを省略すると、多くの場合、最終的にセキュリティを統合する場合より多くのコスト (生産性、収益、全体的なビジネスへの影響) が発生するインシデントにつながる。
• セキュリティ制御は、セキュリティ上の摩擦によって保護される価値より阻害される価値の方が多くなるような、不健全なレベルの摩擦を招く可能性がある。

セキュリティをプロセスに統合する際には、バランスを見い出すことが重要です。 すべての利害関係者が連携して、ビジネス上の懸念事項、IT の信頼性とパフォーマンスに関する懸念事項、セキュリティ上の懸念事項を考慮し、バランスを取る必要があります。 組織では、80% を解決し、残りの 20% を計画するという取り込みも必要です。 100% の解決が得られるまでセキュリティの制御と機能を留保すると、組織で行われるすべての活動が開示の危険にさらされます。 反復的なアプローチは、更新と教育の基本がそうであるように、うまく機能します。

健全なセキュリティ上の摩擦の詳細については、セキュリティ戦略ガイダンスの「適切なレベルのセキュリティ上の摩擦」を参照してください。

次のセクションでは、セキュリティの利害関係者を IT、エンド ユーザー、ワークロード所有者と統合する方法について説明します。 これには、セキュリティ チーム内部の例も含まれています。

IT およびビジネス運用と統合する

ほとんどのセキュリティ機能は目に見えない形で動作しますが、セキュリティに関する考慮事項の一部は、日常のビジネスおよび IT ワークフローに出現します。 セキュリティの考え方を、ビジネスの計画と運用の通常のエクスペリエンスに統合する必要があります。

セキュリティ更新プロセス

セキュリティ更新は、ビジネス プロセスとセキュリティ プロセスが相互作用する最も一般的で目に見えるポイントの 1 つです。 これは、組織内の別々の利害関係者にマップされる次の 2 つの異なる力の難しいバランスが関係するため、摩擦の原因になりがちです。

• 当面のビジネスへの影響: 多くの場合、セキュリティ更新にはテストとシステムの再起動が必要であり、そのためにアプリケーション所有者と IT チームの時間とリソースが消費され、ダウンタイムによるビジネスへの影響が発生する可能性があります。
• セキュリティ リスクとしての潜在的な将来のビジネスへの影響: 更新プログラムが完全に適用されていない場合、攻撃者は脆弱性を悪用し、ビジネスに影響を与える可能性があります。

各チームが目標と責任を共有せずに活動すると (たとえば、IT とビジネスが当面のビジネスへの影響に 100% 集中し、セキュリティがセキュリティ リスクに対して 100% 責任を負うと)、セキュリティ更新をめぐって絶えず対立することになります。 この対立により、チームは協力して問題を解決するのではなく、果てしない議論を繰り返すだけになり、次の問題、リスク、ビジネス価値の創出機会に進むことができなくなります。 組織全体での継続的なコミュニケーションと、更新プログラムを受け入れるカルチャの育成は、エンド ユーザーからの抵抗を抑えるために大いに役立ちます。 ユーザーに、自身がより適切に保護されること、生産性が向上すること、セキュリティとの共存によってビジネスを構築できることを理解してもらうと、ユーザーが更新プログラムと継続的な教育を受け入れる可能性が高まります。

資産所有者にすべての利点とリスクの説明責任を適切に負わせると、当面および将来の潜在的な影響を検討しやすくなります。 ソリューションの識別をセキュリティ、IT、ビジネスの各領域の専門家の共同責任にすると、より多くの多様な見方を検討できるため、ソリューションの品質が向上します。 すべての人を、会社全体のセキュリティ対策の利害関係者にします。 すべての人がセキュリティを日常の役割としているわけではありませんが、誰でも役割を実行するためのセキュリティ要件を持っています。

このプロセス例では、組織が限られた時間内に共有の責任と柔軟性を使用してこの問題をどのように解決し始めるかを示しています。

このプロセスは定期的に実行されます。

• 企業の IT およびセキュリティ チームは、プロセスの開始時に、どのセキュリティ更新プログラム (パッチ) が必要であり、最も大きな影響を与えるかを特定します。 これらの更新プログラムは、企業全体の配布チャネルを通じてエンド ユーザーまたはワークロード所有者に公開されます。
• エンド ユーザーは、一定の期間内に更新プログラムをテストし、それらを適用し、自身のデバイスを再起動します。 この期間が経過すると、企業の IT およびセキュリティ チームは、更新プログラムを適用するか、企業リソースへのアクセスをブロックします。 Microsoft Entra 条件付きアクセスやサードパーティ製のネットワーク アクセス制御ソリューションのようなメカニズムを使用する場合もあります。
• ワークロード所有者には、更新プログラムをテストし、それらを実稼働システムに適用し、必要に応じて再起動するために一定の期間が与えられます。 このセルフサービス期間と猶予期間が経過した後、企業の IT およびセキュリティ チームは、更新プログラムを強制的に適用するか、他の企業リソースから分離します。 厳しい要件を持つ一部の組織では、Azure サブスクリプションまたは AWS アカウントから資産を削除することで、資産の使用を停止する場合があります。
• 企業の IT およびセキュリティ チームは、更新プログラムの状態を監視し、特定された強制修復を実施します。

このプロセスは静的なものではなく、1 日で終わるように設定されるものでもありません。 長期間にわたって繰り返し構築され、継続的に改善されます。 任意の段階から開始し、プロセスを継続的に改善しながら、この最終状態に向けて段階的に発展させます。 次の要因を使用して継続的な改善を計画します。

• カバレッジ: 成功の可能性が高い、または侵害された場合にビジネスに大きな影響を与えるような、いくつかのアプリケーション チームから始めます。 環境内のすべてのワークロードを網羅するまで、さらに追加します。
• 時間: 達成できることがわかっている期限から始めて、1 週間以内に完全に更新できるようになるまで、継続的に期限を早めるための明確なロードマップを設定します。
• テクノロジの範囲。 アプリケーション、ミドルウェア、アプリケーション コードで使用されるオープンソース コンポーネントなど、パッチとテクノロジの対象範囲を継続的に拡大します。 メンテナンスの負担を軽減するため、自動的に更新されるコンポーネントの使用を推奨するようにします。 たとえば、独自の SQL Server をインストールして更新する代わりに、Azure SQL Database を使用します。
• プロセス: チーム間の通信チャネル、優先順位付けのガイダンス、例外プロセスを含む、このプロセスのあらゆる側面を継続的に改善します。

セキュリティ チームを統合する

セキュリティ チームは、サイロでの活動によって発生するビジネス リスクの増加を避けるため、連携して共同作業を行う必要があります。 セキュリティ チーム間で学習と重要な分析情報が共有されない場合、組織は回避できたはずの将来のインシデントによってより大きな損害と影響を受ける可能性があります。

セキュリティは、常にアクティブな脅威に対応し、常に学習し、プロセス、ツール、テクノロジを継続的に改善する必要がある動的な規範です。 セキュリティは、攻撃者の手法、テクノロジ プラットフォーム、組織のビジネス モデルの変化に常に適応する必要があります。 セキュリティ チームは、連携して脅威に迅速に対応し、分析情報と学習をプロセスに継続的に統合する必要があります。これらはどちらも、組織のセキュリティ体制と攻撃に迅速に対応する能力を向上させます。

次のワークフロー図は、学習と分析情報を完全に統合してセキュリティ全体を改善するために、セキュリティ規範がどのように連携するかを示しています。

セキュリティの主な使命は、以下の状況に迅速に対応することです。

• 新しいインシデント: 組織のリソースにアクセスできるアクティブな攻撃者は、組織に差し迫ったリスクをもたらします。これは、最優先事項として迅速に修復する必要があります。 修復後、これらの攻撃は将来の攻撃の特徴を学習する絶好の機会になります。 成功しても失敗しても、攻撃者は同じターゲット、手法、または収益化モデルを繰り返し追求する可能性があります。

• 新しい分析情報と学習: 新しい分析情報と学習は、次のソースから取得できます。

  • 外部インシデント。 他の組織のインシデントから、攻撃者に関する分析情報が得られます。 この組織でも同じことを試みる可能性があります。 これらの知識から、改善計画に必要な情報を得たり、投資が適切な方向に行われていることを検証したりします。情報共有および分析センター (ISAC)、ピア組織との直接的な関係、またはインシデントに関するその他の公的なレポートや分析を通じて、外部インシデントを見つけます。

  • 新しい技術機能。 クラウド プロバイダーやソフトウェア ベンダーは、継続的にイノベーションを行っています。 自社の製品に次のような機能を追加しています。

    • セキュリティ防御を必要とするビジネス機能。
    • セキュリティの機能を高めて資産を保護するセキュリティ機能。 これらの機能は、クラウド プラットフォームや他のプラットフォーム テクノロジに統合されたネイティブなセキュリティ機能である可能性があります。 従来のスタンドアロンのセキュリティ機能である可能性もあります。
    • クラウドベースのセキュリティから取得できる可視性とテレメトリは、組織が 1 つのオンプレミス環境から取得できるレベルをはるかに上回ります。 これらのデータはすべて、クラウド全体からメタデータを使用して収集されます。 これらのデータには、行動分析、デトレーション チャンバー、機械学習、AI などの厳格な分析プロセスが適用されます。

  • 業界のベスト プラクティス: 米国国立標準技術研究所 (NIST)、Center for Internet Security (CIS)、The Open Group などのベンダーや組織が提供する業界のベスト プラクティス。 これらの組織は、セキュリティ チームが学習できる学習項目やベスト プラクティスを収集して共有する特権を持っています。

  • 脆弱性とは、攻撃者が資産を制御するために悪用できるもの (ソフトウェアの脆弱性など) のことです。 セキュリティ構成の選択肢、暗号アルゴリズムの弱点、セキュリティで保護されていないプラクティス、システムを使用または管理するためのプロセスなどもあります。 脆弱性を発見した場合は、セキュリティ体制に与える影響と、攻撃の検出、攻撃への対応、攻撃からの回復が可能かどうかを評価します。

• 脅威への対応: セキュリティ運用チームは、検出結果を調査します。 組織内の制御ポイントから敵対者を排除することで対応します。 組織の規模とインシデントの複雑さによっては、この対応に複数のセキュリティ チームが関与する場合があります。

• 根本原因分析: 大規模なインシデントの可能性や影響を大きくした主な要因を特定することで、組織のセキュリティ体制と対応能力を向上させる分析情報の学習が行われます。 これらの学習は、攻撃ツールおよびインフラストラクチャ、攻撃手法、ターゲット、動機、収益化モデルなど、多くの要因に沿って行われます。 根本原因分析によって、予防的コントロール、発見的コントロール、セキュリティ運用プロセス、あるいはセキュリティ プログラムまたはアーキテクチャのその他の要素に必要な情報が得られます。

• 脅威の検出: 脅威の事前検出は、継続的なアクティビティです。 検出では、検出計画と仮説立案において新しい分析情報や学習を常に考慮する必要があります。 検出チームは、次の主要な側面に重点を置くことができます。

  • 最近の広範囲または影響の大きい脆弱性。
  • 新しい攻撃者グループ。
  • カンファレンスで示された新しい攻撃手法。

• 軽減策の設計と実装: 学習した教訓は、技術環境とセキュリティおよびビジネスの両方のプロセスに統合する必要があります。 各チームは、教訓をアーキテクチャ、ポリシー、標準に統合するために連携する必要があります。 たとえば、最近の内部または既知のインシデントで発生した管理者資格情報の盗難は、組織が Microsoft の特権アクセスの制御を導入するきっかけになる可能性があります。 詳細については、「セキュリティの迅速な最新化計画」を参照してください。

次のステップ

クラウド導入を計画する際には、セキュリティ機能の統合に重点を置きます。 セキュリティをより大きな組織と統合します。 セキュリティによって生じる摩擦に細心の注意を払います。 摩擦が健全であることを確認してください。 健全な摩擦であれば、保護される価値より阻害される価値の方が多くなるような減速が起きないため、組織のリスクが軽減されます。

• セキュリティ戦略の定義を確認する

• クラウド セキュリティ機能を確認する

• セキュリティの次の重点領域であるビジネスの回復性を確認する。