XX_133_BCP_事件处理流程_系统.doc

文档编号 XX_113_BCP_事件处理流程_系统 版 本 号 V1.0 密 级 内部公开 事件处理流程_系统 XXX信息技术有限公司 XXX信息技术有限公司（XXX）www.XXX.com 电话：+86-10-59017500 - II - 北京市朝阳区朝外大街甲6号万通中心D座10层  100020 传真：+86-10-59017300 版本控制 编号 修订人 修订时间 版本号 修订内容说明 2 3 目录 1 引言 4 1.1 编写目的 4 1.2 参考资料 4 1.3 术语定义 4 2 相关部门人员和职责 4 3 总体指引 5 4 制定恢复计划 6 5 应急计划的实施 6 6 应急计划培训、规划和演习 6 7 应急计划修改以及评审 7 8 详细应急计划 7 8.1 紧急事件通告 8 8.1.1 银行系统问题的通告 8 8.1.2 系统故障通告 10 8.1.3 交易和应用类故障通告 12 8.1.4 运营后台故障通告 13 8.2 病毒事件处理流程 15 8.3 重大漏洞事件处理流程 16 8.4 黑客攻击事件应急预案 16 8.5人为破坏重要系统的事件应急预案 16 8.6 重大攻击事件处理流程 17 8.7 攻击事件处理流程 18 8.8 机密信息泄露处理流程 18 8.9 无线设备处理流程： 19 8.10支付卡事件处理过程 20 8.10.1处理方法说明 21 8.10.2商家报案操作流程 22 8.10.3持卡人报案操作流程 22 8.10.4银行提出交易查询的操作流程 23 8.10.5公安机关要求查询的操作流程 24 8.10.6新闻媒体要求调查的操作流程 25 1 引言 1.1 编写目的 本文档为XXX信息安全管理制度中的应急响应计划部分。 主要读者为：产品部；研发部；测试部；IT部；客户服务部；系统部；财务部。 1.2 参考资料 《设计和开发安全策略》。 《卡信息保护策略》。 《访问控制安全策略》。 《网络安全策略》。 《防病毒管理策略》。 《介质安全管理策略》。 《日志安全策略》。 《应急响应计划》。 1.3 术语定义 略。 2 相关部门人员和职责 第一条 系统部负责组织编写并推广本程序； 第二条 系统部负责具体落实本程序的控制要求和措施； 第三条 风险总监负责对本程序的执行情况进行审核； 第四条 网络负责角色: 负责网络基础设施和物理安全的业务连续性支持工作。 第五条 软件负责角色：负责应用系统平台的业务连续性支持工作。（包括硬件环境、操作系统环境、数据库环境的保障工作） 第六条 全体员工: 遵守本程序规定的内容。 3 总体指引 第七条 根据各个业务特点和事件分类，结合业务影响性分析（BIA）的情况，须分别制订相应的应急计划。 第八条 应急响应计划内容 n 应急响应计划通讯策略及职责说明 Ø 系统部相关的值班人员7×24负责处理应急响应，并监控任何未授权活动、未授权无线访问、重要的IDS事件，以及重要系统或内容文件的未授权的变更等。 Ø 系统漏洞发现后，系统部通知系统部主管和风险部门。 Ø 系统部主管根据系统漏洞具体情况，如果严重则上报通知CISO和风险合规部。 Ø CISO根据系统漏洞具体情况，如果涉及卡信息泄漏等情况，则通知相关收单机构以及信用卡组织。 Ø CISO根据系统漏洞具体情况以及相关法律规定，如有需要，则通知相关法务人员分析其影响。 n 应急响应计划覆盖范围 Ø 应急响应计划包括电子支付系统所有涉及的网络，硬件，数据库，操作系统，应用软件等系统组件。 Ø 系统漏洞报警的方式包括：系统软件监控报警；客户服务部门监控报警；客户服务部门接收的其他人员提醒和报警。 n 应急响应以及恢复流程 Ø 如系统漏洞需通知相关收单机构以及信用卡组织，则遵循收单机构以及信用卡组织的应急响应流程。 Ø 技术支持部门与IT部门经理根据系统漏洞具体情况，备份各项系统日志。 Ø 如涉及数据库，则备份当前数据库内容。 Ø 如涉及应用软件，则备份当前应用软件。 Ø 技术支持部门与IT部门经理根据系统漏洞类型，进行漏洞修补工作。 Ø 技术支持部门与IT部门经理根据具体情况恢复系统。 4 制定恢复计划 第九条 由信息安全管理组织管理制定恢复计划。在制定了详细的应急计划和对安全事件进行分级的基础上，根据业务的恢复需求，如 BIA、RPO、RTO等关键因素，制定恢复计划。在恢复计划中必须明确以下相关内容： n 根据资产的分类分级，明确业务系统的重要等级 n 不同安全事件对RTO、RPO、BIA的不同需求 n 根据不同需求制定不同的恢复方案。 n 明确执行恢复的人员。 5 应急计划的实施 第十条 当紧急情况和中断发生时，一旦符合应急计划的启动条件，应严格按照计划规定来行动。 第十一条 没有按照规定操作且给东莞局造成损失的部门或个人将按规定进行处罚。 第十二条 在应急计划执行过程，需及时保存操作过程记录。 6 应急计划培训、规划和演习 第十三条 所有应急计划在制订或修订完成后，都必须进行测试，并根据测试结果修订应急计划；保证应急计划的可行性；至少每年测试一次应急计划。 第十四条 计划测试的主要活动包括： n 制定测试的策略，建立测试项目，确定测试需求 n 确定测试方式（结构化检查、检查列表、模拟、并行、完全中断），制定现实的情景 n 确定测试评估标准和记录发现 n 确定测试时间进度 n 准备测试计划 n 执行测试 n 识别测试后的反馈并制作测试报告 第十五条 至少每年举办一次针对应急计划职责的培训作为对计划测试的补充。应急计划培训的最终目标应该是使得相关员工能够无需实际文档的协助就能够执行相应的恢复规程。接受应急响应计划培训的人员包括负责响应安全漏洞的员工。应急计划人员应该得到以下计划要素的培训： n 计划的目的 n 团队之间的协调与沟通 n 汇报规程 n 安全需求 n 团队特有的处理过程 n 个人职责 第十六条 至少每半年进行一次全面的计划演习。 7 应急计划修改以及评审 第十七条 建立计划的维护方案和时间进度，定期或由特定事件触发对应急响应的复审（如测试、变更及真正实施了应急响应等），包括但不限于下列事件： n 每年定期修改评审应急响应计划。 n 结合本公司或行业已有教训或行业发展情况，不定期修改评审应急响应计划。 n 当购买新设备或操作系统升级后要对计划重新评审 n 当整体经营战略发生变化时要对计划重新评审 n 当场所、设施和资源发生变化时要对计划重新评审 n 当法律法规变化时要对计划重新评审 n 当关键的业务流程改变时要对计划重新评审 n 建立计划的变更控制过程，并融入整体变更管理流程当中。 8 详细应急计划 基于XXX的业务特点，应急响应将重点关注于事件通告、安全事件和业务安全等三个方面。其中，安全事件将基于公司互联网业务的特点，对病毒、攻击、入侵事件和泄密行为进行展开。 详细应急计划如下： 8.1 紧急事件通告 根据以往的系统运营经验，系统在运行过程中会出现突发性的故障，这些故障包括：XXX主页无法正常的登录、XXX商户或个人无法正常登录后台、用户无法使用XXX平台成功支付(非银行或用户原因)等。 出现系统故障，通常客服的消息来源有：技术部主动告知、商户或用户投诉、客服测试或公司内部员工发现。 客服人员一旦得到消息，先要证实这些情况属实，然后客服人员迅速启动客服通知机制，具体办法如下： 8.1.1 银行系统问题的通告 现象： 1） 银行监控系统报警 2） 经测试，某银行无法正常链接 通知流程： 1、 3分钟内在XXX首页测试，并登陆竞争对手网站选择相同银行测试 2、 根据测试情况确定问题来源，5分钟内通知实施人解决，同时邮件和短信通知四条产品线总经理及相关人员、本部门主管以及其他相关人员 3、 故障恢复后5分钟内，邮件和短信通知上述所有故障知晓人员（夜间发短信） 4、 客服班长将故障详情记录在《故障记录表》中备案，并在周报中予以反馈 控制要求： 1、 若判断故障为我司接口问题，实施解决人为李均柠；若为银行问题，实施解决人为池海玲 2、 若为晚17：00-次日9：00期间，或节假日银行故障，因银行休息时间无法联系，故池海玲无法做出响应，邮件报送名单中加入池海岭，以便工作日时核实。 3、 5分钟内必须保证在测试竞争对手后完成故障通知过程，遇到故障进度可通过后续邮件进行反馈 4、 若遇到接口人无法联系上的情况，按照现有流程5分钟内发送通知邮件，邮件中注明：目前接口人XXX联系不上，客服人员正在继续联络，请大家知晓！ 5、 若故障银行为银联银行，可通过测试竞争对手的银联银行来确定问题来源 6、 夜间22：00以后的银行故障不做短信通知，只发邮件通知 通知模板： 1、 邮件 1) 故障时： 邮件主题：XX时XX分，XX银行无法正常链接，XX查询中，请知晓！ 大家好！    客服于XX月XX日XX时XX分，接到用户咨询XX银行无法交易，经测试公司一分钱支付也交易不成功，测试竞争对手快钱（或者支付宝）可以\不可以交易，联系XX处理中，请各位知晓！      XXX客服XX号   2) 恢复时： 邮件主题：XX时XX分，XX银行恢复正常，请知晓！ 大家好！      客服于XX月XX日XX时XX分反馈：接到用户咨询**银行无法交易问题，已于XX月XX日XX时恢复，请各位知晓！            XXX客服XX号   主送人： 抄送人： 2、 短信 发送人： 8.1.2 系统故障通告 现象： 1、 首页无法登陆 2、 XXX商户或会员登录后台提示“无法显示该页” 3、 部分地区用户描述访问不了首页或登陆后台提示“无法显示该页” 通知流程： 1、 客服通过测试访问首页或登陆后台，判断问题来源，若测试正常，建议用户清楚缓存再试 2、 若能重现错误，5分钟内联系系统组柴栋（第二联系人：刘刚）解决，同时邮件发送至例会群组，（夜间发短信） 3、 故障恢复后5分钟内，邮件或短信通知上述所有故障知晓人员 4、 客服班长将故障详情记录在《故障记录表》中备案，并在周报中予以反馈 控制要求： 1、 必须在故障发生5分钟之内发出通知邮件或短信，若接口人联系不上，先行发送邮件通知大家，再继续跟进并反馈跟进结果 2、 若为部分地区无法访问首页，需要提供地区名称及IP地址反馈给系统组 通知模板： 1、 邮件： 1） 故障时 大家好！    客服于XX月XX日XX时XX分，接到用户投诉首页无法登陆/登陆会员/商家系统提示“该页无法显示”，经测试能够重现错误，现联系系统组XX处理中，请各位知晓！      XXX客服XX号 2） 恢复时 大家好！      客服于XX月XX日XX时XX分反馈：接到用户投诉首页无法登陆/登陆会员/商家系统提示“该页无法显示”问题，已于XX月XX日XX时恢复，请各位知晓！            XXX客服XX号 主送人： 抄送人： 2、 短信 发送人： 8.1.3 交易和应用类故障通告 现象： 1、 登陆商家或会员后台，系统返回错误提示 2、 链接银行时报错：系统故障，无法提交支付，交易中断 通知流程： 1、 将系统问题描述清楚，并提供相应错误页面截图，反馈给李均柠（第二联系人张礼文） 2、 故障发送5分钟内邮件发送例会组（夜间发短信），并抄送客服组 3、 故障恢复后5分钟内，邮件通知上述所有故障知晓人员（夜间发短信） 4、 客服班长将故障详情记录在《故障记录表》中备案，并在周报中予以反馈 邮件模板： 1、 通知： 大家好！    客服于XX月XX日XX时XX分，接到用户投诉登陆会员/商家系统报错/银行卡业务支付不成功，经测试能够/不能够重现错误，现联系技术部门李均柠处理中，请各位知晓！      XXX客服XX号 2、 工作日反馈给技术： XX，您好！    客服于XX月XX日XX时XX分，接到用户投诉登陆会员/商家系统报错/银行卡业务支付不成功，经测试能够/不能够重现错误，具体信息如下，请协助处理，并尽快回复，谢谢！ 商户/会员编号： 遇到问题描述： 另：错误截图请见附件！ 主送人： 抄送人： 8.1.4 运营后台故障通告 现象： 1、 运营后台无法正常登录 2、 运营后台使用功能报错 通知流程： 1、 后台无法登陆，3分钟内联系应用运营中心测试判断是网络问题还是系统问题 2、 若为系统问题，5分钟内联系系统部柴栋（第二处理人刘刚）处理 3、 后台某功能使用报错，5分钟内联系技术部李均柠处理 4、 10分钟内无法登陆的故障或某功能故障无法使用，导致业务无法正常运行或无法正常提供服务，邮件和短信通知4条产品线相关人员 5、 故障恢复后5分钟内，邮件通知上述所有故障知晓人员（夜间发短信） 6、 客服班长将故障详情记录在《故障记录表》中备案，并在周报中予以反馈 邮件模板： 1、 邮件： 1）后台无法登陆 大家好！    XX月XX日XX时XX分起，XX后台无法正常登陆，现联系系统部XXX处理中，请各位知晓！      XXX客服XXX号 2）后台功能无法使用造成业务受影响 大家好！    XX月XX日XX时XX分起，XX后台的XX功能无法使用，造成XXX工作无法正常进行，现联系技术部XXX处理中，请各位知晓！ XXX客服XXX号      XXX客服XXX号 3）恢复 大家好！    客服于XX日XX时XX分反馈问题---XX后台无法正常登录/XX后台的XX功能无法使用，现已于XX时XX分解决，请各位知晓！ XXX客服XXX号      XXX客服XXX号 主送人： 2、 抄送人： 发送人： 备注： 1、 任何系统故障一定要在规定时间联系到相关人员。如果联系不上，先行按照要求按时通知，待逐级向上联系到相关人员后，再及时反馈处理进度。 2、 以上任何故障，与数据库有关的直接联系柴栋或刘刚，与后台有关的直接联系李均柠或张礼文。任何故障都要报给贾宇飞、吴丽华知道。 8.2 病毒事件处理流程 1、明确并报告病毒事件的影响和范围。 2、在必要的情况下切断病毒事件的源头。 3、制定病毒的解决方案。解决方案的制定包括但不限于： Ø 从外部获得病毒定义和病毒引擎更新； Ø 从外部获取专门的工具； Ø 对脆弱系统组件的加固与更新； Ø 限制病毒传播的范围和条件。 4、实施相应的解决方案。 5、针对相关的脆弱组件进行整体加固。 6、验证病毒事件已解决，类似的问题不会发生。 8.3 重大漏洞事件处理流程 1 通过漏洞信息收集发现重大系统和应用漏洞时， 管理人员应立即通告安全管理小组，由其对漏洞的潜在影响和当前措施进行评估，并报告信息安全事件处理小组和经济信息中心。 2 必要时，网络室评估漏洞对现有业务系统产生的影响，并上报至信息安全事件处理小组。 3 信息安全事件处理小组基于评估结果进行处理。处理措施包括但不限于：通告相关人员、修复漏洞、断开网络和系统等。 4 事态或后果严重的，信息安全事件处理小组应及时报告相关领导。 5 处置结束后 , 网络室应将事发经过、造成影响、处置结果在修复工作结束后一日内书面报告信息系统事件处理小组 。 8.4 黑客攻击事件应急预案 1、 当发现网络被非法入侵、网页内容被篡改，应用服务器上的数据被非法拷贝、修改、删除，或通过入侵检测系统发现有黑客正在进行攻击时，使用者或管理者应断开网络，并立即报告信息系统事件应急领导小组。 2、 接报告后，信息系统事件应急领导小组应立即指令经济信息中心核实情况，关闭服务器或系统，修改防火墙和路由器的过滤规则，封锁或删除被攻破的登陆帐号，阻断可疑用户进入网络的通道。 3、 系统维护人员及时清理系统，恢复数据、程序，恢复系统和网络正常；情况严重的，应上报领导，并请求支援。 4、 处置结束后 ,网络室及系统维护人员应将事发经过、处置结果等在调查工作结束后一日内报告信息系统事件应急领导小组 。 8.5人为破坏重要系统的事件应急预案 1、 通过集中监控平台、文件完整性监控工具、系统安全日志检查等方式发现对重要生产系统的核心文件（包括但不限于配置文件、系统文件、应用处理文件等）的人为破坏和修改时， 值班人员应在第一时间报告给安全管理员。 2、 安全管理员召集信息安全事件应急处理小组进行评估，并制定应采取的措施。包括但不限于：立即中断未授权访问、向应急事件领导小组进行报告、恢复内容、追究责任等。 3、 由系统管理员立即中断连接，并尽可能保留访问踪迹。 4、 事态或后果严重的，信息系统事件应急领导小组应及时报告相关领导。必要时，追究相关责任人的经济和法律责任。 5、 处置结束后 , 网络室应将事发经过、造成影响、处置结果在调查工作结束后一日内书面报告信息系统事件应急领导小组 。 8.6 重大攻击事件处理流程 1、明确并报告攻击事件的影响和范围。 2、在入口位置切断攻击源。 3、风险管理部展开攻击事件调查和评估。相应的工作包括如下方面： Ø 基于影响和范围决策是否启动法律程序。 Ø 如启动，相应的取证专家介入，开始证据的调查和收集。 Ø 基于攻击事件的信息，对攻击的可能性和危害进行评估。 Ø 评估被攻击系统可能的脆弱点。 4、系统部针对脆弱点进行加固和修复。 5、风险管理部对修复进行再验证。 8.7 攻击事件处理流程 具体请参见《系统攻击应急流程》。 8.8 机密信息泄露处理流程 1、明确并报告泄密事件的影响和范围。 2、切断泄露事件的路径。 3、风险管理部展开攻击事件调查和评估。相应的工作包括如下方面： Ø 基于影响和范围决策是否启动法律程序。 Ø 如启动，相应的取证专家介入，开始证据的调查和收集。 Ø 基于泄密事件的信息，对潜在的危害进行评估。 4、系统部针对存在泄密风险的源头和路径进行控制，杜绝类似的事件。 5、风险管理部调整安全审计范围，机密信息处于监控的范围内。 相应的奖惩措施，参见《风险事件调查规程》。 8.9 无线设备处理流程： 1、 每季度通过物理观察、技术探测、网络扫描等方式发现未经授权的有线或无线连接时， 值班人员应立即断开网线和无线信号，终止由此带来的未授权通讯，并报告信息系统事件到安全管理人员。 2、 安全管理人员应立即告知IDC管理人员，由后者采取隔离受影响的网络等措施。安全管理人员评估未授权接入对重要信息资产造成的影响，并追查私自网络接入事件的来源。 3、 事态或后果严重的，安全管理人员应及时报告相关领导。 4、 处置结束后 , 安全管理人员应将事发经过、造成影响、处置结果在调查工作结束后一日内书面报告相关领导 。 8.10支付卡事件处理过程 风险事件 商户被盗 支付卡被盗用 2持卡人自己 3银行调查 4公安局调查 5媒体调查 5000以上需要和上级一起处理 核实身份 通过提供订单号，CSR后台查询交易信息 卡号、开户地查询 发起地IP地址查询 与商家联系、查询交易信息。是否发货、无发货办理退款 与商家联系 通知公关部 整理入风险案例，并发出风险通报 将相关信息加入风险案例库中 风险事件总结 XXXXXX会员支付，冻结账户 8.10.1处理方法说明 1) 商家报案 Ⅰ、查询交易信息 Ⅱ、将交易信息提供给商家 2) 个人资金被并盗用 持卡人自己报案 Ⅰ、核实报案人身份 Ⅱ、查询详细交易信息 Ⅲ、商户是否发货，无发货联系商户做退款处理。 Ⅳ、与报案人联系，解决用户提出的问题 银行要求查询 Ⅰ、银行证明 Ⅱ、查询详细交易信息 Ⅲ、联系商户，请商户提供交易账户相关信息，同时如交易物品无发货，则做退款处理。 Ⅳ、将我公司平台资料提供给银行 公安机关要求调查 Ⅰ、需要提供公安局的证明 Ⅱ、查询详细交易信息 Ⅲ、与商户联系，请商户提供交易账户相关信息，同时如交易商品无发货，则做退款处理。 Ⅳ、将调查的相关资料提供给公安机关 新闻媒体要求调查 Ⅰ、通知公关部门 Ⅱ、查询详细交易信息 Ⅲ、与商户联系，请商户提供交易账户相关信息，同时如交易商品无发货，则做退款处理。 Ⅳ、将调查的相关资料提供给调查人 8.10.2商家报案操作流程 1、根据商家提供的交易信息进入CSR管理系统查询交易信息： 包括：XXXXXX的订单号、银行订单号、提交时间、扣款时间、交易金额等 2、银行卡号、归属地查询 将查询出的扣款时间、银行订单号交给结算，查询出银行卡号 根据卡号查询银行卡的归属地。 3、交易发起地查询 将查询出的XXXXXX订单号及提交时间交给技术查询出交易发起地的IP地址 4、将查询信息提供给商家，并详细询问商家风险是如何产生的 5、将以上查询信息填入标准的风险案例表中，生成Adobe Reader文件并向风 险小组（riskctrl@XXX.com）发出风险通报 6、将填好的风险案例及客服接到风险时留下的QQ聊天记录或电话录音等信 息一起存入风险案例库中 8.10.3持卡人报案操作流程 （注：被盗金额大于5000元，公安机关可以立案，需要与上级一块处理） 1、 核实报案人身份 手机号查询归属地（查询） 身份证号核实(查询)， 2、 如果是XXXXXX会员支付则马上冻结其个人账户 3、交易信息查询 进入CSR管理系统，根据报案人提供的银行订单号查询详细的交易信息 包括：XXXXXX的订单号、商户名称、商户订单号、提交时间、扣款时间、交易金额等 4、银行卡号、归属地查询 将查询出的扣款时间、银行订单号交给结算查询出银行卡号 将银行卡号提供给业管查询出银行卡归属地 如果报案人提供卡号，则同样的流程核实一个下 5、交易发起地查询 将查询出的XXXXXX订单号及提交时间交给技术查询出交易发起地的IP地址 6、交易信息查询，如果交易状态是未成功，联系商家做退处理 7、与报案人联系 详细询问被盗经过包括：在什么网站上购买过商品、输入过卡号、密码；是否在假的银行网站上输入卡号、密码；是否因为疏忽泄露给别人知道。 如果报案人是通过浏览假的网站泄露的密码，需要模拟被盗人的过程，将在假网站交易过程的截图保存下来。 如果交易商品已发货，需要和报案人解释整个交易过程中XXXXXX所起的作用，以免用户产生误解。提醒其对银行卡及时采取保护措施。 如果可以做退款处理的，告诉用户可以退款。 有关报案人询问的问题：可以提供商家的名称，网址及联系电话，对于收款人的信息则不可以透露， 尽可能的解决用户的需要 8、 将以上查询信息填入表准的风险案例表中，生成Adobe Reader文件并向风 险小组（riskctrl@XXX.com）发出风险通报 9、 将填好的风险案例及客服接到风险时留下的QQ聊天记录或电话录音等信 息一起存入风险案例库中 8.10.4银行提出交易查询的操作流程 1、根据银行要求调查内容查询需要信息（需要加盖公章） 2、如果是XXXXXX会员支付则马上冻结其个人账户 3、交易信息查询 进入CSR管理系统，根据银行提供的银行订单号查询详细的交易信息 包括：XXXXXX的订单号、商户名称、商户订单号、提交时间、扣款时间、交易金额等。 4、交易发起地查询 将查询出的XXXXXX订单号及提交时间交给技术查询出交易发起地的IP地址 5、与商家联系，查询卖方交易信息 将查询出的交易信息：商家订单号、交易时间及金额提供给商家。请商家帮助查询对方交易账户的信息，如账户号、账户名等 如果商家物品没有发出，则要求商家做退款处理 6、将交易信息提供给银行 7、将以上查询信息填入表准的风险案例表中，生成Adobe Reader文件并向风 险小组（XXX@XXX.com）发出风险通报 8、 将填好的风险案例及银行传真或电话录音等信息一起存入风险案例库中 8.10.5公安机关要求查询的操作流程 1、 核实调查人身份，要有公安局加盖公章的介绍信及协助调查函 北京以处公安机关要求协查的话，请其先与北京市网监处的人联系。 2、 如果是XXXXXX会员支付则马上冻结其个人账户 3、交易信息查询 进入CSR管理系统，根据银行提供的银行订单号查询详细的交易信息 包括：XXXXXX的订单号、商户名称、商户订单号、提交时间、扣款时间、交易金额等。 4、交易发起地查询 将查询出的XXXXXX订单号及提交时间交给技术查询出交易发起地的IP地址 5、与商家联系，查询卖方交易信息 将查询出的交易信息：商家订单号、交易时间及金额提供给商家。请商家帮助查询对方交易账户的信息，如账户号、账户名等 如果商家物品没有发出，则要求商家做退款处理 6、将交易信息提供给公安局的调查人 7、 将以上查询信息填入表准的风险案例表中，生成Adobe Reader文件并向风 险小组（XXXl@XXX.com）发出风险通报 8、将填好的风险案例、公安机关的证明文件、电话录音等信息一起存入风险案例库中 8.10.6新闻媒体要求调查的操作流程 1、 通知公关部门做好公关准备 2、交易信息查询 进入CSR管理系统，根据银行提供的银行订单号查询详细的交易信息 包括：XXXXXX的订单号、商户名称、商户订单号、提交时间、扣款时间、交易金额等。 3、如果是XXXXXX会员支付则马上冻结其个人账户 4、交易发起地查询 将查询出的XXXXXX订单号及提交时间交给技术查询出交易发起地的IP地址 5、与商家联系，查询卖方交易信息 将查询出的交易信息：商家订单号、交易时间及金额提供给商家。请商家帮助查询对方交易账户的信息，如账户号、账户名等 如果商家物品没有发出，则要求商家做退款处理 6、将交易信息提供给调查人 7、 将以上查询信息填入表准的风险案例表中，生成Adobe Reader文件并向风 险小组（XXXl@XXX.com）发出风险通报 8、将填好的风险案例及相关信息一起存入风险案例库中 第 23 页 共 23 页