PCI DSS V3.2における変更点解説（１） 要件10.8セキュリティ制御システムの監視と障害への対応

PCI DSS Ver3.2の主な変更点について、今回はVer3.2からの追加となった発展的要件となる要件10.8を取り上げる。

PCI DSSの要件10は「ネットワークリソースおよびカード会員データへのすべてのアクセスの監視・追跡」のための要件群で、主にログの記録やその追跡について定義している。要件10.8および要件10.8.1は、サービスプロバイダのための追加要件であり、2018年1月31日までは「ベストプラクティス」となっている。「ベストプラクティス」要件とは、ある期日までは実施しなくても不適合にはならないが、その期日を過ぎると正式な要件になるものをいう。このような扱いは、すでにPCI DSS準拠済みの企業が準備するのに時間を要するのを配慮してのことである。要は対応に相応な負担がかかるということである。

「セキュリティ制御システム」の異常を検知する

要件10.8は、最初に「重要なセキュリティ制御システム障害のタイムリーな検出・報告プロセスの実装」を求めている。

泥棒が入る時にまず建物の警報システムを落とすのと同様に、システムへの侵入者の多くもセキュリティ制御システムの無効化を試みる。要件10.8のガイダンスに記載の通り、侵入に長時間気づけなければ、カード会員データを盗むのに十分な時間を侵入者に与えてしまう。侵入時のログが残らなければ、事件発生の際のフォレンジック調査すらできない。

リスクを軽減するには、まずはセキュリティ制御システムの障害発生をタイムリーに検出する必要がある。障害の原因は、ハッキングの場合もあれば、単純な機器故障もある。まずは障害が発生したという事象そのものに対して、不正侵入を受けたかもしれないという疑いを持って対処する必要がある。

監視対象とリスクの例

要件10.8では、障害を検出すべき対象の例として以下を挙げている。
 
以下に、対象ごとに想定されるリスクの例を補足する。

ファイアウォールやIDS/IPSは、ネットワークのトラフィックを監視して、許可されていない宛先やポート番号への通信が行われていないかを制御するために導入されている。障害としては、意図しないポリシーの変更や制御の監視機能そのものの停止などが想定されるので、それらをモニタリングする必要がある。なお、セグメンテーションの制御を使用している場合には、PCI DSSの対象範囲外のネットワークから対象範囲内のネットワークへのアクセスがないかどうかを監視するということになる。

不正侵入の検知に効率が良いと言われているファイル整合性監視についても稼働状態の監視が要求されている。ファイル整合性監視はハッシュ値の比較によりファイルの変更を検知しているものが多い。サーバやアプリケーションの脆弱性を攻撃され、悪意のあるソースコードが入ったファイルに置き換えられるのを監視することが可能である。悪意のあるコードの一例として、カード情報の入力画面など見た目は全く同じでもデータ送信先に不正な外部のサーバを指定したりするものもある。このファイル整合性監視を無効化してしまえば、不正に置き換えたページからエンドユーザの認証情報やカード情報などを不正な送信先に送られてしまう。また改ざんしたソースコードからは、正規の通信先を削除しないことが多い。よって、正規のカード処理は継続している状態であり、カード情報の流出に長期間気付けない場合があるため注意が必要だ。

アンチウィルスのソフトウェアが停止されるのも、ハッキングの可能性が高い兆候だ。OSにおけるサービスやプロセスの監視が必要である。

VPNを含むLDAPやActiveDirectoryなどの認証系システムなどへの侵入は、特権アカウントが乗っ取られることが最大のリスクであり、昨今の事件ではそこを足がかりにされることが多いため注意が必要だ。RDP（リモートデスクトッププロトコル）を許可している踏み台サーバも狙われやすい。認証系システムの稼働状況や特権のログイン状態についての監視も重要である。

また、物理アクセス制御についても監視対象に含めることが求められている。データセンタ、オフィスの入退室管理システムや監視カメラ（要件9.1）の録画機能が停止する事態も想定しておく必要がある。

上記のようなリスクを特定した上で監視と報告の手順について文書化することが要求されている。

 

監視サーバもPCI DSSの対象に

それぞれのシステムに対するpingなどを利用した単純な死活監視だけでなく、プロセスやサービスの監視も有効な方法である。有効な監視をするためには一般的に監視サーバを導入する必要がある。
ここでのポイントは、要件10.8の要求により監視サーバも新たにPCI DSSの対象範囲に含めると必要があるということだ。

すでに監視サーバがPCI DSSの対象に入っているところは問題ないが、要件10.8の追加の対応により、新たにPCI DSS対象範囲のシステムを監視する場合は、対象範囲内にPCI DSS準拠システム専用の監視サーバを新たに構築する必要があるかもしれない。

 

「可用性」に大きく踏み込んだ要件10.8

要件10.8は、「全ての重要なセキュリティ制御の障害に対して、タイムリーに対応すること」を求め、障害対応プロセスを以下の通り定義している。情報セキュリティの三要素である「機密性」、「完全性」、「可用性」のうち、これまでPCI DSSが触れてこなかった「可用性」について踏み込んだものとなっている。要件10.8.1では検出したセキュリティ制御の障害に対応するプロセスも要求されている。
 
検出した障害に対して停止した機能を復旧するのみならず、障害発生と解決の日付時刻を記録する必要がある。なぜ停止したのか、根本原因をつきとめ、再発防止策を立案し記録するなど文書化も含め求められている。特に根本原因の識別は再発防止とリスク評価のために重要である。HDDの空き領域がなくなったためウィルススキャンが停止したのであれば、まずはHDDに空き領域を作り復旧する必要がある。その上で、なぜHDDが一杯になったのか？をつきとめる。単に定期的な監視をしていなかったのでログがいっぱいになったという原因であれば、その根本原因を取り除くことが再発防止策になる。急激にログがいっぱいになった原因が不正アクセスによるものであれば、その不正アクセスについてさらに調査する必要がある。

 

さらなる活動が必要かを判断するためのリスク評価

最後に定義されている「障害中に発生した全てのセキュリティ問題の識別及び対応」は、セキュリティ制御システムの障害発生中に他のサーバで発生したイベントのうち、セキュリティインシデントとみなして対応すべきものがないかを確認し、リスク評価することを要求している。言い換えると、「監視システムが落ちている間に他のシステムがやられていないか？」という観点で確認し、発生したのがセキュリティ機能を持つ機器の単なる障害なのか、不正侵入なのかを識別する必要がある。

セキュリティインシデントの懸念があれば、PCI DSS要件12.10（インシデント対応）で要求されている計画を発動させるトリガーになる可能性がある。その場合、カード会社など、外部への報告や対応が必要となるため、発生したイベントのリスク評価を慎重に行う必要がある。

 

ISMSの「是正対応処置」やITILの「問題管理プロセス」

ガイダンスでは、障害対応プロセスや手順の適切さを証明するために、活動や対応を文書化された証跡として収集するべきであることが説明されている。よって、実際にPCI DSSのオンサイトレビュー（QSAによる外部監査）では、システムの稼働時間などのログを含めて記録を確認することが想定される。文書化された証跡の例として問題管理システムへの記録が挙げられている通り、ISMSの要求事項である「是正対応措置」やITILの「問題管理」のプロセスなどをすでに導入している場合はそれらを活用すれば効率的に対応が可能である。

次の記事：PCI DSS V3.2における変更点解説（２） 要件8.3　管理者アクセスに対する多要素認証の要求

PCI DSS Ready Cloudでは、PCI DSS v4.0への効率的な移行支援及び準拠を促進するクラウドサービスを提供しています。
是非一度、ご相談ください。
PCI DSS準拠を促進するクラウドサービスならPCI DSS Ready Cloud

■ PCI DSS の構築、維持・運用にかかるコストと工数を削減する
 
■ AWSでの開発事業者や外部ベンダー/事業者との専用線接続がない場合に最適
 
■ 国内トップクラスのPCI DSS専門のコンサルタント集団によるPCI DSS準拠支援サービス