安全漏洞管理制度

1、文件名称版本号文件编号机密等级发布日期生效日期拟制日期审核日期批准日期XXXX安全漏洞管理制度创建/变更人变化状态变更摘要（章节/内容）版本创建/变更时间批准人文件修订履历变化状态：新建，增加，修改,删除目录1引言51.1目的51.2对象51。3范围52漏洞获知53级别定义和处理时间要求53。1级别定义53。1.1高风险漏洞定义53.1。2中风险漏洞定义53。1。3漏洞处理原则64职责分工64。1信息安全部64。2 IT中心64。3各产品开发部门65漏洞处理流程76罚则81引言1。1目的本制度规范了XXXX(以下简称：XXXX)信息系统安全漏洞的发现、评估及处理过程.保障尽早发现安全漏洞,及时

2、消除安全隐患。加快安全处理响应时间,加强信息资产安全。1.2对象本制度阅读对象为单位所有的运维人员、产品开发人员、测试和质量保障人员等.各产品开发、运营、系统运维、质量测试等部门负责人应通读并认真执行本制度中与其职责相关的要求。1.3范围本制度中的信息系统描述适用于XXXX信息系统：应用系统:所有业务相关应用系统，包括自主开发和外购产品。操作系统:Windows、Linux 和 UNIX 等.数据库：Oracle、MySQL、Sql Server 等.中间件:Tomcat，Apache,Nginx 等.网络设备:交换机、路由器等。安全

3、设备：安全管理、审计、防护设备等.2漏洞获知漏洞获知通常有如下方式：Ø 来自软、硬件厂商和国际、国内知名安全组织的安全通告。Ø 单位信息安全部门工作人员的渗透测试结果及安全评审意见。Ø 使用安全漏洞评估工具扫描。Ø 来自单位合作的安全厂商或友好的外部安全组织给出的漏洞通知。3级别定义和处理时间要求3。1级别定义对于没有CVE评级的安全漏洞统一参考附录一标准进行漏洞评级。3.1。1高风险漏洞定义1.操作系统层面:依据CVE标准。2。网络层面：依据CVE标准.3。数据库层面:依据CVE标准.4。中间件（包括应用组件包）：依据CVE标准。5。单位自主开发的业务

4、应用:详见附录一。3。1.2中风险漏洞定义1操作系统层面：依据CVE标准。2网络层面：依据CVE标准。3。数据库层面:依据CVE标准。4。中间件（包括应用组件包):依据CVE标准。5。单位自主开发的业务应用：详见附录一.3.1。3漏洞处理原则1.所有高、中风险必须在规定时间内完成修复.2.对于有关安全漏洞的修复方案经评估后会影响系统稳定或短期不能找到解决方案的漏洞,由信息安全部会同有关部门出具体解决方案.4职责分工4。1信息安全部1。定期对单位生产系统使用的应用软件及第三方组件进行漏洞监控和查找，并在当天将高、中风险转交给有关部门处理.2.不定期对本制度执行情况进行检查，确保所有漏洞都按照流程

5、进行了有效处理。3。针对发生的安全事件，及时总结经验和教训，避免再度发生类似事件。4。协助各部门提供安全漏洞测试和修复方法,并定期组织安全培训.4。2IT中心负责办公网、生产网中：操作系统、数据库、中间件、网络设备等安全漏洞的监控和修复工作：1。负责维护信息系统所有设备（包括虚拟机)和信息资产列表.2。运维部门根据信息安全部提供的安全扫描报告和本制度,制定整改工作日程,根据优先级按照“3。2处理时间要求"进行整改。外部漏洞优先处理,内部漏洞经信息安全部协商后可以延后处理。4。3各产品开发部门各产品开发部门应在接到漏洞修复通知后,按照“3。2处理时间要求"及附录一的相关要求，按时修复所负责应用系统的安全漏洞：1.在生产系统中:可获取系统权限（操作系统、数据库、中间件、网络设备、业务系统等）的漏洞；可直接导致客户信息、交易信息、单位机密信息外泄的漏洞；可直接篡改系统数据的漏洞,必须在48小时之内完成修复.2。如果确实存在客观原因，无法按照规定时间完成修复工作的,应在修复截止日期前与信息安全部申请延期，并共同商定延后的修复时间和排期。5漏洞处理流程6罚则本制度适用于单位全体员工，自颁布之日起执行。违反本制度条款的责任人，第一次发现由行政部或相关部门领导对其进行口头批评;第二次发现以邮件形式在