信息安全事件管理程序Word文档下载推荐.docx
《信息安全事件管理程序Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《信息安全事件管理程序Word文档下载推荐.docx（9页珍藏版）》请在冰豆网上搜索。
4.2事件经理负责事件类型的确定，事件过程的管理；
4.3支持团队负责针对事件的方案的实施和解决；
4.4信息科技部总经理负责重大事件的管理，担当重大事件经理的角色。
5程序
5.1事件管理目标
对于事件管理过程，应遵循以下目标：
a）尽快恢复正常服务。
b）最小化事件对业务的影响。
c）确保一致地处理事件和服务请求而不会有任何遗漏。
d）定向到最需要的支持资源。
e）提供允许优化支持流程、减少事件数量和执行管理计划的信息。
5.2事件的分类
5.2.1基于两个方面对事件进行分类:
a）事件所造成的影响
b）事件的紧急程度
5.2.1.1事件的影响等级
等级
说明
事例
高级
事件影响到：
总行或分行
多个支行
单个支行
机房设备损坏
核心系统失效
网络服务中断
中级
事件影响到一组用户或行领导用户
局域网故障
文件服务器故障
打印服务器故障
邮件服务器故障
低级
事件影响到单一用户
PC维护
文件恢复
个人文件夹修复
用户解锁、密码重置
5.2.1.2事件的紧急程度等级
全部或严重影响到全行业务运作的事件
部分影响业务运作的事件
不影响业务运作的事件
5.2.1.3事件的优先级
事件的优先级是根据事件的影响等级和事件的紧急程度来决定的。
影响等级高并且紧急程度高的事件优先级为最高级，影响等级低并且紧急程度低的事件优先级为低级。
下表显示了与这些参数相关事件的分类：
影响>
低
中
高
紧急程度
最高（重大事件）
5.3事件的发现、记录和报告
5.3.1事件的发现
事件通常由用户、IT团队、供应商或监控系统检测到。
对于各类来源所探测到的事件报告，均应由首先接到报告的人员根据事件分类的原则进行判断，属于高等级或最高等级的事件，应立即向信息科技部总经理报告，必要时应继续报告行领导及上级监管机构。
一般事件的处理按照5.4.1要求执行。
5.3.2事件的记录
所有被报告或主动探测到的事件均应被记录。
记录内容应包括：
a）唯一参考号
b）记录日期和时间
c）记录事件的人员的身份
d）报告事件的人员的身份（包括姓名、部门、位置和联系详细信息）
e）联系方法
f）受影响的配置项（CI）的详细信息
g）症状描述和任何错误代码
h）重现该问题所需要的步骤
5.4事件的处理
5.4.1一般事件
一般事件根据引起事件的不同原因，按照各类日常维护工作所涉及到的管理程序执行处理过程。
5.4.2分类和初始支持
5.4.2.1分类
必须对事件分类以便使用适当的解决方案尽可能有效地处理它们。
分类是对给定的事件归类和进行优先级设置的流程，是事件管理中非常重要的第一阶段，因为它确定要采取的后续操作。
网管值班人员应首先根据5.2的分类原则，定义事件的类别。
分配给事件的优先级可用于确定目标解决时间，如下表所示：
优先级代码
描述
目标解决时间
重大事件
---
1
关键
<
1小时
2
4小时
3
24小时
4
48小时
5
计划
预定
5.4.2.2初始支持
初始支持是网管值班人员分配给各系统管理员后，能够令客户满意地解决事件而无需涉及其他任何支持领域的流程。
系统管理员能够根据个人经验或通过规定的培训计划获得的专业经验提供解决方案详细信息。
但是如果这些都不能解决用户的问题时，系统管理员应向主管领导汇报，并通过会议等形式讨论解决方案。
5.4.3调查和诊断
如果初始支持未能解决事件，则它将移交给调查和诊断流程。
相关领导可组成问题解决小组，可能包含广泛的IT团队，包括支持和开发人员、外包提供商、合作伙伴和其他第三方。
必要时可向总经理汇报，确定是否采取重大事件处理机制。
5.4.4重大事件过程
重大事件过程在如下情况下提供附加的跨组织协调、资源、管理参与和沟通：
即这些情况下的事件影响或潜在影响使得超出常规事件管理流程所提供的响应变得必要。
关于事件是否足以调用重大事件过程的决定应由总经理决定。
一旦确定某个事件是重大事件，总经理应指定相关领导立即通知涉及的所有各方人员。
信息科技部总经理负责在重大事件期间协调计划、资源和沟通，并组织“恢复小组”。
总经理应主持一次与恢复小组、已经参与处理事件的任何团队成员、受影响的部门人员和其他任何相关技术专家进行的初始计划会议。
该会议的目标是同时就恢复计划和沟通计划达成一致。
恢复计划的目标是提供用于服务恢复的有计划和协调的方法，对需要采取的操作、由谁执行操作以及在何时完成操作等事项进行文档记录。
在重大事件的整个生命周期中定期更新该计划，确保保留旧版本以用于审核目的。
恢复计划包含以下内容：
●截止目前已知的“问题”的陈述。
●事件的细分，详细描述组件、接口和可能的问题原因。
●关于如何检验或排除每个可能的直接原因的高级计划。
●根据可能性和确认的容易性权衡每个可能的原因，允许向每个可能的原因的调查赋予一个优先级。
●将在此阶段采取的调查或解决操作（基于所分配的优先级）的详细信息。
●关于谁将执行调查或解决操作的详细信息。
●每个操作的执行时间表，以及下一次恢复团队复查会议的时间。
一旦同意了沟通计划和恢复计划，则应该分配任何需要的附加资源。
一旦重大事件过程已在进行中，计划已得到同意，资源已完成分配，就应该遵循调查、诊断、解决、恢复和终结的标准事件生命周期。
恢复小组应该以定期间隔向总经理汇报进度情况。
5.4.5解决和恢复
解决和恢复流程负责确保按照变更和发布管理流程实施任何已确定的变通办法或解决方案，并确保采取任何附加恢复操作。
一旦完成解决操作的执行，相关系统管理员将负责确认解决操作的成功。
如果没有成功，应该检查的第一件事情就是验证是否所有变更都已正确地实施。
如果所有变更请求都已正确地实施，但是事件仍未解决，则应该将事件传回调查和诊断流程。
一旦解决操作已成功实施，则相关管理员应与用户进行确认，确保用户需求得到一致性的解决。
5.4.6安全事件的记录和改进
对于所有事件，相关的系统管理员均应进行分析，如果原因是由于安全问题导致的，则应该向安全管理员报告，由安全管理员决定是否需要采取纠正预防措施。
所有由于安全问题导致的事件均应由安全管理员进行记录，形成《事件事故记录单》，可由事件解决过程规避的安全问题，可由系统管理员进行处理，安全管理员应验证结果。
不可由事件解决过程处理的情况，应下发《纠正/预防措施表》，并跟踪验证。
6记录
《事件事故记录单》
《纠正/预防措施表》
事件事故记录单
编号：
ISMSP-33-R01记录人:
时间：
年月日
地点描述：
事件描述：
报告人：
报告人部门:
联系方式:
事件等级:
□重大□关键（1小时内解决）□高（4小时）□中（24小时）□低（48小时）
处理建议：
科技信息部领导审批：
处理结果：
处理人签字：
处理措施实施是否有效：
□是□否验证人签字：
备注：
注：
处理人员与验证人员不得为相同一个人。
纠正/预防措施表
编号:
ISMSP-07-R01
受审核
区域
审核员
陪同人员
不合格事实描述：
严重程度
严重一般
审核员（签字）：
年月日
受审核区域负责人（签字）：
不合格原因分析：
负责人：
纠正措施及预定完成日期：
制定人（签字）：
纠正措施验证结论：
审核员（签字）：
升级会员 