Threat Stackは現在、F5 Distributed Cloud App Infrastructure Protection(AIP)となっています。チームでDistributed Cloud AIPの利用を今すぐ開始しましょう。
PCI DSSの現行バージョンは、2018年5月に公開された3.2.1です。要件6では、「安全なシステムおよびアプリケーションを開発し、保守する」ことが求められています。もちろん、何の問題もありません。実に明快で簡単な話です――安全なシステムやアプリケーションを開発・保守した経験がない人にとっては!それ以外の人にとっては、非常に難しい要求です。
しかし、この文書では続いて、比較的わかりやすい要件がいくつも挙げられています。その多くは、セキュアなソフトウェア開発ライフサイクルですでに取り入れられているものです。たとえば、セキュリティ脆弱性を特定するプロセスの確立、既知の脆弱性への対処、コーディングのベストプラクティスの採用、開発環境とテスト環境およびそれらのアカウントの本番環境からの安全な分離、コードレビューの実施、変更管理プロセスの整備、セキュアコーディング手法に関する開発者教育などです。どれも至極妥当な内容です。
その最上位要件をさらに掘り下げた要件6.5では、アプリケーションを保護すべき具体的な脆弱性が複数挙げられています。これらは、OWASP TOP 10、SANS CWE Top 25、CERT Secure Codingなどから代表的なものを集めたような内容で、SQLインジェクション、脆弱な暗号化、XSS、バッファオーバーフローなど、想定どおりの脆弱性です。これも妥当な要件です。攻撃者は、こうした種類の脆弱性を攻撃の足掛かりとして常に狙っています。
そして、要件6.6には重要な規定があります。「一般公開されているWebアプリケーションについて、新たな脅威や脆弱性に継続的に対処し、既知の攻撃から保護されるようにすること」。どの攻撃を指すのでしょうか。その答えは、「少なくとも、要件6.5に記載されたすべての脆弱性」です。少し考えてみてください。文書の64ページに埋もれているこの要件6.6だけで、ソフトウェアの構築方法と運用方法に大きな影響が及びます。この要件を満たすために、どのような方法が提示されているのでしょうか。答えは2つあります。
- 「手動または自動の脆弱性セキュリティ評価ツールまたは手法のいずれか」を使用して、アプリを年1回および変更のたびにレビューする
- 「Webベースの攻撃を検知して防止する自動化された技術ソリューション」を使用する
したがって、これはWebアプリケーションのビルド時と実行時の両方に影響し、実際にはまったく異なる2つのアクティビティが関係します。
1. アプリケーションをレビューして脆弱性の有無を事前に確認し、確実に修正する
― そして ―
2. 攻撃をリアルタイムで検知してブロックする
これは決して悪い要件ではありません。ガイダンスにも、「一般公開されているWebアプリケーションは攻撃者の主な標的であり、適切にコーディングされていないWebアプリケーションは、攻撃者が機密データやシステムにアクセスするための容易な経路となる」と記載されています。まったくそのとおりです。課題は、この要件を実際に実装する際に生じます。
最初の部分であるアプリのレビューをどのように実施するかについては、あまり具体的な指針が示されていません。アプリは「手動または自動の脆弱性セキュリティ評価ツールもしくは手法を使用して」レビューする必要があるとされています。かなり広範な規定です。
2つ目の部分では、もう少し具体的な推奨事項が示されています。すべてのトラフィックを継続的にチェックするため、一般公開されているWebアプリケーションの前段に「Webベースの攻撃を検知して防止する自動化された技術的ソリューション(Webアプリケーションファイアウォールなど)」を導入することが推奨されています。これはWAFベンダーにとって追い風となりました。要件6.6への準拠を目指すチームにとって、WAFは突如、チェック項目を満たすための製品となったからです。しかし、WAFは要件の最初の部分には役立ちません。WAFはセキュリティ評価ツールではなく、アプリケーションが何をどのように行うかを把握していません。理解できるのはアプリケーションに送信される内容だけであり、アプリケーションがその情報をどのように処理するか(あるいは処理しないか)までは把握できません。
こうした事情から、多くのチームが要件6.6のすべてに対応することに苦慮しています。この短い要件には、重要でありながら大きく異なる2つのニーズが含まれています。多くのチームは、2つ目のニーズをWAFで満たし、1つ目のニーズには複数の手法(手動によるコードレビュー、自動ソースコード解析など)を組み合わせて対応しようとします。
しかし、単一のソリューションで要件6.6を満たせる別の方法があります。PCI基準では、WAFに言及する際に「たとえば」という表現が使われています。これは重要な点です(以前のバージョンの基準には含まれていませんでした)。つまり、「Webベースの攻撃をブロックするか、直ちに調査されるアラートを生成するように設定」されていれば、他のテクノロジーでもアプリケーションを保護できることが認められています。Application Security Monitoringは、Threat StackがCloud Security Platform®に追加料金なしで追加した統合アプリケーションセキュリティソリューションであり、要件6.6のビルド時とランタイムの両方に対応します。この2つの大きな課題を、1つのソリューションで解決します。
ビルド時には、他のサードパーティ製コードライブラリと同じように、Threat Stack microagentをアプリケーションに追加します。開発者にとっては、APMソリューションを使用してアプリケーションを計測する作業とよく似ています。microagentを追加すると、ローカルでの手動テスト、夜間ビルドでの自動テスト、ユーザー受け入れテストなど、アプリケーションが実行されるたびに評価が行われます。PCIでは、アプリケーションを「少なくとも年1回、および変更後」にレビューすることを規定しています。Threat Stackはこの要件を大きく上回り、開発者に追加作業を求めることなく、セキュリティ脆弱性を継続的に特定します。テストを作成したり、サーバーを管理したりする必要はありません。
脆弱性が特定された場合、要件6.6では、その脆弱性への対処も求めています。「すべての脆弱性が修正され、修正後にアプリケーションが再評価されること」を確実にする必要があります。Threat Stack AppSec Monitoringは、検出されたリスクについて、リスクの説明、修正方法を示すサンプルコード、検出箇所の正確なモジュール名、メソッド名、ファイルの場所、行番号など、開発者が対処に活用できるガイダンスを提供します。開発者が脆弱性を修正した後は、「再評価」のために特別な作業を行う必要はありません。次回のアプリケーション実行時に自動的に評価されます。
実行時には、既知の攻撃からアプリケーションを保護するために「すべてのトラフィックを継続的にチェックする」ことが求められます。同じThreat Stackマイクロエージェントがこの処理も行います。アプリケーションが開発環境から本番環境へデプロイされる際、マイクロエージェントも一緒にデプロイされます(依存関係としてアプリケーションに組み込まれています)。その後、アプリケーションに送信されるすべてのWebペイロードを分析し、攻撃の兆候を監視します。ペイロードが悪意のあるものと判定された場合、リクエストを直ちに停止できます。攻撃については、Threat Stackポータル、Slack、またはその他のChatOpsチャネルを通じてチームに通知されます。これにより、「Webベースの攻撃をブロックするか、直ちに調査されるアラートを生成する」というPCI要件に的確に対応できます。
PCI 6.6への対応は大きな課題です。「新たな脅威や脆弱性に継続的に対処し、既知の攻撃からアプリケーションを確実に保護する」という要件は、ソフトウェア開発ライフサイクルの2つの異なるフェーズ(開発環境と本番環境)にまたがり、2つの異なるタスク(プロアクティブな脆弱性評価とリアルタイムの攻撃検知・防御)を伴います。どちらも複雑で、通常は異なるチームが担当します。しかし、これらに対応するために別々のツールを用意する必要はありません。Threat StackのApplication Security Monitoringなら、開発者の作業を妨げることなく、1つのソリューションで両方の要件に対応できます。今すぐお試しください。
詳細をご覧になりたい場合や、Application Security Monitoringをお試しになりたい場合は、Threat Stack Cloud Security Platformのデモにお申し込みください。コンプライアンスとセキュリティの専門家が、お客さま固有の要件についてご相談を承ります。
参考資料
『Requirements and Security Assessment Procedures』バージョン3.2.1(2018年5月)のPCI DSS要件6.6
6.6 公開されているWebアプリケーションについては、新たな脅威および脆弱性に継続的に対処し、次のいずれかの方法により、既知の攻撃からこれらのアプリケーションを保護します。
- 手動または自動のアプリケーション脆弱性セキュリティ評価ツールもしくは手法を使用して、公開Webアプリケーションを少なくとも年1回、および変更のたびにレビューする
- すべてのトラフィックを継続的に検査するため、公開Webアプリケーションの前段に、Webベースの攻撃を検知して防止する自動化された技術ソリューション(Webアプリケーションファイアウォールなど)を導入する。
Threat Stackは現在、F5 Distributed Cloud App Infrastructure Protection(AIP)となりました。チームでDistributed Cloud AIPの利用を今すぐ開始してください。
著者について
関連するブログ記事

F5 Application Study Tool:OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版:リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。