【ISO认证AAA级信用企业价格公道】

ISO27001标准简介 世界广泛采用的关于信息管理体系的英国标准——BS7799-2:2002，经修订后，于2005年10月15日作为国际标准ISO/IEC27001:2005发布。本文旨在向组织指出标准的变化及在实际应用中的意义，协助组织做好向新标准过渡的准备。新标准的正式标题是:《BS7799-2:2005(ISO/IEC27001:2005)信息技术-技术-信息管理体系-要求》这意味着它不仅仅是IT标准，标题中的“信息技术-技术”表明它还是以ISO委员会(JTC1/SC27)的名义发表的。该标准的焦点还是放在贯穿组织的信息管理上。尽管大部分控制在实际中会在IT部门或IT组织内部实现，但总体上标准执行的重点仍应放在业务信息的风险上。标准的主要改变在于它现在是国际公认的，这意味着除了英国标准的国际认可，组织可以构建一个全球性的框架来管理他们的信息。不管是为了组织自身的商业信息，如财政信息，知识产权，职员资料等等，或者是客户或第三方与组织间沟通的信息，标准都是适用的。实际上，它是组织能够对他们的信息管理系统进行客观独立评估的国际标准。新版的国际标准已经有一系列更新来阐明巩固原始英国标准——BS7799-2:2002的要求。这些更新主要集中在以下范围：风险评估、合同责任、范围、管理决策以及所选控制措施有效性的测量等。对于采用BS7799-2:2002的组织来说，新版的国际标准并没有太大的影响。的影响就是要求对所选的控制措施或控制措施组合的有效性进行测量。（详见ISO/IEC27001:2005的4.2.2d）下面是该标准重大改变的解释概要。附录A是一个显示BS7799-2:2002和ISO/IEC27001:2005之间的变化的表格。《ISO/IEC27001:2005》。范围和界线在执行信息管理体系的时候，组织所要做的件事就是定义ISMS的范围。现在国际标准要求组织定义ISMS的范围和界线[4.2.1a]，包括被排除在范围外的详细说明及理由。尽管富有经验的BSI审核员在评估过程中也会寻找这些东西，但是现在把这个要求加到标准中了，如果组织打算超越根据2002版标准取得的认证而达到新标准的要求，就必须把这个要求考虑在内。评估风险该国际标准的基础是：信息的保护是基于业务信息的风险，该风险能促使组织运用合适的措施来保护业务的。很少有业务信息会暴露在多种风险之下，因此太多的措施可能使公司花费过多的成本。标准的一个重大改变是组织现在需要详细说明（并文件化）风险评估的步骤[4.2.1c]，这也意味着挑选并文件化风险评估方法将会使风险评估“产生可比较、可重复的结果”[4.2.1c和4.3.1d]。目前已通过BS7799-2:2002认证的组织不会把这点看成一个比较大的变化，因为在评估过程中已经考虑过它了。打算通过BS7799-2:2002认证的组织可能会把它看成该国际标准的新要求。风险评估按照计划的时间间隔[4.2.3d]进行复查，对风险评估和风险处理计划[7.3b]的更新进行复查管理已经是标准的要求。这个要求必须作为组织信息管理体系的管理复查的一部分[7.1]，至少一年完成一次。在对BS7799-2:2002版标准进行审核的过程中，审核员应该根据ISMS的方针和目标[4.3.1]，寻找所选择的控制措施与风险评估结果和风险处理程序之间的关系。尽管BS7799-2:2002标准提到过这点，但现在已经在国际标准中阐明了。想获得BS7799-2:2002认证的组织可以把它看作国际标准的新要求。合同责任除了法律法规的要求，该国际标准还特别强调在所有ISMS所有过程中的合同责任，包括风险评估、风险处理、控制选择、记录控制、资源、ISMS的监视和复查、以及文件要求。通过BS7799-2认证的组织现在需要做什么？需要特别注意的是：新的国际标准是双重的，既可以是ISO/IEC27001:2005，又可以是BS7799-2:2005。这种情况会持续一段时间（预期2年左右），这就意味着BS7799-2:2005认证和ISO/IEC27001:2005认证没有什么不同。然而，目前所有通过现行的BS7799-2:2002认证的组织必须考虑2005版本的变化，及时更新他们信息管理体系。通过BS7799-2:2002认证的组织会逐步转换到ISO/IEC27001认证。转换期限多久现在还不得而知，要等待国际认可论坛(IAF)，或认可机构（如UKAS）发表正式声明来公布。实际上，在以后的监督审核中，会把这些不同点考虑在内；如果合适的话，建议客户取得ISO/IEC27001:2005标准的认证。如果在转换期内客户不及时转换到新标准，一直停留在旧标准，审核员可以把与ISO的不一致作为“注释/观察项”记录在案。一旦转换期结束，观察项就上升为不符合项，的注册就存在了风险。新标准发布后，就可以依据ISO/IEC27001:2005进行认证了。附录A变化摘要 BS7799部分2：2002（条款号）ISO/IEC27001:2005（条款号）变化和差异的注解1.2应用1.2应用确定对ISO/IEC27001条款4-8的删减都是不可接受的，解释在何种情况下对控制进行了删减是可能的。3术语和定义3术语和定义从ISO/IEC13335-1：2004，ISO/IECTR18044：2004和ISO/IEC指南73:2002中添加定义。改变部分现有定义以配合ISO/IEC13335-1：2004标准。重新明确定义了“风险处理”和“适用性声明”。4.2.1建立ISMS项目a)定义ISMS的范围4.2.1建立ISMS项目a)定义ISMS的范围和界线现在,定义了ISMS的“范围和界线”的要求。要求包括：1、说明在范围内的部分2、解释被排除在范围外的理由。项目c)定义风险评估的系统方法在项目c)中的第二句“定义组织的风险评估方法”被删除后新增了一条。新增一条对现有的要求进行阐明和补充。同时声明风险评估方法应产生可比较、可重复的结果。项目g)为风险处理选择控制目标及控制。项目g)“为风险处理选择控制目标及控制”已经被延伸了。现有的要求加上了这样的阐释：选择应该考虑到在法律、法规及合同的要求范围内接受风险的标准。项目h)准备适用性声明。项目j)添加了新项目j)2)“准备适用性声明”。阐明了现有关于适用性声明的要求。现在强调它要包括当前实施的控制目标及控制。4.22实施和运作ISMS4.22实施和运作ISMS新增项目d)定义如何测量有效性。这可能是实施和运作ISMS过程中的改变，要求定义如何测量控制及控制组合的有效性，要求详细列出测量方法使控制效果评估产生可比较、可重复的结果。4.2.3监控和评审ISMS项目a)执行监控程序及其它的控制。4.2.3监控和评审ISMS项目a)4)添加了“执行监控程序及其它的控制以探测事件”。项目c)添加了“测量控制的效力”。阐明了有助于事故的事件探测。包括使用指标。项目c)评审剩余风险和可接受风险。新增项目d)5)按计划的时间间隔评审风险评估，评审剩余风险和可接受风险，评审时要考虑现行控制的有效性的变化。新增项目g)更新计划与4.2.2.d结合以监控ISMS的效力。现有要求的阐述，帮助监测现行控制的效果。阐述和补充了以下要求:根据监控评审活动的发现来监控评审ISMS以更新计划的要求。4.31概要4.31概要段阐明：文件要包括管理决策的记录，活动要根据管理决策和方针进行，记录/结果是可重复的。 第二段新增一句说明所选择的控制与风险评估和风险处理过程的关系，以及与ISMS方针和目标的关系。 新增项目d)风险评估方法的描述风险评估方法的描述要包含在文件中。项目e)文件化的程序项目g)“文件化的程序”已经被更新了阐明并补充了描述如何测量控制的有效性的要求。4.3.2文件控制4.3.2文件控制新增项目f)确保文件是可用的阐述了确保使用者可以获得所需文件的要求，及文件的转移存储和终处置要按照合适的等级来处理。5.1管理承诺5.1管理承诺新增项目g）保证ISMS内部审核得到管理。在管理承诺中声明确保ISMS内部审核得到管理。条款6.1到6.3条款7.1到7.3移动的章节条款7.1到7.3条款8.1到8.3移动的章节6.2评审输入7.2评审输入新增项目f)有效性测量的结果移动的章节新增了有效性测量的结果。6.3评审输出7.3评审输出新增项目b）更新风险评估和风险处理计划。移动的章节阐明确保更新风险评估和风险处理计划。项目c)必要时，修改影响信息的程序，以响应对ISMS造成影响的内外事件。项目c)必要时，修改影响信息的程序和控制，以响应对ISMS造成影响的内外事件。包括合同责任的改变。阐明包括合同责任的改变。 新增项目e)改进控制有效性的测量方法。加进了“改进控制效力的测量方法。”的声明。6.4ISMS内部审核6.4ISMS内部审核现在是第六章的要求。7.3措施8.3措施项目8.3b)“评估采取措施不符合发生的必要性”移动的章节阐明措施。评估采取措施不符合发生的必要性附录A附录A根据ISO/IEC17799:2005的修订版本更新附录A附录B和表B1附录B除了说明OECD原则和本国际标准之间的关系的表格外，其他被删除。删除的部分可能被ISO/IEC作为发展成新指南的基础。附录C附录C更新后的版本附录D 从ISO/IEC27001:2005版本中删除。

从无到有讲述ISO27001认证全过程ID:135/ 发布时间：2017-09-1613:53分类： 内容摘要：是一个不断的持续的过程，每个环节都不可缺少，在的路上懂的越多发现自己不懂的越多。1概述我在某做WL的公司负责公司整体，保护公司业务系统的（这个系统会有大部分看官的个人信息）。公司业务... 是一个不断的持续的过程，每个环节都不可缺少，在的路上懂的越多发现自己不懂的越多。 1概述 我在某做WL的公司负责公司整体，保护公司业务系统的（这个系统会有大部分看官的个人信息）。公司业务发展很快，但是信息化基础建设很落后，管理不规范，人员技术水平参差不齐，对网络和没有认识。领导对概念模糊，无法落实；因为是新来的，领导对提出的解决方案有选择的进行，但是有个好的地方就是公司发展太快，出现过不少问题，给我们部带来了外部推动力（虽然不想出事，但是出事了可以加快建设的脚步）。 一年的时间从什么都没到现在的逐渐成型、各种流程的建立和落地，建了ISO27001体系（通过了认证），此篇文章进行了一个总结，期间也碰到了的很多坑和挫折，自己也在这个过程中学习了成长了，这里再次感谢帮助过我的朋友们，感谢部另外一位X大牛。 2对ISO27001理解 通过一年的时间对从0到拿证的过程，简单说一下我对27001的理解：不管是ISO27001还是我觉得都是围绕着业务进行的，一切的出发点都是保证业务的连续的、稳定的运行，要保证业务的连续的、稳定的运行，你需要知道你有什么资产，资产面临什么风险，这些风险要怎么处理，这样一个过程中还要循序PDCA的原则（plan-do-check-action）。做每一个制度和每一个要求的时候从业务角度出发去思考，这样做才可以化的保证所写的制度规范能执行，为后面落地提供依据。凭空或单纯从的角度看问题，很容易把问题想的很严重，给出的解决方案往往短时间无法执行，后面会简阐述一下当时的想法。 脱离业务谈和脱离谈业务都是不现实的。 3为什么要做 我个人理解做这个事情的2大因素：1外因 一个公司发展到一定程度和规模的时候，公司自身的已经不是自己的问题了，你会涉及到社会层面、合作层面、业务发展层面。如：我们公司的发起做ISO27001的需求其实就不是来自部，是业务部门在推广业务的过程中遇到了阻力，因为客户的系统过了ISO27001他们会要求你与他对接的系统有一定的性，这个要求就表现为ISO27001。 我们就业找工作很多时候是看能力，但是有时候就像一个门票，没有门票就无法上车，ISO27001就是一个公司的。 还有重要因素《网络法》出台了，对的要求肯定是先从政府自身开始，然后慢慢到要求企业，与其等出事不如从现在开始做。2内因 每一个公司通过几年或更长时间的成长，公司会积累很多信息化系统，保障这些系统的正常运行就很重要，并且在对信息化管理过程中出现的很多职责不明确，边界不清，流程和制度不全，所有的操作规范和行为都靠约定俗成，没有体系化文档支撑，这些都影响系统稳定运行。 4控制项简单说明 ISO27001相信做的同学都有接触，百度有很详细的说明，我简单说一下自己的理解，大牛勿喷。ISO27001是一套管理类的文档，为了保证信息化工作和生产正常稳定的运行，一切都是围绕业务展开的，很多管理思路从公司的核心业务出发去考虑很多制度和规范都可以合理的解释。说个题外话很多做技术的和做管理的都是相互不对路，相互看不起，说句实在很多时候纯粹靠技术或纯粹靠管理去达到某个防护目标是不可能实现的，技术的实现可以方便和简化管理，管理制度的要求可以推动技术的落地，2者是相辅相成。 ISO27001从原来的15项标准要求变为了现在的18项，新增了2项、通信和操作管理拆除为2项。 下面简单说一下我对18个标准项的理解，并不是所有标准都要响应，如果实际情况没有可以不写，标准的要求不是重新编写公司已有的制度，只需要在原有制度上增加对相关的控制项： 5文档编写架构 ISO27001对应的文档说明其实叫适用性声明，如上表文件和控制项是一一对应的，标准文档架构为：手册、程序文件、作业指导书、运行记录： ?手册：就是对ISO27001体系的一个总体的说明文档 ?程序文件：具体描述每一个对应的标准要做什么 ?作业指导书：是对程序文件进一步解读，怎么做 ?运行记录：是对做了上述工作后的一个产出文档，可以是电子记录或纸质文件 针对这个情况咨询过评审老师，现在可以按照自己公司的实际情况去执行，但是手册文件必须都有。我们针对公司的实际情况做了修改，因为很多时候落地的时候都是以制度去要求和约束，我们把原有架构做了改变，重写全部的策略和要求，当然过程中有参考，整个过程耗费2人一个月时间（对于技术出身的人来说是艰苦的岁月），中途还修改了2个版本，跟领导对内容一个一个文档审。 变为：手册、策略、制度、运行记录 ?手册：一样没变 ?策略：针对标准要求，提出我们自己公司的要求 ?制度：用制度明确需要做什么，要求怎么做 ?运行记录：不单纯为运行记录文件，还包含了怎么做的具体操作文档 强调一下不要拍脑袋写一些要求，尽量实事求是，做到什么程度就在这个程度是增加要求。 6体系运行6.1体系发布 的工作如果由上致下会很顺利很容易推动，但是，体系的发布一定需要领导层去帮你发布执行，让全公司知道有这样一件事情，然后给领导要讲解（洗脑）这个东西是做什么的，可以为公司带来什么好处，让领导认同或部分认同你的观点，这样对后面的体系建设会很有帮助。 6.2体系分解 按照正常套路来说ISO27001要做的东西很多，我把体系分割为了3大块：管理、技术、和运行（前面也有提到）。管理：主要是制度、规范约束；技术：主要是实现目标；运行：主要是让前面的2点不要成为空谈，要有定期检查产出。 本来在按照公司的现状我制定的是分三步走的：起步-成长-成熟，成熟后运行2-3年再通过ISO27001的审核，在我个人看来毫无压力。但是由于要拿证时间只有1年，所有的东西都需要重新做没法按照套路来。 如果大家的时间较多，建议做一次的风险评估，针对风险一个一个完善文档。 6.3体系执行 执行主要是看检查在上述文档中的产出，如：发布了《运维管理制度》，那么根据要求，可能需要对机房进行周期性巡检产出《机房巡检记录表》，进出机房需要产出《机房进出记录表》。 按照个套路检查一个制度文件的产出，因此我们做了一个表，便于后面的审计： 大家可以把一些事情简单化，什么什么都用文档很繁琐，如： 基于django自主开发的资产管理系统，如果出现什么漏洞可以快速定位。 上面只是日常的执行要求，ISO27001还会有一个每年的内审和评审，内审：检查日常工作是否按照要求做好；评审：审核制度体系是否需要跟上公司的业务变化，做错对应的调整。 6.4体系培训 体系制度已经发布后，执行是有阻力的，因为打破了原有的约定俗成，增加了各个部门的工作量，这个需要非常耐心的去解释解答（这个过程很多人会找碴），需要培训去使大家有一定认识，从而配合你做事情。当然重要的是从领导层面推动，那样阻力就少很多，我们在这个过程中也没少发生申请事件，被删文件夹、中勒索病毒、数据库被暴力破解还有来自合作伙伴的漏洞通报。 培训可以从以下几块做： ?新员工培训 ?平时公司内部培训、讨论、讲座 ?真实案例延时（渗透测试、当场干公司的系统，顺便展示实力，不过这个度自己要把握好） 多抛头露面准没坏处。 7总结 简单介绍了ISO27001的建设，一个体系文件写下来，深深的觉得这个东西就是套路，环环相扣，都是相互引用的。在刚开始的时候压力、阻力会很大，但是做好了后面是一劳永逸，让制度执行几个月后做内审和评审，发现问题并解决，做完这些就基本可以申请外审了。 如果大家有想法要做的话可以先看一次标准，理解一下，再结合实际情况进行编写，因为在制度文档里面写到的就需要实现，外审的时候就要查的，尽量实事求是。 后面会对申请审核的前中后和大家分享。 原标题：从无到有讲述ISO27001认证全过程