CIS Control 16：アプリケーションソフトウェアのセキュリティ

最新のIT環境には、通常、幅広い種類のアプリケーションが含まれます。社内で開発されたソフトウェア、ホスト型ソフトウェアプラットフォーム、オープンソースのツール、市販のソリューションなどです。これらのアプリケーションは機密性の高いシステム、データ、その他のIT資産にアクセスするため、サイバー犯罪者は攻撃の際にそれらを悪用しようとします。

CIS Control 16 では、組織のセキュリティ態勢を強化するためのアプリケーションソフトウェアのセキュリティ管理策を提供しています。このブログ記事では、これらの CIS controls を実装することで、コーディングミス、認証の弱さ、安全でない設計、安全でないインフラ、ならびに攻撃者が機密性の高いデータやシステムにアクセスするために利用するその他の脆弱性によるリスクをどのように低減できるかを説明します。

「 CIS Critical Security Controls Version 8」の前までは、アプリケーションをどのように保護するかというテーマは CIS Control 18 で扱われていました。

16.1. 安全なアプリケーション開発プロセスを確立し、維持する

最初のステップは、安全なコーディング手法、安全なアプリケーション設計の標準と手順、さらにサードパーティ製コードのセキュリティを対象とした、安全なアプリケーション開発プロセスを確立することです。あわせて、開発チームや実装グループを含め、アプリケーションのライフサイクルに関わるすべての人に対して、このプロセスに関するトレーニングを必ず提供してください。目的は、誰もが自社のセキュリティ実践を理解し、リスクへの露出を最小化するために積極的に取り組むという、サイバーセキュリティ意識の文化をつくることです。

このアプローチにより、業界の規制、法的な要件、社内のガバナンス要件への準拠（コンプライアンス）も向上します。

16.2. ソフトウェアの脆弱性を受け入れて対応するためのプロセスを確立し、維持する

ソフトウェアの脆弱性を受け入れて対応するためには、堅牢な脆弱性管理プロセスも必要です。定期的にリスク評価を実施してネットワークセキュリティにおけるギャップを明らかにし、チームメンバーが、インシデント対応の最中に発見される場合を含め、セキュリティ上の問題を見つけた際にいつでも簡単に報告できるようにプロセスを作成してください。

脆弱性レポートの取り扱いと、修復（是正）プロセスの監視を担当する役割を必ず割り当て、脆弱性を追跡するシステムへの投資も検討してください。

16.3. セキュリティ脆弱性に対して根本原因分析を実施する

セキュリティ脆弱性を緩和するには、根本原因分析によって根本的な問題を理解することが不可欠です。特定の脆弱性への対処を支援するだけでなく、根本原因分析は、セキュリティとコンプライアンスの状況を強化する安全な構成基線（secure configuration baselines）を定義するのにも役立ちます。

16.4. 第三者ソフトウェアコンポーネントのインベントリを確立し、管理する

開発中にチームが使用しているものや、将来的に使用予定のものを含めて、第三者ソフトウェアコンポーネントのインベントリを作成します。これらのソフトウェアコンポーネントがアプリに与えるリスクを検討し、文書化してください。さらに、変更や更新があればそれらを特定して記録し、インベントリを適切に管理するようにしましょう。

16.5. 最新かつ信頼できる第三者ソフトウェアコンポーネントを使用する

可能な限り、実績のある検証済みのソフトウェアやライブラリを使用します。これらのコンポーネントについて信頼できる入手元を特定し、使用前にソフトウェアに脆弱性がないか評価してください。

すべての第三者ソフトウェアコンポーネントが継続的な開発者サポートを提供していることを確認してください。サポートがないものは無効化するか削除します。セキュリティ更新を継続的に受け取っているソフトウェア資産を利用することで、リスクへのエクスポージャーを最小限に抑えることができます。これらの更新には、必ず信頼できるかつ検証済みの情報源のみを使用してください。もちろん、システムやデバイスの整合性を維持するために、更新を適時にインストールする必要があります。

16.6. アプリケーションの脆弱性に対する深刻度（Severity）評価の仕組みとプロセスを確立し、維持する

アプリケーションの脆弱性の深刻度を評価すると、リスクの修復（対応）の優先順位を付けやすくなります。プロのヒント：評価システムを設計する際は、アプリケーションと脆弱性が自社のビジネスプロセスにとってどれほど重要かを含めてください。さらに、アプリケーションに対する最低限のセキュリティ許容レベルを定めることも検討してください。

16.7. アプリケーションのインフラには標準的なハードニング設定テンプレートを使用する

業界で推奨されているテンプレートを使って、サーバー、データベース、SaaS および PaaS の各コンポーネントを設定すると、脆弱性を軽減し、サイバー衛生（cyber hygiene）を改善するための安全な構成を確保できます。

16.8. 本番環境（production）と非本番環境（non-production）を分離する

本番システムと、開発およびテストに使用する非本番システムのために、別々の環境を作成し、維持してください。本番環境へのアクセスを未承認の担当者が行えないように、本番環境とのすべてのやり取りを監視します。

活動の監視に加えて、効果的なアカウント管理によってIT環境を保護してください。ユーザー アカウントには必要な権限だけを付与し、管理者権限は最小限に抑えます。追加のデータ保護対策は、Active Directory 環境において Group Policy を使用して実装できます。

16.9. 開発者に対して、アプリケーション セキュリティの概念と安全なコーディングを教育する

開発者には、安全なコードを書くためのトレーニングが必要です。トレーニングは、チームの特定の環境や責任に合わせて設計されている場合に、最も効果的になります。トレーニングには、アプリケーション セキュリティの標準的な実践と一般的なセキュリティ原則を含め、セキュリティ意識の向上を目指すべきです。SANS Institute は、情報セキュリティやサイバーセキュリティについて学ぶための優れたリソースです。

安全なコードを書くことに投資することで、脆弱性の検出や修復に必要な工数を減らせるため、コストを節約できます。

16.10. アプリケーションのアーキテクチャに安全な設計原則を適用する

安全な設計原則には、「ユーザー入力を決して信頼しない」というガイドラインが含まれており、すべてのユーザー操作を検証し、明示的なエラーチェックを行うことを意味します。

安全な設計には、アプリケーション基盤の攻撃対象領域（attack surface）を最小化することも含まれます。たとえば、チームは不要なプログラムを削除し、デフォルトアカウントの名前を変更するか削除し、保護されていないサービスやポートを無効化できます。

16.11. アプリケーションのセキュリティ構成要素には、審査済みのモジュールまたはサービスを活用する

アプリケーションのセキュリティ構成要素向けの審査済みモジュールやサービスは、Identity management、暗号化、監査、ログ記録に利用できます。これらを使うことで、実装や設計上の誤りを減らし、開発者の作業負荷を最小限に抑えることができます。

たとえば、最新のオペレーティング システムを使用すると、アプリケーションの効果的な識別、認証、および認可を確実にするとともに、安全な監査ログの作成にも役立ちます。広くレビューされている標準の暗号化アルゴリズムのみを使用することで、システムを危険にさらし得る欠陥のリスクを低減できます。

16.12. コード レベルのセキュリティ チェックを実装する

静的および動的解析ツールを活用して、誤りをテストすることで、開発者が安全なコーディングの実践に従っていることを確認できるようにします。利用可能なツールを調査し、自分のコードに対して効果的に機能するものを見つけてください。

16.13. アプリケーションのペネトレーション テストを実施する

ペネトレーション テストは、コードレビューや自動化されたコード スキャンでは見落とされ得るアプリケーション内の脆弱性を明らかにするのに役立ちます。CIS CSC 16 における本コンポーネントでのテストの目的は、インターネット セキュリティ上のギャップを含む弱点を特定し、アプリケーション環境におけるサイバーセキュリティの回復力と防御メカニズムを評価することです。

侵入テストの有効性は、テスターのスキルに依存することを念頭に置いてください。

16.14. 脅威モデリングを実施する

脅威モデリングでは、コーディングを開始する前に、特別に訓練された開発者が、各アクセスレベルまたは入口（エントリーポイント）ごとのセキュリティリスクに焦点を当ててアプリケーションの設計を評価します。アプリケーション、アーキテクチャ、インフラストラクチャを構造化してマッピングすることで、弱点をより深く理解できるため、サイバー防御を強化し、データを不正アクセス、窃取、または破壊から守ることができます。