ISMS在日企外包行业实践探讨.docVIP

ISMS在日企外包行业实践探讨 　　《ISO 27001:2005信息安全管理体系规范》国际标准发布之后，ISO 27001成为炙手可热的企业ISMS（信息安全管理体系）建设蓝本。各行各业，尤其是外包行业，开始广泛参照该标准并结合企业的实际情况，对信息安全活动进行全面管理，期望提升安全管理水平。但是现实与理想总是存在差距，尽管ISO 27001可以指导各行各业的安全管理活动，但它并不是包治百病的良药。是洋标准水土不服还是自个身子板儿太差？ 　　 　　运行过程中问题重重 　　 　　企业按照ISO 27001建立组织的信息安全管理体系时，要么聘请外部咨询顾问，要么让企业内部有体系建设经验的专业人士实施。当项目完成之后，企业的安全管理框架基本建立，但是在体系运行过程中还是暴露出了种种问题。 　　1.管理层对ISMS半推半就 　　信息安全行业在国内诞生至今也不过十多年，还算是一个新生事物，因此企业对信息安全的认识还不足。而在外包企业建立ISMS的驱动因素来自发包客户――获得国际广泛认可的ISO 27001证书成了外包企业签定订单的重要资质之一，外包企业非常需要这张证书。但是一旦证书到手，管理层对ISMS的持续支持就开始打折扣。“本公司将在本月15号接受ISO 27001认证外部审核机构对ISMS的审核，请各部门协助配合质量管理部的工作”――这是我们一个客户的领导在临认证前给公司员工发的一个通知。“协助配合”这几个字体现了公司对ISMS的认识和重视度，意思是ISMS只是质量管理部的事情。 　　2.安全制度、流程难以落实和执行，很多活动流于形式 　　ISMS文档不少，公司级的文档不下二三十个，部门级甚至到操作级别的文档总共不下一百来个。逐个落实，难度确实不小。 　　比如说执行信息系统的变更管理流程时，该流程要求对信息系统的任何配置信息的修改、系统升级等都要事先申请，然后做风险分析、申请相关领导批准等等。而系统管理员之前的习惯可能是比较随意，觉得哪有问题就修改。这个时候要求按流程走，这让他们非常不自在，因此产生抵触情绪。这一方面的改变确实是个痛苦的过程。另一方面就是这些系统管理员往往在企业里具有技术专家优势，而且IT事务多??杂，IT人员非常少，职责分离很难实施。 　　比如在开展ISMS管理评审时，要求业务部门经理与会评审ISMS效用状况，但是这些经理要么请人代理，要么在会上说些无关痛痒的话，总之一副与我关系不大的姿态。评审会议最终沦为形式，留下无用但又是ISO 27001标准要求的评审会议记录。 　　3.信息安全与业务脱钩 　　ISMS在建设和推进过程中，鲜少有业务部门参与，ISMS项目往往是质量管理部门或者IT部门闭门造车。安全控制没有真正站在业务部门的立场上去考虑问题，这也导致企业从事信息安全的人员在业务部门不受欢迎。因为在业务部门的眼中，信息安全捆绑了业务发展的手脚，降低了工作效率。在某外包公司，曾经发生过由于员工无限制地上网而使系统感染病毒，最终导致企业整个网络瘫痪的事件。事发之后，公司领导决定要进一步加大信息安全的保障力度。信息安全部门建议，上班时间禁止浏览网页，尽管员工有反对的声音，但是领导最终还是采纳了该建议。断网之后，软件工程师碰到技术问题，想要通过网络来解决的通路断了，这大大影响了工作效率；同时，长期的网络使用使工程师已经形成了网络依赖，断网犹如婴儿断奶，员工怨声载道。压力之下，只好恢复上网。这个事情让公司领导觉得脸上无光，于是把业务部门和信息安全部门领导叫去，各打五十大板，怨业务部门上网感染病毒，又怨信息安全部门这药下得太猛。这让信息安全部门的人感觉太委屈了――管不是，不管也不是，总之是猪八戒照镜子，里外不是人。 　　4. ISMS没有持续改进 　　改进即改变。对于外包软件开发项目，除了软件开发过程本身的改进任务之外，还增加了在安全的环境中开发出安全软件的新的过程改进要求，这无疑加大了改进的难度，增加了开发人员的抵制情绪。比如以前可以随时访问Internet，以查阅相关资料获取信息，而现在由于保密性的要求而限制访问Internet。 　　过程改进被认为是一项额外的工作，重要但不紧急。按照ISMS的要求，一个新的软件项目立项之后，势必将产生各种各样的数据和文档，需要依赖相关的信息系统，而这些数据文件以及系统就是企业需要保护的信息资产。这些信息资产要纳入风险管理的范围，资产识别、分类分级、弱点和威胁的识别和评价等等随之而来。人们往往会忽略那些重要的但是不紧急的工作，因此这项工作常常被推迟甚至被取消。 　　业务部门与信息安全部门普遍存在问题。在业务部门的眼中，信息安全是可有可无的东西，甚至被认为是业务的绊脚石――太多的安全控制降低了他们的工作效率，因此想方设法来阻碍信息安全过程的改进，甚至