• 3.SDL落地方案

    01.安全培训

    安全意识培训(全员)

    • 邮件安全
    • 钓鱼邮件
    • 邮件伪造
    • 第三方转存
    • 检查发件人
    • 开启二次验证
    • 邮件转发
    • 第三方代收

    • 邮件附件敏感信息加密

    • 病毒防范

    • 什么是木马病毒
    • 我安装哪些杀毒软件？

    • 定期更新病毒库

    • 浏览器安全

    • 不浏览恶意网站
    • 不从恶意网站下载软件

    • 下载软件从官网下载

    • 信息泄露

    • 敏感数据上传到云笔记、GitHub
    • 共享账号
    • 使用公司邮箱注册外部账号或者私人账号
    • 社交网络发布公司技术解决方案&保密产品信息
    • 公司账号和私人账号要隔离
    • 打印后及时取走

    • 定期删除浏览记录和搜索记录

    • 个人电脑安全

    • 锁屏幕
    • 不轻易插入陌生U盘
    • 及时的系统更新
    • 不从外部下载破解软件(有需要请找IT同学)
    • 不将公司数据带离工作场所
    • 电脑要加开机密码，防止电脑丢失后造成数据泄露
    • 企业微信、微信、QQ、QQ群文件发送文件要打包加密

    • 工作文档加密盘（利用如TrueCrypt的之类的加密软件）

    • 密码泄露

    • 根据调查显示目前全世界泄露账号密码以及个人隐私有800亿条
    • 密码使用超过12位以上使用特殊字符、大小写字母和数字
    • 密码不要与公司内部密码有关联
    • 密码三个月要更换一次

    • 不在浏览器上使用保存密码功能

    • WiFi安全

    • 不连接不可信WiFi
    • 连接不可信WiFi后需要连接VPN
    • 不要在工作区私自桥接，共享办公网WIFI

    • 不要使用WIFI万能钥匙等共享密码的APP

    • VPN以及OA安全

    • VPN账号和OA账号仅自己持有
    • 任何人不会和你以任何理由要VPN以及OA账号

    • VPN的动态验证短信不转发给其他人

    • 客服注意事项

    • 我在和谁聊天
    • 确定对方身份的流程
    • 我可以提供哪些信息

    • 敏感操作回拨验证人员身份

    • 物理安全

    • 门禁
    • 碎纸机（防止泄露商业信息）
    • 视频监控
    • 禁止人员尾随进入工作区

    WEB安全开发

    • XSS跨站漏洞
    • SQL注入
    • 跨站请求伪造漏洞
    • 支付逻辑漏洞
    • 越权漏洞
    • 平行权限
    • 验证码逻辑漏洞
    • API未限速漏洞
    • GitHub敏感信息泄露
    • 法律风险意识

    APP安全开发

    • 数据安全
    • 存储
    • 传输
    • 使用
    • 验证
    • 代码安全
    • 逆向
    • 调试
    • 重新打包
    • 环境特性
    • 系统
    • 组件
    • 权限
    • 端口
    • 业务安全
    • 逻辑漏洞
    • 策略
    • 合规

    安全运维

    • 服务器安全
    • MFA登录
    • 使用key登录
    • 禁止弱密码登录
    • 禁用无用账号
    • 账号锁定策略（防止暴力破解，ssh:fail2ban）
    • 检查特殊账号（空口令）
    • 禁止root远程登录
    • 关闭非必须服务器服务
    • 安装IDS/IPS系统

    • 进行日志收集

    • 更新

    • 系统版本要尽量贴近官方版本

    • 软件版本（例如：php）要及时升级

    • 日志

    • 收集全面
    • 实时传输
    • 重点日志例如 ssh 内核日志 业务日志

    • 业务日志要脱敏

    • 软件安装

    • 只允许可信软件源
    • 需要新软件需要经过安全评估

    • 业务代码尽量不使用root权限运行

    • 网络安全

    • ACL限制不需要互相访问的业务通讯
    • 安全组不要附加

    • snmp修改团体名称

    • 数据安全

    • 杜绝弱口令
    • 禁止匿名用户
    • 数据库加密（按照最小化权限原则）
    • Redis必须加密
    • 大数据服务必须有鉴权

    • MongoDB必须加密码

    • 流程安全控制

    • 运维准入
    • 域名开通流程
    • VPN申请流程

    • 跳板机申请流程

    • 物理安全

    • 机房服务器不允许使用USB接口
    • VGA显示器应该处于退出状态

    产品经理安全培训

    • 敏感信息泄露
    • 调试开关
    • 防重签名
    • http-dns
    • 数据包劫持
    • 登录机制安全性
    • 防暴力破解
    • 时间窗口合理性
    • 不要成为短信轰炸机
    • 任意用户密码重置

    引用

    02.需求评估

    记录一次安全设计评审的过程，当然这也是我第一次进行安全评审。因此做一个总结。安全设计评审应该是SDL落地安全人员参与过程中首当其冲的地方。仅指安全人员自身的功用。如果按照SDL流程来讲，最前期应该是进行安全培训。我们可以看两个微软SDL官方给出的流程图。 image

    image

    那么在安全设计评审这一阶段，应该怎么去做。我们可以先看下唯品会的SDL中在落地安全设计这一块怎么做的。

    image

    就我自身而言。是按照以下这个流程进行的。

    看着一大堆乱七八糟，自上而下的流程，但是做起来其实很快的。此处默认安全人员熟悉各种基本的开发过程中的安全规范以及一些Checklist(必须要了解公司开发语言对应的安全开发规范)，举例： web安全开发规范，Python安全编码规范，Flask安全， Django安全,常用的安全配置，面临哪些攻击点等等。 ps: 明确逻辑是非常重要的，可以说最为重要，如果连逻辑都不明白，谈什么设计评审。

    一些比较基础的:

    • HTTPS Everywhere
    • Bcypt 存储Hash
    • OTP
    • 频率限制
    • 盐不要硬编码
    • secret 和 auth-token 不要硬编码
    • 服务器间调用的api不要在app出现
    • CSP, CSRF, HSTS, X-FRAME-OPTIONS, X-XSS-PROTECTION
    • 过滤输入 等等等....

    下面以C2C平台交易部分为例进行说明，可以简单的想一下，在智联买一张火车票，打开了支付宝进行支付。: image

    然后，你知道数字签名当然是很基础的部分了。那么接下来，你就要细化支付流程过程中出现哪些操作，针对这些操作需要做什么样的防护措施。下图是针对用户商户支付方之间的流程：

    image

    针对每个输入点，自身可控的输入输出的地方，进行过滤，校验等操作。

    所以那么问题来了，如果只单单是用户和支付方之间的呢?

     image

    你也可以思考一下如何进行。

    并且在OWASP应用安全设计中，详细指出了其他一些问题(中文版 Version 1.0 5):

    • 数据流:

     用户输入是否被直接用于引用业务逻辑的类或函数?

     是否有一个数据绑定缺陷?

     是否暴露任何后门参数来调用业务逻辑?

     应用程序的执行流程是否正确?

    • 身份验证和访问控制:

     是否对所有文件实现访问控制?

     是否安全地处理会话?

     是否存在单点登录?单点登录是否留下后门?

    • 已有或内置的安全控制:

     在现有任意安全控制中的弱点;

     安全控制的部署是否正确?

    • 架构:

     对所有的输入是否有验证?

     到外部服务器的连接是安全的吗?

    • 配置或代码文件和数据存储:

     配置文件中是否含有敏感数据?

     是否支持任何不安全的数据源?

    imageimage

    但是其实并不需要按照上述所有清单做自检，或者说是当你和开发团队在讨论的过程中不需要涉及全部的checklist，可能只需要在架构上，设计上进行检验，以及身份验证和数据检验上。当然，都是需要根据自己的业务场景去实现，因地制宜。

    Resources

    03.产品设计

    1.应用系统架构安全设计要求

    在应用系统设计阶段，应充分考虑该架构的安全性,包括B/S、C/S等形式的安全，主要体现在应用数据和用户会话的安全，还应当考虑应用系统自身体系架构内部的安全，以及与外系统接口的安全。针对某些特殊应用，还需考虑复、抗攻击等安全机制。

    1.1.应用系统自身架构安全

    1. 自身结构中各组件之间通讯过程的安全机制
      组件之间的通讯包括命令级的和数据级的，应充分考虑：

      • 传输命令和数据所采用的协议的安全性。应根据组件之间通讯内容安全性要求程度的不同选择不同安全性要求的协议；
      • 考虑程序的模块之间的安全通讯机制；
      • 不应使用标准的服务端口或者常见病毒、蠕虫等使用的服务端口。

    2. 认证与访问控制机制，应考虑：

      • 组件之间的信任机制；
      • 用户的身份认证机制；
      • 对于组件资源的访问控制机制；
      • 不通用户对资源的权限控制机制。

    3. 组件内重要文件和数据的安全防护机制：
      存在于组件内部的重要数据资源应当考虑其相应的安全防护机制，这些重要的数据资源包括：

      • 配置文件；
      • 用户数据，包括文件数据及数据库中的数据；
      • 临时文件和数据；
      • 与外系统或者系统内部其他组件接口用的数据文件。

      对这些重要数据的存取安全性设计，包括: - 文件和数据存放是否加密及采用的加密方式。

    1.2.应用系统与外系统接口的安全

    应用系统与外系统的接口安全设计，主要应考虑以下几个要素： 1. 与外系统的之间通讯中的安全机制。应充分考虑： - 传输命令和数据所采用的协议的安全性。应根据系统之间通讯内容安全性要求程度的不同选择不同安全性要求的协议； - 建议不使用默认的服务端口或者常见病毒、蠕虫等使用的服务端口。

    1. 与外系统的认证与访问控制机制，应考虑：
    2. 系统之间的信任机制；

    3. 对于系统之间资源的访问控制机制。

    4. 对外系统安全机制的符合性，应考虑：

    5. 如果外系统采用的接口方式经评估认为是安全的，本系统应当沿用其接口规范进行设计开发；
    6. 如果外系统采用的接口方式经评估认为存在安全缺陷，应商定采用更加安全的接口方式；
    7. 在考虑接口安全性的同时，也应当注意接口方式对双方系统性能、磁盘、连接数等各种性能指标和资源的影响。

    1.3.应用系统其他的安全机制

    除了上述基本的安全架构设计内容外，针对不同的应用，以及应用系统的重要程度，可以补充考虑以下几种安全机制： 1. 针对Web应用的页面保护与恢复机制。
    利用专用的安全产品，或者系统自身设计时就考虑到了对于Web页面进行静态保护和监控问题，当监控到网页被篡改时能够实时恢复页面。 2. 针对特殊数据的完整性检查和监控机制。
    应用系统自身的审计机制。这一点也可算作是应用系统的安全功能设计的一部分，参见相关章节的要求。 3. 应用系统安全性分析。
    任何系统都会存在一定的安全缺陷，关键在于风险和缺陷是否可以被容忍，因此，在应用系统设计完成后，应当就其安全性问题进行自我分析和评价。

    2.应用系统软件功能安全设计要求

    除了在架构上考虑的安全机制外，这些安全机制及相关的安全功能也应当分配在应用系统软件的各部件中。应用系统在开发中应该考虑如下五个方面的安全功能： - 安全审计； - 通讯安全（此部分内容在架构中进行了设计）； - 数据保护； - 认证与授权； - 资源保障。

    2.1.认证与授权功能的设计

    1. 应用软件应包含用户身份认证体系的强度设计,重要系统应使用双因素认证措施，加强系统安全性：
    2. 用户名、口令认证；
    3. 一次性口令、动态口令认证；
    4. 证书认证；（可选）
    5. 生物特征的认证（签名、声音、指纹、虹膜、视网膜等）。（可选）
    6. 应用软件应包含认证失败后的处理方式设计
    7. 连续失败3次，将锁定登录账号一个小时。账号锁定后可以由系统管理员解锁，也可以在一段时间后自动解锁；
    8. 通知用户认证失败，防止黑客暴力猜测；
    9. 验证码的功能；
    10. 账号复杂度提醒功能。
    11. 应用软件应包含用户权限分配和管理功能设计。
    12. 系统编码中要实现读、写、执行三个权限的分离设计；
    13. 系统查看、配置、修改、删除、登录、运行等权限设计；
    14. 数据访问范围的权限设计；
    15. 应用功能模块使用权限的设计。
    16. 应用软件应包含接口设计，应明确系统的内部结构和外部接口，对于每一个对外接口应详细说明：
    17. 需要通信的对方系统的安全状况和可信程度；
    18. 需传送的数据的保密性和完整性要求；
    19. 对传送数据的合法性检验规则；
    20. 对通信可靠性的要求；
    21. 与外部系统的互相认证方面的需求。

    2.2.数据安全功能

    1. 应用系统的数据安全功能，应当根据安全需求进行功能设计，内容涉及：数据库的安全、数据采集、数据传输、数据处理、数据存储、数据备份和恢复的安全。对重要的敏感数据应进行加密和完整性保护。
    2. 应用软件应包含输入的安全性设计，主要指对错误输入、恶意输入进行处理。
    3. 应用软件应包含输出的安全性设计。

    2.3.安全审计功能

    1. 应用系统具备如下安全审计功能：
    2. 审计功能的启动和关闭；
    3. 变更审计功能的配置信息；
    4. 至少应进行审计的事件：进入和退出的时间(登录、退出系统)、异常的系统使用行为(失败登录)、系统维护行为、敏感行为和其它安全功能要求的审计内容；
    5. 每个审计记录中至少记录如下信息：事件的日期和时间、事件的类型、主题标识、事件的结果(成功、失败)和事件相关信息。
    6. 应用系统应支持数据查阅审计功能：按照主题、事件查阅；应用系统应明确用户能够查阅审计数据用户。
    7. 在意外情况出现时，应有措施保证审计数据的可用性，当审计记录溢出时采取保护行动。

    2.4.容错功能设计

    1. 应用软件应包含各模块的出错处理设计。
    2. 应用软件应包含可能出现的各种异常情况的安全处理设计。
    3. 应用软件应包含抗网络攻击的能力的设计及系统脆弱性分析。4、对于应用软件本身的资源及服务的优先保障设计。

    3.应用系统存储安全设计要求

    在应用系统存储安全设计时，应对系统的存储容量、存储介质、存储备份内容、存储备份方式、存储设备功能要求及相关的存储技术统筹进行考虑。

    3.1.应用系统的存储容量设计

    应依据对于应用数据的测算，估算应用系统的存储容量，建议在存储容量估算时应考虑以下要求： - 在实际估算值上预留20%的存储余量，并考虑未来的应用存储量的增长需求。 - 考虑到应用系统自身的审计数据的容量、保存期限以配置相应的存储设备。 - 对于应用系统中的临时数据和过渡数据，应当设计其保存的时间，并以此考虑这部分的存储容量要求。

    3.2.应用系统的存储介质选择

    应用系统的存储介质主要包括但不限于：磁带、纸带、闪存、软盘、光 盘、磁盘和磁盘阵列。具体存储介质的选择应依据应用系统的业务种类及存储周期的要求，采用不同的介质。 1. 对于应用系统的交易数据，应采用高性能、高可靠的存储介质，如磁盘、磁盘阵列等进行存储； 2. 对于应用系统的历史数据，应采用可靠、稳定的存储介质，如磁带、光盘等进行存储。

    3.3.应用系统存储备份对象

    应用系统对于其储存备份的对象设计，应包括如下内容： 1. 系统数据的备份：应包括Web服务器的网站内容、Mail服务器的邮件实时备份、数据库、文件服务器中的文件以及其他数据； 2. 系统的完全备份：应包括关键的、需要快速恢复的设备，通过磁带机的完全备份，应实现快速的灾难恢复； 3. 系统的冗余主机备份：对于关键并且不能停止的服务设备（如计费服务、Web、Mail服务器），应考虑使用多台主机进行冗余备份，以保证当任何一台主机发生故障时，服务器仍可提供服务； 4. 系统配置的备份：应包括关键路由器的配置、防火墙的配置、各类服务器操作系统的安全配置以及各类服务器（如Web、Mail、文件服务器等）中服务器软件（如Apache、Sendmail）的配置。

    3.4.应用系统存储备份方式

    应用系统应当根据不同的阶段，系统数据不同的重要程度，对数据采取不同的备份方式： 1. 完全备份
    使用备份介质对整个系统进行完全备份，包括系统和数据。这种备份方 式的优点是直观，容易被人理解，而且当数据丢失时，可以快速恢复丢失的数据。它也有不足之处，即： - 定期对系统进行完全备份，因此在备份数据中有大量的重复信息，占用了大量的存贮空间，增加了备份成本； - 需要备份的数据量大，因此备份所需要的时间较长。
    建议在关键性应用系统的实施前、实施后、变更以及升级等重要操作时， 对操作系统进行完全备份。针对信息较小的不断变化的，且变化的内容大于 50％的，定期进行完全备份。 2. 增量备份
    每次备份的数据只是相当于上一次备份后增加和修改过的数据。没有重 复的备份数据，节省备份介质的空间，缩短了备份时间。这种备份的优点很明显，同时也存在某些不足之处，即当发生灾难时，恢复数据比较麻烦。 建议在关键性应用系统正常运行维护阶段，针对变化的、不断增加的信息，定期进行增量备份。 3. 差异备份
    每次备份的数据只是相当于上一次完全备份后新增加和修改过的数据， 即采用完全备份和差异备份相结合备份策略。如每周日进行一次完全备份， 而周一至周六进行差异备份。其优点为：没有重复的备份数据，即节省备份介质的空间，缩短了备份时间；缺点为：当发生灾难时，恢复数据比较麻烦。 建议应用系统的正常运行维护阶段，针对不断变化的（变化的内容小于 50％）系统，定期进行差异备份。 4. 按需备份
    按需备份是指在正常的备份安排之外，额外进行的备份操作，这种备份 方式可以弥补冗余管理以及长期转存的日常备份的不足。因此它是一种非常 灵活、重要的备份方式，在应用系统的各个阶段，如果备份的内容较少，可以采用按需备份。
    建议应用系统在下列情况下采取按需备份： - 只需要备份很少的几个文件、目录、数据库或数据库中的表； - 备份服务器上必要的配置文件。 5. 排除备份
    排除备份是指排除不需要的文件后再进行备份。从本质上讲，排除备份不是一种备份方法，只是减少备份冗余的一种方法。
    建议应用系统在下列情况下考虑排除备份： - 有些文件非常大，但并不重要； - 某些文件总是导致备份异常或出错。

    3.5.应用系统的存储设备功能要求

    应用系统存储设备的功能要求应包括如下内容： 1. 存储设备应保证数据的高可用性和完整性要求； 2. 存储设备应具有在多主机环境下工作的能力； 3. 存储设备应能方便地做到快速备份和恢复，重要系统应做到双机备份、支持热插拔； 4. 存储设备应有简便的、功能强大的管理工具，做到对整个存储系统的监视与控制。

    4.应用系统通讯安全设计要求

    1. 应采用安全通信协议对重要数据进行安全传输（尤其是账号、口令信息），如使用SSL/TLS、HTTPS、SFTP和IPSec等安全协议进行通信：
    2. 终端与服务器端之间的WWW服务，建议使用HTTPS安全通信协议；
    3. 终端与服务器端之间的FTP服务，建议使SFTP安全通信协议；
    4. 终端与服务器端之间的Telnet服务，建议使SSH安全通信协议。
    5. 终端应用程序采用加密传输机制对重要信息进行传输。
    6. 终端应用程序采用完整性检查对业务的重要数据或敏感数据进行检查。
    7. 终端应用程序应采用抗抵赖攻击技术对重要的交互信息进行保护。
    8. 终端应用程序使用固定的通信端口。

    5.应用系统数据库安全设计要求

    1. 应从以下方面进行数据库的选型：
    2. 数据库、应用系统的运行环境；
    3. 数据库的稳定性、安全性（多级安全）；
    4. 数据库的容量（最多支持的库的数目、表的数目、记录数目）；
    5. 数据库的存取速度；
    6. 是否支持多种备份方式；
    7. 是否支持数据库的导入和导出。
    8. 应明确数据库相关的用户管理、资源管理、特权管理和角色管理，明确各种用户的资源权限，并建立规范的权限文档。
    9. 数据库原则上应及时更新重要补丁。在安装补丁前应先在测试环境进行，提前进行数据备份，充分准备回退方案和应急预案。
    10. 数据库的配置应符合相应的基线配置要求。
    11. 应及时修改数据库的默认密码或将默认账号锁定、删除。
    12. 数据库的账号应根据业务和维护需要进行合理分配，避免账号共用。

    6.应用系统数据安全设计要求

    6.1.数据采集安全

    应根据数据采集的内容、采集的频率、数据精确度要求、时间特性等来进行数据采集的安全要求设计，数据采集服务器和采集主机应考虑30%的系统开销及冗余。

    6.2.数据传输安全

    1. 应按照数据的类型、数据的重要程度、网络的安全状况等综合因素，对 数据的传输采取不同的安全保护，包括但不限于防火墙、IDS、VPN、病毒防护等安全措施。
    2. 应了解数据传输存在安全隐患的网络或设备，对存在安全隐患的网络采取必要的安全技术，包括但不限于安全通信协议、加密算法、完整性检查算法以及抗抵赖攻击方法等。
    3. 应制定数据传输安全的检查方式，包括但不限于数据传输安全抗主动攻击能力检查、被动抗攻击的能力检查。
    4. 应保障“数据传输安全”有关的重要配置参数安全，包括但不限于口令、加/解密算法、加/解密密钥等。
    5. 应采用安全通信协议对数据进行安全传输，如使用SSL/TLS、HTTPS、 SFTP和IPSec等安全协议进行通信。
    6. 对传输的信息进行不同等级的加密保护，即根据网络或设备的风险、传输内容安全要求的不同，选择不同安全强度的加密算法对信息进行加密传输。建议使用RSA等高强度的密码算法对非常重要的信息（如口令、加密密钥）进行加密传输；对于普通数据的传输，可以采用DES、3DES 等加密算法进行加密传输。
    7. 应防止对所传输数据进行未经授权的任何形式的修改，即对业务的重要数据或敏感数据，建议使用MD5、SHA等算法对数据完整性进行保护。
    8. 对重要的交互信息，建议采取抗抵赖技术，包括但不限于数字签名技术。
    9. 为了配合网络其它安全设备，建议采用基于用户名/口令的认证技术、 VLAN技术、MPLS技术等安全技术手段。

    6.3.数据处理安全

    1. 应根据数据的类型、数据的处理方式、数据的安全性要求、与其它接口 有关的敏感等级、数据相关业务应用的重要性程度来进行数据处理过程的安全性设计。
    2. 应对原始数据进行检错和校验操作，保证原始数据的正确性和完整性。
    3. 数据在转换过程中，应采用通用的标准格式，应考虑相关的不同系统和不同应用的格式需求。
    4. 数据处理过程应提供处理数据的状态信息和数据处理过程的动态信息。
    5. 数据处理过程应具备异常处理功能，在任一环节发现问题，均应能及时回退，必要时可以人工处理。
    6. 数据处理的中间过程和中间结果不能暴露给第三方

    04.代码编写

    05.渗透测试

    一、总则

    • 第一条 为了对信息系统的安全性作深入了解，及时发现信息系统中存在的安全薄弱环节，让技术人员了解当前信息系统的脆弱性和可能造成的影响，以采取必要的防范措施，特制定《渗透测试管理办法》。

    • 第二条 本办法适用于公司所有信息系统。

    • 第三条本办法阅读对象为公司业务主办发及所有技术人员。

    二、公司安全工作组职责分工

    • 第四条公司安全工作组公司安全工作组（以下简称“安全组”）下设渗透测试小组负责协调组织公司信息系统渗透测试具体实施、结果分析、报告提交、整改跟进和结果复测工作；

    • 第五条渗透测试工作涉及本单位的业务主办方、系统运维方、网络运维方、应用运维方和安全管理方。

    • 第六条业务主办方：负责提出新系统上线前业务系统的渗透测试需求，并对渗透结果需要整改的业务影响范围进行评估和确认，跟进整改进度，一般由业务部门人员担。

    • 第七条系统运维方：负责业务应用部署、操作系统和中间件的安装升级（含补丁升级）、安全基线配置、漏洞整改的具体实施，一般由系统运维职能人员担任。

    • 第八条网络运维方：负责业务相关的网络及安全设备的部署、安全基线配置、补丁升级和漏洞整改及漏洞扫描策略配置和调优，一般由网络运维职能人员担任。

    • 第九条应用运维方：负责应用的开发和维护，对应用程序配置和逻辑上的漏洞进行修复，一般由应用开发职能人员担任。

    • 第十条安全管理方：负责信息系统的安全管理，组织实施安全检查、漏洞扫描、渗透测试和落实整改，一般由安全管理职能人员担任。

    三、渗透测试对象

    • 第十一条主机系统安全 针对Windows、Linux、AIX等操作系统进行渗透测试。
    • 第十二条数据库系统安全 针对MySQL、Oracle、MSSQL、Sybase、DB2等数据库应用进行渗透测试。。
    • 第十三条应用系统安全 针对如ASP、JSP、PHP、CGI等组成的Web应用，包括但不限于Web应用系统安全、APP软件安全进行渗透测试。

    四、渗透测试原则和流程

    • 第十四条渗透测试工作以业务系统为单位进行，所有信息系统每季度至少进行一次完整的渗透测试。为减轻渗透测试对信息系统的影响，渗透测试时间须避开业务高峰时段，单次渗透测试持续时间须控制在1天到2天，最长不得超过3天。

    • 第十五条为防止渗透测试造成信息系统的业务中断，在渗透测试中不得使用含有影响业务正常运行的测试手段。

    • 第十六条对于不能接受任何可能风险的信息系统，需搭建与生产环境完全一致的测试环境，包括硬件平台和软件平台（包括但不限于操作系统版本、中间件版本、数据库版本、应用程序版本），再对所搭建的环境进行渗透测试。

    • 第十七条新系统上线前和应用变更上线前必须进行渗透测试（包括黑盒测试及白盒测试），对存在高中危漏洞的系统，须整改完成后方可上线。

    • 第十八条渗透测试工作完成后由安全管理方出具包含漏洞名称、漏洞描述、安全级别、利用方式、修复建议等内容的渗透测试报告。

    五、渗透测试工作的准备、监控和应急

    • 第十九条渗透测试前期准备安全管理方依据信息系统资产台帐信息，制定包含实施办法、实施时间、实施人员、实施范围等要素的详细测试方案，经安全组评审通过后方可开展。

    • 第二十条渗透测试的执行需严格按照通过评审的渗透测试方案定制渗透测试任务，并在既定的时间点开始执行。在渗透测试任务的执行过程中，渗透测试对象所属的安全人员应对渗透测试任务密切监控。

    • 第二十一条渗透测试的风险防范为防止在渗透测试过程中出现的异常情况，所有被测试系统须在被渗透操作之前进行一次完整的系统备份，在渗透测试任务执行过程中，业务主办方、系统运维方和安全管理方对被测试对象进行应急保障。当渗透测试过程中出现与影响性评估不符合的情况时，应根据渗透测试方案立即启动应急措施，消减对被测试对象的影响。

    六、渗透测试后的整改

    • 第二十二条渗透测试结束后安全人员需对渗透测试结果进行分析，并制定整改方案和计划，1个工作日内提供包含漏洞类型、风险级别、修复方法等关键表项的渗透测试报告。

    • 第二十三条报告提交后1个工作日内安全管理方协调业务主办方、系统运维方、应用运维方、网络运维方组织整改交流，并将需整改的漏洞落实到具体责任人，根据整改交流会上确定的整改周期（评估为高危级别以上的漏洞整改时限为1天，中危级别的漏洞整改时限为2天）完成漏洞整改工作，无法整改的漏洞须备注说明，并提供未整改期间防护手段（在漏洞整改完成前需立即提供临时防范手段）。

    • 第二十四条渗透测试结果需由人工对检查出的漏洞进行复核确认，评估漏洞影响性，最终确定系统的风险系数和漏洞的安全级别。

    七、附则

    • 第二十五条本管理办法由技术部负责解释。

    • 第二十六条本办法自颁布之日起实行，有新的修改版本颁布后，本办法自行废止。

    八、附件

    06.上线发布

    1. 概述

    为进一步规范某公司应用系统上下线管理，实现系统建设、运行维护各阶段的平稳过渡和有序衔接，确保系统安全稳定可靠运行，特制定本办法。规范仅供参考。

    2. 使用范围

    本规范中仅供于某公司信息技术部，应用开发部门，运维部门，业务部门参考，系统上线指应用系统在生产环境部署并提供给用户实际使用，包括上线试运行和上线正式运行两个阶段。应用系统的开发阶段、上线试运行阶段、上线正式运行阶段以及系统下线构成其全部生命周期。其中上线试运行阶段又包括上线试运行申请、上线试运行测试、上线试运行和上线试运行验收等环节。

    3. 上线试运行申请

    应用系统开发部门负责向信息技术部申请系统的上线试运行。系统申请上线试运行必须满足以下条件：

    1.应用系统开发部门按照系统需求说明书、系统目标任务书或合同中的规定已完成系统的开发和实施，系统经用户试用并修改完善，已相对稳定，具备有关功能和安全保障措施，经业务部门确认能够满足当前业务需求并在一定程度上适应业务的发展。

    2.应用系统开发部门对系统进行严格的测试，包括系统的功能实现、安全性、性能、可用性、兼容性、集成性等方面，并形成测试报告。测试结果经信息技术部、业务部门、运维部门和相关人员的认可。

    3.应用系统开发部门完成各个层次重点用户的培训工作， 包括系统最终用户和运维部门和相关人员有关人员的培训工作。

    4.应用系统开发部门配合运维部门和相关人员制定详细的上线试运行实施计划、系统备份方案、系统监控方案、安全策略配置方案、应急预案和移交计划等。

    5.应用系统开发部门、 运维部门和相关人员共同检查系统的安装环境，确认满足安装所需的服务器、网络、电源等环境保障条件。

    6.运维部门和相关人员基于安全可靠稳定运行和硬件资源整合利用的原则评估确定系统的安装部署模式。

    4. 上线试运行测试

    4.1. 上线试运行的安装

    运维部门和相关人员负责操作系统和支撑软件系统的安装，包括主机漏洞扫描、安全加固等工作，应用系统开发部门负责上线应用系统软件的安装和整体调试。

    应用系统安装调试完成后，运维部门和相关人员即可组织应用系统开发部门开展系统上线试运行测试，测试应在一个月内完成。在上线试运行测试完成前，不对外提供服务。

    4.2. 上线试运行测试

    测试环境测试主要通过性能测试工具对系统进行压力测试和安全评估，重点考察系统的集成性、健壮性、稳定性、负荷响应能力和安全性等指标，并开展系统应急预案演练，形成相关记录和报告，测试环境应该与生产环境类似。

    生产环境测试主要考察系统在上线正式运行环境中各功能模块的连通性、响应能力、安全性以及对整个应用系统的影响等指标，形成相关记录和报告。生产环境测试，应避免对在线系统产生不利影响，并应制定有关应急预案，采取数据备份措施。

    测试中存在不符合项时，应用系统开发部门提出整改方案，报信息技术部及业务部门审查通过后，按要求限期整改，并再次申请复测。

    4.3. 上线前安全测试

    应该至少对需要上线的应用进行系统安全和应用安全进行安全测试，包括但不仅限于漏洞扫描，渗透测试，代码审计，基线评估；

    对于要对外部开放的应用系统至少应该完成：

    系统漏洞扫描，应用漏洞扫描，渗透测试，基线评估等安全评估；

    对于内部使用的应用系统至少应该完成：

    系统漏洞扫描，应用漏洞扫描（不仅限于以上内容）的安全评估

    所有应用在测试后应进行至少一次复测，保证测试和修复结果的可靠，保障应用稳定，安全，可靠上线。

    5. 上线试运行

    信息技术部和业务部门共同确定系统上线试运行开始时间和上线试运行的期限，原则上上线试运行期为三个月，具体可根据系统的复杂程度不同，按照能够全面检验系统运行质量的原则确定合理的试运行时间。

    系统进入上线试运行后，按照上线正式运行的要求管理，严格执行某公司关于应用系统运行维护及安全管理的有关规定，做好数据的备份，保证系统及用户数据的安全。业务部门负责提出最终用户的权限分配方案。运维部门负责执行和登记。

    上线试运行的初期安排一定时间的观察期。观察期内由应用系统开发部门和运维部门和相关人员共同安排人员进行运行监视、调试、备份和记录，并提交观察期的系统运行报告。在观察期内对系统进行变更时，按照某公司应用系统运行管理规定执行。

    观察期原则上不短于上线试运行期的三分之一，一般为一个月。若观察期内系统连续运行未出现故障，未进行重大变更，满足信息技术部和业务部门相关考核要求，可认为观察期结束；否则重新开始观察期。

    相关业务部门会同系统运维部门和相关人员审核观察期的系统运行报告，确认系统在观察期内运行稳定，报信息技术部审批后，办理上线试运行期间系统运行管理权限的移交手续。移交内容包括应用系统的管理权限分配情况以及有关技术服务支持的联络机制及联络人等。

    系统运行管理权限移交后，系统由运维部门和相关人员负责日常运行管理、监控和系统应用统计，并负责系统和软件产品维护权限的分配和登记。应用系统开发部门负责系统应用程序级的运维技术支持，并配合运维部门和相关人员解决系统运行中出现的有关问题。

    系统上线试运行期间，未发生影响用户使用的故障、未发生因软件缺陷而导致系统停运的重大故障、未进行较大变更等，可认为该系统上线试运行期间稳定运行；否则需待系统整改完善后重新开始上线试运行。

    系统上线试运行期间发生变更的，需对变更部分及相关功能重新按上线试运行申请流程组织上线试运行测试后再安排上线试运行，对涉及系统重大变更的，需对整个系统重新按上线试运行申请流程组织上线试运行测试后，满足要求的重新开始上线试运行。

    系统上线试运行期间稳定运行后，应用系统开发部门需删除临时工作所需的帐号及其它临时措施，组织完成工作报告、技术报告和用户使用报告，并负责办理上线试运行结束和上线试运行验收的申请手续。运维部门和相关人员负责提供系统上线试运行报告，应用系统开发部门配合。

    下级单位的等级保护二级及以上应用系统上线试运行需一个月内报上级信息技术部备案。

    6. 上线试运行验收

    系统上线试运行在具备以下条件后，由应用系统开发部门负责向信息技术部申请系统上线试运行验收。

    系统上线试运行期间连续稳定运行。

    信息技术部、业务部门及运维部门和相关人员应确定系统服务级别，建立保证应用系统正常运行的运行维护管理办法和考核制度，明确系统各级维护管理和应用人员的职责，确保信息的及时、准确、全面和安全。

    应用系统开发部门完成用户应用培训、运行维护培训，配合运维部门和相关人员制定系统备份方案、系统监控方案、安全策略配置方案、应急预案等运行技术文档。

    应用系统开发部门完成系统的全面移交，移交内容包括系统日常维护手册、系统管理员手册、系统培训手册、系统核心参数及端口配置表、系统用户及口令配置表（需含口令修改关联关系）、技术支持服务联系人及联系方式等。

    信息技术部牵头组织验收，成立验收工作组（或验收委员会），成员应由业务部门、系统开发、运行维护的专业人员组成，验收工作组包括技术审查组、生产准备组、文档审查组等专业小组。

    验收工作组按要求对项目相关文档进行全面检查，对系统功能实现、性能、安全性、数据备份与恢复、应急与快速恢复方案等进行测试和核实，并作出验收结论。

    上线试运行验收要严格按照信息化项目管理有关规定，有效规避投运后的各种风险，认真做好项目开发过程中形成的应用软件源代码（包括二次开发源代码）、各类技术文档的移交、保管、存档工作。运维部门和相关人员负责运行文档的接受和系统生命周期内运行文档的管理。

    验收时发现影响系统上线正式运行的重大问题，应责成相关单位立即整改，并延长上线试运行时间，系统完成整改并连续稳定运行一个月后，方可再次申请验收。

    通过应用系统的上线试运行验收是应用系统完成上线试运行转入上线正式运行维护的标志。

    7. 上线正式运行

    通过上线试运行验收后，系统完成建转运工作，该应用系统即为正式在运应用系统，需严格按照某公司应用系统运行维护和安全管理相关规定纳入日常管理。

    运维部门和相关人员负责系统的日常运行维护，除保证系统所需网络和软硬件环境正常外，还应对系统应用情况进行实时监控，做好应用统计，保证系统安全、可靠和稳定运行。

    应用系统开发部门需按合同规定指定专人负责配合运维部门和相关人员开展系统的售后服务和技术支持工作，并具体负责系统的程序代码维护。

    系统的修改、调整、更新、升级等维护操作，须严格执行某公司有关应用系统运行维护的管理规定，履行相关流程和审批制度。相关维护操作应先在测试环境上开展，测试通过后部署到生产环境，不得擅自进行在线调试和修改。

    为保障系统安全，在根据需要安排应用系统开发部门人员进行维护操作时，运维部门和相关人员应安排专人进行监护。维护操作完成后，运维部门和相关人员应及时收回临时分配出的所有权限

    07.应急响应

    什么是应急响应和应急响应体系

    基本概念

    安全事件（Security Accident） 是指影响一个系统正常工作的情况。这里的系统包括主机范畴内的问题，也包括网络范畴内的问题，例如黑客入侵、信息窃取、拒绝服务攻击、网络流量异常等。

    应急响应（Emergency Response） 是指组织为了应对突发/重大信息安全事件的发生所做的准备以及在事件发生后所采取的措施。 应急响应是信息安全防护的最后一道防线！

    应急响应体系（Emergency Response System） 是指在突发/重大信息安全事件后对包括计算机运行在内的业务运行进行维持或恢复的各种技术和管理策略和规程。

    信息安全应急响应体系的制定是一个周而复始、持续改进的过程，包含以下几个阶段：

    • 应急响应需求分析和应急响应策略的确定；
    • 编制应急响应计划文档和技术管理规范；
    • 应急响应计划的测试、培训、演练和维护。

    应急响应目的

    应急响应服务的目的是尽可能地减小和控制住网络安全事件的损失，提供有效的响应和恢复指导，并努力防止安全事件的发生。

    政策要求

    • 《关于加强信息安全保障工作的意见》（中办发『2003』27号文）指出：“信息安全保障工作的要点在于，实行信息安全等级保护制度，建设基于密码技术的网络信任体系，建设信息安全监控体系，重视信息安全应急处理工作，推动信息安全技术研发与产业发展，建设信息安全法制与标准”

    • 国家信息安全战略的近期目标：通过五年的努力，基本建成国家信息安全保障体系。

    • 为了落实27号文精神国家网络与信息安全协调小组办公室于2003年10月发布了《网络与信息安全信息通报暂行办法》、2004年9月发布了

    • 《关于做好重要信息系统灾难备份工作的通知》，2004年8月发布了《关于建立健全基础信息网络和重要信息系统应急协调机制的意见》等文件。这些文件对推动灾难备份和应急响应的发展起到了重要作用。

    相关标准

    • GB/T 24364-2009 《信息安全技术 信息安全应急响应计划规范》
    • GB/T 20988-2007 《信息安全技术 信息系统应急响应规范》
    • GB/Z 20985-2007 《信息技术 安全技术 信息安全事件管理指南》
    • GB/Z 20986-2007 《信息安全技术 信息安全事件分类分级指南》

    应急响应六阶段

    第一阶段：准备——让我们严阵以待

    • 预防为主

    • 微观（一般观点）：

      • 帮助服务对象建立安全政策
      • 帮助服务对象按照安全政策配置安全设备和软件 扫描，风险分析，打补丁 如有条件且得到许可，建立监控设施

    • 宏观：

      • 建立协作体系和应急制度
      • 建立信息沟通渠道和通报机制
        • 电话、即时通讯、email
      • 如有条件，建立数据汇总分析的体系和能力 有关法律法规的制定

    • 制定应急响应计划

    • 资源准备
      • 应急经费筹集
      • 人力资源
        • 指挥调度人员
        • 协作人员
        • 技术人员
        • 专家
        • 设备、系统和服务提供商
      • 硬件设备准备
        • 数据保护设备（磁盘、SAN）
        • 冗余设备 （网络链路、网络设备、关键计算机设备
      • 软件工具准备
        • 备份软件
        • 日志处理软件
        • 系统软件
        • 应急启动盘
        • 病毒、恶意软件查杀软件
        • 等等
      • 现场备份
      • 业务连续性保障
        • 系统容灾
        • 搭建临时业务系统

    第二阶段：确认——对情况综合判断

    • 确定事件性质和处理人
    • 微观（负责具体网络的CERT）：
      • 确定事件的责任人：指定一个责任人全权处理，事件，给予必要的资源
      • 确定事件的性质： 误会？玩笑？还是恶意的攻击/入侵？ 影响的严重程度， 预计采用什么样的专用资源来修复？

    • 宏观（负责总体网络的CERT）：

      • 通过汇总，确定是否发生了全网的大规模事件
      • 确定应急等级，以决定启动哪一级应急方案

    • 事故的标志（征兆和预兆）

      • Web服务器崩溃
      • 用户抱怨主机连接网络速度过慢
      • 子邮件管理员可以看到大批的反弹电子邮件与可疑内容
      • 网络管理员通告了一个不寻常的偏离典型的网络流量流向

    • 来源

      • 网络和主机IDS 、防病毒软件、文件完整性检查软件
      • 系统、网络、蜜罐日志
      • 公开可利用的信息
      • 第三方监视服务

    • 确认事故

      • 确认网络和系统轮廓： 分析事故的最好技术方法之一
      • 理解正常的行为： 基于处理事故的良好准备
      • 使用集中的日志管理并创建日志保留策略
      • 执行事件关联
      • 保持所有主机时钟同步
      • 维护和使用信息知识库： 分析事故时的快速参考
      • 使用互联网搜索引擎进行研究
      • 运行包嗅探器以搜集更多的数据
      • 过滤数据
      • 经验是不可替代的
      • 建立诊断矩阵
      • 寻求帮助

    诊断矩阵实例

    征兆拒绝服务恶意代码非授权访问不正确使用
    文件，关键，访问尝试 低 中 高 低
    文件，不适当的内容 低 中 低 高
    主机崩溃 中 中 中 低
    端口扫码，输入的，
    不正常的    		 高 低 中 低
    端口扫码，输出的，
    不正常的    		 低 高 中 低
    利用带宽高 高 中 低 中
    利用电子邮件 中 高 中 中
    • 事故优先级- 服务水平协议
      • 服务水平协议（SLA ）：

    定义服务目标及双方的预期及责任 - 服务水平协议指标 - 远程应急响应服务 在确认客户的应急响应请求后? 小时内，交与相关应急响应人员进行处理。无论是否解决，进行处理的当天必须返回响应情况的简报，直到此次响应服务结束。 - 本地应急响应服务 对本地范围内的客户，？小时内到达现场；对异地的客户，？小时加路途时间内到达现场。

    应急响应 SLA矩阵

    事故当前或将来可
    能的影响    		高（例如：互联网
    连接，公共Web服
    务器，防火墙，客
    户数据）    		中（例如：系统管
    理员工作站，文件和
    打印服务器，XYZ 
    应用数据）    		低（例如：用户工
    作站）
    ROOT级访问 15min 30min 1h
    非授权的数据修改 15min 30min 2h
    对敏感信息的非
    授权访问    		 15min 1h 1h
    非授权的用户级访问 30min 2h 4h
    服务不可用 30min 2h 4h
    骚扰 30min 不限 不限

    第三阶段：遏制——制止事态的扩大

    • 即时采取的行动
    • 微观：
      • 防止进一步的损失，确定后果
      • 初步分析，重点是确定适当的封锁方法
      • 咨询安全政策
      • 确定进一步操作的风险
      • 损失最小化（最快最简单的方式恢复系统的基本功能，例如备机启动）
      • 可列出若干选项，讲明各自的风险，由服务对象选择

    • 宏观：

      • 确保封锁方法对各网业务影响最小
      • 通过协调争取各网一致行动，实施隔离
      • 汇总数据，估算损失和隔离效果

    • 建议组织机构为几类主要的事故建立单独的遏制策略，其标准包括：

      • 潜在的破坏和资源的窃取
      • 证据保留的需要
      • 服务可用性（例如：网络连接，提供给外部当事方的服务）
      • 实施战略需要的时间和资源
      • 战略的有效性（例如：部分遏制事故，完全遏制事故）
      • 解决方案的期限（例如：紧急事故工作区需在4 小时内清除，临时工作区需在两周内清除，永久的解决方案）。

    第四阶段：根除——彻底的补救措施

    • 长期的补救措施
    • 微观：
      • 详细分析，确定原因，定义征兆
      • 分析漏洞
      • 加强防范
      • 消除原因
      • 修改安全政策
    • 宏观：
      • 加强宣传，公布危害性和解决办法，呼吁用户解决终端的问题；
      • 加强检测工作，发现和清理行业与重点部门的问题

    第五阶段：恢复——系统恢复常态

    • 微观：
      • 被攻击的系统恢复正常的工作状态
      • 作一个新的备份
      • 把所有安全上的变更作备份
      • 服务重新上线
      • 持续监控
    • 宏观：
      • 持续汇总分析，了解各网的运行情况
      • 根据各网的运行情况判断隔离措施的有效性
      • 通过汇总分析的结果判断仍然受影响的终端的规模
      • 发现重要用户及时通报解决
      • 适当的时候解除封锁措施

    第六阶段：跟踪——还会有第二次吗

    • 关注系统恢复以后的安全状况，特别是曾经出问题的地方
    • 建立跟踪文档，规范记录跟踪结果
    • 对响应效果给出评估
    • 对进入司法程序的事件，进行进一步的调查，打击违法犯罪活动
    • 事件的归档与统计
      • 处理人
      • 时间和时段
      • 地点
      • 工作量
      • 事件的类型
      • 对事件的处置情况
      • 代价
      • 细节

    应急预案的编制和管理

    应急响应预案的制定

    • 制定应急响应预案的原则

      • 首先，必须集中管理应急响应预案的版本和发布。
      • 其次，为了建立有效的版本控制体系，必须建立规范的应急响应预案的问题提交、解决、更新、跟踪、发布的渠道和流程。
      • 第三，建立相关的保密管理规定，保证应急响应预案中涉及的秘密信息得到保护。
      • 第四，应急响应预案在内容管理方面应注意内容的分布和粒度，可根据版本和内容的更新频度将应急响应的内容进行适当的分布。
      • 第五，建立合理的应急响应预案的保管制度，强调存放的安全性和易取得性。

    • 成功预案的特点

      • 清楚、简洁
      • 高级管理层支持/组织承诺
      • 不断改进和更新的恢复策略
      • 及时的更新维护
      • 组织职责分工明确
      • 保留、备份和异地存储计划
      • 完整记录并定期演练
      • 风险得到管理
      • 弱点得到优先重视
      • 灵活、可适应

    应急响应预案的教育、培训和演练

    • 在灾难来临前使相关人员了解熟悉恢复流程
    • 使应急响应预案得到理解并可以使用
    • 促进应急响应预案活动、更新、实用
    • 展示恢复的能力
    • 达到法律和内部审计要求

    演练与演习的类型

    • 演练和演习的主要方式有：
      • 桌面演练；
      • 模拟演练；
      • 实战演练等
    • 根据演练和演习的深度，可分为：
      • 系统级演练；
      • 应用级演练；
      • 业务级演练等
    • 根据演练和演习的准备情况，可分为：
      • 计划内的演练和演习；
      • 计划外的演练和演习等

    预案维护管理

    • 核对预案的功能性
    • 验证预案文档的精确性和完整性
    • 分发更新的文档
      • 文档计划分发和发布流程
      • 确保相关的团队收到更新的文档
    • 依靠维护来改变管理流程
    • 提供培训作为持续维护预案的一部分
      • 为与应急响应的相关人员开展定期培训，如：复习进修课程或灾难备份研讨会
      • 指派培训责任，如：部门经理要确保员工被送去参加培训
    • 完成时报告预案维护情况
    • 毁掉旧应急响应预案的复印件或电子版本

    预案变更管理

    • 业务操作的增长或变化
      • 如：新的分支、产品和业务功能的增加
    • 公司所有权的变化
    • 关键人员的变化
    • 硬件配置的变化
    • 使用新操作系统
    • 预案审核和演练后
    • 软件/应用软件的变化
    • 新的法律或审计要求
    • 定期审核和更新——如：每年两次
    • 《应急预案管理制度》
    • 应急预案变更记录

    应急响应体系建立流程

    应急响应计划编制

    信息安全应急响应计划编制方法

    总则

    • 编制目的
    • 编制依据
    • 适应范围
    • 工作原则

    角色及职责

    • 应急响应领导小组
    • 应急响应技术保障小组
    • 应急响应专家小组
    • 应急响应实施小组
    • 应急响应日常运行小组

    预防和预警机制

    检测、 预测、 预警，做到 早发现、早报告、早处置

    应急响应流程

    应急响应流程

    • 事件通告
    • 信息通报


    信息通报分为组织内信息通报和组织外信息通报两部分。组织内信息通报的目的是在信息安全事件发生后迅速通知应急响应日常运行小组，并根据评估结果迅速通知所有相关人员，从而快速有序的实施应急响应计划。组织外信息通报目的是将相关信息及时通报给受到负面影响的外部机构、互联的单位系统以及重要用户，同时根据应急响应的需要，应将相关信息准确通报给相关设备设施及服务提供商（包括电信、电力等）等外部组织，以获得适当的应急响应支持。值得注意的是对外信息通报应符合组织的对外信息发布策略。

    1. 信息上报


    信息安全事件发生后，应按照相关规定和要求，及时将情况上报相关主管或监管单位/部门。

    1. 信息披露


    信息发布的目的是避免信息安全事件影响被误传，同时规范组织内人员信息披露，保证信息的一致性。因此，信息安全事件发生后，应根据信息安全事件的严重程度，指定特定的小组及时向新闻媒体发布相关信息，并且指定的小组应严格按照组织相关规定和要求对外发布信息，同时组织内其它部门或者个人不得随意接受新闻媒体采访或对外发表自己的看法。

    • 应急响应流程-呼叫树

    应急响应流程-呼叫树

    小组名称 姓名 在小组中职位 联络信息
    工作电话 家庭电话 手机 电子邮件 家庭住址
                   
                   
                   
                   
                   
    • 信息上报
    重大信息安全事件报告表
    报告时间： x 年x 月x 日x 时x 分
    单位名称： 报告人：
    联系电话： 通讯地址：
    传真： 电子邮件：
    发生重大信息安全事件的信息系统名称及用途：
    负责部门： 负责人：
    重大信息安全事件的简要描述（如以前出现过类似情况也应加以说明）：
    初步判定的事故原因：
    当前采取的措施：
    本次重大信息安全事件的初步影响状况：
    影响范围： 严重程度：
    值班电话： 传真：
    • 事件分类与定级

    要确定信息安全事件后如何实施应急响应计划，对系统损害性质和程度的评估是非常重要的。这个损害评估应该在能够确保人员安全这个最优先任务的前提下尽快完成。所以，如果可能，应急响应日常运行小组是第一个得到事件通知的小组。损害评估规程对于不同的系统是不同的，但是应该涉及到以下领域： 1. 造成紧急情况或中断的原因； 1. 潜在的附加中断或损失； 1. 受到紧急情况影响的区域； 1. 物理构架（如计算机室结构的完整性、电源、电信以及制热、通风和空调的情况）的状况； 1. 系统设备的总量和功能状态（如具备完整功能、具备部分功能或丧失功能）； 1. 系统设备及其存货的损失类型（如水害、水灾或热能、物理以及电涌影响）； 1. 被更换的项目（如硬件、软件、固件或支持材料）； 1. 估计恢复正常服务所需的时间。

    • 我国信息安全事件分类方法

    GB/Z 20986-2007《信息安全事件分级分类指南》 - 有害程序事件MI - 网络攻击事件NAI - 信息破坏事件IDI - 信息内容安全事件ICSI - 设备设施故障FF - 灾害性事件DI - 其他信息安全事件OI - 分级要素 - 系统损失 - 信息系统重要程度 - 社会影响

    特别重大事件(I级）

    特别重大事件是指能够导致特别严重影响或破坏的信息安全事件，包括以下情况：  - 会使特别重要信息系统遭受特别严重的系统损失   - 产生特别重大的社会影响 

    重大事件(II级）

    重大事件是指能够导致严重影响或破坏的信息安全事件，包括以下情况：  - 会使特别重要信息系统遭受严重的系统损失、或使重要信息系统遭受特别严重- 的系统损失 - 产生重大的社会影响

    较大事件(III级）

    较大事件是指能够导致严重影响或破坏的信息安全事件，包括以下情况： - 会使特别重要信息系统遭受较大的系统损失、或使重要信息系统遭受严重的系统损失，一般信息系统遭受特别严重的系统损失 - 产生较大的社会影响

    一般事件(IV级）

    一般事件是指不满足以上条件的信息安全事件，包括以下情况：  - 会使特别重要信息系统遭受较小的系统损失、或使重要信息系统遭受较大的系统损失，一般信息系统遭受严重或严重以下级别的系统损失 - 产生一般的社会影响

    应急启动

    • 启动原则——快速、有序；
    • 启动依据——一般而言，对于导致业务中断、系统宕机、网络瘫痪等突发/重大信息安全事件应立即启动应急。但由于组织规模、构成、性质等的不同，不同组织对突发/重大信息安全事件的定义可能不一样，因此，各组织的应急启动条件可能各不相同。启动条件可以基于以下方面考虑：人员的安全和/或设施损失的程度；系统损失的程度（如物理的、运作的或成本的）；系统对于组织使命的影响程度（如保护资产的关键基础设施）；预期的中断持续时间等。只有当损害评估的结果显示一个或多个系统启动条件被满足时，应急响应计划才应被启动。
    • 启动方法——由应急响应领导小组发布应急响应启动令。

    应急处置

    • 恢复顺序
      当恢复复杂系统时，恢复进程应该反映出BIA中确定的系统优先顺序。恢复的顺序应该反映出系统允许的中断时间，以避免对相关系统及其应用的重大影响。
    • 恢复规程
      为了进行恢复操作，应急响应计划应提供恢复业务能力的详细规程。规程应被设定给适当的恢复小组并且通常涉及到以下行动：
      1. 获得访问受损设施和／或地理区域的授权；
      2. 通知相关系统的内部和外部业务伙伴；
      3. 获得所需的办公用品和工作空间；
      4. 获得安装所需的硬件部件；
      5. 获得装载备份介质；
      6. 恢复关键操作系统和应用软件；
      7. 恢复系统数据；
      8. 成功运行备用设备。

    后期处置

    • 信息系统重建
      在应急处置工作结束后，要迅速采取措施，抓紧组织抢修受损的基础设施，减少损失，尽快恢复正常工作。 通过统计各种数据，查明原因，对信息安全事件造成的损失和影响以及恢复重建能力进行分析评估，认真制定恢复重建计划，迅速组织实施信息系统重建。
    • 应急响应总结
      应急响应总结是应急处置之后应进行的工作，具体工作包括：
      1. 分析和总结事件发生原因；
      2. 分析和总结事件现象；
      3. 评估系统的损害程度；
      4. 评估事件导致的损失；
      5. 分析和总结应急处置记录；
      6. 评审应急响应措施的效果和效率，并提出改进建议；
      7. 评审应急响应计划的效果和效率，并提出改进建议。

    信息安全事件应急响应总结模板

    信息安全事件应急响应结果报告表
    原事件报告时间： x 年x 月x 日x 时x 分
    备案编号： x 年x 月x 日x 第 x 号
    单位名称： 报告人：
    联系电话： 通讯地址：
    信息系统名称及用途：
    已采用的安全措施：
    信息安全事件的补充描述及最后判定的事故原因：
    本次信息安全事件的初步影响状况：
    事后结果： 影响范围：
    严重程度：
    本次信息安全事件的主要处理过程及结果：
    针对此类信息安全事件应采取的保障信息系统安全的措施和建议：
    报告人签名：

    应急响应保障措施

    • 人力保障

      • 管理人力
      • 技术人力

    • 物质保障

      • 财力
      • 交通运输
      • 通信

    • 技术保障

      • 应急响应技术支持
      • 事件监控与预警
      • 应急技术储备

    附件

    • 具体的组织体系结构及人员职责
    • 应急响应计划各小组成员的联络信息
    • 供应商联络信息，包括离站存储和备用站点的外部联系点
    • 系统恢复或处理的标准操作规程和检查列表
    • 支持系统运行所需的硬件、软件、固件和其它资源的设备和系统需求清单
    • 供应商服务水平协议（SLA）、与其它机构的互惠协议和其它关键记录
    • 备用站点的描述和说明
    • 在计划制定前进行的BIA，包含关于系统各部分相互关系、风险、优先级别等
    • 应急响应计划文档的保存和分发方法

    应急响应工作机构图

    应急响应工作机构图

    职责示例

    应急响应领导小组：<b1. 应急响应领导小组是信息安全应急响应工作的组织领导机构，组长应由组织最高管理层成员担任。领导小组的职责是领导和决策信息安全应急响应的重大事宜，主要如下： 1. 对应急响应工作的承诺和支持，包括发布正式文件、提供必要资源（人财物）等； 1. 审核并批准应急响应策略； 1. 审核并批准应急响应计划； 1. 批准和监督应急响应计划的执行； （1. 启动定期评审、修订应急响应计划； 1. 负责组织的外部协作工作。

    应急响应组（IRT ）

    • 什么是应急响应组（IRT ）
      • 应急响应组就是机构可以借助的网络安全专业组织。
    • 为什么需要成立应急响应组
      • 容易协调响应工作
      • 提高专业知识
      • 提高效率
      • 提高先期主动防御能力
      • 更加适合于满足机构的需要
      • 提高联络功能
      • 提高处理制度障碍方面的能力

    从应急组织到应急体系：信息安全保障的必要条件

    • 现实表明，单一的应急组织已经不能应对当今的网络安全威胁，我国的应急体系正是在实际工作的经验总结中逐渐形成的：平台从点到环到面；应急体系从点到树到网
    • “现实世界中发生的任何事情，在网络世界中都可以找到与之对 应的事件”
    • SARS 事件反映出社会防疫应急体系的重要
    • 红色代码、尼姆达、SQL 杀手、口令蠕虫等具有和现实世界中的疫病相同的特点
    • 处理方式也具有同样的特点：隔离--- 分析--- 治疗
    • 不同之处：“病人”不自知；隔离缺乏法律依据或技术手段；应
    • 急缺乏成熟体系和工作制度…. .

    国际信息安全应急响应组织

    • 美国计算机紧急事件响应小组协调中心 （Computer Emergency Response Team/Coordination Center, CERT/CC）
    • 事件响应与安全组织论坛（Forum of Incident Response and Security Teams, FIRST）  
    • 亚太地区计算机应急响应组（Asia Pacific Computer Emergency Response Team, APCERT） 
    • 欧洲计算机网络研究教育协会（Trans-European Research and Education Networking Association, TERENA) 
    • 国家计算机网络应急技术处理协调中心 （National Computer network Emergency Response technical Team/Coordination Center of China, CNCERT/CC）
    • 中国教育和科研计算机网紧急响应组(China Education and Research Network Computer Emergency Response Team, CCERT)   
    • 国家计算机病毒应急处理中心 
    • 国家计算机网络入侵防范中心
    • 国家863计划反计算机入侵和防病毒研究中心

    信息系统应急计划一般过程

    • 美国SP800-34 信息技术系统应急计划/预案指南：七步走
      • 第一步：制定应急计划/预案策略条款
      • 第二步：进行业务影响分析
      • 第三步：确定防御性控制
      • 第四步：制定恢复策略
      • 第五步：IT应急计划/预案的制定
      • 第六步：计划/预案的测试、培训和演习
      • 第七步：计划/预案的维护

    七步走

    转自：https://www.securitypaper.org
  • 相关阅读:
    STDMETHOD (转)
    DirectX中的纹理映射相关技术 （转）
    (转)清空std::stringstream，联系到stream的clear()和清空
    （转载）MultiAnimation
    （转）SkyBox
    [转载]漫谈游戏中的阴影技术
    反射矩阵计算
    (转)COM组件里的AddRef（）
    LINQ简记（2）：重要概念
    继续聊WPF——自定义命令
  • 原文地址：https://www.cnblogs.com/suanguade/p/15531465.html
Copyright © 2020-2023  润新知