信息系统安全漏洞评估及管理制度.docx

上传人:b****2 文档编号:17735801 上传时间:2023-04-24 格式:DOCX 页数:10 大小:19.74KB
下载 相关 举报
信息系统安全漏洞评估及管理制度.docx_第1页
第1页 / 共10页
信息系统安全漏洞评估及管理制度.docx_第2页
第2页 / 共10页
信息系统安全漏洞评估及管理制度.docx_第3页
第3页 / 共10页
信息系统安全漏洞评估及管理制度.docx_第4页
第4页 / 共10页
信息系统安全漏洞评估及管理制度.docx_第5页
第5页 / 共10页
点击查看更多>>
下载资源
资源描述

信息系统安全漏洞评估及管理制度.docx

《信息系统安全漏洞评估及管理制度.docx》由会员分享,可在线阅读,更多相关《信息系统安全漏洞评估及管理制度.docx(10页珍藏版)》请在冰豆网上搜索。

信息系统安全漏洞评估及管理制度.docx

信息系统安全漏洞评估及管理制度

四川长虹电器股份有限公司

 

虹微公司管理文件

 

信息系统安全漏洞评估及管理制度

XXXX-XX实施X

XXXX-XX发布X

四川长虹虹微公司发布

1概况错误!

未指定书签。

目的错误!

未指定书签。

目的错误!

未指定书签。

2正文错误!

未指定书签。

.术语定义错误!

未指定书签。

.职责分工错误!

未指定书签。

.安全漏洞生命周期错误!

未指定书签

•信息安全漏洞管理错误!

未指定书签

原则错误•!

未指定书签

风险等级错误」未指定书签

评估范围错误」未指定书签

整改时效性错误.!

未指定书签

实施错.误.!

未指定书签

3例外处理错误!

未指定书签

4检查计划错误!

未指定书签

5解释错误!

未指定书签。

6附录错误!

未指定书签。

概况

1.1目的

1、规范集团内部信息系统安全漏洞(包括操作系统、网络设备和应用系统)的评估及管

理,降低信息系统安全风险;

2、明确信息系统安全漏洞评估和整改各方职责。

1.2适用范围

本制度适用于虹微公司管理的所有信息系统,非虹微公司管理的信息系统可参照执行。

正文

2.1.术语定义

2.1.1.信息安全Informationsecurity

保护、维持信息的保密性、完整性和可用性,也可包括真实性、可核查性、抗抵赖性、

可靠性等性质。

2.1.2.信息安全漏洞Informationsecurityvulnerability

信息系统在需求、设计、实现、配置、运行等过程中,有意或无意产生的缺陷,这些缺陷以不同形式存在于计算机信息系统的各个层次和环节之中,一旦被恶意主体利用,就会对信息系统的安全造成损害,影响信息系统的正常运行。

2.1.3.资产Asset

安全策略中,需要保护的对象,包括信息、数据和资源等等。

2.1.4.风险Risk

资产的脆弱性利用给定的威胁,对信息系统造成损害的潜在可能。

风险的危害可通过事件发生的概率和造成的影响进行度量。

2.1.5.信息系统(Informationsystem)

由计算机硬件、网络和通讯设备、计算机软件、信息资源、信息用户和规章制度组成的以处理信息流为目的的人机一体化系统,本制度信息系统主要包括操作系统、网络设备以及应用系统等。

2.2.职责分工

2.2.1.安全服务部:

负责信息系统安全漏洞的评估和管理,漏洞修复的验证工作,并为发现的漏洞提供解决建议。

2.2.2.各研发部门

研发部门负责修复应用系统存在的安全漏洞,并根据本制度的要求提供应用系统的测试环境信息和源代码给安全服务部进行安全评估。

2.2.3.数据服务部

数据服务部负责修复生产环境和测试环境操作系统、网络设备存在的安全漏洞,并根据本制度的要求提供最新最全的操作系统和网络设备的IP地址信息。

2.3.安全漏洞生命周期

依据信息安全漏洞从产生到消亡的整个过程,信息安全漏洞的生命周期可分为以下几个阶段:

a)漏洞的发现:

通过人工或自动的方法分析、挖掘出漏洞的过程,且该漏洞可被验证和重现。

b)漏洞的利用:

利用漏洞对信息系统的保密性、完整性和可用性造成破坏的过程。

c)漏洞的修复:

通过补丁、升级版本或配置策略等方法对漏洞进行修补的过程,使该漏洞不能被利用。

d)漏洞的公开:

通过公开渠道(如网站、邮件列表等)公布漏洞信息的过程。

2.4.信息安全漏洞管理

2.4.1原则

信息安全漏洞管理遵循以下:

a)分级原则:

应根据对业务影响程度,对安全漏洞进行分级;同时对不同级别的安全漏洞执行不同的处理要求;

b)及时性原则:

安全服务部应及时把发现的漏洞发布给相关的负责人;各部门在对安全漏洞进行整改时,及时出具整改方案,及时进行研发或更新补丁和加固,及时消除漏洞与隐患;

c)安全风险最小化原则:

在处理漏洞信息时应以信息系统的风险最小化为原则;

d)保密性原则:

对于未修复前的安全漏洞,必须严格控制评估报告发放范围,对评估报告中敏感的信息进行屏蔽。

2.4.2风险等级

充分考虑漏洞的利用难易程度以及对业务的影响情况,采取DREAD模型对安全漏洞进行风险等级划分。

在量化风险的过程中,对每个威胁进行评分,并按照如下的公司计算风险值:

Risk=D+R+E+A+D

DREAD模型

"类等级

咼(3)

中⑵

低⑴

DamagePotential

潜在危害

获取完全权限;执行管

理员操作;非法上传文

件等等

泄露敏感信息

泄露其他

信息

Reproducibility

重复利用可能性

攻击者可以随意再次攻

攻击者可以重复攻击,

但有时间或其他条件

限制

攻击者很

难重复攻

击过程

Exploitability

利用的困难程度

初学者在短期内能掌握

攻击方法

熟练的攻击者才能完

成这次攻击

漏洞利用

条件非常

苛刻

Affectedusers

影响的用户范围

所有用户,默认配置,

关键用户

部分用户,非默认配置

极少数用

户,匿名用

Discoverability

发现的难易程度

漏洞很显眼,攻击条件

很容易获得

在私有区域,部分人能看到,需要深入挖掘漏洞

发现该漏

洞极其困

说明:

每一项都有3个等级,对应着权重,从而形成了一个矩阵。

表一:

安全漏洞等级评估模型

最后得出安全漏洞风险等级:

计算得分

安全漏洞风险等级

5-7分

低风险

8-11分

中风险

12-15分

咼风险

表二:

风险等级对应分数

243评估范围

1)安全服务部应定期对信息系统进行例行的安全漏洞评估,操作系统层面的评估主要以自动化工具为主,应用系统层面评估以自动化工具和手动测试相结合。

2)操作系统层面评估的范围为所有生产系统的服务器;网络层面评估的范围为公司内部

网络所有的路由器、交换机、防火墙等网络设备;应用系统层面评估的范围为所有生产环境的应用系统,包括对互联网开发的应用系统以及内网的应用系统。

3)操作系统层面安全漏洞评估的周期为每季度一次,并出具漏洞评估报告。

4)应用系统层面的安全评估,新系统在第一个版本上线前,必须经过安全测试和源代码安全扫描。

5)应用系统层面的安全评估,对于原有系统进行版本更新的,按照下面的规则进行评估:

1如果本次版本中涉及信息安全漏洞整改的,在上线前必须经过安全测试;

2如果本次版本中没有涉及信息安全漏洞整改的依据下面的规则进行安全测试:

a、应用系统安全级别为高级别的,每间隔3个版本进行一次安全测试,比如在版本进行了安全测试,那下次测试在版本需要进行安全测试;

b、应用系统安全级别为中级或低级别的,每间隔5个版本进行一次安全测试,比如在版本进行了安全测试,那下次测试在版本需要进行安全测试;

c、如果需要进行测试的版本为紧急版本,可以延后到下一个正常版本进行安全测试。

6)安全服务部应定期跟进安全漏洞的修复情况,并对已修复的安全漏洞进行验证。

7)信息系统安全评估报告中应包括信息系统安全水平、漏洞风险等级的分布情况、漏洞的详细信息、漏洞的解决建议等。

244整改时效性

依据信息系统部署的不同方式和级别,以及发现的安全漏洞不同级别,整改时效性有一

定的差异。

2.4.4.1应用系统安全漏洞整改时效性要求

依据DREAD模型,和应用系统的不同级别,应用系统安全漏洞处理时效要求如下表,低

风险安全漏洞不做强制性要求。

应用系统安全级别

整改的时效性

高风险漏洞

中风险安全漏洞

高级

5个工作日

10个工作日

中级

10个工作日

10个工作日

低级

1个月内

1个月内

表三:

应用系统安全漏洞整改时效性要求

2.442操作系统安全漏洞整改时效性要求

依据操作系统所处网络区域的不同,操作系统的安全漏洞处理时效要求如下表,低风险安全漏洞不做强制性要求。

所处网络区域

整改的时效性

高风险漏洞

中风险漏洞

对外提供服务区域

Window操作系统3个月内

Linux&unix操作系统6个月内

对于影响特别严重,易受攻击的漏洞,根据公司安全组的通告立即整改完成

Window操作系统3个月内Linux&unix操作系统6个月内

对内提供服务区域

Window操作系统6个月内

Linux&unix操作系统12个月内

对于影响特别严重,易受攻击的漏洞,根据公司安全组的通告立即整改完成

Window操作系统6个月内Linux&unix操作系统

12个月内

表四:

操作系统安全漏洞整改时效性要求

245实施

根据安全漏洞生命周期中漏洞所处的不同状态,将漏洞管理行为对应为预防、发现、消

减、发布和跟踪等阶段。

1)漏洞的预防

针对集团内部自行开发的Web应用系统,应采用安全开发生命周期流程

(SDL-IT),在需求、设计、编码、测试、上线等阶段关注信息安全,提高应用系统的安全水平。

数据服务部应依据已发布的安全配置标准,对计算机操作系统进行安全加固、及时安装补丁、关闭不必要的服务、安装安全防护产品等操作。

2)漏洞的发现

安全服务部应根据本制度的要求对公司的应用系统、操作系统和网络设备进行安全测试,及时发现信息系统存在的安全漏洞;

安全服务部同时还应建立和维护公开的漏洞收集渠道,漏洞的来源应同时包括集团内部、厂商及第三方安全组织;

安全服务部应在规定时间内验证自行发现或收集到的漏洞是否真实存在,并依据DREAD模型,确定漏洞的风险等级,并出具相应的解决建议。

3)漏洞的发布

安全服务部依据及时性原则,把发现的安全漏洞通知到相关的负责人;

漏洞的发布应遵循保密性原则,在漏洞未整改完成前,仅发送给信息系统涉及的研发小组或管理小组,对敏感信息进行屏蔽。

4)漏洞的消减

安全漏洞所涉及的各部门应遵循及时处理原则,根据本制度的要求在规定时间内修复发现的安全漏洞;

数据服务部在安装厂商发布的操作系统及应用软件补丁时,应保证补丁的有效性和安全性,并在安装之前进行测试,避免因更新补丁而对产品或系统带来影响或新的安全风险;

在无法安装补丁或更新版本的情况下,各部门应共同协商安全漏洞的解决措施。

5)漏洞的跟踪

安全服务部应建立漏洞跟踪机制,对曾经出现的漏洞进行归档,并定期统计漏洞的修补情况,以便确切的找出信息系统的短板,为安全策略的制定提供依据。

安全服务部应定期对安全漏洞的管理情况、安全漏洞解决措施和实施效果进行检查和审计,包括:

1预防措施是否落实到位,漏洞是否得到有效预防;

2已发现的漏洞是否得到有效处置;

3漏洞处理过程是否符合及时处理和安全风险最小化等原则。

例外处理

如因特殊原因,不能按照规定的时效性要求完成漏洞修复的,可申请延期,申请延期必须经过研发总监或数据服务部部长和安全服务部部长审批。

如因特殊原因,不能进行修复的,必须申请例外,按风险接受处理,申请例外必须经过研发总监或数据服务部总监和安全服务部总监审批。

检查计划

安全服务部每年组织1次对信息系统安全漏洞的评估和管理工作进行检查。

解释

本流程制度由安全服务部负责解释

附录

精心搜集整理,因文档各种差异性,请按实际需求再行修改编辑调整字体属性及大小

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 解决方案 > 营销活动策划

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1