ＩＳＭＳ在日企外包行业的实践探讨:外包是什么意思

　　《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的要求，一个新的软件项目立项之后，势必将产生各种各样的数据和文档，需要依赖相关的信息系统，而这些数据文件以及系统就是企业需要保护的信息资产。这些信息资产要纳入风险管理的范围，资产识别、分类分级、弱点和威胁的识别和评价等等随之而来。人们往往会忽略那些重要的但是不紧急的工作，因此这项工作常常被推迟甚至被取消。
　　业务部门与信息安全部门普遍存在问题。在业务部门的眼中，信息安全是可有可无的东西，甚至被认为是业务的绊脚石――太多的安全控制降低了他们的工作效率，因此想方设法来阻碍信息安全过程的改进，甚至歪曲现有的安全控制效果。
　　ISO 27001标准是国外众多信息安全专家的实践总结，简单的“拿来主义”肯定会导致消化不良。我们需要坚持先进理论融入实践和具体问题具体分析的思路。
　　
　　融入企业实际环境
　　
　　ISMS运行成果的好坏由两个方面所决定，一方面是ISMS搭建者的能力，另一方面是企业的内部环境。从PDCA的思路来看的话，归根到底还是取决于企业的内部环境。人们常说要量体裁衣，建设有效的ISMS必须考虑企业的实际情况。那么建设ISMS时，需要考虑哪些企业环境信息呢？
　　首先是企业组织架构，包括决策、权利分配、责任分工。曾经碰到这么一个客户，他们的ISMS建设由质量管理部门来主导实施，但是质量管理部门由开发本部直接领导。试想一下，下级部门督促监督上级部门做某项费力的工作，在这么一个环境中推行安全改进，其困难何其大。
　　其次是全体员工的安全意识水平。员工的信息安全意识简单说是能够对可能发生的安全事件保持警惕。发散开来，可以理解为以下几个层次：能够认知可能存在的安全问题，明白安全事故对组织的危害，恪守正确的行为方式，清楚在安全事故发生时所应采取的措施。
　　最后是企业文化。企业环境的因素中非常重要的是企业文化，企业文化主导了员工行为方式和企业对外形象。外包企业中的在华日企应该说传承了日本企业的基本文化特点，具体体现是看重企业诚信，诚信可以成为企业成败的关键。在日本，企业如果发生信息泄露等信息安全事件，按规定是要主动向有关政府部门报告的。如果隐瞒不报，一旦被发现将会严重影响公司信用，后果是十分严重的。不二家这个创立于1910年的西点食品连锁企业，就是因为隐瞒使用过期原料进行生产的事实被曝光，而发生了严重的信用危机，砸了自己的百年老字号，现在超市已经看不到不二家的东西了。
　　另外，企业非常重视信息安全。从ISMS 国际用户组织对全球通过ISO 27001认证的企业数目上可以看出，日本到当前为止已有2800家企业，占全球通过企业数的50％以上。由此可见日本企业对信息安全的重视。此外，在2005年4月生效的《个人信息保护法》是日本保护个人信息安全的根本法律，企业从各个方面加强了对个人信息的保护。在华日企外包公司主要为日本提供外包服务，客户如此重视信息安全，外包企业不跟上行吗？
　　那么建设ISMS时如何考虑环境因素并最终把安全体系嵌入企业环境中呢？
　　1. 建立合理的信息安全组织架构
　　合理的信息安全组织架构应该包含三个层次：决策层、管理层和执行层；从角色上来讲可以分为普通员工、信息安全专业人员、安全审核员；信息安全是“一把手”工程，由企业的总经理直接挂帅领导。
　　2. 建立全员信息安全和培训制度
　　一方面按照企业人员级别以及业务性质的不同，对不同人员实施不同侧重内容的培训，关注不同级别人员对信息安全的关注点；另一方面，实现员工在企业整个就业期间，接受不间断的持续培训。当然，在安全教育和培训方面，不必拘泥于形式，除了正常的集中人员面对面的培训之外，还可以采取网络教程、Flash动画、张贴墙报、定期发送电子报、开展信息安全知识竞赛等形式。通过多方式、全方位的宣传和教育，把信息安全融入到企业文化当中。
　　3. 让员工承诺负责
　　让员工咨询阅读与其业务相关的安全策略，让员工承诺遵守公司的安全制度并签字。
　　
　　紧密切合业务需求
　　
　　外包公司的主要业务是承接客户业务链中的某个环节，而外包公司所提供的这些服务的失败可能会影响到发包公司整个业务。比如软件外包，这可能会涉及到某些具有知识产权的技术，也可能会涉及到客户的机密数据，也有可能会涉及到某些商业秘密等。那么ISMS如何满足业务需求呢？5W1H的分析方法是一种行之有效的方法。
　　业务驱动是指业务开展在信息安全方面的需求。首先，国内日企外包企业的主要客户基本上都是日本的跨国或者高科技企业，而这些企业自身对信息安全要求很高，这种高要求势必会传递给他们的接包客户。随着离岸外包的发展以及国内对外包业务的大力推动，越来越多的企业加入到外包大军中，发包公司与接包公司需要通过一种方式来建立彼此之间在信息安全方面广泛的信任关系，引入公信的第三方――ISO 27001认证就是解决这个问题的有效途径。其次，目前对日软件外包项目中，绝大多数是应用系统的开发，而这些应用系统基本上都是运行在互联网环境中的。因此，开发出安全的能够抵御黑客攻击的软件成了重要需求之一。这需要接包方确保客户信息的机密性，保障一切与开发系统相关的设计文档、源代码的机密性。同时还要维护客户的知识产权。再次，很多项目是协同开发的模式，这需要保证信息系统运行可靠，网络通畅。另外，对于保持开发团队稳定也是保障项目顺利进行的条件之一。
　　业务属性是指那些企业想要保护或者支持的事务。业务属性包括用户属性、运维属性、风险管理属性、法律法规属性、业务战略属性等，下面仅仅对用户属性和运维属性做简单分析。
　　用户属性是指用户在系统中的信息安全体验，这里的用户主要是指软件工程师、软件项目管理人员。工程师或者项目经理因开发工作的需要，要求访问项目配置库，可访问性则是用户属性之一，它是指对于授权能够访问的项目文档信息以及信息安全过程改进文档，用户能够容易地找到并且有适当的访问权限；另外，项目里不同模块由不同人员开发，业务驱动中对设计文档、源代码保密性的需求，这要求工程师各自的用户和访问权限信息必须受到保护，这又是用户属性中的受保护属性。当然还有其他属性，比如职责分离、接受安全意识和教育等就不再一一赘述。
　　运维属性是指企业日常运行的安全。外包公司要完成与发包公司的协同工作，网络基础设施的安全稳定运行且满足约定的服务级别水平是基础，这是可靠性要求。百密终有一疏，企业可能会遭受严重信息安全事故甚至灾难，如大面积网络瘫痪、机房起火设备被毁等，导致业务中断，运维属性中的可持续性则要求企业在允许的最大业务中断时间之内恢复业务的运行。
　　从以上的分析当中，可以看出，业务驱动与业务属性存在着对应关系。业务驱动在较大、较粗的层面上分析问题，紧密结合业务，而业务属性则从企业具体事务和保护对象入手，对业务进行层层分解。
　　当然，对企业业务的分析还包括要考虑业务目标达成必须的关键因素，以此确定安全控制目标；还需要对核心业务流程和模型在时间状态、职能的依赖关系、人员责任以及关系逻辑等方面进行分析，以确定时间模型、信任模型以及安全域模型，这里就不再一一详述。最终确定企业的安全架构。
　　总之，对业务在5W1H六个方面的分析，使得信息安全与业务之间架起了一座桥梁，完成了信息安全与业务的对接。
　　
　　ISMS就是过程改进
　　
　　过程改进本身是一项重要的管理工作。信息安全的效果通过业务部门的参与得以体现，改进的信息安全过程能够增加公司核心业务和产品的附加值（客户更加信任），让业务部门从安全改进中尝到了甜头，才能更积极地参与到改进中来。
　　过程改进需要全体员工的参与――上到管理层，下到普通工程师。上文我们提到，过程改进就是过程改变，员工的参与也就是要改变之前的做事方法。人们为什么要做出改变呢，只有让人看到好处，让参与的各个级别的人员能够满足其诉求。因此，信息安全经理要仔细分析他们的关注点。在信息安全改进过程中，在企业内部，安全经理需要与三个方面的人员做好沟通：高层管理者、中层业务经理和工程师。高层管理者关注信息安全，一般在各种场合都会表示对信息安全工作的支持；而中层业务经理则要关注多项指标，项目进度和质量、人员技能提升等等，信息安全只是其中指标之一，而他们需要在多项指标中寻找平衡；工程师在项目压力不是很大的情况下，非常乐意学习新的技能和方法。
　　了解他们的关注点之后，信息安全经理再与他们的沟通时要有针对性。对于高层管理者，只需说明新方法概况、目的、初步计划和人员投入等，无需过多细节。面对业务部门经理，除了上述要点之外，还要说明信息安全工作如何与他们的目标挂钩，这一新方法不仅是为了满足客户安全需求，还能帮助完成更安全的软件，并且就投入多少时间，涉及哪些人员，风险降低何种程度进行讨论。如果与高层管理者和业务部门经理都已经达成共识，再与工程师来讨论新方法的推行就会很顺畅。
　　ISO 27001国际标准作为全球在信息安全管理方面的最佳实践之一，是他人的经验总结。在当前国内企业管理水平整体相对较低的情况下，我们唯有努力学习他人经验，并切实结合自身的实际情况，打造有效的ISMS。