安全管理体系ISO27001信息安全运维规范.docx
- 文档编号:26441179
- 上传时间:2023-06-19
- 格式:DOCX
- 页数:27
- 大小:188.88KB
安全管理体系ISO27001信息安全运维规范.docx
《安全管理体系ISO27001信息安全运维规范.docx》由会员分享,可在线阅读,更多相关《安全管理体系ISO27001信息安全运维规范.docx(27页珍藏版)》请在冰豆网上搜索。
安全管理体系ISO27001信息安全运维规范
信息安全运维规范
1目的
本规范明确了信息安全工程运维过程应当遵守的工作流程和方法。
用于指导公司运行维护人员完成信息系统运行维护工作,促使运维工作实现标准化、规范化、流程化。
保障运行维护工作按照用户需求完成,保障运维工作质量满足要求,为信息系统安全、平稳、持续运行提供支持。
2范围
本规范将运维阶段分为运行测试和日常维护两个部分,分别规定了运行测试部分对信息系统的有效性判定和日常维护部分所采用的方法、内容和流程。
3引用文件
下列文件中的条款通过本规范的引用而成为本规范的条款。
凡是标注日期的引用文件,其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本规范,然而,根据本规范达成协议的各方研究是否可使用这些文件的最新版本。
凡是不注日期的引用文件,其最新版本适用于本规范。
4术语和定义
信息安全运维服务
信息安全运维服务是指信息安全运维服务供应商或信息安全运维部门综合利用各种信息安全运维支撑工具提供的确保信息安全基础设施和应用系统正常、安全、高效、经济运行及信息安全事件得到有效控制的服务。
本规范中规定的信息安全运维服务包括信息安全基础设施运维服务、信息安全应用系统运维服务、安全管理服务、网络接入服务、内容信息服务以及综合管理服务。
IT运维服务
IT运维服务是指IT运维服务供应商或IT运维部门综合利用各种IT运维支撑工具提供的确保IT基础设施和应用系统正常、安全、高效、经济运行的服务。
运行维护服务交付
服务提供方在服务级别协议有效期内,向服务需求方提供服务级别协议中承诺的运行维护服务。
应急事件
导致或即将导致运行服务对象中断、运行质量降低,以及需要实施重点时段保障的事件。
应急响应
组织委预防、监控、处置和管理应急事件所采取的措施和活动。
5运维组织与职责
系统运行维护工作首先要组织建立运行维护组织架构,确定岗位职责和角色,明确工作内容与有关任务,根据不同角色明确分配工作,确定岗位工作职责。
一般运维工作的组织可分为运维管理、技术支持、运维操作三个组。
主要工作岗位包括管理岗、技术支持岗、操作岗。
管理岗负责与信息系统运维需求方建立顺畅的沟通渠道、准确的将需求方的需求传递到运行维护团队,规划、检查运行维护服务的各个过程,对运行维护服务能力的规划、实施、检查、改进的范围、过程、信息安全和成果负责。
技术支持岗包括在运行维护服务中负责技术支持人员,包括网络、操作系统、数据库、中间件、应用开发、硬件设备、集成、信息安全等方面的专业技术人员。
主要负责对运行维护过程中的请求、事件和问题做出响应,保障信息安全,对处理结果负责。
操作岗包括在运行维护中,负责日常操作实施的人员,根据规范和手册,执行运行维护服务各个过程,对执行结果负责。
根据运维工作内容的不同,应当明确各个岗位人员数量,编制岗位职责说明书,明确从事相关岗位人员在知识、技术、经验方面应满足的要求。
其中,在知识方面应当包括基础知识、专业知识、综合知识三方面的基本要求。
基础知识是指与信息技术相关的基本知识。
专业知识是指从事运行维护服务所必备的知识,应具有较为系统的内容体系和知识范围。
综合知识是指与运行维护服务相关的企业和行业有关知识。
建立岗位备份制度,避免从事某个岗位工作人员出现离职、休假、病假等意外情况,导致有关运维工作不能正常完成情况发生。
6编制原则与方法
本系列规范采用ISO20000系列标准的思想,并参考ITIL框架规定的方法进行编制。
信息安全运维服务管理框架包括信息安全运维服务全生命周期管理方法、管理标准规范、管理模式、管理支撑工具、管理对象以及基于流程的管理方法。
信息安全运维服务管理框架以ITIL/ISO20000为基础,以适应各种管理模式为目标,以管理支撑工具为手段,以流程化、规范化、标准化管理为方法,以全生命周期的PDCA循环为提升途径,体现了对信息安全运维服务全过程的体系化管理。
7安全管理规范
应重视信息系统运行维护中的安全管理工作,建立相应的安全管理体系,并根据情况适时修订安全策略,确保信息系统安全。
维护人员必须确立安全第一的意识。
为确保信息系统维护工作、设备运行、系统数据的安全,运行维护部门应不断加强操作控制、运行控制及操作设备控制。
操作控制包括对操作流程、用户分级、权限分级、操作记录、远程管理、密码管理、防火墙技术、数据备份的安全保证;运行控制包括对告警处理、测试、性能分析;操作设备控制包括防病毒、杀毒软件、非生产应用软件的安全控制。
8运维工作管理规范
8.1设备维护管理
业务平台设备范围:
已经竣工验收并投入运行的设备,包括:
服务器、网络设备、存储设备、安全设备等(具体工作内容可以根据实际情况增加)。
序号
维护项目
周期
1
设备日志及告警信息监测与检查,是否有严重和致命级别告警
日
2
网络连通性及业务功能测试
日
3
设备或系统CPU、内存占用率等性能监测与检查
日
4
磁盘阵列、存储空间检查
日
5
检查、修改设备各级登录口令
季
备注
由于信息系统数量多、重要程度不一,可根据系统重要性进行分级管理,核心、重要业务系统加强巡检项目、巡检次数;非核心、业务很少的平台可减少巡检项目、巡检次数。
设备维护要求:
1.监控设备运行状况,保证平台正常运行;
2.发现故障后应及时处理,无法排除的故障应报主管部门;
3.完成相关运维记录。
8.2网络维护管理
网络维护范围:
业务平台内的所有网络及设备,如路由器、防火墙、交换机、负载设备、安全防护设备等及组成的网络(具体工作内容可以根据实际情况增加)。
序号
维护项目
周期
1
网络连通性监测与检查
日
2
网络端口状态监测与检查
日
3
网络流量监测与检查
日
4
网络设备CPU、内存占用率等性能监测与检查
日
5
网络设备配置文件备份,遇到网络重大调整及时备份
季
6
网络设备密码修改
季
7
双机切换测试
年
备注
由于信息系统数量多、重要程度不一,可根据系统重要性进行分级管理,核心、重要业务系统加强巡检项目、巡检次数;非核心、业务很少的平台可减少巡检项目、巡检次数。
网络维护要求:
1.监控网络运行状况,保证平台正常运行;
2.发现故障后应及时处理,无法排除的故障应报主管部门;
3.设专人负责信息系统IP地址的规划及管理。
4.绘制网络拓扑图,并及时更新。
5.管理网络设备软件版本,需要时按相关流程制定、实施软件版本升级计划,并做好记录。
6.对远程网络接入进行管理,外部人员接入设备必须经过严格审批,并做好记录,保证系统的安全性。
7.完成相关运维记录。
8.3软件维护管理
业务平台软件范围:
操作系统、数据库、中间件、应用软件、网管软件、安全软件等(具体工作内容可以根据实际情况增加)。
序号
维护作业项目
周期
1
重要进程及数据库存活性、健康性监测与检查
日
2
日志检查
日
3
文件系统检查
日
4
数据库空间检查
日
5
安全参数配置检查
月
6
数据备份及检查
周
7
软件及配置文件备份
季
8
修改密码,账号权限审核
季
9
系统病毒库升级,补丁更新
周
10
双机、集群检查
日
11
双机切换测试
年
12
数据备份恢复检查
年
备注
由于信息系统数量多、重要程度不一,可根据系统重要性进行分级管理,核心、重要业务系统加强巡检项目、巡检次数;非核心、业务很少的平台可减少巡检项目、巡检次数。
软件维护要求
1、所有设备在作配置修改前,必须对可能受到影响的系统软件、数据库、配置文件进行完整的备份,并做完整性、一致性检查;
2、设备配置文件的备份必须多于一份,且保存在不同的存储介质上;
3、对软件版本进行严格管理,需进行周期性审计和分析的工作,并提出更新、升级建议。
9运维服务管理规范
9.1事件管理
为确保信息系统尽快恢复正常工作状态而设计的流程。
强调快速响应、快速恢复、使事件对业务的影响降低至最小化。
事件管理流程的主要目标是尽快恢复IT服务提供并减少其对业务的不利影响,尽可能保证最好的IT服务质量和可用性等级。
事件管理流程通常涉及事件的识别、记录、事件优先级的判定、处理及关闭。
事件管理流程图如下所示:
9.1.1角色说明
事件管理角色分为事件管理负责人与事件支持组。
9.1.2事件识别
事件识别用于对事件或潜在事件进行实时监控,尽可能在对业务造成影响之前将其识别,将影响减少至最低。
此流程是监控管理与事件管理流程之间的衔接。
应对所有接收到的事件和服务请求进行详细记录,确保无任何遗漏。
事件记录应包括唯一编号、事件描述、事件分类、事件紧迫度、事件影响度、记录日期和时间、系统错误信息和错误代码等信息。
9.1.3确定优先级
优先级确定:
事件分类完成后,事件支持组应对事件进行优先级分配,确定处理事件的先后顺序。
事件的优先级可分为一级、二级、三级三个级别:
一级:
影响到大部分用户工作的事件,例如系统崩溃、网络瘫痪和全局性安全问题;影响到部分要害部门用户,例如严重影响财务部门进行账务处理的问题;
二级:
影响到部分用户工作的事件,如发生在部分用户的系统遭遇非法入侵和病毒攻击等情形;
三级:
影响到个别用户工作的事件,如个人计算机硬件事件。
重大事件应依据高影响度和高紧迫性进行综合判定。
事件支持组在认为必要时通知事件管理负责人,由事件管理负责人确认是否将事件定义为重大事件后,依照重大事件的流程进行处理。
9.1.4常规事件处理与分析
对于具有经常性、复发性的事件,可定义标准的事件处理记录。
事件处理记录将事件解决流程中的步骤进行提前定义,当相应的事件发生时依照记录进行处理。
如果常规事件未能通过事件处理记录解决,则需要启动事件调查分析流程,事件的调查和分析包括以下活动:
a)完整记录所收集的信息;
b)明确相关事件的先后顺序;
c)确认事件的总体影响,包括影响数量和影响范围;
d)确认事件源;
解决方案应进行充分测试才能实施,如需进行变更,则打提报监控管理负责人统一调度变更请求的执行。
解决方案实施成功后,应及时更新相关事件信息,调整事件状态并将记录反馈给配置管理。
9.1.5事件升级
事件支持组成员应及时响应和处理分配到自身的事件,在规定的时间内不能解决时,对问题进行升级处理,由事件管理负责人协调资源,并督促事件能够及时被响应和处理。
对于重大事件,事件支持组应立即报告到事件管理负责人人,由事件管理负责人启动重大事件处理流程。
9.1.6重大事件处理
重大事件处理流程应在事件管理负责人直接领导或协调下,成立独立的重大事件处理团队,专门解决某一事件。
如果在处理事件的同时需要调查事件的原因,则问题管理负责人和监控管理负责人应参与其中。
事件管理负责人确保事件恢复。
问题管理负责人开展问题原因的调查工作。
监控管理负责人负责支持各项工作的开展,提供必要的信息和人力资源的协调。
9.2问题管理
问题管理流程的主要目标是预防问题和事故的再次发生,并将未能解决的事件的影响降低到最小。
问题管理流程包括诊断事件根本原因和确定问题解决方案所需要的活动,通过合适的控制过程,尤其是变更管理和发布管理,负责确保解决方案的实施。
问题管理还将维护有关问题、应急方案和解决方案的信息。
问题管理流程如下图所示:
9.2.1角色说明
问题管理角色分为问题管理负责人与问题支持组。
9.2.2问题识别
问题支持组应定期通过件监控管理、事件管理、配置管理等管理流程,或用户使用问题报障等其他渠道接收到问题后,对其进行评估,确定是否纳入问题管理范围。
同时问题支持组应随时主动分析配置管理数据库发现潜在问题。
9.2.3问题记录
发现系统问题后,问题支持组应对问题的详细情况进行记录。
一般记录内容包括:
问题报告者及联系信息、与问题相关的时间数量及信息、问题处理的日期和事件记录、问题的详细情况描述、问题的类别、优先级、历史处理记录、处理状态、应急方案。
9.2.4问题分类
问题支持组应根据问题发生的关联领域对问题进行初步分类,一般可以分为以下几个类别:
IT服务、信息系统、中间设备、操作系统、硬件、局域网、基础设施、网络出口、其他等。
9.2.5问题调查
问题支持组应查阅与问题相关的各类文档记录,访问配置管理数据库,获取诊断问题所需的证据。
一般调查过程需要收集的证据信息包括:
所有受到影响或可能会受到影响的基础设施、曾经发生过的类似事件的记录、由其他流程提供与问题相关的文档资料、受影响的用户信息、事件支持组采取恢复服务或解决事件的所有方法与步骤。
9.2.6问题分析
在结束调查工作后,问题支持组应对所涉及的问题进行深入地分析,力求在短时间内找出问题发生的根本原因,提供应急解决方案以恢复服务。
问题支持组在查找产生问题的根本原因时应遵循以下步骤:
明确指出信息系统服务受到的影响、对问题进行详细描述、依据问题描述中的比较和实施的变更发现问题可能产生的原因、评价问题描述中的比较和实施的变更发现问题可能产生的原因、评价每个可能原因以确认形成问题症状的原因。
9.3配置管理
对信息系统运维管理过程中配置资源进行识别和定义,在信息系统整个生命周期内控制配置项的状态及配置项之间的相互关系等信息,记录并报告配置变更的要求,验证配置项的完整性和正确性。
确保配置管理数据库能够准确地反映现存配置项的实际版本状况。
一般包括制定配置管理规划(规划)、配置项识别(识别)、配置项控(控制)、配置项状态监控(状态监控)、配置项验证与审核(审核)五项活动。
配置流程图如下:
9.3.1角色说明
配置管理负责人:
信息系统配置管理流程中负责定义配置管理数据库的管理流程,挑选和培训配置管理小组的成员并进行职责分配的人员。
配置管理小组:
主要由信息系统参与配置管理流程的所有人员组成,每位成员负责信息技术环境某一特定领域的配置管理活动。
9.3.2制定配置管理规划
配置管理规划活动主要包括以下几项:
制定战略、策略和目标,认命配置管理负责人和组建配置管理小组,分析现有的有用信息,制定配置管理规划,制定详细的事实计划。
1)制定战略、策略和目标
在所有配置活动发生之前,信息系统应与配置管理服务提供方就配置管理的目标、具体策略达成一致。
信息系统配置管理战略与策略将以总体战略作为指导,保证信息系统的正常运行,实现保障业务持续,促进业务发展的最终目标。
配置管理战略与策略应包含以下几个内容:
a)配置管理所控制基础架构的级别;
b)配置管理的某些重要规则,如命名和编号规则;
c)有关配置的具体定义,以及签发有关紧急修正的策略;
d)确定配置管理的指导性原则;
e)配置管理的输出成果,如配置管理报告、配置记录等;
f)配置管理的职责;
g)有关配置管理控制流程的描述(如评审会、进度评估、配置项标识、影响分析等);
h)最终软件库中配置的记录,以及新增软件验收标准的定义。
2)人名配置管理负责人和组建配置管理小组
根据配置管理的目标和粗略,信息系统运维组织人名配置管理负责人,然后由配置管理负责人负责组建配置管理小组。
3)分析有用信息
配置管理负责人分析当前已有的配置管理的规定和程序,确定这些规定和程序的归属,并调查和分析现有的有用信息。
调查和分析的有用信息的工作主要包括:
a)信息系统上线时交付的相关配置信息。
b)配置项的负责人
c)配置管理范围
d)变更管理和配置管理运营程序的规程
e)保存于文档、电子表格和数据库中的配置管理方面的数据
f)配置管理人员的任务、责任和能力。
4)制定配置管理规划
分析有用信息之后,配置管理负责人组织配置管理小组开始制定配置管理规划。
完整的配置管理规划应包括以下内容:
a)配置管理的目标和范围
b)配置管理的相关策略、标准和流程
c)配置管理的角色和职责
d)配置项命名规则
e)实施配置管理活动的进度和程序
f)与其他流程(如变更管理)的接口控制
g)配置挂历的系统设计
h)为配置管理的每一阶段确定的配置基准线、重大发布、里程碑、工作量和资源计划
i)其他工作,如许可证管理、配置项存档和保管的期限等
5)制定详细的实施计划
制定配置管理规划之后,应根据上一步完成的配置管理规划来制定详细的配置管理实施计划,以便于配置管理的具体实施。
9.3.3配置项识别
配置项识别的工作应包括确定配置项的范围、配置项的结构、配置项关系、深度、命名规范、属性、标识符以及配置基准线。
1)范围
配置管理活动对信息系统基础架构的有效管理是通过将其分解为单个配置项,并对配置项分配唯一标识和编号来实现。
配置管理的范围包括用于构建、发布、验证、安装、分发、维护、恢复和移除的硬件配置项、软件配置项及相关文档配置项。
配置管理最初始来源于信息系统上线提交的资料,至少包括以下方面:
需要识别的硬件配置项包括:
服务器(群)、存储设备、应用层交换设备、网络、终端、外设。
需要识别的软件配置项包括:
信息系统、系统软件等。
需要识别的文档配置项包括:
用户状态、数据、其他相关文档(如规程、操作手册、技术规范、组织结构图、许可证)等。
配置项相关文档可以存放于不同地点,它们的版本号、发布日期、作者、存放地点等其他相关信息应保存于配置管理数据库,以便于其进行控制。
2)配置项结构
a)概述
配置管理小组确定配置项结构是为了完整地识别和记录各配置项之间的关系。
b)内容
配置项结构说明了配置项的各种层次结构中的相对定位以及各配置项之间的关系。
3)配置项关系
配置管理小组需要识别的配置项之间的关系通常可以分为两大类,即物理关系和逻辑关系。
需要识别的物理关系一般包括:
a)父子关系:
配置项之间数据衍生或者包含的关系,例如个人PC机中的软盘或硬盘,程序中的某个软件模块、代码片段等;
b)关联关系:
配置项之间是相互连接、关联的关系,例如PC与LAN连接;
c)依赖关系:
一个配置项需要运行另外一个配置项才能实现其功能,例如网络硬件需要运行应用软件来实现其功能。
需要识别的逻辑关系一般包括:
a)聚合关系:
配置项之间是聚合关系,例如标准模型、基线或者程序的拷贝
b)使用关系:
配置项之间是一个配置项使用另外一个配置项的关系,例如配置项需要提供服务,或者软件模块被许多程序使用。
c)种类(相关)关系:
配置项之间是种类关系,例如程序、手册或者文档等。
4)深度
配置项是分层次的,各个不同层次的配置项构成相互关联的树状网络。
每个配置项从完成的系统,包括所有的硬件、软件与文档,到某个单个模块或者小的硬件组件,它在复杂性、规模和类型上都存在着很大的差别。
在识别配置项的过程中,配置管理小组对应所有配置项的深度进行识别。
5)命名规范
在识别配置项的过程中,配置管理小组应建立所有的配置项和控制形式。
配置管理小组制定配置项命名规范时应考虑以下性质:
延续性(尽量保持原有的命名)、易记性(名称简短有意义)、可扩展性(留出一定的空间以备将来使用)
配置管理小组建立的配置项命名规范可以应用于配置项标识、配置文档、变更和配置基准线等;也可以用于为配置项的物理标签保证在审计、维护和事件记录时能迅速准确地识别。
6)属性
配置管理小组应预先定义和确定各配置项,特别是高风险或关键性配置项的属性。
属性是用于存在存储与配置项类型相关的信息,表1中所列的属性可能会用到。
7)标示符
配置管理小组应赋予每个配置项一个唯一的标示符,并制定计划对配置项进行标准和维护这些标注的准确性。
配置管理小组需要识别的标示符包括硬件配置项、软件配置项与文档配置项。
8)配置基准线
配置管理小组需要对配置基准线进行识别和确认
配置基准线是对某个特定时点上一组配置项的描述,内容应至少包括以下五项:
a)以前的、当前的和计划中的发布信息
b)以前的当前的和计划中的变更信息
c)批准和实施变更时系统的状态和有关文档
d)实施发布时系统的状态和有关文档
e)按标准规范配置的硬件和软件。
9.3.4配置项控制
配置管理小组在正式建立配置文档后,应对配置项变更进行控制,配置项控制包括对变更的评价、协调、批准或否决等活动。
目的是确保配置管理数据库中只记录那些得到授权和确认的配置项,同事确保配置项的增加、修改、替换或删除是根据相关的控制文档(最新的变更请求RFC)
配置管理小组需进行以下配置项控制活动:
a)注册新配置项及其版本
b)更新配置项记录
c)许可证管理
d)撤销或删除配置项时保存有关记录。
e)保护各种配置的完整性
f)定期检查配置项以确保它的存在性和合规性,并相应更新配置管理数据库。
9.3.5配置项状态监控
1)概述
配置项状态监控可以来建立系统配置基准线,以及配置基准线和版本之间的变动情况。
配置管理小组应监控并定期报告所有受控配置项当前状态及其变更轨迹。
信息系统运维管理人员可随时登陆配置管理数据库进行实时查询,并依据配置管理计划定期发布配置状态报告。
2)内容
配置状态报告内容可以包括:
a)配置基准线和发布标示符
b)系统使用的软件的最新版本
c)系统变更次数
d)配置基准线和发布版本的数量
e)配置项的使用情况
f)对配置基准线和发布版本的比较结果。
9.3.6配置项验证与审核
1)概述
配置管理小组审计、检验配置管理数据库,以确认已记录配置项的存在性和验证记录的准确性。
核实配置管理数据库中记录的信息是否仍然反映了当前的现实状况。
2)内容
配置管理小组在进行配置项验证与审核时应设计一下内容:
a)新配置项的命名是否遵循了命名规范。
b)定期评审配置管理数据库,检查是否与实际配置项状态相一致
c)进行物理配置审计,检查已在软件配置管理中维护的配置项和应在软件配置管理中维护的配置项是否存在差异。
d)进行功能配置审计,检查各配置项是否一致,变更请求是否按要求完成
e)发布审计报告,以基线报告为基础,标识审计结果,并记录审计人,说明审计中发现的问题,提出纠正措施。
f)对在配置审计中发现的问题进行修正。
g)移除或者按照政事程序注册错误的或未授权的配置项
h)分析产生错误或未授权的配置项的原因,并采取纠正措施或提出改进意见和建议。
i)确认配置管理中的变更记录和发布记录
3)时机
配置验证和审核的时机根据需要一般有以下几种情况:
a)实施配置管理数据库
b)重大变更前后
c)灾难恢复后
d)发现未授权的配置项后
e)临时需要审核
9.4变更管理
变更管理实现所有IT基础设施和应用系统的变更,变更管理应记录并对所有要求的变更进行分类,应评估变更请求的风险、影响和业务收益。
其主要目标是以对服务最小的干扰实现有益的变更。
对变更进行审批和控制,通过对变更进行评估,确保在对信息系统运维产生最小负面影响的情况下实施变更,同时通过在组织内进行有效的沟通和协商,确保所有的变更都经过授权,并具有可追溯性。
一般变更管理流程如下所示:
9.4.1角色说明
在变更管理流程中,变更管理负责人负责对变更请求进行筛选和归类,以及在变更实施过程中负责筹划与协调工作。
变更管理负责人的职责包括:
制定变更管理策略、批准、发布变更管理计划、接受并审阅变更顾问文员会报告、筛选、接收并变更请求进行分类、获取所需的授权、计划并协调变更的组织和实施。
9.4.2变更基本要求
在信息系统变更管理中,一般应满足一下别本要求和策略。
严禁XX的变更;与其他信息系统运维管理流程进行结合,保证变更的可追溯性;对变更进行优先级管理;基于业务、项目和相关方面定义的变更管理流程,部署变更管理流程及相关服务;在整个服务生命周期中将变更职责明确,实行职责分离;明确变更主要关注点,将变更冲突最小化,对业务
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 安全管理 体系 ISO27001 信息 安全 规范