作者：惠普IT管理学院高级顾问，资深审计专家 宋琳

[  /showpic.html#blogid=7ebc432501017r1y&  /orignal/7ebc4325g7b154911a1df][/url]

审计人员要有系统性的思维，即必须考虑所有审计范围所涉及的资源、人员、程序、执行等，是对IT人员最大的考验。以前的IT都称为IT技术，现在的IT则为IT服务，技术需要的是几个点的深入，而服务则是一个系统面的满足。

做ITSM&ISO20000 IT服务审核，单独把十几个流程分开看，在ITSM平台上很难发现问题，只要按照流程做了，在流程上有记录或证据，就证明是OK的。但事实上流程不是孤立的，不符合往往发生在流程的接口上。

如在某公司查事件事故管理流程， ITSM上随机抽几个案列，发现纠正措施到位，也有证据附上整改状况，常规审核这种情况是通过的。但抽查重要的服务器日志发现连续半个月服务器硬盘报错，每次都是重启恢复。而这种真实报错并未记录在事件事故流程上，说明事件事故的搜集途径有问题，直接开具不符合。事实上，事件的来源可能是意外宕机，可能是用户投诉，可能是病毒或服务台报告，但也可能是错误日志的反馈。一个有效的事件事故管理流程应该能够收集并及时处置所有途径的意外，做到防大于治。同样，变更管理往往与配置管理紧密结合，SLA必须与供应商的SLA有一定的长短关系，这都是审核中要注意的流程之间的关系考虑。

做ISMS&ISO27001信息安全审核时，我们发现有家客户是国际知名的纸制品制造厂，最敏感的数据是粘胶的测试数据，而数据的产生部门是研发部门。在研发部门审核时发现，最新胶的测试数据为公司“绝密”，部门为秘书配置为专用的房间，有摄像头监控，有保险柜放置胶数据的打印报告，任何研发人员要看到数据必须签字且不能将数据带离现场，每张打印报告上都盖红色“绝密”章，测试数据是秘书通过加密U盘从测试部拿到，回来后打印一份，U盘也放在保险柜中，定期格式化。仅从研发部来看，做得相当完美。但审核员到了测试部，询问测试数据是如何放置的，测试员回答所以测试后的数据都放在P盘上，审核员把记录下来的新胶号交给测试部员工，问他们是否能够找到，结果测试部员工在P盘上（有他们给生产部、质量部、研发部等各部门分别建的数据文件夹），找到研发部，点击看到新胶号，与研发部保存的HARDCOPY一致，而测试部把这个FOLDER的权限设置为“public to all”， 被开具不合格。

几点经验：

-“流程”的概念：一个重要的信息，它的生命周期内每个环节都安全，不管是电子版还是纸张的， 我们才敢说它是相对安全的。

- 风险的理念：我们审核的重点在放在有风险的区域，比如N多应用系统，要选择对公司业务运作最重要的几个来审核；N多数据，要选择被确认为重要的信息或数据来查验访问权限等；N多开发项目，要选择有特殊客户要求或对公司发展非常重要的项目做全面的审核。

- 自信：审核员要找的是客观证据，客观证据是指文件、记录或工作流等。依据是公司的文件或相关方（如银监证监等）的要求，要求是明确的，抽样发现没有执行就是不符合。

转自：惠普IT管理学院 博客

[p=null, 2, center][color=#1f497d][font=宋体][size=10pt][color=#000000]作者：惠普IT管理学院高级顾问，资深审计专家 宋琳[/color][/size][/font][/color][/p][p=null, 2, center] [/p][p=null, 2, center][color=#1f497d][font=宋体][size=10pt][  /showpic.html#blogid=7ebc432501017r1y&  /orignal/7ebc4325g7b154911a1df][color=#000000][img=262,358]mw690/7ebc4325g7b154911a1df&690[/img][/color][/url][/size][/font][/color][/p][p=null, 2, left] [/p][p=null, 2, left] [/p][p=null, 2, left][color=#1f497d][font=宋体][size=10pt][color=#000000]审计人员要有系统性的思维，即必须考虑所有审计范围所涉及的资源、人员、程序、执行等，是对IT人员最大的考验。以前的IT都称为IT技术，现在的IT则为IT服务，技术需要的是几个点的深入，而服务则是一个系统面的满足。[/color][/size][/font][/color][/p][p=null, 2, left] [/p][p=null, 2, left][color=#1f497d][font=宋体][size=10pt][color=#000000]做ITSM&ISO20000 IT服务审核，单独把十几个流程分开看，在ITSM平台上很难发现问题，只要按照流程做了，在流程上有记录或证据，就证明是OK的。但事实上流程不是孤立的，不符合往往发生在流程的接口上。[/color][/size][/font][/color][/p][p=null, 2, left] [/p][p=null, 2, left][color=#1f497d][font=宋体][size=10pt][color=#000000]如在某公司查事件事故管理流程， ITSM上随机抽几个案列，发现纠正措施到位，也有证据附上整改状况，常规审核这种情况是通过的。但抽查重要的服务器日志发现连续半个月服务器硬盘报错，每次都是重启恢复。而这种真实报错并未记录在事件事故流程上，说明事件事故的搜集途径有问题，直接开具不符合。事实上，事件的来源可能是意外宕机，可能是用户投诉，可能是病毒或服务台报告，但也可能是错误日志的反馈。一个有效的事件事故管理流程应该能够收集并及时处置所有途径的意外，做到防大于治。同样，变更管理往往与配置管理紧密结合，SLA必须与供应商的SLA有一定的长短关系，这都是审核中要注意的流程之间的关系考虑。[/color][/size][/font][/color][/p][p=null, 2, left] [/p][p=null, 2, left][color=#1f497d][font=宋体][size=10pt][color=#000000]做ISMS&ISO27001信息安全审核时，我们发现有家客户是国际知名的纸制品制造厂，最敏感的数据是粘胶的测试数据，而数据的产生部门是研发部门。在研发部门审核时发现，最新胶的测试数据为公司“绝密”，部门为秘书配置为专用的房间，有摄像头监控，有保险柜放置胶数据的打印报告，任何研发人员要看到数据必须签字且不能将数据带离现场，每张打印报告上都盖红色“绝密”章，测试数据是秘书通过加密U盘从测试部拿到，回来后打印一份，U盘也放在保险柜中，定期格式化。仅从研发部来看，做得相当完美。但审核员到了测试部，询问测试数据是如何放置的，测试员回答所以测试后的数据都放在P盘上，审核员把记录下来的新胶号交给测试部员工，问他们是否能够找到，结果测试部员工在P盘上（有他们给生产部、质量部、研发部等各部门分别建的数据文件夹），找到研发部，点击看到新胶号，与研发部保存的HARDCOPY一致，而测试部把这个FOLDER的权限设置为“public to all”， 被开具不合格。[/color][/size][/font][/color][/p][p=null, 2, left] [/p][p=null, 2, left][color=#1f497d][font=宋体][size=10pt][color=#000000][b]几点经验：[/b][/color][/size][/font][/color][/p][p=null, 2, left] [/p][p=null, 2, left][color=#1f497d][font=宋体][size=10pt][color=#000000]-“流程”的概念：一个重要的信息，它的生命周期内每个环节都安全，不管是电子版还是纸张的， 我们才敢说它是相对安全的。[/color][/size][/font][/color][/p][p=null, 2, left][color=#1f497d][font=宋体][size=10pt][color=#000000]- 风险的理念：我们审核的重点在放在有风险的区域，比如N多应用系统，要选择对公司业务运作最重要的几个来审核；N多数据，要选择被确认为重要的信息或数据来查验访问权限等；N多开发项目，要选择有特殊客户要求或对公司发展非常重要的项目做全面的审核。[/color][/size][/font][/color][/p][p=null, 2, left][color=#1f497d][font=宋体][size=10pt][color=#000000]- 自信：审核员要找的是客观证据，客观证据是指文件、记录或工作流等。依据是公司的文件或相关方（如银监证监等）的要求，要求是明确的，抽样发现没有执行就是不符合。

转自：惠普IT管理学院 博客[/color][/size][/font][/color][/p]