先日某T先生が出るという、某PCIDSSに関するセミナに出席。
前も1度さらっとPCIデータセキュリティ基準(PCIDSS) v1.1を読んだが、今改めて読んでいる最中……。
またネット上からも色々と情報収集をしているが、やや気になる事が。
何か特定の要件のみ取り上げて「あーだこーだ」と言っている人が見受けられるが……「とりあえず、まずは全文読め」と言いたい気分……(全文シッカリと読んだ上で語ってるなら、まぁ構いませんが)。
個人的に気になったのは以下の点。
---
●「要件xxを満たすためには○○が必要」というトーン
よくあるのが「要件6.6でWAF導入」というヤツ。正確には……
スペシャリスト(※1)による検査
WAFの導入
……のいずれか一方を満たせば良く、しかも何らかの理由で両方が無理というケースの場合、代替コントロールの提示さえシッカリ示せればOKだったりする訳で。
(尤も認証を受けようとする場合、監査(審査)員にOKと言わせなければいけない訳ですが。＞代替コントロール）
あと折角なのでWAFに関して言っちゃうと、「WAF設置しました、でも特に何も設定していないです」という、ある意味「ノーガード戦法」は通用しないので悪しからず(監査(審査)時は、その辺(設定情報)もシッカリ見るよ～との事)。
---
●とにかく「PCIDSSを満たさないとマズい」というトーン
対象になるのが「PAN(カード番号の事)」を取り扱うシステムなので、PANを全く取り扱わないシステムはそもそも対象外(ただし要件の[一部|全部]を既存のシステムに適用する事は可能……つーかかなり具体化した要件なので、他のセキュリティ規格に比べたら適用しやすいと思われる)。
仮にPANを取り扱うシステムがあったとしても、まずは「自己問診」からスタートするので、(取り扱う件数などの規模にもよるけど)大慌てして対策に走る必要はない。
もしPCIDSS準拠が必要だと思うなら、まずは自己問診から初めて、現状と理想(要求事項)との差を把握する事から。
---
●「Webアプリ『だけ』が対象」というトーン
別にWebアプリ(特にECサイト)が対象という訳じゃなく、PANを取り扱うシステムであればハード・ソフトは問わないというのが正しい(ハードウェア(デバイス)に関しては「PED(PCI PIN Entry Device)」という基準があるので、ソチラが適用される事になる)。
当然バックエンドシステムでPANを取り扱うのであれば、そこも適用対象範囲内になる。
---
●「技術的要件さえ満たせば……」というトーン
確かにISMSなんかと比較すれば技術寄りだけど、だからと言ってマネジメントシステムに関する要件が全く無いかと言われれば、それは「No」(要件12がシッカリ該当する)。
あと同様に物理的対策に関する要件がかなり乏しいけど、これはISMSなどの他の規格側でカバーできるからあまり記述していないとの事。
なので、PCIDSSに触れる時は「まずはISMS、次にPCIDSS」という感じの方がベターかも(無論ISMS認証を絶対に取得する必要性は無いが、あった方が「ちゃんと対策出来てるよ～」とは説明しやすい)。
---
いずれにせよ、この手の基準を読む際には個別の要件ばかりを見るのではなく、大きなレベルから「この要件は何を意図しているのか？」を読み取りながら読んでいかないと間違った解釈をしかねないので、その辺は注意が必要かと。
---
(※1)基準上では「アプリケーションセキュリティに特化した組織(an organization that specializes in application security)」という表現をしている。
前も1度さらっとPCIデータセキュリティ基準(PCIDSS) v1.1を読んだが、今改めて読んでいる最中……。
またネット上からも色々と情報収集をしているが、やや気になる事が。
何か特定の要件のみ取り上げて「あーだこーだ」と言っている人が見受けられるが……「とりあえず、まずは全文読め」と言いたい気分……(全文シッカリと読んだ上で語ってるなら、まぁ構いませんが)。
個人的に気になったのは以下の点。
---
●「要件xxを満たすためには○○が必要」というトーン
よくあるのが「要件6.6でWAF導入」というヤツ。正確には……
……のいずれか一方を満たせば良く、しかも何らかの理由で両方が無理というケースの場合、代替コントロールの提示さえシッカリ示せればOKだったりする訳で。
(尤も認証を受けようとする場合、監査(審査)員にOKと言わせなければいけない訳ですが。＞代替コントロール）
あと折角なのでWAFに関して言っちゃうと、「WAF設置しました、でも特に何も設定していないです」という、ある意味「ノーガード戦法」は通用しないので悪しからず(監査(審査)時は、その辺(設定情報)もシッカリ見るよ～との事)。
---
●とにかく「PCIDSSを満たさないとマズい」というトーン
対象になるのが「PAN(カード番号の事)」を取り扱うシステムなので、PANを全く取り扱わないシステムはそもそも対象外(ただし要件の[一部|全部]を既存のシステムに適用する事は可能……つーかかなり具体化した要件なので、他のセキュリティ規格に比べたら適用しやすいと思われる)。
仮にPANを取り扱うシステムがあったとしても、まずは「自己問診」からスタートするので、(取り扱う件数などの規模にもよるけど)大慌てして対策に走る必要はない。
もしPCIDSS準拠が必要だと思うなら、まずは自己問診から初めて、現状と理想(要求事項)との差を把握する事から。
---
●「Webアプリ『だけ』が対象」というトーン
別にWebアプリ(特にECサイト)が対象という訳じゃなく、PANを取り扱うシステムであればハード・ソフトは問わないというのが正しい(ハードウェア(デバイス)に関しては「PED(PCI PIN Entry Device)」という基準があるので、ソチラが適用される事になる)。
当然バックエンドシステムでPANを取り扱うのであれば、そこも適用対象範囲内になる。
---
●「技術的要件さえ満たせば……」というトーン
確かにISMSなんかと比較すれば技術寄りだけど、だからと言ってマネジメントシステムに関する要件が全く無いかと言われれば、それは「No」(要件12がシッカリ該当する)。
あと同様に物理的対策に関する要件がかなり乏しいけど、これはISMSなどの他の規格側でカバーできるからあまり記述していないとの事。
なので、PCIDSSに触れる時は「まずはISMS、次にPCIDSS」という感じの方がベターかも(無論ISMS認証を絶対に取得する必要性は無いが、あった方が「ちゃんと対策出来てるよ～」とは説明しやすい)。
---
いずれにせよ、この手の基準を読む際には個別の要件ばかりを見るのではなく、大きなレベルから「この要件は何を意図しているのか？」を読み取りながら読んでいかないと間違った解釈をしかねないので、その辺は注意が必要かと。
---
(※1)基準上では「アプリケーションセキュリティに特化した組織(an organization that specializes in application security)」という表現をしている。