Microsoft Word - SAQ_D_v20_12_2_10_form_ZH-TW.doc

Transcription

1 支付卡行業 (PCI) 資料安全標準自我評估問卷 D 和合規證明 其他所有符合 SAQ 資格的商戶和服務提供商 2.0 版 2010 年 10 月

2 文件變更記錄 日期版本描述 2008 年 10 月 1 日 1.2 版 根據新的 PCI DSS v1.2 調整相關內容, 並實施自原始 v1.1 以來所註明的次要變更 2010 年 10 月 28 日 2.0 版根據新的 PCI DSS v2.0 要求與測試程序調整相關內容 PCI DSS SAQ D,v2.0, 文件變更記錄版權所有 2010 PCI Security Standards Council LLC 2010 年 10 月第 i 頁

3 目錄 文件變更記錄... i PCI 資料安全標準 : 相關文件... iii 開始之前... iv 完成自我評估問卷...iv PCI DSS 合規 完成步驟...iv 關於某些特定要求不適用性的指南...v 合規證明,SAQ D 商戶版... 1 合規證明,SAQ D 服務提供商版... 1 自我評估問卷 D... 1 建立並維護安全網路...1 要求 1: 安裝並維護防火牆設定, 以保護資料...1 要求 2: 對於系統密碼及其他安全參數, 請勿使用供應商提供的預設值...4 保護持卡人資料 6 要求 3: 保護儲存的持卡人資料...6 要求 4: 加密透過開放的公用網路傳輸的持卡人資料...10 維護漏洞管理程式...11 要求 5: 使用並定期更新防毒軟體或程式...11 要求 6: 開發並維護安全系統和應用程式...11 實施嚴格的存取控制措施...15 要求 7: 限制為只有業務需要知道的人才能存取持卡人資料...15 要求 8: 為具有電腦存取權的每個人指定唯一的 ID...16 要求 9: 限制對持卡人資料的實際存取...19 定期監控並測試網路...22 要求 10: 追蹤並監控對網路資源及持卡人資料的所有存取...22 要求 11: 定期測試安全系統和程序...23 維護資訊安全政策...27 要求 12: 維護確保適用於所有員工的資訊安全政策...27 附錄 A: 對共用託管提供商的其他 PCI DSS 要求 要求 A.1: 共用託管提供商必須保護持卡人資料環境...31 附錄 B: 補償性控制 附錄 C: 補償性控制工作表 補償性控制工作表 完成的範例...35 附錄 D: 不適用性解釋 PCI DSS SAQ D,v2.0, 目錄版權所有 2010 PCI Security Standards Council LLC 2010 年 10 月第 ii 頁

4 PCI 資料安全標準 : 相關文件 以下文件旨在協助商戶和服務提供商理解 PCI 資料安全標準 (PCI DSS) 和 PCI DSS SAQ 文件 PCI 資料安全標準 : 要求和安全評估程序 導覽 PCI DSS: 理解資料安全要求的目的 PCI 資料安全標準 : 自我評估問卷說明和指南 PCI 資料安全標準 : 自我評估問卷 A 和證明 PCI 資料安全標準 : 自我評估問卷 B 和證明 PCI 資料安全標準 : 自我評估問卷 C-VT 和證明 PCI 資料安全標準 : 自我評估問卷 C 和證明 PCI 資料安全標準 : 自我評估問卷 D 和證明 PCI 資料安全標準與支付應用程式資料安全標準 : 術語 縮寫和首字縮寫 適用對象 所有商戶和服務提供商 所有商戶和服務提供商 所有商戶和服務提供商 1 符合資格的商戶 1 符合資格的商戶 1 符合資格的商戶 1 符合資格的商戶 1 符合資格的商戶和服務提供商 所有商戶和服務提供商 1 為了確定適當的自我評估問卷, 請參閱 PCI 資料安全標準 : 自我評估問卷說明和指南 中的 選擇最適合您組織的 SAQ 和證明 部分 PCI DSS SAQ D,v2.0,PCI 資料安全標準 : 相關文件版權所有 2010 PCI Security Standards Council LLC 2010 年 10 月第 iii 頁

5 開始之前 完成自我評估問卷 SAQ D 適用於所有符合 SAQ 資格條件的服務提供商, 以及所有不符合 SAQ A-C 類型的商戶 各驗證類型的簡要描述見下表, 完整描述見 PCI DSS 自我評估問卷說明和指南 SAQ 描述 A 不出示實卡 ( 電子商務或郵購 / 電話訂購 ) 的商戶, 所有持卡人資料處理事宜均外包 這永不適用於面對面交易的商戶 B C-VT C D 未儲存電子格式的持卡人資料的刷卡機商戶或者未儲存電子格式持卡人資料的獨立撥出終端機商戶 僅使用基於 Web 的虛擬終端機而不儲存電子格式持卡人資料的商戶 擁有連接到網際網路的支付應用程式系統而不儲存電子格式持卡人資料的商戶 所有其他商戶 ( 不包括在上述 SAQ A-C 的描述中 ), 以及所有由支付品牌定義為符合完成 SAQ 資格條件的服務提供商 SAQ D 適用於未達到上述 SAQ A-C 以及符合 SAQ 之支付品牌定義之所有服務提供商標準, 但符合 SAQ 的商戶 SAQ D 服務提供商和商戶必須完成 SAQ D 和相關的合規證明, 確認以下事項, 以便驗證其合規性 雖然許多完成 SAQ D 的組織需要驗證是否符合各項 PCI DSS 要求的規定, 但是對於一些業務模式非常特殊的組織來說, 某些要求可能不適用 例如, 如果某公司在任何情況下均不會使用無線技術, 則對於 PCI DSS 中針對無線技術管理的部分, 該公司不需要驗證其合規性 請參閱下述指南, 瞭解有關無線技術及某些其他特定要求排除事項的資訊 本問卷的每個部分均根據 PCI DSS 中的要求, 關注某個特定的安全領域 PCI DSS 合規 完成步驟 1. 評估您的環境的 PCI DSS 合規性 2. 根據 自我評估問卷說明和指南 中的說明, 完成本自我評估問卷 (SAQ D) 3. 與 PCI SSC 核准掃描供應商 (ASV) 一起完成漏洞傳遞掃描, 並從 ASV 處獲得傳遞掃描證據 4. 完整填寫合規證明 5. 將 SAQ 傳遞掃描證據和合規證明隨其他必要的文件一起, 提交給您的收單機構 ( 適用於商戶 ), 或提交給支付品牌或其他要求機構 ( 適用於服務提供商 ) PCI DSS SAQ D,v2.0, 開始之前版權所有 2010 PCI Security Standards Council LLC 2010 年 10 月第 iv 頁

6 關於某些特定要求不適用性的指南 排除事項 : 如果您需要回答 SAQ D 以驗證您的 PCI DSS 合規狀態, 則可能需要考量以下例外事項 請參閱下方的 不適用性, 瞭解相應的 SAQ 回應 僅當您的網路中存在無線系統時, 才需要回答針對無線的問題 ( 例如, 要求 和 4.1.1) 請注意, 要求 11.1 ( 使用程序識別未經授權的無線存取點 ) 仍必須作答, 即使您的環境中沒有無線系統, 其原因在於程序可偵測到在您不知情時新增的任何惡意或未經授權的設備 僅當您的組織自己編寫自訂應用程式時, 才需要回答針對自訂應用程式和程式碼的問題 ( 要求 6.3 和 6.5) 僅當設施具有本文中所定義的 敏感區域 時, 才需要回答針對要求 的問題 敏感區域 是指用於儲存 處理或傳輸持卡人資料的系統所在的任何資料中心 伺服器室或任何區域 敏感區域 不包括僅配備 POS 終端機的區域, 例如零售店的收銀區, 但包括儲存持卡人資料的零售店後臺伺服器機房以及儲存大量持卡人資料的儲存區 不適用性 : 對於不適用於您環境的這些要求及任何其他要求, 您必須在 SAQ 的 特殊說明 欄中標明 不適用 此外, 對於每個 不適用 項目, 還必須相應填寫附錄 D 中的 不適用性解釋 工作表 PCI DSS SAQ D,v2.0, 開始之前版權所有 2010 PCI Security Standards Council LLC 2010 年 10 月第 v 頁

7 合規證明,SAQ D 商戶版 提交說明 商戶必須根據 支付卡行業的資料安全標準 (PCI DSS) 要求和安全評估程序 完成此合規證明, 以證明商戶的合規狀態 請完成所有適用部分並參閱本文件中 PCI DSS 合規 完成步驟 部分的提交說明 第 1 部分 : 商戶與合格安全性評估商資訊 第 1a 部分 : 商戶組織資訊 公司名稱 : DBA: 聯絡人姓名 : 職務 : 電話 : 電子郵件 : 營業地址 : 城市 : 州 / 省 : 國家 / 地區 : 郵遞區號 : 網址 : 第 1b 部分 : 合格安全評估機構公司資訊 ( 如適用 ) 公司名稱 : PCI DSS SAQ D,v2.0, 合規證明, 商戶版版權所有 2010 PCI Security Standards Council LLC 2010 年 10 月第 1 頁

8 QSA 主要聯絡人姓名 : 職務 : 電話 : 電子郵件 : 營業地址 : 城市 : 州 / 省 : 國家 / 地區 : 郵遞區號 : 網址 : 第 2 部分商戶業務類型 ( 勾選所有適用項目 ): 零售商 電信 雜貨店和超市 石油 電子商務 郵購 / 電話訂購 其他 ( 請在此處寫明 ): 列岀 PCI DSS 審查中包括的設施和位置 : 第 2a 部分 : 關係 貴公司是否和一家或多家第三方代理機構 ( 例如閘道公司 網路託管公司 航空訂票代理機構 忠誠項目代理機構等 ) 有關係? 是 否 您的公司是否與一個以上的收單機構有關係? 是否 第 2b 部分 : 交易處理您的企業如何以及出於何種目的儲存 處理和 / 或傳輸持卡人資料? 請提供有關貴組織使用之支付應用程式的以下資訊 : 使用的支付應用程式版本號最後一次按照 PABP/PA-DSS 認證 PCI DSS SAQ D,v2.0, 合規證明, 商戶版版權所有 2010 PCI Security Standards Council LLC 2010 年 10 月第 2 頁

9 第 3 部分 :PCI DSS 驗證 根據 ( 完成日期 ) 完成的 SAQ D 中註明的結果,( 商戶公司名稱 ) 聲稱自己的合規狀態如下 ( 勾選一項 ): 合規 : PCI SAQ 的所有部分均已完成, 且對所有問題的回答均為 是, 因此總體評定結果為合規, 並 PCI SSC 核准掃描供應商 (ASV) 已完成傳遞掃描, 從而證明 ( 商戶公司名稱 ) 完全符合 PCI DSS 規定 不合規 :PCI DSS SAQ 的所有部分並未全部完成, 或並非對所有問題的回答均為 是, 因此總體評定結果為不合規, 或者 PCI SSC 核准掃描供應商 (ASV) 尚未完成傳遞掃描, 從而未證明 ( 商戶公司名稱 ) 完全符合 PCI DSS 規定 合規的目標日期 : 提交此表單的實體如果狀態為 不合規, 則可能需要完成本文件第 4 部分的 措施計劃 在完成第 4 部分之前, 請聯絡您的收單機構或支付品牌, 因為並非所有支付品牌都需要完成此部分 第 3a 部分 : 合規狀態確認 商戶確認 : PCI DSS 自我评估問卷 D (SAQ 的版本 ) 版已根據其中的說明填寫完畢 上述 SAQ 與本證明中的所有資訊在一切重要方面公正代表了我的評估結果 我已與我的支付應用程式供應商確認, 我的支付系統不會在授權後儲存敏感的驗證資料 我已閱讀 PCI DSS 且知曉我必須始終完全符合 PCI DSS 規定 在此評估過程中審查的任何系統上, 找不到任何在交易授權後儲存磁條 ( 即磁軌 ) 資料 2 CAV2 CVC2 CID 3 4 或 CVV2 資料或者 PIN 資料的證據 第 3b 部分 : 商戶確認 磁條中編碼的資料或晶片上的等同資料, 用於在出示實卡的交易過程中進行授權 實體不得在交易授權後保留完整的磁條資料 可以保留的磁軌資料元素只有帳戶號碼 到期日期與姓名 印在支付卡簽名條上或右側或印在支付卡正面的三到四位的數值, 用於驗證不出示實卡的交易 由持卡人在出示實卡的交易過程中輸入的個人識別碼, 和 / 或出現在交易訊息中的經加密的 PIN 區塊 PCI DSS SAQ D,v2.0, 合規證明, 商戶版版權所有 2010 PCI Security Standards Council LLC 2010 年 10 月第 3 頁

10 商戶執行長簽名 日期 商戶執行長姓名 標題 代表的商戶公司 第 4 部分 : 針對不合規狀態的措施計劃 請針對每項要求選擇相應的 合規狀態 如果對於任何要求, 您的回答為 否, 則需要提供公司將符合要求的日期, 並簡要描述為了 4 部分之前, 請聯絡您的收單機構或支付品牌, 因為並非所有支付品牌都需要完成此部分 合規狀態 ( 選擇一項 ) PCI DSS 要求要求描述是否 補救日期和措施 ( 如果合規狀態為 否 ) 1 安裝並維護防火牆設定, 以保護持卡人資料 2 對於系統密碼及其他安全參數, 請勿使用供應商提供的預設值 3 保護儲存的持卡人資料 4 加密透過開放的公用網路傳輸的持卡人資料 5 使用並定期更新防毒軟體或程式 6 開發並維護安全系統和應用程式 7 根據業務需要限制對持卡人資料的存取 8 為具有電腦存取權的每個人指定唯一的 ID 9 限制對持卡人資料的實際存取 PCI DSS SAQ D,v2.0, 合規證明, 商戶版版權所有 2010 PCI Security Standards Council LLC 2010 年 10 月第 4 頁

11 合規狀態 ( 選擇一項 ) 10 追蹤並監控對網路資源及持卡人資料的所有存取 11 定期測試安全系統和程序 12 維護確保適用於所有員工的資訊安全政策 PCI DSS SAQ D,v2.0, 合規證明, 商戶版版權所有 2010 PCI Security Standards Council LLC 2010 年 10 月第 5 頁

12 合規證明,SAQ D 服務提供商版 提交說明 服務提供商必須根據 支付卡行業的資料安全標準 (PCI DSS) 要求和安全評估程序 完成此合規證明, 以證明服務提供商的合規狀態 請完成所有適用部分並參閱本文件中 PCI DSS 合規 完成步驟 部分的提交說明 第 1 部分 : 服務提供商與合格安全性評估商資訊 第 1a 部分 : 服務提供商組織資訊 公司名稱 : DBA: 聯絡人姓名 : 職務 : 電話 : 電子郵件 : 營業地址 : 城市 : 州 / 省 : 國家 / 地區 : 郵遞區號 : 網址 : 第 1b 部分 : 合格安全評估機構公司資訊 ( 如適用 ) 公司名稱 : PCI DSS SAQ D,v2.0, 合規證明, 商戶版版權所有 2010 PCI Security Standards Council LLC 2010 年 10 月第 1 頁

13 QSA 主要聯絡人姓名 : 職務 : 電話 : 電子郵件 : 營業地址 : 城市 : 州 / 省 : 國家 / 地區 : 郵遞區號 : 網址 : 第 2 部分 :PCI DSS 評估資訊 第 2a 部分 : 包括 在 PCI DSS 評估範圍之内的服務 ( 勾選所有適用項目 ) 3-D 安全託管服務提供商 託管服務提供商 硬體 支付處理 ATM 帳戶管理 託管服務提供商 Web 支付處理 MOTO 授權 發行者處理 支付處理 網際網路 後臺服務 忠誠方案 支付處理 POS 帳單管理 管理服務 預付費服務 結算 商戶服務 記錄管理 資料準備 網路服務提供商 / 傳輸器 稅金 / 政府支付款項 欺詐和退款服務 支付閘道 / 交換器 其他 ( 請在此處寫明 ): 列岀 PCI DSS 審查中包括的設施和位置 : PCI DSS SAQ D,v2.0, 合規證明, 商戶版版權所有 2010 PCI Security Standards Council LLC 2010 年 10 月第 2 頁

14 第 2b 部分 : 如果任何列述之服務由服務提供商提供, 但未包括在 PCI DSS 評估的範圍之内, 請勾選 : 3-D 安全託管服務提供商 託管服務提供商 硬體 託管服務提供商 ATM 帳戶管理 託管服務提供商 Web 支付處理 MOTO 授權 發行者處理 支付處理 網際網路 後臺服務 忠誠方案 支付處理 POS 帳單管理 管理服務 預付費服務 結算 商戶服務 記錄管理 資料準備 網路服務提供商 / 傳輸器 稅金 / 政府支付款項 欺詐和退款服務 支付閘道 / 交換器 其他 ( 請在此處寫明 ): 第 2c 部分 : 關係 您的公司是否與一個或多個第三方服務提供商託管公司 航班訂票代理商 忠誠度方案代理商等 ) 有關係? ( 例如, 閘道 Web 是否 第 2d 部分 : 交易處理 您的企業如何以及出於何種目的儲存 處理和 / 或傳輸持卡人資料? 使用的支付應用程式版本號最後一次按照 PABP/PA-DSS 認證 請提供有關貴組織使用之支付應用程式的以下資訊 : 第 3 部分 :PCI DSS 驗證 根據 ( 完成日期 ) 完成的 SAQ D 中註明的結果,( 服務提供商公司名稱 ) 聲稱自己的合規狀態如下 ( 勾選一項 ): 合規 : PCI SAQ 的所有部分均已完成, 且對所有問題的回答均為 是, 因此總體評定結果為合規, 並且 PCI SSC 核准掃描供應商 (ASV) 已完成傳遞掃描, 從而證明 ( 服務提供商公司名稱 ) 完全符合 PCI DSS 規定 PCI DSS SAQ D,v2.0, 合規證明, 商戶版版權所有 2010 PCI Security Standards Council LLC 2010 年 10 月第 3 頁

15 不合規 :PCI SAQ 的所有部分並未全部完成, 或對某些問題的回答為 否, 因此總體評定結果為不合規, 或者 PCI SSC 核准掃描供應商 (ASV) 尚未完成傳遞掃描, 從而未證明 ( 服務提供商公司名稱 ) 完全符合 PCI DSS 規定 合規的目標日期 : 提交此表單的實體如果狀態為 不合規, 則可能需要完成本文件第 4 部分的 措施計劃 在完成第 4 部分之前, 請聯絡您的收單機構或支付品牌, 因為並非所有支付品牌都需要完成此部分 PCI DSS SAQ D,v2.0, 合規證明, 商戶版版權所有 2010 PCI Security Standards Council LLC 2010 年 10 月第 4 頁

16 第 3a 部分 : 合規狀態確認 服務提供商確認 : 自我评估問卷 D ( 插入版本號 ) 版已根據其中的說明填寫完畢 上述 SAQ 與本證明中的所有資訊公正代表了我的評估結果 我已閱讀 PCI DSS 且知曉我必須始終完全符合 PCI DSS 規定 在此評估過程中審查的任何系統上, 找不到任何在交易授權後儲存磁條 ( 即磁軌 ) 資料 5 CAV2 CVC2 CID 6 7 或 CVV2 資料或者 PIN 資料的證據 第 3b 部分 : 服務提供商確認 服務提供商執行長簽名 日期 服務提供商執行長姓名 標題 代表的服務提供商公司 第 4 部分 : 針對不合規狀態的措施計劃 請針對每項要求選擇相應的 合規狀態 如果對於任何要求, 您的回答為 否, 則需要提供公司將符合要求的日期, 並簡要描述為了 4 部分之前, 請聯絡您的收單機構或支付品牌, 因為並非所有支付品牌都需要完成此部分 磁條中編碼的資料或晶片上的等同資料, 用於在出示實卡的交易過程中進行授權 實體不得在交易授權後保留完整的磁條資料 可以保留的磁軌資料元素只有帳戶號碼 到期日期與姓名 印在支付卡簽名條上或右側或印在支付卡正面的三到四位的數值, 用於驗證不出示實卡的交易 由持卡人在出示實卡的交易過程中輸入的個人識別碼, 和 / 或出現在交易訊息中的經加密的 PIN 區塊 PCI DSS SAQ D,v2.0, 合規證明, 商戶版版權所有 2010 PCI Security Standards Council LLC 2010 年 10 月第 5 頁

17 合規狀態 PCI ( 選擇一項 ) DSS 要求 要求描述 是 否 補救日期和措施 ( 如果合規狀態為 否 ) 1 安裝並維護防火牆設定, 以保護持卡人資料 2 對於系統密碼及其他安全參數, 請勿使用供應商提供的預設值 3 保護儲存的持卡人資料 4 加密透過開放的公用網路傳輸的持卡人資料 5 使用並定期更新防毒軟體或程式 6 開發並維護安全系統和應用程式 7 根據業務需要限制對持卡人資料的存取 8 為具有電腦存取權的每個人指定唯一的 ID 9 限制對持卡人資料的實際存取 10 追蹤並監控對網路資源及持卡人資料的所有存取 11 定期測試安全系統和程序 12 維護確保適用於所有員工的資訊安全政策 PCI DSS SAQ D,v2.0, 合規證明, 商戶版版權所有 2010 PCI Security Standards Council LLC 2010 年 10 月第 6 頁

18 自我評估問卷 D 註 : 以下問題均依據 PCI DSS 要求和安全評估程序文件定義之 PCI DSS 要求和測試程序編號 建立並維護安全網路 完成日期 : 要求 1: 安裝並維護防火牆設定, 以保護資料 * 1.1 建立的防火牆和路由器設定標準是否包括以下內容 : 是否制定了一套正式程序, 用於核准及測試所有外部網路連接以及對防火牆和路由器設定的變更? (a) 是否具有目前網路圖表 ( 例如, 一個表明網路中持卡人資料流程圖表 ), 並且它記錄了至持卡人資料的所有連接, 包括所有無線網路? (b) 圖表是否及時更新? (a) 設定標準是否要求在各網際網路連接以及在非軍事區域 (DMZ) 和內部網路區域之間建立防火牆? (b) 目前網路圖表是否與防火牆設定標準一致? 防火牆和路由器設定標準是否包括關於網路元件邏輯管理的群組 角色和責任的說明? (a) (b) 防火牆和路由器設定標準是否包括一個業務需要的服務 通訊協定和連接埠 ( 例如, 超文字傳輸協定 (HTTP) 和安全通訊端層 (SSL) 安全殼層 (SSH) 和虛擬專用網路 (VPN) 協定 ) 的文件清單 所有許可之不安全服務 通訊協定和連接埠是否必需, 並且各服務 通訊協定和連接埠之安全功能是否嚴加記錄和執行? 註 : 不安全的服務 通訊協定或連接埠包括但不限於 FTP Telnet POP3 IMAP 和 SNMP (a) 防火牆和路由器設定標準是否要求至少每 6 個月審查一次防火牆和路由器規則集? (b) 防火牆和路由器規則集是否至少每六個月對進行一次審查? 1.2 版防火牆和路由器設定是否可限制不受信任網路和持卡人資料環境中的任何系統之間的連接, 如下所述 : 註 : 不受信任網路 是指在接受審查的實體網路之外的任何網路, 和 / 或實體無法控制或管理的任何網路 2010 年 10 月第 1 頁

19 * 版 (a) 輸入和輸出流量是否受到持卡人資料環境需要的限制, 並且對這些限制進行了記錄? (b) 其他所有輸入和輸出流量是否明確禁止 ( 例如透過使用明示的 禁止所有 或允許聲明後的暗示禁止 )? 路由器設定檔案是否安全且同步? 是否在任何無線網路和持卡人資料環境之間安裝周邊防火牆, 並對這些防火牆進行設定, 以禁止或控制 ( 如果此類流量是業務所必需的 ) 任何從無線環境到持卡人資料環境的流量? 1.3 防火牆設定是否禁止網際網路和持卡人資料環境中任何系統元件之間的直接公共存取? 是否實施 DMZ, 使輸入流量僅流入可提供經授權公共存取服務 通訊協定和連接埠的系統元件? 是否限制輸入網際網路流量, 使其只能到達 DMZ 內的 IP 位址? 對於網際網路和持卡人資料環境之間的輸入或輸出流量, 是否禁止直接連接? 是否禁止內部位址從網際網路傳遞到 DMZ? 是否明確授權輸出流量從持卡人資料環境流向網際網路? 是否實施了亦稱為動態封包過濾的狀態檢查 ( 即, 僅允許已建立的連接進入網路 )? 儲存持卡人資料 ( 例如資料庫 ) 的系統元件是否妥善放置到内部網路區域内, 並且與 DMZ 和其他不受信任網路隔離開來? (a) 方法是否到位, 以防止專用 IP 位址和路由資訊洩漏至網際網路? 註 : 掩蓋 IP 位址的方法包括但不限於 : 網路位址轉換 (NAT) 將包含持卡人資料的伺服器放置到代理伺服器 / 防火墻或内容快取區之後, 移除或過濾那些使用註冊位址的專用網路路由廣告, 内部使用 RFC1918 位址空間, 而不是註冊位址 (b) 任何洩漏專用 IP 位址和路由資訊至外部實體的行為是否得到授權? 2010 年 10 月第 2 頁

20 * 1.4 (a) 對於直接連接到網際網路且用於存取組織網路的行動電腦和 / 或員工自己的電腦 ( 例如, 員工使用的膝上型電腦 ), 是否在其上安裝了個人防火牆軟體? (b) 個人防火牆軟體是否設定為特定的標準, 並且行動和 / 或員工自有電腦使用者無法對其變更? 2010 年 10 月第 3 頁

21 要求 2: 對於系統密碼及其他安全參數, 請勿使用供應商提供的預設值 * 2.1 在網路上安裝系統之前, 是否總會變更供應商提供的預設設定? 供應商提供的預設設定包括但不限於密碼 簡單網路管理協定 (SNMP) 社群字串, 並刪除不必要的帳戶 對於連接到持卡人資料環境或用於傳輸持卡人資料的無線環境, 是否按如下所述變更預設設定 : (a) 加密金鑰是否已在安裝時變更了預設設定, 並且在任何知道金鑰的人離開公司或改變崗位時能夠隨時變更? (b) 無線裝置上的預設 SNMP 社群字串是否已變更? (c) 存取點上的預設密碼 / 複雜密碼是否已變更? (d) 是否已升級了無線裝置上的韌體, 以支援無線網路上的認證和傳輸強效加密? (e) 其他安全相關性的無線供應商預設設定是否已變更 ( 視情況而定 )? 2.2 (a) 是否為所有系統元件制定設定標準, 並且這些標準與行業認可之系統強化標準一致? 行業認可之系統強化標準資源包括但不限於系統管理員稽核網路安全 (SANS) 學會 美國國家標準技術研究所 (NIST) 國際標準組織 (ISO) 以及網際網路安全中心 (CIS) (b) 是否按照要求 6.2 在發現新漏洞問題時更新系統設定標準? (c) 在設定新系統時是否套用了系統設定標準? (d) 系統設定標準是否包括以下項目 : (a) 每台伺服器是否僅實施一項主要功能, 以防止要求不同安全等級的功能在相同伺服器上共存? ( 例如,Web 伺服器 資料庫伺服器和 DNS 應該分別在獨立的伺服器上實施 ) (b) (a) 如果使用虛擬技術, 則每個虛擬系統元件或裝置是否僅實施一項主要功能? 是否僅啓用系統功能需要的必需的服務 通訊協定和精靈等 ( 並非執行裝置特定功能所直接需要之服務與通信協定未啓用 )? 2010 年 10 月第 4 頁

22 * (b) 所有啓用之不安全的服務 通訊協定或精靈是否均論證合理, 安全功能是否嚴加記錄和執行? ( 例如, 使用諸如 SSH S-FTP SSL 或 IPSec VPN 等安全技術, 保護諸如 NetBIOS 檔案共用 Telnet FTP 等不安全服務 ) (a) 設定系統元件之系統管理員及 / 或員工是否知悉這些系統元件的一般安全參數設定? (b) 一般系統安全參數設定是否包含在系統設定標準中? (c) 系統元件上的安全參數設定是否適當? (a) 是否移除了所有不必要的功能, 例如指令碼 驅動程式 功能 子系統 檔案系統和不必要的 Web 伺服器? (b) 啓用的功能是否嚴加記錄並且支援安全設定? (c) 系統元件是否僅存在記錄的功能? 2.3 是否已對所有非主控台管理存取按若下所屬進行加密? 使用針對基於 Web 的管理與其他非主控台管理存取的技術 ( 例如 SSH VPN 或 SSL/TLS) (a) 所有非主控台管理存取是否已使用強效密碼進行加密, 並且在要求提供管理員密碼之前啓動強效加密方法? (b) 系統服務與參數檔案是否已設定, 以防止使用 Telnet 和其他不安全之遠端登入指令? (c) 管理員對基於 Web 管理介面的存取是否經過強效加密法加密? 2.4 如果您是共用託管提供商, 您是否對系統進行了設定, 以保護各實體的託管環境和持卡人資料? 請參閱 附錄 A: 對共用託管提供商的其他 PCI DSS 要求, 瞭解必須符合的特定要求 2010 年 10 月第 5 頁

23 保護持卡人資料 要求 3: 保護儲存的持卡人資料 * 3.1 資料保留與處理政策和程序是否依照如下所示執行的? (a) 資料保留與處理政策和程序是否已執行, 並且包括特別針對業務 法律及 / 或法規所需之持卡人資料之保留要求? 例如, 持卡人資料因 Y 業務原因而需要保留 X 時間 (b) 政策和程序是否包含因法律 法規或業務原因不再需要之資料安全處理的規定, 包括持卡人資料處理? (c) 政策和程序是否包括所有持卡人資料儲存的各個方面? (d) 政策和程序是否至少包括以下一項? 程式化程序 ( 自動或手動 ), 用於移除已儲存但超出資料保留政策定義之要求的持卡人資料 ( 至少每季度實施一次 ) 審查要求 ( 至少每季度實施一次 ), 用於確認儲存的持卡人資料沒有超出資料保留政策定義之要求 3.2 (a) (b) (e) 所有儲存之持卡人資料是否符合資料保留政策定義之規定? 對於支援發行服務並儲存敏感驗證資料的發行商及 / 或公司, 是否存在儲存敏感驗證資料的正當業務理由, 並且資料得到安全儲存? 如果接收並刪除了敏感驗證資料, 是否訂立安全刪除資料的程序, 以確認資料無法恢復? (c) 是否所有系統都遵守關於授權後不儲存敏感驗證資料 ( 即使已加密 ) 的以下要求? 2010 年 10 月第 6 頁

24 * 磁條任意磁軌上的完整內容 ( 卡背面上, 晶片中等同資料或其他位置 ) 是否未儲存在任何環境内? 該資料也可稱為全磁軌 磁軌 磁軌 1 磁軌 2 和磁條資料 註 : 在正常的業務過程中, 可能需要保留以下磁條資料元素 : 持卡人的姓名 主要帳戶號碼 (PAN) 到期日期 業務代碼 為將風險降至最低, 只儲存業務所需的資料元素 卡驗證代碼或值 ( 印在支付卡正面或背面的三或四位數字 ) 是否未儲存在任何環境内? 個人識別碼 (PIN) 或加密的 PIN 區塊是否未儲存在任何環境内? 3.3 顯示 PAN 時是否對其進行遮罩 ( 最多可顯示前六位和後四位數字 )? 註 : 對於出於特定需求需要查看完整 PAN 的員工和其他方, 本要求不適用 ; 如果針對銷售點 (POS) 收據等持卡人資料顯示有更加嚴格的要求, 則本要求不會取代此類要求 3.4 是否透過使用下列任一方法, 至少使 PAN 在其任何儲存位置 ( 包括資料存放庫 可擕式數位媒體 備份媒體與稽核記錄中的資料 ) 都具有不可讀性? 基於強效加密的單向雜湊 ( 雜湊必須應用於整個 PAN) 截斷 ( 雜湊不得用於取代 PAN 被截斷的區段 ) 索引權杖與 Pad ( 必須安全地儲存 Pad) 具有相關金鑰管理流程和程序的強效密碼編譯 註 : 如果可以存取 PAN 的截斷與雜湊版本, 惡意之人可以相對輕鬆地重建原始 PAN 資料 凡同一 PAN 的雜湊與截斷版本呈現在實體環境内, 必須採取額外的控制措施以確保雜湊與截斷版本不會被用於重建原始 PAN 如果使用了磁碟加密 ( 而不是檔案或資料欄層級的資料庫加密 ), 則是否依照如下方法管理存取 : (a) 是否獨立於原生作業系統存取控制機制, 對加密檔案系統的邏輯存取進行管理 ( 例如, 不使用本機使用者帳戶資料庫 )? 2010 年 10 月第 7 頁

25 * (b) 加密金鑰是否被安全儲存 ( 例如, 儲存在透過嚴格存取控制進行充分保護的卸除式媒體上 ) (c) 卸除式媒體上的持卡人資料在任何儲存之地是否都進行了加密? 註 : 如果未使用磁碟加密對卸除式媒體進行加密, 則儲存在此媒體上的資料需要透過其它一些方法實現不可讀性 3.5 是否使用任何金鑰用於保全持卡人資料以防洩露和濫用, 如下所述 : 註 : 此項要求還適用於保護資料加密金鑰之金鑰加密金鑰 此類金鑰加密金鑰必須至少與資料加密金鑰一樣強效 是否限制對密碼編譯金鑰的存取, 只讓極少數保管人在必要時方能存取? (a) 確認金鑰是否以加密的形式儲存, 並且金鑰加密金鑰是與資料加密金鑰分開儲存? (b) 密碼編譯金鑰是否儲存的位置和形式儘可能少? 3.6 (a) 對用來加密持卡人資料的密碼編譯金鑰, 是否完全紀錄並實施所有金鑰管理流程和程序? (b) 僅對於服務提供商 : 如果與客戶共用金鑰來傳輸或儲存持卡人資料, 則是否向客戶提供相關文件, 其中包含了有關如何按照以下要求 安全傳輸 儲存和更新客戶金鑰的指南? (c) 是否實施了金鑰管理程序, 並作如下要求 : 加密金鑰程序是否包括產生強效加密金鑰? 加密金鑰程序是否包括安全加密金鑰分發? 加密金鑰程序是否包括安全加密金鑰儲存? 加密金鑰程序是否包括完成加密程序之金鑰的加密金鑰變更 ( 例如, 特定期限之後及 / 或特定金鑰產生特定數量的密碼文字之後 ), 此變更必須依照相關應用程式供應商或金鑰所有者並基於行業最佳實務與指南實施 ( 例如,NIST 特殊出版物 )? (a) 金鑰的完整性一旦削弱 ( 例如, 知悉明碼文字金鑰之員工離職等 ), 加密金鑰程序是否包括加密金鑰撤回或更換 ( 例如, 存檔 銷毀及 / 或廢止 )? (b) 加密金鑰程序是否包括更換已知或疑似洩露金鑰? 2010 年 10 月第 8 頁

26 * (c) 如果撤回或更換的加密金鑰得以保留, 則這些金鑰是否未被用於加密 / 論證目的 ( 不用於加密作業 )? 對於使用手動純文字金鑰管理作業, 加密金鑰程序是否包括分割知識與雙重控制措施 ( 例如要求兩名或三名人員共同重建整個金鑰, 且每人僅知悉自己負責之部分金鑰 )? 註 : 手動金鑰管理作業範例包括但不限於 : 金鑰產生 傳輸 上載 儲存以及銷毀 加密金鑰程序是否包括防止加密金鑰未經授權之替代? 是否要求加密金鑰保管人簽署一份聲明 ( 書面或電子格式 ), 表明其瞭解並接受金鑰保管人的責任? 2010 年 10 月第 9 頁

27 要求 4: 加密透過開放的公用網路傳輸的持卡人資料 * 4.1 (a) 是否使用強效密碼編譯以及安全通訊協定 ( 例如 SSLTLS SSH 或 IPSEC) 來保護透過開放式公用網路傳輸的敏感持卡人資料? 屬於 PCI DSS 範圍內的開放式公用網路範例包括但不限於網際網路 無線技術 全球行動通訊系統 (GSM) 與整合封包無線電服務 (GPRS) (b) 是否只有受信任的金鑰及 / 或證書被接受? (c) 是否執行安全通信協定, 以便僅使用安全設定, 並且不支援不安全的版本或設定? (d) 是否已對正在使用的加密方法執行正確的加密強度 ( 檢查供應商建議 / 最佳實務 )? (e) 對於執行 SSL/TLS: HTTPS 是否作為瀏覽器統一記錄定位符 (URL) 的部分出現? 是否僅在 HTTPS 出現於 URL 中時要求持卡人資料? 對於用於傳輸持卡人資料或連接到持卡人資料環境的無線網路, 是否使用行業最佳實務 ( 例如 IEEE i) 對驗證和傳輸實施了強效加密? 註 : 嚴禁在 2010 年 6 月 30 日之前使用 WEP 作為安全控制措施 4.2 (a) 無論何時傳送, 是否透過最終使用者通信技術 ( 例如, 電子郵件 即時訊息或聊天 ), 促使 PAN 實現不可讀性, 或者使用強效加密保全? (b) 是否訂立勿使用最終使用者通訊技術傳送未受保護之 PAN 的政策? 2010 年 10 月第 10 頁

28 維護漏洞管理程式 要求 5: 使用並定期更新防毒軟體或程式 * 5.1 在常受惡意軟體影響的所有系統是否都部署了防毒軟體? 所有的防毒程式是否都能偵測 移除和保護免於所有已知類型的惡意軟體的侵害 ( 例如病毒 木馬 蠕蟲 間諜軟體 廣告軟體和 rootkit)? 5.2 所有的防毒機制是否都是最新的且正在運行, 並且能夠產生稽核日誌記錄, 如下所述 : (a) 防毒政策是否要求更新防毒軟體和定義? (b) 軟體的母片安裝是否啓用自動更新和掃描? (c) 是否啓用自動更新和定期掃描? (d) 所有防毒機制是否正在產生稽核日誌記錄, 並且日誌記錄根據 PCI DSS 要求 10.7 加以保留? 要求 6: 開發並維護安全系統和應用程式 6.1 * (a) 6.2 (a) 所有系統元件和軟體是否都安裝了供應商提供的最新安全修補程式, 以抵御已知漏洞造成的威脅? (b) 關鍵的安全修補程式是否在發佈後的一個月內即已安裝? 註 : 組織可以考量採用基於風險的方法來設定修補程式的安裝優先權 例如, 與不太關鍵的內部設備相比, 可將關鍵基礎架構 ( 例如, 面向公眾的設備 系統和資料庫 ) 的優先權設得較高, 以確保優先權較高的系統和設備能在一個月內處理完畢, 而不太關鍵的設備和系統在三個月內處理完畢即可 是否制定用於識別新發現之安全漏洞的程序, 包括為此類漏洞指定風險排名? ( 至少, 最危急 最高風險漏洞應排名為 高 ) 註 : 風險排名必須基於行業最佳實務 例如, 高 風險漏洞的標準包括 : CVSS 基本分數達到 4.0 或以上, 及 / 或供應商提供的列為 危急 的修補程式, 及 / 或影響關鍵系統元件的漏洞 漏洞排名在 2012 年 6 月 30 日之前被視為最佳實務, 之後它會變成一項要求 2010 年 10 月第 11 頁

29 * (b) 用於確定新安全漏洞的程序是否包括使用安全漏洞資訊的外部資源? 6.3 (a) 軟體開發程序是否基於行業標準及 / 或最佳實務? (b) 資訊安全是否納入整個軟體開發生命週期? (c) 軟體應用程式是否根據 PCI DSS ( 例如, 安全驗證和日誌記錄 ) 進行開發? (d) 軟體應用程式是否足以確保如下項目? 在支付應用程式啟用或發佈給客戶前, 是否移除了自訂的支付應用程式帳戶 使用者 ID 及 / 或密碼? 在發佈給生産或客戶前, 是否審查所有自訂應用程式程式碼變更 ( 使用手動或自動程序 ), 以便識別任何潛在編碼漏洞, 如下所述 : 程式碼變更是否都必須由原始程式碼作者以外且熟知程式碼檢查技術和安全編碼實踐的人員進行? 程式碼審查是否能確保程式碼是根據安全的編碼指南進行開發的 ( 請參閱 PCI DSS 要求 6.5)? 在發佈以前是否執行相應的更正? 在發佈以前是否由管理層審查並批准程式碼檢查結果? 註 : 有關程式碼審查的本要求適用於系統開發生命週期中的所有自訂程式碼 ( 包括內部和面向公眾的自訂程式碼 ) 程式碼審查可以由有經驗的內部人員或第三方進行 根據 PCI DSS 要求 6.6 所述, 如果 Web 應用程式是面向公眾的, 則也需受到更多控制, 以應對實施後持續出現的威脅和漏洞 6.4 變更控制程序是否遵循所有系統元件的變更, 以包括如下項目 : 測試 / 開發環境是否獨立於生產環境, 並設定存取控制, 確保兩者的分離? 是否對分配到開發 / 測試環境與生產環境中的人員進行職責分離? 是否未將生產資料 ( 真實的 PAN) 用於測試或開發? 在生產系統啟用前, 是否移除了測試資料與帳戶? (a) 實施安全修補程式和軟體變更相關的變更控制程序是否記錄在案, 並要求下述 ? 2010 年 10 月第 12 頁

30 * (b) 是否執行以下項目以實現所有變更 : 是否記錄影響? 獲得授權方的核准是否記錄在案? (a) (b) 是否執行功能測試, 以確認變更沒有對系統安全產生不利影響? 對於自訂程式碼變更, 在部署用於生産之前, 是否測試所有更新對於 PCI DSS 要求 6.5 的合規性? 每項變更是否均準備了退出程序? 6.5 (a) 應用程式的開發是否基於安全編碼指南? ( 例如, 開放式 Web 應用程式安全專案 (OWASP) 指南 SANS CWE Top 25 CERT 安全編碼等 )? (b) 開發者是否瞭解安全編碼技術? (c) 軟體開發程序是否包含預防一般編碼漏洞, 以確保應用程式至少不易受以下項目的攻擊 : 註 :6.5.1 至 中列舉的漏洞都是此版 PCI DSS 發佈時行業最佳實務中最新的漏洞 然而, 在更新漏洞管理的行業最佳實務時, 這些要求必須使用最新的最佳實務 插入式攻擊, 特別是 SQL 插入? ( 驗證輸入項, 以確認使用者資料無法修改指令與查詢的意思, 利用參數化查詢等 ) 同時還須考慮 OS 指令注入 LDAP 與 Xpath 注入式漏洞以及其他注入式漏洞 緩衝區溢位? ( 驗證緩衝區界限, 截斷輸入字串 ) 非安全密碼編譯儲存? ( 防止加密漏洞 ) 非安全通訊? ( 對所有已驗證的敏感通訊進行妥善加密 ) 不當錯誤處理? ( 不要透過錯誤訊息洩露資訊 ) 所有 高危 漏洞是否依照漏洞識別程序確定 ( 按照 PCI DSS 要求 6.2 的定義 )? 註 : 此要求在 2012 年 6 月 30 日之前被視為最佳實務, 之後它會變成一項要求 對於網路應用程式和應用程式介面 ( 内部或外部 ), 以下額外漏洞也得到解決 : 跨網站指令碼攻擊 (XSS)? ( 在納入之前驗證所有參數, 利用内容敏感的逸出等 ) 2010 年 10 月第 13 頁

31 * 不當存取管控措施, 例如非安全直接物件參考, 無法限制 URL 存取以及目錄傳輸? ( 正確驗證使用者並處理輸入 切勿向使用者公開內部物件參考 ) 跨網站請求偽造 (CSRF)? ( 切勿答復由瀏覽器自動提交的授權證書與權杖 ) 6.6 對於面向公眾的 Web 應用程式, 是否能夠持續應對新的威脅和漏洞? 是否透過以下任一方法, 保護這些應用程式免受已知攻擊? 透過手動或自動應用程式漏洞安全評估工具或方法檢查面向公眾的 Web 應用程式, 具體如下 : o 至少每年變更一次 o 任何變更後 o 由專門檢查應用程式安全的機構 o 所有的漏洞都被更正 o 更正後重新評估應用程式 或 確認在面向公眾的 Web 應用程式前端安裝 Web 應用程式層級防火牆, 以偵測並防止基於 Web 的攻擊 註 : 專門檢查應用程式安全的機構 可以是第三方公司或一個內部組織, 只要檢查人是專門從事應用程式碼安全的, 並且能夠證明獨立於開發團隊 2010 年 10 月第 14 頁

32 實施嚴格的存取控制措施 要求 7: 限制為只有業務需要知道的人才能存取持卡人資料 * 7.1 對系統元件和持卡人資料的存取是否僅限於如下因工作需要須進行此類存取的人員, 如下所述 : 是否限制擁有權限之使用者 ID 的存取權為履行工作職責所必需的最小權限? 是否已根據工作劃分和職能分配了權限 ( 也稱為 基於角色的存取控制 或 RBAC)? 是否要求獲得授權方的記錄核准 ( 書面或電子形式 ), 以指定所需權限? 是否透過自動存取控制系統實施存取控制? 7.2 是否為具有多個使用者的系統設定了存取控制系統, 以根據使用者的知情需要限制存取? 是否將其設定為 全部拒絕, 除非明確允許, 如下所述 : 所有的系統元件是否都採用了存取控制系統? 是否已設定了存取控制系統, 根據工作劃分和職能將權限分配給個人? 存取控制系統是否擁有一個預設的 禁止所有 設定? 註 : 一些存取控制系統被預設設定為 允許所有, 因此允許所有存取, 除非制定了專門禁止的規則 2010 年 10 月第 15 頁

33 要求 8: 為具有電腦存取權的每個人指定唯一的 ID * 8.1 在允許所有使用者存取系統元件或持卡人資料之前, 是否為其指定唯一的 ID? 8.2 除了指定唯一的 ID 之外, 是否還採用以下一種或多種方法, 對所有使用者進行驗證? 您知道的東西, 例如密碼或口令 您擁有的東西, 例如權杖設備或智能卡 您的身份描述, 例如生物識別訊息 8.3 是否為員工 管理員和第三方對網路的遠端存取 ( 來自網路外部的網路級存取 ) 採用了雙因素驗證? ( 例如, 遠端驗證和帶有權杖的撥入服務 (RADIUS) ; 終端存取控制器 存取帶有權杖的存取控制系統 (TACACS); 或者便於雙因素驗證的其他技術 ) 註 : 雙因素驗證要求使用三种驗證方法之中的兩种方法進行驗證 ( 請參閲要求 8.2 的驗證方法描述 ) 兩次使用一種因素 ( 例如使用兩個單獨的密碼 ) 不被視為雙因素驗證 8.4 (a) 在所有系統元件上進行傳輸和儲存操作時, 是否使用強效加密使所有密碼不可讀? (b) 僅對於服務提供商 : 客戶密碼是否已加密? 8.5 是否為所有系統元件上的非消費者使用者和管理員制定了適當的使用者識別和驗證管理控制措施, 如下所述 : 使用者 ID 認證以及其他識別碼物件的添加 刪除和修改是否嚴加控制, 以便僅依據授權實施此類使用者 ID ( 包括具備特定特權 )? 在針對使用者請求執行密碼重設前, 是否透過非面對面方法論證使用者身份 ( 例如, 電話 電子郵件或網路 )? 是否將每位使用者的初始密碼和重設密碼設定為唯一值? 每位使用者是否必須在首次使用密碼後立即對其進行變更? 是否立即撤銷或移除所有已終止使用者的存取權? 是否至少每 90 天對非活躍使用者帳戶進行一次移除或停用? (a) 僅在需要時啓用供應商用於遠端存取 維護或支援的帳戶? (b) 供應商遠端存取帳戶在使用時是否會受到監控? 是否向有權存取持卡人資料的所有使用者傳達了驗證程序和政策? 2010 年 10 月第 16 頁

34 * 是否禁止使用群組 共用或一般帳戶和密碼或者其他驗證方法, 如下所述 : 一般使用者 ID 和帳戶已停用或撤除 ; 用於系統管理活動和其他重要功能的共用使用者 ID 已不存在 ; 並且 共用使用者 ID 和一般使用者 ID 未用於管理任何系統元件 (a) 是否至少每 90 天變更一次使用者密碼? (b) 僅對於服務提供商 : 非消費者使用者密碼是否要求定期變更, 並且非消費者使用者是否獲得有關密碼在何時 何種情況下必須變更的指導? (a) 是否要求密碼至少包含七個字元? (b) 僅對於服務提供商 : 是否要求非消費者使用者密碼滿足最短長度要求? (a) 密碼是否必須包含數字和字母字元? (b) 僅對於服務提供商 : 非消費者使用者密碼是否必須包含數字和字母字元? (a) 個人提交的新密碼是否必須不同於其最近使用過的四個密碼? (b) 僅對於服務提供商 : 新的非消費者使用這密碼是否必須不同於其最近使用過的四個密碼? (a) 是否限制重複存取嘗試次數, 最多允許嘗試六次, 達到此限制後即鎖定使用者 ID? (b) 僅對於服務提供商 : 是否在超過六次無效存取嘗試後暫時鎖定非消費者使用者密碼? 一旦使用者帳戶被鎖定, 是否將鎖定持續時間設定為至少 30 分鐘, 或者直到管理員啟用使用者 ID 為止? 如果工作階段保持空閒狀態超過 15 分鐘, 則是否需要使用者重新驗證 ( 例如重新輸入密碼 ), 重新啟動終端或工作階段? 2010 年 10 月第 17 頁

35 * (a) 是否驗證對所有包含持卡人資料的任何資料庫的存取? ( 包括應用程式 管理員和所有其他使用者的存取 ) (b) 是否所有使用者存取資料庫 查詢資料庫和操作資料庫 ( 例如移動 複製 刪除 ) 的行為均僅依循程式設計方法實施 ( 例如, 依循儲存的程序 )? (c) 是否僅資料庫管理員可執行資料庫的使用者直接存取或查詢? (d) 有權存取資料庫的應用程式 ID 是否僅能由應用程式使用 ( 並且不透過個人使用者或其他程序 )? 2010 年 10 月第 18 頁

36 要求 9: 限制對持卡人資料的實際存取 * 9.1 是否制定了相應的設施進入控制措施, 以限制並監控對持卡人資料環境中所含系統的實際存取? (a) 是否制定攝影機及 / 或存取控制機制, 以監控個人對敏感區域的實體存取? 註 : 敏感區域 是指用於儲存持卡人資料的系統所在的任何資料中心 伺服器室或任何區域 其中不包括只有銷售點終端的區域, 例如零售店中的收銀區 (b) 攝影機及 / 或存取控制機制是否保護其不會受到篡改或停用? (c) 透過攝影機及 / 或存取控制機制收集的資料是否接受審查並與其他實體關聯, 並且這些資料是否在法律無另行規定時儲存至少三個月, 除非? 公開存取網路端子的實體存取是否受到嚴格限制 ( 例如, 訪客可存取的區域未啓用網路連接埠, 除非網路存取獲得明確授權 )? 此外, 在這些網路端子處於活躍狀態的區域, 訪客身邊是否始終都有陪護人員? 是否限制對於無線存取點 閘道 掌上型裝置 網路 / 通訊硬體和電信線的實體存取? 9.2 是否制定程序以輕鬆辨別現場人員與訪客, 如下所述 : 出於要求 9 之目的, 現場工作人員 指的是全職和兼職雇員 臨時雇員和承包商以及實際出現在實體場所的顧問 訪客 是指供應商 任何現場工作人員的客人 服務人員或需要進入場所作短暫停留 ( 通常不超過一天 ) 的任何人 (a) 指定識別證給現場人員和訪客的程序是否包括以下項目 : 授予新識別證, 變更存取要求, 以及 是否撤銷終止關係的現場工作人員和過期的訪客識別證? (b) 是否僅獲得授權之工作人員可存取識別證系統? (c) 識別證是否可準確識別訪客並輕鬆辨別現場人員和訪客? 9.3 是否按如下所述對待所有訪客 : 訪客是否須經授權方可進入處理或維護持卡人資料的區域? (a) 是否為訪客提供實體權杖, 以便將訪客識別為非現場工作人員 ( 例如, 識別證或存取裝置 )? 2010 年 10 月第 19 頁

37 * (b) 訪客識別證是否已到期? 是否要求訪客在離開場所前或實體權杖到期時交出實體權杖? 9.4 (a) 是否使用訪客記錄機構 電腦室以及存放和傳輸持卡人資料的資料中心的實體存取活動? (b) 訪客記錄是否包含訪客姓名 所屬公司以及授權實體存取的現場工作人員, 並且該訪客記錄至少保留三個月? 9.5 (a) 是否將媒體備份儲存在安全的位置, 最好是在經營場所之外的設施, 例如替用或備用場所, 或商業儲存設施? (b) 是否至少每年對此位置的安全性進行一次審查? 9.6 所有媒體 ( 包括但不限於電腦 卸除式電子媒體 書面收據 書面報告和傳真 ) 是否均已安全儲存? 9.7 出於要求 9 之目的, 媒體 是指包含持卡人資料的所有紙質和電子媒體 (a) 是否始終對任何媒體的內部和外部分發採取嚴格的控制措施? (b) 控制措施是否包括以下內容 : 是否對媒體進行分類, 以便確定資料的敏感性? 媒體是否透過安全的遞送或其他可以準確追蹤的傳送方式進行發送? 9.8 是否妥善維護記錄, 以便追蹤所有從安全區域遷移的媒體, 另外, 在遷移媒體之前是否獲得管理層核准 ( 尤其是分發媒體給個人時 )? 9.9 是否對媒體的儲存和存取採取嚴格控制措施? 是否正確維護所有媒體的盤存記錄, 並且至少每年盤存媒體一次? 9.10 當出於業務或法律原因不再需要所有媒體時, 是否將這些媒體銷毀? 是否按照以下方法實施銷毀 : (a) 是否將硬拷貝材料粉碎 焚毀或打漿, 以便無法從中恢復持卡人資料? 2010 年 10 月第 20 頁

38 * (b) 儲存資訊之容器在銷毀前是否妥善處置, 以防止有人存取其中内容? ( 例如, 待粉碎 " 容器應配有防止獲取其中内容的鎖具 ) 是否依照行業認可的安全刪除標準, 透過安全擦除程式, 或者透過其他實體方法銷毀媒體 ( 例如消磁 ), 確保電子媒體上的持卡人資料實現不可讀性, 使持卡人資料無法恢復? 2010 年 10 月第 21 頁

39 定期監控並測試網路 要求 10: 追蹤並監控對網路資源及持卡人資料的所有存取 * 10.1 是否制定了一套程序, 將對系統元件的所有存取 ( 尤其是透過 根 等管理權限進行的存取 ) 與每位個人使用者關聯起來? 10.2 是否為所有系統元件實施了自動稽核追蹤, 以重建以下事件 : 所有個人使用者對持卡人資料的存取? 具有根權限或管理權限的任何個人執行的所有動作? 對所有稽核追蹤記錄的存取? 無效的邏輯存取嘗試? 識別和驗證機制的使用? 稽核記錄的初始化? 系統級物件的建立和刪除? 10.3 是否為所有系統元件的各事件記錄了以下稽核追蹤記錄項目 : 使用者識別碼? 事件類型? 日期和時間? 成功或失敗指示? 事件起源? 受影響資料 系統元件或資源的識別碼或名稱? 10.4 (a) 是否透過使用時間同步技術使所有關鍵系統時鐘實現同步, 並且是否對時間同步技術及時更新? 註 : 時間同步處理技術的一則範例是網路時間協定 (NTP) (b) 是否實施以下控制措施擷取 分發和儲存時間 : (a) 是否僅讓指定的中央時間伺服器接收外部來源的時間信號, 並且所有關鍵系統均擁有正確且一致的時間 ( 基於國際原子時間或 UTC)? (b) 指定的中央時間伺服器是否彼此對等, 以維持精確時間, 並且其他内部伺服器僅接收來自中央時間伺服器的時間? 2010 年 10 月第 22 頁

40 * 時間資料是否受到保護, 如下所述 : (a) 存取時間資料者是否僅限於具有存取時間資料業務需求的工作人員? (b) 是否對關鍵系統時間設定的變更進行記錄 監控和審查? 是否接受來自行業認可之特定時間來源的時間設定? ( 這可防止惡意之人變更時鐘 ) 或者, 可使用對稱金鑰加密這些更新, 而且可建立存取控制清單, 指定客戶端機器的 IP 位址隨時間更新一起提供 ( 防止未授權使用內部時間伺服器 ) 10.5 稽核追蹤記錄是否已安全儲存, 從而不會被竄改, 如下所述 : 稽核追蹤記錄的檢視是否僅限於有相關工作需要的人? 是否已透過存取控制機制 實體隔離和 / 或網路隔離保護稽核追蹤檔案, 防止未授權的修改操作? 是否將稽核追蹤記錄檔案立即備份到中央記錄伺服器或難以竄改的媒體中? 面向外部之技術 ( 例如無線 防火牆 DNS 郵件 ) 的記錄是否已卸載或複製到内部區域網路安全中央記錄伺服器或媒體? 是否對記錄使用了檔案完整性監控或變更偵測軟體, 以確保在現有的記錄資料變更時, 一定會產生警示 ( 但加入新資料時不應產生警示 )? 10.6 是否要求所有系統元件的記錄至少每日審查一次, 並且要求制定意外情況的後續跟進措施? 10.7 記錄審查必須包括那些執行安全功能的伺服器, 例如, 入侵偵測系統 (IDS) 和驗證 授權與記帳協定 (AAA) 伺服器 ( 例如 RADIUS) 註 : 可以使用記錄收集 剖析和警示工具, 以符合要求 10.6 的規定 (a) (b) 是否制定稽核記錄保留政策和程序, 並且要求稽核追蹤記錄至少保留一年時間? 稽核記錄是否至少保留一年以作備用, 相關程序是否可立即恢復至少最近三個月的記錄以供分析? 要求 11: 定期測試安全系統和程序 * 2010 年 10 月第 23 頁

41 * 11.1 (a) 是否實施記錄程序, 用於每季偵測並識別一次無線存取點? 註 : 程序可用的方法包括但不限於無線網路掃描 系統元件和基礎架構的實體 / 邏輯檢查 網路存取控制 (NAC) 或無線 IDS/IPS 無論使用何種方法, 它們都必須足以偵測並識別任何未經授權的裝置 (b) 所用方法是否足以偵測並識別任何未授權無線存取點, 至少包括以下項目 : 插入系統元件的 WLAN 卡 ; 連接至系統元件的可攜式無線裝置 ( 例如, 透過 USB 等 ); 連接至網路連接埠或網路裝置的無線裝置 ; (c) 用於識別未授權無線存取點的程序是否至少每季對所有系統元件和設施實施一次? (d) 如果使用自動監控 ( 例如, 無線 IDS/IPS NAC 等 ), 則是否設定會及時警示相關工作人員的監控? (e) 偵測到未授權無線裝置時作出回應是否包括在事故回應計劃中 ( 請參閱 要求 12.9 )? 11.2 是否在網路發生任何重大變更 ( 例如, 安裝新系統元件 網路拓撲變更 防火牆規則修改 產品升級 ) 後, 或至少每季度按如下要求執行內部和外部網路漏洞掃描? 註 : 如果確定以下內容, 則不要求必須完成四次通過性季度掃描才能獲得初始的 PCI DSS 合規性 :1) 最近一次的掃描結果成功通過 ;2) 實體已記錄了要求季度掃描的政策和程序 ; 以及 3) 掃描結果中指出的漏洞在重新掃描時顯示已糾正 第一次 PCI DSS 檢查完成之後的年份中, 必須執行四次通過性季度掃描 (a) 是否執行内部漏洞季度掃描? (b) (c) 內部季度掃描程序是否包括重新掃描, 直到獲得通過性結果, 或所有 PCI DSS 要求 6.2 定義的 高危 漏洞均已解決? 内部季度掃描是否由合格內部人員或外部第三方執行, 如有可能, 還應確定測試方是否具備組織獨立性 ( 不必為 QSA 或 ASV)? (a) 是否執行外部季度漏洞掃描? 2010 年 10 月第 24 頁

42 * (b) 每次外部季度掃描結果是否足以確保符合 ASV 計劃指南 的要求 ( 例如, 不存在 CVSS 評級超過 4.0 的漏洞和自動失效 )? (c) 每次外部漏洞季度掃描是否由支付卡行業安全標準協會 (PCI SSC) 認可的核准掃描供應商 (ASV) 執行? (a) 是否在網路發生任何重大變更 ( 例如, 安裝新系統元件 網路拓撲變更 防火牆規則修改 產品升級 ) 後, 或至少每季度按如下要求執行內部和外部網路漏洞掃描? 註 : 網路變更後執行的掃描可由內部人員執行 (b) 掃描程序是否包括重新掃描, 直至 : 對於外部掃描, 不存在得分超過 CVSS 評級為 4.0 的漏洞, 對於内部掃描, 可成功通過, 或者 PCI DSS 要求 6.2 定義之所有 高危 漏洞是否均得到解決? 11.3 (c) 掃描是否由合格內部人員或外部第三方執行, 如有可能, 還應確定測試方是否具備組織獨立性 ( 不必為 QSA 或 ASV)? (a) 是否至少每年一次以及在對基礎結構或應用程式進行任何重大變更 ( 例如, 作業系統升級 新增子網路或 Web 伺服器至環境 ) 後, 執行內部和外部滲透測試? (b) 所記錄的可被利用的漏洞是否都已糾正並且測試多次重複執行? (c) 測試是否由合格內部人員或外部第三方執行, 如有可能, 還應確定測試方是否具備組織獨立性 ( 不必為 QSA 或 ASV)? 這些滲透測試是否包括以下內容 : 網路層滲透測試? 註 : 此類測試應包括支援網路功能和作業系統的元件 應用程式層滲透測試? 註 : 此類測試至少應包括要求 6.5 列舉的漏洞 11.4 (a) 是否使用入侵偵測系統和 / 或入侵防禦系統來監控持卡人資料環境周邊及環境内部關鍵點的所有流量? (b) IDS 和 / 或 IPS 組態是否設定為在發現可疑漏洞時提醒員工? (c) 是否及時更新所有入侵偵測引擎和入侵防禦引擎 基準和簽名? 2010 年 10 月第 25 頁

43 * 11.5 (a) 持卡人資料環境内是否部署了檔案完整性監控工具? 需要監控的檔案範例包括 : 系統可執行檔 應用程式可執行檔 組態檔案和參數檔案 集中儲存的 歷史的或封存的日誌檔案和稽核檔案 (b) 檔案完整性監控工具是否設定為, 一旦發現對關鍵系統檔案 設定檔案或內容檔案的未授權修改, 立即提醒工作人員 ; 並且該工具至少每週比較一次重要檔案? 註 : 在談及檔案完整性監控時, 關鍵檔案通常是指那些不常變更但一經修改便可能表明系統受到威脅或可能受到威脅的檔案 相關作業系統的關鍵檔案通常會配備預先設定的檔案完整性監控產品 其他關鍵檔案 ( 例如, 自訂應用程式的關鍵檔案 ) 則必須由實體 ( 即, 商戶或服務提供商 ) 進行評估和定義 2010 年 10 月第 26 頁

44 維護資訊安全政策 要求 12: 維護確保適用於所有員工的資訊安全政策 * 12.1 是否已將安全政策訂立 出版 維護並散發給所有相關工作人員? 出於要求 12 之目的, 工作人員 指的是全職和兼職雇員 臨時雇員 承包商以及 常駐 在實體場所或者進出公司場所持卡人資料環境的顧問 政策是否滿足所有 PCI DSS 要求? (a) 是否記錄可識別威脅和漏洞並能產生正式風險評估的年度程序? ( 風險評估方法的範例包括但不限於 OCTAVE ISO 和 NIST SP ) (b) 是否至少每年執行一次風險評估程序? 資訊安全政策是否至少每年檢查一次, 並在需要時進行更新以反映業務目標或風險環境的變動? 12.2 是否按照本規範中的要求, 制定了日常作業安全程序 ( 例如, 使用者帳戶維護程序和記錄審查程序 ), 並且這些程序包括有關每項要求的管理和技術程序? 12.3 是否為面向員工的關鍵技術 ( 例如, 遠端存取技術 無線技術 卸除式電子媒體 膝上型電腦 平板電腦 個人資料 / 個人數位助理 [PDA] 電子郵件和網際網路使用 ) 制定了相關的使用政策, 並作出如下要求? 是否在獲得被授權方的明確核準後使用這些技術? 針對技術使用的驗證? 所有此類設備和擁有存取權的人員的清單? 是否在裝置上貼標籤, 以便確定所有者 聯絡資訊和用途? 針對這些技術的可接受的使用方法? 針對這些技術的可接受的網路位置? 公司核准的產品清單? 在無活動時間達到特定值後, 自動中斷遠端存取技術的工作階段? 是否僅在供應商和商業合作夥伴需要時為其啓用遠端存取技術, 並在使用之後立即停用? 2010 年 10 月第 27 頁

45 * (a) 對於透過遠端存取技術存取持卡人資料的工作人員, 是否制定程序禁止將持卡人資料複製 移動和儲存到本機硬碟和卸除式電子媒體, 除了因業務需求而獲得明確授權的情況? (b) 對於獲得適當授權的工作人員, 是否制定政策要求按照 PCI DSS 要求保護持卡人資料? 12.4 安全政策和程序是否明確定義了所有工作人員的資訊安全責任? 12.5 是否已正式向首席安全執行長或其他具有安全知識的管理層成員分配資訊安全職責? 是否將以下資訊安全管理責任指定給個人或團隊 : 建立 明文規定並分發安全政策和程序? 監控並分析安全警示和資訊, 並將其分發給相應人員? 建立 明文規定並分發安全事件回應和向上報告程序, 以確保及時有效地處理各種狀況? 管理使用者帳戶, 包括新增 刪除和修改? 監控並控制對資料的所有存取? 12.6 (a) 是否制定了正式的安全意識計劃, 以便使所有員工都意識到持卡人資料安全的重要性? (b) 安全意識方案計劃是否包括以下項目 : (a) 安全意識計劃是否包括有關加強工作人員安全意識 教育工作人員的多種方法 ( 例如海報 信函 備忘錄 基於網路的訓練 會議和宣傳 )? 註 : 教育方法多種多樣, 具體取決於工作人員的角色及其存取持卡人資料的級別 (b) 是否在入職時教育工作人員, 並且每年執行一次教育訓練? 是否要求工作人員每年至少確認一次他們已閱讀並瞭解安全政策和程序? 2010 年 10 月第 28 頁

46 * 12.7 是否在雇用前對潛在員工 ( 請參閱上述 9.2 中 員工 的定義 ) 進行篩選, 儘量降低從內部受到攻擊的風險? ( 背景調查的範例包括以前的雇用歷史 犯罪記錄 信用歷史和證明人調查 ) 註 : 如果錄用的是特定職位工作人員, 例如在完成交易時一次只能存取一個卡號的商店收銀員, 本要求僅為建議 12.8 如果持卡人資料將與服務提供商共用, 是否維護並實施了用來管理服務提供商的政策和程序? 這些政策和程序是否包括以下內容? 是否維護一份服務提供商清單? 是否簽署一份書面合約, 其中確認服務提供商負責確保其持有的持卡人資料的安全? 是否制定聘用服務提供商的程序, 包括聘用前執行相應的審查評鑑? 是否維護一個計劃, 以監控服務提供商的 PCI DSS 合規狀態? 12.9 是否實施包括以下內容的事件回應計劃, 以便提前做好準備, 當出現系統缺口時可以立即作岀回應? (a) 是否建立了事件回應計劃, 以便在出現系統缺口時加以實施? (b) 該計劃是否至少述及如下內容 : 當威脅發生時, 有關的角色 責任以及溝通和聯絡策略是否至少包括向支付品牌發岀通知? 具體的事件回應程序? 業務恢復和持續程序? 資料備份程序? 分析法律要求, 以報告出現的威脅? 涵蓋和回應所有關鍵系統元件? 參考或包括支付品牌的事件回應程序? 是否至少每年對計劃進行一次測試? 是否指派特定人員負責全天候回應警示? 是否對肩負安全性缺口回應責任的人員提供了相應訓練? 事件回應計劃是否包括入侵偵測 入侵防禦和檔案完整性監控系統提供的警示? 2010 年 10 月第 29 頁

47 * 是否制定了相應程序, 以便根據經驗教訓及行業發展動態, 修改並完善事件回應計劃? 2010 年 10 月第 30 頁

48 附錄 A: 對共用託管提供商的其他 PCI DSS 要求 要求 A.1: 共用託管提供商必須保護持卡人資料環境 * A.1 是否按照如下 A.1.1-A.1.4, 對各實體 ( 即商戶 服務提供商或其他實體 ) 的託管環境和資料加以保護 : 託管提供商必須滿足這些要求以及 PCI DSS 其他所有相關部分的要求 註 : 即使託管提供商可以滿足這些要求, 也不能保證託管服務提供商所服務的實體的合規性 各實體必須符合 PCI DSS 規定並驗證合規性 ( 如適用 ) A.1.1 A.1.2 每個實體是否允許運行僅存取該實體持卡人資料環境的程序, 並且這些應用程式的程序是否使用該實體唯一的 ID 運行? 例如 : 系統中的任何機構都不得使用共用的網路伺服器使用者 ID 機構使用的所有 CGI 指令碼在建立和執行時都必須作為該機構唯一的使用者 ID 各實體的存取權和權限是否僅限於其自身的持卡人資料環境, 如下所述 : (a) 應用程式程序的使用者 ID 是否並非有權限的使用者 ( 根權限 / 管理員權限 )? (b) 每個實體擁有的讀取 寫入或執行權限是否僅可用於其所屬檔案或目錄或者必要的系統檔案 ( 透過檔案系統權限 存取控制清單 chroot jailshell 等加以限制 )? 注意 : 機構的檔案不能與群組共用 (c) 所有機構使用者對共用的系統二進位檔案是否沒有寫入權限? (d) 是否只有擁有記錄項目的實體才可檢視其項目? PCI DSS SAQ D,v2.0, 自我評估問卷, 附錄 A 版權所有 2010 PCI Security Standards Council LLC 2010 年 10 月第 31 頁

49 * (e) 是否針對系統資源的使用嚴加限制? 磁碟空間, 頻寬, 記憶體, CPU 這可確保每個機構不會獨佔控制伺服器資源, 進而可防止其利用漏洞 ( 例如, 錯誤 race 和重新啟動會導致像緩衝區溢出這樣的情況 ), A.1.3 A.1.4 是否啟用了記錄和稽核追蹤記錄? 對於各實體的持卡人資料環境而言, 這些記錄是否是唯一的且符合 PCI DSS 要求 10? 是否針對每位商戶和服務提供商環境啓用記錄操作, 如下所述 : 是否已針對第三方一般應用程式啟用記錄? 記錄在預設情況下是否處於活躍狀態? 是否只有擁有記錄的機構才能查看其記錄? 記錄位置是否已明確通知給擁有它的機構? 是否啟用了相應書面政策和程序, 以便在任何託管商戶或服務提供商受到威脅時, 能及時進行鑑識調查? PCI DSS SAQ D,v2.0, 自我評估問卷, 附錄 A 版權所有 2010 PCI Security Standards Council LLC 2010 年 10 月第 32 頁

50 附錄 B: 補償性控制 在以下情況下, 可為大多數 PCI DSS 要求考量進行補償性控制 : 由於合法的技術限制或明文規定的業務限制, 實體無法滿足某項明確規定的要求, 但已透過其他實施或補償性控制充分降低了與該要求相關的風險 補償性控制必須滿足以下標準 : 1. 符合原始 PCI DSS 要求的目的和嚴格程度 2. 提供與原始 PCI DSS 要求相似的防護水平, 以便補償性控制能夠充分防範原始 PCI DSS 要求所要規避的風險 ( 請參閱 導覽 PCI DSS, 瞭解各項 PCI DSS 要求的目的 ) 3. 超越 其他 PCI DSS 要求 ( 如果只是遵從其他 PCI DSS 要求, 則不是補償性控制 ) 評估補償性控制是否 超越 其他 PCI DSS 要求時, 請考量以下內容 : 註 : 以下 a) 到 c) 項只是範例, 所有補償性控制的充分性必須由執行 PCI DSS 審查的評估機構進行審查和驗證 補償性控制的有效性取決於實施控制的具體環境 週邊的安全控制以及控制的設定 公司應該知曉, 特定的補償性控制不是在所有環境中均有效 a) 如果現有的 PCI DSS 要求已在接受審查的項目要求範疇內, 則不得視為補償性控制 例如, 在發送非主控台管理存取密碼時必須加密, 以降低純文字管理密碼遭到攔截的風險 如果密碼沒有加密, 實體不能使用其他 PCI DSS 密碼要求 ( 入侵者鎖定 複雜密碼等 ) 對此進行補償, 因為這些密碼要求不會降低純文字密碼遭到攔截的風險 而且, 其他密碼控制也已在接受審查的項目 ( 密碼 ) 的 PCI DSS 要求範疇內 b) 如果現有的 PCI DSS 要求是其他領域所要求的, 但不在接受審查的項目要求範疇內, 則可以視為補償性控制 例如, 雙因素驗證是一項針對遠端存取的 PCI DSS 要求 當系統無法支援傳輸加密的密碼時, 也可將內部網路內的雙因素驗證視為針對非主控台管理存取的補償性控制 如果雙因素驗證滿足以下條件, 則可視為可接受的補償性控制 :(1) 透過應對純文字管理密碼遭到攔截的風險, 達到原始要求的目的 ;(2) 得以適當設定且在安全的環境中 c) 現有的 PCI DSS 要求可與新的控制結合成為補償性控制 例如, 如果公司無法按照要求 3.4 使持卡人資料具有不可讀性 ( 例如, 透過加密方式 ), 則可利用解決以下所有問題所需的設備 ( 或設備 應用程式和控制的組合 ) 構成補償性控制 :(1) 內部網路區段劃分 ;(2) IP 位址或 MAC 位址過濾 ; 及 (3) 內部網路內的雙因素驗證 4. 能夠應對由於不符合 PCI DSS 要求所引起的其他風險 評估機構應按照上述 1-4 項, 在每年的 PCI DSS 評估中, 對補償性控制進行徹底評估, 以驗證各補償性控制能否充分應對原始 PCI DSS 要求所要規避的風險 為了保持合規性, 必須制定程序和控制措施, 以確保補償性控制在評估完成後仍然有效 PCI DSS SAQ D,v2.0, 附錄 B: 補償性控制版權所有 PCI Security Standards Council LLC 2010 年 10 月第 33 頁

51 附錄 C: 補償性控制工作表 對於勾選了 是 且在 特殊說明 欄中提到了補償性控制的任何要求, 可使用本工作表來定義其補償性控制 註 : 只有已接受風險分析且有合法的技術限制或明文規定的業務限制的公司, 才可以考量利用補償性控制來實現合規 要求編號和定義 : 所需資訊 解釋 1. 限制列出妨礙達到原始要求的限制 2. 目標定義原始控制的目標 ; 識別透過補償性控制達到的目標 3. 識別的風險識別由於缺少原始控制而引起的任何其他風險 4. 補償性控制的定義定義補償性控制, 並解釋其如何達到原始控制的目標及應對增加的風險 ( 如果有 ) 5. 補償性控制的驗證定義如何對補償性控制進行驗證和測試 6. 維護定義為維護補償性控制而制定的程序和控制措施 PCI DSS SAQ D,v2.0, 附錄 C: 補償性控制工作表版權所有 2010 PCI Security Standards Council LLC 2010 年 10 月第 34 頁

52 補償性控制工作表 完成的範例 對於勾選了 是 且在 特殊說明 欄中提到了補償性控制的任何要求, 可使用本工作表來定義其補償性控制 要求編號 : 8.1 在允許所有使用者存取系統元件或持卡人資料之前, 是否透過唯一的使用者名稱對其進行識別? 所需資訊 1. 限制列出妨礙達到原始要求的限制 2. 目標定義原始控制的目標 ; 識別透過補償性控制達到的目標 3. 識別的風險識別由於缺少原始控制而引起的任何其他風險 4. 補償性控制的定義定義補償性控制, 並解釋其如何達到原始控制的目標及應對增加的風險 ( 如果有 ) 5. 補償性控制的驗證定義如何對補償性控制進行驗證和測試 6. 維護 定義為維護補償性控制而制 定的程序和控制措施 解釋 公司 XYZ 使用了沒有 LDAP 的獨立 Unix 伺服器 因此, 每個人都需要 根 登入, 但公司 XYZ 不可能管理 根 登入, 也不可能記錄每位使用者的所有 根 活動 要求使用唯一登入的目標有兩個 首先, 從安全角度來看, 共用登入認證是不可接受的 其次, 如果使用共用的登入, 則無法明確指明要對某個特定動作負責的人是誰 由於不能確保所有使用者都有唯一 ID, 因此無法對使用者進行追蹤, 這樣便會使存取控制系統面臨更多風險 公司 XYZ 將要求所有使用者使用 SU 指令, 從各自的桌面登入伺服器 SU 不但可以讓使用者存取 根 帳戶並在 根 帳戶下執行動作, 還可以在 SU 記錄目錄中記錄使用者的動作 這樣, 便可透過 SU 帳戶來追蹤每個使用者的動作 公司 XYZ 向評估機構證明,SU 指令已在執行, 且已記錄利用該指令的個人, 以識別此人在根權限下執行動作 公司 XYZ 明文規定了相關流程和程序, 以確保不會發生以下情況 : 個別使用者為了在執行根指令時逃避追蹤或記錄而變更 修改或移除 SU 設定 PCI DSS SAQ D,v2.0, 附錄 C: 補償性控制工作表版權所有 2010 PCI Security Standards Council LLC 2010 年 10 月第 35 頁

53 附錄 D: 不適用性解釋 如果在 特殊說明 欄中輸入了 N/A 或 不適用, 則應使用本工作表來解釋相關要求為何不適用於您的組織 要求 範例 : 要求不適用的原因 不允許訪客進入處理或維護持卡人資料的區域 PCI DSS SAQ D,v2.0, 附錄 D: 不適用性解釋版權所有 2010 PCI Security Standards Council LLC 2010 年 10 月第 36 頁