先知技术社区独家发表本文,如需要转载,请先联系先知技术社区授权;未经授权请勿转载。先知技术社区投稿邮箱:Aliyun_xianzhi@service.alibaba.com;
安全是一个不断的持续的过程,每个环节都不可缺少,在安全的路上懂的越多发现自己不懂的越多。

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 信息安全策略
5.1 信息安全的管理方向 信息安全策略集宜由管理者定义、批准、发布并传达给员工和相关外部方。
5.1.1 信息安全策略 信息安全方针文件应由管理者批准、发布并传达给所有员工和外部相关方。 需要写一个全局性的说明文档,包含:组织环境、领导作用、规划、支持、运行、绩效评价和改进。描述体系适用在哪里,明确职责范围,怎么做,做这些需要什么支持和资源,检查我有没按照要求做好,最后是对自己的考核,以及做的不好的要改进。 信息安全管理手册 参考策略文件
5.1.2 信息安全策略的评审 信息安全策略宜按计划的时间间隔或当重大变化发生时进行评审,以确保其持续的适宜性、充分性和有效性。 一般是在内审完后做评审,主要是确定系统适不适合公司,不适合可以修改,保证体系是适合的、有效的 信息安全体系运行评审制度
信息安全内部审核管理制度
A6 信息安全组织
A6.1 内部组织 在组织内管理信息安全
A6.1.1 信息安全角色和职责 雇员、承包方人员和第三方人员的安全角色和职责应按照组织的信息安全方针定义并形成文件。 明确本公司领导、部门、员工、外包和第三方的职责 信息安全管理手册第三方安全管理策略 参考策略文件
A6.1.2 职责分配 管理者应通过清晰的说明、可证实的承诺、明确的信息安全职责分配及确认,来积极支持组织内的安全。 前面明确了职责现在需要分工 信息安全管理手册第三方安全管理策略 参考策略文件
A6.1.3 与政府部门的联系 应保持与政府相关部门的适当联系。 上级主管单位,消防,公安等政府部门关系,他们对我们的要求,或者我们需要他们提供什么帮助 信息安全管理手册 参考策略文件
A6.1.4 与特定利益集团的联系 应保持与特定权益团体、其他安全专家组和专业的协会的适当联系。 公司集团、股东、投资人,第三方关系,他们对我们的要求 信息安全管理手册 参考策略文件
A6.1.5 项目管理中的信息安全 a) 信息安全目标纳入项目目标;b) 在项目的早期阶段进行信息安全风险评估,以识别必要的控制措施;c) 信息安全监控成为项目每个阶段的组成部分。 项目管理中考虑安全,最直接的是安全建设占项目成本的10%(比例自定义,此处为例子) 信息安全管理手册 参考策略文件
A6.2 移动设备 确保远程工作和使用移动设备时的安全.
A6.2.1 移动设备策略 宜采用策略和支持性安全措施来管理由于使用移动设备带来的风险。 电脑是怎么管理的,怎么领、怎么用、怎么保护、怎么销毁等 移动设备和介质管理策略 参考策略文件
A6.2.2 远程工作 宜实施策略和支持性安全措施来保护在远程工作场地访问、处理或存储的信息 对远程管理系统的要求,用什么样的协议,在那个网络使用是否需要VPN等 网络安全管理策略 vpn接入管理制度
A7 人力资源安全
A7.1 任用之前 确保雇员和承包方人员理解其职责、适于考虑让其承担的角色。
A7.1.1 审查 关于所有任用候选者的背景验证核查宜按照相关法律、法规、道德规范和对应的业务要求、被访问信息的类别和察觉的风险来执行。 对入职员工的背景、技术能力审查,简单说判断这个人是否卧底以及能力是否胜任 人力资源管理策略 人力资源管理制度
A7.1.2 任用条款和条件 与雇员和承包方人员的合同协议宜声明他们和组织的信息安全职责。 员工和公司签定合同、竞业协议、保密协议等
A7.2 任用中 确保雇员和承包方人员知悉并履行其信息安全职责。
A7.2.1 管理职责 管理者宜要求所有雇员和承包方人员按照组织已建立的策略和规程对信息安全尽心尽力。 明确职责 人力资源管理策略 人力资源管理制度
A7.2.2 信息安全意识、教育和培训 组织的所有雇员,适当时,包括承包方人员,宜受到与其工作职能相关的适当的意识培训和组织策略及规程的定期更新培训。 入职培训需要包含安全培训,还需要每年对员工有安全意识培训,含年度计划等
A7.2.3 纪律处理过程 宜有一个正式的、已传达的纪律处理过程,来对信息安全违规的雇员采取措施。 违规了会怎么样,与下面的奖惩对应
A7.3 任用的终止或变更 将保护组织利益作为变更或终止任用过程的一部分。
A7.3.1 任用终止或变更的职责 管理者应要求雇员、承包方人员和第三方人员按照组织已建立的方针策略和程序对安全尽心尽力。 员工离职和岗位变更的时候要怎么做 人力资源管理策略 人力资源管理制度
A8 资产管理
A8.1 对资产负责 识别组织资产,并定义适当的保护职责。
A8.1.1 资产清单 明晰公司资产情况 先找出自己有什么,服务器or应用 资产安全管理策略 资产安全管理制度
A8.1.2 资产所有权 清单中所维护的资产应分配所有权。 服务器是谁管,应用是谁管,数据库是谁管
A8.1.3 资产的可接受使用 信息及与信息和信息处理设施有关的资产的可接受使用规则宜被确定、形成文件并加以实施。 明确职责权限,不能越界,包含公司员工和第三方
A8.1.4 资产的归还 所有的雇员和外部方人员在终止任用、合同或协议时,应归还他们使用的所有组织资产。 离职或变更需要归还公司资产,包含公司员工和第三方
A8.2 信息分类 确保信息按照其对组织的重要性受到适当级别的保护。
A8.2.1 信息的分类 信息宜按照法律要求、价值、关键性以及它对未授权泄露或修改的敏感性予以分类。 对公司的资产分类,定义级别 资产安全管理策略 资产安全管理制度
A8.2.2 信息的标记 宜按照组织所采纳的信息分类机制建立和实施一组合适的信息标记规程。 很少涉及,其实就是资产分了级别,要贴个标签
A8.2.3 信息的处理 宜按照组织所采纳的信息分类机制建立和实施处理资产的规程。 根据不同的等级划分指定不同的防御措施
A8.3 介质处置 防止存储在介质上的信息遭受未授权泄露、修改、移动或销毁。
A8.3.1 可移动介质的管理 宜按照组织所采纳的分类机制实施可移动介质的管理规程。 移动介质的管理,U盘、移动硬盘 移动设备和介质管理策略 移动存储介质管理制度
A8.3.2 介质的处置 不再需要的介质,宜使用正式的规程可靠并安全地处置。 介质管理,怎么使用,怎么保存,怎么销毁
A8.3.3 物理介质传输 包含信息的介质在运送时,宜防止未授权的访问、不当使用或毁坏。 传输过程的完整性和机密性保障
A9 访问控制
A9.1 访问控制的业务要求 限制对信息和信息处理设施的访问。
A9.1.1 访问控制策略 访问控制策略宜建立、形成文件,并基于业务和信息安全要求进行评审。 各种访问控制的建立,网络、文件、系统等的访问控制,其实就是不同的人的权限控制 访问控制策略 参考策略文件
A9.1.2 网络和网络服务的访问 用户应仅能访问已获专门授权使用的网络和网络服务。
A9.2 用户访问管理 确保授权用户访问系统和服务,并防止未授权的访问。
A9.2.1 用户注册及注销 宜实施正式的用户注册及注销规程,使访问权限得以分配。 用户标识要唯一,只能一人一个标识,账户的开通变更需要审批,保证职责分离;账号要有定期审计,保证权限都是合理的;特殊权限指root或admin权限的申请要有要求和限制;在有人员变动的时候首先要禁用其账号,保证离职人员不可以登录系统 访问控制策略 用户账号管理制度
A9.2.2 用户访问开通及变更 宜实施正式的用户访问开通过程,以分配或撤销所有系统和服务所有用户类型的访问权限。
A9.2.3 特殊访问权限管理 宜限制和控制特殊访问权限的分配及使用
A9.2.4 用户秘密鉴别信息管理 宜通过正式的管理过程控制秘密鉴别信息的分配
A9.2.5 用户访问权限的复查 资产所有者应定期复查用户的访问权限。
A9.2.6 撤销或调整访问权限 所有雇员、外部方人员对信息和信息处理设施的访问权限应在任用、合同或协议终止时撤销,或在变化时调整。
A9.3 用户职责 使用户承担保护认证信息安全的责任。
A9.3.1 使用秘密鉴别信息 宜要求用户在使用秘密鉴别信息时,遵循组织的实践。 有密码复杂度要求,不可以共用账号,不可以在文件或纸上写上密码,这里更多说的是基础的安全账号意识 访问控制策略 用户账号管理制度
A9.4 系统和应用访问控制 防止对系统和应用的未授权访问。
A9.4.1 信息访问限制 宜依照访问控制策略限制对信息和应用系统功能的访问 还是上面的访问控制的要求 访问控制策略 参考策略文件
A9.4.2 安全登录规程 在访问控制策略要求下,访问操作系统和应用宜通过安全登录规程加以控制。 不可以暴力登录,需要有登录日志记录,不可以泄漏口令,保证登录的安全
A9.4.3 口令管理系统 口令管理系统宜是交互式的,并宜确保优质的口令。
A9.4.4 特殊权限实用工具软件的使用 对于可能超越系统和应用程序控制措施的适用工具软件的使用应加以限制并严格控制。 特殊权限管理工具需要最小授权,需要审计,使用的账号必须可信
A9.4.5 对程序源代码的访问控制 应限制访问程序源代码。 授权后才可以访问,访问需要有记录,复制和上传源码需要严格管控 软件开发版本安全管理制度
A10 密码学
A10.1.1 密码控制 恰当和有效的利用密码学保护信息的保密性、真实性或完整性。 使用什么样的加密,什么样的加密是不安全的,密码怎么存储,怎么传输,怎么销毁 密码技术管理策略 参考策略文件
A10.1.2 密钥管理 宜开发和实施贯穿整个密钥生命周期的关于密钥使用、保护和生存期的策略。
A11 物理和环境安全
A11.1 安全区域 防止对组织场所和信息的未授权物理访问、损坏和干扰。
A11.1.1 物理安全周边 宜定义安全周边和所保护的区域,包括敏感或关键的信息和信息处理设施的区域。 公司环境的物理安全考虑,防火、门禁、保安、消防、排水、办公室出入授权等,针对自然灾害的物理防护,设立安全区域,重要的工作可以在安全区域内进行,有人来访可以设立一个等待区域 物理安全管理策略 机房安全管理制度视频监控管理制度出入访问管理制度
A11.1.2 物理入口控制 安全区域宜由适合的入口控制所保护,以确保只有授权的人员才允许访问。
A11.1.3 办公室、房间和设施的安全保护 宜为办公室、房间和设施设计并采取物理安全措施。
A11.1.4 外部和环境威胁的安全防护 为防止自然灾难、恶意攻击或事件,宜设计和采取物理保护措施
A11.1.5 在安全区域工作 宜设计和应用工作在安全区域的规程。
A11.1.6 交接区安全 访问点(例如交接区)和未授权人员可进入办公场所的其他点宜加以控制,如果可能,宜与信息处理设施隔离,以避免未授权访问。
A11.2 设备 防止资产的丢失、损坏、失窃或危及资产安全以及组织活动的中断。
A11.2.1 设备安置和保护 宜安置或保护设备,以减少由环境威胁和危险所造成的各种风险以及未授权访问的机会。 简单说就是从各方面保证设备安全 设备安全管理策略 参考策略文件
A11.2.2 支持性设施 宜保护设备使其免于由支持性设施的失效而引起的电源故障和其他中断
A11.2.3 线缆安全 宜保证传输数据或支持信息服务的电源布缆和通信布缆免受窃听或损坏。
A11.2.4 设备维护 设备宜予以正确地维护,以确保其持续的可用性和完整性
A11.2.5 资产的移动 设备、信息或软件在授权之前不宜带出组织场所。
A11.2.6 组织场外设备和资产的安全 宜对组织场所外的设备采取安全措施,要考虑工作在组织场所以外的不同风险。
A11.2.7 设备的安全处置或再利用 包含储存介质的设备的所有项目宜进行验证,以确保在处置之前,任何敏感信息和注册软件已被删除或安全地写覆盖。
A11.2.8 无人值守的用户设备 用户宜确保无人值守的用户设备有适当的保护。
A11.2.9 清空桌面和屏幕策略 遵循良好的信息安全习惯,对非权限内的网络或设备进行控制。 用户习惯要求,其实跟安全意识相关 计算机管理策略 参考策略文件
A12 操作安全
A12.1 操作规程和职责 确保正确、安全的操作信息处理设施。
A12.1.1 文件化的操作规程 操作规程应形成文件并对所有需要的用户可用。 如计算机启动和关机规程、备份、设备维护、介质处理、计算机机房、邮件处置管理和安全等 安全运维管理策略 安全运维管理制度
A12.1.2 变更管理 对影响信息安全的组织、业务过程、信息处理设施和系统等的变更应加以控制。 对资产或系统的变更经行管理 变更管理安全策略 变更管理安全制度
A12.1.3 容量管理 资源的使用应加以监视、调整,并作出对于未来容量要求的预测,以确保拥有所需的系统性能。 对CPU、内存、硬盘、数据库的监控,保证系统性能 安全运维管理策略 安全运维管理制度
A12.1.4 开发、测试和运行环境分离 开发、测试和运行环境应分离,以减少未授权访问或改变运行环境的风险。 开发、测试、运行环境 要分离 软件开发安全策略 软件开发安全管理制度
A12.2 恶意软件防护 确保对信息和信息处理设施进行恶意软件防护。
A12.2.1 控制恶意软件 应实施恶意软件的检测、预防和恢复的控制措施,以及适当的提高用户安全意识。 安装统一防病毒软件,对终端和服务器进行管控 计算机管理策略 参考策略文件
A12.3 备份 为了防止数据丢失。
A12.3.1 信息备份 对重要信息进行备份,防止系统断电等危害引起数据丢失。 重要信息备份 信息备份管理策略 数据备份恢复管理制度
A12.4 日志和监视 记录事态和生成证据。
A12.4.1 事态记录 宜产生记录用户活动、异常情况、故障和信息安全事态的事态日志,并保持定期评审。 要保留日志,对日志记录有要求,如:什么人在什么时间用什么权限对什么系统做了什么操作,方便日后追责和审计。堡垒机其实可以满足要求 安全审计管理策略 参考策略文件
A12.4.2 日志信息的保护 记录日志的设施和日志信息宜加以保护,以防止篡改和未授权的访问。
A12.4.3 管理员和操作员日志 系统管理员和系统操作员的活动宜记入日志,保护日志并定期评审。
A12.4.4 时钟同步 一个组织或安全域内的所有相关信息处理设施的时钟宜使用单一参考时间源进行同步。
A12.5 运行软件的控制 确保运行系统的完整性。
A12.5.1 在运行系统上安装软件 宜实施规程来控制在运行系统上安装软件。 软件白名单,其实很少公司能做得到这样的管理,电脑不可以安装什么,可以安装什么,怎么升级 计算机管理策略 参考策略文件
A12.6 技术脆弱性管理 防止技术脆弱性被利用。
A12.6.1 技术脆弱性的控制 宜及时得到现用信息系统技术脆弱性的信息,评价组织对这些脆弱性的暴露程度,并采取适当的措施来处理相关的风险。 要有风险评估,漏洞扫描之类的 安全运维管理策略 安全运维管理制度
A12.6.2 限制软件安装 应建立和实施软件安装的用户管理规则。 同12.5.1 计算机管理策略 参考策略文件
A12.7 信息系统审计考虑 将运行系统审计活动的影响最小化。
A12.7.1 信息系统审计控制措施 涉及对运行系统验证的审计要求和活动,应谨慎地加以规划并取得批准,以便使造成业务过程中断最小化。 同12.4 安全审计管理策略 参考策略文件
A13 通信安全
A13.1 网络安全管理 确保网络中信息的安全性并保护支持性信息处理设施。
A13.1.1 网络控制 宜管理和控制网络,以保护系统中信息和应用程序的安全。 设置网络ACL、网络传输加密、网络隔离、网络监控,还要求了对提供网络服务的管理要求 网络安全管理策略 防火墙策略管理制度
A13.1.2 网络服务安全 安全机制、服务级别以及所有网络服务的管理要求应予以确定并包括在所有网络服务协议中,无论这些服务是由内部提供的还是外包的。 参考策略文件
A13.1.3 网络隔离 宜在网络中隔离信息服务、用户及信息系统。 参考策略文件
A13.2 信息传递 确保网络中信息的安全性并保护支持性信息处理设施。
A13.2.1 信息传递策略和规程 宜有正式的传递策略、规程和控制措施,以保护通过使用各种类型通信设施的信息传递。 同13.1,细化网络要求,要求较全面 网络安全管理策略 参考策略文件
A13.2.2 信息传递协议 协议应解决组织与外部方之间业务信息的安全传递。
A13.2.3 电子消息发送 包含在电子消息发送中的信息应给予适当的保护。
A13.2.4 保密性或不泄露协议 宜识别、定期评审并记录反映组织信息保护需要的保密性或不泄露协议的要求。
A14 系统获取、开发和维护
A14.1 信息系统的安全要求 确保信息安全是信息系统整个生命周期中的一个有机组成部分。这也包括提供公共网络服务的信息系统的要求。
A14.1.1 信息安全要求分析和说明 信息安全相关要求宜包括新的信息系统要求或增强已有信息系统的要求。 明确软件开发所涉及的安全,从软件开发的需求阶段一直到系统的报废,都要考虑 软件开发安全策略 软件开发安全管理制度
A14.1.2 公共网络应用服务安全 宜保护公共网络中的应用服务信息,以防止欺骗行为、合同纠纷、未授权泄露和修改。
A14.1.3 保护应用服务交易 宜保护涉及应用服务交易的信息,以防止不完整传送、错误路由、未授权消息变更、未授权泄露、未授权消息复制或重放。
A14.2 开发和支持过程中的安全 应确保进行信息安全设计,并确保其在信息系统开发生命周期中实施。
A14.2.1 安全开发策略 宜建立软件和系统开发规则,并应用于组织内的开发。 同14.1,开发首选要有自己的一套开发流程,在这个流程上面补全对应的安全要求 软件开发安全策略 软件开发安全管理制度
A14.2.2 系统变更控制规程 宜通过使用正式变更控制程序控制开发生命周期中的系统变更。
A14.2.3 运行平台变更后应用的技术评审 当运行平台发生变更时,应对业务的关键应用进行评审和测试,以确保对组织的运行和安全没有负面影响。
A14.2.4 软件包变更的限制 宜对软件包的修改进行劝阻,只限于必要的变更,且对所有的变更加以严格控制。
A14.2.5 安全系统工程原则 宜建立、记录和维护安全系统工程原则,并应用到任何信息系统实施工作。
A14.2.6 安全开发环境 组织应建立并适当保护系统开发和集成工作的安全开发环境,覆盖整个系统开发生命周期。
A14.2.7 外包开发 组织应管理和监视外包系统开发活动。
A14.2.8 系统安全测试 在开发过程中,应进行安全功能测试。
A14.2.9 系统验收测试 确保信息系统符合甲方要求
A14.3 测试数据 确保保护测试数据。
A14.3.1 系统测试数据的保护 测试数据应认真地加以选择、保护和控制。 测试数据也需要保护 软件开发安全策略 软件开发安全管理制度
A15 供应商关系
A15.1 供应商关系的信息安全 确保保护可被供应商访问的组织资产。
A15.1.1 供应商关系的信息安全策略 为减缓供应商访问组织资产带来的风险,应与供应商协商并记录相关信息安全要求。 供应商的关系我统一理解为非本公司人员的第三方,对于第三方的要求首先是满足公司的基础要求,跟公司的员工一个级别,但是对于特定的系统他们可能没有权限,还需要签定保密协议 第三方安全管理策略 参考策略文件
A15.1.2 处理供应商协议中的安全问题 应与每个可能访问、处理、存储组织信息、与组织进行通信或为组织提供 IT 基础设施组件的供应商建立并协商所有相关的信息安全要求
A15.1.3 信息和通信技术供应链 供应商协议应包括信息和通信技术服务以及产品供应链相关信息安全风险处理的要求。
A15.2 供应商服务交付管理 保持符合供应商交付协议的信息安全和服务交付的商定水准。
A15.2.1 供应商服务的监视和评审 组织应定期监视、评审和审计供应商服务交付。 同15.1 第三方安全管理策略 参考策略文件
A15.2.2 供应商服务的变更管理 应管理供应商服务提供的变更,包括保持和改进现有的信息安全策略、规程和控制措施,并考虑到业务信息、系统和涉及过程的关键程度及风险的再评估。
A16 信息安全事件管理
A16.1 信息安全事件和改进的管理 确保采用一致和有效的方法对信息安全事件进行管理,包括安全事件和弱点的传达。
A16.1.1 职责和规程 宜建立管理职责和规程,以确保快速、有效和有序地响应信息安全事件。 定义什么是安全事件,事件等级,怎么响应,总结经验,最后的取证调查,为后面的业务连续性计划打基础 信息安全事件管理策略 信息安全事件管理制度
A16.1.2 报告信息安全事态(发生) 信息安全事态宜尽可能快地通过适当的管理渠道进行报告。
A16.1.3 报告信息安全弱点 (未发生) 宜要求使用组织信息系统和服务的所有雇员和承包方人员记录并报告他们观察到的或怀疑的任何系统或服务的安全弱点。
A16.1.4 评估和确定信息安全事态 信息安全事态应被评估,并且确定是否划分成信息安全事件。
A16.1.5 信息安全事件响应 宜具有与信息安全事件响应相一致的文件化规程
A16.1.6 对信息安全事件的总结 获取信息安全事件分析和解决的知识应被用户降低将来事件发生的可能性或影响。
A16.1.7 证据的收集 组织宜定义和应用识别、收集、获取和保存信息的程序,这些信息可以作为证据。
A17 业务连续性管理的信息安全方面
A17.1 信息安全连续性 组织的业务连续性管理体系中应体现信息安全连续性。
A17.1.1 信息安全的连续性计划 组织应确定不利情况下(例如,一个危机或危难时)信息安全的要求和信息安全管理连续性。 保证业务在任何情况下都稳定的运行,首要要明确业务的RPO、RTO,再更具这个指定对应的保证计划和措施。最后为了验证有效性还需要进行应急演练 业务连续性管理策略 参考策略文件
A17.1.2 实施信息安全连续性计划 组织应建立、文件化、实施和维护过程、规程和控制措施,确保在负面情况下要求的信息安全连续性级别。
A17.1.3 验证、评审和评价信息安全连续性计划 组织应定期验证已制定和实施信息安全业务连续性计划的控制措施,以确保在负面情况下控制措施的及时性和有效性。
A17.2 冗余 确保信息处理设施的有效性。
A17.2.1 信息处理设施的可用性 信息处理设备应冗余部署,以满足高可用性需求。 直接字面意思,重要的信息系统要有冗余 业务连续性管理策略 参考策略文件
A18 符合性
A18.1 符合法律和合同要求 避免违反任何法律、法令、法规或合同义务以及任何安全要求。
A18.1.1 可用法律及合同要求的识别 对每一个信息系统和组织而言,所有相关的法律依据、法规和合同要求,以及为满足这些要求组织所采用的方法,宜加以明确地定义、形成文件并保持更新。 满足国家法律法规上级单位要求。收集法律法规,主要选取公司引用的法律法规条文,每年要有专人更新;在不违法法律的前提下还要保证自己的权益,如:著作权、知识产权 信息安全法律法规策略 信息安全法律法规管理制度
A18.1.2 知识产权(IPR) 宜实施适当的规程,以确保相关的知识产权和所有权的软件产品的使用,符合法律、法规和合同的要求。
A18.1.3 保护记录 宜防止记录的遗失、毁坏、伪造、非授权访问和非授权删除,以满足法令、法规、合同和业务的要求。
A18.1.4 隐私和个人身份信息保护 隐私和个人身份信息保护宜确保符合相关法律、法规的要求。
A18.1.5 密码控制措施的规则 使用密码控制措施宜遵从相关的协议、法律和法规。 密码技术管理策略 参考策略文件
A18.2 信息安全评审 确保信息安全实施及运行符合组织策略和程序。
A18.2.1 独立的信息安全评审 宜定期或发生较大变更时对组织的信息安全处置和实施方法(即控制目标、控制、策略、过程和信息安全程序)进行评审。 同5.1.2,安全管理人员开展独立评审,对信息安全体系本身进行评审,因为公司是不断的发展变化的,制度和策略要跟随变化。 信息安全管理手册 信息安全体系运行评审程序内部审核管理程序
A18.2.2 符合安全策略和标准 管理者宜定期对所辖职责范围内的信息安全过程和规程评审,以确保符合相应的安全政策、标准及其他安全要求。
A18.2.3 技术符合性评审 信息系统宜被定期评审是否符合组织的信息安全政策和标准。

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

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

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

       [hr]新增附件,里面的文档是最早期版本,后面我们换了另外一套思路,上文有说。
第一版的模版应该能满足大家的基本需求,提供的只是一个架构体系思路,具体的文档不够详细的,大家根据实际情况补充吧。
有打码不严谨的地方大家就忽略吧(大家不要扣细节,重在参考)。

设置个积分下载吧。

ISMS信息安全管理体系-2013V2.zip (2.3 MB) 下载附件
点击收藏 | 8 关注 | 0
登录 后跟帖