【正文】 為因素等遭到破壞： 1)程序應該有處理的校驗機制 2)程序應該有相應的例外處理機制 3)對于有先后執(zhí)行順序的程序或程序模塊，內(nèi)部必須有執(zhí)行順序的限制機制 第253條 控制措施的選擇應根據(jù)應用的性質(zhì)和數(shù)據(jù)受損對業(yè)務造成的影響而定，可選擇的措施包括但不限于： 1)會話或批處理控制措施，在事務更新后協(xié)調(diào)相關數(shù)據(jù)文件的一致性 2)驗證系統(tǒng)生成數(shù)據(jù)的正確性 3)檢查數(shù)據(jù)完整性，特別是在計算機之間傳輸?shù)臄?shù)據(jù) 4)計算記錄和文件的哈希值以便驗證 5)確保程序以正確的順序運行，在出現(xiàn)故障時終止，在問題解決前暫停處理 消息驗證 第254條 對需要確保消息內(nèi)容完整性的應用（例如電子交易）應該使用消息驗證。 第255條 在采用消息驗證之前，應該通過安全風險評估，以確定其是否能滿足需要或采取其他更適合的解決方式。 數(shù)據(jù)輸出的驗證 第256條 應該使用檢查輸出數(shù)據(jù)合理性的機制。應該使用確保數(shù)據(jù)被全部處理的機制。 第257條 輸出的數(shù)據(jù)應該含有相關標志，以便判斷數(shù)據(jù)的狀態(tài)（例如是否準確、是否完整等）。必須對數(shù)據(jù)輸出驗證功能進行全面的測試，以保證其正確性和有效性。 第258條 系統(tǒng)在使用過程中，應該明確定義參與數(shù)據(jù)輸出各環(huán)節(jié)所有相關人員的職責。 加密控制 加密的使用管理辦法 第259條 敏感信息應該根據(jù)信息分類的要求采用加密措施進行保護。 第260條 加密措施的采用不但要考慮到信息存儲，也應該考慮到信息傳輸?shù)囊?。應該使用被公司認可的標準加密算法。 第261條 未經(jīng)安全管理委員會的同意，用戶不能安裝任何未經(jīng)授權的加密軟件。 第262條 加密算法應該根據(jù)算法強度和密鑰長度進行選擇，以符合信息保護的要求。 第263條 數(shù)字簽名的使用必須符合國家電子簽名法的相關規(guī)定。 密鑰管理 第264條 密鑰管理系統(tǒng)應該包括以下活動： 1)密鑰產(chǎn)生 2)密鑰變更 3)密鑰存儲 4)密鑰交換和分發(fā) 5)密鑰注銷 6)密鑰恢復和備份 7)密鑰銷毀 系統(tǒng)文件的安全 生產(chǎn)系統(tǒng)的應用軟件控制 第265條 生產(chǎn)系統(tǒng)的應用軟件更新必須由獲得授權的管理員來執(zhí)行。 第266條 嚴禁在生產(chǎn)系統(tǒng)中保留應用軟件的源代碼。必須建立程序庫統(tǒng)一保管和維護應用程序的可執(zhí)行代碼。 第267條 在測試成功、用戶驗收完成或相關的程序庫被更新前，嚴禁更新生產(chǎn)系統(tǒng)中的可執(zhí)行代碼。 第268條 必須對程序庫做好訪問控制，并對程序庫的更新進行日志記錄。 第269條 應用軟件必須做好版本控制管理，每一個版本都必須有相應的備份。源代碼的所有版本都必須保留，并標識版本號，每個版本之間的差異描述要文檔化。 測試數(shù)據(jù)的保護 第270條 測試系統(tǒng)應該參照生產(chǎn)系統(tǒng)的訪問控制規(guī)則進行訪問控制。 第271條 每次從生產(chǎn)系統(tǒng)中復制數(shù)據(jù)到測試系統(tǒng)中必須獲得授權，并做好記錄。從生產(chǎn)系統(tǒng)中復制的數(shù)據(jù)必須經(jīng)過處理，去掉有關財務和個人隱私的信息。 對程序源代碼庫的訪問控制 第272條 應該建立程序源代碼庫，并由指定人員進行統(tǒng)一管理。正在開發(fā)或修改的程序不應該保存在程序源代碼庫中。 第273條 更新程序源代碼庫和向程序員提供程序源代碼，應通過指定的程序源代碼庫管理員來執(zhí)行，并且獲得管理層的授權。程序源代碼必須保存在安全的環(huán)境中。 第274條 必須控制程序源代碼庫的訪問，只提供工作需要的最小權限。程序源代碼的訪問必須做好相關記錄。 第275條 程序源代碼必須做好版本控制管理，每一個版本都必須有相應的備份。 開發(fā)和維護過程中的安全 變更控制流程 第276條 所有應用軟件的變更必須獲得批準。 第277條 應用軟件的變更需求應該由業(yè)務部門授權的資深人員提出。應用軟件的變更不應破壞軟件本身的可靠性和已有的控制措施。 第278條 變更需求中應該包括對運行環(huán)境的要求（如硬件資源、軟件資源等）。 第279條 變更的設計方案必須通過正式的批準才能開始編碼。變更在部署之前必須通過驗收。 第280條 變更的部署必須盡量減少對業(yè)務正常運行的影響。 第281條 變更完成后，相關的文檔（如系統(tǒng)需求文檔、設計文檔、操作手冊、用戶手冊等）必須得到更新，舊的文檔必須進行備份。 第282條 必須維護所有軟件更新的版本控制。必須維護所有變更需求的記錄。 操作系統(tǒng)變更的技術檢查 第283條 操作系統(tǒng)變更之前必須進行評估，以確保應用程序的完整性和控制措施不會受到破壞。操作系統(tǒng)變更之前必須通知相關人員，以便他們有足夠的時間去做相關的評估。 第284條 操作系統(tǒng)變更之后必須對業(yè)務連續(xù)性計劃作相應修正。 商業(yè)軟件的修改限制 第285條 由廠家提供的商業(yè)軟件不應該被修改。如果需要修改商業(yè)軟件，必須評估下列影響： 1)軟件功能和內(nèi)部的控制措施是否會受到破壞 2)是否會導致廠家的升級包不能使用 3)原廠商對修改過的軟件是否不提供維護支持 第286條 在進行任何修改之前，必須得到廠家的允許，以保證不侵犯其知識產(chǎn)權。 信息泄漏 第287條 軟件的開發(fā)、采購和使用都應該受到控制和檢查，以防范可能的隱秘通道、邏輯炸彈、木馬等。以下幾點必須被考慮到： 1)只從信譽良好的廠家購買軟件 2)關鍵系統(tǒng)上的工作必須由值得信任的員工擔任 3)購買獲得國家有關機構認可的軟件 4)所有開發(fā)的代碼都必須進行安全檢查，確定無問題后才可以部署在生產(chǎn)環(huán)境。 第288條 所有源代碼應該進行恰當?shù)淖⑨?，以方便檢查。 軟件開發(fā)的外包 第289條 所有外包開發(fā)的軟件，必須簽定正式的合同，合同內(nèi)容包括但不限于： 1)確定軟件許可證的范圍和數(shù)量 2)明確代碼所有權和知識產(chǎn)權的歸屬 3)對代碼質(zhì)量的要求 4)有權對軟件開發(fā)過程進行審計 5)軟件維護要求 第290條 外包軟件在正式使用前，必須經(jīng)過病毒檢測和充分測試。對于提供源代碼的外包軟件，必須對源代碼進行充分的安全檢查。 技術漏洞管理 控制技術漏洞 第291條 根據(jù)漏洞的嚴重程度制定漏洞的風險等級評估標準和處理時間要求。 第292條 必須建立技術漏洞的監(jiān)控機制，及時發(fā)現(xiàn)漏洞，修補漏洞。定義公司員工在漏洞管理流程中的角色和職責。 第293條 補丁在安裝之前必須進行測試和評估，確保補丁不會影響系統(tǒng)的正常運行并可以正?；赝撕蟛拍馨惭b。如果補丁不能安裝，必須采取其他的控制措施，控制措施包括但不限于： 1)停止漏洞利用的相關服務或功能 2)增加訪問控制阻擋漏洞或縮小漏洞的來源 3)增加監(jiān)控和檢測機制 4)升級防病毒代碼庫到可以查殺利用漏洞的病毒的版本 5）重要系統(tǒng)必須優(yōu)先進行漏洞處理。 第294條 內(nèi)部開發(fā)的系統(tǒng)在發(fā)現(xiàn)漏洞后必須立即開發(fā)補丁程序，并在補丁發(fā)布前采取其他控制措施，避免漏洞被利用。12 信息安全事件的管理 報告信息安全事件和漏洞 信息安全事件報告 第295條 必須對員工明確說明需要報告的安全事件。員工有責任報告安全事件。 第296條 必須制定安全事件的分類、識別方法及建立相關的報告程序，以便安全事件得到及時的報告和處理。 第297條 員工一旦發(fā)現(xiàn)重要信息可能或正在遭受破壞，必須立即按照相關的報告程序向公司報告。如果可能的話，還應采取適當?shù)拇胧﹣肀O(jiān)控并保護這些重要信息。 第298條 當外界對公司發(fā)生的安全事件進行詢問和調(diào)查時，員工必須將這類請求轉(zhuǎn)交給公司的品牌宣傳部進行處理，嚴禁私自回應。 第299條 嚴禁員工私自對安全事件進行調(diào)查和利用公司環(huán)境對其進行研究試驗。 第300條 當安全事件發(fā)生時，應當成立安全事件調(diào)查組，并明確其職責；其成員應具備相應的處理技能。 第301條 安全管理代表應該維護事件報告數(shù)據(jù)庫，分析并確定事件發(fā)生的基本原因和應當采取的預防措施。 第302條 通過信息安全管理會議，安全管理委員會必須每季度對所有重大的安全事件報告進行復審。 信息安全漏洞報告 第303條 應該對員工明確說明需要報告的安全漏洞。員工有責任報告安全漏洞。 第304條 應該制定安全漏洞的分類、識別方法及建立相關的報告程序，以便安全漏洞得到及時的報告和處理。在技術符合性測試中發(fā)現(xiàn)的問題應被當作安全漏洞進行處理。 信息安全事件的管理和改進 職責和程序 第305條 必須建立信息安全事件處理程序，程序必須包括以下內(nèi)容： 1)角色定義和職責； 2)不同安全事件的處理方法及注意事項； 3)系統(tǒng)應急恢復措施； 4)審計追蹤和證據(jù)收集要求； 5)安全事件的補救措施和糾正預防措施。 第306條 信息安全事件處理程序必須能夠適應不同類型的信息安全事件。 第307條 參與信息安全事件處理的每位成員必須清楚他們的角色和職責。 第308條 當發(fā)現(xiàn)已經(jīng)產(chǎn)生嚴重影響或可能帶來嚴重影響的安全事件時，必須立即停止事件中直接受影響系統(tǒng)的服務。程序中必須定義每個處理環(huán)節(jié)的響應和處理時間要求，并在實際處理中嚴格執(zhí)行。 從安全事件中學習 第309條 必須對安全事件進行復審，并對事件的類型、影響程度和所帶來的損失等進行分析和監(jiān)控。 第310條 必須從已發(fā)生的事件和故障中總結經(jīng)驗，分析造成事件的根本原因，增強安全控制管理，避免問題的再次發(fā)生。 第311條 信息安全培訓應增加有關安全事件處理方面的內(nèi)容。 安全事件處理要求 第312條 證據(jù)的收集應該滿足法律法規(guī)的要求。 第313條 證據(jù)的收集應該尋求法律部門、安全專家和外部相關機構的建議和幫助。 13 業(yè)務連續(xù)性管理方面 業(yè)務連續(xù)性管理 業(yè)務連續(xù)性管理流程 第314條 業(yè)務連續(xù)性計劃的制訂必須有信息管理中心、業(yè)務部門和公司高層的參與。 第315條 必須對公司業(yè)務所面臨的風險進行評估，綜合考慮其可能性和影響。必須進行業(yè)務影響分析，識別業(yè)務的重要性和評估風險對業(yè)務帶來的影響。應根據(jù)業(yè)務影響分析的結果，制定符合公司業(yè)務目標的業(yè)務連續(xù)性計劃，并通過管理層的審批。業(yè)務連續(xù)性計劃必須經(jīng)過演練測試。 業(yè)務連續(xù)性及風險評估 第316條 業(yè)務影響分析應該在風險評估的基礎上進行。業(yè)務影響分析應該對直接損失進行量化，并且綜合評估公司聲譽的損失、法規(guī)的違反以及人員的傷亡等。 第317條 業(yè)務影響分析的結果報告必須提交管理層進行審批。 開發(fā)和實施包括信息安全的持續(xù)計劃 第318條 業(yè)務連續(xù)性計劃應該包括以下幾點： 1)識別關鍵業(yè)務流程及其從屬流程 2)流程恢復的優(yōu)先次序 3)所有的職責和緊急措施 4)恢復管理辦法 5)恢復流程 第319條 業(yè)務連續(xù)性計劃必須涵蓋所有關鍵業(yè)務流程，并且人員安全必須被優(yōu)先考慮。應說明計劃演練及修正的方式和時間安排。 第320條 每個計劃都應該有一個指定的總負責人，而且每個計劃應該清楚地說明其激活的條件以及執(zhí)行計劃中每個要素的負責人。 業(yè)務連續(xù)性計劃的測試、維護與再評估 第321條 業(yè)務連續(xù)性演練必須每年至少進行一次，由安全管理委員會指導進行。 第322條 必須為每項演練制定進度表，說明演練頻率、目的以及方法。應該維護演練的完整記錄，采取適當?shù)拇胧┙鉀Q遇到的問題并改進現(xiàn)有的流程。 第323條 計劃必須定期維護以確保其有效性，并指定人員負責維護，在出現(xiàn)下列情況時，必須對計劃進行在評估和更新： 1)法律的變化 2)員工和公司的變化 3)業(yè)務的變化 4)業(yè)務系統(tǒng)和運行環(huán)境的變化（如操作系統(tǒng)的升級） 5)第三方責任人的變化（如承包人、供應商） 6)地址或者聯(lián)系電話的變化 7)風險評估和業(yè)務影響分析的變化 8)地點、設備和資源的變化 第324條 計劃的更新必須通過正式的審批，最新的版本必須妥善保存，并分發(fā)給所有相關人員。 14 附則 第325條 本制度對公司信息安全管理工作的指導是基礎和根本性的，其它所有相關制度都應與本制度保持一致。 第326條 本制度由信息安全管理委員會負責解釋 第327條 本制度自印發(fā)之日起生效。