金融事業(yè)部風(fēng)險與安全改進建議-安全部分

1、金融事業(yè)部支付風(fēng)險與安全改進建議金融事業(yè)部支付風(fēng)險與安全改進建議 2011年1月 主要內(nèi)容 改進建議制定思路 風(fēng)險與安全現(xiàn)狀分析 銀行支付安全模式分析 安全模型設(shè)計 2 基于現(xiàn)有風(fēng)險與安全管控現(xiàn)狀，結(jié)合銀行模式，提出改進建議 3 2012/01/062011/12/30 確定整體工作 思路及方法 制定整體計劃 確定資源需求 完成現(xiàn)有系統(tǒng) 及運營風(fēng)險和 安全機制分析 基于銀行支付安全 分析銀行采用的國際 國內(nèi)規(guī)范 分析銀行現(xiàn)有系統(tǒng)安 全措施 提出針對 的建議 基于銀行風(fēng)險機制 分析國際國內(nèi)風(fēng)險 規(guī)范 分析銀行現(xiàn)有風(fēng)險 措施 提出針對 的建議 方法 計劃 資源 PCI CUPSecure 網(wǎng)銀 E

2、MV ？ 電子商務(wù) BASEL AML 銀行應(yīng)用 系統(tǒng)現(xiàn)狀分析 運營現(xiàn)狀分析 確定綜合考核體系 確定風(fēng)險安全對象 確定對象的風(fēng)險安 全屬性 制定維護策略 風(fēng)險安全IT系統(tǒng)改 進建議 風(fēng)險安全內(nèi)部管 控改進建議 IT系統(tǒng)改進建議 1 準(zhǔn)備 2 現(xiàn)狀分析 4 風(fēng)險最佳實踐分析 3 安全模式對比 5 安全模型設(shè)計 6 風(fēng)險改進建議 現(xiàn)有系統(tǒng)風(fēng)險 和安全機制分 析 現(xiàn)有運營風(fēng)險 和安全機制分 析 2012/01/132012/01/20 策略 目標(biāo) 綜合 對象 屬性 維護 IT系統(tǒng)改進 內(nèi)部管控改進 優(yōu)先級 主要內(nèi)容 改進建議制定思路 風(fēng)險與安全現(xiàn)狀分析 銀行支付安全模式分析 安全模型設(shè)計 4 金融支

3、付相關(guān)的安全及風(fēng)險現(xiàn)狀已初成體系 5 領(lǐng)域領(lǐng)域現(xiàn)狀描述現(xiàn)狀描述 風(fēng)險管理 目前 風(fēng)險管理整體建設(shè)尚未開始，部分風(fēng)險管理功能已經(jīng)進行開展； 尚未建立統(tǒng)一的風(fēng)險管理部門或類似職能組織，部分風(fēng)險管理的職能分散在各業(yè)務(wù)部門之 中，目前在籌建風(fēng)險管理團隊； 沒有或較少設(shè)置專門進行風(fēng)險管理的崗位，沒有或較少專門從事風(fēng)險管理的人員； 沒有或較少制定風(fēng)險管理相關(guān)的制度和管理辦法； 沒有或較少制定風(fēng)險管理相關(guān)的管理流程，部分流程通過系統(tǒng)實施中進行了梳理和制定并 部署于系統(tǒng)之中； 在管理系統(tǒng)中開始實施風(fēng)險管理模塊，實現(xiàn)了少部分風(fēng)險管理的功能，如實名驗證、危險 人物名單等，有些業(yè)務(wù)需求因條件限制尚未得到實現(xiàn)，如交易

4、規(guī)則的監(jiān)控等； 整體上缺少風(fēng)險管理相關(guān)的文檔； 尚未建設(shè)風(fēng)險數(shù)據(jù)集市，目前所需數(shù)據(jù)直接從生產(chǎn)獲取，數(shù)據(jù)源比較分散； 尚未建立風(fēng)險監(jiān)控報表，已在規(guī)劃當(dāng)中； 安全管理 安全管理已開展，支持目前支付業(yè)務(wù)的運行； 安全管理很多功能均已系統(tǒng)化，在系統(tǒng)中實現(xiàn)了相關(guān)安全管理的流程，但缺乏安全管理的 相關(guān)制度及相關(guān)文檔； 在主機的安全管理上，按照Web、應(yīng)用和DB三類服務(wù)器制定了相應(yīng)權(quán)限的管理機制； 根據(jù)需求建立了銀行接入模塊，定義了銀行接口規(guī)范，一般采用證書加簽名方式保證支付 請求的安全； 金融支付相關(guān)的安全及風(fēng)險現(xiàn)狀已初成體系 6 領(lǐng)域領(lǐng)域現(xiàn)狀描述現(xiàn)狀描述 安全管理 在客戶系統(tǒng)的建立了客戶門戶模塊支持外部

5、客戶的訪問，其安全機制由網(wǎng)站提供證書、對 用戶權(quán)限進行控制和部分需用戶屬性（如手機激活等）進行控制； 在客戶系統(tǒng)的建立了管理門戶模塊支持內(nèi)部用戶的訪問，其安全機制由用戶權(quán)限進行控制； 在客戶系統(tǒng)的建立了開放平臺模塊支持其他系統(tǒng)的訪問，其安全機制簽名驗證和密鑰進行 控制； 網(wǎng)絡(luò)、主機和數(shù)據(jù)的管理及其安全工作由數(shù)據(jù)中心負(fù)責(zé)； 互聯(lián)網(wǎng)支付安全管理上，使用支付密碼，在交易時進行短信提醒，手機校驗碼網(wǎng)上支付， 正在進行安全控件招標(biāo)工作，手機支付模式和互聯(lián)網(wǎng)支付類似； 在雨花機房進行了數(shù)據(jù)同城災(zāi)難備份，但未做應(yīng)用備份，雨花機房主機通過服務(wù)器集群實 現(xiàn)非單點高可用； 辦公網(wǎng)絡(luò)和生產(chǎn)網(wǎng)絡(luò)尚未進行隔離，容易通過

6、辦公網(wǎng)絡(luò)訪問生產(chǎn)產(chǎn)生安全問題，如網(wǎng)上打 款等； 尚未實現(xiàn)應(yīng)用級的災(zāi)難備份； 主要內(nèi)容 改進建議制定思路 風(fēng)險與安全現(xiàn)狀分析 銀行支付安全模式分析 安全模型設(shè)計 7 銀行的支付安全模式是基于國際國內(nèi)規(guī)范的體系化成熟模型 8 PCI DSS支付安全規(guī)范研究 安全措施改進建議 可能建議 網(wǎng)絡(luò)設(shè)置 系統(tǒng)管理 帳戶管理 網(wǎng)上支付 密鑰管理 安全措 施對比 基于銀行支付安全框架分析，找到 可能借鑒的措施，為最終 的風(fēng)險安全模型及改進建議打基礎(chǔ)。 網(wǎng)銀安全規(guī)范研究 電子商務(wù)安全措施研究 EMV安全規(guī)范研究 CUPSecure安全規(guī)范研究 銀行密鑰體系研究 主要內(nèi)容 改進建議制定思路 風(fēng)險與安全現(xiàn)狀分析 銀行

7、支付安全模式分析 PCI DSS支付安全規(guī)范研究 CUPSecure安全規(guī)范研究 網(wǎng)銀安全規(guī)范研究 銀行密鑰體系研究 電子商務(wù)安全措施研究 EMV安全規(guī)范研究 安全模型設(shè)計 9 其中PCI DSS是國際公認(rèn)的卡支付安全規(guī)范，被銀行業(yè)廣泛應(yīng)用 10 PCI DSS（ Payment Card Industry Data Security Standard ）是是PCI SSC（Payment Card Industry Security Standards Council ）所制定的卡支付行業(yè)數(shù)據(jù)安全標(biāo)準(zhǔn)。所制定的卡支付行業(yè)數(shù)據(jù)安全標(biāo)準(zhǔn)。 l由由VISA、JCB、MASTERCARD、AMERI

8、CAN EXPRESS、DISCOVER FINANCIAL SERVICE 200606年設(shè)立的統(tǒng)一的支付卡行業(yè)信息安全標(biāo)準(zhǔn)委員會年設(shè)立的統(tǒng)一的支付卡行業(yè)信息安全標(biāo)準(zhǔn)委員會 lVISA 的的AIS（Account Information Security）PROGRAM發(fā)展而來發(fā)展而來 lVISA的支付卡數(shù)據(jù)保護最佳實踐：例如的支付卡數(shù)據(jù)保護最佳實踐：例如 VISA的的PABP (Payment Application Best Practices ) ， 20082008年被采納作為年被采納作為PA-DSS （Payment Application Data SECURITY STANDA

9、RD ），PA-DSS已經(jīng)代已經(jīng)代 替替PABP用于用于VISA的合規(guī)項目的合規(guī)項目 lPCI SSC有相關(guān)工作組負(fù)責(zé)各自領(lǐng)域的標(biāo)準(zhǔn)開發(fā)和體系維護技術(shù)工作：有相關(guān)工作組負(fù)責(zé)各自領(lǐng)域的標(biāo)準(zhǔn)開發(fā)和體系維護技術(shù)工作： DSS組、PED工工 作組、作組、 QSA（Qualified Security Assessors 合格的安全性評估機構(gòu)合格的安全性評估機構(gòu)）體系管理、體系管理、ASV（ Approved Scanning Vendors授權(quán)掃描廠商授權(quán)掃描廠商）體系管理體系管理、PA（Payment Application)體系管理體系管理 PCI DSS中規(guī)定了12項安全要求 11 高階概述高階

10、概述對比對比 初步建議初步建議 構(gòu)建并維護安全網(wǎng)絡(luò)構(gòu)建并維護安全網(wǎng)絡(luò) 要求1. 安裝防火墻配置并予以維護，以保護持卡人數(shù)據(jù)好加強正規(guī)流程，加強文檔工作 要求2. 系統(tǒng)密碼和其它安全參數(shù)不要使用供應(yīng)商提供的默認(rèn)設(shè)置很好 保護持卡人數(shù)據(jù)保護持卡人數(shù)據(jù) 要求3保護存儲的持卡人數(shù)據(jù)好在未來的設(shè)計中加強考慮，并建立機制 要求4在開放型的公共網(wǎng)絡(luò)中對持卡人數(shù)據(jù)進行加密傳輸很好 維護漏洞管理程序維護漏洞管理程序 要求5使用殺毒軟件并定期更新很好 要求6開發(fā)、維護安全系統(tǒng)和應(yīng)用程序很好 執(zhí)行嚴(yán)格的訪問控制措施執(zhí)行嚴(yán)格的訪問控制措施 要求7只有具備業(yè)務(wù)需求的人才能訪問持卡人數(shù)據(jù)好需要健全制度 要求8為每位擁有計

11、算機訪問權(quán)限的人分配唯一的ID好需要推廣單點登錄，建立機制 要求9限制對持卡人數(shù)據(jù)的物理訪問好加強對媒介的管理與保護 定期監(jiān)控和測試網(wǎng)絡(luò)定期監(jiān)控和測試網(wǎng)絡(luò) 要求10跟蹤和監(jiān)控訪問網(wǎng)絡(luò)資源和持卡人數(shù)據(jù)的所有操作差需要建立嚴(yán)格的機制 要求11定期測試安全系統(tǒng)和流程差需要建立正式的流程 維護信息安全政策維護信息安全政策 要求12維護針對信息安全的政策很差需要建立并逐步完善政策、機制 要求1：安裝并維護防火墻配置，以保護持卡人數(shù)據(jù)的詳細(xì)規(guī)定及分析 12 高階概述高階概述對比對比 1.1 建立包含以下各項的防火墻和路由器配置標(biāo)準(zhǔn)： 1.1.1 為批準(zhǔn)和測試所有網(wǎng)絡(luò)連接以及更改防火墻和路由器配置制定正 式

12、流程 沒有正式的流程，建議未來納入安全體系 1.1.2 提供當(dāng)前網(wǎng)絡(luò)架構(gòu)圖，必須包含所有與持卡人數(shù)據(jù)的連接，包括 所有無線網(wǎng)絡(luò) 符合要求 1.1.3 明確每個 Internet 連接處以及非軍事化區(qū)(DMZ) 與內(nèi)部網(wǎng)絡(luò)區(qū)域 之間的防火墻要求 正在進行相關(guān)工作 1.1.4說明網(wǎng)絡(luò)組件邏輯管理組、角色及其責(zé)任符合要求 1.1.5 書面說明允許的所有服務(wù)、協(xié)議和端口和業(yè)務(wù)原因，包括為那些 認(rèn)為不安全的協(xié)議實施的安全功能的文檔 缺乏書面文檔，建議未來補充 1.1.6 設(shè)置規(guī)則要求至少每 6 個月檢查一次防火墻和路由器目前3個月檢查一次，會清理冗余 1.2 設(shè)置防火墻規(guī)則，拒絕任何沒有受信的網(wǎng)絡(luò)或主機

13、接觸 持卡人數(shù)據(jù)和任何系統(tǒng)組件，只允許授權(quán)的協(xié)議通過 1.2.1 根據(jù)IP地址限制網(wǎng)絡(luò)必需的進出信息符合要求 1.2.2 保護并同步路由器配置文件符合要求 1.2.3 在任何無線網(wǎng)絡(luò)和持卡人數(shù)據(jù)環(huán)境之間安裝外圍防火墻，并且將 這些防火墻配置為禁止或控制（如果業(yè)務(wù)目的需要這樣的流量）從無 線環(huán)境流入持卡人數(shù)據(jù)環(huán)境的信息 符合要求 要求1：安裝并維護防火墻配置，以保護持卡人數(shù)據(jù)的詳細(xì)規(guī)定及分析（2） 13 高階概述高階概述對比對比 1.3 禁止通過 Internet 直接訪問系統(tǒng)組件和持卡人數(shù)據(jù)環(huán)境 1.3.1 實施 DMZ 以限制只允許持卡人數(shù)據(jù)環(huán)境需要的協(xié)議的進出信息正在實施 1.3.2 限制

14、進入 DMZ 內(nèi)部 IP 地址的Internet 信息正在實施 1.3.3 不允許 Internet 和持卡人數(shù)據(jù)環(huán)境之間進出信息的任何直接路由符合要求 1.3.4 不允許內(nèi)部地址從 Internet 至 DMZ 通過正在實施 1.3.5 限制從持卡人數(shù)據(jù)環(huán)境至 Internet的傳出信息只能訪問DMZ 內(nèi)部 的 IP 地址 正在實施 1.3.6 實施狀態(tài)檢測，也即動態(tài)包過濾（也就是只有通過“建立”的連 接才允許信息傳輸） 符合要求 1.3.7 在內(nèi)部網(wǎng)絡(luò)區(qū)域（從 DMZ 隔離開來的）中使用數(shù)據(jù)庫正在實施 1.3.8 實施 IP 偽裝以防止內(nèi)部地址被轉(zhuǎn)譯和發(fā)布到 Internet 上，使用 R

15、FC 1918 地址空間或者網(wǎng)絡(luò)地址轉(zhuǎn)譯 (NAT) 技術(shù)，例如端口地址轉(zhuǎn) 譯 (PAT)。 符合要求 1.4 通過至 Internet 的直接連接在任何移動和/或員工自有計 算機上（例如員工使用的筆記本電腦）安裝個人防火墻軟件， 然后才能用于訪問機構(gòu)網(wǎng)絡(luò)。 符合要求 要求2：系統(tǒng)密碼和其他安全參數(shù)不使用供應(yīng)商提供的默認(rèn)設(shè)置的詳細(xì)規(guī)定及分析 14 高階概述高階概述對比對比 2.1 在網(wǎng)絡(luò)上安裝系統(tǒng)以前，務(wù)必更改供應(yīng)商提供的默認(rèn)項 ，包括密碼、簡單網(wǎng)絡(luò)管理協(xié)議 (SNMP) 機構(gòu)字串，并刪除 不必要的賬戶。 2.1.1 對于連接到持卡人數(shù)據(jù)環(huán)境或傳輸持卡人數(shù)據(jù)的無線環(huán)境，更改 無線供應(yīng)商默認(rèn)項，

16、包括但不局限于默認(rèn)無線加密密鑰、密碼和 SNMP 機構(gòu)字串。確保無線設(shè)備安全設(shè)置已啟用，采用了嚴(yán)格的加密 技術(shù)進行認(rèn)證和傳輸 基本作到，需要仔細(xì)檢查現(xiàn)狀，未來需要納入體系要求 2.2 制定所有系統(tǒng)組件的配置標(biāo)準(zhǔn)，符合行業(yè)接受的系統(tǒng)安 全標(biāo)準(zhǔn)，并且確保安裝所有已知的安全漏洞補丁包 2.2.1 每臺服務(wù)器只執(zhí)行一項主要功能（Web Server，APP Server， DNS，DB Server） 符合要求 2.2.2 禁用所有不必要和不安全的服務(wù)和協(xié)議（來執(zhí)行設(shè)備特定功能的 不必要的服務(wù)和協(xié)議） 符合要求 2.2.3 配置系統(tǒng)安全參數(shù)以防止濫用符合要求 2.2.4 刪除所有不必要的功能，例如腳本

17、、驅(qū)動程序、屬性、子系統(tǒng)、 文件系統(tǒng)和不必要的 Web 服務(wù)器 符合要求 2.3 對所有非控制臺管理訪問進行加密。對于基于 Web 的管理和其他 非控制臺管理訪問使用諸如 SSH、VPN 或 SSL/TLS 等技術(shù) 符合要求 2.4 共享托管提供商必須保護每個機構(gòu)托管環(huán)境和持卡人數(shù)據(jù)。這些供 應(yīng)商必須滿足：針對共享托管提供商的額外 PCI DSS 要求中詳細(xì)規(guī)定 的具體要求 N/A 要求3：保護存儲持卡人的數(shù)據(jù)的詳細(xì)規(guī)定及分析 15 高階概述高階概述對比對比 3.1 使持卡人數(shù)據(jù)存儲最小化。制定數(shù)據(jù)保留和處理政策。 根據(jù)業(yè)務(wù)、法律和/或法規(guī)要求限制存儲的大小和保留時間， 在數(shù)據(jù)保留政策中進行記

18、錄。 在未來的設(shè)計中需要采納 3.2 不在授權(quán)后存儲敏感的驗證數(shù)據(jù)（即使已經(jīng)加密）。敏 感驗證數(shù)據(jù)包括下文要求 3.2.1 至 3.2.3 中列舉的數(shù)據(jù)： 3.2.1 不要存儲磁條任意磁道上的完整內(nèi)容（位于卡的背面、芯片上或 其他位置）。該數(shù)據(jù)也可稱為全磁道、磁道 1、磁道 2 和磁條數(shù)據(jù) 注：在正常的業(yè)務(wù)過程中，以下磁條數(shù)據(jù)元素可能需要保留： 持卡人姓名， 主賬戶 (PAN)， 失效期，以及 服務(wù)碼 為將風(fēng)險降至最低，只存儲業(yè)務(wù)所需的數(shù)據(jù)元素。 需要考慮此安全思想，但要結(jié)合業(yè)務(wù)實際設(shè)計 方案 3.2.2 不要存儲用于驗證離線交易的卡驗證代碼或值（印在支付卡正面 或背面的三或四位數(shù)字） 符合要

19、求 3.2.3 不要存儲個人識別碼 (PIN) 或經(jīng)加密的 PIN 數(shù)據(jù)塊。符合要求 3.3 顯示 PAN 時對其進行掩蓋（最多可顯示的數(shù)位包括前六 位與后四位）。 注：此要求不適用于那些因合法業(yè)務(wù)需要查看完整的 PAN 的員工和其 他方。此要求不取代顯示持卡人數(shù)據(jù)采用的更嚴(yán)格的要求，例如POS 收據(jù)。 符合要求 要求3：保護存儲持卡人的數(shù)據(jù)的詳細(xì)規(guī)定及分析 （2） 16 高階概述高階概述對比對比 3.4 通過以下方法盡量使 PAN 在存儲的地方不可讀（包括在 便攜式數(shù)字媒體、備份介質(zhì)、日志中）： 基于強效加密法的單向哈希 截詞 索引記號與索引簿（索引簿必須安全地存儲） 使用具有密鑰管理流程和

20、過程的強效加密法 注： 在賬戶信息中，最應(yīng)實現(xiàn)不可讀的就是 PAN。 如果因 為某些原因，公司不能使 PAN 不可讀，請參閱附錄 B：補 償性控制。 建議采用補償性控制 3.4.1 如使用了磁盤加密（而不是文件級或數(shù)據(jù)庫列級加密），則對邏 輯訪問的管理必須獨立于本地操作系統(tǒng)的訪問控制機制（例如，不使 用本地用戶賬戶數(shù)據(jù)庫）。解密密鑰決不能與用戶賬戶綁定。 未來設(shè)計中采納 3.5 保護加密持卡人數(shù)據(jù)以防泄露和盜用的加密密鑰： 3.5.1 將對加密密鑰的管理人數(shù)盡量減到最少。未來安全體系中采納 3.5.2 將加密密鑰以盡量少的形式安全存儲在盡量少的地方。符合要求 要求3：保護存儲持卡人的數(shù)據(jù)的詳細(xì)

21、規(guī)定及分析 （3） 17 高階概述高階概述對比對比 3.6 全面記錄并實施用于加密持卡人數(shù)據(jù)的加密密鑰采用的 所有密鑰管理流程和過程，包括以下各項： 3.6.1 強效加密法密鑰的生成符合要求 3.6.2 安全的加密法密鑰分發(fā)符合要求 3.6.3 安全的加密法密鑰存儲符合要求 3.6.4 定期更改加密密鑰 認(rèn)為有必要并且由相關(guān)應(yīng)用程序推薦（例如重新加密）；首選自動 至少每年一次 工作密鑰符合，其它需要在未來體系中考慮 3.6.5 棄用或更改舊的或疑似泄露的加密密鑰。需要建立相應(yīng)機制 3.6.6 加密密鑰雙重控制的分開保管和建立需要建立正規(guī)流程 3.6.7 防止加密密鑰的未授權(quán)更改符合要求 3.6

22、.8 要求密鑰保管人簽署聲明他們知道并接受密鑰保管責(zé)任的文件建議采納 要求4：在開放型的公共網(wǎng)絡(luò)中傳輸持卡人數(shù)據(jù)時會加密的詳細(xì)規(guī)定及分析 18 高階概述高階概述對比對比 4.1 使用強效加密法和安全協(xié)議（例如SSL/TLS 或 IPSEC） 以保護在開放型公共網(wǎng)絡(luò)中傳輸敏感持卡人數(shù)據(jù)的安全。 PCI DSS 范圍內(nèi)的開放型公共網(wǎng)絡(luò)示例如： Internet， 無線技術(shù)， 移動通信的全球系統(tǒng) (GSM) 和 通用無線分組業(yè)務(wù) (GPRS)。 符合要求 4.1.1 確保傳輸持卡人數(shù)據(jù)或連接到持卡人數(shù)據(jù)環(huán)境的無線網(wǎng)絡(luò)使用了 行業(yè)最優(yōu)方法（例如 IEEE 802.11i）對認(rèn)證和傳輸實施了強效加密。

23、對于新的無線實施，自 2009 年 3 月31 日起禁止實施 WEP。 對于當(dāng)前的無線實施，自 2010 年 6月 30 日起禁止使用 WEP。 符合要求 4.2 切勿使用終端用戶通訊技術(shù)（例如，電子郵件、即時通 訊工具、聊天工具等）發(fā)送未加密的 PAN。 將來安全體系中采納 要求5：使用并定期更新殺毒軟件或程序的詳細(xì)規(guī)定及分析 19 高階概述高階概述對比對比 5.1 在所有經(jīng)常受惡意軟件影響的系統(tǒng)上部署殺毒軟件（特 別是個人電腦和服務(wù)器上）。 符合要求 5.1.1 確保所有殺毒程序都能夠監(jiān)測、刪除并防止所有已知類型的惡意 軟件的攻擊。 符合要求 5.2 確保所有殺毒機制都是最新并且在運行，而

24、且能夠生成 審核日志。 符合要求 要求6：開發(fā)、維護安全系統(tǒng)和應(yīng)用程序的詳細(xì)規(guī)定及分析 20 高階概述高階概述對比對比 6.1 確保所有系統(tǒng)組件和軟件都安裝了最新的供應(yīng)商提供的 安全補丁。在發(fā)布的一個月以內(nèi)安裝關(guān)鍵的安全補丁。 要結(jié)合應(yīng)用進行補丁升級 6.2 建立一個流程來識別新發(fā)現(xiàn)的安全漏洞（例如，訂閱 Internet 免費的警告服務(wù)）。根據(jù) PCI DSS 要求 2.2 更新配 置標(biāo)準(zhǔn)，以解決新的漏洞問題。 正在實施 6.3 根據(jù) PCI DSS（例如，安全的認(rèn)證和登錄）并基于行業(yè) 最優(yōu)方法開發(fā)軟件應(yīng)用程序，并將信息安全融入到整個軟件 開發(fā)生命周期中。這些程序必須包括以下各項： 6.3.

25、1 部署前，對所有的安全補丁、系統(tǒng)與軟件配置的更改進行測試符合要求 6.3.2 分開開發(fā)/測試環(huán)境與生產(chǎn)環(huán)境符合要求 6.3.3 開發(fā)/測試環(huán)境與生產(chǎn)環(huán)境中的職責(zé)分離符合要求 6.3.4 在測試或開發(fā)過程中不使用生產(chǎn)數(shù)據(jù)（真實的 PAN）符合要求 6.3.5 在生產(chǎn)系統(tǒng)啟動前清除測試數(shù)據(jù)與賬戶符合要求 6.3.6 在激活應(yīng)用程序或發(fā)布給用戶以前，清除所有自定義應(yīng)用程序賬 戶、用戶ID 和密碼 符合要求 6.3.7 在發(fā)布生產(chǎn)以前檢查自定義代碼，以識別所有潛在的編碼漏洞符合要求 要求6：開發(fā)、維護安全系統(tǒng)和應(yīng)用程序的詳細(xì)規(guī)定及分析 （2） 21 高階概述高階概述對比對比 6.4 跟蹤對系統(tǒng)組件進

26、行的所有更改的更改控制流程。這些 程序必須包括以下項目： 6.4.1 影響記錄 符合要求 6.4.2 相關(guān)方管理層的簽發(fā) 建議將來采納 6.4.3 對操作功能的測試符合要求 6.4.4 取消流程符合要求 6.5 基于安全編碼指南開發(fā)所有 Web 應(yīng)用程序（內(nèi)部與外部 的，以及對應(yīng)用程序的Web 管理訪問)，例如開放式 Web 應(yīng) 用程序安全項目指南。涵蓋在軟件開發(fā)過程中對常見編碼漏 洞的防護，包括以下各項： 6.5.1 跨站腳本 (XSS)符合要求 6.5.2 注入攻擊，特別是 SQL 注入。同時還須考慮 LDAP、Xpath 及 其他注入攻擊。 符合要求 6.5.3 惡意文件執(zhí)行符合要求 6

27、.5.4 不安全的直接對象引用符合要求 6.5.5 跨站請求偽造 (CSRF)符合要求 6.5.6 信息泄露和不正確的錯誤處理符合要求 要求6：開發(fā)、維護安全系統(tǒng)和應(yīng)用程序的詳細(xì)規(guī)定及分析 （3） 22 高階概述高階概述對比對比 6.5.6 信息泄露和不正確的錯誤處理 設(shè)計要完善 6.5.7 失效的驗證和會話管理 符合要求 6.5.8 不安全加密存儲 符合要求 6.5.9 不安全通信符合要求 6.5.10 未能限制 URL 訪問 符合要求 6.6 對于面向公眾的 Web 應(yīng)用程序，經(jīng)常解決新的威脅和漏 洞，并確保保護這些應(yīng)用程序不受到以下任一方法的攻擊： 通過手動或自動應(yīng)用程序漏洞安全評估工具

28、或方法檢 查面向公眾的 Web 應(yīng)用程序，至少每年一次并在所有更改 后進行檢查。 在面向公眾的 Web 應(yīng)用程序前端安裝Web 應(yīng)用程序 防火墻 符合要求 要求7：限制為只有業(yè)務(wù)需要知道的人才能訪問持卡人數(shù)據(jù)的詳細(xì)規(guī)定及分析 23 高階概述高階概述對比對比 7.1 將對系統(tǒng)組件和持卡人數(shù)據(jù)的訪問限制為只有工作需要 訪問這些數(shù)據(jù)的人。訪問限制必須包括以下項目： 7.1.1 將特權(quán)用戶 ID 的訪問權(quán)限限制為執(zhí)行工作職責(zé)要求的最小權(quán)限未來采納此安全思想 7.1.2 根據(jù)個人工作劃分和職能分配權(quán)限符合要求 7.1.3 要求管理層簽署授權(quán)書以指明需要的權(quán)限未來納入安全體系 7.1.4 自動訪問控制系統(tǒng)

29、的實施符合要求 7.2 為多用戶系統(tǒng)組件建立訪問控制系統(tǒng)，根據(jù)用戶的數(shù)據(jù) 限制訪問權(quán)限。缺省設(shè)置為“禁止所有”，除非特別允許。 此訪問控制系統(tǒng)必須包含以下各項： 7.2.1 覆蓋所有的系統(tǒng)組件符合要求 7.2.2 根據(jù)工作劃分和職能給個人分配權(quán)限符合要求 7.2.3 默認(rèn)的“禁止所有”設(shè)置符合要求 要求8：為每位擁有計算機訪問權(quán)限的用戶分配唯一的 ID的詳細(xì)規(guī)定及分析 24 高階概述高階概述對比對比 8.1 在允許所有用戶訪問系統(tǒng)組件或持卡人數(shù)據(jù)之前為其分 配唯一的 ID。 部分符合要求，需要推廣現(xiàn)有的LDAP 8.2 除分配唯一的 ID 之外，至少采用以下一種方法驗證所有 用戶的身份： 密碼

30、或口令 雙因素驗證（例如令牌設(shè)備、智能卡、生物測定技術(shù) 或公共密鑰） 采用密碼 8.3 員工、管理員和第三方采用雙因素驗證以遠(yuǎn)程訪問（ 從 網(wǎng)絡(luò)外進行網(wǎng)絡(luò)級的訪問）網(wǎng)絡(luò)。使用遠(yuǎn)程撥入用戶認(rèn)證服 務(wù)(RADIUS)、帶有令牌的終端訪問控制器訪問控制系統(tǒng) (TACACS) 或帶有個人證書的 VPN（基于 SSL/TLS 或 IPSEC）等技術(shù)。 采用VPN 8.4 在所有系統(tǒng)組件上進行傳輸和存儲操作時，采用強效加 密術(shù)使所有密碼不可讀。 符合要求 8.5 確保在所有系統(tǒng)組件上都對非消費者用戶和管理員都采 用正確的用戶身份認(rèn)證和密碼管理，具體如下： 8.5.1 控制用戶 ID、憑據(jù)和其他識別對象的添

31、加、刪除和修改操作。符合要求 8.5.2 重置密碼前確定用戶身份。符合要求 8.5.3 為每位用戶的初始密碼設(shè)置唯一值，第一次使用后立即更改。符合要求 要求8：為每位擁有計算機訪問權(quán)限的用戶分配唯一的 ID的詳細(xì)規(guī)定及分析（2） 25 高階概述高階概述對比對比 8.5.4 立即撤銷任何已終止用戶的訪問權(quán)限。需要改進 8.5.5 至少每 90 天撤除/停用一次非活躍的用戶賬戶。符合要求 8.5.6 僅在所需時段啟用供應(yīng)商用于遠(yuǎn)程維護的賬戶。符合要求 8.5.7 向擁有訪問持卡人數(shù)據(jù)權(quán)限的所有用戶通報密碼程序和政策。需要改進 8.5.8 不要使用組、共享或常規(guī)賬戶和密碼。符合要求 8.5.9 至少

32、每 90 天更改一次用戶密碼。符合要求 8.5.10 密碼必 須至少有七個字符長。符合要求 8.5.11 使用包含數(shù)字和字母字符的密碼。符合要求 8.5.12 不允許個人提交和前四次使用過的任何密碼相同的新密碼。符合要求 8.5.13 用戶嘗試次數(shù)達到六次后鎖定該用戶 ID，以限制嘗試反復(fù)訪問 。 符合要求 8.5.14 將鎖定時長設(shè)置為至少 30 分鐘或直到管理員啟用用戶 ID 為止 。 符合要求 8.5.15 如果會話保持空閑狀態(tài)超過 15 分鐘，則需要用戶重新輸入密碼 以重新激活終端。 符合要求 8.5.16 驗證訪問任何數(shù)據(jù)庫（其中包括持卡人數(shù)據(jù)）的所有操作。這 包括應(yīng)用程序、管理員和

33、所有其他用戶的訪問操作。 需要改進 要求9：限制對持卡人數(shù)據(jù)的物理訪問的詳細(xì)規(guī)定及分析 26 高階概述高階概述對比對比 9.1 使用適當(dāng)?shù)臋C構(gòu)入口控制，以在持卡人數(shù)據(jù)環(huán)境中限制 和監(jiān)控系統(tǒng)的物理訪問。 9.1.1 使用攝像頭或其他訪問控制機制，以監(jiān)控個人對敏感區(qū)域的物理 訪問。檢查收集的數(shù)據(jù)并與其他入口相關(guān)聯(lián)。至少保存三個月，法律 另有規(guī)定的除外。 符合要求 9.1.2 限制對公共網(wǎng)絡(luò)插座交換機的物理訪問。符合要求 9.1.3 限制對無線訪問點、網(wǎng)關(guān)和手持式設(shè)備的物理訪問。符合要求 9.2 制訂相關(guān)程序，以幫助所有員工迅速識別雇員和訪客， 尤其是在可以查看持卡人數(shù)據(jù)的區(qū)域迅速識別雇員和訪客。

34、建議未來安全體系采納 9.3 確保遵循以下程序處理所有訪客： 9.3.1 進入處理或維護持卡人數(shù)據(jù)的區(qū)域之前，必須獲得授權(quán)符合要求 9.3.2 提供可以將訪客識別為非雇員而且使用后會過期的物理令牌（例 如工卡或訪問設(shè)備） 符合要求 9.3.3 要求訪客在離開機構(gòu)之前或在過期日交出物理令牌符合要求 9.4 使用訪客日志，以保持訪客活動的實體核查記錄。在日 志上記錄訪客姓名、所屬公司以及授權(quán)訪客進行物理訪問的 員工。將該日志至少保存三個月，法律另有規(guī)定的除外。 符合要求 9.5 將備份媒介存放在安全的地方，最好存放在機構(gòu)之外的 場所，例如其它場所或備用中心或商業(yè)性的存儲機構(gòu)。至少 每年檢查一次該場

35、所的安全性。 符合要求 要求9：限制對持卡人數(shù)據(jù)的物理訪問的詳細(xì)規(guī)定及分析(2) 27 高階概述高階概述對比對比 9.6 采用物理方式保護包含持卡人數(shù)據(jù)的所有紙質(zhì)媒介和電 子媒介。 需要改進 9.7 始終嚴(yán)格控制在內(nèi)部或外部分發(fā)任何類型的包含持卡人 數(shù)據(jù)的媒介，包括以下內(nèi)容： 9.7.1 將媒介分類，以便將其標(biāo)識為“機密”。目前不需要，未來采納 9.7.2 使用安全的快遞服務(wù)或其他可準(zhǔn)確跟蹤的傳送方式寄送媒介。目前不需要，未來采納 9.8 將任何和所有包含持卡人數(shù)據(jù)的媒介從安全區(qū)域轉(zhuǎn)移時 （尤其是當(dāng)媒介發(fā)放給個人時），務(wù)必確保管理層已同意。 需要改進 9.9 始終嚴(yán)格控制對媒介（其中包含持卡人

36、數(shù)據(jù)）的存儲和 訪問操作。 需要改進 9.9.1 正確保存所有媒介的盤存日志，媒介至少每年盤存一次。需要改進 9.10 包含持卡人數(shù)據(jù)的媒介由于業(yè)務(wù)原因或法律原因不再需 要時應(yīng)予以銷毀，具體如下： 9.10.1 對硬拷貝材料進行粉碎、焚燒或打漿，讓持卡人數(shù)據(jù)無法復(fù)原 。 需要改進 9.10.2 使電子媒介上的持卡人數(shù)據(jù)不可恢復(fù)，確保持卡人數(shù)據(jù)不可復(fù) 原。 需要改進 要求10：跟蹤和監(jiān)控訪問網(wǎng)絡(luò)資源和持卡人數(shù)據(jù)的所有操作的詳細(xì)規(guī)定及分析 28 高階概述高階概述對比對比 10.1 為每個個人用戶建立一個可連接訪問所有系統(tǒng)組件（尤 其是具有根權(quán)限等管理權(quán)限的訪問）的流程。 未來需要采納 10.2 針

37、對所有系統(tǒng)組件實施自動核查記錄，以重建以下事件 ： 10.2.1 對持卡人數(shù)據(jù)的所有個人訪問符合要求 10.2.2 具有根權(quán)限或管理權(quán)限的任何個人實施的所有操作符合要求 10.2.3 訪問所有核查記錄符合要求 10.2.4 無效的邏輯訪問嘗試符合要求 10.2.5 使用身份認(rèn)證和驗證機制符合要求 10.2.6 初始化核查日志符合要求 10.2.7 創(chuàng)建和刪除系統(tǒng)級對象符合要求 10.3 針對每個事件的所有系統(tǒng)組件至少記錄以下核查記錄條 目： 10.3.1 用戶身份認(rèn)證符合要求 10.3.2 事件類型符合要求 10.3.3 日期和時間符合要求 10.3.4 成功指示或失敗指示符合要求 10.3.

38、5 事件起源符合要求 10.3.6 受損數(shù)據(jù)、系統(tǒng)組件或資源的特征或名稱符合要求 要求10：跟蹤和監(jiān)控訪問網(wǎng)絡(luò)資源和持卡人數(shù)據(jù)的所有操作的詳細(xì)規(guī)定及分析(2) 29 高階概述高階概述對比對比 10.4 同步所有重要的系統(tǒng)時鐘和時間。 符合要求 10.5 保護核查記錄，以避免篡改。 10.5.1 僅限出于工作需要的人員查看核查記錄。需要改進 10.5.2 保護核查記錄文件，防止未經(jīng)授權(quán)的修改操作。需要改進 10.5.3 將核查記錄文件迅速備份到不易篡改的中心日志服務(wù)器或媒介 。 需要改進 10.5.4 將外部式技術(shù)的日志寫入外部 LAN上的日志服務(wù)器。需要改進 10.5.5 針對日志使用文件完整

39、性監(jiān)控軟件或更改檢測軟件，以確?，F(xiàn) 有的日志數(shù)據(jù)在不生成警報的情況下不會更改（盡管添加新數(shù)據(jù)不會 引發(fā)警報）。 需要改進 10.6 每天至少檢查一次所有系統(tǒng)組件的日志。日志檢查必須 包括檢查執(zhí)行入侵檢測系統(tǒng)(IDS) 和驗證、授權(quán)等安全功能 的服務(wù)器以及記賬協(xié)議 (AAA) 服務(wù)器（例如 RADIUS）。 需要改進 10.7 核查歷史記錄至少保留一年，至少可以立即準(zhǔn)備（例如 在線、已歸檔或從備份中恢復(fù)）三個月的歷史記錄以供分析 。 需要改進 要求11：定期測試安全系統(tǒng)和流程的詳細(xì)規(guī)定及分析 30 高階概述高階概述對比對比 11.1 至少每季度使用一次無線分析儀或部署可識別所有在用 無線設(shè)備的無

40、線 IDS/IPS，以測試無線訪問點是否存在。 需要改進 11.2 至少每季度以及在網(wǎng)絡(luò)有任何重大變動后（例如安裝新 的系統(tǒng)組件、更改網(wǎng)絡(luò)拓?fù)?、修改防火墻?guī)則、產(chǎn)品更新） 運行一次內(nèi)部和外部網(wǎng)絡(luò)漏洞掃描。 需要改進 11.3 外部和內(nèi)部穿透測試每年至少執(zhí)行一次，基礎(chǔ)架構(gòu)或應(yīng) 用程序有任何重大升級或修改后（例如操作系統(tǒng)升級、環(huán)境 中添加子網(wǎng)絡(luò)或環(huán)境中添加網(wǎng)絡(luò)服務(wù)器）也應(yīng)執(zhí)行。此類穿 透測試必須包括以下內(nèi)容： 11.3.1 網(wǎng)絡(luò)層穿透測試需要改進 11.3.2 應(yīng)用程序?qū)哟┩笢y試需要改進 11.4 使用入侵檢測系統(tǒng)和/或入侵防御系統(tǒng)，以監(jiān)控持卡人 數(shù)據(jù)環(huán)境中的所有流量并在發(fā)現(xiàn)可疑威脅時提醒員工。隨

41、時 更新所有入侵檢測引擎和入侵防御引擎。 需要改進 11.5 部署文件完整性監(jiān)控軟件，如發(fā)現(xiàn)未經(jīng)授權(quán)修改重要系 統(tǒng)文件、配置文件或內(nèi)容文件的操作將提醒員工；配置該軟 件，使其至少每周比較一次重要文件。 需要改進 要求12：維護針對雇員和承包商信息安全的政策的詳細(xì)規(guī)定及分析 31 高階概述高階概述對比對比 12.1 建立、發(fā)布、維護和散發(fā)可實現(xiàn)以下標(biāo)準(zhǔn)的安全政策： 12.1.1 處理所有 PCI DSS 要求。需要參考 12.1.2 包括可識別威脅和漏洞的年度流程并能生成正式的風(fēng)險評估。需要改進 12.1.3 包括至少每年執(zhí)行一次檢查并在環(huán)境變動時予以更新。需要改進 12.2 根據(jù)此規(guī)格中的要求

42、制訂每日操作安全程序（例如用戶 帳戶維護程序和日志查看程序）。 需要改進 12.3 針對面向員工的重要技術(shù)（例如遠(yuǎn)程訪問技術(shù)、無線技 術(shù)、可移動電子媒介、筆記本電腦、個人數(shù)據(jù)助理 (PDA)、 電子郵件使用和因特網(wǎng)使用）制訂使用政策，以定義所有雇 員和承包商正確使用這些技術(shù)的政策。確保此類使用政策要 求以下內(nèi)容： 12.3.1 管理層的明確許可需要改進 12.3.2 使用技術(shù)的授權(quán)需要改進 12.3.3 所有此類設(shè)備和獲得訪問權(quán)限的員工列表需要改進 12.3.4 給設(shè)備貼標(biāo)簽并注明所有者、聯(lián)系信息和用途需要改進 12.3.5 可接受的技術(shù)使用方式符合要求 12.3.6 可接受的技術(shù)網(wǎng)絡(luò)位置符合

43、要求 要求12：維護針對雇員和承包商信息安全的政策的詳細(xì)規(guī)定及分析（2） 32 高階概述高階概述對比對比 12.3.7 公司許可的產(chǎn)品列表需要改進 12.3.8 非活躍狀態(tài)達到特定時限后自動中斷遠(yuǎn)程訪問技術(shù)的會話需要改進 12.3.9 僅在供應(yīng)商需要時為其激活遠(yuǎn)程訪問技術(shù)，并在使用后立即停 用 需要改進 12.3.10 通過遠(yuǎn)程訪問技術(shù)訪問持卡人數(shù)據(jù)時，禁止將持卡人數(shù)據(jù)復(fù)制 、移動和存儲到本地硬盤和可移動電子媒介。 需要改進 12.4 確保安全政策和程序明確定義了所有雇員和承包商的信 息安全職責(zé)。 需要改進 12.5 針對個人或團隊分配以下信息安全管理職責(zé)： 需要改進 12.5.1 建立、記錄

44、和分配安全政策和程序。需要改進 12.5.2 監(jiān)控、分析安全警報和安全信息并將其分配給相關(guān)人員。需要改進 12.5.3 創(chuàng)建、記錄和分配安全事故響應(yīng)程序和逐層上報程序，以確保 及時有效地處理所有情況。 需要改進 12.5.4 管理用戶賬戶，包括添加、刪除和修改需要改進 12.5.5 監(jiān)控和控制所有的數(shù)據(jù)訪問操作。需要改進 12.6 實施正式的安全意識計劃，使所有雇員都能了解持卡人 數(shù)據(jù)安全的重要性。 12.6.1 雇員一經(jīng)雇用后立即培訓(xùn)，之后每年至少培訓(xùn)一次。需要改進 12.6.2 要求雇員每年至少確認(rèn)一次他們已閱讀并了解公司的安全政策 和程序。 需要改進 要求12：維護針對雇員和承包商信息安

45、全的政策的詳細(xì)規(guī)定及分析（3） 33 高階概述高階概述對比對比 12.7 雇用員工前篩選應(yīng)征者，以盡量減少內(nèi)部人員發(fā)起攻擊 的風(fēng)險。 需要改進 12.8 如持卡人數(shù)據(jù)與服務(wù)提供商共享，應(yīng)維護和實施管理服 務(wù)提供商的政策和程序，以包括以下各項： 12.8.1 保留服務(wù)提供商列表。需要改進 12.8.2 要求服務(wù)提供商出具書面協(xié)議，由其確認(rèn)對自己擁有的持卡人 數(shù)據(jù)的安全性負(fù)責(zé)，并保留此協(xié)議。 需要改進 12.8.3 確保已建立雇用服務(wù)提供商的流程（包括雇用前相應(yīng) 的盡職調(diào)查）。 需要改進 12.8.4 始終遵循計劃，以監(jiān)控服務(wù)提供商的 PCI DSS 遵從 性狀態(tài)。 需要改進 12.9 實施事故響

46、應(yīng)計劃。隨時準(zhǔn)備立即響應(yīng)系統(tǒng)漏洞事故。 需要改進 12.9.1 創(chuàng)建“事故響應(yīng)計劃”，以便在發(fā)現(xiàn)系統(tǒng)漏洞時實施。確保計 劃至少可以處理以下各項： 發(fā)生漏洞時的角色、職責(zé)和溝通策略以及聯(lián)系策略，至少包括通知支 付品牌； 特定的事故響應(yīng)程序；業(yè)務(wù)恢復(fù)和業(yè)務(wù)連續(xù)性程序； 數(shù)據(jù)備 份流程； 分析報告漏洞的法律要求；所有重要系統(tǒng)組件的范圍和響應(yīng) ； 來自支付品牌的參考或包涵事故響應(yīng)程序 需要改進 要求12：維護針對雇員和承包商信息安全的政策的詳細(xì)規(guī)定及分析（4） 34 高階概述高階概述對比對比 12.9.2 至少每年測試一次計劃。需要改進 12.9.3 指定一天 24 小時、一周 7 天隨時準(zhǔn)備響應(yīng)警報

47、的特定人員。需要改進 12.9.4 針對負(fù)責(zé)響應(yīng)安全漏洞的員工提供相應(yīng)培訓(xùn)。需要改進 12.9.5 包括來自于入侵檢測系統(tǒng)、入侵防御系統(tǒng)和文件完整性監(jiān)控系 統(tǒng)的警報。 需要改進 12.9.6 根據(jù)以往的經(jīng)驗教訓(xùn)、結(jié)合行業(yè)發(fā)展情況制訂有關(guān)修改和改進 事故響應(yīng)計劃的流程。 需要改進 主要內(nèi)容 改進建議制定思路 風(fēng)險與安全現(xiàn)狀分析 銀行支付安全模式分析 PCI DSS支付安全規(guī)范研究 CUPSecure安全規(guī)范研究 網(wǎng)銀安全規(guī)范研究 銀行密鑰體系研究 電子商務(wù)安全措施研究 EMV安全規(guī)范研究 安全模型設(shè)計 35 CUPSecure是銀聯(lián)制定的網(wǎng)上交易支付安全標(biāo)準(zhǔn) 36 中國銀聯(lián)中國銀聯(lián)CUPSecu

48、re：即網(wǎng)上安全控制系統(tǒng)，是中國銀聯(lián)電子支付驗證和授權(quán)方案，內(nèi)容覆蓋了持卡人驗證和 交易授權(quán)兩部分，是中國銀聯(lián)互聯(lián)網(wǎng)支付的核心，實現(xiàn)了人民幣卡在線進行安全支付驗證。 SC（Securtiy Control）：）：銀聯(lián)建立的安全信息輸入系統(tǒng)，是CUPSecure的主控系統(tǒng)。它相當(dāng)于交換系統(tǒng)的網(wǎng) 絡(luò)前置，負(fù)責(zé)互聯(lián)網(wǎng)持卡人認(rèn)證部分的消息傳遞。 API（Authentication Plug-in）：）：即CUPSecure系統(tǒng)中收單系統(tǒng)插件，由收單機構(gòu)負(fù)責(zé)與其收單系統(tǒng)進行整合 ，為收單系統(tǒng)與SC/SR之間的安全接口。 SA（Security Authentication）：）：持卡人安全認(rèn)證系統(tǒng)，等

49、同于3-D Secure中的ACS。 SR（Security Route）：）：路由確定，為CUPSecure的主控部分，負(fù)責(zé)CUPSecure的整個網(wǎng)上交易信息路由。 SI（Security Interactive）：）：即持卡人安全互動系統(tǒng)，由銀聯(lián)建立，負(fù)責(zé)為持卡人提供原有持卡人驗證之外的 輔助性安全服務(wù)。SI和發(fā)卡行對持卡人采取雙重認(rèn)證，任何一種認(rèn)證未通過都不能完成網(wǎng)上交易。 銀聯(lián)安全輸入模式：銀聯(lián)安全輸入模式：在銀聯(lián)安全輸入模式中，由安全信息輸入服務(wù)器負(fù)責(zé)提供安全便利的交互界面供持卡人輸入 安全信息。安全信息輸入成功后，相關(guān)支付信息由收單機構(gòu)隨聯(lián)機交易報文送CUPS，CUPS將加密后的

50、安全信 息填入相關(guān)報文域后，將報文轉(zhuǎn)發(fā)給發(fā)卡機構(gòu)，由發(fā)卡機構(gòu)認(rèn)證并完成相應(yīng)支付交易。 由于由于CUPSecure處理邏輯復(fù)雜，其基本原理可以通過處理邏輯復(fù)雜，其基本原理可以通過Visa 3DSecure說明說明 1 驗證注冊過程，即驗證持卡驗證注冊過程，即驗證持卡 人是否注冊了人是否注冊了3-D Secure服務(wù)服務(wù) 2 持卡人驗證過程，即通過持持卡人驗證過程，即通過持 卡人設(shè)定的驗證信息，驗證是卡人設(shè)定的驗證信息，驗證是 否是持卡人本人否是持卡人本人 3 交易授權(quán)過程，即通過支付交易授權(quán)過程，即通過支付 平臺產(chǎn)生的驗證信息，驗證交平臺產(chǎn)生的驗證信息，驗證交 易是否是合法交易易是否是合法交易

51、3D Secure（3 Domain Secure）由發(fā)卡域（）由發(fā)卡域（Issuer Domain）、收單域（）、收單域（ Acquirer Domain）和協(xié)作域（）和協(xié)作域（Interoperability Domain）三個域組成，）三個域組成， 通過三個域組件交互實現(xiàn)網(wǎng)上安全支付身份驗證和網(wǎng)上安全收單機制。通過三個域組件交互實現(xiàn)網(wǎng)上安全支付身份驗證和網(wǎng)上安全收單機制。 CUPSecure支付流程符合支付流程符合3DSecure的基本原理，并提供發(fā)卡機構(gòu)代理服務(wù)（的基本原理，并提供發(fā)卡機構(gòu)代理服務(wù)（SC模式，銀模式，銀 聯(lián)安全輸入模式）聯(lián)安全輸入模式） 國際卡組織3D Secure和中

52、國 銀聯(lián) CUPSecure為銀行卡安全 支付提供了統(tǒng)一的支付驗證與 授權(quán)方案 基于 的實際情況，不會照搬銀行的做法，但是可以參考銀行網(wǎng)上支付安全體系適 當(dāng)修正。 39 1 驗證注冊過程，即驗證持卡人是否注 冊了3-D Secure服務(wù) 2 持卡人驗證過程，即通過持卡人設(shè)定 的驗證信息，驗證是否是持卡人本人 3 交易授權(quán)過程，即通過支付平臺產(chǎn)生 的驗證信息，驗證交易是否是合法交易 銀行機制 銀聯(lián)IT SC/SA：獨立的安全注冊、認(rèn)證系統(tǒng) SR：獨立的交易路由系統(tǒng) SI：獨立的輔助安全認(rèn)證系統(tǒng) API：為商戶提供安全插件 CUPS：交易授權(quán)系統(tǒng) 目前 的易購平臺使用支持 易付寶、預(yù)付費卡、優(yōu)惠券

53、及銀行卡支付， 可以暫不考慮完全遵照CUPSecure規(guī)范。 可以借鑒注冊認(rèn)證、持卡人身份認(rèn)證和交易授權(quán)的概念，增加客戶協(xié)議、協(xié)客戶協(xié)議、協(xié) 議認(rèn)證議認(rèn)證等手段，以加強安全性。 考慮到 作為商戶代理銀行卡，可以考慮采用CUPSecure API，以增加免責(zé) 可以參考其身份認(rèn)證及授權(quán)系統(tǒng)分離的概念，以增加安全性。 主要內(nèi)容 改進建議制定思路 風(fēng)險與安全現(xiàn)狀分析 銀行支付安全模式分析 PCI DSS支付安全規(guī)范研究 CUPSecure安全規(guī)范研究 網(wǎng)銀安全規(guī)范研究 銀行密鑰體系研究 電子商務(wù)安全措施研究 EMV安全規(guī)范研究 安全模型設(shè)計 40 在多年的實踐過程中，網(wǎng)上銀行遇到了一些安全問題在多年的

54、實踐過程中，網(wǎng)上銀行遇到了一些安全問題 ，同時也采取了眾多的安全，同時也采取了眾多的安全 措施。措施。 1. 銀行交易系統(tǒng)被非法入侵。銀行交易系統(tǒng)被非法入侵。 2. 信息通過網(wǎng)絡(luò)傳輸時被竊取或篡改。信息通過網(wǎng)絡(luò)傳輸時被竊取或篡改。 3. 交易雙方的身份識別交易雙方的身份識別;賬戶被他人盜用。賬戶被他人盜用。 網(wǎng)銀問題網(wǎng)銀問題主要技術(shù)措施主要技術(shù)措施 1. 設(shè)立防火墻，隔離相關(guān)網(wǎng)絡(luò)設(shè)立防火墻，隔離相關(guān)網(wǎng)絡(luò) 一般采用多重防火墻方案。其作用為：一般采用多重防火墻方案。其作用為： (1) 分隔互聯(lián)網(wǎng)與交易服務(wù)器，防止互聯(lián)網(wǎng)用戶的非法入侵。分隔互聯(lián)網(wǎng)與交易服務(wù)器，防止互聯(lián)網(wǎng)用戶的非法入侵。 (2) 用于

55、交易服務(wù)器與銀行內(nèi)部網(wǎng)的分隔，有效保護銀行內(nèi)部網(wǎng)，同時防止內(nèi)部用于交易服務(wù)器與銀行內(nèi)部網(wǎng)的分隔，有效保護銀行內(nèi)部網(wǎng)，同時防止內(nèi)部 網(wǎng)對交易服務(wù)器的入侵。網(wǎng)對交易服務(wù)器的入侵。 2. 高安全級的高安全級的Web應(yīng)用服務(wù)器應(yīng)用服務(wù)器 服務(wù)器使用可信的專用操作系統(tǒng)，憑借其獨特的體系結(jié)構(gòu)和安全檢查，保證只有服務(wù)器使用可信的專用操作系統(tǒng)，憑借其獨特的體系結(jié)構(gòu)和安全檢查，保證只有 合法用戶的交易請求能通過特定的代理程序送至應(yīng)用服務(wù)器進行后續(xù)處理。合法用戶的交易請求能通過特定的代理程序送至應(yīng)用服務(wù)器進行后續(xù)處理。 3. 24小時實時安全監(jiān)控小時實時安全監(jiān)控 例如采用例如采用ISS網(wǎng)絡(luò)動態(tài)監(jiān)控產(chǎn)品，進行系統(tǒng)漏

56、洞掃描和實時入侵檢測。在網(wǎng)絡(luò)動態(tài)監(jiān)控產(chǎn)品，進行系統(tǒng)漏洞掃描和實時入侵檢測。在2000年年2 月月Yahoo等大網(wǎng)站遭到黑客入侵破壞時，使用等大網(wǎng)站遭到黑客入侵破壞時，使用ISS安全產(chǎn)品的網(wǎng)站均幸免于難。安全產(chǎn)品的網(wǎng)站均幸免于難。 網(wǎng)銀的安全重點在身份認(rèn)證和網(wǎng)絡(luò)傳輸。網(wǎng)銀的安全重點在身份認(rèn)證和網(wǎng)絡(luò)傳輸。 身份認(rèn)證身份認(rèn)證網(wǎng)絡(luò)傳輸網(wǎng)絡(luò)傳輸 在網(wǎng)上銀行系統(tǒng)中，用戶的身份認(rèn)證依靠基于在網(wǎng)上銀行系統(tǒng)中，用戶的身份認(rèn)證依靠基于“RSA公鑰密碼體制公鑰密碼體制”的加密的加密 機制、數(shù)字簽名機制和用戶登錄密碼的多重保證。銀行對用戶的數(shù)字簽名和登機制、數(shù)字簽名機制和用戶登錄密碼的多重保證。銀行對用戶的數(shù)字簽名和

57、登 錄密碼進行檢驗，全部通過后才能確認(rèn)該用戶的身份。用戶的惟一身份標(biāo)識就錄密碼進行檢驗，全部通過后才能確認(rèn)該用戶的身份。用戶的惟一身份標(biāo)識就 是銀行簽發(fā)的是銀行簽發(fā)的“數(shù)字證書數(shù)字證書”。用戶的登錄密碼以密文的方式進行傳輸，確保了。用戶的登錄密碼以密文的方式進行傳輸，確保了 身份認(rèn)證的安全可靠性。數(shù)字證書的引入，同時實現(xiàn)了用戶對銀行交易網(wǎng)站的身份認(rèn)證的安全可靠性。數(shù)字證書的引入，同時實現(xiàn)了用戶對銀行交易網(wǎng)站的 身份認(rèn)證，以保證訪問的是真實的銀行網(wǎng)站，另外還確保了客戶提交的交易指身份認(rèn)證，以保證訪問的是真實的銀行網(wǎng)站，另外還確保了客戶提交的交易指 令的不可否認(rèn)性。令的不可否認(rèn)性。 由于互聯(lián)網(wǎng)是一

58、個開放的網(wǎng)絡(luò)，客戶在網(wǎng)上傳輸?shù)拿舾行畔⒂捎诨ヂ?lián)網(wǎng)是一個開放的網(wǎng)絡(luò)，客戶在網(wǎng)上傳輸?shù)拿舾行畔?如密碼、交易指如密碼、交易指 令等令等)在通訊過程中存在被截獲、被破譯、被篡改的可能。為了防止此種情況在通訊過程中存在被截獲、被破譯、被篡改的可能。為了防止此種情況 發(fā)生，網(wǎng)上銀行系統(tǒng)一般都采用加密傳輸交易信息的措施，使用最廣泛的是發(fā)生，網(wǎng)上銀行系統(tǒng)一般都采用加密傳輸交易信息的措施，使用最廣泛的是 SSL數(shù)據(jù)加密協(xié)議數(shù)據(jù)加密協(xié)議。 SSL協(xié)議協(xié)議是由是由Netscape首先研制開發(fā)出來的，其首要目的是在兩個通信間提供秘密而可靠首先研制開發(fā)出來的，其首要目的是在兩個通信間提供秘密而可靠 的連接，目前大部分

59、的連接，目前大部分Web服務(wù)器和瀏覽器都支持此協(xié)議。用戶登錄并通過身份認(rèn)證之后服務(wù)器和瀏覽器都支持此協(xié)議。用戶登錄并通過身份認(rèn)證之后 ，用戶和服務(wù)方之間在網(wǎng)絡(luò)上傳輸?shù)乃袛?shù)據(jù)全部用會話密鑰加密，直到用戶退出系統(tǒng)，用戶和服務(wù)方之間在網(wǎng)絡(luò)上傳輸?shù)乃袛?shù)據(jù)全部用會話密鑰加密，直到用戶退出系統(tǒng) 為止。而且每次會話所使用的加密密鑰都是隨機產(chǎn)生的。這樣，攻擊者就不可能從網(wǎng)絡(luò)為止。而且每次會話所使用的加密密鑰都是隨機產(chǎn)生的。這樣，攻擊者就不可能從網(wǎng)絡(luò) 上的數(shù)據(jù)流中得到任何有用的信息。同時，引入了數(shù)字證書對傳輸數(shù)據(jù)進行簽名，一旦上的數(shù)據(jù)流中得到任何有用的信息。同時，引入了數(shù)字證書對傳輸數(shù)據(jù)進行簽名，一旦 數(shù)據(jù)

60、被篡改，則必然與數(shù)字簽名不符。數(shù)據(jù)被篡改，則必然與數(shù)字簽名不符。SSL協(xié)議的加密密鑰長度與其加密強度有直接關(guān)協(xié)議的加密密鑰長度與其加密強度有直接關(guān) 系，一般是系，一般是40128位，可在位，可在IE瀏覽器的瀏覽器的“幫助幫助”“”“關(guān)于關(guān)于”中查到。目前，建設(shè)銀行等已中查到。目前，建設(shè)銀行等已 經(jīng)采用有效密鑰長度經(jīng)采用有效密鑰長度128位的高強度加密。位的高強度加密。 人民銀行的網(wǎng)銀安全規(guī)范可以作為 的參考 安全技術(shù)規(guī)范安全管理規(guī)范業(yè)務(wù)運作安全規(guī)范 客戶端安全： -客戶端程序 -密碼保護 -登錄控制 組織機構(gòu)： -完善而獨立的團隊 -部門操作章程和職責(zé) -建立風(fēng)險管理架構(gòu) 業(yè)務(wù)申請及開通： -