情報セキュリティのライフサイクル

ITのあらゆる分野において、プロジェクトはライフサイクルモデルを通じて管理されることが多く、製品は終わりのない改善と維持のサイクルを継続します。このことは、他のIT分野と同様に、情報セキュリティにおいても当てはまります。

情報セキュリティのライフサイクルは、セキュリティのプロの日々の業務における基本的な指針となります。情報セキュリティ計画のライフサイクルモデルを理解することで、企業内の情報セキュリティの継続的な進化を可能にする指針を得ることができます。

本ガイドでは、「情報セキュリティプログラムのライフサイクルにおけるフェーズとは何か」という重要な疑問点について説明します。

基盤：セキュリティポリシーと基準

情報ライフサイクルのフェーズについて詳しく説明する前に、まずは中核的な要素について説明します。

情報セキュリティプログラムのライフサイクルは、堅牢な基盤に依存します。この基盤とは、セキュリティチームがライフサイクルプロセスを構築するうえでの基礎となる、企業の方針と手順の集合体です。

堅牢な基盤を持つことによるメリット期待値・目標の明確な設定緊密な関係の構築効率的な改善

明確で徹底したポリシーと基準は、情報セキュリティの核心的な要素です。明確な基準の確立に時間を割り当てることにより、以下のようなメリットが得られます。

期待値・目標の明確な設定：ポリシーと手順は、セキュリティチームが現行のシステムと新規システムの両方を分析・評価する際に参照できる明確な枠組みを構築します。システムやプロセスを曖昧な目標と比較するのではなく、比較のための確固たるポリシーと基準を確立します。
緊密な関係の構築：多くの情報セキュリティプロジェクトは、個別の問題領域ごとに独立して実行される場合があります。明確なポリシーと手順は、全てのチームが作業できる基盤を構築し、矛盾する解決策や更新を最小限に抑えるのに役立ちます。
効率的な改善：詳細なポリシーと基準は、システムやソリューションの開発・評価時にチームが参照できる基盤を確立し、チーム間の煩雑なやり取りや手戻りの必要性を最小限に抑えます。これにより、情報セキュリティのライフサイクルを通じて、セキュリティチームの業務効率が高まります。策定したポリシーと手順によっては、情報ライフサイクルの基盤が他社と根本的に異なる場合があります。しかし、このような基盤の違いにもかかわらず、企業の情報セキュリティのライフサイクルは概ね同様の段階的なプロセスに従う傾向があります。このプロセスについて、以下のセクションで詳細に説明します。

フェーズ1：特定

情報セキュリティプログラムのライフサイクルの最初のフェーズは、保護が必要な項目の特定です。情報セキュリティプロトコルにおいては、認識していないものを保護することはできません。したがって、保護項目の特定は、ライフサイクルがネットワークのあらゆる側面を網羅することを保証する重要な第一歩となります。

特定のプロセスは、主に、対象とするネットワークのマッピングから始まります。まず、高レベルな視点から着手し、次第に下位のレベルへと掘り下げていきます。この情報は、情報セキュリティチームがシステム内のアセットとそれらの相互関係および、情報セキュリティプロトコルに現時点で利用可能なリソースを理解するのに役立ちます。特定のフェーズで検討すべき主要項目には、以下のものが含まれます。

利用可能なサーバー、ルーター、その他のアセットの数
物理的なアセットの設置場所
ネットワーク上で稼働しているオペレーティングシステムの種類
システム上で稼働しているアプリケーションおよびソフトウェアの数と種類
各部門におけるアプリケーションおよびソフトウェアの普及状況と重要性
ネットワーク上の各コンピューターおよびモバイルデバイスの状態
自社にとって最優先のアセット
セキュリティシステムの現行インフラ

この情報を収集するには、会社のシステム監査を実施する必要があります。監査は通常、現行のツールやプラットフォームの把握と評価から始まります。ただし、この監査にはインタビューや内部協議も組み込む必要があります。セキュリティ担当者、ITスタッフ、他部門の関係者との対話を通じて、現行のシステム、システム間の相互関係、社内での目的、各部門における重要性について深く理解することができます。監査の一環として、社外の専門家の協力を得て自社のセキュリティ体制を客観的に評価するケースも多く、これにより、監査で収集される情報にさらなる深みが加わります。

監査が完了すると、情報セキュリティチームは現状の企業情報セキュリティ体制を包括的に把握できます。データは文書化され、情報セキュリティのライフサイクルにおいて今後も利用・参照できるよう保管されます。

フェーズ2：評価

情報セキュリティチームが特定プロセスを通じて組織の既存技術の徹底的なマッピングが完了したら、次は評価フェーズに移ります。評価フェーズでは、セキュリティ専門家が特定プロセスで収集した情報を基に、全てのアセットに対するセキュリティ評価を実施します。この評価プロセスは、情報セキュリティのライフサイクルにおいて最も広範なフェーズの1つであり、プロセスとシステムのレビュー、サーバーのレビュー、脆弱性の評価など複数の領域をカバーします。

1. プロセスとシステムのレビュー

評価フェーズの最初の段階は、ビジネスの現在の構造をレビューすることです。このレビューでは、セキュリティ専門家が特定プロセスで概説された構造を精査し、脆弱性を特定するための追加情報を収集します。特に大規模な企業にとっては膨大な作業となる可能性があるため、評価プロセスのこの段階では一般的に以下の方法のいずれか、または複数を併用することが推奨されます。

まずは重要なアセットに焦点を当てる：評価プロセスを効率的に進める方法として、アセットの重要度に基づく優先順位付けが挙げられます。組織が機能するための最重要アセット、最も脆弱なアセットを優先して評価プロセスを開始します。重要な改善点を早期に特定し、セキュリティチームによる迅速な改善を可能にします。
上位から下位へと評価する：評価プロセスを扱うもう1つの方法として、上位レベルのシステムから分析を開始する方法が挙げられます。最も汎用的な上位のシステムから下位のシステムへと分析を進めることで、重大な問題を早期に特定できます。
フラグを探す： 情報セキュリティチームは、特定のプロセスにおけるに危険信号や懸念事項を既に把握している可能性があります。これには古いソフトウェアバージョン、陳腐化したハードウェア、従業員からのフィードバックなどが含まれます。評価プロセスでは、このようなフラグが、初期段階での小さな脆弱性の特定に役立ちます。

これらの評価を実施する際に、情報セキュリティチームは、分析対象のリソースに関する情報収集を継続します。収集対象となる情報には、アプリケーションの詳細、設定方法、コンポーネントの配置場所、業務内でのアプリケーションの使用目的・使用方法などが含まれます。これらのデータは全て、徹底した脆弱性の評価に役立ちます。

2. サーバーのレビュー

評価プロセスにおいて、チームは各サーバーの内部レビュー（構成や設定を含む）も実施します。サーバー設定をポリシーや基準と比較し、特に以下の領域におけるコンプライアンスを確認します。

パスワードとユーザーアカウントに関するポリシー
ユーザーID、管理者アカウント、グループ
Webサーバーの構成
ログプロトコルとアクセス
他のサーバーとの関係性

プロセスとシステムのレビューと同様に、各サーバーに関する詳細情報（問題点や設定を含む）を収集します。これらの情報は全て、脆弱性評価を実施し、サーバーやプロセスに対する更新の必要性を評価するために必要です。

3. 脆弱性の評価

セキュリティチームは、情報収集を終えると、各システムの脆弱性の評価を実施します。脆弱性の評価では、リスク管理の手法を活用し、各システムの現在と将来のリスクを詳細に分析します。

脆弱性評価プロセスでは、セキュリティチームは通常、重要なアセットや潜在的なリスク要因が確認された領域に最も注力します。脆弱性評価において懸念事項を全て特定し、リスク管理上の重要なポイントを明らかにします。

各システムで許容可能なリスクレベルはどの程度か？
各システムは既存の脅威に対処する準備がどの程度整っているか？
システムは新たな脅威に対処する柔軟性をどの程度備えているか？
自然災害発生時におけるデータの保護は確保されているか？
各デバイスとサービスに対してどのような対策が講じられているか？
システム停止による業務への影響はどのようなものか？
現行のセキュリティ構造は、業界、地域、国の規制に準拠しているか？

各脆弱性評価が完了すると、情報セキュリティのライフサイクルの後のフェーズで参照できるよう、結果を文書化します。

フェーズ3：設計

全てのシステムを評価した後に、収集した情報を用いて解決策と対策の設計を行います。評価フェーズで特定された脆弱性や課題に基づき、情報セキュリティチームは、サイバーセキュリティの脅威、セキュリティ製品、情報セキュリティ文化やプロセスを含む具体的な問題解決策についてのブレインストーミングを行います。設計フェーズでチームが考慮する具体的な要素には以下のものが含まれます。

セキュリティの多層化：設計チームは、セキュリティの多層化を設計の必須要素と位置付けます。この設計プロトコルでは、ファイアウォールなどの一般的な防護策から始まり、多要素認証の手順などの詳細なセキュリティ対策へと段階的に強化される多重防御層で各システムを保護します。セキュリティ設計者は、特に重要なシステムにおいて、各システムが複数のセキュリティ層によって保護されていることを確認する必要があります。
コンプライアンス：設計におけるもう1つの考慮事項は、業界、地方、国レベルでの義務的要件への準拠です。設計プロセスで構築されるセキュリティ構造は、該当するあらゆる基準や法令に準拠する必要があります。
事業継続性：事業継続性とは、サービスの中断や災害の発生後もサービスを維持・復旧する企業の能力を意味します。セキュリティチームは、インシデントの発生後にも企業が迅速に通常業務を再開できるよう、統合されたバックアップと冗長性を備えたシステムとプロセスを設計する必要があります。
影響範囲： 設計チームは、変更の可能性が生じるたびに、どのシステムが影響を受けるかを検討する必要があります。影響が限定的な変更もあれば、複数のシステムに影響を及ぼす広範な変更を必要とするものもあります。
有効性・効率性：システム設計を担当するチームは、セキュリティと有効性・効率性の間のトレードオフを考慮する必要があります。最大限のセキュリティは最も安全な選択肢かもしれません。しかし、それを実現するには、投入するリソースと、導入によって生じる非効率性の両面で、極めて高コストとなるおそれがあります。

特定の課題を解決する手段を開発したら、各解決策を詳細に分析し、それぞれ個別の計画と設計図を作成します。設計図には、システム構成の変更、プロセスの変更、ツール、その他の要素に加え、それらがどのように課題を解決するかが含まれます。設計図には、手順の変更、隣接システムへの影響、実装コストなど、変更による影響の分析も提示されます。

チームが設計図を完成させると、その解決策を経営陣／リーダー層に提出し、経営陣／リーダー層は、各課題に対する今後の計画について最終決定を下します。

フェーズ4：実装

解決策の設計が承認された後、情報ライフサイクルの次のフェーズは実装です。このプロセス段階では、チームは解決策の実装計画を作成し、展開を開始します。この実装計画には通常、以下の手順が含まれます。

変更計画の策定：設計フェーズで作成された設計図に基づき、セキュリティチームは段階的な変更計画を作成します。可能な限り、最も重要な領域から優先的に取り組み、その後脆弱性の低い領域へと順に作業を進めます。変更計画には、新たな手順やポリシーを実装するために必要な人員トレーニングも考慮に入れる必要があります。
関係者の役割の定義： 計画策定後、チームは変更実装に関わる各個人の役割と責任を割り当てます。これにはプロジェクトマネージャー、ITリーダー、トレーニングチーム、実装される変更に関連するその他の専門家が含まれます。
リソースの確保： 次に、提案された変更を実装するために必要なツールを調達します。これには、提案された変更の実装と維持に必要なセキュリティプログラム、ネットワークハードウェア、ソフトウェアなどが含まれます。
変更のテスト： 必要なリソースを確保した後、チームは新しいリソースが期待どおりに機能することを確認するためのテストを実施します。予期せぬ問題が発生した場合は、必要に応じて変更計画を調整します。
変更の実装： テストで望ましい結果が確認され、変更計画への修正が最終決定された後、セキュリティチームは計画に従って新たな変更を展開します。また、実装フェーズでは定期的な評価とレビューを実施し、遅延が発生した場合には調整を加えます。

実装フェーズには、チェンジマネジメント（変革管理）や品質保証レビューなど、社内で大きな変更を行う際に必要となる内部プロセスが含まれていなければなりません。

フェーズ5：保護

このフェーズは設計と実装フェーズと密接に関連しています。ただし、対象範囲が若干異なります。保護フェーズ（緩和フェーズとも呼ばれる）は、セキュリティ対策を検証し、システムが確立されたセキュリティポリシーと基準に適合していることを確認するためのフェーズです。

このフェーズでは、情報セキュリティ計画チームが、前のフェーズで追加された新たな変更と組み合わせて、システム全体をレビューします。主な内容を以下に示します。

ポリシーと基準：セキュリティチームは、新規および現行のシステムが、確立されたセキュリティポリシーと基準を満たすか、またはそれを上回っていることを確認します。
セキュリティレベル：個々のシステムが重要性に応じた適切なセキュリティレベルを有していることを確認します。例えば、基幹システムは、重要度の低いシステムよりも高いセキュリティレベルが求められます。
実装検証：チームと関係者は、全ての新規対策が正しく実装されていることを検証します。これには、設計／実装フェーズで設定された目標に対する各変更の評価が含まれます。

システムと変更点が評価された後、保護フェーズでは、設計および実装フェーズを繰り返し、エラーを修正したり、当初の評価フェーズで見落とされた対象領域に対処したりする場合があります。

フェーズ6：監視

情報セキュリティのライフサイクルの最終段階は監視フェーズです。このフェーズでは、情報セキュリティチームが、システムと変更された部分を監視します。現在実装されているセキュリティ対策は、脆弱性に対する防御策となり得ます。しかし、将来にわたってセキュリティが保証されるわけではありません。監視フェーズの目的は大きく分けて2つあります。強化したセキュリティが維持されているのを確認することと、新たな脆弱性の発生を特定することです。

監視フェーズでは、セキュリティチームは、ネットワーク内の新たなシステムと現行のシステムの状態を測定できるよう、必要に応じて監視プロセスを更新・実装する必要があります。監視プロセスの確立における重要な領域を以下に示します。

監視方法：ネットワークシステムの監視と検証が必要なのはいうまでもありません。ここで重要なのは、これらのシステムをどのように監視するかです。ネットワークへの侵入は、イベントログやその他のセキュリティシステムを通じて監視できます。しかし、ネットワークシステムが正しい設定を維持していることを保証するのも同様に重要です。新しいアプリケーションやパッチのインストール時に脆弱性が発生するおそれがあります。そのため、サーバー、ルーター、アプリケーションが企業のセキュリティポリシーや基準に準拠し続けることを保証するには、設定の定期的な検証が必要になります。セキュリティチームは、手動で、またはコンプライアンス監視ツールを利用して、これらの設定を監視します。
監視頻度：もう1つの重要な問題は、システムをどのくらいの頻度で監視すべきかです。各リソースの重要度に基づいて頻度を決定します。全てのシステムの脆弱性を定期的にチェックする必要があります。特に中核システムは、重要度の低いシステムよりも高頻度なチェックが必要です。重要度に基づき、各リソースに適したレベルの監視を行います。
監視測定：監視には、データを定量化可能な形式で認識する測定も含まれる必要があります。定量化が可能なデータにより、企業全体で日々の指標を比較できます。これにより、セキュリティの可視化が容易になり、欠陥の特定も容易になります。質の高い監視プロトコルは、情報セキュリティの担当者がセキュリティシステム全体の可視性を維持し、重大なエラーの発生時に通知を受けるための重要な基盤となります。監視プロトコルの確立に加えて、監視フェーズでは、サイバーセキュリティ環境における新たな動向の把握にも常に注意を払う必要があります。新たな脅威は日々発生し、情報セキュリティのベストプラクティスは絶えず進化しています。質の高い監視とサイバーセキュリティ意識を組み合わせることで、情報セキュリティの担当者は、情報セキュリティのライフサイクルをリスタートする最適なタイミングを判断できます。

Boxによるセキュリティとコンプライアンス

組織内で情報セキュリティのライフサイクルを活用することは、セキュリティを最大化し、システムとチームを最適化する優れた方法です。情報セキュリティプログラムのライフサイクルは、段階的な手順を通じてITシステムの優先順位付けとニーズ分析を支援し、評価と監視プロトコルによる継続的改善を可能にする体制を整えます。情報セキュリティのライフサイクルを整備することで、セキュリティチームは、サイバー攻撃の脅威の増大からビジネスを効率よく効果的に保護できます。セキュリティライフサイクルに適合するツールをお探しなら、Boxがお役に立ちます。

Boxのインテリジェントコンテンツ管理（ICM）は、コンテンツのライフサイクル全体に対応した、使いやすくセキュアなプラットフォームです。ファイルの作成・編集から分類・保存まで、Boxは関連する全ての段階の管理を支援します。いかなる状況でも、コンテンツはビジネスの中核となるものです。Boxのプラットフォームは、組み込みのアクセス制御、AES 256ビット暗号化、完全な可視性を含む、フリクションレスな（摩擦のない）セキュリティとコンプライアンスで重要なファイルを保護します。さらに、高度なセキュリティソリューションであるBox Shieldは、機械学習を活用した防御対策を提供します。

Boxは、10万社以上のお客さま、フォーチュン500企業の67%に信頼され、利用されています。Boxの導入についてのご相談・お問い合わせを承っております。こちらのページから今すぐご連絡ください！

**Boxは、高度なプライバシー、セキュリティ、コンプライアンスを備えた製品とサービスの提供に尽力しています。ただし、この記事で提供される情報は、法的助言の提供を意図したものではありません。適用される法律に対するコンプライアンスを検証する際には、お客さまが自らデューデリジェンスを実施することを推奨します。