国家计算机网络应急技术处理协调中心计算机网络安全应急处理.ppt

国家计算机网络应急技术处理协调中心计算机网络安全应急处理.ppt

《国家计算机网络应急技术处理协调中心计算机网络安全应急处理.ppt》由会员分享，可在线阅读，更多相关《国家计算机网络应急技术处理协调中心计算机网络安全应急处理.ppt（42页珍藏版）》请在冰豆网上搜索。

计算机网络安全应急处理,国家计算机网络应急技术处理协调中（CNCERT/CC）运行部主任杜跃进博士2004年7月3日,报告内容,引言：

应急处理和网络安全保障的关系应急处理领域面临的主要问题国内外现状和趋势,如何才算安全,假设：

攻击（达到攻击者的目的）所需要的时间Ta=tae-tas;防护（确保预先定义的防护指标）所需要的时间Td=tde-tds;安全：

tde=taeTIP：

在有限成本的前提下，Td不可能无限缩短，因此，尽量减小tds是解决问题的关键问题：

tds从何时算起tds有可能小于tas吗,如何才算安全（cont.）,按照过程划分的安全保障的一般环节：

PPDRR结论：

安全取决于响应时间和抗攻击时间的关系RtPt（及时响应是安全保障的关键）推论：

安全保障的各个环节不应该是相互孤立的；投资多少和设备好坏，不是决定安全的充分条件问题：

怎样将这些环节有机地联系起来？

安全是一个动态的过程,“动态”的问题：

网络和系统的组成和变化（结构、地址、甚至操作系统）应用的变化（内部应用的增加或者减少）用户的变化（用户的群体和个体行为属性的变化）外界威胁的变化（新的漏洞、新的攻击方法、etc.）安全不是一个静止的“状态”，而是一个动态的过程。

什么是应急响应,调查：

我们有多少人知道应急响应？

多少人知道CERT/CSIRT？

应急处理实际上是网络安全保障“工作”的具体体现。

各种防护方案、安全设施、策略规定等，广义上都可以理解为应急处理工作的一部分。

而完整的应急处理工作的各个阶段，则体现了网络安全保障的不间断的“过程”。

实践：

及时发现是安全保障的第一要求,根本性的问题在于当事件发生的时候，有关人员能否及时发现，以及能否做出准确判断问题1：

局部网络安全策略的维护、日志分析、报警数据处理；问题2：

局部数据只能反映片面的情况，如何作出全局的判断；问题3：

网络世界和现实世界的一个不同之处是，受到事件影响的用户自己经常并不明白发生了什么事情，因此，完全依赖用户投诉作为发现手段是不现实的。

对红色代码、SQLSLAMMER等事件的处理过程，证明了网管人员及其工作在应急工作中的重要性；也证明了数据情报及时汇总分析的重要性。

事后：

部分用户投诉事件；事中：

大规模网络攻击事件、部分用户投诉事件事前：

异常检测的分析结果、关联事件、根据其他情报获悉,应急处理领域面临的问题,应急处理成为专业化的方向,应急处理领域面临的问题方法论的问题具体方法的问题技术平台的问题（及其关键技术）数据交换的问题处理流程的问题（包括有效的预案）组织和体系建设的问题（包括和产业界的合作、CERT和LEA的合作）基础技术问题（漏洞处理、犯罪取证）etc.,方法论的问题：

复杂巨系统的控制,已有的论证：

互联网+用户构成一个复杂巨系统复杂巨系统的控制，需要“人机结合、以人为主”，建设开放的综合集成的研讨厅体系突发的危机事件处理，关键在于要在“黄金时间”内作出恰当的响应面临的重大挑战：

信息网络空间中的危机事件，留给我们的“黄金时间”越来越少，原有的方法如何能够在这个领域进行有效的实践？

问题的重要性：

宏观战略的问题！

具体方法的问题：

面对各种安全事件的处理技术,已有的工作：

针对各种层出不穷的事件，需要提供相应的解决方法、工具和背景知识：

各种后门、病毒、蠕虫；人工的入侵；各种系统、设备、和应用；DoS；Web-deface；Phishing；等（组合）面临的挑战：

一个CSIRT不可能精通一切；在解决具体问题的时候，是否能够得到及时的支持问题的重要性：

实际工作中最迫切的问题,技术平台的问题：

综合的应急处理支撑平台,在刚刚结束的FIRST大会上，FIRST的主席指出，全球安全事件处理的四个关键因素：

事件处理的基础设施、国际论坛、信息技术交流和组织专业化。

我们需要一个什么样的平台？

DNIDS？

IPS？

IHS？

PNDS？

SOC？

Whatisitindeed?

Atleast:

首先需要一个能够持续、准确、全面、及时反映整体网络安全状况的系统!

面临的重大挑战：

大规模网络、超大规模网络、多网互联、国家网络等情况下，存在很多的关键技术问题的重要性：

没有它，就是无米之炊！

数据交换的问题：

系统和组织之间进行数据交互,趋势（而且将成为必然）：

应急组织之间展开频繁的数据交换不同系统之间进行持续的数据交换高效率的综合数据汇总与分析面临的问题：

IODEF?

IDMEF？

推广问题问题的重要性：

综合技术平台和CSIRT合作体系的一个必要条件,处理流程的问题：

科学规范的方法,理论基础：

“人”在安全保障方面的作用不可替代理论上的问题：

如何保证人机结合的过程中，人的动作的规范性和科学性？

实践需求：

不断出现的新的安全事件、不断出现的新的情况，对原来的流程提出新的挑战制定的各种应急预案，经常发现不能有效地应对突发事件面临的挑战：

需要持续地改进，并且和多方面进行沟通需要持续地研究，补充新的内容问题的重要性：

CSIRT有效工作的必要条件之一,组织和体系建设的问题：

有效合作,GlobalProblem,GlobalSolution趋势：

CERT的诞生其实就来来源于协作的需要国际上出现越来越多的合作组织与形式（包括CSIRT的专业化组织、CSIRT和LEA的合作、CSIRT和政府的合作、CSIRT和综合国际组织例如APEC的合作、CSIRT和网络反恐领域的合作，CSIRT和产品供应商的合作，etc）面临的问题：

机制、法律、国际规则和效率等问题的重要性：

有效处置的必要条件之一,基础技术问题：

各种相关的支撑工作,有关的基础技术的积累漏洞发现、监测和分析，系统化的漏洞处理方法和体系犯罪取证海量信息的有效处理etc.问题的重要性：

长远的积累和根本性的支持,国内外现状与趋势-组织体系、技术平台、部分项目,全球CSIRT发展现状

（1）,事件响应小组的数量在过去的四到五年中有大的增长，这种增长主要发生在商业领域。

教育和政府小组的增长也在继续。

从全球角度来看，得到了更多关注，特别是国家和地区政府小组。

小组数量增长的原因有（）安全事件数量的增加和对有计划的响应的认识，（）新的法律要求，以及（）目前的观点认为，计算机安全必须事前预防才能取得成功，事后反应不再是充分有效的。

事件处理和事件响应小组仍然是一个计算机安全的较新领域，并且事件响应仍然是一个不成熟的领域。

因为这个原因，很少有得到广泛认可的事件处理方法学标准。

数据来源：

CERT/CC,全球CSIRT发展现状

（2）,目前（年九月）的项目：

协调与协作各之间建立交流和协调机制的讨论。

信息共享和信息收集标准所有小组在信息共享、事件数据收集、或制订发行物方面没有公认的标准，很多讨论认为建立这样的标准将简化共享和分析的过程。

事件数据收集各种机构已经在开发用于收集、关联、以及合成事件数据的工具或机制。

工具专门为事件响应和事件处理提供的工具很少。

各个机构已经制作了一些工具档案，提供对安全和事件响应工具的访问或评论。

研究致力于获得更多有关于安全网络和系统以及有效的事件处理的知识。

数据来源：

CERT/CC,全球CSIRT发展现状（3）,数据来源：

CERT/CC,全球CSIRT发展现状（4）,一般CSIRT所提供的服务：

数据来源：

CERT/CC,国际应急组织和部分项目,FIRST：

154个正式成员（CNCERT/CC2002年8月加入）。

国际最权威的专业组织。

APCERT中、日、澳等发起成立，目前15个正式成员，主要代表亚太地区的经济体。

事件协调处理方面作用明显。

EGC&TF-CSIRT美洲：

“泛美应急组织观察和预警网络”。

2004年4月。

23个国家参加。

建立各国应急响应组织的联系，监测系统的信息传递标准，提高快速发现问题的能力CIIP中日韩IODEF项目组,我国的公共互联网络应急处理体系,技术平台：

国际方面,美国韩国日本澳大利亚马来西亚、巴西,技术平台：

国内的情况,互联网运营商863-917平台,研究内容：

总体框架,863-917网络安全平台,目前具备的主要能力,大规模异常事件的发现能力01年：

2-3天确认情况03年初：

2-3小时目前：

10-30分钟重大网络安全事件的初步监测分析能力包括感染范围和速度、控制效果、对网络的影响情况等攻击事件的分布式自动验证拓扑发现和定位分析分布式问题网站发现系统，等,实例.特征：

红色代码01.9.2-9.9,监测到感染服务器48,414个，其中仅2,000余个和8月22-27日的数据重复,变化情况,分布情况,监测到的攻击1,024,013次，实际攻击次数估计为该数据的数百倍。

实例.特征：

红色代码对不同地区的影响程度,实例.特征：

03年3月口令蠕虫,实例.特征：

恶意代码监测,时间：

2004年6月11日,实例.流量：

LSASS系列蠕虫,实例.流量：

MSBLAST系列,04年1月1日起，数据明显降低,实例.流量：

蠕虫引起流量异常,2004年3月9日下午发现整个流量涨幅较大，并且UDP数据超过TCP和HTTP的流量定为异常，启动进一步分析，发现大量报文目的端口为1434报文分析确认为SQLSLAMMER,实例.分布：

蠕虫形成的数据报文分布属性,SQLSLAMMER攻击报文的分析结果：

目的地址十分分散源地址相对比较集中UDP，目的端口1434Witty蠕虫由于其自身特点，表现得更加明显,实例.分布：

DDoS形成的分布属性,2004年4月16日发现ICMPtype=0流量上升异常进一步分析，发现Ping回答数据量不正常，对报文属性分析认为是对目的地址（美国）的一次PingFlood攻击,谢谢!

2004年7月3日.西安,历史教训：

国际方面,1988年11月：

Morris蠕虫：

主体瘫痪几周后，CERT/CC成立其后的两年，CERT组织纷纷出现1989年10月：

Wank蠕虫：

发现CERT组织之间的沟通与合作非常必要1990：

FIRST成立FIRST依然存在不足,在受攻击的网络中采取隔离措施,依靠合作在攻击源附近实施隔离,CNCERT/CC的部分工作&项目,技术平台的研究和建设863-917平台骨干网络设备运行数据采集与汇总分析国家网络安全资源平台综合数据资源：

IP定位、拓扑发现、事件库、应用信息分布、攻击特征库、漏洞库、恶意代码库、工具库、补丁库、Checklist、邓恶意代码和弱点分析能力模拟仿真平台提前发现和预警：

攻击特征无关的弱点利用行为监测；综合信息采集和分析综合数据分析“被动网络发现”研究异常检测信息交换格式与平台：

IODEF/IDMEF信息产业部应急预案CIIP研究国际事务培训事件处理：

入侵、web-deface、phishing、DoS、scan、etc.,