アプリケーション・セキュリティ(AppSec)とは
AppSecは、ソフトウェア開発プロセスの一環として、アプリケーション・レベルでセキュリティの脆弱性を検出、修正、防止するプロセスです。 これには、アプリケーションの計画から運用環境での使用まで、開発ライフサイクル全体にわたるアプリケーションメジャーの追加が含まれます。 これまでは、セキュリティはアプリケーションの設計と開発の後に発生していました。 今日、セキュリティは「シフトレフト」しており、セキュリティは開発およびテストプロセスの不可欠なプロセスになりつつあります。 最初からAppSecを追加することで、組織は自社のコードやアプリケーション内で使用されるサード・パーティ・コンポーネントにセキュリティの脆弱性が生じる可能性を大幅に減らすことができます。

アプリケーションセキュリティの脅威:OWASPトップ10
ソフトウェアアプリケーションに影響を与えるセキュリティの脅威は数え切れないほどあります。 ただし、Open Webアプリケーション Security Project (OWASP) Top 10 リストには、最も一般的で深刻で、運用環境のアプリケーションに影響を与える可能性が最も高いアプリケーションの脅威がまとめられています。
AppSecイニシアチブは、少なくとも、最新のアプリケーションに対する次の注目度の高い脅威に焦点を当てる必要があります。
- インジェクション - コードインジェクションには、悪意のあるデータや信頼できないデータを含むソフトウェアアプリケーションに送信されるクエリやコマンドが含まれます。 最も一般的なのはSQLインジェクションですが、NoSQL、オペレーティングシステム、LDAPサーバーにも影響を与える可能性があります。
- 認証の不備:多くのアプリケーションでは、認証および承認機能が不十分または誤動作しています。 これにより、攻撃者はユーザーの資格情報を盗んだり、適切な資格情報なしで簡単にアクセスしたりする可能性があります。
- 機密データの漏洩 - アプリケーションや API は、財務情報や支払い情報、個人を特定できる情報 (PII) など、組織またはその顧客に属する機密データを公然と公開する可能性があります。
- XML 外部エンティティ (XXE) - 攻撃者は、古い XML パーサーの脆弱性により、XML ドキュメント内の外部エンティティ参照を悪用する可能性があります。これらを使用して、内部ファイルへのアクセス、ポートのスキャン、およびリモートでのコードの実行を行うことができます。
- アクセス制御の不備:認証されたユーザに対する制限が正しく実装されていません。 攻撃者がこれを悪用して、許可されていない機能やデータにアクセスしたり、別のユーザーのアカウントにアクセスしたり、機密ファイルを表示したり、他のユーザーの権限を変更したりする可能性があります。
- セキュリティの設定ミス - アプリケーションにセキュリティ機能があっても、設定ミスがある可能性があります。 これは通常、アプリケーションの既定の構成を誰も変更していないために発生します。 これには、オペレーティングシステムとフレームワークへのパッチ適用の失敗が含まれます。
- クロスサイトスクリプティング(XSS)—攻撃者がユーザーのブラウザで悪意のあるスクリプトを実行できるようにします。 これは、セッションを盗んだり、ユーザーを悪意のあるサイトにリダイレクトしたり、Webサイトの改ざんを実行したりするために使用できます。
- 安全でない逆シリアル化 - コードがファイルから取得され、オブジェクトに構築される方法の誤り。 これにより、許可されたユーザーによる悪意のあるコードの実行、特権の昇格、およびアクティビティの再生が可能になります。
- 既知の脆弱性を持つコンポーネントの使用 - 複数の脆弱性データベースがソフトウェアコンポーネントの既知の脆弱性を報告します。 脆弱なコンポーネントを使用するソフトウェアは、そのコンポーネントの 1 つの依存関係であっても、攻撃にさらされます。
- 不十分なロギングと監視:多くのアプリケーションには、侵害の試みを特定または記録する手段がない可能性があります。 これは、侵害が検出されず、攻撃者がラテラルムーブメントを実行して追加のシステムを侵害する可能性があることを意味します。
基本的なAppSecプロセスには、次の段階があります。
- 会社資産の定義
- 各アプリケーションがこれらの資産にどのように影響するかを判断する
- 各アプリケーションのセキュリティプロファイルの作成
- 潜在的な脅威の特定と優先順位付け
- セキュリティインシデントと軽減策の記録
アプリケーション・セキュリティ・テスト・ツール
AppSecツールセットには、SAST、DAST、IASTの3つの主要なツール・カテゴリがあります。
静的アプリケーション・セキュリティ・テスト(SAST)
SASTツールにより、ホワイトボックステストが可能になります。 アプリケーションコードを評価し、スキャンして、セキュリティ上の問題を引き起こす可能性のあるバグ、脆弱性、またはその他の弱点を特定します。 SASTは、コンパイル済みコード、コンパイルされていないコード、またはその両方で実行できます。
SAST分析では、次のような問題を特定できます。
- 競合状態
- パス探索
- 入力検証の欠落
- 数値またはデータ型のエラー
- セキュリティで保護されていない参照またはポインター
動的アプリケーション・セキュリティ・テスト(DAST)
DASTツールは、ブラックボックス・テスト方法を使用して、実行中のアプリケーションのセキュリティー問題をテストします。 ソースコードの実行中に動的分析を実行します。 DASTは一般的にファジー・テストを使用しますが、これは、ランダムで予期しない要求を大量にアプリケーションにぶつけることです。
DAST は、次のようなセキュリティーの脆弱性を示す条件を検出できます。
- セキュリティで保護されていない、または脆弱なインターフェイス
- 異常な要求と応答
- JavaScript や Python などの言語でのスクリプトの問題
- データまたはコードの挿入
- セッションの異常
- 認証の問題
インタラクティブ・アプリケーション・セキュリティ・テスト(IAST)
IASTは、SASTとDASTを組み合わせたハイブリッド・アプローチです。 セキュリティテストのインタラクティブなアプローチでは、静的分析と動的分析を組み合わせることで、既知の脆弱性を特定し、実行中のアプリケーションで実際に使用されており、悪用される可能性があるかどうかを確認することができます。
IASTツールは、アプリケーションの実行フローとデータ・フローに関する詳細な情報を収集し、複雑な攻撃パターンをシミュレートできます。 実行中のアプリケーションの動的スキャンを実行するときに、アプリケーションがどのように応答するかを確認し、それに応じてテストを調整できます。 これは、新しいテストケースを自動的に作成するために使用できます(人間の侵入テスト担当者によく似ています)。
このアプローチにより、IASTツールは疑わしいセキュリティ問題を詳細に調査できるため、誤検知の数を減らすことができます。 また、迅速なリリースによるアジャイル開発プロセスにも、より自然に適合します。
ルールベースのWebアプリケーションファイアウォール(WAF)
WAF は、ネットワークエッジに展開されるソリューションであり、ネットワークに出入りするトラフィックを検査し、悪意のあるトラフィックを特定してブロックしようとします。
従来のルールベースのWAFは、メンテナンスの手間がかかるツールであり、組織は特定のトラフィックとアプリケーションのパターンに一致するルールセットを細心の注意を払って定義する必要があります。 さらに、ルールベースのWAFでは、絶えず変化する攻撃ベクトルのカバレッジが限られています。
さらに、従来のWAFでは、新しいマイクロサービスがデプロイされるたびに、新しいルールやポリシーを定義するための大きなオーバーヘッドが必要になるため、新しいマイクロサービスを自動的に保護することはできません。 実際には、これは、組織によって展開された新しいシステムが保護されないことが多いことを意味します。
アプリケーションセキュリティのベストプラクティス
ここでは、組織にAppSecを効果的に実装するためのベスト・プラクティスをいくつか紹介します。
脅威評価から始める
攻撃者がアプリケーションを侵害するために使用できる主なエントリポイント、実施されているセキュリティ対策、およびそれらが適切かどうかを調査します。 各種類の脅威に対して達成するセキュリティのレベルについて、妥当な目標と時間の経過に伴うマイルストーンを設定します。
セキュリティを左にシフト
セキュリティテストは、計画段階から開発、テスト、本番環境へのデプロイメントまで、ソフトウェア開発ライフサイクル(SDLC)と完全に統合する必要があります。
自動化ツールを使用して、プロセスのできるだけ早い段階で、 CI/CDパイプライン全体の複数のチェックポイントでアプリケーションがテストされるようにします。 たとえば、開発者がコードをコミットしてビルドをトリガーすると、そのコードは自動的に何らかの形式のセキュリティ テストを受け、開発者がコード内のセキュリティの問題をすぐに修正できるようにする必要があります。
同じコードを、テスト環境と運用環境に昇格させたときに、より包括的に再度テストする必要があります。
修復の優先順位付け
アプリケーションセキュリティは、アプリケーションの脆弱性を発見する結果となりますが、すべての脆弱性を修正することはできません。 優先順位付けは、開発者の生産性を損なうことなく、重大な脆弱性を迅速に修正するために非常に重要です。
セキュリティテストプロセスには、脆弱性の深刻度と悪用可能性を示す自動化されたメトリックと、必要に応じて、脆弱性が本当にビジネスリスクをもたらすかどうかを示す手動評価を含める必要があります。 本番環境で実行されていない脆弱なコンポーネントは優先されません。
開発者は、実際の注目度の高い脆弱性に取り組んでいることを認識し、SDLCで発生した脆弱性を修復する時間を確保できます。
AppSecの結果の追跡
AppSecプログラムには、時間とリソースへの多額の投資、および文化や組織の変更が必要です。 プログラムがセキュリティに与える影響を理解して、プログラムを正当化し、管理者によってサポートされていることを確認することが重要です。
AppSecの成功を実証するために追跡および共有できる重要な指標:週次または月次の傾向により、アプリケーション・セキュリティ対策の導入による影響を示すことができます。
- 内部AppSecポリシーの違反件数
- コンプライアンス違反件数
- テスト環境で見つかったセキュリティ上の欠陥の数
- 本番環境で見つかったセキュリティ上の欠陥の数
- セキュリティインシデントの数
権限の管理
アプリケーションセキュリティプログラムに関連するものはすべて、攻撃者にとって非常に有用な機密データです。 以下を慎重に管理してください。
- ポリシーとプロセスの文書化
- セキュリティツールへのアクセス
- CI/CD および開発ツールへのアクセス
最小特権の原則を使用し、各ユーザーが業務に絶対に必要なデータとシステムにのみアクセスできるようにします。 統合システム間で ゼロトラストの原則 を使用し、各システムが機能するために必要な最小限の権限のみを持つようにします。
AppSec with チェック・ポイント
チェック・ポイントのCloudGuardには、次の機能を提供するゼロ構成のアプリケーション・セキュリティ・ソリューションが含まれています。
- 正確な予防 – OWASP top 10 のような高度な攻撃に対して、誤検知を発生させることなく保護します。
- ゼロポリシー管理 – アプリケーションの変更や更新に自動適応
- 柔軟で高速なデプロイメント – 最大48時間で保護
特許出願中のコンテクスチュアルAIエンジンを搭載した CloudGuardアプリケーションセキュリティ は、完全に自動化されており、あらゆる環境に導入できます。