ISO27001信息安全管理国标新版解读精要文档格式.docx

ISO27001信息安全管理国标新版解读精要文档格式.docx

《ISO27001信息安全管理国标新版解读精要文档格式.docx》由会员分享，可在线阅读，更多相关《ISO27001信息安全管理国标新版解读精要文档格式.docx（23页珍藏版）》请在冰点文库上搜索。

组织可以根据自身的情况，选用简化的风险评估方法，或继续使用现行的方法。

新版中依然未明确评估周期。

（6.1.2）。

（老李：

实操层面，当前风险评估可参照的标准有ISO31000，GBT20984，ISO27005，但此类标准都有各自的问题，包括逻辑性、操作性，实际应用中要有所取舍）。

d）风险属主

6.1.2识别风险中“风险属主”替代了“资产责任人”。

资产所有者未必是风险属主，风险属主可以是资产的管理者、该风险管控的负责人（如部门领导）、或组织领导者等。

（6.1.2）

e）风险处置

组织可自行选择所需控制，而不仅限于从附录A中选择；

明确了风险处置计划和残余风险需要风险属主审批。

（6.1.3）。

注意，风险属主可能是一个人、多个人或一个代表，也包括非IT人员。

f）RA参考标准

明确信息安全风险评估和风险处置过程与ISO31000:

2009相一致。

备注中的风险评估参考文件从ISO/IECTR13335-3，《信息技术-IT安全管理指南-IT安全管理技术》变成了ISO31000:

2009。

（6.1.3）

g）信息安全目标

对信息安全目标及实现的要求独立为6.2，6.2中对目标的制定、沟通、测量、时间计划、更新、职责等的要求比旧版更为明确。

h）文档要求

旧版中4.2Documentationrequirements变成了新版的7.5Documentationinformation，对于文件“编制和更新”的要求独立出来。

旧版的4.3.2文件控制，4.3.3记录控制，合并为新版的“文件控制”。

内容上更精简，架构上更灵活，通用性强。

旧版4.3.1中对于强制性文件的要求在新版中不再有。

新版中的Documentinformation，指的可能是document（文件），也可能是record（记录），其目的是为了证明过程已经实施，表明体系的有效性。

新版中关于文档控制的要求基本不变。

但要留意新版对保留过程文档信息Documentationinformation的要求几乎散布了标准各个章节，包括：

4.3ScopeoftheISMS

8.3Resultsoftheinformationsecurityrisktreatment

5.2Informationsecuritypolicy

9.1Evidenceofthemonitoringandmeasurement

6.1.2Informationsecurityriskassessmentprocess

results

6.1.3Informationsecurityrisktreatmentprocess

9.2g）Evidenceoftheauditprogramme（s）andthe

6.1.3d）StatementofApplicability

auditresults

6.2Informationsecurityobjectives

9.3Evidenceoftheresultsofmanagementreviews

7.2d）Evidenceofcompetence

10.1f）Evidenceofthenatureofthenonconformities

7.5.1b）Documentedinformationdeterminedbythe

andany

organizationasbeingnecessaryfortheeffectiveness

subsequentactionstaken

oftheISMS

10.1g）Evidenceoftheresultsofanycorrective

8.1Operationalplanningandcontrol

action

8.2Resultsoftheinformationsecurityriskassessments

对document的要求在以上标准条款中都有重复，个人觉得比较罗嗦，当然也可理解为BSI/ISO比之前更加重视对管理文档化的要求。

老李飞刀点评：

除了正文中的Documentationinformation的（通用）要求外，附录A的多项控制措施中也提到documented即文件化的要求，看得出标准对于文件的要求在整体上放宽了但在局部却变得更严了。

大家

知道管理制度文件并不是越多越好的，但问题来了，哪些文件是要写的？

哪些是可以不写的？

编写文件的重点或颗粒度该如何把握？

这就要看各人的经验和把握了。

老李认为最好的作法的是“编写文件，但要忘记文件”，什么意思呢，其实大家知道日常工作中是没有人是读着文件做事的，所有安全管理要求和控制措施应融合到已有的业务工作中去，并实现管理的流程化和电子化，达到安全工作从“有形”到“无形”，这才是安全落地的终极目标，否则相关的问题是很多的。

关于此项的探讨请见本系列文章四《信息安全管理体系落地的最佳实践》。

i）外包安全

明确了外包涉及的风险应受管控。

对应的是附录A.15供应商关系中的5项参考控制措施。

（8.1）

j）测量与绩效评价

旧版4.2.2控制措施有效性测量和4.2.3MonitorandreviewtheISMS在新版中变成了第9章Performance

evaluation。

绩效评价的要求包括：

监视、测量、分析、评价；

并以5W1H（测什么？

如何测？

何时测？

何时分析？

谁来分析？

谁负责评价）的方式提出了监视和测量的要求。

相比旧版相关要求显得逻辑更清晰，要求更明确。

k）管理评审

新版中已简化管理评审程序要求，如管理评审原先要求的9大输入5大输出调整为新版的6大审查项目。

而评审周期从“每年至少一次”变为“按计划定期执行”。

（9.3）

l）持续改进

取消了旧版8.3的预防性控制的要求，因风险评估与处置本身就是预防性控制。

增加了“应评审已执行纠正措施的有效性”，同时要求应确认“是否有相似的不符合项存在或可能发生”。

（正文条款10）

m）从标准正文中删除的要求

旧版条款

要求

老李解读

4.2.1（g）

ThecontrolobjectivesandcontrolsfromAnnexAshallbeselectedaspartofthisprocessassuitabletocover

theserequirements.

新版中明确组织可选择任何适用的控制，包括但不限于

附录A的内容。

4.2.1（i）

Obtainmanagementauthorizationtoimplementandoperate

theISMS.

旧版在风险评估条款里谈这

个，有点多余，该删

4.2.3（a）（1

）

promptlydetecterrorsintheresultsofprocessing;

难以操作/不适当

4.2.3（a）（2

promptlyidentifyattemptedandsuccessfulsecurity

breachesandincidents;

要求太具体/不适当

4.2.3（a）（4

helpdetectsecurityeventsandtherebypreventsecurity

incidentsbytheuseofindicators;

and

4.2.3（a）（5

determinewhethertheactionstakentoresolveabreach

ofsecuritywereeffective.

4.2.3（h）

Recordactionsandeventsthatcouldhaveanimpacton

theeffectivenessorperformanceoftheISMS（see4.3.3）.

4.3.1

Documentationshallincluderecordsofmanagementdecisions,ensurethatactionsaretraceableto

managementdecisionsandpolicies,andtherecorded

旧版：

管理决策与可重现？

措辞不妥

resultsarereproducible.

文件应包括管理层决策的记录，确保措施可以追溯到管理层决策和策略，确保记录结果是可重复；

Itisimportanttobeabletodemonstratetherelationshipfromtheselectedcontrolsbacktotheresultsoftheriskassessmentandrisktreatmentprocess,andsubsequentlybacktotheISMSpolicyandobjectives.

重要的是能够证明所选择的控制措施与风险评估和风险处理过程的结果之

间的关系，以及追溯到信息安全管理策略和目标。

在新版正文的风险评估中有要求。

旧版4.3“文件控制”中此项要求自然删去。

4.3.1（c）

proceduresandcontrolsinsupportoftheISMS;

由新版7.5.1A取代

4.3.2

Adocumentedprocedureshallbeestablishedtodefinethe

managementactionsneededto:

由新版7.5.3取代

4.3.3

Thecontrolsneededfortheidentification,storage,protection,retrieval,retentiontimeanddispositionof

recordsshallbedocumentedandimplemented.

原记录控制转到新版的

7.5.3，统一为文件控制

andofalloccurrencesofsignificantsecurityincidents

relatedtotheISMS.

5.2.1（b）

ensurethatinformationsecurityproceduressupportthe

businessrequirements;

罗嗦了

5.2.1（d）

maintainadequatesecuritybycorrectapplicationofall

implementedcontrols;

多余

6（d）

Theresponsibilitiesandrequirementsforplanningandconductingaudits,andforreportingresultsandmaintainingrecords（see4.3.3）shallbedefinedina

documentedprocedure.

太罗嗦、多余

8.3

Thedocumentedprocedureforpreventiveactionshall

definerequirementsfor:

新版中不再采用

preventiveaction提法

8.3（e）

Thepriorityofpreventiveactionsshallbedetermined

basedontheresultsoftheriskassessment.

2.3附录A的变化

综述：

控制措施的设置上，ISO27001:

2013保留了多数老的控制项，但对旧版中相近或类似的项进行了整合，删除了部分过时的或太过于具体的控制措施。

针对这几年信息技术的发展，将移动设备管理列入了控制项

（A.6.2.1Mobiledevicepolicy）。

域的结构：

在新版中，加密控制和供应商管理则成为单独的领域。

旧版中的（Communications&

Operations）领域，拆分成（Operationssecurity）和（Communicationssecurity）。

老李点评：

操作安全和通信安全的管理领域相对独立，各自的内容也不少，旧版标准中混在一起谈本来就不合适，我们在ISMS项目实施过程中经常觉得挺别扭，8年后的今天标准才纠正此类问题。

a）新增控制措施

编号

控制项

说明

飞刀解读

A.6.1.5

Informationsecurityinproject

management项目管理中的信息安全

Informationsecurityshallbeaddressedinprojectmanagement,regardlessofthetypeofproject.

在项目早期就应考虑项目的安全风险，进行控制。

特别是外包项目，合作项目。

当然此控制项并非独立的控制项，落实上与人员安全、访问控制、供应商关系内的各

控制项紧密相关。

A.12.6.2

Restrictionsonsoftware

installation限制

软件安装

Rulesgoverningtheinstallationofsoftwarebyusersshallbeestablishedandimplemented.

一为终端安全；

二为知识产权考虑。

适用于国内普遍情况

A.14.2.1

Securedevelopment

policy开发的安全策略

Rulesforthedevelopmentofsoftwareandsystemsshallbeestablishedandappliedtodevelopmentswithinthe

organization.应建立组织内部的软件和系统开发准则。

新版要求建立适用于软件开发生命周期的策略（落实上可单列，也可包含在整个开发策略中）；

其要求也与软件开发的项目管理（安全）亦相关。

从文件编写考虑，此二级文件可包含A.14.2

中大部分控制要求。

A.14.2.5

Securesystemengineering

principles安全系统工程原则

Principlesforengineeringsecuresystemsshallbeestablished,documented,maintainedandappliedtoanyinformationsystemdevelopment

efforts.基于安全工程原则的信息系统工程原则应被建立、文件化、应用于内部信息系统工

程活动。

与开发安全策略不同的是，此项控制更技术、更细节，可包含旧版A.12.2的相关要求（如输入输出控制等。

此控制项可支撑A.14.2.1落地。

A.14.2.6

environment建立和保护开发环境

Organizationsshallestablishandappropriatelyprotectsecuredevelopmentenvironmentforsystemdevelopmentandintegrationeffortsthatcovertheentiresystem

developmentlifecycle.组织应建立并适当保护系统开发和集成工作的安全开发环境，覆

盖整个系统开发生命周期。

从数据安全、访问控制、环境分离、异地备份等方面明确了管理要求，要求更加全面，主要目的为了代码安全。

旧版标准仅在A.10.1.4中提到开发环境分离的要求。

A.14.2.8

Systemsecurity

testing系统安全测试

Testingofsecurityfunctionalityshallbecarriedoutduringdevelopment.在开发过程中应进行安全功能测试

新系统或更新的系统在开发过程中均需要全面的测试验证，如在一定条件下测试输入和期望的输出。

此要求有点模糊，个人理解是做局部

的功能性测试。

A.14.2.9

Systemacceptance

testing系统验收测

对于新建信息系统和新版本升级系统，应建立验收测试方案和相关准则。

系统验收测试宜包括信息安全要求测试（见14.1.1和

14.1.2）并遵循系统安全开发

试

事件

（见14.2.1），宜进行单元测试和系统集成测试。

A.15.1.1

Information

Informationsecurityrequirements

此项具体控制要求较多，编

securitypolicy

formitigatingtherisksassociated

写文件/实施控制时应参见

forsupplier

withsupplieraccessto

ISO27002:

2013；

relationships供

organization’sassetsshallbe

应商关系的信息安全

documented.为降低供应商访问组织资产带

策略

来的风险，宜与供应商协商并记录相关信息安全

要求。

A.15.1.3

Informationand

Agreementswithsuppliersshall

新版提出了供应链的概念，

communication

includerequirementstoaddressthe

至于什么是IT的供应链，与

technology

informationsecurityrisks

供应商的协议应包含什么要

supplychain信息

associatedwithinformationand

求，应参见27002（个别内容

和通信技术的供应链

communicationstechnologyservices

比较抽象，要细化）。

此项控

andproductsupplychain.供应商协议

制的达成体现在协议模板的

应包括信息和通信技术服务以及产品供应链相

制定及实际应用上。

关信息安全风险处理的要求。

A.16.1.4

Assessmentand

Informationsecurityeventsshallbe

安全事件处理中新增的评估

decisionon

assessedanditshallbedecidedif

步骤，与A.16.1.2相关；

information

theyaretobeclassifiedas

信息安全事态：

信息安全威

securityevents评

informationsecurityincidents.信息

胁的行为已经发生，可能造

估和决策信息安全事

安全事态应被评估，并且确定是否划分成信息安

成负面影响。

件

全事件。

信息安全事件：

胁的行为已经发生，且已经

造成负面影响。

A.16.1.5

Responseto

Informationsecurityincidentsshallberespondedtoinaccordancewiththedocumentedprocedures.按文件化的程序

响应

强调安全事件响应的规范

性、程序化。

security

incide