从无到有通过ISO27001认证(转)

× 文章目录
  1. 1. 建设篇
    1. 1.1. 1 概述
    2. 1.2. 2 对ISO27001理解
    3. 1.3. 3 为什么要做
      1. 1.3.1. 3.1 外因
      2. 1.3.2. 3.2 内因
    4. 1.4. 4 控制项简单说明
    5. 1.5. 5 文档编写架构
    6. 1.6. 6 体系运行
      1. 1.6.1. 6.1 体系发布
    7. 1.7. 6.2 体系分解
      1. 1.7.1. 6.3 体系执行
    8. 1.8. 6.4 体系培训
    9. 1.9. 7 总结
  2. 2. 审核篇
    1. 2.1. 1 审核前
      1. 2.1.1. 1.1 注意事项
      2. 2.1.2. 1.2 需要递交的电子档文件
        1. 2.1.2.1. 1.1.1 电子文档
        2. 2.1.2.2. 1.1.2 二、所需原件有:
    2. 2.2. 2 审核中
      1. 2.2.1. 2.1 一审
      2. 2.2.2. 2.2 二审
    3. 2.3. 3 审核后
  3. 3. 4 总结

转自:从无到有通过ISO27001认证-建设篇

转自:从无到有通过ISO27001认证-审核篇

建设篇

安全是一个不断的持续的过程,每个环节都不可缺少,在安全的路上懂的越多发现自己不懂的越多。

1 概述

我在某做WL的公司负责公司整体安全,保护公司业务系统的安全(这个系统会有大部分看官的个人信息)。公司业务发展很快,但是信息化基础建设很落后,管理不规范,人员技术水平参差不齐,对网络和安全没有认识。领导对安全概念模糊,无法落实;因为是新来的,领导对提出的解决方案有选择的进行,但是有个好的地方就是公司发展太快,出现过不少安全问题,给我们安全部带来了外部推动力(虽然不想出事,但是出事了可以加快安全建设的脚步)。

一年的时间从什么都没到现在的逐渐成型、各种安全流程的建立和落地,建了ISO27001安全体系(通过了认证),此篇文章进行了一个总结,期间也碰到了的很多坑和挫折,自己也在这个过程中学习了成长了,这里再次感谢帮助过我的朋友们,感谢安全部另外一位X大牛。

2 对ISO27001理解

通过一年的时间对从0到拿证的过程,简单说一下我对ISO27001的理解:不管是ISO27001还是安全我觉得都是围绕着业务进行的,一切的出发点都是保证业务的连续的、稳定的运行,要保证业务的连续的、稳定的运行,你需要知道你有什么资产,资产面临什么风险,这些风险要怎么处理,这样一个过程中还要循序PDCA的原则(plan-do-check-action)。做每一个制度和每一个要求的时候从业务角度出发去思考,这样做才可以最大化的保证所写的制度规范能执行,为后面落地提供依据。凭空或单纯从安全的角度看问题,很容易把问题想的很严重,给出的解决方案往往短时间无法执行,后面会简阐述一下当时的想法。

脱离业务谈安全和脱离安全谈业务都是不现实的。

3 为什么要做

我个人理解做这个事情的2大因素:

3.1 外因

一个公司发展到一定程度和规模的时候,公司自身的安全已经不是自己的问题了,你会涉及到社会层面、合作层面、业务发展层面。如:我们公司的发起做ISO27001的需求其实就不是来自安全部,是业务部门在推广业务的过程中遇到了阻力,因为客户的系统过了ISO27001他们会要求你与他对接的系统有一定的安全性,这个要求就表现为ISO27001。

我们就业找工作很多时候是看能力,但是有时候证书就像一个门票,没有门票就无法上车,ISO27001就是一个公司的证书。

还有重要因素《网络安全法》出台了,国家对安全的要求肯定是先从政府自身开始,然后慢慢到要求企业,与其等出事不如从现在开始做。

3.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的建设,一个体系文件写下来,深深的觉得这个东西就是套路,环环相扣,都是相互引用的。在刚开始的时候压力、阻力会很大,但是做好了后面是一劳永逸,让制度执行几个月后做内审和评审,发现问题并解决,做完这些就基本可以申请外审了。

最后如果大家有想法要做的话可以先看一次标准,理解一下,再结合实际情况进行编写,因为在制度文档里面写到的就需要实现,外审的时候就要查的,尽量实事求是。

后面会对申请审核的前中后和大家分享。

审核篇

1 审核前

1.1 注意事项

找个一个评审机构交钱(相信机构大家能找到),签合同,签合同的时候需要注意几点:

Ø 体系类型、覆盖范围、人数

体系类型这个问题不大,基本都不会错;覆盖范围是需要慎重的,因为最后的证书上面会写清楚公司所通过认真的范围,如果不包含自己的业务那认证就白做了,当时写错了还要改合同,后面搞的很麻烦,希望大家不要重现我的坑;人数要写真实的,人数会关系到最后这个认证的费用,人数越多费用越贵。

附一个ITSMS的可以受理的范围:

Ø 填写申请书《管理体系认证申请书》

公司名字和地址要真实,包含所有的分公司,其中有临时办公场所也需要写,分公司多的话检查的时候是需要抽查到不同的分公司审核的(说是抽查其实甲方可以指定)。如果只是一个地址认证就写对应的地址就好。

1.2 需要递交的电子档文件

1.1.1 电子文档

组织简介、组织机构图、人员情况、申请认证产品的生产/加工/服务工艺流程图;

管理手册和程序文件;

关于认证活动的限制条件(如出于安全和/或保密等原因,存在时);

信息安全管理体系方针和目标;

支持信息安全管理体系的规程和控制措施;

风险评估报告;(含风险评估方法的描述);

残余风险报告

风险处置计划

适用性声明;

适用的法律法规的标准的清单。

申请书附表四、五(见申请书第6、7页)(到时候认证公司会给你文档的,如果有需求我也可以分享)

1.1.2 二、所需原件有:

合同,一式两份,签名盖章;

申请书,一式一份,签名盖章;

信息安全及信息技术服务管理体系保密协议,一式两份,签名盖章;

临时场所清单;加盖企业公章;(不存在临时场所企业不需提供)

营业执照、相关资质证书(最新年检副本)一式一份,加盖企业公章。

2 审核中

所有文档提交后,等待外审的到来,外审:分为一审和二审,外审的时候认证公司会联系负责人并约定好检查时间到现场检查。如果项目含了外审老师的差旅费,后面就不需要公司承担,如果不含的话,需要报销审核老师的差旅费(建议签合同的时候把这部分的钱包含了,免得后面太麻烦)。

在通知书里会包含审核的内容和计划,在审核老师来之前做好准备。

2.1 一审

一审安排:

主要是审核制度体系文件是否满足标准,公司有没按照体系制度的要求去执行,是否有运行记录的产出,公司的总体情况以及看一下公司的办公环境。一审主要是针对信息安全部进行的,以了解情况为主,一般来说有问题可以当场整改。

一般一审只需要一天,审核人员为:审核组长。审核完成会出一份审核结果。如果不通过一般都在一审不通过,不需要二审了。

2.2 二审

二审安排:

二审建议首末次会议最好有重要的领导参加,表示对安全的重视(至于为什么后面解释)。

二审需要的时间会较长,我们那时候是2个审核员审核4天,具体的时间需求会根据所申报的系统和人数去判定。系统多时间长审核的也很详细,审核的套路不是像等保对着一个一个标准制度过。我们的那2个审核老师是把对应的系统负责人叫过来大家聊天,如:你负责什么,平时正常工作什么做的,忙不忙周末要加班吗。如果心里有底气的不怕被套路,坐等没那么好的建议还是多培训一下,让主要负责人熟悉一下安全部所写的体系。

​ 审核完成后现场给出不符合项进行整改,反正不管做的多好都有整改项的。

3 审核后

审核完成后需要对上面的不符合项进行整改,整个整改需要做的有:

1、 整改前后截图

2、 打印纸质文档,并需要手写填写

3、 扫描彩色版发给审核组长确认

最后就是把所有的资料扫描盖章快递到指定地址。

4 总结

通过跟审核老师沟通,发现如果一个企业有做好安全的决心,并且也再去做,领导足够重视那样一般来说肯定可以过,但是如果审核过程中出现说的但是没做,那就是原则性问题了,就会不过。ISO27001总体原则就是:说我所做,做我所说。说到必须要做,做的好不好是改进的地方。

所以审核不要怕有不符合项,不符合项是一定会有的。除了原则性问题外,有2种情况也会导致不过:

1、 不符合项太多

2、 区域性不符合,严重不符合,举例子:抽查防病毒安装情况,一个部门抽查都没装就是区域性;一个办公环境一层都没装,而且包含很多部门,这个就是严重不符合

审核主要是自己有做,心里有底,最后照顾好审核老师的心情,中午一起吃个饭,这样后面就好说话了,过的几率就会大很多。

最后祝大家ISO27001外审都通过。