ISO27001:2013信息安全控制实用守则之操作安全
发布时间：2018-11-07 浏览次数：2125
12 操作安全
12.1 操作程序和职责
目标：确保正确、安全的信息处理设施运行。
12.1.1 文件化的操作程序（原 10.1.1）
控制措施
运行程序应形成文件、并对所有需要的用户。
实施指南
应为与信息处理和通信设施相关的操作活动准备形成文件的程序，例如计算机启动和关机程序、备份、设备维护、介质处理、计算机机房、邮件处置管理和安全设备等。
运行程序应详述操作指南，包括：
a） 系统的安装和配置；
b） 自动和手动加工和处理信息；
c） 备份（见 12.3）；
d） 规划要求，包括与其他系统的相互关系、最早工作开始时间和最后工作完成时间；
e） 在工作执行期间处理错误或其它的异常条件的操作指南，包括对系统工具的使用限制（见 9.4.4）；
f） 支持和升级联系，包括出现非预期操作或技术难题时的外部支持联系；
g） 特定输出及介质处理的指作指南，诸如特殊文具的使用或保密输出的管理，包括任务失败时输出的安全处置程序（见 8.3 和 11.2.7）；
h） 系统失败事件使用的系统重启和恢复程序；
i） 审计跟踪和系统日志信息的管理（见 12.4）；
j） 监视程序。
操作程序和系统活动的文档化程序应作为正式的文件处理，其变更由管理者授权。技术上可行时，信息系统应使用相同的程序、工具和工具软件进行一贯的管理。
12.1.2 变更管理（原 10.1.2）
控制措施
对影响信息安全的组织、业务流程、信息处理设施和系统的变更应加以控制。
实施指南
特别的，下列条款应予以考虑。
a）重大变更的识别和记录；
b）变更的策划和测试；
c）对这种变更的潜在影响的评估，包括信息安全影响；
d）对建议变更的正式批准程序；
e）验证信息安全要求已被满足；
f） 向所有有关人员传达变更细节；
g）回退程序，包括从不成功变更和未预料事件中中止和恢复的程序与职责；
h）紧急变更处理的规定使需要恢复事件的变更能快速且在受控下完成。
正式的管理职责和程序应是适当的，以确保所有的变更的的控制。当发生变更时，包含所有相关信息的审计日志要予以保留。
其它信息
对信息处理设施和系统的变更缺乏控制是系统或安全故障的常见原因。对运行环境的变更，特别是当系统从开发阶段向运行阶段转移时，可能影响应用程序的可靠性。（见14.2.2）。
12.1.3
容量管理（原 10.3.1）
控制措施
资源的使用应加以监视、调整，并应作出对于未来容量要求的预测，以确保拥有所需的系统性能。
实施指南
关注有关系统的业务临界状态，应识别容量要求。应使用系统调整和监视确保必需提高的系统可用性和效率。应有检测控制措施以及时地指示问题。未来容量要求的预测应考虑新业务和系统的要求以及组织信息处理容量的当前和预期的趋势。需要特别关注长订货交货周期或高成本相关的所有资源；因此管理者应监视关键系统资源的使用。他们应识别出使用的趋势，特别是有关业务应用或信息系统管理工具。管理者应使用这些信息来识别和避免潜在的瓶颈及对关键员工的依赖，他们可能引起对系统安全或服务的威胁，并策划适当的行动。
提供足够的容量可以由增加容量或降低需求来获得。管理容量需求的例子包括：
a) 废弃数据的删除（磁盘空间）；
b) 应用、系统、数据库或环境的退役；
c) 优化批处理和进度；
d) 优化应用逻辑或数据库队列；
e) 拒绝或限制渴求资源的带宽，如果这些不是关键业务（如，视频流）。应考虑关键任务系统的文档化的容量管理计划。
其它信息
这个控制措施也处理人力资源、办公室和设备的容量，
12.1.4 开发、测试和运行环境分离（原 10.1.4）
控制措施
开发、测试和运行环境应被分离，以减少未授权访问或对运行环境变更的风险。
实施指南
为防止操作的问题，运行、测试和开发环境之间的的分离级别应被识别并实施是必须的。
下列条款应加以考虑：
a) 软件从开发转移到运行状态的规则应被定义并形成文件；
b) 开发和运行应运行在不同的系统或计算机处理器上，且在不同的域或目录内；
c) 运行系统和应用的变更应在应用到运行系统之前，在测试或升级环境中进行测试；
d) 除特殊例外情况，测试不应在运行系统上完成；
e) 编译器、编辑器、其他开发工具或系统工具如果没有要求，不应从运行系统中访问到；
f) 用户应在运行和测试系统中使用不同的用户档案文件，菜单要显示合适的标识消息以减少出错的风险；
g) 敏感数据不应拷贝到测试系统环境中，除非为测试环境提供等效的控制措施（见14.3）。
其它信息
开发和测试活动可能引起严重的问题，例如，文件或系统环境的不需要的修改或者系统故障。有必要保持一种已知的和稳定的环境，来执行有意义的测试并防止不适当的开发者访问到运行环境。若开发和测试人员访问运行系统及其信息，那么他们可能会引入未授权和未测试的代码或改变运行数据。在某些系统中，这种能力可能被误用于实施欺诈，或引入未测试的或恶意代码，从而导致严重的运行问题。开发者和测试者还造成对运行信息保密性的威胁。如果开发和测试活动共享相同的计算环境，那么可能引起非故意的软件和信息的变更。因此，为了减少意外变更或未授权访问运行软件和业务数据的风险，分离开发、测试和运行环境是有必要的（见 14.3 的测试数据保护）。
12.2 恶意软件防护
目标：确保信息和信息处理设施不受恶意软件侵害。
12.2.1 控制恶意软件（原 10.4.1）
控制措施
与适当的用户意识相结合，实施检测、预防和恢复控制措施来防范恶意软件。
实施指南
防范恶意代码要基于恶意代码监测、修复软件、信息安全意识、适当的系统访问和变更管理控制。下列指南要加以考虑：
a）建立禁止使用未授权软件的正式策略（见 12.6.2 和 14.2）；
b）实施控制措施预防和检测未授权软件的使用（如，应用程序白名单）；
c）实施控制措施预防和检测已知或可疑恶意代码网络的使用（如，黑名单）；
d）建立防范风险的正式策略，该风险与来自或经由外部网络或在其他介质上获得的文件和软件相关，此策略指示应采取什么保护措施；
e）减少可能被恶意代码利用的脆弱性，如，通过技术脆弱性管理（见 12.6）；
f） 对支持关键业务过程的系统中的软件和数据内容进行定期评审。应正式审查存在的任何未批准的文件或未授权的修改；
g）安装和定期更新恶意代码检测和修复软件来扫描计算机和介质，以作为预防控制或作为例行程序的基础；执行的扫描应包括：
1）恶意代码使用前，扫描从网络上接收到的任何文件或通过任何存储介质的格式；
2）恶意代码使用前，扫描电子邮件附件和下载内容；该扫描应被执行在不同地方，如，在电子邮件服务器、台式计算机和进入组织的网络时；
3）针对恶意代码，扫描 web 页面；
h）定义程序和职责，以处理在系统上防护恶意代码、对他们使用的培训、恶意代码攻击报告和恢复；
i） 制定适当的从恶意代码攻击中恢复的业务连续性计划，包括所有必要数据和软件备份以及恢复安排（见 12.3）；
j） 实施程序定期收集信息，如，订阅邮件列表或检查提供新恶意代码信息的 web 站点；
k）实施检验与恶意代码相关信息的程序，并确保警告公告是准确和翔实的；管理者应确保使用合格的来源，如，声誉好的期刊、可靠的 Internet 网站或防范恶意代码软件的供应商，被用来区分虚假的和真实的；要让所有用户了解欺骗问题，以及在收到它们时要做什么。
l） 孤立的环境，可能导致灾难性的影响。
其它信息
在信息处理环境中使用来自不同供应商和技术的防范恶意代码的两个或多个软件产品，能改进恶意代码防护的有效性。应注意防止在实施维护和紧急程序期间引入恶意代码，这将避开正常的恶意代码防护的控制措施。
某种情况下，恶意代码防护可能导致运行中的干扰。
恶意代码检测和修复软件的使用独立的作为一个恶意代码控制措施，通常是不胜任的，一般需要伴有预防恶意代码介绍的运行程序。
12.3 备份
目标：防止数据丢失。
12.3.1 信息备份（原 10.5.1）
控制措施
根据既定的备份策略备份信息、软件和系统映象的拷贝，并定期测试。
实施指南
应建立备份策略来定义组织对信息、软件和系统备份的要求。备份策略应定义保留和保护要求。应提供足够的备份设施，以确保所有基本信息和软件能在灾难或介质失效后进行恢复。当设计备份计划时，下列条款应加以考虑：
a） 精确的和完整的备份拷贝的记录和文档化恢复程序应被产生；
b） 备份的程度（如，全备份或差异备份）和频率应考虑组织的业务要求、涉及信息的安全要求和组织连续运行信息的临界状态；
c） 备份应被存储在远端场所，这个场所应保持足够的距离以避免因主场所发生灾难而对备份造成的任何损害；
d） 应给予备份信息一个与主办公场所应用标准相一致的适当的物理和环境保护等级（见 11）;
e） 必要时，定期地测试备份介质，确保当需要应急使用时可以依靠这些备份介质；这应与恢复程序结合并检查对恢复所需要的时间。测试恢复备份数据的能力应被执行，映射到专用的测试介质，不是重写原始介质，避免备份或恢复过程失败而导致不可修复的数据损坏或丢失；
f） 在保密性十分重要的情况下，备份应通过加密方法进行保护。
运行程序应监视备份的执行和预定备份的故障处理，以确保备份根据备份策略来完成。各个系统和服务的备份安排应定期测试，以确保他们满足业务连续性计划的要求。对于关键系统和服务，备份安排覆盖在发生灾难时恢复整个系统所必需的所有系统信息、应用和数据。基本业务信息的保存期应被确定，考虑对永久保存的存档拷贝的任何要求。
12.4 日志和监控
目标：记录事态并生成证据。
12.4.1 事态日志（原 10.10.1）
控制措施
事态日志记录用户活动、例外、故障和信息安全事态，应被产生、保持和定期评审。
实施指南
当相关联的时候，事态日志应包括：
a） 用户 ID；
b） 系统活动；
c） 日期、时间和关键事态的细节，例如注册和注销；
d） 若有可能，设备身份或位置，以及系统标识；
e） 成功的和被拒绝的对系统尝试访问的记录；
f） 成功的和被拒绝的对数据以及其他资源尝试访问的记录；
g） 系统配置的变化；
h） 特权的使用；
i） 系统工具和应用程序的使用；
j） 访问的文件和访问类型；
k） 网络地址和协议；
l） 访问控制系统引发的报报警；
m） 防护系统的激活和停用，如，防病毒系统和入侵检测系统；
n） 用户在应用上执行的交易记录。
事态日志安置基本的自动监视系统，在系统安全上能产生统一的报告和告警。
其它信息
事态日志可以包含敏感数据和个人可识别的信息。应采取适当的隐私保护措施（见18.1.4）。可能时，系统管理员不允许删除或停用他们自己活动日志。
12.4.2 日志信息的保护（原 10.10.3）
控制措施
日志设施和日志信息应加以保护，以防止篡改和未授权的访问。
实施指南
应实施控制措施以防止日志信息被未授权更改和与日志设施有关的操作问题，包括：
a) 更改已记录的消息类型；
b) 日志文件被编辑或删除；
c) 超越日志文件介质的存储容量，导致不能记录事态的故障或过去记录事态被覆盖。一些审计日志可能需要被存档，以作为记录保留策略的一部分，或由于收集和保留证据的要求（也见 16.1.7）。
其它信息
系统日志通常包含大量的信息，其中许多与信息安全监视无关。为帮助识别出对安全监视目的有重要意义的事态，应考虑将相应的消息类型自动地拷贝到第二份日志，或使用适合的系统工具或审计工具，执行文件查询及合理化。需要保护系统日志，因为如果其中的数据被修改或删除，它们的存在可能产生安全的虚假感觉。实时拷贝系统日志到系统管理员或操作员控制外的系统，可以用来保护日志。
12.4.3 管理员和操作员日志（原 10.10.4）
控制措施
系统管理员和系统操作员活动应被记录、日志被保护并定期检查。
实施指南
特权用户帐号持有者在他们的直接控制下也许能够操纵信息处理设施上的日志，因此，保护和审查维护日志对特权用户赋予责任是必要的。
其它信息
对在系统和网络管理员控制之外进行管理的入侵检测系统可以用来监视系统和网络管理活动的符合性。
12.4.4 时钟同步（原 10.10.6）
控制措施
一个组织或安全域内的所有相关信息处理系统的时钟应使用一个单一的时钟源进行同步。
实施指南
时间的表现、同步和精确性的外部和内部的要求应被文件规定。这些要求可能是法律的、监管的、合同要求的、标准符合性的或内部监视要求的。组织内使用的标准参考时间应被定义。组织从外部源获得参考时间的方法和如何可靠地同步内部时钟应被记录在案并被实施。
其它信息
正确设置计算机时钟对确保审计记录的准确性是重要的，审计日志可用于调查或作为法律、法规案例的证据。不准确的审计日志可能妨碍调查，并损害这种证据的可信性。链接到国家原子钟无线电广播时间的时钟可被使用作为日志系统的主时钟。网络时间协议可被使用，保持所有的服务器与主时钟同步。
12.5 运行软件的控制
目标：保证操作系统的完整性
12.5.1
操作系统上软件的安装（新增）
控制措施
控制在操作系统上软件安装的程序应被落实。
实施指南
在操作系统上软件的变更控制应考虑下列指南：
a) 运行软件、应用和程序库的更新仅应由经过训练的管理员在适当的管理授权下来执行（见 9.4.5）；
b) 操作系统仅保留被批准的执行代码，没有开发代码和编译程序；
c) 应用和操作系统软件仅应被执行在广泛的和成功的测试之后；这个测试应涵盖可用性、安全性、对其它系统的影响和用户友好性，并应在独立的系统上执行（见12.1.4）；它应被确保所有的对应的源代码库已被更新；
d) 配置控制系统应被使用以保持所有执行软件和系统文档的控制；
e) 变更实施前应安置一个回退策略；
f) 对运行程序库的所有更新的审计日志应被维护；
g) 应用软件的先前版本应被保留作为应变措施；
h) 软件的老版本应被存档，与所有要求的信息、参数、程序、配置细节和支持软件作为长久数据以存档的方式被保留。操作系统中使用的由厂商提供的软件应以供应商的水平来维护，随着时间的推移，软件厂商将停止老版本软件的支持。组织应用考虑信赖于不被支持的软件的风险。任何对新版本的升级决定，应考虑版本变更和安全的业务要求，如，新的信息安全功能、数量的引入和影响这个版本的信息安全问题的严重性。软件补丁应被应用，当他们可以帮助来消除或降低信息安全弱点的时候（见 12.6 ）.
物理或逻辑访问应仅被给到需要时的供应商的支持目的，并得到管理批准。供应商的活动应被监视（见 15.2.1）。信赖于外部提供的软件和模块的计算机软件，应被监视和控制，以避免可能引入安全弱点的非授权变更。
12.6 技术脆弱性管理
目标：防止技术脆弱性的利用。
12.6.1 技术脆弱性的管理（条款不变）
控制措施
应及时获得信息系统技术脆弱性的信息，评价对这些脆弱性组织的暴露程度，并采取适当的措施来处理相关的风险。
实施指南
当前并完整的资产清单（见 8）是进行有效的技术脆弱性管理的前提。支持技术脆弱性管理所需的特定信息包括软件厂商、版本号、当前部署的状态（如，在什么系统上安装什么软件），以及组织内负责软件的人员。
应采取适当的和及时的行动以响应对潜在技术脆弱性的识别。为建立有效的技术脆弱性管理过程应遵循下面的指南：
a) 组织应定义并建立与技术脆弱性管理相关的角色和职责，包括脆弱性监视、脆弱性风险评估、补丁、资产追踪，和任意需要的协调职任；
b) 识别有关技术脆弱性和维护脆弱性意识的软件和其它技术的信息资源应被识别，对于软件和其他技术（基于资产清单，见 8.1.1）；这些信息资源应根据清单的变更或当发现其它新的或有用的资源时进行更新；
c) 应制定时间表对潜在的有关技术脆弱性的通知做出反映；
d) 一旦潜在的技术脆弱性被确定，组织应识别相关的风险并采取措施；这些措施可能包括对脆弱系统的补丁，或者应用其它控制措施；
e) 依据技术脆弱性需要解决的紧急程度，应根据变更管理相关的控制措施（见12.1.2），或者遵照信息安全事态响应程序（见 16.1.5）采取措施；
f) 如果有来自合法源的可用的补丁，则应评估与安装该补丁相关的风险（由脆弱性引起的风险与安装补丁带来的风险应进行比较）；
g) 在安装补丁之前，应进行测试和评估，以确保它们是有效的，且不会导致不能容忍的负面影响；如果没有可用的补丁，应考虑其它控制措施，如：
1）关闭与脆弱性有关的服务和能力；
2）选配或增加访问控制措施，如，在网络边界上添加防火墙（见 13.1）；
3）增加监视以检测真实的攻击；
4）提高脆弱性意识；
h) 应保持所有执行程序的审计日志；
i) 应定期对技术脆弱性管理过程进行监视和评价，以确保其有效性和效率；
j) 处于高风险中的系统应首先处理；
k) 有效的技术脆弱性管理过程应与事件管理活动结合考虑，脆弱性数据传达给事件响应功能，事件发生时提供技术脆弱性程序来执行；
l) 定义一个程序来处理，脆弱性已被识别，但没有合适的对策的情形。在这种情形中，组织应评估与已知脆弱性相关的风险，并规定合适的检测和纠正行动。
其它信息
技术脆弱性管理可以作为变更管理的一个子功能被评审，并可利用变更管理过程和程序（见 12.1.2 和 14.2.2）。
厂商往往尽早发布补丁要承受重大的压力。因此，补丁可能不足以解决该问题，并且可能存在负作用。而且，在某些情况下，一旦补丁被应用后，很难被卸载。
如果不能对补丁进行充分的测试，如，由于成本或资源缺乏，那么可以根据其它用户的报告经验，考虑推迟打补丁，评价相关的风险。
12.6.2 软件安装限制（原 12.4.1）
控制措施
应建立和执行规则来控制由用户安装软件。
实施指南
组织应定义和执行严格的策略，用户可以安装的软件类型。最小特权原则应被应用。如果准许某个特权，用户可以有能力来安全软件。组织应识别被允许安装软件的类型（如，对现有软件的更新和安全补丁），和禁止安装的软件（如，仅由个人使用的软件和出身于未知和怀疑带潜在恶意代码的软件）。用户所涉及的角色的特权应被准许。
其它信息
在计算机设备上不受控的软件安装可能导致引入脆弱性、产生信息泄漏、丢失完整性或其它信息安全事件，或违反知识产权。
12.7 信息系统审计的考虑
目标：将运行系统上审计活动的影响最小化。
12.7.1 信息系统审计控制（原 15.3.1）
控制措施
涉及对运行系统验证的审计要求和活动，应谨慎地加以规划并取得批准，以便最小化业务过程的中断。
实施指南
应遵守下列指南：
a) 应与合适的管理者商定对系统和数据访问的审计要求；
b) 技术审计测试的范围应商定并被控制；
c) 审计测试应限于对软件和数据的只读访问；
d) 非只读的访问应只允许隔离的系统文件的拷贝，当审核完成时，应被删除，或者在审计文件要求下，具有保留这些文件的义务，则要给予适当的保护；
e) 特定的或附加的过程要求应被识别和同意；
f) 可能影响系统可用性的审计测试应在非业务时间段来完成；
g) 所有访问应被监视和记录，以产生参考踪迹。
