ソフトウェア環境

導入:ソフトウェア環境(SE)

ソフトウェア環境実践法では、OSやプラットフォームのパッチ適用(クラウドを含む)、Webアプリケーション・ファイアウォール、インストールおよび構成のドキュメンテーション、コンテナ化、オーケストレーション、アプリケーションの監視、変更管理、およびコード・サイニングを行います。

ソフトウェア環境レベル1

[SE1.1: 58] アプリケーション入力監視を使用している。

組織は、攻撃を検知するために、実行するソフトウェアへの入力を監視します。Webコードの場合は、Webアプリケーション・ファイアウォール(WAF)を使用できます。他の種類のソフトウェアでは他の方法を使用する必要がある場合が多くなります。SSGは、システムの維持と入力監視を担当できますが、インシデント対応はこのアクティビティには含まれません。ログを定期的に監視する従業員がいる場合は、ログ・ファイルに書き込む無力化されたWAFを使用できます。監視されていないWAFはアプリケーションになにかあっても役に立ちません。

[SE1.2: 104] ホストおよびネットワーク・セキュリティの基本事項が実施されていることを確認する。

組織は、ホストおよびネットワーク・セキュリティの基本事項が実施されていることを確認することによって、ソフトウェア・セキュリティの確固とした基盤を提供します。オペレーティング・システムへのパッチ適用、ファイアウォールの保守、クラウド・サービスの適切な構成などの職務は、通常、運用セキュリティ・チームが担当しますが、ネットワーク・セキュリティを実施する前にソフトウェア・セキュリティを設定するのは、馬を買わずに鞍を買うようなものです。  

ソフトウェア環境レベル2

[SE2.2: 39] インストール・ガイドを発行する。

SSDLは、ソフトウェア・セキュリティをインストールおよび構成する導入チームやオペレーターのために、インストール・ガイドまたは、コンテナなどが明確に記述された構成を作成する必要があります。デプロイメントのセキュリティを保証するために特別な手順が必要な場合は、手順をインストール・ガイドで説明するか、自動化された導入中に明示的に表示する必要があります。このガイドではCOTSコンポーネントについても説明する必要があります。場合によっては、ソフトウェアを購入した顧客にインストール・ガイドを配布します。自動化された展開が、機械だけでなく、人間によってもよく理解できるようになっていることを確認してください。開発・運用および統合されたチームの構造が進化していたとしても、人間が読んで理解できるガイダンスは必要です。無論、セキュリティがデフォルトで組み込まれているのが最適です。

[SE2.4: 31] コード・サイニングを使用している。

組織は、信頼済みの複数の境界にわたって、ソフトウェアを公開するために、コード・サイニングを使用します。コード・サイニングは、市販化されるアプリケーションやシック・クライアントなどの、組織の統制を離れるソフトウェアの整合性を保護する上で特に有用です。一部モバイル・プラットフォームでアプリケーション・コードに署名する必要があったとしても、コード・サイニングを組織的に使用しているとはみなされません。

ソフトウェア環境レベル3

[SE3.2: 17] コード保護を使用している。

組織は、知的財産を保護し、開発の悪用を困難にするために、リバース・エンジニアリングの防止対策を実施します。これは、広範囲に配布されるモバイル・アプリケーションの場合に特に重要です。難読化技術を、運用環境のビルトおよびリリース・プロセスの一貫として適用できます。Data Execution Prevention (DEP)、Safe Structured Error Handling (SafeSEH)、Address Space Layout Randomization (ASLR)などのプラットフォーム固有の統制を適用すると、開発の悪用がより困難になります。

[SE3.3: 4] アプリケーションの動作監視および診断を使用する。

組織は、運用環境のソフトウェアの動作を監視し、誤動作や攻撃の兆候を検出します。このアクティビティは、悪意のある動作の兆候などのソフトウェア固有の問題を検出するためのホストおよびネットワーク・モニタリング以上のものです。アプリケーション・レベルでの侵入の検知や異常検出システムは、アプリケーションとオペレーティング・システムの間の交信(システム呼び出しによる)、またはアプリケーションが消費、操作、またはアプリケーションから送信する種類のデータに注目します。

[SE3.4: 11] アプリケーション・コンテナを使用している。

組織は、アプリケーション・コンテナを使用して、ソフトウェア・セキュリティの目標を支援します。コンテナを使用する主な理由は、導入が簡単なこと、アプリケーションとその依存関係をより緊密に結合できること、仮想マシン上にOSを完全にデプロイするオーバーヘッドなしに隔離できることです。コンテナを使用することで、セキュリティ統制を簡単に適用でき、整合性のある方法で更新できます。開発環境またはテスト環境でセキュリティを考慮することなくコンテナを使用していても、このアクティビティには含まれません。

[SE3.5: 0] コンテナおよび仮想化環境のオーケストレーション。

組織は、自動化を用いてコンテナや仮想マシンの導入を統制のとれた形でスケール変更します。オーケストレーションのプロセスでは、組み込みおよびアドオンのセキュリティ・コントロールを利用することで、導入された各コンテナおよび仮想マシンが規定のセキュリティ要件を確実に満たすようにします。セキュリティ動作を全体的に設定することにより、必要が生じたときに迅速な変更が可能になります。オーケストレーション・プラットフォーム自体もソフトウェアであるため、セキュリティのパッチ適用と構成が必要です。Kubernetesを使用する場合は、必ずKubernetesのパッチを適用してください。

[SE3.6: 0] 運用部品表を用いてアプリケーションのインベントリを向上させる。

健全な企業経営にとって、運用環境におけるアプリケーションとその保存場所の一覧は不可欠な情報です([CMVM2.3 アプリケーションの運用環境インベントリを作成する]を参照)。また、運用環境のすべてのソフトウェアのコンポーネント、依存関係、コンフィグレーション、外部サービスなどの詳細情報を記載したマニフェストがあれば、組織のすべてのセキュリティ保護が可能になります。攻撃者や攻撃の進化に応じて機敏に対応するために、コンプライアンス要件は変更され、パッチの適用対象となる項目数も膨大に増えていきます。プライベート・データセンターにあるか、クラウド上にあるか、市販製品であるかを問わず、実行中のソフトウェアのすべてのコンポーネントを把握していれば、不幸な事態に見舞われた場合に速やかに対応できます。

[SE3.7: 0] クラウド・セキュリティの基本事項を確認する。

[SE1.2 ホストおよびネットワーク・セキュリティの基本事項が実施されていることを確認する]は既に実践されていることと思いますが、クラウドの導入についてもその基本事項が満たされていることを確認する必要があります。ソフトウェア・デファインドがますます進展する中、ケーブルと物理ハードウェアを使用して構築する場合と同等以上のセキュリティ機能・コントロールを明示的に実装する必要があります。一見、処理は自動的に行われているようでも実はそうではありません。