ISMS信息通信和操作管理
操作程序和责任
目标：确保对信息处理设备正确和安全的操作。
应该建立所有信息处理设备管理和操作的责任和程序。包括制订适当的操作指南
和事故反应程序。
适当情况下应实施责任划分，以降低疏忽或故意滥用系统的风险。
1. 文件化操作程序
被安全方针确定的操作程序应该文件化并保持。应将操作程序作为正式文件对待，经管理层授权后可修改。
程序应该规定每项工作详细的执行指导，包括：
信息的加工和处理；
日程要求，包括和其他系统的依存关系，最早的工作开始时间和最晚的工作完成时间；
对在工作执行过程中出现的错误或其他意外情况的处理指导，包括对系统功能使用的限制；
在发生意外的操作或技术困难时的支持联络；
特殊输出处理指导，诸如特殊文具的使用或保密输出的管理，包括失败作业输出的安全处理程序；
在系统失效时使用的系统重启和恢复程序；
与信息处理和通信设备有关的系统日常管理活动也应准备文件化的程序。如计算机启动和关机程序、备份、设备维护、计算机房和信件处理的管理和安全。
2. 操作的变更控制
应该控制信息处理设备和系统的改变。对信息处理设备和系统变化的控制不够是系统或安全故障的通常原因。应该制订正式的管理责任和程序以确保满足对设备、软件或程序的所有改变的控制。对操作程序应该进行严格的变更控制。在程序变更时，应该保留包括所有相关信息的审计日志。操作环境的变化能够影响到应用程序。可行的情况下，应把操作和应用的变更控制程序整合起来。特别应考虑以下控制措施：
重大变更的识别和记录；
评估此类变更的潜在影响；
所建议更改的正式审批程序；
变更细节通知给所有相关人员；
确定中止和恢复不成功变更的责任的程序。
3. 事故管理流程
应建立事故管理责任和流程来确保对安全事故快速、有效和有序的响应（见6.3.1）。应考虑以下的控制措施：
针对所有潜在的安全事故类型，建立响应程序，包括：
信息系统故障和丧失服务；
拒绝服务；
不完整或不准确的商业数据导致的错误；
保密性的破坏；
除正常的应急计划（为尽快的恢复系统或服务而设计），程序还应包括（见6.3.4）：
分析和识别事故原因；
如有必要，设计和实施补救措施以防止事故的重发；
收集审计记录和类似证据；
与受到事故影响的人，或恢复工作涉及到的人沟通；
向有关当局汇报情况。
如果适当，应该收集和安全的保管审计记录和相似的证据，以用于：
内部问题分析；
为可能的违反合同、违反法规要求或引起的民事或刑事诉讼（如由于滥用计算机或违反数据保护法）作为相关证据；
与软件和服务提供商商谈赔偿问题。
对安全破坏的恢复工作以及系统故障的纠正工作，应进行谨慎和正式的控制。此程序应确保：
仅允许经明确识别和授权的员工访问运行中的系统和数据；
详细记录所采取的所有紧急行动；
应急行动应报告给管理层，并以有序的方式评审；
对控制措施和商业系统完整性的确认应尽量避免延迟。
4. 职责分开
职责分开是降低意外或故意滥用系统的风险的一种方法。为减小未经授权的修改或滥用信息或服务的机会，应考虑分开管理或执行特定职责或责任领域。
小型组织可能发现这种控制方法难以做到，但是只要可能并可行，该原则应该被应用。如划分工作比较困难，应考虑其他的控制措施，如行动监视、审计跟踪和管理监督。保持安全审计的独立性很重要。
应该注意不能有人在独立责任领域实施诈骗而不被发现。事件的提出和批准应该分开。应考虑如下的控制措施：
活动分开很重要，此时需要相互勾结才能进行欺诈，如提高订单价格，和核对所收到的货物。
如有相互勾结的危险，则需设计控制措施以包括两个或更多的人，由此降低合谋的可能性。
5. 开发和操作设备的隔离
隔离开发、测试和操作设备对实现分离所涉及的任务是重要的。应该制订并文件化软件从开发转入操作状态的规则。
开发和测试行为会引起严重的问题，如文件或系统环境的不希望有的修改或系统故障。应考虑为防止操作问题在操作与测试和开发环境之间所必要的分离级别。在开发和测试功能之间也应实施类似的隔离。在这种情况下，有必要保持一个已知的并稳定的环境，在此环境中执行有