一切之前
什么是27001
ISO/IEC 27001，按照ISO官网对其的介绍[^1]：
ISO/IEC 27001 is the world’s best-known standard for information security management systems (ISMS). It defines requirements an ISMS must meet.
The ISO/IEC 27001 standard provides companies of any size and from all sectors of activity with guidance for establishing, implementing, maintaining and continually improving an information security management system.
Conformity with ISO/IEC 27001 means that an organization or business has put in place a system to manage risks related to the security of data owned or handled by the company, and that this system respects all the best practices and principles enshrined in this International Standard.
ISO/IEC 27001 是全球最著名的信息安全管理体系 (ISMS) 标准。它规定了 ISMS 必须满足的要求。
ISO/IEC 27001 标准为各类规模和所有行业的公司提供了关于建立、实施、维护和持续改进信息安全管理体系的指导。
符合 ISO/IEC 27001 标准意味着组织或企业已建立起管理公司拥有或处理的数据安全风险的体系，并且该体系遵循了本国际标准中规定的所有最佳实践和原则。
27001是一种相对于质量三体系更少见的认证体系，大部分认证体系都是基于合规的要求进行认证，国内当前主打等保认证，对于27001没有强制要求，故而27001没有像三体系一样泛滥。但大部分涉外或中大型公司都会对供应商有信息安全方面的准入要求，如果有数据层面的交互那么更是会强制要求供应商具备至少一个信息安全的认证。在这些前提下，27001作为一个并不算太基础但也完全说不上高端的门槛，确实算是世界范围内知名度最高的信息安全认证了。
另外根据ISO每年的ISO SURVEY（截至本文发布时最新版本为2023版），全球27001证书数量(certificates)为47,291。China区域的证书数量(certificates)为4,108，被认证的物理场所或地点（site）为5,318。这个数字包括了2013版和2022版。作为对比，9001的全球证书数量是837,978
，China区域数量为130,402。由此可以管中窥豹地看出一些27001的含金量。
版本区别
27001的版本是在不断更新的，最近的两个版本是2013和2022版，大部分公司使用的也都是这两个版本。它们之间的区别如下[^2]：
- 标题由《信息技术-安全技术-信息安全管理体系要求》改为《信息安全-网络安全-隐私保护-信息安全管理体系要求》
- 2022版对附录A中信息安全控制框架结构进行了重新构建，2013版的14个安全控制域合并后总结归纳为人员、物理、技术、组织四大主题，这样的分类更加简单，更加方便组织对安全控制项进行选择归类，以加强信息安全控制措施的实施。
2022版的控制项相比2013版，从114个变为93个，其中新增11个控制项，更新58个控制项，合并24个控制项。
新版增加了11个安全控制项，新增加的控制项主要集中在：
- 组织控制主题中增加了威胁情报、云服务以及业务连续性的控制点。
- 技术控制主题主要是增加了关于数据安全、配置管理、信息删除、数据防泄漏、数据屏蔽、监控活动、网站过滤、安全编码等控制点。
- 物理控制主题增加了物理安全监控。
| 5.组织控制 | 6.人员控制 | 7.物理控制 | 8.技术控制 | |||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 5.1信息安全策略 | 5.11资产归还 | 5.21ICT供应链中的信息安全管 | 5.31法律法规、监管 和合同要求 | 6.1审查 | 7.1物理安全边界 | 7.11支持性设施 | 8.1用户终端设备 | 8.11数据屏蔽 | 8.21网络服务安全 | 8.31开发、测试与生产环境的隔离 |
| 5.2信息安全角色与职责 | 5.12信息的分级 | 5.22供应商服务的监 视、评审和变更管理 | 5.32知识产权 | 6.2任用条款及条件 | 7.2物理入口 | 7.12布缆安全 | 8.2特许访问权 | 8.12数据防泄漏 | 8.22网络隔离 | 8.32变更管理 |
| 5.3职责分离 | 5.13信息的标记 | 5.23使用云服务的信息安全 | 5.33记录保护控制 | 6.3信息安全意识、 教育和培训 | 7.3办公室、房间和 设备的安全保护 | 7.13设备维护 | 8.3信息访问限制 | 8.13信息备份 | 8.23网站过滤 | 8.33测试信息 |
| 5.4管理职责 | 5.14信息传输 | 5.24信息安全事件管 理的策划和准备 | 5.34隐私和 PII（个 人可识别信息） 的保护 | 6.4违规处理过程 | 7.4物理安全监控 | 7.14设备的安全处置 或再利用 | 8.4对源代码的访问 | 8.14信息处理设施的 冗余 | 8.24密码使用 | 8.34审计测试期间的 信息系统保护 |
| 5.5与职能机构的联系 | 5.15访问控制 | 5.25信息安全事态的 评估和决策 | 5.35信息安全的独立 评审 | 6.5任用终止或变更 后的责任 | 7.5物理和环境威胁 的安全防护 | 8.5身份验证安全 | 8.15日志管理 | 8.25开发生命周期安 全 | ||
| 5.6与特定相关方的联系 | 5.16身份管理 | 5.26信息安全事件的 响应 | 5.36符合信息安全的 策略、规则和标 准 | 6.6保密和不泄露协 议 | 7.6在安全区域工作 | 8.6容量管理 | 8.16监控活动 | 8.26应用程序安全要 求 | ||
| 5.7威胁情报 | 5.17鉴别信息 | 5.27 从信息安全事件中的学习 | 5.37文件化的操作规程 | 6.7远程工作 | 7.7清理桌面和屏幕 | 8.7恶意软件防范 | 8.17时钟同步 | 8.27安全系统架构和 工程原则 | ||
| 5.8项目管理中的信息安全 | 5.18访问权限 | 5.28证据的收集 | 6.8信息安全事态报 告 | 7.8设备安置和保护 | 8.8技术脆弱性管理 | 8.18特许权实用程序 的应用 | 8.28安全编码 | |||
| 5.9信息及其他资产清单 | 5.19供应商关系的信息安全 | 5.29中断期间的信息 安全 | 7.9组织场所外的资 产安全 | 8.9配置管理 | 8.19运行系统的软件 安装 | 8.29开发和验收中的 安全测试 | ||||
| 5.10信息和其他相关资产的可接受使用 | 5.20在供应商协议中强调信息安全 | 5.30业务连续性的ICT准备 | 7.10存储介质 | 8.10信息删除 | 8.20网络安全 | 8.30外包开发 |
认证流程
ISO27001认证的六大流程:
差距分析：从人员、环境、技术、管理四个方面对企业进行评估调研，发掘组织信息安全需求，分析与标准之间差距，明确体系实施的目标、范围和要点
培训导入：开展信息安全基础知识培训、项目专题培训、体系建立指导等，导入信息安全管理思想，明确各岗位信息安全管理职责
体系建立：结合组织信息安全目标和方针，指导、协助编写ISO27001程序文件、管理手册，制定合乎规范的管理规程和控制措施
推广实施：在企业内部推进体系运行，识别信息安全风险资产，在适宜时间开展有效的内部评审和管理评审，保留体系有效运行证据
现场审核：向第三方认证机构申请信息安全管理体系认证，协助企业完成现场审核整改或纠正审核过程中产生的不符合项。
改进维持：规划体系年度审核计划及方案，按照PDCA原则，结合企业实际需求，继续完善和改进信息安全管理体系。
实际上个人体验的话，程序文件建立与信息安全风险识别这两点最为关键，后续的现场审核其次，这两点做得好现场审核一般不会出什么问题，其他更多是日常的水磨工夫。不过我是以实际安全的角度出发，如果以拿证的角度出发那没有什么比现场审核更重要了。只需要通过模板和参考生成一堆完全不符合公司情况也没有实际价值但非常详细精美的制度文件及相关运行记录，然后在咨询机构的帮助下再生成一堆看起来可靠的安全风险评估表，最后和审核机构进行一些利益交换（国内大部分审核机构同时都有咨询业务，无非是过不过白手套），开具一两个轻微不符合项，然后等发证就行。这种模式也是大部分公司过认证的常态，不单单只是27001认证。不得不说挺没劲的，*叹气。
认证流程（PDCA）
凡是属于“管理体系标准”的 ISO 标准，几乎都遵循戴明环（PDCA）原则，我认为这是合理的，PDCA几乎是所有具备持续改进特点的项目都应该尽量去实现的管理方法。
PLAN
人类想象不出从未见过的意象，这一点在制度编写的过程中体现得淋漓尽致。凭空创造任何东西都是痛苦的，参考文件和人对目标交付物的认知决定了对痛苦的削弱程度。但无论如何，痛苦总是存在。
制度编写的难度取决于你对安全的认知和参考/模板文献的多少（或者说你能直接抄多少）。27001的审核会逐项对照附录A的要求，并以一种操作指南式的方式引导审核员对附录A的要求进行确认满足，一项项对照直到全部满足。这其中大部分是确认制度中是否有某些内容。例如：（这里后续补充）
所以实际上制度中的必要元素——需要包含什么内容以及需要提到什么内容——这些都是规定死的，编写者需要首先满足这些必要元素，再在其之上编写符合公司情况与自己对安全理解的制度。
大部分编写者（包括我）的编写方式都是参考咨询机构提供的模板，结合公司当下情况，修改出一版看起来挺像那么回事的底稿。这里值得一提的是公司是否有现存的安全制度和意识。如果公司本身就存在一些信息安全类的考量，比如文档分类分级，比如人员保密协议，比如对资产的盘点，那么很多制度就可以直接沿用进底稿。
关于内审
内审在我的体验中主要内容是风险评估。
风险评估依照《信息安全风险评估表》，理论上每个部门都应该建立一份，按年或半年度更新。评估方法可以参考以下标准和框架：
1. 《信息安全技术 信息安全风险评估方法》（GB/T 20984—2022）：作为我国信息安全领域的基础性标准，该标准自第一版发布以来，有效指导了我国信息安全风险评估工作开展，成为了国家各级网络安全主管机关、各行业主管部门开展信息安全管理工作的重要抓手，为国家网络安全保障体系的搭建、保障我国数字经济的高质量发展作出了贡献。
2. ISO/IEC 27005：国际标准化组织（ISO）和国际电工委员会（IEC）联合发布的《信息技术 - 安全技术 - 信息安全风险管理指南》。该标准提供了一套全面的信息安全风险管理框架和方法，包括风险评估、风险处理和风险监控等。
3. NIST SP 800-30：美国国家标准与技术研究院（NIST）发布的《风险管理指南》。该指南提供了一套风险管理框架和方法，包括风险评估、风险处理和风险监控等，适用于各种组织和行业。
4. OWASP Risk Rating Methodology：开放式Web应用安全项目（OWASP）提供的风险评估方法。该方法主要用于评估Web应用程序的安全风险，包括威胁模型、漏洞评估和风险评估等。
5. CIS Critical Security Controls：由Center for Internet Security（CIS）提供的一套网络安全控制框架。该框架包括20个关键安全控制，用于评估和改善组织的网络安全状况。
我详细看过相关标准，基本大差不离：首先划分范围，然后区分业务，然后根据业务来识别各类资产，对资产进行评分，然后对重要资产进行风险脆弱性分析，最后出具风险处置计划并判断残余风险是否可以接受。
ICT 供应商
ICT（Information and Communications Technology）供应商是2022版本中突出的概念之一。2013中对此有一定的描述。
参考文献
[^1]:ISO/IEC 27001:2022 - Information security management systems
[^2]:深度解读《ISO/IEC 27001:2022信息安全-网络安全-隐私保护-信息安全管理体系要求》-新华三集团-H3C