总体风险示范审计工作底稿_ 对数据和程序的访问
文档编号：ITDA_017
总体风险示范审计工作底稿_ 对数据和程序的访问
控制编号
控制领域
控制目标
测试步骤
测试结果
控制方式/类型
控制缺陷、异常情况
改进建议
审计证据
0501000
信息安全组织和安全管理
0501001
根据信息安全风险评估结果对信息安全职能方面进行职能划分和岗位设计。
对信息安全职能划分和岗位设计基于对信息完整性的风险评估。
1．访谈相关管理部门，了解如何对信息安全性进行风险评估，如何根据评估结果，建立信息系统安全管理部门和相关岗位。对于重要岗位人员的录用，如何进行背景调查。（提示：被审计单位管理部门针对上述问题所关注的主要风险点有哪些？这些风险是通过哪些控制手段和方法来进行规避的）
2．查看管理部门信息安全风险评估记录和结果和信息安全组织机构图和岗位职责描述，确认其中明确定义了部门和岗位的具体职责和报告路径。
1.通过2006年8月22日与安全部总经理刘建设的访谈，我们了解到
数据中心（上海）自2002年正式成立，根据7799安全体系规范在数据中心安全体系规范在数据中心下设了12个部门，包括总经理室、生产调度办公室、运行部、客户服务部、技术管理部、系统部、网络部、应用部、开放平台部、设备部、安全部、办公室，涵盖了信息管理、运行安全、数据安全、物理安全、网络安全管理等各个方面。我们查阅了非现场审计期间（2006年8月14－18日）数据中心（上海）统一提供的《组织结构图》和《各部门主要职责》，确认与访谈结果一致。
数据中心（上海）在2005年度进行了针对信息安全的风险评估，综合评定了数据中心（上海）现有的资产的风险评分，并根据各部门拥有的资产识别出各部门面临的主要风险。我们查看了非现场审计期间（2006年8月14－18日）数据中心（上海）统一提供的《中国工商银行数据中心（上海）风险评估报告》，确认其中提到各部门主要风险如附件所示。据刘建设介绍，针对其中的高风险领域，被评估部门编制了《不可接受风险处理计划》，加强了相关岗位控制来规避风险。我们查看了2006年8月24日安全部提供的《不可接受风险处理计划》，确认针对评估报告中提到存在的高风险领域，都注明了相关岗位需要增加的控制职责。详细内容请参见审计文档SH_ITGC_ATDP_03《中国工商银行数据中心（上海）风险评估报告》和SH_ITGC_ATDP_04《不可接受风险处理计划》。
通过查阅数据中心（上海）非现场审计期间（2006年8月14－18日）数据中心（上海）统一提供的《人力资源管理程序》，我们了解到数据中心（上海）要求对招聘的人员进行资格审查。通过2006年8月24日访谈人力资源部经理张旭，我们了解到数据中心上海有以下3种员工招聘方式：
招收应届大学毕业生：人力资源部主要招聘长期合作的重点高校应届毕业生，优先考虑学生干部和学生党员，同时参考学生家庭环境和经济能力，并从学校就业指导处了解学生有无重大过失。但对毕业生信用记录、道德素质和经济能力没有有效的检查方法。
工行系统内调动：中心人力资源部采信员工原工作部门人力资源组织提供的关于员工背景、工作业绩和思想素质资料，重点关注新员工的工作能力。
社会招聘：审计期间内没有进行社会招聘。
可以看出，数据中心（上海）现有员工招聘程序未对新员工信用记录、经济能力和道德素质进行有效、规范的背景调查，不足以合理规避员工的道德风险。我们在0101004中已经提出该例外事项。
2．通过查阅非现场审计期间（2006年8月14－18日）数据中心（上海）统一提供的《组织结构图》和《各部门主要职责》，我们了解到其中明确定义了部门的组织架构、职责划分和汇报路径。通过查阅2006年8月《岗位职责作业指导书》，我们确认了该指导书中详细说明了各个岗位的工作职责和技能要求。
未发现例外事项。
手动/预防型
SH_ITGC_ATDP_01
《组织结构图》
SH_ITGC_ATDP_02
《各部门主要职责》
SH_ITGC_ATDP_03
《中国工商银行数据中心（上海）风险评估报告》
SH_ITGC_ATDP_04
《不可接受风险处理计划》
SH_ITGC_ATDP_05
《岗位职责作业指导书》
0501002
规划信息安全职能时，是否考虑到职责分工？
规划信息安全职能时充分考虑到职责分工，需要独立的岗位或存在职责冲突的岗位应该由不同人员担任。
1. 访谈相关部门负责人，了解在进行岗位职责设计的时候，是否考虑上述职责分离因素。
2. 查看有关岗位职责说明、分工的制度，确认对职责进行了适当分离。
1．通过2006年8月22日访谈安全部总经理刘建设，我们了解到在进行岗位职责设计时，遵循《信息系统安全体系规范》，考虑职责分离的因素。我们查阅了非现场审计期间（2006年8月14－18日）数据中心（上海）统一提供的《信息系统安全体系规范》，确认其中考虑了适当的职责分离原则，明确规定“互斥、不兼容的职能角色必须分离”，包括“1) 生产操作人员必须与软件开发人员分离；2) 软件开发人员必须与测试人员分离；3) 生产操作人员必须与审查人员分离；4) 系统使用人员必须与系统维护人员分离；5) 授权人员与权限复核人员分离；6) 生产操作人员与交易业务人员分离。”
2.通过查看非现场审计期间（2006年8月14－18日）数据中心（上海）统一提供的《组织结构图》和《各部门主要职责》，我们了解到其中明确定义了数据中心（上海）的部门职责，对不兼容的职责进行了适当分离，符合ISACA要求的职责分离原则。详见下表。
未发现例外事项。
手动/预防型
SH_ITGC_ATDP_01
《组织结构图》
SH_ITGC_ATDP_02
《各部门主要职责》
0501003
是否考虑业务部门在信息安全中的作用。
在进行信息安全职能设计时，充分考虑业务部门数据所有者在信息安全中的作用。
1．查看相关管理制度，确认制度上规定由业务部门负责审批访问、修改业务数据的权限。
2．具体控制的测试，请参见“业务数据安全”（0504000）和“应用系统安全”（0503000）等部分。
1.通过2006年8月22日与安全部总经理刘建设的访谈，我们了解到访问、修改业务数据的需求必须由业务部门审批，数据中心（上海）负责具体实施。我们查看了非现场审计期间（2006年8月14－18日）数据中心（上海）统一提供的《事件管理办法服务请求事件实施细则》，发现其中明确规定了业务部门对访问、修改业务数据的审批权限，具体而言在“第六章服务请求事件申请”中明确提出了“各相关业务部门负责对下属业务部门提交的变更申请进行审批”。
2. 具体控制的测试，请参见“业务数据安全”（0504000）和“应用系统安全”（0503000）等部分。
未发现例外事项。
手动/预防型
SH_ITGC_ATDP_06
《事件管理办法服务请求事件实施细则》
0502000
安全制度和程序
0502001
为达到信息安全性的目标，是否制定了一系列安全制度和工作程序？
有详细、完整的安全制度和程序，规范安全方面的控制，确保银行的信息安全。
1．访谈相关部门负责人，了解有哪些安全制度和程序。
2．查看相关制度，如《中国工商银行信息系统运行管理制度》及其他安全制度制度、细则，确保其涵盖了上述信息安全的各个方面。
1.通过2006年8月22日访谈安全部总经理刘建设，我们了解到总行颁布了《中国工商银行信息系统运行管理制度》；数据中心（上海）根据总行颁布的《中国工商银行信息系统运行管理制度》，结合数据中心自身特点，细化制度，制定管理程序和作业指导书确保信息安全性。具体的制度名称和内容见2。
2．我们查看了以下的规则制度，确认这些制度涵盖了操作系统安全、应用系统安全、数据安全、网络安全、物理安全、运行安全等各个方面。这些资料的提供时间和提供方式见附件。
1) 针对操作系统安全：
我们查看了总行颁布的《中国工商银行信息系统运行管理制度》，其中包含《安全管理办法计算机安全漏洞扫描实施细则》、《配置管理办法实施细则》、《安全管理办法主机用户管理实施细则》以及《安全管理办法网络与开放平台用户管理实施细则》，确认其中对主机和开放平台的用户管理、系统性能、参数设置等进行了界定。
我们查看了数据中心（上海）颁布的《开放平台服务器用户管理程序》、《生产系统开放平台服务器用户管理办法》、《开放平台生产系统UNIX安全规范》、《主机用户安全管理程序》以及《生产环境变更管理程序》，确认这些制度细化了数据中心（上海）管理的系统的用户管理流程、参数配置原则等。
2) 针对应用系统安全：系统应用层面的管理职能集中在各个分行层面；对于应用系统安全，数据中心（上海）只涉及到程序上线部分。
我们查看了总行颁布的《中国工商银行信息系统运行管理制度》之《变更管理办法生产变更实施细则》，确认涵盖了变更上线的处理原则和流程。
我们查看了数据中心（上海）《变更管理办法生产变更实施细则》，确认该制度涵盖了应用系统变更上线的申请审批细则。
3) 针对数据安全：
我们查看了总行颁布的《中国工商银行信息系统运行管理制度》之《安全管理办法机密资源管理实施细则》和《数据管理办法实施细则》，确认其中对数据机密性和数据管理原则、流程进行了界定。
我们查看了数据中心（上海）颁布的《数据安全管理程序》、《业务数据变更程序》、《性能分析程序》、《主机数据备份作业指导书》和《开放平台数据备份作业指导书》，确认这些制度细化了数据变更、备份等的申请审批流程。
4) 针对网络安全：
我们查看了总行颁布的《中国工商银行信息系统运行管理制度》之《安全管理办法网络非法外联监测实施细则》和《安全管理办法网络入侵检测实施细则》，确认对网络设计原则、网络参数设置、网络安全管理、网络入侵检测进行了规定。
我们查看了数据中心（上海）颁布的《非法内网外联管理作业指导书》、《防火墙管理作业指导书》、《防病毒管理程序》、《网络安全管理程序》和《网络用户管理作业指导书》，确认这些制度对网络安全管理、网络入侵检测、网络用户管理进行了规范。
5) 针对物理安全：
我们查看了总行颁布的《中国工商银行信息系统运行管理制度》之《安全管理办法外来人员管理实施细则》、《园区管理办法消防管理实施细则》、《园区管理办法治安保卫管理实施细则》、《机房管理办法实施细则》和《总行及各直属科技机构外部技术资源使用管理实施细则》，确认这些制度对人员管理、治安保卫、安全消防和机房管理制定了规定。
我们查看了数据中心（上海）颁布的《机房安全管理程序》、《机密部件管理程序》、《门禁卡管理程序》、《商密部件管理程序》、《外来人员安全管理程序》、《消防管理程序》和《园区安全管理程序》，对于数据中心（上海）的园区、机房、商密部件的管理规则进行了详细说明。
6) 针对运行安全：请参见0201001
未发现例外事项。
手动/预防型
SH_ITGC_ATDP_07
《中国工商银行信息系统运行管理制度》
SH_ITGC_ATDP_08
《开放平台服务器用户管理程序》
SH_ITGC_ATDP_09
《生产系统开放平台服务器用户管理办法》
SH_ITGC_ATDP_10
《开放平台生产系统UNIX安全规范》
SH_ITGC_ATDP_11
《主机用户安全管理程序》
SH_ITGC_ATDP_12
《生产环境变更管理程序》
SH_ITGC_ATDP_13
《变更管理办法生产变更实施细则》
SH_ITGC_ATDP_14
《数据安全管理程序》
SH_ITGC_ATDP_15
《业务数据变更程序》
SH_ITGC_ATDP_16
《性能分析程序》
SH_ITGC_ATDP_17
《主机数据备份作业指导书》
SH_ITGC_ATDP_18
《开放平台数据备份作业指导书》
SH_ITGC_ATDP_19
《非法内网外联管理作业指导书》
SH_ITGC_ATDP_20
《防火墙管理作业指导书》
SH_ITGC_ATDP_21
《防病毒管理程序》
SH_ITGC_ATDP_22
《网络安全管理程序》
SH_ITGC_ATDP_23
《网络用户管理作业指导书》
SH_ITGC_ATDP_24
《机房安全管理程序》
SH_ITGC_ATDP_25
《机密部件管理程序》
SH_ITGC_ATDP_26
《门禁卡管理程序》
SH_ITGC_ATDP_27
《商密部件管理程序》
SH_ITGC_ATDP_28
《外来人员安全管理程序》
SH_ITGC_ATDP_29
《消防管理程序》
SH_ITGC_ATDP_30
《园区安全管理程序》
0502002
针对安全制度和工作规范的定期更新、完善建立了哪些流程？
安全制度和程序根据业务上和技术上的发展，及时更新。
1．访谈相关部门负责人，了解安全制度和程序的更新方式、更新流程和更新频率。(同时查看相应的制度更新流程和管理办法，了解变更的频率要求等内容)
2．抽样检查各项安全制度和程序的更新记录，检查其是否符合管理部门的要求。
1.通过2006年8月22日访谈安全部总经理刘建设、9月1日访谈办公室副主任葛翠凤，我们了解到
1) 总行颁布的制度：总行信息科技部每年进行必要的更新，并且通过正式的公文下发。
2) 数据中心（上海）内部制定管理：
公文的审批：数据中心（上海）内部制定了《公文处理程序》、《ISO文件控制程序》和印发了《关于进一步规范文件报批流程的通知》，我们查阅了以上资料（办公室2006年9月1日提供），确认其中对中心公文的报批流程进行了规定，要求中心各部室制定的新的规章制度经数据中心（上海）总经理审批后由办公室统一发文执行。
公文的更新：
对于中心的行政管理制度（包括人事管理、财务管理、党务工作、工会工作等内容）由办公室每年进行检查，确保进行必要的更新。我们查看《关于上报我中心梳理整合后规章制度的函》（工银数沪函2005－24号）(办公室2006年9月1日提供），确认办公室在2005年6月对制度进行了必要的梳理更新。
对于具体的安全管理制度统一遵照《ISO文件控制程序》的规定，我们查看了该规定（办公室2006年9月1日提供），发现制度规定 “各文件使用部门发现实际情况发生变化，与文件规定不符时，应及时向文件编制部门提出申请修改相关ISO文件；每年的内审和外审检查发现需要修改ISO文件的，应在纠正预防报告规定的关闭时间内完成”。对于0502001中涉及的相关制度的抽样请参见2。
2. 我们查看了0502001中涉及的所有安全制度和工作规范，确认
在审计期间内，总行的制度进行了更新，我们查看了更新下发记录，确认更新后的制度通过公文形式下发给了相关科室。
我们查看了数据中心（上海）2006年8月24日提供的“制度更新的下发记录”，确认这些制度进行了更新，并在更新后都通过邮件、公文的形式下发给了相关科室。详细抽样结果见下表。
未发现例外事项。
手动/预防型
SH_ITGC_ATDP_31
制度更新下发记录
0502003
对信息技术部门和业务部门人员制定相关的信息安全培训制度？
制定正式的信息安全培训制度，对信息技术部门和业务部门相关人员进行培训。
1．访谈相关部门负责人，了解通过何种途径，将安全制度和流程下发给各个相关部室和员工，并对相关人员进行信息安全方面的培训。
2．抽样相关培训记录和制度下发记录，如：网站公告、电子邮件等。
3．抽样访谈科技部门员工是否了解相关安全制度和流程。
1.通过2006年8月22日访谈安全部总经理刘建设，我们了解到
1) 对于总行制定的制度：总行信息科技部统一通过公文系统下发给数据中心（上海）办公室下的文秘室，由文秘室下发给相关部室；并要求各部门学习。
2) 对于数据中心（上海）制定的制度：数据中心通过notes邮件下发中心各部室，供各部室学习。
2. 通过2006年8月22日与安全部总经理刘建设的访谈，我们了解到
更新后的制度通过邮件、公文的形式下发给相关科室。我们查看了0502001中提到的所有制度的更新记录，以及更新后的下发邮件，确认更新后的制度都及时发给了相关部门学习。具体抽样请参见0502002中的附件。
数据中心（上海）建立了“ISO9000标准化质量管理体系”notes园地和“数据中心（上海）门户网站”。我们于2006年8月24日现场查看了存放在数据中心（上海）的“ISO9000标准化质量管理体系”notes园地和“数据中心（上海）门户网站”的“规章制度”栏目（内容包括技术管理、行政管理、人事管理、财务管理、安全保卫、党务工作、工会工作）中的规章制度，确认了数据中心通过以上措施发布制度供中心员工查阅学习。
3. 我们于2006年8月22日－25日访谈了安全部总经理刘建设、开放平台部鲍玲、系统部李伟杰和网络部孔兵，确认他们都了解以上的安全制度和流程。
未发现例外事项。
手动/预防型
SH_ITGC_ATDP_31
制度更新下发记录
0502004
同上
同上
1．访谈相关部门负责人，了解对员工进行了哪些安全方面的培训，培训频率如何，培训覆盖了哪些员工。在17799的 中提到了培训的相关要求和内容。
2．抽样查看培训记录。
1. 通过2006年8月22日与安全部总经理刘建设的访谈，我们了解到
1) 数据中心（上海）每年举行安全专项培训，由安全管理部和各部门经理以上级别的人员参与。
2）对于新进员工，数据中心会统一组织集中培训，帮助他们了解安全相关的制度规范。
2. 我们查阅了2006年8月28日数据中心（上海）办公室提供的 “中心培训完成情况统计表”，了解到在2005年6月1日至2006年6月30日期间数据中心（上海）各部门的管理干部和工作人员共参加总行、中心内部和IBM、CISCO等服务商提供的74次培训，内容包括制度学习、生产管理和技术培训等。其中
1）由安全管理部和各部门经理以上级别的人员参与的安全培训共66次。
2）对新进员工的集中安全培训共8次。
详情请参见SH_ITGC_ATDP_32中心培训完成情况统计表。
未发现例外事项。
手动/预防型
SH_ITGC_ATDP_32
中心培训完成情况统计表
0504000
业务数据安全管理
0504001
制定了哪些相关制度来限制对数据库直接进行访问。
直接访问数据的权限和流程控制严格，数据安全得到有效保护。
1．访谈相关部门负责人，并查看相关制度如《中国工商银行系统运行管理制度》及数据管理办法、变更管理办法及其他实施细则等，了解对直接访问数据进行了怎样的规定。
2．检查被审计单位制定的规定和流程是否与运行管理制度中对数据安全管理的要求是否一致。
1．通过2006年8月23-25日与系统部DB2安全管理员张勤和开放平台部数据库管理员鲍玲，我们了解到存在严格的制度规定直接访问修改数据流程：
总行统一颁布了的《中国工商银行系统运行管理制度》之《变更管理办法生产变更实施细则》和《事件管理办法服务请求事件实施细则》，对直接访问、修改生产数据的申请、审批流程进行了规定。
根据总行颁布的以上制度，数据中心（上海）颁布了相应的实施细则《业务数据变更程序》和《生产环境变更管理程序》。
在0502002已经提到，我们获取并查看了这些制度，了解到变更分为业务类变更（包括直接修改数据、下载查询数据等）和技术类变更（包括网络变更、数据库参数变更、系统参数变更、数据库层面和操作系统层面的用户及权限变更），都遵循生产变更的流程。具体步骤如下：
变更提出：变更申请部门根据变更类别分别填写相应的变更申请表，内容包括请求名称、请求内容、请求原因等要素，要求填写规范、详实。数据类变更填写《业务请求申请表》，其他变更填写《技术变更申请表》。如附件所示。
EMBED \s
变更审批：数据类变更由业务部门领导进行审批，技术类变更由相关管理部门（软件开发中心、总行信息科技部等）进行审批。
变更受理：审批后服务请求被提交给受理部门。需要在后台进行变更的情况下，受理部门为数据中心（上海）和数据中心（北京）；对于前台就可以进行的变更，受理部门也可以是各分行。变更受理部门7×24小时统一通过Helpdesk系统受理各类请求申请。
变更处理：数据中心客户服务部在Helpdesk上按照受理需求的类别，选择具体的受理部门。Helpdesk自动将申请发送到受理部门的审批领导信箱以及安全部信箱；在受理部门的领导和安全部审批后，该申请才能自动转入实施人员的信箱，由实施人员领用相应权限的ID实施变更。
变更反馈：变更处理完成后，受理部门要将处理结果反馈申请部门，申请部门确认处理结果，在Helpdesk上反馈确认意见。
具体的审批权限规定见《变更管理办法生产变更实施细则》和《事件管理办法服务请求事件实施细则》。
2．我们查阅了数据中心（上海）在非现场审计期间（2006年8月14－19日）提供的《数据安全管理程序》，确认该制度是根据总行统一颁布《中国工商银行系统运行管理制度》（总行2006年2月下发给中国工商银行IT内审）编订的具体实施细则，两者对数据安全的要求是一致的。
未发现例外事项。
手动/预防型
SH_ITGC_ATDP_07
《中国工商银行系统运行管理制度》
SH_ITGC_ATDP_15
《业务数据变更程序》
SH_ITGC_ATDP_12
《生产环境变更管理程序》
0504002
是否严格控制对数据库的直接访问。
对直接访问数据库进行控制确保满足信息安全性的总体目标。
1．访谈相关部门负责人，了解直接访问、修改生产数据的申请、审批流程。
2．查看数据库日志，按照抽样原则，从中抽取X个直接在数据库中修改数据的记录，并追溯至原始的申请表，检查申请、审批程序是否符合相关管理规定。
主机平台
1. 通过2006年8月23-25日与系统部DB2安全管理员张勤的访谈，我们了解到
在DB2数据库中，数据变更主要通过批量提交作业的方式进行；对于VSAM文件的数据变更，或者对DB2数据进行紧急变更时，则通过特殊工具进行变更。
无论是通过批量提交作业方式进行，还是使用特殊工具，申请审批流程都遵循生产变更的流程（生产变更流程详见0504001中第1点）。
2. 2006年8月29－30日我们对数据变更进行了抽样测试，如下：
使用批量提交作业方式的数据变更：我们于2006年8月29日查看了个人金融系统从2005年6月1日到2006年6月30日的使用批量作业方式提交的数据变更日志，发现共记录了直接访问、修改数据活动超过200次。根据抽样原则，我们共抽取了20个样本，追溯到原始的申请表格，确认这些变更都经过了业务部门和数据中心（上海）的牵头实施部门的审批授权，符合管理规定的要求。详细测试情况见下表。
使用特殊工具的数据变更：特殊工具的使用流程和抽样请参见0504006和0506007
开放平台
1. 通过2006年8月23－25日与开放平台部数据库管理员鲍玲的访谈，我们了解到在开放平台上，数据变更都是通过直接在数据库层面更改数据的方式进行，数据变更遵循生产变更的流程（生产变更流程详见0504001中第1点）。
2. 如0504008中提到的，开放平台上不存在这样的日志。我们与开放平台部数据库管理员鲍玲口头确认了，开放平台上进行的数据变更都在Helpdesk上进行记录，没有日志用于查看和分析所有的数据变更，也没有有效的方法发现未在Helpdesk上进行申请审批的非法数据修改。
发现例外事项。由于开放平台上没有相应的审计日志可用来查看和分析全部的数据变更，导致无法对开放平台的数据变更实施监控策略。
因此，我们无法从日志中进行抽样。作为替代性抽样，我们对Helpdesk上记录的开放平台数据变更进行了抽样。我们在Help desk上查阅了2005年6月1日至2006年6月30日间Helpdesk上记录的开放平台数据变更，共1585笔，每日发生超过一次。按照抽样原则，我们抽取了20笔，确认这些变更都经过了业务部门和数据中心（上海）的牵头实施部门的审批授权，符合管理规定的要求。详细测试情况见下表。
未发现例外事项。
手动/预防型
由于开放平台上没有相应的审计日志可用来查看和分析全部的数据变更，导致无法对开放平台的数据变更实施监控策略。
我们建议管理层应根据风险的高低，划分资源种类和定义敏感资源，确定安全部检查的重点、检查方法和审计周期。
并且结合实际情况进行分析，考虑采用自动化工具进行检查，提高检查的效率和准确性。
0504003
制定了哪些正式制度来管理数据的直接访问权限的增加、变更或删除。
严格控制对数据的直接访问权限，增加、变更、删除权限经有效审批。
1. 访谈相关部门负责人，并查看相关管理制度，了解如何设置数据访问权限，制定了哪些针对修改数据访问权限的制度。
2. 抽查X个有直接访问数据库中数据权限的用户，查看这些用户的权限审批记录，确认经过有效审批，且审批流程与相关管理制度一致。（对于审批不能仅限于有签字审批，有进一步评估其是否合理）
3. 对于重要的配置文件，系统参数文件，数据文件检查其访问权限是否合理。（文件、路径的访问权限设置，请参见技术平台审计程序。）
1.通过2006年8月23－25日访谈系统部RACF管理员李伟杰、DB2安全管理员张勤和开放平台部系统管理员朱鹏、数据库管理员鲍玲，我们了解到数据访问权限的管理流程与操作系统层面访问权限的管理流程一致，因此我们将两者合并进行了审计抽样和测试。
通过2006年8月23－25日访谈系统部RACF管理员李伟杰、DB2安全管理员张勤和开放平台部系统管理员朱鹏、数据库管理员鲍玲，我们了解到
RACF管理员负责主机RACF上的ID权限管理，DB2管理员负责主机上具有DB2权限的ID权限管理。管理流程遵循总行制定的《中国工商银行系统运行管理制度》之《主机用户管理实施细则》和数据中心（上海）制定的《中国工商银行数据中心（上海）主机系统用户分级管理安全策略实施方案》、《主机用户安全管理程序》。
开放平台部系统管理员负责开放平台操作系统层面ID权限管理，数据库管理员负责Oracle权限管理。管理流程符合总行制定的《中国工商银行系统运行管理制度》之《安全管理办法网络与开放平台用户管理实施细则》和数据中心（上海）制定的《生产系统开放平台服务器用户管理程序》。
总行于2006年2月下发给中国工商银行IT内审《中国工商银行系统运行管理制度》；数据中心（上海）在非现场审计期间（2006年8月14－19日）提供了《主机用户安全管理程序》和《开放平台服务器用户管理程序》，在8月24日提供了《中国工商银行数据中心（上海）主机系统用户分级管理安全策略实施方案》。我们查阅了以上的规章制度，了解到
在主机平台，数据中心（上海）将操作系统层面拥有TSO属性的ID和数据库层面的ID都分为三类，日常使用的监控ID、应用维护ID和特权用户ID。具体的用户列表、以及权限设置与工作职责相符的测试请参见技术平台审核_RACF和DB2的工作底稿。
监控ID：持有人用于日常工作，没有权限对数据和程序进行修改。
应用维护ID：约30+个。平时处于Revoke状态，当值班人员需要值班或者实施变更时，生产调度办（非工作时间则由ECC）将ID激活，并在值班结束或变更完成后将ID重新REVOKE。对于目前系统中应用维护ID的状态的测试请参见技术平台审核_RACF和DB2的工作底稿。
特权用户ID：特权用户的密码由系统部设定后交给安全部，安全部将密码和用户名都封存在密码信封中；密码信封在工作时间由安全部保管，非工作时间由ECC保管。当需要使用临时用户时，值班人员审核使用临时用户的原因（如根据Helpdesk上经过审批的变更）。安全部或ECC审批后，将密码信封交给申请人，并在信封内登记。申请人使用完临时用户后，安全部或ECC会通知系统部更改临时用户的密码。系统部将更改后的新密码交给安全部，由安全部的检查员重新封存。
我们于2006年8月30日现场查看了安全部保存的《机密部件交接表》，确认特权用户共14个，由系统部在2005年9月先后交给安全部保管。具体ID及交接时间见附件。
我们于2006年8月30日现场查看了安全部保存的《主机特权用户使用登记表》，发现在特权用户使用过的密码中多次出现AAAAAA00、AAAAAAOO等弱密码。这一点在技术平台审阅_RACF的工作底稿第7点中已经提出了例外事项提出。
在开放平台的操作系统层面和数据库层面，数据中心（上海）目前仅将操作系统上的root和super两个ID作为特权用户集中管理。管理流程同主机上的特权用户。其他ID都由相应人员日常长期持有。我们于2006年8月31日现场查看了安全部保存的《开放平台特权交接表》，确认了CM2002系统的六台应用服务器平台和数据库所在AIX平台的root和super在2005年10月10日都由开放平台部交给了安全部管理。但是，我们在查看现场与安全部主机检查员王佳音进行了访谈，了解到CM2002的六台应用服务器的super用户都封存在同一个信封里。发现例外事项。CM2002所有应用服务器的super用户都封存在同一个信封里，当申请者需要使用其中一台服务器的super用户时可以同时看到其他服务器的super密码。
发现例外事项。《主机用户安全管理程序》和《生产系统开放平台服务器用户管理程序》规定特权用户的密码由系统管理员设定，交给安全部保管。但是系统管理员和安全部相应的检查员同时知道特权用户的密码，在发生问题时不利于责任划分；而且系统管理员本身既负责系统维护，又知道特权用户的密码，没有真正实现特权用户密码上收到保险箱保管。
安全部主机检查人员负责封存主机的特权用户密码，开放平台检查人员负责封存开放平台特权用户密码。但是安全检查人员负责安全检查，同时知道同一平台的特权用户密码，不符合检查人员与能够使用该权限人员的职责分离原则。
以上的数据库和操作系统层面ID变更流程都遵循《变更管理办法生产变更实施细则》，任何ID增加、删除和权限变更都应经过安全部、生产调度办公室、实施部门（主机上的变更实施部门为系统部，开放平台变更实施部门则为开放平台部）的领导签字审批方能执行。该流程的具体细节请参见0504001第1点。
通过查看数据库层面ID权限（具体测试请参见技术平台审核_DB2和Oracle的工作底稿），我们发现
主机平台：只有SJBG组能够在数据库层面进行数据访问和变更。SJBG组中共有10个ID，如下：
SJBG01：无TSO属性；在SURROGAT配置中显示GRPAMT组和GRPOMON组可以通过SJBG01提交作业进行数据变更。2006年8月30日我们访谈了系统部RACF管理员李伟杰，了解到
GRPAMT组是应用维护ID，用于值班维护或紧急数据变更，管理流程请参见上面的应用维护ID的管理流程；而GRPOMON是运行用户，用于日常数据变更。
凡是通过SJBG01提交的数据变更作业都被日志记录下来。2006年8月30日我们访谈了安全部数据变更检查员胡玲娟，了解到安全部每日查看该日志。从SJBG01提交作业的日志中抽样追溯回原始的申请表的测试请参见0504001，对日志审核记录的抽样测试请参见0504008。
SBTCH：无TSO属性；在SURROGAT配置中显示没有用户可以通过SURROGAT使用SBTCH提交作业。2006年8月30日据系统部RACF管理员李伟杰和安全部数据变更检查员胡玲娟介绍，运行部的ID都有权限通过JSSC调用SBTCH提交作业库中的程序，但是没有监控机制能够及时发现库中的错误或非法变更。这一点我们在PC部分的工作底稿第0405002步中提出了例外事项。
SJBGAP1和SJBGSP2：有TSO属性，SURROGAT中无定义。2006年8月30日据安全部数据变更检查员胡玲娟介绍，这2个ID属于应用维护用户，用于调用特殊工具SPUFI。关于SPUFI的管理流程与测试请参见0504006和0504007。
SPAY01、SPAY02、SPAY03、SPAY04、SPAY05和SPAY06：有TSO属性，SURROGAT中无定义。2006年8月30日据安全部数据变更检查员胡玲娟介绍，这6个ID都属于特权用户，适用特权用户管理流程。如我们在前面提到的，我们查看了特权用户交接表，确认了14个特权用户都包括这6个ID。主机上的SMF日志可以记录特权用户的登录情况，安全部主机检查员定期检查该日志，确保没有发生非法变更。对该检查的抽样测试请参见0505006。
2. 我们于2006年8月30日参照技术平台审阅_RACF、DB2、AIX、Solaris和Oracle的工作底稿，查看了个人金融系统和CM2002系统在操作系统层面数据库层面的所有用户的列表，发现可以登录使用的用户（系统自动调用的用户除外）超过200个。根据抽样原则，我们随机抽取了30个样本，追溯到原始的申请表，确认15个主机用户都经过了有效的审批，且审批流程与管理流程一致；但是15个开放平台上的用户（包括操作系统层面和数据库层面）在helpdesk上都没有找到有效的申请表。抽样详情请参见下表（对于这些用户的权限与工作职责相符的测试，请参见技术平台审阅_RACF、AIX、Solaris、DB2和Oracle的工作底稿）。
发现例外事项。根据《生产系统开放平台服务器用户管理程序》，要求用户变更都在Help desk上提出申请和进行审批。审计组对CM2002系统在操作系统层面、数据库层面的所有可以登陆使用的用户进行了抽样调查，发现抽取的15个开放平台上的用户在Help desk上均没有相应的申请审批记录。
3. 关于具体的参数和权限设置请参见技术平台审阅_DB2和技术平台审阅_Oracle的工作底稿。
手动与自动组合控制/兼有预防型与发现型控制
1. CM2002所有应用服务器的super用户都封存在同一个信封里，当申请者需要使用其中一台服务器的super用户时可以同时看到其他服务器的super密码。
2. 《主机用户安全管理程序》和《生产系统开放平台服务器用户管理程序》规定特权用户的密码由系统管理员设定，交给安全部保管。但是系统管理员和安全部相应的检查员同时知道特权用户的密码，在发生问题时不利于责任划分；而且系统管理员本身既负责系统维护，又知道特权用户的密码，没有真正实现特权用户密码上收到保险箱保管。
3. 安全部主机检查人员负责封存主机的特权用户密码，开放平台检查人员负责封存开放平台特权用户密码。但是安全检查人员负责安全检查，同时知道同一平台的特权用户密码，不符合检查人员与能够使用该权限人员的职责分离原则。
4. 根据《生产系统开放平台服务器用户管理程序》，要求用户变更都在Help desk上提出申请和进行审批。审计组对CM2002系统在操作系统层面、数据库层面的所有可以登陆使用的用户进行了抽样调查，发现抽取的15个开放平台上的用户在Help desk上均没有相应的申请审批记录。
1. 将每台服务器的super用户分开封存
2&3. 建立适当的职责分工，特权用户的密码由独立岗位更改和封存。
4. 建议任何生产变更都应遵循既定的变更流程，在Help desk上进行申请审批，并附上相应的变更信息。
SH_ITGC_ATDP_07
《中国工商银行系统运行管理制度》
SH_ITGC_ATDP_33
《中国工商银行数据中心（上海）主机系统用户分级管理安全策略实施方案》
SH_ITGC_ATDP_11
《主机用户安全管理程序》
SH_ITGC_ATDP_09
《生产系统开放平台服务器用户管理程序》
0504005
是否定期审核对数据的直接访问权限（即：数据库管理员权限），确保权限和员工的岗位职责相符合？
确保对数据直接访问的权限和员工的岗位职责相符合。
1．访谈相关部门负责人，了解是否定期审核，审核的频率是多少。
2．按照审核频率，检查X份审核数据库管理员权限的记录，确认审核中发现的问题，进行了及时的调查和处理。
主机层面
1. 通过与系统部DB2安全管理员张勤的访谈，我们了解到系统部DB2安全管理员没有对DB2用户权限进行规范的定期审计，只是在投产新的应用版本或发生用户权限变更申请时会查看DB2用户权限设置。据张勤介绍，数据中心(上海)在2005年6月1日至2006年6月30日期间几乎每月都发生过用户权限变更和投产新的应用版本，因此实际上对DB2的权限检查每月都发生过。但是该检查没有检查记录，缺乏审计证据。
如0505004中提到的，主机检查员定期查看SMF日志，对于其中记录的用户权限变更，都会追溯回原始的申请表。因此可以合理确保数据直接访问权限没有发生非法变更。不过该检查不会留下详细的审计证据（我们在0505004中已经提出了例外事项），只是在发现问题的情况下，将问题及解决方法记录在每月的《安全检查情况通报》。详见0504004。
2. 由于《安全检查情况通报》每月公布，按照抽样原则，我们随机抽取了3个样本（2005年8月，2005年11月和2006年4月），发现检查中未发现问题。
开放平台层面
1. 通过与开放平台数据库管理员鲍玲和安全部开放平台检查人员王佳音的访谈，我们了解到不存在对数据的直接访问权限的定期审核。
2. 由于缺乏定期审核和审核记录，因此该步骤不适用。
发现例外事项。安全部目前没有对开放平台数据的直接访问权限实施定期审核。
手动/发现型
安全部目前没有对开放平台数据的直接访问权限实施定期审核。
建议管理层应根据风险的高低，划分资源种类和定义敏感资源，确定安全部检查的重点、检查方法和审计周期。
并且结合实际情况进行分析，考虑采用自动化工具进行检查，提高检查的效率和准确性。
0504006
如果使用了某种特殊工具来实现对数据的直接访问，那么对工具的使用是否有记录？是否会定期审核这些记录？
严格控制直接访问数据的特殊工具的使用，保护数据安全性。
1．访谈相关部门负责人，了解在使用哪些直接访问并修改数据的特殊工具，是否制定了特殊工具使用权限的授予流程。
2．通过访谈，了解现有数据环境中对特殊工具使用的记录和监控功能，以及日志的保存期限；
3．通过查看日志，抽样检查X次特殊工具使用记录，追溯至相关申请、审批程序文档，检查其是否与相关管理流程一致。
主机平台
1. 通过2006年8月23－30日与系统部DB2安全管理员张勤和安全部数据变更检查员胡玲娟的访谈，我们了解到在主机上直接访问修改数据除0504002中提到的通过提交作业方式外，还可以使用特殊工具：
DITTO和CECI：两种VSAM文件（主机V＋系统）的直接访问和修改的专用工具。
SPUFI：DB2的直接访问和修改的专用工具。
使用DITTO、CECI和SPUFI都是数据变更的一种形式。如0504001中提到的，数据变更必须遵循生产变更的流程。具体请参见0504001。
2. 通过2006年8月23－30日与系统部DB2安全管理员张勤和安全部数据变更检查员胡玲娟的访谈，我们了解到
DITTO：在审计期间内，应用维护部和系统部的维护用户（共4个）都持有使用DITTO权限，并且DITTO的使用没有日志记录。
CECI：在审计期间内，应用维护部和系统部的维护用户（共4个）都持有使用CECI的权限。主机上的CICS日志可以记录CECI的使用信息，包括使用CECI的ID、使用时间和修改的文件名。CICS日志每日备份，并长期保留。但是，在审计期间内没有人对CECI的使用日志进行定期检查。据胡玲娟解释，自2006年7月起数据中心（上海）已经加强了这方面的控制，将DITTO用户上收到安全部统一管理，限制使用DITTO；而且安全部自2006年7月开始定期查看CECI的日志，防止使用CECI进行的非法变更。
SPUFI：在0504003中已经提到只有两个应用维护ID可以使用SPUFI（维护用户的管理见0504003）。根据2006年8月30日系统部RACF管理员李伟杰介绍，SPUFI只能在指定的两台终端上使用，该终端上的任何操作都被自动抓屏记录。该抓屏记录每日备份，永久保存。
发现例外事项。自2006年7月已经将DITTO用户上收到安全部统一管理，限制使用DITTO；而且安全部自2006年7月开始定期查看CECI的日志。但是，在审计期间内(2005年6月1日－2006年6月30日)，应用部和系统部的维护用户（共4人）持有DITTO和CECI的权限，可以使用DITTO或CECI而无需经过申请审批流程控制；同时DITTO的使用没有日志记录，CECI使用的日志没有人定期检查。
3．
DITTO：由于没有日志，无法抽样。上面已经提出了例外事项。
CECI：据胡玲娟介绍，在审计期间内CECI几乎没有使用过。由于CECI使用的日志是每日记录，根据抽样原则我们随机抽取了15个样本日期（2005年6月3日、6月15日、7月10日、8月12日、9月13日、10月31日、11月15日、12月31日，以及2006年1月17日、2月18日、3月19日、4月4日、4月20日、5月21日、6月22日），确认在样本期间内CECI都没有被用于数据变更。
SPUFI：我们在2006年8月31日现场查看了主机设置，确认其中设定了SJBGAP1和SJBGAP2用户只能在2个 IP地址上登录；并且我们于8月31日现场查看确认了这两个IP地址指向ECC中放置的两台终端。我们于2006年8月31日现场看到在这两台终端上安装了抓屏软件，抓屏时机设置为“运行软件进行录制”，据胡玲娟介绍该设置表示开打了自动录制功能，任何在这两台终端上进行的操作都被自动抓屏记录下来，只有安全部数据变更检查员知道抓屏软件的密码有权限删除或改动这些抓屏记录。据胡玲娟介绍，在审计期间内SPUFI几乎没有使用过。由于抓屏记录是每日一份，根据抽样原则，我们随机抽取了15份抓屏记录（2005年6月3日、6月15日、7月10日、8月12日、9月13日、10月31日、11月15日、12月31日，以及2006年1月17日、2月18日、3月19日、4月4日、4月20日、5月21日、6月22日），发现样本期间内SPUFI都没有使用过。另外，在0505006中也提到了，SMF日志可以记载这两个用户是否使用过，安全部主机检查员定期查看SMF日志确认没有人使用这两个用户进行非法变更。
开放平台
1&2&3. 通过2006年8月23日与开放平台部应用数据维护人员陈帅俊和安全部开放平台检查人员王佳音的访谈，我们了解到在开放平台上直接访问修改数据都是通过数据库用户名和密码验证的，未使用特殊工具。
手动与自动控制组合/兼有预防型和发现型控制
在审计期间内(2005年6月1日－2006年6月30日)，应用部和系统部的维护用户（共4人）持有DITTO和CECI的权限，可以使用DITTO或CECI而无需经过申请审批流程控制；同时DITTO的使用没有日志记录，CECI使用的日志没有人定期检查。
我们了解到自2006年7月1日起数据中心（上海）加强了对DITTO和CECI的管理，限制使用DITTO，并定期查看CECI的日志。审计组建议将此发现列为审计关注事项，在下次审计期间对新控制进行相应的审计测试。
0504007
同上
同上
按照抽样原则，抽样查看特殊工具使用日志，检查有无审核痕迹，以及对于审核中发现的潜在的未经授权的使用，是否进行了调查和追踪。
主机平台
通过2006年8月23－30日与安全部主机数据变更检查员胡玲娟的访谈，我们了解到
DITTO和CECI：DITTO没有日志记录，CECI没有定期监控。我们已经在0504006中提出了例外事项。
SPUFI：数据变更检查员每日检查抓屏记录，对于其中记录的通过SPUFI进行的数据变更，都追溯到helpdesk的申请表，确认这些变更都有适当的申请审批程序。
如果发现问题，主机检查员会及时通知相关人员追踪解决，并且在当月的《安全检查情况通报》中披露。
因此，我们进行了对《安全检查情况通报》的抽样测试。我们随机抽取了2005年8月、2005年11月和2006年4月的《安全检查情况通报》（由安全部在2006年8月24日提供），发现在样本期间内都没有使用过SPUFI。
开放平台
正如在0504006提到的，在开放平台上直接访问修改数据都是通过数据库用户名和密码验证的，未使用特殊工具。因此该步骤不适用。
未发现例外事项。
手动/发现型
SH_ITGC_ATDP_34
2005年8月、2005年11月和2006年4月的《安全检查情况通报》
0504008
如何监控数据环境中未经授权的活动。
及时发现并处理未经授权的活动。
1．查看系统参数设置方式，了解现有数据环境中开启了哪些日志。
2．通过访谈了解日志记录的保存方式和保存期限；
3．检查日志记录了何种事项和交易。
主机平台
1. 通过2006年8月24日与系统部DB2安全管理员张勤的访谈，我们了解到
审计功能：DB2的审计功能都未开启。我们查看了数据库设置（请参见技术平台审阅_DB2），确认审计功能未开。
日志：如0504002中提到的，DB2的数据更改有两种方式，批量提交作业和使用特殊工具。使用特殊工具的日志记录及审核请参见0504006和0504007。对于批量提交作业，在0504003中已经提到
SJBG01和SBTCH：目前只对SJBG01用户提交作业保存日志。对于SBTCH提交的作业没有日志，无法定期检查，我们已经在0504003中提出了例外事项。
SJBGAP1和SJBGAP2：在0504003中已经提到，有抓屏记录这两个用户的使用情况。具体抽样测试请参见0504006。
SPAY01、SPAY02、SPAY03、SPAY04、SPAY05和SPAY06：在0504003中已经提到，SMF日志可以记录这些用户的使用情况。具体抽样测试请参见0505006。
2. 通过2006年8月24日与系统部DB2安全管理员张勤和安全部数据变更检查员胡玲娟的访谈，我们了解到数据中心（上海）每日备份主机上提交作业的日志和SMF日志，永久保留。
3. 我们于2006年8月30日现场查看了主机上SJBG01提交作业的日志，确认该日志记录了数据变更的时间、ID、执行的SQL语句与变更内容。对于从该日志的审核与抽样测试请参见0504001和 0504009。
我们于2006年8月31日现场查看了SMF日志，确认其中记录了登录的ID、登录时间和运行的命令。对于从该日志的审核与抽样测试请参见0505003和0505004。
开放平台
1. 通过2006年8月24日与开放平台部数据库管理员鲍玲的访谈，我们了解到
审计功能：Oracle的审计功能都未开启。我们查看了数据库设置（请参见技术平台审阅_Oracle），确认审计功能未开。在技术平台审阅_Oracle中已经提出了例外事项。
日志：Oracle开启了Archive日志，主要用于数据库恢复，数据中心不会使用解析软件阅读和分析日志。我们在0504001中已经提出，对于开放平台上的数据变更缺乏有效的监控策略，无法有效发现非法变更，作为例外事项。
2. 2006年8月23－24日通过与系统部DB2安全管理员张勤和开放平台部数据库管理员鲍玲的访谈，我们了解到数据中心（上海）每日备份Archive日志，永久保留。
3. 如1中提到的，目前数据中心（上海）未开启审计功能，Archive日志无法解析分析。因此，该步骤不适用。
未发现例外事项。
手动与自动控制组合/发现型
0504009
是否定期审核上述审计、监控工具输出的审计证据？当发现数据环境中未经授权的活动时，会采取何种措施？
及时发现并处理未经授权的活动。
1．访谈相关部门负责人，了解是否对各类日志进行定期审核，审核频度是否满足数据安全性的要求；
2．访谈相关部门负责人，并查看相关流程文档，了解当监控发现数据环境中未经授权活动时，是否根据预先制定的方案或流程采取相应的措施；
3．对上一个控制测试中，查看的日志进行检查，查看审核的记录。并且，对其中的未经授权的活动，查看相关调查处理记录。
主机平台
1. 如0504002中提到的，DB2的数据更改有两种方式，批量提交作业和使用特殊工具。
1）批量提交作业。
如0504008中提到的：
对于SBTCH提交的作业没有日志，无法定期检查，我们已经在0504003中提出了例外事项。
SJBG01提交的作业有日志记录提交作业的ID、时间、执行的SQL语句和变更内容。通过2006年8月30日与安全部数据变更检查员胡玲娟的访谈，我们了解到
2005年6月1日至2005年12月20日之间，安全部数据变更检查员（如0504003中提到的，安全部检查员没有调用SJBG01的权限）每日查看前一日提交作业的日志，对于其中涉及到金额变更的记录，手工查询helpdesk系统，确认都有相应的经过审批的变更单支持，且变更内容与变更单一致。但是该审核没有留下审计痕迹，只在发现问题的时候在《安全检查情况通报》中进行书面通报，并且采取进一步措施跟踪解决。
2005年12月21日至2006年6月30日之间，数据中心（上海）使用了数据变更事后核对系统。该系统每天自动查找helpdesk的信息，核对前一日SJBG01提交作业日志的每条记录，确保每条日志记录都有经过审批的变更单支持，且变更内容与变更单显示的内容一致。在发现问题时，安全部数据变更检查员会在《安全检查情况通报》中进行书面通报，并且采取进一步措施跟踪解决。
发现例外事项。安全部开展的对开放平台和主机的用户、系统参数的检查，只是将发现的问题汇总在《安全检查情况通报》中，对于检查的具体内容和过程都没有留下详细的书面记录。
SJBGAP1和SJBGAP2：在0504003中已经提到，有抓屏记录这两个用户的使用情况。具体抽样测试请参见0504006。
SPAY01、SPAY02、SPAY03、SPAY04、SPAY05和SPAY06：在0504003中已经提到，SMF日志可以记录这些用户的使用情况。具体抽样测试请参见0505006。
2）使用特殊工具：
日志记录及审核请参见0504006和0504007。
2. 我们查看了《中国工商银行数据中心（上海）主机系统用户分级管理安全策略实施方案》（安全部于2006年8月24日提供）和《生产系统开放平台服务器用户管理程序》（数据中心上海在非现场审计期间，即2006年8月14－19日提供），了解到其中规定了安全部定期检查发现的问题通过《安全检查报告》形式进行通报。通过与安全部数据变更检查员胡玲娟的访谈，我们了解到
1）批量提交作业：
如果发现问题，数据变更检查员会及时通知相关人员追踪解决，并且在当月的《安全检查情况通报》中记录问题的内容以及解决追踪的情况。
2）使用特殊工具：
日志记录及审核请参见0504006和0504007。
3. 如1&2中提到的，以上的检查没有留下详细的审计痕迹，只是在发现问题的时候在《安全检查情况通报》中记录。
我们进行了对《安全检查情况通报》的抽样测试。根据抽样原则，我们抽取了2005年8月、2005年11月和2006年4月的《安全检查情况通报》（由安全部2006年8月24日提供），发现
2005年8月：《安全检查情况通报》第60期指出“2005年7月21日至8月20日南北生产环境的数据变更进行了检查，未发现问题”。
2005年11月：《安全检查情况通报》第94期指出 “2005年10月21日至11月20日南北生产环境的数据变更进行了检查，未发现问题”。
2006年4月：《安全检查情况通报》第57期指出“2006年03月21日至04月20日南北生产环境的数据变更进行了检查，发现6个变更存在问题”
其中4个变更实施时间与计划实施时间不符（变更单号：110805、110925、112978、114056），2个变更实施SQL语句涉及账号有误（变更单号：112320、113328），安全部要求应用部按制度流程处理变更并严格确认变更实施方案。
据安全部数据检查员胡玲娟在2006年8月30日的介绍，应用部于4月28日通过邮件对问题原因和跟进措施进行了答复。我们在现场检查了6个问题的答复邮件，确认这些问题都已得到变更申请部门的反馈意见表示都已准确解决。
开放平台
1&2&3. 通过2006年6月23－25日与安全部开放平台检查员王佳音和开放平台部数据库管理员鲍玲的访谈，我们了解到不存在对开放平台上的数据变更日志的检查和分析，因此无法发现未在helpdesk上登记的非授权数据变更。
我们已经在0504001中提出了该问题，作为例外事项。
手动/发现型
安全部开展的对开放平台和主机的用户、系统参数的检查，只是将发现的问题汇总在《安全检查情况通报》中，对于检查的具体内容和过程都没有留下详细的书面记录。
加强对对开放平台和主机的用户、系统参数的检查的书面记录，至少应在记录中包括检查具体内容和过程的说明，以便于管理层审阅工作及确保检查质量。
SH_ITGC_ATDP_33
《中国工商银行数据中心（上海）主机系统用户分级管理安全策略实施方案》
SH_ITGC_ATDP_09
《生产开放平台服务器用户管理办法》
SH_ITGC_ATDP_34
2005年8月、2005年11月和2006年4月的《安全检查情况通报》
SH_ITGC_ATDP_35
《安全检查情况通报》57期的答复邮件
0505000
操作系统安全
0505001
是否对各个相关的操作系统进行风险评估？
对各个相关操作系统进行风险评估。
1．访谈相关部门负责人，了解科技部门如何对各个相关的操作系统进行评估，识别的风险有哪些，如何对这些风险进行评级，及评级的结果。
2．查看相关风险评估的文档、记录。
1&2. 通过2006年8月24－25日与系统部RACF管理员李伟杰和开放平台部总经理范远希的访谈，我们了解到没有针对操作系统的风险评估。我们在0102001中提出了该例外事项。
手动/预防型
0505002
在操作系统层面制定了哪些安全制度和工作规范？
适当的操作系统层面安全控制能够规避风险，确保业务数据的安全。
1．访谈科技部门负责人，了解针对所识别的风险，制定了哪些相关的管理制度及工作规范。
2．查看相关管理制度和规范是否对相关的风险进行控制。
1&2. 如0505001提到的，没有针对操作系统的风险评估，因此不存在针对风险评估结果制定的管理制度和工作规范。
现有的制度和规范请参见下面的步骤0505003－0505010。
手动/预防型
0505003
是否制定了操作系统参数变更流程？
操作系统参数变更遵循正式的流程和管理制度。
1．访谈科技部门负责人，了解是否建立了系统参数配置标准以及参数变更流程。
2． 查看参数配置标准是否详细和完整，相关参数变更流程是否包括相应的申请、审批和实施管理的具体内容。
3．对审计范围内操作系统主要参数进行审核。（具体参见操作系统技术平台审计工作底稿。）
4．对审计期间内发生的参数变更进行抽样检查，查看每个变更样本的申请、审批手续和记录是否齐全，是否与相关管理规定相符。
1&2. 通过2006年8月24－25日访谈系统部RACF管理员李伟杰和开放平台部系统管理员范远希，我们了解到
1) 对参数配置标准的审阅请参见技术平台审阅_RACF和技术平台审阅_AIX、技术平台审阅_Solaris的工作底稿。
2) 系统参数配置更改遵循《变更管理办法生产变更实施细则》，在help desk上审批。该制度详细内容请参见0504001第1点。
3. 请参见技术平台审阅_RACF、技术平台审阅_AIX和技术平台审阅_Solaris。
4.
1）主机平台：我们于2006年8月31日现场查看了2005年6月1日至2006年6月30日的操作系统层面参数变更的日志，发现只发生参数变更1次，发生时间为2006年1月20日，变更内容为增加设置PASSWORD（WARNING（005））和PASSWORD（REVOKE（005））。我们追溯到helpdesk上的原始申请表＃104892，确认了该样本经过了合理的审批，变更内容与审批内容一致。
2）开放平台：如0505004中提到的，我们已经发现开放平台上的参数变更未在help desk上进行申请和审批，不符合管理规定。我们自0504004中提出了例外事项。
手动/预防型
0505004
是否定期审核操作系统参数设置？
操作系统参数配置符合安全要求和目标。
1．访谈相关部门负责人，了解操作系统参数检查管理办法及实施情况，并查看检查管理办法内容。
2．抽样检查操作系统参数设置的检查记录是否符合相关检查管理办法。
1. 通过2006年8月23－31日与安全部主机检查员杨玲、系统部RACF管理员李伟杰和安全部开放平台检查员王佳音的访谈，我们了解到
主机平台：主机上每日自动将SMF日志下传到一个文件服务器上，系统部RACF管理员和安全部主机检查员都权限登录该文件服务器。据李伟杰介绍，他有权限修改该下传下来的日志文件。安全部主机检查员负责定期从文件服务器上获取SMF文件，检查内容包括主机用户的登录情况、对资源和系统参数的修改记录、对用户权限的更改记录等。发现例外事项。目前安全部每月检查主机上的SMF日志，对主机上操作进行监控。但是，SMF日志是由RACF管理员导出提供给安全部的，同时RACF管理员有访问或修改导出日志的权限。系统管理员拥有高权限用户，同时有权限访问和修改导出SMF日志，不符合适当的职责分工原则。
我们于2006年8月31日现场查看了SMF日志，了解到该日志记录了所有ID的登录时间，访问的资源以及对此资源执行的命令。
据杨玲介绍，在对SMF日志的检查过程中
当发现特权用户、应用维护用户登录，用户权限修改，或者对敏感的资源和参数进行了修改，主机检查员会检查前一日的help desk上的变更申请表，确认这些用户使用和生产变更都经过了适当的审批。但是据杨玲介绍，2006年7月－8月数据中心（上海）正在草拟正式的的规章制度对资源进行划分并明确定义敏感资源。在审计期间内（2005年6月1日－2006年6月30日）尚未正式的规章制度明确划分资源种类和定义敏感资源，导致主机检查员对SMF日志的检查，只是通过经验判断选择对敏感资源的访问和修改作为重点检查对象。发现例外事项。
当发现具有数据修改权限的用户（如0504003中提到的有SJBGAP1、SJBGAP2、SPAY01－06）通过TSO登录过，主机检查员会通知安全部数据变更检查员对变更内容进行检查。数据检查员对数据变更内容的检查及抽样测试请参加0504006、0504007和0504009。
以上的检查都没有留下审计证据，只是在发现问题时，主机检查员会在当月的《安全检查情况通报》中指出，并且负责进一步督促相关人员进行整改。
开放平台：安全部每月检查操作系统参数。每月抽查2台，检查内容包括root的远程登录控制、弱密码、日志是否开启、ftpuser设置等是否符合规定。该检查都没有留下审计证据，只是在发现问题时，主机检查员会在当月的《安全检查情况通报》中指出，并且负责进一步督促相关人员进行整改。
我们发现，安全部每月对主机平台SMF日志进行检查，对开放平台操作系统参数进行检查，但是检查员只是将发现的问题每月汇总在《安全检查情况通报》中，对于检查的详细情况和过程都没有留下详细的审计证据，不便于管理层监督和审阅检查工作。我们已经在0504009中提出了该例外事项。
2. 由于安全部是每月检查，根据抽样原则我们随机抽取了3个样本（2005年8月、2005年11月和2006年4月）的《安全检查情况通报》，发现
主机平台：我们查看了样本《安全检查情况通报》发现未提到RACF参数设置的非法变更，但是如前面所提到的，安全部的检查不会留下详细的审计痕迹，因此我们无法从样本中看出安全部的检查流程。
开放平台：只有在2006年4月的《安全检查情况通报》049期中提到对开放平台服务器的系统设置进行了检查。据开放平台检查员王佳音解释，对开放平台参数设置的检查是从2005年12月开始的。我们查看了2006年4月的《安全检查情况通报》，发现其中提出问题有4个：
个人营销系统应用服务器root没有被限制在控制台登录。
个人营销系统应用服务器所谓MAXWEEKS、MINWEEKS未设置。
个人营销系统应用服务器的FTP禁用用户未设置。
用友系统应用服务器root帐户没有被限制只在控制台登录。
但是，我们无法找到开放平台部对以上问题的书面反馈意见。安全部王佳音于2006年9月1日确认，开放平台部当时进行了整改，并且电话通知了安全部整改完毕。该整改属于生产环境变更，但是我们无法找到Help desk上相应的审批表。发现例外事项。
发现例外事项。安全部从2005年12月开始每月对开放平台操作系统参数配置进行检查，每月随机抽取2台服务器检查root的远程登陆控制、UMASK、错误输入密码的次数限制、密码设置、日志是否开启、FTPUSER设置等几项。但安全部为对该检查的具体内容进行明确规定。
手动/预防型
1. 目前安全部每月检查主机上的SMF日志，对主机上操作进行监控。但是，SMF日志是由RACF管理员导出提供给安全部的，同时RACF管理员有访问或修改导出日志的权限。系统管理员拥有高权限用户，同时有权限访问和修改导出SMF日志，不符合适当的职责分工原则。
2. 在审计期间内（2005年6月1日－2006年6月30日）尚未正式的规章制度明确划分资源种类和定义敏感资源，导致主机检查员对SMF日志的检查，只是通过经验判断选择对敏感资源的访问和修改作为重点检查对象。
3. 安全部从2005年12月开始每月对开放平台操作系统参数配置进行检查，每月随机抽取2台服务器检查root的远程登陆控制、UMASK、错误输入密码的次数限制、密码设置、日志是否开启、FTPUSER设置等几项。但安全部为对该检查的具体内容进行明确规定。
4. 安全部在2006年049期《安全检查情况通报》中发现了4个开放平台系统参数的设置问题。审计组与安全部开放平台检查员确认，了解到当时开放平台部进行了相应的整改并通过电话通知了安全部整改完成，但是未向安全部出具书面反馈；同时该参数设置修改属于生产环境变更，但在Help desk上无相应的申请审批记录。
1. 审计组建议实施职责分工由独立的人员进行日志导出操作。
同时适当考虑采用自动化工具对日志进行管理（如日志实时镜像存放在独立的服务器中），以确保日志的完整性与真实性。
2. 我们了解到安全部目前已经着手编制关于主机资源的划分标准和敏感资源定义的规章制度。我们建议管理层应根据风险的高低，划分资源种类和定义敏感资源，确定安全部检查的重点、检查方法和审计周期。
3. 建议管理层应根据风险的高低，划分资源种类和定义敏感资源，确定安全部检查的重点、检查方法和审计周期。
并且结合实际情况进行分析，考虑采用自动化工具进行检查，提高检查的效率和准确性。
4. 建议任何生产变更都应遵循既定的变更流程，在Help desk上进行申请审批，并附上相应的变更信息。
0505005
是否制定了操作系统访问权限的管理制度（包括权限的增加、删除和变更）
严格控制操作系统访问权限，增加、变更及删除权限经过有效审批。
1．访谈相关部门负责人，并查看相关管理制度，了解操作系统权限变更流程。
2．获取操作系统用户权限列表，按照抽样原则，选取X个用户（至少包括所有的系统管理员和超级用户），检查：
- 是否有用户申请表及相应管理部门的审批；
- 申请程序是否与管理规定相符；
- 系统中的权限和申请表中的权限是否一致；
- 用户权限与其职责是否相符。
操作系统层面和数据库层面用户管理完全一致。管理制度、流程及抽样请参见0504003。
手动与自动控制组合/兼有预防型和发现型控制
0505006
是否定期检查操作系统访问权限。
严格控制操作系统中的访问权限，确保用户权限与其职责相符。
1、访谈相关部门负责人，了解操作系统访问权限检查管理办法及实施情况，并查看检查管理办法内容。
2、对定期检查记录进行抽样检查同时查看对那些定期检查中发现的问题，是否进行了记录、跟进和处理。
1. 通过查阅总行制定的《中国工商银行系统运行管理制度》之《主机用户管理实施细则》和《安全管理办法网络与开放平台用户管理实施细则》（总行2006年2月统一下发给IT内审），我们了解到起其中规定了安全管理部门应定期对用户权限的设置、用户使用情况及用户活动进行检查。
通过2006年8月23－31日访谈安全部主机检查员杨玲和开放平台检查员王佳音，我们了解到
根据总行制定的规范，数据中心（上海）制定了《中国工商银行数据中心（上海）主机系统用户分级管理安全策略实施方案》（2006年8月24日安全部提供）和《生产系统开放平台服务器用户管理程序》（数据中心上海于非现场审计期间提供，即2006年8月14－19日提供）。我们查阅了这些规范，了解到其中规定了“安全部定期对用户的设置、权限、使用情况和用户资源访问情况的进行抽查。检查结果通过《安全检查情况通报》形式进行通报。”
目前，安全部每月进行一次操作系统访问权限检查。正如0504004中提到的，所有的操作系统权限变更都遵循生产变更流程，都会发给安全部审批，因此安全部维护了最新的操作系统用户列表。
主机平台：主机检查员每月对比主机上ID的个数是否与自己维护用户列表个数一致。如0505004中提到的，主机检查员定期查看SMF日志，对于其中记录的用户权限变更，都会追溯回原始的申请表。因此可以合理确保用户权限没有发生非法变更。不过该检查不会留下详细的审计证据，我们在0505004中已经提出了例外事项。
开放平台：开放平台安全检查员每月抽查2台开放平台的系统，查看用户列表是否与安全部手中的最新的用户列表相符，以及超级用户ID是否与安全部手中的最新的用户列表相符。
发现例外事项。安全部从2005年11月开始对开放平台用户进行检查，每月随机抽取2台服务器，查看ID列表以及属于超级用户组的ID，确认没有发生非法的ID增删。但是该检查未查看除超级用户组外的其他ID的权限。
2. 由于《安全检查情况通报》是每月一次，根据抽样原则我们随机抽取了三个月（2005年8月、2005年11月和2006年4月）的《安全检查情况通报》（安全部2006年8月24日提供），发现
主机平台：安全部对主机用户的列表进行了检查，并且通过查看SMF日志查看主机用户权限是否发生了变更。在这三个月的检查中均未发现用户权限的非法变更。但是，安全部发现主机环境中对某些库和资源的访问权限设置过宽，在当月的《安全检查情况通报》中都与相关部门协商了解决方案，加强了对资源的访问权限设置。
开放平台：2005年8月的《安全检查情况通报》没有提到对开放平台用户进行检查。据安全部开放平台检查员王佳音2006年8月24日解释，对开放平台用户的检查是从2005年11月开始的。我们查看了2005年11月和2006年4月的《安全检查情况通报》，了解到安全部检查了用户列表以及其中属于超级用户的ID的合规性，没有发现问题。
手动/发现型
安全部从2005年11月开始对开放平台用户进行检查，每月随机抽取2台服务器，查看ID列表以及属于超级用户组的ID，确认没有发生非法的ID增删。但是该检查未查看除超级用户组外的其他ID的权限。
在进行用户检查时除对超级用户定期检查外亦应对其他用户的权限及使用情况进行检查。
SH_ITGC_ATDP_07
《中国工商银行系统运行管理制度》
SH_ITGC_ATDP_33
《中国工商银行数据中心（上海）主机系统用户分级管理安全策略实施方案》
SH_ITGC_ATDP_09
《生产系统开放平台服务器用户管理程序》
0505007
如何监控操作系统中未经授权的活动。
及时发现和处理操作系统中未经授权的活动。
1．访谈相关人员并查看操作系统参数，了解开启了哪些日志功能。（具体请参见操作系统技术平台审计工作底稿。）
2．访谈相关人员，了解是否采用相关工具软件对操作系统进行监控，并查看该软件的使用情况、生成的报告等。
1. 请参见技术平台审阅_RACF和技术平台审阅_Solaris的工作底稿。
2. 通过2006年8月23日与安全部主机检查员杨玲和开放平台检查员王佳音的访谈，我们了解到目前只是采用了事后的日志检查来发现问题，还没有采用软件监控主机和开放平台上的非授权活动。日志检查请参见0505008。
手动和自动控制组合/发现型
0505008
是否定期检查系统日志及相关工具软件生成的报告？当发现未经授权的活动时，是否采取相应措施。
及时发现未经授权的活动并采取措施，保护数据信息的安全性。
1．访谈相关部门负责人，了解对系统日志和报告定期检查的管理规定和实施情况，并查看管理规定的内容。
2．抽样检查管理部门定期检查记录，同时查看对那些发现的未经授权活动是否及时进行了记录和跟踪处理。
通过2006年8月23－31日与安全部主机检查员杨玲、开放平台检查员王佳音、系统部RACF管理员李伟杰和开放平台系统管理员朱鹏的访谈，我们了解到安全部和系统管理员定期查看系统参数和用户权限，发现非法变更。对于该检查的内容、汇报流程和抽样测试请参见0505004和0505006。
手动/发现型
0505009
是否安装了防病毒软件。
在所有计算机系统上安装防病毒软件，以防止系统遭受病毒攻击。
1．访谈相关人员，并查看相关管理规定，了解与防病毒相关的管理制度。
2．查看防病毒服务器上的防病毒软件及其版本号、更新日期确认其进行了及时更新。
3．抽查客户端的防病毒软件版本号、升级日期是否符合相关管理规定。
1.我们查阅了总行颁布的《中国工商银行信息系统运行管理制度》之《安全管理办法计算机防病毒实施细则》（总行2006年2月下发给IT内审），规定对需接入我行网络的计算机信息系统安装全行统一的防病毒软件。根据总行颁布的该制度，数据中心（上海）制定了详细的实施办法《防病毒管理程序》（数据中心上海在非现场审计期间提供，即2006年8月14－19日）。通过查阅以上的规定，以及2006年8月23－30日与安全部防病毒管理员徐雯的访谈，我们了解到：
1）各部门安全员负责为本部室所辖各类计算机设备安装防病毒软件。
2）防病毒服务器会自动更新病毒码和版本，客户端的相应文件会自动更新。
通过2006年8月24日与安全部计算机防病毒管理员徐雯访谈，我们了解到数据中心（上海）的计算机设备安装趋势科技的防毒软件（TMCM）进行集中管理，分为以下四个层面：
父TMCM：由数据中心安全部防病毒管理员进行管理，每15分钟自动在“趋势”网站上查找新的病毒码并下传到子TMCM
子TMCM：数据中心（上海）和每个一级都有一个子TMCM，分别进行管理。子TMCM会自动接收由父TMCM传送的病毒码，并自动下传各防病毒服务器
防病毒服务器：共分三种，office scan下连客户端，管理98\2000\xp系统的pc设备；在2000\2003系统服务器上安装server protect；在邮件服务器上安装了scan mail。防病毒服务器会自动接收由父TMCM传送的病毒码，并自动下传客户端。
客户端：98\2000\xp系统的pc设备都安装了客户端，接收从office scan上传来的病毒码和版本。
2. 由于这些病毒码和版本的更新都是自动控制，根据抽样原则，我们于2006年8月24日13:05现场查看了自动控制的系统设置（“趋势科技防毒墙控制管理中心”的设置），并且在各个层面抽取了一个样本进行测试。
1）父TMCM层面：
我们现场查看到父TMCM病毒码为；下载日期为8月24日12:40；下载频率设置为每10分钟一次；部署计划为立即下传，即一旦有了新的版本，父TMCM会立即自动下传到所辖的子TMCM。
2）子TMCM层面：
我们现场查看到数据中心的子TMCM病毒码为，下载日期为8月24日12:43。下载频率设置为每小时一次，即父TMCM未自动下传病毒码的控制失效时，子TMCM会每小时自动从父TMCM中索取更新版本。部署计划为立即下传给辖内的防病毒服务器。
3）防病毒服务器层面
Office scan：我们现场查看了南方中心办公网防病毒服务器（FANGBINGDU3_SPNT）病毒码，下载日期为8月24日12:33。下载频率为每小时一次，即子TMCM未自动下传病毒码的控制失效时，office scan会每小时自动从子TMCM中索取更新版本。部署计划为立即下传到辖内的客户端。
Scan mail：我们现场查看了scan mail服务器病毒码，下载日期为8月24日13：00。
Server protect：我们现场查看了server protect服务器病毒码。确认服务器病毒码已及时更新。
3. 客户端层面：
1）客户端的安装
我们查看了《防病毒管理程序》（数据中心上海非现场审计期间统一提供，即2006年8月14－19日），发现其中规定“各部门安全员负责为本部室所辖各类计算机设备安装防病毒软件”。同时，安全部防病毒检查员每月利用TMVS系统对办公、测试网段计算机进行扫描，检查防病毒软件安装情况，对未按要求安装的情况在当月的《安全检查情况通报》中进行通报并协助其安装防病毒软件。
由于TMVS扫描是每月进行一次，根据抽样原则我们随机抽取了三个月（2005年8月、11月和2006年4月）的《安全检查情况通报》（安全部2006年8月24日提供）。我们查阅了这些报告，发现
2005年8月的安全部检查中发现有5台服务器病毒码过期，在8月15日之前已经进行了处理。
2005年11月的安全部检查中发现网络部1台公用办公设备防病毒软件未正常启动，11月8日之前已经进行了处理。
2006年4月的安全部检查中发现有5台服务器病毒码过期，在4月21日之前已经进行了处理。
2）安装完成的客户端的病毒码更新
正如前面提到的，防病毒系统会自动更新客户端的病毒码。根据抽样原则，对于该自动控制，我们抽取了一个样本进行测试。我们现场查看了安全部王佳音、徐雯的pc机office scan客户端病毒码为，确认已及时更新。
未发现例外事项。
自动/预防型
SH_ITGC_ATDP_07
《中国工商银行信息系统运行管理制度》
SH_ITGC_ATDP_21
《防病毒管理程序》
0505010
同上
同上
对防病毒服务器的自动扫描报告及管理部门的检查记录分别进行抽样检查。
通过与2006年8月23－25日与安全防病毒管理员徐雯访谈，以及查阅《防病毒管理程序》（数据中心上海在8月14－19日非现场审计期间提供给IT内审的），我们了解到防病毒服务器自动实时监控感染病毒的情况，安全部防病毒管理员根据监控结果每日填写《病毒日志每日检查表》，并采取必要措施。
由于该控制是每日发生，根据抽样原则，我们抽取了15个日期，确认当日填写了《病毒日志每日检查表》，对于其中发现的问题采取了必要措施进行进一步的追踪处理。
未发现例外事项。
手动与自动组合/发现型
《病毒日志每日检查表》
0507000
内部网络安全管理
0507001
是否制定了适当的安全管理制度，以管理内网的变更？
制定相应的管理制度对内部网络的变更进行管理，从而保证内部网络结构的合理性和安全性。
1．查阅《中国工商银行系统运行管理制度》及相关的实施细则，查看是否包括网络变更流程。
2．查阅网络建设技术规范、安全区域设计规范等文档，通过访谈网络部门负责人，了解审计时限的网络变更情况。查看审计时限内网络变更记录，了解变更内容和次数等。
3．抽样检查X份网络变更审批流程记录，检查其是否经过了相关部门的审批是否符合相关管理规定。
1.通过查阅《网络安全管理程序》(SH_ITGC_ATDP_40) 和《中国工商银行计算机信息
系统安全体系规范》(SH_ITGC_ATDP_36)（网络部于2006年8月29日提供），我们了解到制度规定
“所有的安全域以及域内的网络设备必须指定明确的管理部门和管理责任人，并明确管理责任”，建立规范的网络安全配置流程。
网络配置权限进行分级，只能由经过授权的管理人员对授权的设备进行配置。
网络变更流程遵循生产变更流程。具体流程见2。
2. 如0507006中提到的，数据中心（上海）网络设备清单中只有管理部门，而未指定具体责任人。我们已经在0507006中提出了例外事项。
2006年8月28－31日与网络部二部经理麻艳阳的访谈和查看生产变更的记录，我们了解到
对于内网的变更是遵循生产变更流程，并通过Helpdesk系统进行申请审批流程控制，其申请审批步骤如下：
需求提出部门申请网络变更
设备部了解服务器位置
安全部和网络部网络变更申请进行审批
网络部根据服务器的位置分配具体的网络设备IP地址和端口
网络部安排变更实施
变更实施人/申请人反馈变更实施结果，变更受理人在Helpdesk系统中关闭变更申请。
网络变更的内容包括网络设备的变更、防火墙/路由器/交换机的配置变更、IP地址/端口变更等。
每日的网络变更都在当日的《全行生产运行情况日通报》(SH_ITGC_ATDP_50)中记录。据麻艳阳介绍，2005年6月1日至2006年6月30日之间的网络变更次数超过200个。
3．由于样本总数超过200个，根据抽样原则，我们从《全行生产运行情况日通报》(SH_ITGC_ATDP_50)中抽取了20份网络变更，追溯到Helpdesk上的申请表，确认都经过了相关部门的审批，申请审批流程符合相关管理规定。
未发现例外事项。
手动/预防性
《网络安全管理程序》
SH_ITGC_ATDP_40
《中国工商银行计算机信息
系统安全体系规范》SH_ITGC_ATDP_36
《全行生产运行情况日通报》SH_ITGC_ATDP_50
0507002
同上
同上
1．查看IP地址管理规定是否包括IP地址的申请和审批、分配、使用、登记、和回收；
2．查看当前的IP地址登记清单，随机抽取X个IP地址，对其申请、审批流程进行检查；
3．访谈IP地址使用部门和人员，并抽样检查使用部门整理的设备清单，核实IP地址的实际使用情况是否与网络管理部门的登记相符。
1. 通过查看《IP地址管理作业指导书》(SH_ITGC_ATDP_44)（网络部于2006年8月29日提供），我们了解到该指导书中规定了IP地址的申请审批登记和回收的流程。具体而言：
申请或变更IP地址时，由使用部门填写《IP地址申请表》(SH_ITGC_ATDP_67)中的申请人填写部分，并将《IP地址申请表》(SH_ITGC_ATDP_39)作为变更附件；注销IP地址时，由使用部门在变更单中注明。如果涉及到设备变更，
新增设备时，设备部安装所需生产区域设备，补充填写《IP地址申请表》(SH_ITGC_ATDP_39)中的设备部填写部分，并在变更单中添加该附件；
注销IP地址停用设备时，更新设备资源管理系统中的相关信息。
IP变更申请由申请部门和网络部的负责人审批后方能实施。
网络部实施设备IP地址的增加、更换等变更操作，填写《IP地址申请表》(SH_ITGC_ATDP_39)中的网络部填写部分，并在变更单中添加该附件；注销IP地址时，网络部按照变更单内容实施注销。
最后，网络部根据变更内容，更新网管系统CMDB配置管理库，维护生产设备IP地址资源。
2&3. IP地址为数据中心（上海）的机密文件，审计组无法获得，因此无法实施相应的抽样测试。审计受限。
手动/预防性
《IP地址管理作业指导书》SH_ITGC_ATDP_44
《IP地址申请表》SH_ITGC_ATDP_39
0507003
如何对内部网络进行相应设计？（如：域的逻辑隔离、使用虚拟局域网、信任关系和远程计算机的认证等）
内部网络系统设计时，必须遵循信息系统的安全需求和网络安全设计原则，以保证银行信息的安全。
1．查看正式的网络安全区域设计规范，规范中应包括以下内容：
- 网络安全区域的划分原则；
- 各安全区域间的边界防护方式；
- 防火墙策略设置原则。
2．查看实际的网络连接拓扑图，检查实际的网络连接是否符合设计规范。
1.通过查看《中国工商银行计算机信息系统安全体系规范》(SH_ITGC_ATDP_36)了解到“ 安全域的划分应该遵循以下原则：1）应当根据网络上应用系统分类、地理位置、连接性质和应用系统安全等级，将网络划分为适当的网络安全域，安全域要求必须具备清晰的安全边界；2)网络安全域应相对独立，保证在安全域边界采取一致的安全防护功能；3)在同一个安全域内必须能够实现统一的安全管理，同一个安全域内的网络管理和维护职责应该隶属于同一个管理机构；4)网络安全域划分应该考虑相关的建设及维护成本以及对网络系统性能的影响。”
通过查阅《数据中心网络安全区域设计规范》(SH_ITGC_ATDP_36)，了解到将数据中心应用系统服务器分为4个网络安全层次，分别对应4个由高到低的安全防护等级，其中1级-核心层、2级-应用层、3级-隔离层、4级-接入层。确定数据中心局域网系统分为7个独立的物理网络区域：Intranet接入网、Extranet接入网、Internet接入网、隔离一网、隔离二网、业务一网、业务二网。其中，3个接入网对应网络安全区域模型的接入层，2个隔离网对应隔离层，2个业务网对应应用层和核心层；
通过与网络部麻艳阳的访谈，我们了解到区域与区域之间必须由两组防火墙作为隔离措施。并且如果数据包的传输不通过防火墙的话，只有通过IDS才可以被发现。
根据与数据中心（上海）网络部尹祚炜的访谈，我们了解到：
数据中心（上海）网吧与Internet接入之间安装了一个NetScreen防火墙，并且对这个防火墙有一个冷备份。
数据中心（上海）中间业务域域外网之间安装了一个NetScreen防火墙，并且对这个防火墙有一个冷备份。
2. 我们于2006年9月6日于安全部现场查看了数据中心（上海）网络拓扑图及其《版本变更说明》(SH_ITGC_ATDP_58)。其中包括以下内容：
更新记录（更新人，更新网络结构，版本号，发布日期，更新内容）
IP地址
端口号
网络设备图示
网络设备连接
拓扑图包括：业务一网，业务二网，接入一网，接入二网，业务一网防火墙，业务二网防火墙，接入一网防火墙，接入二网防火墙，OA网，OA防火墙，上海分行接入，
通过查看实际的网络连接拓扑图，符合《网络安全区域设计规范》的层次结构。
未发现例外事项。
通过查阅《数据中心网络安全区域设计规范》(SH_ITGC_ATDP_45)，了解到需要部署9个IDS探针，分别监控Intranet接入网边界防火墙内侧两个端口、Extranet接入网边界防火墙内侧两个端口和外侧一个端口、Internet接入网边界防火墙内侧和外侧各一个端口,两个应用层防火墙的内侧端口。这些IDS探针的集中管理端部署在ECC管理网。考虑到ECC管理网的特殊性，需要在ECC管理网防火墙内侧部署一个IDS探针，以保护ECC管理网的安全。这些IDS探针的处理能力与其监控的防火墙端口有关，千兆的防火墙端口需要千兆的IDS探针来监控。另外，考虑到网络的冗余部署，不仅需要对主防火墙进行监控，同样也需要对辅防火墙进行监控，因此，总的IDS探针的需求量是16个。
根据与安全部虞明城的访谈了解到，数据中心（上海）正在按照规范中规定的探针数目部署IDS探针，但是作为项目尚未实施完成。
数据中心（上海）IDS目前有三个探针，分别放在以下的网域中：
Internet 网吧域(百兆IDS)
中间业务接入域（目前只部署了上海分行的中间业务接入，其他第三方中间业务接入区正在部署千兆的IDS）
全行接入域(千兆IDS)
因此缺乏发现跨域非法传输数据的机制。
发现例外事项
缺乏发现跨域非法传输数据的机制。
手动/预防型
缺乏发现跨域非法传输数据的机制。
根据制度要求设置IDS sensor
《中国工商银行计算机信息系统安全体系规范
SH_ITGC_ATDP_36
网络拓扑图及《版本变更说明》SH_ITGC_ATDP_58
《数据中心网络安全区域设计规范》SH_ITGC_ATDP_45
0507004
同上
同上
1．查看安全部门定期对可以同时访问多个域的网络设备的扫描检查记录。
1、经过安全部周澄访谈，安全部在2005年10月使用TMVS工具对双网卡访问的服务器检查，其中发现数据中心（上海）有一台服务器上同时安装了两个网卡，分别可以访问生产、办公网段。并且在《安全检查情况通报（2005年第086期）》(SH_ITGC_ATDP_34) 进行了通报。
具体请参见外部文档安全检查情况通报（SH_ITGC_ATDP_34）
发现例外事项
安全部不会定期对可以同时访问多个域的网络设备的扫描检查。
兼有手动与自动控制/预防性和发现型兼有
安全部不会定期对可以同时访问多个域的网络设备的扫描检查。
对中心内可以同时访问多个域的网络设备做定期扫描检查，防止网络非法访问。
《安全检查情况通报（2005年第086期）》SH_ITGC_ATDP_34
0507005
同上
同上
1．访谈相关部门负责人，了解制定了哪些远程访问管理规定和流程，查看相关管理规定。
2．访谈网络管理人员，了解远程访问的相应控制。
3．查看远程访问的用户权限清单，抽样测试其中X个用户的审批记录。
4．查看X份远程访问日志检查记录。
1. 通过查看《中国工商银行计算机信息系统安全体系规范》(SH_ITGC_ATDP_36)了解到“需要对远程访问进行控制，控制内容主要包括：
1）远程访问必须经过管理层的批准，所有者的授权，以及安全管理人员的审核；授权时应当考虑进行远程访问的必要性，信息的敏感性，以及内部系统的敏感性，严格限制访问的范围；
2）只开放必须的协议和端口；
3）对特定服务设备只允许被授权的点进行远程访问，其访问路径应该被监控；重要设备不允许远程访问；
4）远程用户必须通过安全网络接口才能访问内部网；
5）对远程访问设备操作必须有相应的记录；
6）禁止非授权人员使用远程访问设备对内部系统进行访问；
7）对远程访问记录必须定期审计；
8）远程访问结束时，必须收回访问权限。
通过查看《网络安全管理程序》(SH_ITGC_ATDP_40)，我们了解到远程访问可以通过拨号和VPN的方式进行。
2．通过访谈网络部麻艳阳，我们了解对于由数据中心（上海）外访问数据中心（上海）的办公网可以通过以下两种方式：
- 回拨：只有数据中心各个部门经理和副经理以及数据中心总经理等一些高级管理层（40至50人）拥有拨号权限。他们通过数据中心外的普通电话拨打数据中心的特殊电话。之后，将电话挂断等待数据中心进行回拨。从而建立与数据中心办公网的连接。
- VPN：只有数据中心各个部门经理和副经理以及数据中心总经理等一些高级管理层（40至50人）拥有VPN接入权限。他们通过宽带上网访问特定网络地址，从而建立与数据中心办公网的连接。
对于远程访问数据中心（上海）生产网，则只能通过回拨方式。其申请审批流程如下：
账户申领：需求方向ECC提出申请，告知ECC总值班回拨电话-〉由ECC开启密码信封（包括：账号及密码）-〉网络部门负责激活相应的端口
当远程访问账户被激活后， ECC向拨号人进行回拨。拨号人员通过prod1-d 至prod10-d利用静态认证系统，之后通过prod1-v至prod10-v利用加密数据传输（VPDN）传输数据。拨号人通过身份验证后，可以对系统进行远程控制。-〉操作完成后，需求方通知ECC总值班-〉ECC总值班通知网络部关闭相应账号并通知安全部门更改密码。
3．我们现场查看了安全一部保管的防火墙密码信封，发现数据中心（上海）内所有防火墙的用户均使用同一用户名（NETSCREEN）和密码。防火墙用户名和密码保存在密码信封中，并且在每次申领后将统一更改所有防火墙用户的密码。
发现例外事项
中心为了方便保管和更改防火墙口令，将所有防火墙的口令设置成同一密码。
2006年9月5日，我们从ACS 系统中现场抽取了20份远程访问用户。其中包括10份远程访问生产网的应急用户和10份远程访问OA的用户。
发现例外事项
在所抽取远程访问用户的20份样本中，发现19个用户缺少用户申请单。
4. 根据与安全部徐文的访谈了解到，网络部ACS系统日志保存3个月的用户访问日志以用于追溯用户的非法访问。由于本次审计期间为2005年6月1日至2006年6月30日，网络部仅保存了审计期间内一个月的文档，因此我们在2006年9月5日抽取了5日的ACS访问日志作为样本。
未发现例外事项。
兼有手动和自动控制/预防性和发现型兼有
1.中心为了方便保管和更改防火墙口令，将所有防火墙的口令设置成同一密码。
2．在所抽取远程访问用户的20份样本中，发现19个用户缺少用户申请单。
1. 建议更改防火墙本地管理员用户的密码，对不同的防火墙使用不同的密码。
2. 建议任何网络用户的变更都严格遵循既定的变更流程，在Help desk上进行申请审批，并附上变更的详细信息。
《中国工商银行计算机信息系统安全体系规范》SH_ITGC_ATDP_36
《网络安全管理程序》
SH_ITGC_ATDP_40
0507006
制定了哪些网络设备管理制度？
制定完善的网络设备管理制度，以确保网络设备的安全。
1．查看网络设备清单，检查清单中是否包含以下内容：
- 设备名称
- 设备型号
- 设备放置位置
- 设备管理部门和责任人
2．查看网络设备（管理）用户清单，抽样查看X个用户的权限设置情况是否与工作职责相符。
1. 通过查看网络设备清单(SH_ITGC_ATDP_65)（网络部2006年8月29－9月3日提供），我们发现清单中包括设备名称、设备型号、设备用途、IP地址、设备管理部门等信息。但是，设备清单中没有明确的设备放置位置，也没有指明设备的责任人。发现例外事项。
2. 通过2006年8月28－31日访谈网络部二部经理麻艳阳，我们了解到数据中心（上海）使用ACS系统统一管理所有网络设备上的管理用户。我们于2006年9月4日现场查看了ACS中的网络设备管理用户列表，发现超过50个。根据抽样原则，我们随机抽取了20个网络设备上的管理用户，确认权限设置都与用户持有人的工作职责相符；但是，我们发现其中19个ID没有在Help desk上进行申请审批。发现例外事项。
手动/预防性
设备清单中没有明确的设备放置位置，也没有指明设备的责任人。
对每一个网络设备都填上设备放置位置和负责人/岗位的名称。
网络设备清单
SH_ITGC_ATDP_65
0507007
同上
同上
1．查看有关网络硬件设备的配置流程规范；
2．了解目前是不是以一个安全的方法对网络设备进行配置。
3．对参数修改操作进行抽样，检查申请审批流程是否符合管理规范。
1. 通过查阅《网络安全管理程序》(SH_ITGC_ATDP_40)（网络部于2006年8月28－31日提供），我们了解到网络硬件设备的配置遵循生产变更流程，由申请人在Help desk上提出书面申请，经过申请部门和网络部的领导审批方能实施。关于生产变更流程和相关制度的介绍请参见0504002。
2. 通过2006年8月28－31日与网络部麻艳阳的访谈，我们了解到只能通过ACS对网络配置信息进行修改。
首先，在Console Server上使用ACS用户和密码登录。对ACS上的用户的抽样测试请参见0507006。
然后，采用TOKEN卡进行一次性密码认证，之后才能进行配置修改。
据麻艳阳介绍，TOKEN卡是由网络部值班人员持有的，在交接班时进行TOKEN卡的交接。但是，我们发现值班人员的值班用户和令牌在值班换班时无交接手续。按照《网络用户管理作业指导书》(SH_ITGC_ATDP_41)中的要求在交接用户和令牌时应填写《网络值班用户使用登记表》。发现例外事项。
3. 网络设备参数变更是网络变更的一种，实施流程和抽样请参见0507001。
手动/预防型
值班人员的值班用户和令牌在值班换班时无交接手续。按照《网络用户管理作业指导书》中的要求在交接用户和令牌时应填写《网络值班用户使用登记表》。
建议在值班交接时增加值班用户和令牌的交接手续，保留书面的交接记录。
《网络安全管理程序》
SH_ITGC_ATDP_40
《网络用户管理作业指导书》SH_ITGC_ATDP_41
0507008
如何对内部网络进行监控？
对内部网络进行监控及时发现安全隐患。
1．访谈相关部门负责人，了解制定了哪些网络监控报警机制及安全事件响应流程，采用哪些网络监控设备和工具；
2．查阅X天的网络监控记录，追踪其中异常事件的后续处理措施（如：违反访问控制策略的连接尝试，或用户登录失败次数超出阀值等）；
1. 通过访谈网络三部副经理尹祚炜访谈，我们了解到：
NETCOOL
ECC有两种方式对网络进行实时监控，包括：
- NetCool
- 运行脚本监控(Check List)
网络部门通过NetCool工具对Sys Log进行管理。NetCool工具记录所有Information级别以上的事件，并且这些记录会在系统中保存3个月。Sys Log 每日由网络部值班人员进行实时监控，每周汇总一周的日志，如发现异常会当作事件处理。
对于任何事件和事故将在HelpDesk系统中建事件单，并由网络部负责确认事件发生原因，而后采取相应措施。最后在HelpDesk中将相应事件单进行更新（关闭事件单）。但是我们发现网络部值班人员未接受过与网络Sys Log相关的安全培训。发现例外事项
我们于2006年9月4日抽取了20份告警问题处理记录，具体请参见附件：
其中以NetCool和CheckList两种方式监控发现的事件信息均由NetCool系统进行分级（1-6级），并且所有事件信息（包括性能告警）会同时发送到网管平台的事件数据库。5级以上事件将自动送到综合事件监控平台（ECC集中告警平台），再由由ECC总值班在HelpDesk中统一分派。通过与ECC总值班的访谈，了解到NetCool每天发现的事件信息共有100+条，其中5级以上的事件告警很少，每月10+条。
我们在2006年9月1日随机抽取了审计期间内20天的NetCool事件记录，其中包括10条CheckList检查记录和10条NetCool检查记录。监控工具NETCOOL生成的报告中由CHECKLIST报送的信息会传送到NETCOOL,信息前将标注CE，所有关注的告警信息会记录到数据中心（上海）网络运行日报。
未发现例外事项。
入侵检测监控：
根据访谈安全部陈杰，了解到数据中（上海）采用了采用安氏领信版本的IDS作为入侵检测工具，其部署了3个sensor:
- 网吧域里安装了一个百兆sensor
- 中间业务接入域里安装了一个百兆sensor
- 全行接入域里安装了一个千兆sensor
如果在IDS中发现事件，将事件手工放到HelpDesk系统中。
我们放谈了安全部IDS管理员陈杰，了解到他还未接受过任何关于IDS系统的正式培训。
发现例外事项
安全部IDS监控岗未接受过任何关于IDS系统的正式培训。
IDS扫描工具，每日有监控明细表，每月有分析月报。每月第一工作日使用IDS工具备份日志到本地硬盘。每月必须关注的事件有2-3个，通过电话和邮件和相关部室确认。
我们于2006年9月1日在数据中心（上海）安全部分别抽取3份了网络入侵监测运行情况明细表（月报）和
网络入侵监测分析报告（月报）。具体请参见附件：
未发现例外事项。
非法内网外联
根据与安全部的韦应春的访谈, 了解到内网非法外联有”中华箭1号”查询系统（网络非法外联监控管理系统）进行实时告警，由安全部非法外联监控岗负责监控。当发生外联事件时，根据系统显示的主机IP地址、主机MAC地址、开始时间、结束时间、事件描述和发生日期，立即采取电话、邮件或送达等方式通知网络部。由网络部门查找发生外联的具体设备和部门，并写出具体的情况说明，交给安全部，再由安全部整理后通报总经理室。
我们于2006年9月5日于网络部现场查看该系统，发现自2003年3月份以来中心仅发生了23次非法外联事件，其中2005年未发生一起事件，2006年以来仅发生的一起事件（2006年1月16日，具体外联时间为11：29：47 — 11：37：13），并已解决。
未发现例外事项。
兼有自动和手动控制/预防性和发现型兼有
1. 安全部IDS监控岗未接受过任何关于IDS系统的正式培训。
2．网络部值班人员未接受过与网络Sys Log相关的安全培训。
1&2. 对于实施检查的人员，安排专业的技术培训。
0508000
外围网络安全管理
0508001
建立外网联接管理制度。
制定外网联接管理制度，用以评估和审批每一个外网联接。
1．访谈相关部门负责人，了解相关部门制定了哪些外网联接管理制度、流程和技术规范，以及这些制度和流程是如何与相关的员工进行沟通的。
2．查看相关的制度、流程、技术方案和安全规范。
3．查看所有外网联接的清单，检查现有的外网联接是否都经过了相关部门的审批。
1. 通过我们与数据中心（上海）网络部尹祚炜的访谈，我们了解到针对外网联接制定了《中国工商银行计算机信息系统安全体系规范》(SH_ITGC_ATDP_36)、《中国工商银行信息系统运行管理制度（）》之《安全管理办法网络非法外联监测实施细则》(SH_ITGC_ATDP_38)和数据中心（上海）制定的《非法内网外联管理作业指导书》(SH_ITGC_ATDP_42)和《网络安全管理程序》(SH_ITGC_ATDP_40)。如0502002和0502003中提到的，这些制度都通过正式的公文和邮件下发给相关人员，促进相关人员进行学习。具体流程及抽样请参见0502002和0502003。
2. 通过查看《中国工商银行计算机信息系统安全体系规范》(SH_ITGC_ATDP_36)、《中国工商银行信息系统运行管理制度（）》之《安全管理办法网络非法外联监测实施细则》(SH_ITGC_ATDP_38)（2006年2月总行统一下发）和数据中心（上海）制定的《非法内网外联管理作业指导书》(SH_ITGC_ATDP_42)（数据中心上海于非现场审计期间提供，即2006年8月14－19日），我们了解到其中规定
必须严格管理内部网络与因特网的连接。因特网浏览网络与内部网络需要进行物理隔离；
对于必须建立连接的情况需要使用安全控制设备进行可信的逻辑隔离。
网络与因特网进行连接的部分必须是被证明与授权业务有关的。在与因特网的接口处必须放置防火墙等安全设备。
3. 我们于2006年9月4日查看了所有外网联接的清单，发现共有5个连接。我们查看了这5份样本，追溯回原始的申请表，确认都经过了相关部门的审批。详情请参见附件。
未发现例外事项。
手动/预防性
《中国工商银行计算机信息系统安全体系规范》SH_ITGC_ATDP_36
《安全管理办法网络非法外联监测实施细则》SH_ITGC_ATDP_38
《非法内网外联管理作业指导书》SH_ITGC_ATDP_42
《网络安全管理程序》SH_ITGC_ATDP_40
0508002
如何对外网连接进行控制？
对外网联接采取严格控制，以保证银行信息安全。
1．查看防火墙策略，并访谈相关部门负责人，了解防火墙策略是如何与业务信息流相匹配的；
2．将实际的防火墙策略和外网联接的有关技术方案、安全规范进行比较， 检查两者的一致性；
3．抽查防火墙策略和相关技术文档的变更审批程序。
1&2.审计受限：由于防火墙策略属机密文档，数据中心（上海）不能提供。
3. 防火墙策略的变更是一种网络变更。变更流程及抽样请参见0507001。
兼有自动和手动控制/预防性
审计受限：由于防火墙策略属机密文档，数据中心（上海）不能提供。
0508003
保护内网不被外网未经授权的访问？
采取安全措施，保护内网不被外网未经授权的访问和入侵。
1．访谈相关部门负责人，了解目前使用了哪些网络安全设备和工具？
2．查看安全设备的布署结构图和相关配置、维护文档， 确认其与总体网络安全方案和规范一致，并从中抽取X份。
1&2. 网络区域的划分和访问控制请参见0507003，网络监控工具的工作流程和抽样请参见0507008。
预防性
0508004
同上
同上
1．查看网络设备安全配置的技术标准，了解其中规定了哪些安全配置要求；
2．抽样查看X台放置于外网边界的路由器或/和交换机的实际配置，检查其是否符合上述标准。
1&2. 审计受限：由于网络设备配置的技术标准属机密文档，数据中心（上海）不能提供。
预防性
审计受限：由于网络设备配置的技术标准属机密文档，数据中心（上海）不能提供。
0508005
同上
同上
1．访谈相关部门负责人，了解现有制度是否要求对防火墙策略、日志和其他网络安全事件日志进行保存和定期检查；
2．抽样检查相关部门对防火墙策略、日志、异常事件和安全事件日志等进行定期检查的记录。
1. 根据2006年8月28－31日与安全部虞明城和网络部二部经理麻艳阳的访谈，我们了解到
防火墙的日志分别保存在Syslog日志服务器和NetCool Object Server上，并且保存3个月。
发现例外事项。Syslog没有保存在只读媒介上，而且保存时间不够长。
每个月的第一个工作日网络部会将所有网络设备（包括：路由器，交换机，防火墙和负载均衡）的配置文件保存到Notes园地进行备份，保存一年。但是我们发现，网络部的所有人员都有访问该园地的权限。这增大了配置信息被泄漏的风险。发现例外事项
据虞明城介绍，安全部对网络安全进行检查。
每月抽取一天检查当日的Syslog，对其中记录的网络变更追溯回原始的申请表，确保当日没有非法的网络变更。
每月抽查一台防火墙，检查防火墙配置策略是否符合中心策略。
对于检查中发现的问题，都通过《安全检查情况通报》进行报告，并且追踪促进问题的整改。
发现例外事项。目前安全部仅对网络配置变更进行抽查；未落实发现网络设备配置非授权变更的机制，即在网络配置检查中缺乏对基线（baseline）的检查，无法及时发现未授权的网络配置变更。而且，未对TrafficLog进行定期检查。
2．由于安全部的检查是每月进行，根据抽样原则，我们随机抽取了5个月的检查记录，确认当月安全检查人员都按照1中提到的范围实施了安全检查工作，没有发现重大问题。详情请参见附件。
手动/预防性和发现型兼有
1. Syslog没有定期备份到只读媒介上，而且保存时间只有3个月。
2. 所有网络设备（包括：路由器，交换机，防火墙和负载均衡）的配置文件均保存在Notes园地。但是，网络部的所有人员都有访问该园地的权限，这增大了配置信息被泄漏的风险
3.目前安全部仅对网络配置变更进行抽查；未落实发现网络设备配置非授权变更的机制，即在网络配置检查中缺乏对基线（baseline）的检查，无法及时发现未授权的网络配置变更。
1. 建议将Syslog备份在只读媒介上，长期保留备份。
2建议加强对网络设备配置文件的访问控制，仅允许授权人员访问配置文件。
3. 建议安全部对防火墙策略、路由器、交换机配置进行定期检查，防止配置的非法变更，确保网络设备配置的合规性。并且对Traffic Log进行定期检查。
0508006
对外网安全防护设备和工具的访问，制定了哪些安全管理制度？
制定安全管理制度，限制对外网安全防护设备和工具的访问。
1．访谈相关部门负责人，了解访问关键安全设备和工具 （包括防火墙） 的安全管理规定和审批流程；
2．抽样检查X个有权访问安全设备和工具的员工，查看其权限申请表，确定与其实际权限设置相符，并检查其权限是否与岗位工作职责相符。
1&2.网络设备的访问控制由ACS统一管理，关于ACS的相关控制以及针对网络设备访问权限的抽样测试请参见0507006
兼有自动和手动控制/预防性
0508007
如何监控外部网络连接中的安全隐患？
通过对外部网络连接的实时监控，相关部门能及时发现安全隐患。
1．查看自动化监控工具的布署情况，确认其是否按照已制定的网络安全方案进行布署和配置；
2．访谈相关部门负责人，了解对于外网安全事件的应对和处理流程，该流程应包含以下内容：
- 安全事件的日常监控；
- 事件确认和报告流程；
- 发生安全事件的应急处理流程；
- 事后分析、总结及与有关单位（如公安机关、网络运营商、合作伙伴）的沟通协调事宜。
3．访谈网络部门的员工，了解员工对安全事件响应流程的熟悉程度；
4．抽样检查监控工具生成的报告，以及相关人员审核监控报告的证据，检查对于监控报告中反映的异常事件，是否进行追踪和调查。
1&2&3请参见0607008
4、根据与安全部虞明城的访谈，了解到告警事件
安全事件的处理流程是按照总行《事件管理办法生产故障及安全事件实施细则》要求报告安全事件，但对安全事件的统一受理和处理，数据中心（上海）从2006年8月才开始接管，以前由ART小组负责安全事件的处理。安全事件通过信息安全邮箱进行信息传递。
由于采用相同的网络监控工具实施对内网和外网的监控，没有单独的实施安全事件监控的工具，因此将安全事件监控报告改为告警事件，抽样同0507008。
未发现例外事项。
兼有手动和自动控制/发现型
0508008
同上
同上
1．查看自动化监控工具的布署情况，确认其是否按照相关规定进行布署和配置；
2．访谈相关部门负责人，了解网络性能异常和故障的处理流程，应包含以下内容：
- 性能参数的日常监控；
-问题和故障的确认和报告流程；
- 发生故障事件的应急处理流程；
- 事后分析、总结。
3．访谈网络部门人员，了解员工对网络性能监控流程和故障响应流程的熟悉程度；
4．抽样检查X份监控工具生成的报告，以及相关人员审核监控报告的证据，检查对于监控报告中反映的异常事件，是否进行追踪和调查。
1&2&3&4 请参见0607008
兼有手动和自动控制/发现型
第 PAGE 1 页，共 NUMPAGES 74 页
Sheet1
ICBC数据中心（上海）对程序和数据的访问抽样测试
权限变更的抽样测试
样本总体
测试实施时，数据库层面和操作系统层面的用户
样本量/频率
可以登陆使用的用户（系统自动调用的用户除外）超过200个
测试内容：
是否有用户申请表及相应管理部门的审批；
申请程序是否与管理规定相符；
系统中的权限和申请表中的权限是否一致；
编号 系统 ID 是否有用户申请表？ 是否有适当的审批签字？ 申请程序是否与管理规定相符？ ID权限是否与审批表上列示的权限一致？ 例外事项
1 主机 SJBGAP1 58096 有 符合 一致 无
2 SJBGAP2 58096 有 符合 一致 无
3 SPAYJ01 85797 有 符合 一致 无
4 SPAYJ02 85797 有 符合 一致 无
5 SPAYJ03 85797 有 符合 一致 无
6 SPAYJ04 85797 有 符合 一致 无
7 SPAYJ05 85797 有 符合 一致 无
8 SPAYJ06 85797 有 符合 一致 无
9 SPA1006 76362 有 符合 一致 无
10 SPM0005 79283 有 符合 一致 无
11 SPN0013 76362 有 符合 一致 无
12 SPO0031 76362 有 符合 一致 无
13 SPS0028 131097 有 符合 一致 无
14 SPS0013 76362 有 符合 一致 无
15 SPU000A 83852 有 符合 一致 无
16 solairs super 无 无 不符合 未见申请表 开放平台CM2002系统数据库层面和操作系统层面的用户在helpdesk系统中未见相应有效申请表
17 root 无 无 不符合 未见申请表
18 power 无 无 不符合 未见申请表
19 audit 无 无 不符合 未见申请表
20 admin2 无 无 不符合 未见申请表
21 chenly 无 无 不符合 未见申请表
22 alx super 无 无 不符合 未见申请表
23 root 无 无 不符合 未见申请表
24 oracle 无 无 不符合 未见申请表
25 admin1 无 无 不符合 未见申请表
26 zhup 无 无 不符合 未见申请表
27 chenly 无 无 不符合 未见申请表
28 oracle sys 无 无 不符合 未见申请表
29 system 无 无 不符合 未见申请表
30 ICBCSEC 无 无 不符合 未见申请表
Sheet1
ICBC数据中心（上海）对程序和数据的访问抽样测试
网络设备ID的抽样测试
样本总体
测试实施时，网络设备的所有ID
样本量/频率
由于总数超过200个，根据抽样原则，我们随机抽取了20个样本进行测试
测试内容：
是否有用户申请表及相应管理部门的审批；
用户权限与其职责是否相符。
编号 姓名 ID 权限 变更单号 是否有用户申请表？ 是否有适当的审批签字？ ID权限是否与职责相符？ 例外事项
1 管文慰 DCCSH-RO-USER 69898 无 无 Y 发现例外事项
2 值班用户1 DCCSH-RW-USER 69898 无 无 Y 发现例外事项
3 值班用户2 DCCSH-RW-USER 69898 无 无 Y 发现例外事项
4 张柱宏 DCCSH-RW/RO-USER2 69898 无 无 Y 发现例外事项
5 胡滨 DCCSH-RW/RO-USER1 69898 无 无 Y 发现例外事项
6 李振武 DCCSH-RW/RO-USER2 69898 无 无 Y 发现例外事项
7 尹祚炜 DCCSH-RW-USER 69898 无 无 Y 发现例外事项
8 夏云亭 DCCSH-RW-USER 69898 无 无 Y 发现例外事项
9 麻艳阳 DCCSH-RW-USER 69898 无 无 Y 发现例外事项
10 Checklist用户1 checklist CHECKLIST-USER 70382 无 无 Y 发现例外事项
11 Checklist用户2 CHECKLIST-USER 70382 无 无 Y 发现例外事项
12 沈烨旻 DCCSH-RW-USER 69898 无 无 Y 发现例外事项
13 陆青 DCCSH-RW-USER 69898 无 无 Y 发现例外事项
14 许志恒 DCCSH-RO-USER 88909 无 无 Y 发现例外事项
15 史伟（ECC监控用户） wshi DCCSH-RO-USER 79283 有 有 Y 无例外事项
16 张颖 DCCSH-RO-USER 88909 无 无 Y 发现例外事项
17 林轶 DCCSH-RO-USER 88909 无 无 Y 发现例外事项
18 曹洪涛 DCCSH-RO-USER 88909 无 无 Y 发现例外事项
19 陶佩华 DCCSH-RO-USER 88909 无 无 Y 发现例外事项
20 王睿卿 DCCSH-RO-USER 88909 无 无 Y 发现例外事项
Sheet1
ICBC数据中心（上海）对网络设置变更抽样测试
权限变更的抽样测试
样本总体
2005年6月1日至2006年6月30日之间，网络设备日志中记录的修改网络设置的记录
样本量/频率
变更总次数超过200，根据抽样原则抽取20个样本
测试内容：
查看是否有变更申请表
查看申请表的审批手续是否与制度规定相符
编号 变更执行时间 网络变更的内容 对应的变更单编号 变更单是否经过业务部门审批？ 变更单是否经过执行部门的审批？ 例外事项
1 6/15/05 父TMCM服务器网卡更换 #71905 是 是 无
2 3/15/06 IP电话连接电话银行板卡防火墙策略开通 #110614 是 是 无
3 6/15/05 升级OA拨号路由器软件版本 #71975 是 是 无
4 12/15/05 上海分行INTRANET防火墙版本升级 #99269 是 是 无
5 7/15/05 关于投产WAN防火墙开通策略的变更 #76524 是 是 无
6 9/15/05 关于上海研发部访问AD服务器的紧急变更 #85170 是 是 无
7 2/16/06 开放平台部版本文档机实施BEB备份开通网络防火墙 #106760 是 是 无
8 3/15/06 申请开通数据中心(上海)AS400主机和海外数据中心AS400的防火墙策略 #110290 是 是 无
9 2/15/06 关于银证、银期转账业务的网络变更 #107101 是 是 无
10 12/15/05 关于紧急开放电话银行测试访问权限 #99169 是 是 无
11 1/17/06 联通10G SDH改造 #103713 是 是 无
12 3/15/06 对行业信息库相关策略开log #110379 是 是 无
13 3/18/06 山西分行在SX45RT0B-A1上启用端口变更 #110515 是 是 无
14 3/15/06 关于开通总行视频会议申请系统的变更 #110683 是 是 无
15 6/15/05 cm2002迁移环境准备网络部分配服务器地址 #72005 是 是 无
16 2/15/06 测试新增联通40Minternet线路 #107037 是 是 无
17 6/15/05 关于上海分行测试网段的变更 #72262 是 是 无
18 2/15/06 将新增的一台PCM2003应用服务器加入到F5负载均衡 #112127 是 是 无
19 12/15/05 关于请求紧急开放电话银行测试访问权限 #99364 是 是 无
20 3/15/06 在Internet接入端口采用IDS进行监控 #110401 是 是 无
Sheet1
ICBC数据中心（上海）对程序和数据的访问抽样测试
CM2002上直接更改数据流程的抽样测试
样本总体
2005年6月1日至2006年6月30日之间，Helpdesk中记录的开放平台上在数据库层面直接修改数据的记录，共1585条
样本量/频率
根据抽样原则，我们随机抽取了20个样本
测试内容：
查看申请表的审批手续是否与制度规定相符
编号 Helpdesk的变更编号 变更需求创建时间 直接修改数据的内容 是否有业务部门审批？ 是否有牵头实施部门的审批？ 例外事项
1 126632 6/30/06 修改第三方存管华泰（亚洲）证券前置数据 有 有 无例外事项
2 121876 5/31/06 电子银行中心请协助对银证通异常数据进行冲正 有 有 无例外事项
3 117514 5/10/06 风险拨备系统初始化数据变更 有 有 无例外事项
4 114720 4/12/06 [上海ZQ06-0643]第三方存管数据变更 有 有 无例外事项
5 111933 3/22/06 企业年金基金账户管理信息系统数据变更 有 有 无例外事项
6 109797 3/15/06 天津水泥工业设计研究院变更主机协议号(cm2002) 有 有 无例外事项
7 105730 2/5/06 浙江省分行关于删除CM2002系统下4笔出口押汇合同的变更 有 有 无例外事项
8 102829 1/9/06 保函垃圾数据删除 有 有 无例外事项
9 99812 12/19/05 更改国际融资转贷款借据逾期利率浮动率信息(CM2002-2个） 有 有 无例外事项
10 96834 12/2/05 删除远纺工业（苏州）有限公司11月7日台帐数据 有 有 无例外事项
11 94841 11/23/05 变更上报人行接口库中部分票据业务的数据 有 有 无例外事项
12 92825 11/9/05 贷款处理台账数据调整变更 有 有 无例外事项
13 91316 11/2/05 在CM2002中调整保函业务种类为“国外” 有 有 无例外事项
14 90649 10/27/05 CM2002相关变更 有 有 无例外事项
15 87180 9/28/05 更改授信台账(CM2002) 有 有 无例外事项
16 86667 9/27/05 CM2002票据系统票据买入查询出错 有 有 无例外事项
17 84585 9/16/05 山东分行数据仓库数据恢复申请 有 有 无例外事项
18 80785 8/17/05 变更山东鲁宝食品有限公司2004年12月份报表数据(cm2002系统) 有 有 无例外事项
19 76070 7/13/05 激活CM2002子系统代理行授信用户010800001 有 有 无例外事项
20 70823 6/6/05 陕西清算中心（3700地区）申请变更会计要素管理系统“表外控制标志” 有 有 无例外事项
Sheet1
ICBC数据中心（上海）对程序和数据的访问抽样测试
ACS远程访问用户抽样测试
样本总体
测试远程访问ID，包括其申请审批手续
样本量/频率
测试内容：
审计期间内抽样检查ACS用户访问日志，查看其是否远程访问过生产系统的记录，并核查其是否经过适当审批。
可以远程访问生产网的用户包括：prod1-d … prod10-d 和 prod1-v … prod10-v
编号 日期 是否有远程访问生产网的记录？ 是否有审批记录？ 例外事项
1 5/25/06 N N N
2 6/5/06 N N N
3 6/7/06 N N N
4 6/10/06 N N N
5 6/15/06 N N N
Sheet1
ICBC数据中心（上海）对程序和数据的访问抽样测试
系统监测工具（NetCool）抽样测试
样本总体
2005年6月1日至2006年6月30日之间监控工具netcool生成的报告
样本量/频率
测试内容：
查看书面的审核记录
对于报告中记录的问题，确认是否进行了及时的调查和处理
编号 时间 事件名称 helpdesk记录 对这些问题，是否进行了及时调查处理？ 例外事项 备注
1 6/15/05 到运通中间业务服务器丢包 51838 网络16日3：41报，16日4：15接到运通电话 4：26 恢复 N CHECKLIST ERROR REPORT
2 7/15/05 数据中心（上海）OA防火墙故障 54364 7月15日14：45分创建，14：54解决，7月28日关闭 N 由于防火墙故障CHECKLIST ERROR REPORT记录信息不全,我们抽取了当日的HelpDesk工单，发现相应防火墙故障记录。
3 8/15/05 到广东路由PEER不通 57123 15:53发生，16：05创建，解决时间17：40 关闭时间9月6日 N CHECKLIST ERROR REPORT
4 8/19/05 无关注报警事件 N/A N/A N
5 9/15/05 无关注报警事件 N/A N/A N
6 9/20/05 无关注报警事件 N/A N/A N
7 10/14/05 无关注报警事件 N/A N/A N
8 10/18/05 无关注报警事件 N/A N/A N
9 11/15/05 到运通服务器有丢包 66728 13：35创建，16：05创建，解决时间16：44解决 11月16日关闭 N 由于和运行部交接期间CHECKLIST ERROR REPORT记录信息不全
10 12/15/05 无关注报警事件 N/A N/A N
11 1/16/06 无关注报警事件 N/A N/A N
12 2/15/06 无关注报警事件 N/A N/A N
13 2/20/06 无关注报警事件 N/A N/A N
14 3/15/06 陕西到数据中心（北京）ATM线路丢包 78580 15：20创建工单，15：55关闭 N NETCOOL事件库（CHECKLIST报，自动发送到NETCOOL）
15 3/21/06 无关注报警事件 N/A N/A N
16 3/24/06 深圳到数据中心（上海）延时大 79133 9：22发生事件，9：51创建工单，13：14关闭工单 N 多个事件同一原因的创建1个工单。NETCOOL事件库（CHECKLIST报，自动发送到NETCOOL）
17 4/13/06 无关注报警事件 N/A N/A N
18 4/14/06 无关注报警事件 N/A N/A N
19 5/15/06 无关注报警事件 N/A N/A N
20 6/15/06 数据中心（北京）到数据中心（上海）线路延时大 85971 16:15发生事件，16：19创建工单，16：47解决问题后，二线跟踪问题，7月19日关闭工单。 N NETCOOL事件库（CHECKLIST报，自动发送到NETCOOL）
Sheet2
Sheet3
Sheet1
ICBC数据中心（上海）对程序和数据的访问抽样测试
告警事件处理抽样
样本总体
测试其告警事件处理结果
样本量/频率
50+
测试内容：
审计期间内抽取发现告警信息，以及其处理记录。
编号 日期 问题单号 问题说明 问题级别 是否影响业务 问题处理
1 6/15/05 #51838 运通丢包 5级 无 应用signup后恢复
2 6/15/05 #51836 江西省行上联路由器JXWA01故障 5级 无 已处理
3 7/15/05 #54364 数据中心（上海）OA网络故障 5级 无 防火墙回退到NS1000
4 8/15/05 #57153 支付密码网关连接异常 5级 无 管理员重启后正常
5 8/15/05 #57123 数据中心（上海）到广东路由器1peer不通 3级 影响广东行全辖业务15:00－16:08 关闭交换机后业务逐步恢复正常
6 8/15/05 #57152 山西分行通用网关问题 5级 无 山西分行重启后正常
7 9/15/05 #59432 金卡交易部分超时 5级 影响金卡系统10:10－12:00 银联故障
8 9/15/05 #59427 网银安全问题 3级 无 总行网络处处理
9 11/15/05 #66722 HSM网关连接中断 5级 无 重新连接后恢复
10 11/15/05 #66728 运通服务器有丢包现象 5级 无 已处理
11 12/15/05 #70554 南方环境灾备异常中断 5级 无 已处理
12 1/16/06 #73516 发现假冒ICBC网站 3级 无 总行网络处处理
13 1/16/06 #73467 江西分行A类网关IIJ1031不活 5级 无 切换到备机
14 3/16/06 #78594 北方中心到青岛的网通线路中断 5级 无 网通公司修复
15 5/15/06 #83259 福建省下渡分理处光端机故障 5级 下渡分理处柜面业务无法处理 更换设备后恢复
Sheet2
Sheet3
Sheet1
ICBC数据中心（上海）对程序和数据的访问抽样测试
外网连接的抽样测试
样本总体
审计时存在的所有外网连接
样本量/频率
共5个样本
测试内容：
检查所有外网连接是否有适当的申请审批文档
编号 外网连接 是否有相应的申请审批？ 变更单号 例外事项
1 “银保通“系统（三期）太平保险公司专线任务书的通知 Y 128014 N
2 易方达基金公司专线 Y 124443 N
3 武汉证券专线 Y 101882 N
4 高华证券专线 Y 94153 N
5 美国运通国际股份有限公司线路 Y 75145 N
Sheet1
ICBC数据中心（上海）对程序和数据的访问抽样测试
防火墙配置检查
样本总体
测试远程访问ID，包括其申请审批手续
样本量/频率
月报
测试内容：
是否有用户申请表及相应管理部门的审批；
用户权限与其职责是否相符。
网络安全检查内容清单
《安全情况检查通报》
编号 日期 防火策略文件是否根据中心配置变化(安全情况检查报告防火墙策略检查部分) 抽查一台防火墙检查其配置是否合规（安全情况检查报告 防火墙策略检查部分） SysLog的记录抽查一天察看防火墙策略变更情况 (安全情况检查报告 防火墙日志检查部分） 并会核对当日HelpDesk中的变更单号 例外事项
1 2005年8月 Y Y Y Y N
2 2005年11月 Y Y Y Y N
3 2006年2月 Y Y Y Y N
4 2006年4月 Y Y Y Y N
5 2006年5月 Y Y Y Y N
Sheet1
ICBC数据中心（上海）对程序和数据的访问抽样测试
对监控工具生成安全事件报告的抽样测试
样本总体
2006年4月1日至2006年6月31日之间监控工具生成的报告 （从今年2月份开始）
样本量/频率
测试内容：
查看书面的审核记录
对于报告中记录的问题，确认是否进行了及时的调查和处理
网络入侵监测运行情况明细表（每月，3份）
网络入侵监测分析报告（每月，3分）
编号 时间 是否留下书面审核记录？ 报告中记录的外部网络边界上发生的非授权活动和外部网络安全事件 对这些问题，是否进行了及时调查处理？ 例外事项 备注 明细表包括：CPU使用率，运行状态，告警事件数，
每日进行两次监控（中班：16：30，18：30，20：30
日常：9：30，14：15）
1 4月 Y 疑似攻击事件，经事后确认，为正常事件 Y N 月报：
2 5月 Y 疑似攻击事件，经事后确认，为正常事件 Y N
3 6月 Y 疑似攻击事件，经事后确认，为正常事件 Y N
Sheet1
ICBC数据中心（上海）对程序和数据的访问抽样测试
安全制度和程序的定期更新的抽样测试
样本总体
管理部门制定的一系列安全制度和程序的更新记录，包括操作系统安全、应用系统安全、数据安全、网络安全、物理安全等方面的制度
样本量/频率
测试内容
检查各项安全制度和程序的更新记录是否符合管理部门的要求，更新后的制度是否下发到相关科室
编号 制度颁布方 制度涵盖的方面 制度名称 最近更新日期 更新后的制度是否有下发记录？ 例外事项
1 总行信息科技部颁布 操作系统安全、数据安全、网络安全、物理安全、运行安全等各个方面 《中国工商银行信息系统运行管理制度》 2/9/06 notes邮件通知下发(工银办发[2006]62号) 无例外事项
2 数据中心（上海）制定的细则 操作系统安全 《开放平台服务器用户管理程序》 4/30/06 2006年4月SHDC notes邮件通知 无例外事项
3 《生产系统开放平台服务器用户管理办法》 4/30/06 2006年4月SHDC notes邮件通知 无例外事项
4 《性能分析程序》 4/30/06 2006年4月SHDC notes邮件通知 无例外事项
5 《开放平台生产系统UNIX安全规范》 12/21/05 notes邮件通知下发(工银数沪办邮[2006]号) 无例外事项
6 《主机用户安全管理程序》 7/12/06 notes邮件通知下发(工银数沪办邮[2006]号) 无例外事项
7 《生产环境变更管理程序》 12/22/04 notes邮件通知 无例外事项
8 数据安全制度 《数据安全管理程序》 4/30/06 notes邮件通知下发(工银数沪办邮[2006]号) 无例外事项
9 《业务数据变更程序》 4/30/06 2006年4月SHDC notes邮件通知 无例外事项
10 《主机数据备份作业指导书》 3/14/06 2006年3月SHDC notes邮件通知 无例外事项
11 《开放平台数据备份作业指导书》 11/25/05 2005年11月SHDC notes邮件通知 无例外事项
12 网络安全制度 《非法内网外联管理作业指导书》 9/15/03 notes邮件通知 无例外事项
13 《防病毒管理程序》 4/30/06 notes邮件通知下发(工银数沪办邮[2006]号) 无例外事项
14 《网络安全管理程序》 3/14/06 2006年3月SHDC notes邮件通知 无例外事项
15 《防火墙管理作业指导书》 4/30/06 2006年4月SHDC notes邮件通知 无例外事项
16 《网络用户管理作业指导书》 4/30/06 notes邮件通知下发(工银数沪办邮[2006]号) 无例外事项
17 物理安全制度 《机房安全管理程序》 8/2/05 2005年8月SHDC notes邮件通知 无例外事项
18 《机密部件管理程序》 3/14/06 2006年3月SHDC notes邮件通知 无例外事项
19 《门禁卡管理程序》 10/18/05 2005年10月SHDC notes邮件通知 无例外事项
20 《商密部件管理程序》 8/2/05 2005年8月SHDC notes邮件通知 无例外事项
21 《外来人员安全管理程序》 4/30/06 notes邮件通知下发(工银数沪办邮[2006]号) 无例外事项
22 《消防管理程序》 7/16/03 notes邮件通知 无例外事项
23 《园区安全管理程序》 8/2/05 2005年8月SHDC notes邮件通知 无例外事项
Sheet1
ICBC数据中心（上海）对程序和数据的访问抽样测试
远程访问
样本总体
测试远程访问ID，包括其申请审批手续
样本量/频率
测试内容：
是否有用户申请表及相应管理部门的审批；
用户权限与其职责是否相符。
编号 姓名 生产/OA 动态 静态 状态 组 变更单号 是否有用户申请表？ 是否有适当的审批签字？ ID权限是否与职责相符？ 例外事项 备注
1 生产应急拨号用户1 生产 Prod1-d Prod1-v Disable VPN-USER 105473 N N Y Y
2 生产应急拨号用户2 生产 Prod2-d Prod2-v Disable VPN-USER 105473 N N Y Y
3 生产应急拨号用户3 生产 Prod3-d Prod3-v Disable VPN-USER 105473 N N Y Y
4 生产应急拨号用户4 生产 Prod4-d Prod4-v Disable VPN-USER 105473 N N Y Y
5 生产应急拨号用户5 生产 Prod5-d Prod5-v Disable VPN-USER 105473 N N Y Y
6 生产应急拨号用户6 生产 Prod6-d Prod6-v Disable VPN-USER 105473 N N Y Y
7 生产应急拨号用户7 生产 Prod7-d Prod7-v Disable VPN-USER 105473 N N Y Y
8 生产应急拨号用户8 生产 Prod8-d Prod8-v Disable VPN-USER 105473 N N Y Y
9 生产应急拨号用户9 生产 Prod9-d Prod9-v Disable VPN-USER 105473 N N Y Y
10 生产应急拨号用户10 生产 Prod10-d Prod10-v Disable VPN-USER 105473 N N Y Y
11 虞伟 OA nf-yuwei nf-yuwei-v Enable VPN-USER 89090 N N Y Y
12 史伟 OA nf-shiwei nf-shiwei Enable VPN-USER 89090 N N Y Y
13 夏云亭 OA nf-xiayt nf-xiayt-v Enable VPN-USER 89090 N N Y Y
14 张俊 OA nf-zhangjun nf-zhangju-v Enable VPN-USER 89090 N N Y Y
15 任继尧 OA nf-renjy nf-renjy-v Enable VPN-USER 书面申请(2003年9月2日) Y Y Y N
16 王开 OA nf-wangkai nf-wangkai-v Enable VPN-USER 89090 N N Y Y
17 黄颢 OA nf-huanghao nf-huanghao-v Enable VPN-USER 89090 N N Y Y
18 姚欣 OA nf-yaoxin nf-yaoxin-v Enable VPN-USER 89090 N N Y Y
19 刘瑶 OA nf-liuyao nf-liuyao-v Enable VPN-USER 89090 N N Y Y
20 徐刚 OA nf-xugang nf-xugang-v Enable VPN-USER 89090 N N Y Y
Sheet1
ICBC数据中心（上海）对程序和数据的访问抽样测试
直接更改数据流程的抽样测试
样本总体
2005年6月1日至2006年6月30日之间，数据库日志中记录的直接修改数据的记录
样本量/频率
变更总次数超过200，根据抽样原则抽取20个样本
测试内容：
查看是否有变更申请表
查看申请表的审批手续是否与制度规定相符
编号 变更执行时间 直接修改数据的内容 对应的变更单编号 变更单是否经过业务部门审批？ 变更单是否经过执行部门的审批？ 例外事项
1 6/3/05 江苏修改通知存款账户状态 #70459 是 是 无例外事项
2 4/14/06 浙江调整牡丹卡卡片信息中的“受理网点号” #115084 是 是 无例外事项
3 6/15/05 广东调整贷款发放日期限定标志 #72314 是 是 无例外事项
4 7/8/05 在生产环境修改通兑起止时间 #75495 是 是 无例外事项
5 4/14/06 北京分行修改灵通卡卡片信息中活期账户的挂卡状态 #115129 是 是 无例外事项
6 8/12/05 浙江410调整往来户账户状态 #79874 是 是 无例外事项
7 8/25/05 浙江脱离协定存款账户A户与B户关系 #81123 是 是 无例外事项
8 10/14/05 广西桂行405修改信用卡个人客户编号和卡片的证件号码 #88608 是 是 无例外事项
9 11/15/05 浙江调整国债发行结束日和最后计息截止日 #93586 是 是 无例外事项
10 12/16/05 广东调整账户状态 #98816 是 是 无例外事项
11 1/5/06 修改准贷证状态 #102149 是 是 无例外事项
12 4/14/06 福建调整往来户费用的收取标志 #115373 是 是 无例外事项
13 2/18/06 参数表记录删除 #107511 是 是 无例外事项
14 3/19/06 在生产机上维护通汇机构表 #110942 是 是 无例外事项
15 4/14/06 湖北调整个贷帐户信息 #113821 是 是 无例外事项
16 4/20/06 上海调整帐户属性 #115895 是 是 无例外事项
17 5/26/06 青岛市分行调整个人结算帐户保留金额变更 #121159 是 是 无例外事项
18 6/22/06 修改专用卡年费标志、有效期 #124693 是 是 无例外事项
19 5/12/06 陕西分行更改内部、表外户状态变更 #118995 是 是 无例外事项
20 4/14/06 河南许昌分行申请解除个人账户保留金额 #115362 是 是 无例外事项
Sheet1
编号 制度颁布方 制度涵盖的方面 制度名称 资料提供方 资料提供时间
1 总行信息科技部颁布 操作系统安全、数据安全、网络安全、物理安全、运行安全等各个方面 《中国工商银行信息系统运行管理制度》 notes邮件通知下发(工银办发[2006]62号) 2006年2月
2 数据中心（上海）制定的细则 操作系统安全 《开放平台服务器用户管理程序》 数据中心（上海）统一提供的 非现场审计期间（2006年8月14－18日）
3 《生产系统开放平台服务器用户管理办法》 数据中心（上海）统一提供的 非现场审计期间（2006年8月14－18日）
4 《性能分析程序》 数据中心（上海）统一提供的 非现场审计期间（2006年8月14－18日）
5 《开放平台生产系统UNIX安全规范》 数据中心（上海）统一提供的 非现场审计期间（2006年8月14－18日）
6 《主机用户安全管理程序》 数据中心（上海）统一提供的 非现场审计期间（2006年8月14－18日）
7 《生产环境变更管理程序》 数据中心（上海）统一提供的 非现场审计期间（2006年8月14－18日）
8 数据安全制度 《数据安全管理程序》 数据中心（上海）统一提供的 非现场审计期间（2006年8月14－18日）
9 《业务数据变更程序》 数据中心（上海）统一提供的 2006年8月24日
10 《主机数据备份作业指导书》 数据中心（上海）统一提供的 非现场审计期间（2006年8月14－18日）
11 《开放平台数据备份作业指导书》 数据中心（上海）统一提供的 非现场审计期间（2006年8月14－18日）
12 网络安全制度 《非法内网外联管理作业指导书》 数据中心（上海）统一提供的 非现场审计期间（2006年8月14－18日）
13 《防病毒管理程序》 数据中心（上海）统一提供的 非现场审计期间（2006年8月14－18日）
14 《网络安全管理程序》 数据中心（上海）统一提供的 非现场审计期间（2006年8月14－18日）
15 《防火墙管理作业指导书》 数据中心（上海）统一提供的 2006年8月29日
16 《网络用户管理作业指导书》 数据中心（上海）统一提供的 非现场审计期间（2006年8月14－18日）
17 物理安全制度 《机房安全管理程序》 数据中心（上海）统一提供的 非现场审计期间（2006年8月14－18日）
18 《机密部件管理程序》 数据中心（上海）统一提供的 非现场审计期间（2006年8月14－18日）
19 《门禁卡管理程序》 数据中心（上海）统一提供的 非现场审计期间（2006年8月14－18日）
20 《商密部件管理程序》 数据中心（上海）统一提供的 非现场审计期间（2006年8月14－18日）
21 《外来人员安全管理程序》 数据中心（上海）统一提供的 非现场审计期间（2006年8月14－18日）
22 《消防管理程序》 数据中心（上海）统一提供的 非现场审计期间（2006年8月14－18日）
23 《园区安全管理程序》 数据中心（上海）统一提供的 非现场审计期间（2006年8月14－18日）
Sheet1
ICBC数据中心（上海）对程序和数据的访问抽样测试
特权用户的交接记录抽样测试
样本总体
测试实施时，安全部保管的特权用户
样本量/频率
共14个
测试内容：
查看交接时间，确认交接双方是否签字
编号 ID 交接时间 交出方系统部是否签字？ 接收方安全部是否签字？ 例外事项
1 IBMUSER 9/8/05 是 是 无例外事项
2 IBMUSER2 9/8/05 是 是 无例外事项
3 IBMSE01 9/8/05 是 是 无例外事项
4 IBMSE02 9/8/05 是 是 无例外事项
5 IBMSE03 9/8/05 是 是 无例外事项
6 IBMSE04 9/8/05 是 是 无例外事项
7 SPAY01 9/22/05 是 是 无例外事项
8 SPAY02 9/22/05 是 是 无例外事项
9 SPAY03 9/22/05 是 是 无例外事项
10 SPAY04 9/22/05 是 是 无例外事项
11 SPAY05 9/22/05 是 是 无例外事项
12 SPAY06 9/22/05 是 是 无例外事项
13 DBSADM1 9/8/05 是 是 无例外事项
14 DBSADM2 9/15/05 是 是 无例外事项
Sheet1
ICBC数据中心（上海）对程序和数据的访问抽样测试
对防病毒服务器自动扫描报告的抽样测试
样本总体
2005年6月1日至2006年6月30日之间相关管理人员定期检查防病毒服务器的自动扫描报告的审核记录
样本量/频率
对防病毒服务器的自动扫描报告及管理部门的检查记录分别进行抽样检查。
测试内容：
确认定期审核留下了审计证据
对于审核中发现的问题，确认是否进行了及时的调查和处理
编号 扫描报告时间 是否留下书面审核记录？ 审核发现的问题 对审核发现的问题，是否进行了及时调查处理？ 例外事项
1 6/16/05 有 无 无 无例外事项
2 7/26/05 有 无 无 无例外事项
3 8/16/05 有 数据中心（上海）子TMCM服务器发现病毒 病毒日志发送防病毒管理员处理 无例外事项
4 9/26/05 有 数据中心（上海）子TMCM服务器发现病毒 病毒日志发送防病毒管理员处理 无例外事项
5 10/16/05 有 无 无 无例外事项
6 11/26/05 有 无 无 无例外事项
7 12/16/05 有 数据中心（上海）子TMCM服务器发现病毒 病毒日志发送防病毒管理员处理 无例外事项
8 12/26/05 有 数据中心（上海）子TMCM服务器发现病毒 病毒日志发送防病毒管理员处理 无例外事项
9 1/26/06 有 1)、数据中心（上海）子TMCM服务器发现病毒
2)、xmfh\shujuzhongxin\shanghai\sanxia子TMCM服务器的病毒码更新异常 1)、病毒日志发送防病毒管理员处理
2)、已部署 无例外事项
10 2/16/06 有 无 无 无例外事项
11 2/26/06 有 无 无 无例外事项
12 3/16/06 有 数据中心（上海）子TMCM服务器发现病毒 病毒日志发送防病毒管理员处理 无例外事项
13 4/26/06 有 数据中心（上海）子TMCM服务器、网吧防病毒服务器发现病毒 病毒日志发送防病毒管理员处理 无例外事项
14 5/16/06 有 数据中心（上海）子TMCM服务器发现病毒 病毒日志发送防病毒管理员处理 无例外事项
15 6/26/06 有 无 无 无例外事项
技术变更管理表
变更编号：
以下内容由变更申请单位填写
变更名称
需求来源
联系人员
变更原因
变更目的
联系电话
传真号码
Notes ID
E-Mail
变更实施条件
变更期望
的完成时间
是否经过测试
是否需要通知相关业务部门
变更需求内容
（本栏可为附件） 签章： 日期：
变更计划
（本栏可为附件） 签章： 日期：
部门主管意见
签章： 日期：
以下内容由变更受理及协调部门填写
受理
时间
年 月 日 ： ：
问题编号
部门
受理人
实施
时间
年 月 日 ： ：
结 果
变更级别
级
缓急程度
□一般 □紧急
牵头实施部门
负责人
协助实施部门
负责人
以下内容由参与审批各部门填写
受理部门意见
各审批部门意见
总经理意见
以下内容由变更牵头实施部门组织填写
变更实施计划
（本栏可为附件） 签章： 日期：
变更回退方案
（本栏可为附件） 签章： 日期：
牵头实施部门
主管意见
协助实施部门
主管意见
实施过程
（本栏可为附件） 签章： 日期：
实施结果
（本栏可为附件） 签章： 日期：
以下内容由变更受理及协调部门填写
变更分析与审核意见
（本栏可为附件） 签章： 日期：
以下内容由变更申请部门填写
变更申请部门确认意见
（本栏可为附件） 签章： 日期：
备注
说明：
1、“需求来源”填写文件或通知的编号等信息，作为变更依据；
2、由问题产生的变更需要填写相应的“问题编号”。
Sheet1
ICBC数据中心（上海）对程序和数据的访问抽样测试
岗位职责分离的测试
样本总体
ISACA认为职责不兼容的14个岗位职责，包括信息技术部门管理人员、系统分析员、应用编程人员、技术支持人员、最终用户、数据录入人员、运行操作人员、数据库管理员、网络管理员、操作系统管理员、安全管理员、介质管理员、系统编程人员、质量管理人员
样本量/频率
ISACA认为职责不兼容的岗位职责
测试内容
对于ISACA认为的存在职责不兼容的岗位，数据中心（上海）都实行了岗位职责分离
ISACA认为需要考虑职责分离的岗位 信息技术部门管理人员 系统分析员 应用编程人员 技术支持人员 最终用户 数据录入人员 运行操作人员 数据库管理员 网络管理员 操作系统管理员 安全管理员 介质管理员 系统编程人员 质量管理人员 例外事件
数据中心（上海）对应的部门 总经理室 N/A N/A 技术管理部 N/A N/A 运行部 系统部、开发平台部 网络部 系统部、开发平台部 安全部 运行部 N/A 生产调度办公室
ISACA是否认为职责不兼容 数据中心SH是否做到职责分离 ISACA是否认为职责不兼容 数据中心SH是否做到职责分离 ISACA是否认为职责不兼容 数据中心SH是否做到职责分离 ISACA是否认为职责不兼容 数据中心SH是否做到职责分离 ISACA是否认为职责不兼容 数据中心SH是否做到职责分离 ISACA是否认为职责不兼容 数据中心SH是否做到职责分离 ISACA是否认为职责不兼容 数据中心SH是否做到职责分离 ISACA是否认为职责不兼容 数据中心SH是否做到职责分离 ISACA是否认为职责不兼容 数据中心SH是否做到职责分离 ISACA是否认为职责不兼容 数据中心SH是否做到职责分离 ISACA是否认为职责不兼容 数据中心SH是否做到职责分离 ISACA是否认为职责不兼容 数据中心SH是否做到职责分离 ISACA是否认为职责不兼容 数据中心SH是否做到职责分离 ISACA是否认为职责不兼容 数据中心SH是否做到职责分离
信息技术部门管理人员 是 N/A 是 N/A 是 是 否 N/A 是 N/A 是 是 是 是 是 是 是 是 否 是 否 是 是 N/A 否 是 无例外事项
系统分析员 是 N/A 是 N/A 是 N/A 是 N/A 否 N/A 是 N/A 否 N/A 否 N/A 否 N/A 是 N/A 是 N/A 否 N/A 否 N/A 无例外事项
应用编程人员 是 N/A 否 N/A 是 N/A 是 N/A 是 N/A 是 N/A 是 N/A 是 N/A 是 N/A 是 N/A 是 N/A 是 N/A 否 N/A 无例外事项
技术支持人员 是 是 是 N/A 是 N/A 是 N/A 是 N/A 否 是 是 是 是 是 是 是 否 是 是 是 是 N/A 否 是 无例外事项
最终用户 否 N/A 是 N/A 是 N/A 是 N/A 否 N/A 是 N/A 是 N/A 是 N/A 否 N/A 否 N/A 是 N/A 是 N/A 是 N/A 无例外事项
数据录入人员 是 N/A 否 N/A 是 N/A 是 N/A 否 N/A 是 N/A 是 N/A 是 N/A 是 N/A 是 N/A 否 N/A 是 N/A 否 N/A 无例外事项
运行操作人员 是 是 是 N/A 是 N/A 否 是 是 N/A 是 N/A 是 是 是 是 是 是 是 是 否 是 是 N/A 否 是 无例外事项
数据库管理员 是 是 否 N/A 是 N/A 是 是 是 N/A 是 N/A 是 是 是 是 是 是 否 是 否 是 是 N/A 否 是 无例外事项
网络管理员 是 是 否 N/A 是 N/A 是 是 是 N/A 是 N/A 是 是 是 是 否 是 否 是 是 是 否 N/A 否 是 无例外事项
操作系统管理员 是 是 否 N/A 是 N/A 是 是 否 N/A 是 N/A 是 是 是 是 否 是 否 是 是 是 否 N/A 否 是 无例外事项
安全管理员 否 是 是 N/A 是 N/A 否 是 否 N/A 是 N/A 是 是 否 是 否 是 否 是 是 是 是 N/A 否 是 无例外事项
介质管理员 否 是 是 N/A 是 N/A 是 是 是 N/A 否 N/A 否 是 否 是 是 是 是 是 是 是 是 N/A 否 是 无例外事项
系统编程人员 是 N/A 否 N/A 是 N/A 是 N/A 是 N/A 是 N/A 是 N/A 是 N/A 否 N/A 否 N/A 是 N/A 是 N/A 是 N/A 无例外事项
质量管理人员 否 是 否 N/A 否 N/A 否 是 是 N/A 否 N/A 否 是 否 是 否 是 否 是 否 是 否 是 是 N/A 无例外事项
备注：
N/A表示数据中心（上海）没有该职责，因此与该职责相关的岗位职责分离原则不适用
业务请求申请表
业务请求申请表
申请单位
服务请求名称
服务请求类型
服务请求原因
服务请求的内容
（本栏可为附件） 签章： 日期：
联系人员
联系电话
Notes ID
传真号码
E-Mail
期望
完成时间
一级（直属）分行相关业务部门意见
签章： 日期：
一级（直属）分行相关业务主管行长意见
签章： 日期：
一级（直属）分行会计结算部门意见
签章： 日期：
一级（直属）分行信息科技部门意见
总行业务部门意见
签章： 日期：
总行会计结算部意见
签章： 日期：
总行信息科技部意见
以下内容由服务请求受理部门组织填写
服务请求实施结果及签章
服务请求受理部门联系人及联系方式
服务请求申请单位确认及签章
备注
说明：
1、本申请表为纸质文档，一式三份，服务请求申请单位和服务请求受理单位各留存一份，另一份作为回执（如通过信息科技部门已投产的HelpDesk系统向数据中心提交变更申请，可将有效审批文件扫描后以JPG格式附加在HelpDesk系统中）；
2、服务请求类型是指业务调整服务请求、数据需求服务请求；
3、只有一级（直属）分行及其辖属分支机构业务部门要进行业务调整和调整额度超过500万元（含）的业务调整服务请求才需要一级（直属）分行相关业务主管行长填写意见；
4、只有一级（直属）分行及其辖属分支机构业务部门要进行业务调整和利用主机调账系统无法处理的业务调整服务请求、数据需求服务请求时，才需要一级（直属）分行信息科技部门填写意见；
5、只有总行本部相关业务部门（清算中心、总行营业部、牡丹卡中心等）业务调整服务请求，才需要总行业务部门填写意见；
6、只有总行本部相关业务部门业务调整服务请求以及一级（直属）分行及其辖属分支机构业务部门数据需求服务请求和业务调整服务请求且涉及参数表时，才需要总行会计结算部填写意见；
7、只有总行本部相关业务部门（牡丹卡中心、电子银行中心、总行营业部、清算中心等）业务调整服务请求，才需要总行信息科技部门填写意见；
8、如一级（直属）分行及其辖属分支机构会计结算部门发起业务调整服务请求，则只需填写一级（直属）分行相关业务部门意见栏，一级（直属）分行会计结算部门意见栏可不再重复填写；
9、备注栏用于填写业务请求申请单位在将服务请求实施结果反馈服务请求处理单位后，业务请求申请单位确认其未按审批后的业务请求实施，服务请求处理单位重新实施业务请求的处理情况。
