信息系统安全管理要求.docx

《信息系统安全管理要求.docx》由会员分享，可在线阅读，更多相关《信息系统安全管理要求.docx（23页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、信息系统安全管理要求信息系统安全管理要求231. 概述42. 系统安全管理41.1. 操作系统安全41.2. 用户安全41.3. 服务器定期巡检51.4. 安全监控51.5. 系统安全测试53. 设备安全管理53.1. 防火墙安装与维护53.2. 防火墙部署策略63.3. 3.防火墙配置标准63.4. 其他配置73.4.1. 日志监控73.4.2. 日志管理83.4.3. 更新服务84. 应用安全管理84.1. 概述84.2. 商业风险84.3. 规范要素94.3.1. XSS94.3.2. 注入式攻击94.3.3. Insecure Remote File Include94.3.4. In

2、secure Direct Object Reference94.3.5. CSRF94.3.6. Information Leakage and Improper Error Handling104.3.7. Broken Authentication and Session Management104.3.8. Insecure Cryptographic Storage104.3.9. 不安全通道104.3.10. Failure to Restrict URL Access URL105. 数据安全管理115.1. 日志管理策略115.1.1. 适用范围115.1.2. 日志收集115

3、.1.3. 日志内容要求125.1.4. 日志审计125.2. 数据管理策略135.2.1. 策略适用范围135.2.2. 数据的分类135.2.3. 隐私数据的保存与销毁政策135.2.4. 数据备份策略165.2.5.概述165.2.6. 数据备份的存储要求165.2.7. 数据备份的使用要求165.2.8. 数据备份的销毁166. 应急机制管理166.1.概述166.2. 组织及分工176.2.1. 应急响应组176.2.2. 应急响应组职责176.2.3. 安全事件的分类176.3. 统一应急响应流程186.3.1. 事件的识别186.3.2. 事件的报告与发布186.3.3. 事故涉

4、及泄密。196.3.4. 报告安全事故196.3.5. 事件的分类196.3.6. 事件处理流程196.3.7. 事件分析及总结206.4. 应急响应流程测试和培训206.5. 事件后处理及应急报告206.5.1. 善后处置206.5.2. 处置评价及内审211. 概述信息系统的安全管理是工程化的系统课题，随科技的发展快速更替方案和工具。本文主要从信息系统安全管理最重要的几个方面，分别介绍详细的安全管理，管控和应用的相关措施和方案。2. 系统安全管理1.1. 操作系统安全在保证硬件设施稳定运行的同时，系统本身的清洁高效是我们追求的目标。信息安全部门或系统工程师必须更新系统供应商 30 天之内发

5、布的所有安全补丁，热修复程序和Service Pack。 订阅 Microsoft 的安全报告，定期更新安全补丁(每周/次) 升级 Linux 服务器的内核版本，弥补系统漏洞 调试完成流量监控服务器，监控整个网络内时事数据流量 安装防病毒软件，集中管理病毒库，保证病毒库版本的实时性 在本地服务器上运行测试完毕后，再更新生产环境的程序 上传 ftp 使用完毕后，关闭 ftp 服务 定期重启服务器 合理配置 iis 的安全 卡数据交易、后台服务器属专用服务器，不得做其它用途 每周定期分析服务器日志，发现问题及早处理 在公司内部服务器和托管机房服务器中运行监控程序，遇到突发问题，将有短消息发送至相映

6、责任人手机 订阅安全警报邮件,及时发现和弥补最新的漏洞和潜在攻击行为 系统所有组件包括无线进行扫描（至少每个季度一次)1.2. 用户安全提高个人安全意识，增强对个人 pc 的安全控制 定期更改服务器口令，并且对口令强度进行严格要求，在服务器安全策略中设置强制每 3 个月，必须更改 Administrator 口令，并且修改口令不能和前四次的密码相同。Linux root 口令也制定策略，定期更改。并且口令必须满足实现订立的规则，是字母加数字加字符形的。口令有专门人员保管，需要登陆或者使用服务器的员工，一般给予user 的权限。 在防火墙和服务器上记录用户登录信息各类登录工具，ftp 工具应用。

7、我们在防火墙中针对公司 ip 地址，并且在防火墙访问日志中进行记录。其他所有 ip 地址，所有端口都不允许通过远处登陆工具和 FTP 上传下载服务。阻止服务器端对外部 Internet 的访问超级用户以及 root 口令专人管理给每一个用户分配唯一的 ID 统一管理,并且记录每次登陆和操作日值及时停止离职人员的用户及其权限对个人电脑安装防病毒和防火墙软件，杜绝从个人电脑信息泄密，造成的口令丢失 密码输入错误并锁定，至少锁定时间 30 分钟以后进行重置密码。 会话的空闲状态超时时间至少设置为 15 分钟1.3. 服务器定期巡检 每天针对核心应用服务器远程登录进行检查 每周对服务器进行一次全面的实

8、地巡检 每月对服务器进行一次全面的实地巡检 每季度由真如工程师陪同做服务器和数据库的季度巡检1.4. 安全监控 建立监控服务器，对支付页面和数据库链接进行监控，发现问题短消息通知相关人员 客服人员一旦发现客户问题，及时处理。如果判断为系统故障和网络问题，及时通知相关技术人员，随时处理。1.5. 系统安全测试 对所有系统组件进行定期的内外部漏洞扫描（至少每季度一次）并检查每季度的扫描合规结果。 对所有系统组件进行定期应用层和网络层的渗透测试（至少每年一次）并检查每年的渗透测试合格结果。3. 设备安全管理3.1. 防火墙安装与维护1.1 安装：按照 cisco、juniper 防火墙手册进行标准安

9、装配置。可参考 CIS 文档：1.2 初始密码更改：设备初始密码必须更改。（密码必须符合密码更改标准，即 8 位数字、字母和特殊符号混合的强密码）。1.3 防火墙的管理和维护防火墙统一存放在专用机柜中， 由系统工程师负责维护。职责描述：网络设备是整个网络运转的核心，系统工程师必须保证网络交换机、防火墙等主干设备的正常运转。任何人不得改动设备配置，为了保证特殊情况下的接管工作，系统工程师必须做好网络设备的配置记录，纪录对每次的配置更改，并备份设备的配置文档，记录配置时间。对防火墙的操作分为管理，审核，操作人员。有关防火墙的所有变更必须遵从防火墙策略变更流程防火墙配置标准。对防火墙的变更包括（但不

10、限于）：防火墙规则的添加、删除和修改。防火墙软件或系统配置变更。防火墙软件或系统的更新、升级或打补丁。防火墙策略变更后，及时保存配置3.2. 防火墙部署策略2.1 当行为和要求不一致时，请检查防火墙配置。2.2 只允许可以允许的客户、源地址、目的地和协议。仔细的检查每一条规则，看规则的元素是否和所需要的一致，尽量避免使用拒绝规则。2.3 针对相同用户或含有相同用户子集的访问规则，拒绝的规则一定要放在允许的规则前面。2.4 当需要使用拒绝时，显式拒绝是首要考虑的方式。2.5 在不影响防火墙策略执行效果的情况下，请将匹配度更高的规则放在前面。2.6 在不影响防火墙策略执行效果的情况下，请将针对所有

11、用户的规则放在前面。2.7 尽量简化规则，提高效率。2.8 禁止使用 Allow ALL 规则（Allow all users use all protocols from all networks to all networks）。2.9 可以通过配置系统策略来实现，就不再建立自定义规则。2.10 每条访问规则都是独立的，执行每条访问规则时不会受到其他访问规则的影响。2.11 禁止允许任何网络访问所有协议，内部网络也是不可信的。2.12 无论作为访问规则中的目的还是源，最好使用 IP 地址。2.13 如果在访问规则中使用域名集或 URL 集，需将客户配置为 Web 代理客户。2.15 新增防

12、火墙策略必需经过测试。3.3. 3.防火墙配置标准3.1 严格执行防火墙变更流程。3.2 源地址：特殊用户指定用户必须指定 ip 地址或 ip 地址范围.禁止使用 All（内-外）3.3 禁止 Internet 的出站和入站，与持卡人数据相关的环境直接通信连接3.4 禁止内部地址通过 Internet 访问 DMZ 区域3.5 持卡人相关的环境访问 Internet 区域，必须有明确的业务需求和管理层授权3.6 禁止任何的私有地址和路由信息被显示在公网上用户策略3.7 所有用户的初始密码必须修改，用户密码必须符合密码更改标准（密码必须符合密码更改标准，即 8 位数字、字母和特殊符号混合的强密码

13、）。3.8 日常维护使用只读账号，策略变更或防火墙重启等重大操作使用管理员账户。3.9 管理员账号必须是唯一的，新建账号只能是只读账号。管理策略3.11 限制防火墙只允许公司 ip 地址访问3.12 开启防火墙的网络地址转换（NAT）功能，开启 dynamic packet filtering 功能，保护内部网络地址。3.13 防火墙必须配置并启用 e-mail 报警机制启用事件日志配置并启用 syslog3.14 监控防火墙网络流量，启用 SNMP 陷阱3.15 在防火墙中对多种攻击形式设置报警机制和丢弃响应机制3.16 定期审查防火墙日志, 监控防火墙日常运转.3.17 在防火墙日志管理界

14、面，设置日志服务器地址，日志级别为事件级3.18 若防火墙配置改变，必须备份防火墙配置。3.19 定期检查防火墙策略，确保所有策略全部登记在案信息安全控制组应该每月复查一次防火墙规则，检查的结果应该记录在案。检查的范围应该包括规则的删除，访问路径的修改等。检查后提出的修改建议在实施之前，应该遵循 IT 配置变更管理流程。3.20 定期更改防火墙用户密码（每月/次），密码必须符合密码更改标准3.21 针对攻击和可疑 ip 及早采取响应措施3.22 防火墙时间服务器设置成内部服务器地址3.23 防火墙的安全管理。设置所有区段禁止 telnet，http 协议的登录访问，只开通 https和 ssh

15、 管理方式3.24 维护最新的网络 TOP，连接持卡人数据的网络 Top 图发生变化需要更新到当前版本。附：防火墙策略变更流程申请人系统工程师变更并测试否否防火墙策略调整需求表技术部主管确认部门主管审批否否申请人确认技术部主管审批系统工程师记录在案并归档3.4. 其他配置3.4.1. 日志监控每天由网络工程师登陆日志集中管理服务页面查看日志3.4.2. 日志管理发现可疑访问和攻击行为，工程师分析攻击行为的危害，并且及时排除，上报到部门主管，告知事件和解决办法。发现已经被入侵时，上报公司相关主管和风险控制部门。3.4.3. 更新服务编制更新策略，每周定期更新4. 应用安全管理4.1. 概述随着

16、Web 应用程序的增多，随之而来的就是这些 Web 应用程序所带来的安全漏洞。不遵从规范化的编码指导，会使企业、员工以及企业的客户面对严重的安全风险，遭到各种恶意攻击。Open Web Application Security Project（开放式 Web 应用程序安全项目，OWASP） 10 要素，以及 OWASP 建议大家在软件开发生命周期中应该嵌入的标准化方法。根据OWAPS（开放式 Web 应用程序安全项目）10 要素进行安全管理和应用落地，要的所有对外开放系统遵循应用安全管理规则。4.2. 商业风险现在的企业都在向客户提供通过浏览器访问企业信息的功能，同时集成 Web 服务的应用程

17、序也越来越多，这些都导致企业所面临的风险不断增加。这并不代表开发人员没有认真的对待程序开发工作，只是当Web 应用程序的数量越来越多，其潜在的隐患也会越来越频繁的暴露在互联网下。根据 OWASP 的观点：“当企业发布了一个 Web 应用程序，它们就是在邀请全球的网民向其发送 HTTP 请求。而攻击内容也可以随着这些正常的 HTTP 请求穿过防火墙，过滤系统，系统平台上的安全措施以及网络中的入侵检测系统，而不被企业所发现。这意味着企业的Web 应用程序代码本身就是企业安全围墙的一部分。随着企业所采用的Web 应用程序数量和复杂度的增加， 企业的安全围墙将更多的暴露在网络中。”目前，企业所开发的很

18、多新应用程序都是 Web 应用程序。另外，Web 服务也越来越频繁的被用来集成 Web 应用程序或与 Web 应用程序进行交互。所带来的问题就是，Web 应用程序和服务的增长已经超越了程序开发人员所接受的安全培训以及安全意识的范围。随着存在安全隐患的 Web 应用程序数量的增长，OWASP 也总结出了 Web 应用程序的十大脆弱点。在这个 10 要素列表中，不但包括了 Web 应用程序的脆弱性介绍，还包括了 OWASP 的建议内容，帮助程序开发人员和企业尽量避免这些脆弱点给企业系统带来的风险。OWASP 10 要素中还包括了一个指南，帮助企业决定该如何向客户提供信息。比如联邦贸易委员会（FTC

19、）就在 2003 年 1 月的商业案例文档中将这个列表作为了信息安全的参考内容。同年，FTC 还将 OWASP 10 要素列表作为指控 Guess 公司没有尽力做好客户的信息安全保护工作的参考资料。4.3. 规范要素4.3.1. XSSA1、Cross Site Scripting (XSS) Flaws 跨站点脚本攻击XSS 是一种常见的攻击。当攻击脚本被嵌入企业的 Web 页面或其它可以访问的 Web 资源中，当没有保护能力的台式机访问这个页面或资源时，脚本就会被启动。这种问题可以影响成百上千的员工以及企业客户的终端电脑。4.3.2. 注入式攻击A2、Injection Flaws 注入式

20、攻击如果没有成功的阻止带有语法含义的输入内容，有可能导致对数据库信息的非法访问。比如在Web 表单中输入的内容，应该保持简单，并且不应该还有可被执行的代码内容。4.3.3. Insecure Remote File IncludeA3、Insecure Remote File Include 不安全的远程文件包含-对远程文件包含易感的代码允许攻击者包含进入恶意的代码和数据，最后导致破坏性攻击，比如，服务器被完 全攻陷。4.3.4. Insecure Direct Object ReferenceA4、Insecure Direct Object Reference 不安全的直接对象引用当开发者

21、暴露一个对内部对象的引用时，直接对象引用发出。象：文件、目录、数据记录、Key、URL 或者 Fo rm 参数，攻击者可能未经授权操纵直接引用对象，除非适当采取了存取控制控制。4.3.5. CSRFA5、Cross Site Request Forgery (CSRF) 跨站请求伪造跨站请求伪造不是一个新的攻击，但它确是简单而灾难性的。一个跨站请求伪造攻击强制受害者的 browser 发送一个请求到易受攻击的 Web 应用，这个应用不执行受害者行为而执行伪造了的行为。4.3.6.HandlingInformation Leakage and Improper ErrorA6、Informati

22、on Leakage and Improper Error Handling 信息泄漏和异常错误处理一些应用程序问题可能导致应用不经意间泄漏它们的配置、内部工作等。应用也可能通过它们执行特定的操作时间或者对不同输入的响应而泄漏一些内部的东西，象不同的错误代码确显示同样的错误内容。4.3.7. Broken Authentication and Session ManagementA7、Broken Authentication and Session Management 失效的账户和线程管理 良好的访问控制并不代表万事大吉了。企业还应该保护用户的密码，会话令牌，账户列表以及其它任何可以给攻击

23、者提供有利信息帮助他们攻击企业网络的内容。4.3.8. Insecure Cryptographic StorageA8、Insecure Cryptographic Storage 不安全的加密存储对于 Web 应用程序来说，妥善的保存密码，用户名，以及其它与身份验证有关的信息是非常重要的工作。对这些信息进行加密是非常有效的方式，但是一些企业会采用那些未经实践验证的加密解决方案， 其中就可能存在漏洞。4.3.9. 不安全通道A9、Insecure Communications 不安全的通信保护敏感通信非常必要，应用频繁失败加密网络传输。所有的认证连接不是后台连接必须加密( 通常 SSL) ，

24、特别是存取Internet 的 Web 页面。否则，应用将暴露认证或者 Session token。另外，象信用卡或者健康等敏感数据无论何时传输时都要进行加密。4.3.10. Failure to Restrict URL Access URLA10、Failure to Restrict URL Access URL 访问限制失败通常，对 URL 的保护仅仅是不显现给未受权的用户。但，一个故意的、有技巧的用户很容易找到这样的 URL 并存取这些页，调用函数并看数据。在应用程序中不清晰的安全是不足以保护敏感函数与数据的。请求对敏感函数的调用之前必须执行存取控制检查，以保证用户被受权去存取那些函

25、数。5. 数据安全管理本管理策略主要用于指导及规范涉及互联网业务的所有日志的收集、审计以及相应数据的保存与销毁的操作。策略主要用来保护公司赖以生存的信息资产安全。所有的员工均需严格遵守该策略中的规定。公司将根据自身业务的发展需求，持续更新完善此管理策略。本规定参照支付卡行业数据安全标准（PCI DSS）制定。支付卡行业数据安全标准（PCI DSS）程序是由信用卡组织制定的一套法定的安全标准， 它的作用为保证各商家和服务商具有一套完备统一的方法来保护各个卡种的持卡人的信息安全。PCI 数据安全标准适用于所有保存、处理或传递持卡人信息的支付卡系统、商家和服务商；适用于所有信用卡使用方式， 不论是手

26、动刷卡还是网上使用。即使最严格的细则也适用于网上进行信用卡交易的电子商务网站和 POS 零售系统。5.1. 日志管理策略5.1.1. 适用范围所有用户、管理员、应用程序和系统的日志管理过程都必须遵守该策略，除非事先得到系统运营团队主管的批准或书面许可。5.1.2. 日志收集公司的所有的网络安全设备以及应用系统组件都必须打开日志自动审计功能以记录日志， 对于关键的业务系统必须将日志记录到统一的日志记录服务器上，并联机至少保存 3 个月， 脱机至少保存 1 年。以下的行为是日志必须记录的： 非法的网络访问。 网络 IP 地址的成功分配和释放 所有用户对持卡人数据的访问。 任何用户或管理员的登录认证

27、尝试（包括成功的和不成功的） 所有的系统管理行为以及超过普通用户权限的操作：(如： root, 具有管理组权限的 userid, oracle)。 对未在例外中列出的系统和系统中受保护的资源的每个成功的或失败的访问。 对数据库的读写操作。 对的审计日志文件的访问。 认证和授权机制的使用。 创建或删除系统级对象（如可执行文件，库文件或动态库文件，配置文件， 驱动程序等）。 改变系统级对象安全状态的命令。 系统重启以及日志文件的初始化。5.1.3. 日志内容要求所有记录的日志必须能够有效的描述所记录的事件，日志应该包含以下要素： 进程或用户标识 事件的类型 事件发生的日期和时间 事件源 源发地址和

28、目的地址 影响到的数据，系统组件或资源的名称 事件结果（针对该事件系统采取的措施）5.1.4. 日志审计对于网络安全设备所产生的安全日志以及所有的反病毒软件在监测到有病毒的时候所产生的日志，系统运营团队必须 24 小时不间断监测，一旦发现有可能引起安全问题的事件，应及时按照公司应急响应方案及流程中的规定采取相应的措施。对于业务系统所产生的事件日志，必须集中存放在一个受到保护的地点或介质中，存放地点或介质未经授权不得存取，日志内容不得受到非授权更改。只有在必须情况下才允许查阅这些日志。日志必须有文档完整性监测系统（FIM）的保护，一旦发现未经授权的访问，监测系统立即发送报警信息给系统运营团队。5

29、.2. 数据管理策略5.2.1. 策略适用范围本策略适用于所有公司业务系统涉及的数据管理过程，包括数据的保存、备份和清除的操作。除非事先征得系统运营团队主管的批准，否则任何人不得例外。5.2.2. 数据的分类数据按照安全级别可分为机密级、敏感级、私密级和公开级（具体分级标准请参照公司人员管理与访问控制策略）。按照数据存储的介质不同可分为纸质文档和电子数据。5.2.3. 隐私数据的保存与销毁政策5.2.3.1. 概述所谓的隐私数据是指由公司系统运营团队标定为机密级和敏感级的数据，这些数据可能是纸质的文档也可能是电子数据。5.2.3.2. 隐私数据的保存要求所有敏感级和机密级数据的保留，不论保存在

30、何处，数据的保留必须是符合法律、法规和商业条款的要求。数据保留的期限原则上由数据创建者或系统管理员设定，但是一些特定的数据必须遵循以下的规定： 所有关键业务系统和网络设备的审计日志数据必须在设备上动态保存至少 90 天以上，日志的备份数据必须保留一年以上。 用来进行单笔交易的持卡人数据（不管是纸质文档还是电子数据）保存时间不能超过 120 天。 需多次用来交易的持卡人数据在公司客户帐号使用期间可以保存。一旦客户帐号被中止或终止，30 天内该帐户的所有持卡人数据都会以本策略许可的方式销毁。 持卡人的交易信息，包括信用卡磁道信息、CVV2、PIN 数据，仅在交易授权完成前允许保留。禁止在授权完成后

31、保存持卡人的授权数据。5.2.3.3. 隐私数据保存安全要求所有用于保存隐私数据的介质（包括纸质和电子介质）都必须以安全的方式进行保存。在所有的安全介质存储地点必须有介质保存日志（见附录 A）。所有存储的含有机密级或敏感信息的电子介质或纸质资料必须每季度或更短时间内由系统运营团队进行一次检查。检查时必须对保存机制的安全控制机制进行检查。检查完成库存后必须更新介质保存日志。5.2.3.4. 数据的物理安全要求保存有敏感或机密级信息的纸质和电子文档都必须采用相应的物理访问控制措施进行保护。 敏感区域必须装有摄像头监控。除非法律要求，获取的监控数据必须保存三个月以上。 存有机密级或敏感信息的各个系统

32、必须设有相应装置（采取物理访问控制措施） 以限制和监控对此类设施/系统的物理访问。 除非法律要求，进入各个系统的访问日志和审核记录都必须搜集并保存三个月以上。5.2.3.5. 纸质介质的保存要求含有敏感级或机密级信息的纸质介质（如，收据、纸质报告、传真等）必须遵循以下存储原则： 含有敏感或机密级信息的打印报告不得带出公司安全办公环境； 除非事先获得系统运营团队授权，任何含有敏感或机密级信息的纸质材料不得带出公司数据中心机房； 含有消费者机密级或敏感数据的打印或存档，只限于在系统运营团队认定的必要的可用时间段内在公司办公环境的安全区域内使用； 所有含有机密级或敏感信息的纸质资料上必须明确贴上相应

33、标签； 所有机密级或敏感纸质资料必须锁藏在系统运营团队批准的安全的贮器（如， 密码箱、贮柜、贮屉、贮箱）中； 机密级或敏感的纸质资料不得保存在未加锁或不安全的贮器或者开放的办公区域。5.2.3.6. 电子介质的保存要求保存有机密级或敏感信息的电子存储（如，CD、DVD、U 盘、硬盘）介质必须遵循以下原则： 系统运营团队未授权情况下，机密级或敏感信息禁止复制到可移动介质介质上； 除非计算机系统备份外，含有机密级或敏感信息的电子介质不得带出公司的安全办公环境； 除非事先获得系统运营团队授权，含有机密级或敏感信息的电子媒介不得带离公司数据中心或机房中； 含有消费者机密级或敏感数据的电子介质的获取或保

34、存，只限于在系统运营团队认定的必要的可用时间段内在公司办公环境的安全区域内使用； 所有含有机密级或敏感信息的电子介质必须明确贴上相应标签； 所有存储介质必须以确保安全的快递方式或其它方式进行发送或运输，所用方式须经系统运营团队批准，并且可以准确无误地跟踪查询。5.2.3.7. 隐私数据的清除要求在法律或业务需求规定不再要求保留数据时，所有机密级或敏感级电子数据必须按照本策略许可的方式进行销毁。本要求适用于所有保存在各个系统和临时性文件或存储性媒介中的数据。5.2.3.8. 隐私数据清除方式对于超过保留期限的敏感级和机密级数据，每晚在持卡人信息系统会执行一个自动程序进行销毁。其它保存在文件和目录

35、中的应用数据，必须用系统运营团队批准的擦除工具安全删除。以下存储有超过保留期限的机密级或敏感级数据的媒介必须按安全方式处理： 硬盘：内容清洗（用二进制数据清洗 7 遍）、消磁、粉碎硬盘； 软盘：拆散、焚烧、粉碎或溶化； U 盘、智能卡、数字介质：焚烧、粉碎或溶化； 光盘（CD 和 VCD：表面破坏、焚烧、粉碎或溶化； 纸质的文档资料应该由管理员使用专用的碎纸机切碎。计算机或通信设备折旧换新、维修处置前，所有机密级或敏感级信息必须按本策略许可的方式销毁或者隐藏。移动存储媒介如软盘、光盘或磁带不能捐献或作其它重复利用。对于公司自己技术无法销毁的介质应在与具有销毁认证资质的专业厂商签订销毁协议后交给

36、该厂商销毁处理。5.2.4. 数据备份策略5.2.5. 概述为维护公司的业务正常运转，并应对突发情况，管理员有义务在系统运营团队门核准后对自己管辖范围内的系统、应用程序以及各种数据利用介质（电子或纸质）进行备份。公司所有备份数据的操作均需遵守此策略。5.2.6. 数据备份的存储要求所有的数据备份介质都必须安置到安全的离站储存地点。这些备份介质的存储地点必须至少每年一次由管理人员或系统运营团队的成员确认是是在安全的保护状态下（物理安全、防火安全等）。所有的数据在备份前应由系统运营团队对数据的安全级别进行分级（具体分级标准请参照公司人员管理与访问控制策略）并对备份介质进行标识。系统运营团队每季度必

37、须对数据备份进行一次核查，并对比介质保存记录（参见附录A）。5.2.7. 数据备份的使用要求除非在必须并经系统运营团队核准的情况下，数据备份才可以被使用。只有公司技术人员和负责储存设施的人员才能访问数据备份介质。所有的备份数据在使用时都应有明确的使用记录。所有备份数据的介质从一个地点传送到另一个地点都应记录，这些记录包 括：谁，从哪里，是否收到，管理层的签名等要素。5.2.8. 数据备份的销毁所有不再需要或已失效的备份数据存储介质必须予以销毁或使之无法被读取，保证任何数据都不会被提取。数据的合理销毁技巧请参照隐私数据的清除要求。6. 应急机制管理6.1. 概述为适应发展需要，提高应对突发事件的

38、能力，保证系统能够在发生突发事件的情况下，仍然可以系统、协调、高效地开展工作，并将突发事件可能造成的损失控制在最低程度内。所有事故的检测和响应，特别是与关键系统有关的，必须遵守本策略。这些事件包括单不限于:（1） 系统的关键业务系统、网络通信、机器设备等发生故障而引起的交易中断的突发事件；（2） 因业务系统账户信息泄露引发的突发事件；（3） 因自然灾害、事故灾难、公共卫生事件、社会安全事件以及能源供应、物资供应、通讯等公共服务的中断而造成系统无法正常运营的事件；（4） 危害系统公共关系和形象，造成不良社会影响的各类突发事件；（5） 在生产网络探测到未经授权的无线访问点。本方案指导系统突发事件应

39、对工作。6.2. 组织及分工6.2.1. 应急响应组系统设计应急响应组,应急响应组以系统技术总监为负责人,IT 及开发人员为骨干, 各业务部门主要部门负责人为组员。6.2.2. 应急响应组职责应急响应组的职责包括： 管理职责包括：1) 研究拟定突发事件处置对策；2) 组织指挥突发事件处置工作；3) 协调、管理突发事件中的新闻信息工作；4) 向信息安全办公室提交突发事件处置工作报告，报告内容应包括但不限于：突发事件的描述及分析，各项对策制定的原因及实施结果，突发事件及处置工作对未来的影响评估，处置工作的经验教训等。处置职责包括：1) 实施与职责相关的各项处置措施；2) 收集、反馈突发事件处置的相

40、关信息以支持领导小组决策；6.2.3. 安全事件的分类应急响应组必须首先鉴定安全事件是否需要正式应对。很多情况下安全事件不需要响应时，这时只需转交至相应 IT 区域以确保能提供所有必要的技术支持 。以下是对系统运营团队将会做出响应的事件描述：事件分类分类描述一级安全事件例如潜在的非友好行为，（例如：未授权远程登录，端口扫描，病毒检测及清除，意外的性能峰值等等）二级安全事件例如一个明确的对未经授权的信息进行获三级安全事件6.3. 统一应急响应流程取或访问（例如，试图下载的安全密码文件，企图访问受限区域，非关键系统的单机中毒，未经授权的漏洞扫描，等等）或者第二次出现 1 级攻击行为。明显攻击或实际

41、违反安全策略（例如，多手段攻击，拒绝服务攻击，重要系统或网络的病毒感染，成功缓冲/堆栈溢出，未经授权成功访问敏感或关键数据或系统，解锁，盗窃文件等）或者第二次出现 2 级攻击行为.系统遵循的应急响应流程包括：事件的报告与识别、分类、抑制、消除、恢复和原因分析以加强安全控制。6.3.1. 事件的识别能遇到一些安全事故示例包括（但不限于）：事件盗窃、损坏或未经授权的访问欺诈 数据库、日志、文件或纸张记录中的信息不准确系统的异常行为安全事件通知异常的行为系统示例例如，未经授权的登录、办公桌中纸张的丢失、锁被破坏、日志文件丢失、保安警报、闯入或非预定/未经授权的物理进入的视频证据例如，非预定的系统重启

42、、意外的消息、系统日志文件中的异常错误或者终止例如，文件完整性警报、入侵侦测警报和物理安全警报例如，非预定的系统重启、意外的消息、系统日志文件中的异常错误或者终止系统的所有员工必须意识到，他们有责任检测安全事故，以便执行事故响应计划和程序。所有员工都有责任在其特定责任范围内协助执行事故响应程序。员工在日常活动中可所有员工，不论职责岗位，都应该清楚可能发生的事故的标识，并且知道在这些情况下应该通知的人员。在任何情况下，每个员工如果未被指派事故响应计划内的其他活动， 都应该按照事故报告与发布程序（下节）的指示来报告事故。6.3.2. 事件的报告与发布只要有与系统计算资产（特别是任何关键系统）有关的

43、任何可疑或真实安全事故，都应该立即通知 应急响应组。如果不能确定是否为安全事故，应联系 IT 来进行评估。各部门发生轻微或一般的突发事件后，原则上应在下一工作日报送应急信息。若遇到 较大或重大的突发事件后，原则上应在 4 小时内报送应急信息。如果情况特别紧急或重大， 应当在准备书面（电子）材料的同时，第一时间内以电话方式报告。在面对可疑情况时 ， 员工应采取如下措施，以确保事故调查和恢复流程的完整性：6.3.3. 事故涉及泄密。1） 不要改变计算机系统的当前状态。2） 计算机系统应保持运行且所有当前运行的计算机程序保持当前的状态。不要关闭或者重启计算机。 3）应该立即拔掉计算机背后的网线，使其

44、从网络中断开。6.3.4. 报告安全事故向应急响应组联系报告任何可疑或真实的事故。所有员工都应非常清楚应急响应组的电话号码，在非上班时间应直接联系响应者负责人。任何人都不得向其主管或者应急响应组以外的任何人透露任何有关可疑或真实事故的细节或大概情况。所有与执法部门或公众的信息交流都必须由应急响应组和信息安全办公室统一协调。在等待系统运营团队响应事故之前，应记录下您所知道的任何信息。如果知道，则这些信息必须包括事故的日期、时间和性质。您可以提供的任何信息将有助于以正确的方式响应。6.3.5. 事件的分类应急响应组在接到事件报告后，应急处置人员应该对事件进行快速评估并进行初步分类，分类详情参见第

45、3 节。6.3.6. 事件处理流程6.3.6.1. 一级安全事件对于一级安全事件，应该进行抑制和监控；抑制和监控行为包括1) 如果可能的话，记录使用的用户名，IP地址及入侵者网域。2) 利用许可的技术控制手段，临时或永久地阻止入侵者访问。3) 保持警惕，阻止该用户或来自该IP地址的进一步攻击。6.3.6.2. 二级安全事件对于二级安全事件，应该进行抑制、监控和警告；具体措施应包括：1) 收集并保护与该入侵有关的信息2) 利用许可的技术控制手段，临时或永久地阻止入侵者访问3) 分析攻击源。4) 联系ISP获取有关该入侵和入侵者的更多信息。5) 研究有关入侵方法可能带来潜在的风险，重新评估较高级别的安全事件及其抑制、消除以及恢复的措施和手段。6) 根据调查如果发现员工是一个不友好的用户，必须通过警告来防止此类事情再度发生。该雇员的管理者应该和人事部门共同依据可接受使用策略来处理该类事件。6.3.6.3. 三级安全事件对于三级安全事件，应该抑制、消除、恢复并进行事件原因分析。具体措施应该包括：1) 如果事件涉及持卡人数据，必须通知收单行