SlideShare ist ein Scribd-Unternehmen logo
1 von 15
Downloaden Sie, um offline zu lesen
PCI DSSで定期的に
やるべき10のこと	
 
       Yuki Kawashima
             2012/1/20
注意事項	
 
›  本資料および筆者は、読者に対して何の保証もし
    ません
›  抜粋、引用などはしていただいて構いませんが、
    すべて自己責任で行う必要があります
›  本資料は、あくまで著者の執筆時点での個人的な
    見解であり、所属もしくは関連する企業や組織、
    個人の見解を示すものではありません
›  本資料内の企業名、システム名、製品名は各社の
    登録商標もしくは商標です
本資料について	
 
›  本資料は、PCI DSSで求められる要求事項のうち、年
    間を通して「定期的に」行うことが求められているも
    のを抜粋し、概要を説明したものです。
›  要求事項として頻度が明記されているものと明記され
    ていないものがあります。推奨値を記載していますが
    まったくの主観なので、あくまで参考情報ととらえて
    下さい
›  1項目に複数の要求事項を含めたものもあります。
›  「要件」を抜粋したものと、「テスト手順」(いわゆ
    る「サブ要件」)を抜粋したものがあります。
›  詳細は必ずPCI DSS要件をご確認下さい。
本資
                        料の
                           読  み方
                                    	
 
タイトル	
 
›  要件もしくはテスト   ›  定期的に実施するこ
 手順の抜粋	
         と、そのポイント
                 ›  頻度:年1回

                ›  定期的に実施するこ
                 と、そのポイント
                 ›  頻度:四半期に1回
1. ファイアウォールやルータのルールセッ
トを最低6ヶ月毎にレビューする	
 
›    要件1.1.6 ファイアウォールおよび   ›    ファイアウォール/ルータの
      ルーターのルールセットは少なくと            ルールセットのレビューを行う
      も6ヶ月ごとにレビューされる必要
      がある	
                 ›    ルールが変更されていない場合
                                  も実施して記録を残すこと
                                  ›    頻度:最低6ヶ月毎
2. パターンファイルやシグネチャ、エンジ
ン、およびパッチを定期的に更新する	
 
›    要件5.2. すべてのアンチウィルスメ   ›    アンチウィルスソフトウェアのパ
      カニズムが最新で、有効に実行され
      ており、監査ログが生成される              ターンファイル/エンジンを定期
›    要件6.1 すべてのシステムコンポー          的に更新する
      ネントとソフトウェアに、ベンダ提            ›    頻度:未定義。1日1回推奨
      供の最新セキュリティパッチが適用
      され、既知の脆弱性から保護されて      ›    公開された重要なパッチは基本
      いる。重要なセキュリティパッチは、           1ヶ月以内に適用する。重要でな
      リリース後1ヶ月以内にインストー            い場合は3ヶ月以内で良い。ただ
      ルする。
›    要件11.4 侵入検知システムや侵入防         し重要性を適切に判断している会
      止システムを使用して、カード会員            議やその記録が重要。他の定例会
      データ環境との境界およびカード会            議等の一部で検討しても良い
      員データ環境内の重要なポイントを
      通過するすべてのトラフィックを監            ›    頻度:パッチ公開毎、1〜3ヶ月
      視し、侵害の疑いがある場合は担当      ›    IDS/IPS等のシグネチャやエンジン
      者に警告する。すべての侵入検知お            を定期的に更新する。
      よび防止エンジン、ベースライン、
      シグネチャを最新状態に保つ               ›    頻度:未定義。1日1回推奨
3. 使われていない/不要なアカウントの削
除、およびパスワード変更を90日毎に行う	
 
›    要件8.5.5 少なくとも90日ごとに非   ›    ユーザアカウントの棚卸を最低
      アクティブのユーザアカウントを削             90日毎に行い、使っていないア
      除/無効化する                      カウントの削除/無効化や、パ
›    要件8.5.9 少なくとも90日ごとに          スワードを変更していないユー
      ユーザパスワードを変更する	
 
                                   ザの強制パスワード変更フラグ
                                   設定等を行う。運用上問題なけ
                                   れば自動化して良いが、記録を
                                   残すとより良い
                                   ›    頻度:最低90日毎
4. 媒体の在庫ログを確認するため、少なく
とも年1度、媒体の在庫調査を行う	
 
›    要件9.9.1 すべての媒体の在庫ログ   ›    テープなどの媒体の棚卸し(在庫調
      を適切に保持し、少なくとも年に一            査)を最低年に1回行う
      度媒体の在庫調査を実施する	
       ›    これを行わないと、紛失した、もし
                                  くは盗難にあった時などに検知でき
                                  ないため
                            ›    CD/DVD等も使用しているのであれ
                                  ば対象と考えて良い
                                  ›  頻度: 最低年1回
5. すべてのシステム、アプリケーションな
どのログを少なくとも一日に一度確認する	
 
›    要件10.6 少なくとも日に一度、すべ   ›    「すべての」ログを最低一日に一度
      てのシステムコンポーネントのログ            確認する。ただし本当にすべてのロ
      を確認する。ログの確認には、侵入            グを人間の目で確認することは不可
      検知システム(IDS)や認証、認可、          能なので、ある程度のフィルタリン
      アカウンティングプロトコル               グを行い、危険と判断されたものを
      (AAA)サーバ(RADIUSなど)の         毎日通知し、確認するようなフロー
      ようなセキュリティ機能を実行する            で良い。
      サーバを含める必要がある。         ›    確認した記録をとること
      注:要件10.6に準拠するために、ロ    ›    しきい値をどのように設定している
      グの収集、解析、および警告ツール            かが文書化されていると良い
      を使用できる。                     ›    頻度: 最低1日1回
6. 無線機器およびシステム、アプリケー
ションに対するテストを定期的に行う	
 
›    要件6.6 一般公開されているWebアプリケー   ›    Webアプリケーションに対するツールもしく
      ションは、常時、新しい脅威と脆弱性に対処            は手動での脆弱性評価を最低年に1回行う
                                      ›    頻度: 最低年1回
      し、以下のいずれかの手法によって既知の攻
                                ›    不正な無線アクセスポイントを検知するため
      撃から保護する必要がある。1)アプリケー            の無線スキャンを実施、もしくは無線IDS/IPS
      ションのセキュリティ脆弱性を手動/自動で評           を導入して監視する
      価するツールまたは手法によって、少なくと            ›    頻度:スキャンは最低四半期に一回
      も年1回および何らかの変更を加えた後にレ      ›    システム内の全てのIPアドレスに対して脆弱
      ビューする 2)手前にWebアプリケーション          性スキャンを最低四半期に一回行う。外部は
      ファイアウォールをインストールする               ASVが実施する必要あり。内部はASVでなく
                                      ても構わない
›    要件11.1 四半期ごとにワイヤレスアクセスポ         ›    頻度:最低四半期に一回
      イントの存在をテストし、承認されていない      ›    外部、内部含めすべてのIPアドレスに対して
      ワイヤレスアクセスポイントを検出する              ペネトレーションテストを最低年1回行う。
›    要件11.2 内部および外部の脆弱性スキャンを         ›    頻度:最低年1回
      少なくとも四半期に一度およびネットワーク
      での大幅な変更後に実行する             ›    脆弱性スキャン、ペネトレーションテストの
                                      対象が多すぎる場合は段階的に実施。結果の
›    要件11.3 外部および内部のペネトレーション         サンプリングや横展開を含む代替コントロー
      テストを少なくとも年に一度および大幅なイ            ルを検討しても良いが基本は全IPアドレス	
 
      ンフラストラクチャまたはアプリケーション
      のアップグレードや変更後に実行する
7. 重要なファイルの整合性を最低週一回
チェックする	
 
›    要件11.5 ファイル整合性監視ツール   ›    ファイル整合性監視ツールによる整合性
      を導入して重要なシステムファイル、           チェックを最低週に1回実施する
      構成ファイル、またはコンテンツ       ›    「重要なシステムファイル、構成ファイル、
                                  コンテンツファイル」とは、「通常変更さ
      ファイルの不正な変更を担当者に警
                                  れないが、変更されるとシステムが侵害さ
      告し、重要なファイルの比較を少な            れているもしくは侵害されている可能性が
      くとも週に一度実行するようにソフ            発生する」ファイルとされている。各種設
      トウェアを構成する。	
                定ファイル、ライブラリ、システムファイ
                                  ルなどが考えられる
                            ›    製品にはよく各OS向けのテンプレートが
                                  あるので活用すると良い
                                  ›    頻度: 最低週に1度
8. 情報セキュリティポリシーを最低年に1
回更新し、従業員を教育、同意書をとる	
 
›    要件12.1.2 脅威、脆弱性、結果を識   ›    最新のセキュリティ動向やシステム、
      別する年に一度のプロセスを正式な             組織にそった情報セキュリティポリ
      リスク評価に含める                    シーを保ため、ポリシーはリスク評
›    要件12.1.3 (セキュリティポリシー         価結果に基づき最低年1回更新する
      の)少なくとも年に一度含め、環境             ›    頻度: 最低年1回
      の変化に合わせて更新する           ›    セキュリティポリシーの更新にあわ
›    要件12.6.1 雇用時および少なくとも         せて、従業員への教育も行う
      年に一度担当者を教育する	
         ›    情報の取り扱いやポリシーの内容を
                                   承諾した旨の同意書をとる
                             ›    教育の実施および同意書について記
                                   録を残すこと
                                   ›    頻度: 最低年1回
9. 委託先のPCI DSS準拠ステータスを少な
くとも年に一度確認する	
 
›    要件12.8.4 少なくとも年1回サービ   ›    カード情報を取り扱う業務、システ
      スプロバイダのPCI DSS準拠ステー          ムを外部に委託しているような場合、
      タスを監視するプログラムを維持す             委託先のPCI DSSS準拠ステータスを
      る	
                          最低年1回確認する
                             ›    論理的には、委託先が準拠していな
                                   いとまういが、現実的には必ず準拠
                                   しているとも限らない
                             ›    委託する業務の内容や取り扱う情報
                                   の種類に合わせる
                             ›    カード情報取り扱い、およびPCI
                                   DSSへの準拠に関する責任分解点を
                                   明確にすること
                                   ›    頻度: 最低年1回
10. インシデント対応計画を少なくとも年
に一度テストする	
 
›    要件12.9.2 (インシデントレスポン   ›    インシデントレスポンス計画を最低
      ス)計画を少なくとも年に一度テス             年1回テストすること
      トする                    ›    テスト結果を記録し、問題があれば
›    要件12.9.4 観察とポリシーのレ           計画に反映する
      ビューを通じて、セキュリティ違反             ›    頻度:最低年1回
      への対応を担当するスタッフが定期       ›    インシデントレスポンス時の担当者
      的にトレーニングされていることを             に定期的にトレーニングを行う
      確認する	
 
                             ›    四半期に1回くらい行うと良いかも
                                   しれないが、定義やトレーニング結
                                   果を文書化すると良い
                                   ›    頻度:未定義。四半期に1度程度を推奨
定期的にやるべき10のこと まとめ	
 
No.	
            やること	
                                頻度	
 

         ファイアウォール、ルータのルール
 1	
                              •  すべてのファイアウォール、ルータについて最低6ヶ月に1回	
 
         セットレビュー	
 
         アンチウィルス、IDS/IPSのシグネ      •  アンチウィルス、IDS/IPSのシグネチャ、エンジンの更新は1日に1回(推奨)
 2	
 
         チャ、エンジン更新	
              •  パッチの適用はパッチ公開から1〜3ヶ月以内	
 
         不要アカウント削除、パスワード変
 3	
                              •  不要アカウントの削除、パスワード変更を最低四半期に1回	
 
         更	
 

 4	
     媒体の棚卸し	
                 •  媒体の棚卸しを最低年1回	
 

 5	
     すべてのログの確認	
              •  すべてのログについて最低1日1回	
 

                                  •    Webアプリケーションの脆弱性評価を最低年1回
         無線AP検知、脆弱性スキャン、ペ         •    不正な無線AP検知のための無線スキャンを最低四半期に一回
 6	
 
         ネトレーションテスト	
             •    脆弱性スキャンを最低四半期に1回
                                  •    ペネトレーションテストを最低年に1回	
 

 7	
     重要なファイルの整合性チェック	
        •  ファイル整合性のチェックを最低週1回	
 

         情報セキュリティポリシー更新と教         •  情報セキュリティポリシーの更新を最低年1回
 8	
 
         育	
                      •  あわせて教育の実施と同意書を最低年1回	
 

 9	
     委託先のPCI DSS準拠状況チェック	
    •  委託先のPCI DSS準拠ステータスチェックを最低年1回	
 

         インシデント対応計画のテストと担         •  インシデントレスポンス計画のテストを最低年1回
10	
 
         当者トレーニング	
               •  担当者のトレーニングを四半期に1回(推奨)

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Présentation de la Plateforme Nuxeo
Présentation de la Plateforme NuxeoPrésentation de la Plateforme Nuxeo
Présentation de la Plateforme Nuxeo
 
AlmaLinux と Rocky Linux の誕生経緯&比較
AlmaLinux と Rocky Linux の誕生経緯&比較AlmaLinux と Rocky Linux の誕生経緯&比較
AlmaLinux と Rocky Linux の誕生経緯&比較
 
不揮発メモリ(NVDIMM)とLinuxの対応動向について
不揮発メモリ(NVDIMM)とLinuxの対応動向について不揮発メモリ(NVDIMM)とLinuxの対応動向について
不揮発メモリ(NVDIMM)とLinuxの対応動向について
 
優れた問いを見つける(中京大学講演)
優れた問いを見つける(中京大学講演)優れた問いを見つける(中京大学講演)
優れた問いを見つける(中京大学講演)
 
アドテクにおける機械学習技術 @Tokyo Data Night #tokyodn
アドテクにおける機械学習技術 @Tokyo Data Night #tokyodnアドテクにおける機械学習技術 @Tokyo Data Night #tokyodn
アドテクにおける機械学習技術 @Tokyo Data Night #tokyodn
 
IIJmio meeting 9 IIJのモバイル&バックボーンインフラ
IIJmio meeting 9 IIJのモバイル&バックボーンインフラIIJmio meeting 9 IIJのモバイル&バックボーンインフラ
IIJmio meeting 9 IIJのモバイル&バックボーンインフラ
 
機械学習・ディープラーニング、ITの実装スキル学ぶ方法(と私の場合)
機械学習・ディープラーニング、ITの実装スキル学ぶ方法(と私の場合)機械学習・ディープラーニング、ITの実装スキル学ぶ方法(と私の場合)
機械学習・ディープラーニング、ITの実装スキル学ぶ方法(と私の場合)
 
NLP2023 緊急パネル:ChatGPTで自然言語処理は終わるのか? 説明スライド
NLP2023 緊急パネル:ChatGPTで自然言語処理は終わるのか? 説明スライドNLP2023 緊急パネル:ChatGPTで自然言語処理は終わるのか? 説明スライド
NLP2023 緊急パネル:ChatGPTで自然言語処理は終わるのか? 説明スライド
 
Markkinointi- ja asiakasstrategiat
Markkinointi-  ja asiakasstrategiatMarkkinointi-  ja asiakasstrategiat
Markkinointi- ja asiakasstrategiat
 
東北大学講義資料 実世界における自然言語処理 - すべての人にロボットを - 坪井祐太 
東北大学講義資料 実世界における自然言語処理 - すべての人にロボットを - 坪井祐太 東北大学講義資料 実世界における自然言語処理 - すべての人にロボットを - 坪井祐太 
東北大学講義資料 実世界における自然言語処理 - すべての人にロボットを - 坪井祐太 
 
【DL輪読会】BloombergGPT: A Large Language Model for Finance arxiv
【DL輪読会】BloombergGPT: A Large Language Model for Finance arxiv【DL輪読会】BloombergGPT: A Large Language Model for Finance arxiv
【DL輪読会】BloombergGPT: A Large Language Model for Finance arxiv
 
IIJmio meeting #2 IIJmioとIPv6の話
IIJmio meeting #2 IIJmioとIPv6の話IIJmio meeting #2 IIJmioとIPv6の話
IIJmio meeting #2 IIJmioとIPv6の話
 
Pci express
Pci expressPci express
Pci express
 
Rosのリアルタイムツールの紹介
Rosのリアルタイムツールの紹介Rosのリアルタイムツールの紹介
Rosのリアルタイムツールの紹介
 
Surveyから始まる研究者への道 - Stand on the shoulders of giants -
Surveyから始まる研究者への道 - Stand on the shoulders of giants -Surveyから始まる研究者への道 - Stand on the shoulders of giants -
Surveyから始まる研究者への道 - Stand on the shoulders of giants -
 
2016.5.11碩士論文口試
2016.5.11碩士論文口試2016.5.11碩士論文口試
2016.5.11碩士論文口試
 
分散深層学習 @ NIPS'17
分散深層学習 @ NIPS'17分散深層学習 @ NIPS'17
分散深層学習 @ NIPS'17
 
Object Detection & Instance Segmentationの論文紹介 | OHS勉強会#3
Object Detection & Instance Segmentationの論文紹介 | OHS勉強会#3Object Detection & Instance Segmentationの論文紹介 | OHS勉強会#3
Object Detection & Instance Segmentationの論文紹介 | OHS勉強会#3
 
学振特別研究員になるために~知っておくべき10のTips~[平成28年度申請版]
学振特別研究員になるために~知っておくべき10のTips~[平成28年度申請版]学振特別研究員になるために~知っておくべき10のTips~[平成28年度申請版]
学振特別研究員になるために~知っておくべき10のTips~[平成28年度申請版]
 
IIJmio meeting 17 DSDSと着信シーケンスについて
IIJmio meeting 17 DSDSと着信シーケンスについてIIJmio meeting 17 DSDSと着信シーケンスについて
IIJmio meeting 17 DSDSと着信シーケンスについて
 

Andere mochten auch

20110929 クラウド連携において企業内ID管理基盤に求められるもの
20110929 クラウド連携において企業内ID管理基盤に求められるもの20110929 クラウド連携において企業内ID管理基盤に求められるもの
20110929 クラウド連携において企業内ID管理基盤に求められるもの
Naohiro Fujie
 

Andere mochten auch (11)

PCI DSSでよくある質問と回答トップ10
PCI DSSでよくある質問と回答トップ10PCI DSSでよくある質問と回答トップ10
PCI DSSでよくある質問と回答トップ10
 
PCI DSSについて知っておくべき10のこと
PCI DSSについて知っておくべき10のことPCI DSSについて知っておくべき10のこと
PCI DSSについて知っておくべき10のこと
 
クラウドでPCI DSS環境を構築・運用するポイント
クラウドでPCI DSS環境を構築・運用するポイントクラウドでPCI DSS環境を構築・運用するポイント
クラウドでPCI DSS環境を構築・運用するポイント
 
GCが止まらない
GCが止まらないGCが止まらない
GCが止まらない
 
PCIコンプライアンスに向けたビジネス指針〜MasterCardの事例〜 #cwt2015
PCIコンプライアンスに向けたビジネス指針〜MasterCardの事例〜 #cwt2015PCIコンプライアンスに向けたビジネス指針〜MasterCardの事例〜 #cwt2015
PCIコンプライアンスに向けたビジネス指針〜MasterCardの事例〜 #cwt2015
 
Overview pcidss
Overview pcidssOverview pcidss
Overview pcidss
 
なぜ自社で脆弱性診断を行うべきなのか
なぜ自社で脆弱性診断を行うべきなのかなぜ自社で脆弱性診断を行うべきなのか
なぜ自社で脆弱性診断を行うべきなのか
 
スタートアップのCEOもおさえておきたい、ITインフラのセキュリティ対策 先生:
スタートアップのCEOもおさえておきたい、ITインフラのセキュリティ対策 先生:スタートアップのCEOもおさえておきたい、ITインフラのセキュリティ対策 先生:
スタートアップのCEOもおさえておきたい、ITインフラのセキュリティ対策 先生:
 
20110929 クラウド連携において企業内ID管理基盤に求められるもの
20110929 クラウド連携において企業内ID管理基盤に求められるもの20110929 クラウド連携において企業内ID管理基盤に求められるもの
20110929 クラウド連携において企業内ID管理基盤に求められるもの
 
0528 kanntigai ui_ux
0528 kanntigai ui_ux0528 kanntigai ui_ux
0528 kanntigai ui_ux
 
女子の心をつかむUIデザインポイント - MERY編 -
女子の心をつかむUIデザインポイント - MERY編 -女子の心をつかむUIデザインポイント - MERY編 -
女子の心をつかむUIデザインポイント - MERY編 -
 

Ähnlich wie PCI DSSで定期的にやるべき10のこと

COD2012 九州会場 NAP による簡易検疫のススメ
COD2012 九州会場 NAP による簡易検疫のススメCOD2012 九州会場 NAP による簡易検疫のススメ
COD2012 九州会場 NAP による簡易検疫のススメ
wintechq
 
ドラフト版 COD2012 九州会場 NAPによる簡易検疫のススメ
ドラフト版 COD2012 九州会場 NAPによる簡易検疫のススメドラフト版 COD2012 九州会場 NAPによる簡易検疫のススメ
ドラフト版 COD2012 九州会場 NAPによる簡易検疫のススメ
wintechq
 
継続的デリバリー読書会 第 5 章 デプロイメントパイプラインの解剖学
継続的デリバリー読書会 第 5 章 デプロイメントパイプラインの解剖学継続的デリバリー読書会 第 5 章 デプロイメントパイプラインの解剖学
継続的デリバリー読書会 第 5 章 デプロイメントパイプラインの解剖学
Takuma SHIRAISHI
 
Continuous delivery chapter4
Continuous delivery chapter4Continuous delivery chapter4
Continuous delivery chapter4
favril1
 
20100617 seminar
20100617 seminar20100617 seminar
20100617 seminar
NANAROQ
 

Ähnlich wie PCI DSSで定期的にやるべき10のこと (20)

Process team 20190524
Process team 20190524Process team 20190524
Process team 20190524
 
最新情報でわかる Windows 10 の導入と展開 (2017/9/19 開催分)
最新情報でわかる Windows 10 の導入と展開 (2017/9/19 開催分)最新情報でわかる Windows 10 の導入と展開 (2017/9/19 開催分)
最新情報でわかる Windows 10 の導入と展開 (2017/9/19 開催分)
 
講演資料: コスト最適なプライベートCDNを「NGINX」で実現するWeb最適化セミナー
講演資料: コスト最適なプライベートCDNを「NGINX」で実現するWeb最適化セミナー講演資料: コスト最適なプライベートCDNを「NGINX」で実現するWeb最適化セミナー
講演資料: コスト最適なプライベートCDNを「NGINX」で実現するWeb最適化セミナー
 
ワンクリックデプロイ101 #ocdeploy
ワンクリックデプロイ101 #ocdeployワンクリックデプロイ101 #ocdeploy
ワンクリックデプロイ101 #ocdeploy
 
COD2012 九州会場 NAP による簡易検疫のススメ
COD2012 九州会場 NAP による簡易検疫のススメCOD2012 九州会場 NAP による簡易検疫のススメ
COD2012 九州会場 NAP による簡易検疫のススメ
 
ドラフト版 COD2012 九州会場 NAPによる簡易検疫のススメ
ドラフト版 COD2012 九州会場 NAPによる簡易検疫のススメドラフト版 COD2012 九州会場 NAPによる簡易検疫のススメ
ドラフト版 COD2012 九州会場 NAPによる簡易検疫のススメ
 
[data analytics showcase] A15: デジタルデータの可視化基盤「ENdoSnipe」を使った、システムトラブルの未然防止、経営判...
[data analytics showcase] A15: デジタルデータの可視化基盤「ENdoSnipe」を使った、システムトラブルの未然防止、経営判...[data analytics showcase] A15: デジタルデータの可視化基盤「ENdoSnipe」を使った、システムトラブルの未然防止、経営判...
[data analytics showcase] A15: デジタルデータの可視化基盤「ENdoSnipe」を使った、システムトラブルの未然防止、経営判...
 
継続的デリバリー読書会 第 5 章 デプロイメントパイプラインの解剖学
継続的デリバリー読書会 第 5 章 デプロイメントパイプラインの解剖学継続的デリバリー読書会 第 5 章 デプロイメントパイプラインの解剖学
継続的デリバリー読書会 第 5 章 デプロイメントパイプラインの解剖学
 
Zabbix-jp study #4 20111020 session2
Zabbix-jp study #4 20111020 session2Zabbix-jp study #4 20111020 session2
Zabbix-jp study #4 20111020 session2
 
Azure monitoring and alert v0.2.21.0707
Azure monitoring and alert v0.2.21.0707Azure monitoring and alert v0.2.21.0707
Azure monitoring and alert v0.2.21.0707
 
2019 1117 security_jaws_toal_5min_slideshare
2019 1117 security_jaws_toal_5min_slideshare2019 1117 security_jaws_toal_5min_slideshare
2019 1117 security_jaws_toal_5min_slideshare
 
継続的デリバリー読書会資料 #1
継続的デリバリー読書会資料 #1継続的デリバリー読書会資料 #1
継続的デリバリー読書会資料 #1
 
HCL AppScan 10 のご紹介
HCL AppScan 10 のご紹介HCL AppScan 10 のご紹介
HCL AppScan 10 のご紹介
 
GTMF 2015: バグを減らそう。テストを楽にしよう。静的解析が開発者を救う。 | 日本シノプシス合同会社
GTMF 2015: バグを減らそう。テストを楽にしよう。静的解析が開発者を救う。 | 日本シノプシス合同会社GTMF 2015: バグを減らそう。テストを楽にしよう。静的解析が開発者を救う。 | 日本シノプシス合同会社
GTMF 2015: バグを減らそう。テストを楽にしよう。静的解析が開発者を救う。 | 日本シノプシス合同会社
 
Continuous delivery chapter4
Continuous delivery chapter4Continuous delivery chapter4
Continuous delivery chapter4
 
測定と予測を通じたソフトウェア品質評価と改善の実践的取り組み 公開用
測定と予測を通じたソフトウェア品質評価と改善の実践的取り組み 公開用測定と予測を通じたソフトウェア品質評価と改善の実践的取り組み 公開用
測定と予測を通じたソフトウェア品質評価と改善の実践的取り組み 公開用
 
プロダクトアップデートセミナー資料(2020年10月29日開催)
プロダクトアップデートセミナー資料(2020年10月29日開催)プロダクトアップデートセミナー資料(2020年10月29日開催)
プロダクトアップデートセミナー資料(2020年10月29日開催)
 
デブサミ関西2013【A4】コード品質は曖昧なままか(安竹由起夫氏)
デブサミ関西2013【A4】コード品質は曖昧なままか(安竹由起夫氏)デブサミ関西2013【A4】コード品質は曖昧なままか(安竹由起夫氏)
デブサミ関西2013【A4】コード品質は曖昧なままか(安竹由起夫氏)
 
20100617 seminar
20100617 seminar20100617 seminar
20100617 seminar
 
Azure monitoring and alert v0.1.21.0422
Azure monitoring and alert v0.1.21.0422Azure monitoring and alert v0.1.21.0422
Azure monitoring and alert v0.1.21.0422
 

PCI DSSで定期的にやるべき10のこと

  • 2. 注意事項 ›  本資料および筆者は、読者に対して何の保証もし ません ›  抜粋、引用などはしていただいて構いませんが、 すべて自己責任で行う必要があります ›  本資料は、あくまで著者の執筆時点での個人的な 見解であり、所属もしくは関連する企業や組織、 個人の見解を示すものではありません ›  本資料内の企業名、システム名、製品名は各社の 登録商標もしくは商標です
  • 3. 本資料について ›  本資料は、PCI DSSで求められる要求事項のうち、年 間を通して「定期的に」行うことが求められているも のを抜粋し、概要を説明したものです。 ›  要求事項として頻度が明記されているものと明記され ていないものがあります。推奨値を記載していますが まったくの主観なので、あくまで参考情報ととらえて 下さい ›  1項目に複数の要求事項を含めたものもあります。 ›  「要件」を抜粋したものと、「テスト手順」(いわゆ る「サブ要件」)を抜粋したものがあります。 ›  詳細は必ずPCI DSS要件をご確認下さい。
  • 4. 本資 料の 読 み方 タイトル ›  要件もしくはテスト ›  定期的に実施するこ 手順の抜粋 と、そのポイント ›  頻度:年1回 ›  定期的に実施するこ と、そのポイント ›  頻度:四半期に1回
  • 5. 1. ファイアウォールやルータのルールセッ トを最低6ヶ月毎にレビューする ›  要件1.1.6 ファイアウォールおよび ›  ファイアウォール/ルータの ルーターのルールセットは少なくと ルールセットのレビューを行う も6ヶ月ごとにレビューされる必要 がある ›  ルールが変更されていない場合 も実施して記録を残すこと ›  頻度:最低6ヶ月毎
  • 6. 2. パターンファイルやシグネチャ、エンジ ン、およびパッチを定期的に更新する ›  要件5.2. すべてのアンチウィルスメ ›  アンチウィルスソフトウェアのパ カニズムが最新で、有効に実行され ており、監査ログが生成される ターンファイル/エンジンを定期 ›  要件6.1 すべてのシステムコンポー 的に更新する ネントとソフトウェアに、ベンダ提 ›  頻度:未定義。1日1回推奨 供の最新セキュリティパッチが適用 され、既知の脆弱性から保護されて ›  公開された重要なパッチは基本 いる。重要なセキュリティパッチは、 1ヶ月以内に適用する。重要でな リリース後1ヶ月以内にインストー い場合は3ヶ月以内で良い。ただ ルする。 ›  要件11.4 侵入検知システムや侵入防 し重要性を適切に判断している会 止システムを使用して、カード会員 議やその記録が重要。他の定例会 データ環境との境界およびカード会 議等の一部で検討しても良い 員データ環境内の重要なポイントを 通過するすべてのトラフィックを監 ›  頻度:パッチ公開毎、1〜3ヶ月 視し、侵害の疑いがある場合は担当 ›  IDS/IPS等のシグネチャやエンジン 者に警告する。すべての侵入検知お を定期的に更新する。 よび防止エンジン、ベースライン、 シグネチャを最新状態に保つ ›  頻度:未定義。1日1回推奨
  • 7. 3. 使われていない/不要なアカウントの削 除、およびパスワード変更を90日毎に行う ›  要件8.5.5 少なくとも90日ごとに非 ›  ユーザアカウントの棚卸を最低 アクティブのユーザアカウントを削 90日毎に行い、使っていないア 除/無効化する カウントの削除/無効化や、パ ›  要件8.5.9 少なくとも90日ごとに スワードを変更していないユー ユーザパスワードを変更する ザの強制パスワード変更フラグ 設定等を行う。運用上問題なけ れば自動化して良いが、記録を 残すとより良い ›  頻度:最低90日毎
  • 8. 4. 媒体の在庫ログを確認するため、少なく とも年1度、媒体の在庫調査を行う ›  要件9.9.1 すべての媒体の在庫ログ ›  テープなどの媒体の棚卸し(在庫調 を適切に保持し、少なくとも年に一 査)を最低年に1回行う 度媒体の在庫調査を実施する ›  これを行わないと、紛失した、もし くは盗難にあった時などに検知でき ないため ›  CD/DVD等も使用しているのであれ ば対象と考えて良い ›  頻度: 最低年1回
  • 9. 5. すべてのシステム、アプリケーションな どのログを少なくとも一日に一度確認する ›  要件10.6 少なくとも日に一度、すべ ›  「すべての」ログを最低一日に一度 てのシステムコンポーネントのログ 確認する。ただし本当にすべてのロ を確認する。ログの確認には、侵入 グを人間の目で確認することは不可 検知システム(IDS)や認証、認可、 能なので、ある程度のフィルタリン アカウンティングプロトコル グを行い、危険と判断されたものを (AAA)サーバ(RADIUSなど)の 毎日通知し、確認するようなフロー ようなセキュリティ機能を実行する で良い。 サーバを含める必要がある。 ›  確認した記録をとること 注:要件10.6に準拠するために、ロ ›  しきい値をどのように設定している グの収集、解析、および警告ツール かが文書化されていると良い を使用できる。 ›  頻度: 最低1日1回
  • 10. 6. 無線機器およびシステム、アプリケー ションに対するテストを定期的に行う ›  要件6.6 一般公開されているWebアプリケー ›  Webアプリケーションに対するツールもしく ションは、常時、新しい脅威と脆弱性に対処 は手動での脆弱性評価を最低年に1回行う ›  頻度: 最低年1回 し、以下のいずれかの手法によって既知の攻 ›  不正な無線アクセスポイントを検知するため 撃から保護する必要がある。1)アプリケー の無線スキャンを実施、もしくは無線IDS/IPS ションのセキュリティ脆弱性を手動/自動で評 を導入して監視する 価するツールまたは手法によって、少なくと ›  頻度:スキャンは最低四半期に一回 も年1回および何らかの変更を加えた後にレ ›  システム内の全てのIPアドレスに対して脆弱 ビューする 2)手前にWebアプリケーション 性スキャンを最低四半期に一回行う。外部は ファイアウォールをインストールする ASVが実施する必要あり。内部はASVでなく ても構わない ›  要件11.1 四半期ごとにワイヤレスアクセスポ ›  頻度:最低四半期に一回 イントの存在をテストし、承認されていない ›  外部、内部含めすべてのIPアドレスに対して ワイヤレスアクセスポイントを検出する ペネトレーションテストを最低年1回行う。 ›  要件11.2 内部および外部の脆弱性スキャンを ›  頻度:最低年1回 少なくとも四半期に一度およびネットワーク での大幅な変更後に実行する ›  脆弱性スキャン、ペネトレーションテストの 対象が多すぎる場合は段階的に実施。結果の ›  要件11.3 外部および内部のペネトレーション サンプリングや横展開を含む代替コントロー テストを少なくとも年に一度および大幅なイ ルを検討しても良いが基本は全IPアドレス ンフラストラクチャまたはアプリケーション のアップグレードや変更後に実行する
  • 11. 7. 重要なファイルの整合性を最低週一回 チェックする ›  要件11.5 ファイル整合性監視ツール ›  ファイル整合性監視ツールによる整合性 を導入して重要なシステムファイル、 チェックを最低週に1回実施する 構成ファイル、またはコンテンツ ›  「重要なシステムファイル、構成ファイル、 コンテンツファイル」とは、「通常変更さ ファイルの不正な変更を担当者に警 れないが、変更されるとシステムが侵害さ 告し、重要なファイルの比較を少な れているもしくは侵害されている可能性が くとも週に一度実行するようにソフ 発生する」ファイルとされている。各種設 トウェアを構成する。 定ファイル、ライブラリ、システムファイ ルなどが考えられる ›  製品にはよく各OS向けのテンプレートが あるので活用すると良い ›  頻度: 最低週に1度
  • 12. 8. 情報セキュリティポリシーを最低年に1 回更新し、従業員を教育、同意書をとる ›  要件12.1.2 脅威、脆弱性、結果を識 ›  最新のセキュリティ動向やシステム、 別する年に一度のプロセスを正式な 組織にそった情報セキュリティポリ リスク評価に含める シーを保ため、ポリシーはリスク評 ›  要件12.1.3 (セキュリティポリシー 価結果に基づき最低年1回更新する の)少なくとも年に一度含め、環境 ›  頻度: 最低年1回 の変化に合わせて更新する ›  セキュリティポリシーの更新にあわ ›  要件12.6.1 雇用時および少なくとも せて、従業員への教育も行う 年に一度担当者を教育する ›  情報の取り扱いやポリシーの内容を 承諾した旨の同意書をとる ›  教育の実施および同意書について記 録を残すこと ›  頻度: 最低年1回
  • 13. 9. 委託先のPCI DSS準拠ステータスを少な くとも年に一度確認する ›  要件12.8.4 少なくとも年1回サービ ›  カード情報を取り扱う業務、システ スプロバイダのPCI DSS準拠ステー ムを外部に委託しているような場合、 タスを監視するプログラムを維持す 委託先のPCI DSSS準拠ステータスを る 最低年1回確認する ›  論理的には、委託先が準拠していな いとまういが、現実的には必ず準拠 しているとも限らない ›  委託する業務の内容や取り扱う情報 の種類に合わせる ›  カード情報取り扱い、およびPCI DSSへの準拠に関する責任分解点を 明確にすること ›  頻度: 最低年1回
  • 14. 10. インシデント対応計画を少なくとも年 に一度テストする ›  要件12.9.2 (インシデントレスポン ›  インシデントレスポンス計画を最低 ス)計画を少なくとも年に一度テス 年1回テストすること トする ›  テスト結果を記録し、問題があれば ›  要件12.9.4 観察とポリシーのレ 計画に反映する ビューを通じて、セキュリティ違反 ›  頻度:最低年1回 への対応を担当するスタッフが定期 ›  インシデントレスポンス時の担当者 的にトレーニングされていることを に定期的にトレーニングを行う 確認する ›  四半期に1回くらい行うと良いかも しれないが、定義やトレーニング結 果を文書化すると良い ›  頻度:未定義。四半期に1度程度を推奨
  • 15. 定期的にやるべき10のこと まとめ No. やること 頻度 ファイアウォール、ルータのルール 1 •  すべてのファイアウォール、ルータについて最低6ヶ月に1回 セットレビュー アンチウィルス、IDS/IPSのシグネ •  アンチウィルス、IDS/IPSのシグネチャ、エンジンの更新は1日に1回(推奨) 2 チャ、エンジン更新 •  パッチの適用はパッチ公開から1〜3ヶ月以内 不要アカウント削除、パスワード変 3 •  不要アカウントの削除、パスワード変更を最低四半期に1回 更 4 媒体の棚卸し •  媒体の棚卸しを最低年1回 5 すべてのログの確認 •  すべてのログについて最低1日1回 •  Webアプリケーションの脆弱性評価を最低年1回 無線AP検知、脆弱性スキャン、ペ •  不正な無線AP検知のための無線スキャンを最低四半期に一回 6 ネトレーションテスト •  脆弱性スキャンを最低四半期に1回 •  ペネトレーションテストを最低年に1回 7 重要なファイルの整合性チェック •  ファイル整合性のチェックを最低週1回 情報セキュリティポリシー更新と教 •  情報セキュリティポリシーの更新を最低年1回 8 育 •  あわせて教育の実施と同意書を最低年1回 9 委託先のPCI DSS準拠状況チェック •  委託先のPCI DSS準拠ステータスチェックを最低年1回 インシデント対応計画のテストと担 •  インシデントレスポンス計画のテストを最低年1回 10 当者トレーニング •  担当者のトレーニングを四半期に1回(推奨)