Archive

Posts Tagged ‘CoBIT’

Make sure security be always part of IT

February 11th, 2009 No comments

When we think of security ,we all think about security such as security products, security functions, control mechanism, privacy protection, implementation, maintenance, configuration, etc separately ,this causes many problems and adds up the overheads . Read more…

Categories: -English-, Security Tags: , , ,

[Chinese]网络信息安全度量和考核指标体系(4) – 读Andy的“安全度量”

May 8th, 2008 2 comments

坦白说,在LinkedIn上提问之前,就安全度量指标系统而言,我并没有做过更多的学习和研究。在得到大家的热烈指导和响应后,我越来越发现原来有这么多的资源和信息已经在哪里,可以借鉴。写了前面三段关于安全的度量指标体系的帖子后,我开始读Andy的“安全度量”。

Security MetricsAndy(Andrew Jaquith)的“安全度量”(Security Metrics: Replacing Fear, Uncertainty, and Doubt)这本书是一本不错的书。几个星期前从网上找来了PDF的英文版,前几天买了中文版(电子工业出版社,2007年12月)。这两天在深圳出差,抽路上的时间把书读了一遍。下面是点到为止式的一些评论。 Read more…

[Chinese]信息系统安全审计之我见

July 23rd, 2006 No comments

什么是“审计”?

我们知道,审计(Audit)是指检查、验证目标的准确性和完整性,用以检查和防止虚假数据和欺骗行为,以及是否符合既定的标准、标竿和其它审计原 则。各国各级政府、组织一般都设有专门独立的审计部、审计委员会、审计署等机构。审计早年用于财务系统,到现在词典、字典中的“审计”(也包括 Audit)的定义都是针对财务系统。在当今的世界里,几乎所有企业、机构和组织的财务系统都运行在信息系统上面,所以信息手段成为财务审计的一种技术的 同时,财务审计也间接带动了通用信息系统的审计。在美国安然公司(Enron)和世通(WorldCom)财务欺诈案爆发后,在2002年美国紧急出台了 萨班斯法案(SOX, or SOA),赋予了“审计”新的意义,这里也包括了信息系统的审计。“审计”成为企业内控、信息系统治理、安全风险控制等的不可或缺的关键手段。

另据新闻报 导,在最近结束的IATA年会上达成一个重要共识:所有成员航空公司都要进行运行安全审计(IOSA),申请加入IATA的成员在正式加入前必须通过 IOSA审计。目前所有的成员公司要在2007年之前完成审计,否则不予保留会员资格。审计已经逐渐成为越来越多的政府部门、行业分支、大企业等加强治理 的重要手段。

美国信息系统审计的权威专家Ron Weber将它定义为“收集并评估证据以决定一个计算机系统是否有效做到保护资产、维护数据完整、完成目标,同时最经济的使用资源”。

审计系统主要包括两种形态

  • 基于主机的审计(主机、网络等各种日志)
  • 基于网络的审计(网络会话和行为)

它们分别依赖不同的手段来收集审计信息,面向不同的风险和威胁:

1 前者收集并分析各种日志。这是较早的、较为传统的审计方式,登入、登出、添加、删除、修改、更新等活动,应用日志、操作系统日志、数据库日志、网络设备的 日志等。按照IDC的新定义,SIEM(安全信息和事件管理)类安全产品负责收集安全设备和其它信息系统的日志和事件告警,进行过滤、相关、分析等处理。 一般说来,前两年如火如荼采购中的SOC产品(如果喜欢叫平台也可以)基本上都属于IDC的SIEM类。

2 后者直接查看数据本身。由于各种先进的攻击方法的出现、由于IDS的漏报、由于当前对于内部滥用和误用(这些都很难从安全设备的日志中发现)的担心,对于 网络和应用数据本身的记录、回放、分析等形成了另外一个审计分支。这类产品最早的出处应该是雷神(Raytheon )公司的SilentRunner(如果大家还记得的话,后来被CA公司收购,现在产品的名字叫Network Forensics),专门用于分析网络流量和海量日志,从中发现IDS等安全设备不能发现的潜在威胁和事件,违反安全策略和规则的行为。另外NAI公司 的Sniffer,或者后来的开源软件TCPDUMP虽然缺少上层的分析层和展现层,也有一部分这方面的功能。NAI公司分家后,Sniffer公司继承 了网络取证分析产品InfiniStream Security Forensics。Niksun公司的NetDetector, NetVCR, NetX等系列产品可以“连续的流量记录和存储”、帮助分析网络中的流量、监控网络行为“网络异常及入侵检测”、以及帮助进行符合性分析和事件取证“网络 审计分析”等。

近两年来,随着对操作行为本身进行审计的需求的提升,于是产生了一种使用应用代理进而建立堡垒主机的方式来控制网络访问活动、并获得操作数据进行记 录并分析的审计系统。这类系统的代表包括Symark公司的PowerBroker,以及Bluecoat公司的ProxySG等。这类审计系统需要客户 端显式地配置代理指向的地址,并可能需要进行二次验证以符合代理的安全策略。

国内已经开始有越来越多的公司开始涉足并推出自己的安全审计产品,除去上述第一种的日志收集产品之外,还出现了相当多的网络镜像方式获得数据,进行 会话重组和协议分析,可以根据安全策略发送Reset包主动中断网络连接(有些还可以进行身份认证和授权验证),这类产品的代表包括清华紫光的ACA、以 及复旦光华的S_Audit等。前者与认证、授权等结合,面向运行维护需求,而后者则加入了很多HTTP、IM等应用的分析展现功能,面向企业内部安全使 用控制。

[待续]

richardong 2006-09-15 评论

我对文章中对”审计”的分类有一点建议和一点补充:

原文:

  • 基于主机的审计(主机、网络等各种日志)
  • 基于网络的审计(网络会话和行为)

我的观点:

  • 基于主机的审计(用代理监视并记录发生在主机上的行为)
  • 基于网络的审计(网络会话和行为)
  • 日志审计(各种日志:操作系统日志、数据库日志、网络设备日志等)

最后,我认为这三者应该统一在一个平台上,但与SOC最大的不同点在于,这样一个平台不应该强制将各种格式迥异的日志转换成统一的格式(Normalization)。

zhaol 2006-09-15 评论

多谢。不过我保留我的观点。审计要素或者是行为业务数据本身,或者是数据的数据,即元数据,传统的日志和审计系统都是后者。也就是我所说的基于主机的审计。前者记录业务数据本身,也就是我所说的基于网络的审计。或者我对这两类的名称上有些含混。欢迎继续争论…

zhaol 2006-12-26 评论

在三所产品测试网页上有一个安全审计产品的标准…
业界还有许多与审计有关的最佳实践/标准/框架,例如CoBiT,BS7799/ISO27001等。

zhaol 2007-01-20 评论

SOC 正如其名字所说是个Operations Center,主要目的是负责监控、然后带动后台的其它运维活动。不管是日志审计、还是操作行为审计都不是SOC的主要方向,管理制度方面(例如补丁、口 令、策略配置等)的审计更不是SOC的内容。相反的,SOC的运行倒应该是审计的对象:监控的有效性、响应的及时性、措施的有效性等。

12345678! Pyramid Framework

June 14th, 2006 No comments

Yesterday afternoon, WHY and I worked out a holistic enterprise internal control framework. We named it as 12345678! Pyramid Framework. It help integrate the enterprise execution, IT control and security control methodologies and countermeasures.

  1. One Priority: Execution
  2. Two Hands: Technology and Management
  3. Three Layers: Decision Makers, Managers, and Execution
  4. Four Phases: Plan, Do, Check, Act
  5. Five Layer Controls: Control Environment, Risk Assessment, Control Activities, Information and Communications, Monitoring
  6. Six Risk Elements: Assets, Threats, Vulnerabilities, Safeguards, Risks and Opportunities
  7. Seven Information Criteria: Confidentiality, Integrity, Availability, Efficiency, Effectiveness, Compliance, Reliability
  8. Eight IT Processes: Planning and Organization, Acquisition & Implementation, Delivery and Support, Monitoring and Evaluation

Do you like it? We know there has been much space left for it to be perfect. But it help guide your thinking ways when you prepare proposals or do planning. Its original form is in Chinese. Click here for more.

If you think it helpful or have any suggestions, just leave me a comment.

[Tags]Security,BS7799,CoBIT,SOX,Audit,PDCA[/Tags]

Telecom Security Framework (Diagram)

November 4th, 2005 2 comments

Nowadays, the security for telecom operators is expanded to a very wide range, from 3G/IMS/SIP, to IM/P2P filtering, and even security issues related to various VAS(value added services). How to make a plan and blueprint for a telecom operator network security? You must be familiar to not only the BS7799, X.805, CoBit, SSE-CMM, CC and other standards, but those telecom technologies and specificication as well. A very challenging job! Isn’t it?

做电信安全有这么多年了,感觉上越来越累,越来越吃力。因为安全技术和标准的发展很快,更因为电信各种新技术的发展更快!我一向认为,即然是说电信网安全就必须深入电信、体现电信网的特点。这里并不是什么特例独行,也不是故意为了突显电信网的“电信级什么什么”带有的“自我优越感”,而是因为现在的电信网的确是越来越复杂了,而网络安全的内涵也越来越放大,放大到几乎什么“故障”、“中断”、“性能下降”都有可能被冠以网络安全的名下,业务连续性不是被很多安全咨询公司拿来当作自己的顾问服务内容吗。另外,SOX符合性有网络安全的事,城域网优化、网络提质有网络安全的事,垃圾短信、非法广告也有网络安全的事吧,网络安全主管要想办法过滤呀。更有当前的非法VoIP检测、P2P识别也成了网络安全的工作范畴。

呵呵,这下网络安全的饭碗是不是一下子光芒万丈了。如果还想靠防火墙、反病毒、IDS老三样产品,依靠Windows,Unix风险评估加固在电信里打天下,估摸着会越来越吃力。

Telecom Security Framework

【老文章】建立电信IT综合保障体系

August 29th, 2004 No comments

这篇文章写于2004-8-29,发表于中国计算机用户,尝试将ITIL/ITSM与安全结合在一起,与系统生命周期建立安全综合保障体系。网络链接: http://media.ccidnet.com/media/ccu/626/03301.htm

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

1.电信业面临的机遇和挑战
中国电信业的竞争日趋激烈,上市后股东和公众对于中国电信企业管理层的压力也与日俱增。管理层的关注点与几年前相比出现了明显的变化,从用户数为中心的粗放式经营转向关心每用户营收、每用户成本、营运利润、产品服务利润等精细化的经营,也更加关注业务发展的成本。

新技术和新政策给电信市场的发展带来了更多的不确定性,也促使领导企业和潜力企业的管理层来研究这些新技术、新政策背后为企业带来的机遇和挑战。例如一号通(700号业务)和当前的“携号转网(NP)”、“双模”手机等,对中国移动、中国联通和中国电信、中国网通四家主要运营商的决策者带来了很多的思考。依靠传统的号码、地域、资费等都不能稳定地保持住客户资源时,“保障”这个词背后的含义也就更加丰富了。

收入保障、客户保障、IT服务保障、安全保障等越来越成为电信企业控制企业风险、保证长期稳定的股东回报的重要手段。收入保障的宗旨是防止话费流失与欺诈,保证计费数据准确;客户保障的宗旨是防止客户流失,保持客户满意度。它们无疑是企业保持市场竞争的关键要素。

近几年来,一方面,电信企业通过建立业务数据模型、流程模型和重组、建立统一客户资料库、建设数据仓库和主题分析等来深层发掘分析企业的业务发展、运营过程中的多种发展的动力因素;另一方面,通过规划企业自身的IT战略发展路线和战略(ITSP)、建设信息基础设施的保障体系来提基础设施的效率,控制企业的安全风险。这些都是建设IT保障体系的重要步骤。

IT保障体系由IT服务保障和安全保障两个层面构成的,参见附图一,是电信企业整体“保障”体系中至关重要的环节,是企业竞争的重要因素,不仅仅是保护企业核心业务高质量的交付、信息资产不受外部攻击的威胁,更重要地是良好有效地保障体系可以帮助建立起股东和公众的信心,保障企业的市场核心竞争力。

本文后面部分将讨论电信企业的IT综合保障体系的意义和建设路线。

2.建设IT保障体系
如下图所示,电信企业越来越多需要依靠IT系统,不仅仅是向客户交付业务所需的网络管理维护系统,并且还有大规模的客户服务、帐务、市场分析、ERP等企业支撑系统。对这些关键应用的“保障”需要首先保障这些应用的底层,也就是承载这些关键应用的各种IT系统,保障这些大量的软件、硬件、中间件、安全设备、网络设备等构成的基础设施。

经过多年的建设,目前,电信网络中已经部署过大量的网管和网络安全产品。应该说,这些产品都不同程度地提高了网络的运行和交付能力,以及安全防护能力。但是,这些还不是“保障”体系。

我们说,电信级网络是超复杂系统,是因为电信网络往往规模庞大、系统复杂,其中的各种网络设备、服务器、工作站、业务系统、支撑系统都存在着超常的复杂性、多样性。即使是其中的安全防护子系统也是由多种、来源于多个供货商的设备构成。它们通常在架构、协议、通信、操作等许多方面都存在相当大的差异性。这种差异性又进一步加大了系统的复杂度。

如何为这样一个超复杂的系统建设保障体系?这里,我们借用一个管理学上的假设:“高质量”的过程带来“高质量”的结果。针对超复杂的电信IT系统,加强其中某个网元或者模块,对整体系统的服务质量和安全水平,提高是有限的。更有效的做法是,以最终交付的服务为龙头,清理出核心的流程(过程),将关注点和资源、精力放到流程优化,以及端到端的流程服务质量(QoS)上。例如:
? 故障的集中管理和根源分析
? 配置和变更管理
? 新业务系统的开发和上线
? 访问关系的建立和变更
? 预警信息的批准和发布
? 系统补丁的收集、测试、批准、发布和分发
? 等等

基于上述关键流程,来整合IT服务和安全管理、建设企业总控中心(ECC)和安全管理中心(SCC/SOC)等就有了明确的目标和坚实的基础。

3.系统开发生命周期保障
IT保障体系为电信企业的关键应用提供了安全、高效的基础平台,但是如何保障关键应用自身的安全稳定运行呢?在这一点上业界是走过许多弯路的,也付出了许多很惨重的代价。如图1所示,电信企业的关键应用越来越复杂,业界提出了很多这方面的框架、最佳实践和规范来指导关键应用的开发,例如eTOM是电信业务过程方面的权威指导,提出了在产品生命周期和交付、保障和计费等不同阶段的关键过程。而对于这些关键应用和系统本身的开发,则需要参照系统开发生命周期(SDLC)方面的最佳实践,请参见图2。该图取自TMF的eTOM文档,ITIL和eTOM的结合将是电信企业建设关键应用系统的生命周期保障的最佳参照框架。

这里的关键应用包含两层含义,其一是应用本身;其二是包含了整体的软件、硬件等的应用系统。前者需要重点参考软件工程实践,相对成熟,对于电信企业来说,需要加强的是关于数据模型管理、接口管理、变更和配置管理等方面;后者则需要参照SDLC,对于供应商、对于需求、对于体系架构等都有较好的风险控制,并且与ITIL指导的IT服务管理形成闭环,逐步提高运行质量和服务水平。

作为后者的一个例子,相对不够成熟的安全保障系统的建设,就应该充分借鉴电信企业在BOSS/ITSM等大型应用系统建设方面的经验教训,从开始就考虑开放性、集成性和可管理性,并且注重生命周期的管理,与IT保障体系在架构上互相兼容,在数据模型、界面、事件等各种层面可以互相通信、融合。这些都是从 SDLC角度,来提高电信企业IT保障水平的重要内容。

4.运行维护保障体系
前面分别从IT服务管理、安全管理以及生命周期管理等三个方面讨论了电信企业IT保障体系的建设。当前国内的电信企业通常有三个相对独立的IT系统:网络部、计费中心、企业信息化,它们的运行维护也相对独立。在每一个IT系统内都需要“集成”在一起,来考虑三个方面的保障措施和机制。“集成”过程中运行维护保障机制将会成为挑战。

通常情况下,运行维护人员是按照业务进行分工的,参见图3,每个维护人员或小组,负责管理某项或某几项业务的应用、系统、网络等各个层面。当业务或应用增加时,管理者面临的挑战是或者增加人手,或者与原来的某项业务合并管理。这种管理机制的问题是明显的,即可扩展性不好,运行维护人员不容易“专注”。

另外的一种选择是,设立IT支撑小组负责网络和系统管理,设立安全小组,负责安全管理,共同为业务小组提供支撑。当增加新业务或应用时,IT支撑小组和安全小组都可以较容易的扩展覆盖,业务小组因为摆脱了底层支持的重复性内容,可以更加专注,所以也可以管理更多的业务。应该说,后者在前者上面有了提高,更加灵活,具有更好的可扩展性。

但是,层次化分工也会带来新的问题,IT系统的客户关心的是最终的交付质量,并不关心内部的层次化分工。当出现服务故障或问题时,从应用层到系统、网络层、再到安全管理层,解决故障后再逐次返回到应用层,消除客户问题。如何控制这个“时间延迟”?前面讨论到的SDLC可以帮助实现不同层面的通信和共享,从而加速响应过程。但是更根本的保障措施是“流程整合”背景下的重组,即在SDLC提供的通信和共享机制下,将IT管理、安全管理和业务管理的流程对接起来,对端到端的流程质量进行跟踪,并且从组织上、绩效考核上得以体现。

5. 电信IT综合保障体系
综上所述,IT服务管理、安全管理、生命周期管理、运行维护管理是电信IT综合保障体系的四个方面,它们从不同的角度、不同的层面来保障电信企业的核心业务的最终交付质量和效率。

关键业务的服务质量是电信企业的生命线,如何保障超复杂的电信网络的服务质量也是超复杂的挑战性问题。本文试图从四个不同的角度来探讨建立电信企业的综合保障体系的方法和途径,其中欠缺不足之处,希望得到业界专家的指教。



【老文章】实时的安全风险管理体系

April 29th, 2004 No comments

赵 粮(冠群电脑有限公司)
裘晓峰(北京邮电大学)
2004-4-29

1 从风险评估到风险管理
网络安全体系的目的是保障关键信息设施的资产和服务,提供适度的安全保护,即根据每种(个)信息资产(Asset)的价值、面临的威胁(Threat)和安全风险(Risk)来确定相应的安全防护措施和力度,做到“重点防护”、“适度安全”。要做到这一点,风险评估是一个重要环节。

风险评估作为成型的技术已经有数年的历史了,同时,风险评估也是安全专业服务中最为成熟的一个内容之一。近年来,国内的知名企业、机构几乎都开展、购买了专业的安全风险评估服务。风险评估的目的是帮助识别信息设施中的资产,分析判断其价值、存在的脆弱性和面临的安全威胁,从而获得该资产或资产组的安全风险情况,继而可以采取针对性的安全防护措施,提高安全体系的投资效率。

我们知道,风险评估本身不是目的,最终的目的是消除风险、控制风险,在保证投入回报的前提下管理安全风险。一般来说,风险评估是风险管理活动的基础,帮助建立起风险管理的基线。定期的评估活动可以用来审计和考核安全风险管理的效果和效率。本文尝试着讨论建设实时的风险管理体系的可行性,提出一种实用模型。

2安全风险

安全风险具有非常广泛的含义,本文中使用较为通用的风险模型:安全风险由资产价值、脆弱性和威胁来决定:
Risk(t) = R(A,T,V,t)
其中,t代表某个时刻,A代表该资产的价值,T代表该资产面临的威胁,V代表该资产存在的脆弱性(安全漏洞), ?表示对风险管理范围下的资产求和,R代表某种函数关系。通常,在常见的半定量评估过程中,该函数有时采用简单的乘积来计算。

资产价值
信息资产以多种形式存在,无形的、有形的,有硬件、有软件,有文档、代码,也有服务、企业形象等。它们分别具有不同的价值属性和存在特点,存在的脆弱性、面临的威胁、需要进行的安全保护和安全控制都各不相同。若干具有很强的内在业务关联和依赖关系的资产可以构成一个资产组。

信息资产具有不同的安全属性,包括机密性、完整性、可用性、可控性和不可否认性,分别反映了信息资产在5个不同方面的特性。安全属性的不同通常也意味着安全控制、保护功能需求的不同。通过考察5种不同的安全属性,可以得出一个能够基本定性地反映资产价值的数值。确定信息资产以及数值的过程称为信息资产的识别和赋值。

实时的风险管理体系需要建立起能够实时发现并监视资产变化和状态的机制,并且能够反映该资产的价值变化。

安全威胁和漏洞
安全威胁是对信息资产引起不期望事件而造成损害的潜在可能性。威胁可能源于对信息资产直接或间接的攻击,例如非授权的泄露、篡改、删除等,在机密性、完整性、可用性、可控性或不可否认性等方面造成损害。威胁也可能源于偶发的、或蓄意的事件。通常,收集分析安全事件是获取并计算威胁的主要方式之一。

弱点和资产紧密相连,它可能被威胁(威胁的定义参见威胁一章)利用、引起资产损失或伤害。值得注意的是,弱点本身不会造成损失,它只是一种条件或环境、可能导致被威胁方利用而造成资产损失。通常,网络脆弱性扫描、主机和应用的安全审计是获取计算弱点的主要方式。

实时的风险管理体系需要具备实时收集威胁信息和脆弱性信息的能力,并且能够与信息资产相关关联,进行有效性分析。

安全风险
在实时的获取资产、威胁和漏洞的信息基础上,可以计算风险的实时变化:

资产的变化可能来源于新资产的出现,也可能是承载的业务发生的变化。威胁的变化可能是新的安全事件的出现和解决。脆弱性的增加则主要体现在新的脆弱性,而脆弱性的降低主要通过相关的补丁,或者配置策略等的改变或优化。

可以看到,在信息资产保持相对稳定的情况下,降低安全风险的手段主要有两种:其一是通过强化安全策略,减小出现安全事件的机会,并且在出现安全事件的时候,能够及时的发现、定位和分析,消除事件,震慑威胁方;其二是通过及时有效的补丁和安全配置,减少甚至消除资产存在的脆弱性。

3 基于安全总控中心的实时安全风险管理体系

安全总控中心(或称为安全管理中心)是近期非常引人关注的话题。其特点是高度的集成性和自动化,大大减小从发现新的安全风险到完成弥补(风险消除)之间的时间窗口,帮助在与威胁方的时间赛跑中获胜。

安全总控中心的典型结构如下图所示,其关键组件和技术包括:
? 信息资产库及实时资产发现能力
? 实时更新的安全漏洞库和补丁库,预警能力
? 各种安全事件的收集和相关处理,解决安全信息过载问题
? 安全事件与信息资产、安全漏洞的相互关联
? 基于安全知识库的工单和流程管理系统
? 安全补丁的收集、测试和发布等

下图用三个实际场景来介绍基于安全总控中心而构成的实时安全风险管理体系:

通过前面的分析,在安全风险管理活动中,有三种重要的风险“异动”:其一是发生新的安全事件,预示着潜在的安全威胁的变动;其二是新的安全脆弱性(安全漏洞)的出现;其三是新的信息资产上线。下面分别来考察安全总控中心如何来实时处理这三种场景。

新的安全事件
大量的安全事件涌现标志着某种威胁方的活跃。在当前普通的安全体系中,安全管理员很容易被多种安全产品产生的海量安全事件所淹没,没有办法从安全事件中获取背后隐含的安全威胁。而安全总控中心的事件处理模块正是具备了收集、过滤、合并、相关处理海量的、跨产品、跨系统的安全事件的能力。

经过安全总控中心的事件处理,具有高优先级的事件会通过声光、控制台、短信邮件等方式进行集中告警。按照可以配置的既定安全策略,在需要时,安全总控中心会查询内置的资产库以及相应的漏洞库和补丁库,获得事件相关的资产信息,以及相关的漏洞、补丁信息。在获得了相应的资产信息和补丁信息后,总控中心会按照策略通知软件自动分发模块完成自动的补丁分发和安装。对于不能简洁立即处理的告警,将发出工单,呼唤专家介入,进入服务台系统和问题管理流程。

新的安全漏洞
通过实时升级的安全漏洞知识库,获得了最新的安全漏洞信息后,与最新的安全资产库进行相关匹配,如果适用,存在受影响的资产,则查询相关的最新补丁,并且按照策略通知软件自动分发模块完成自动的补丁分发和安装。对于尚没有补丁、却具有高优先级的安全漏洞,发出工单,呼唤专家介入,寻找临时解决方案(Workaround)来处理。

新的资产
某新信息设备上线投入运行,这时,资产自动发现模块发现了这一新的资产,立刻匹配安全漏洞知识库,查看是否具有尚未处理的安全漏洞。如果存在则激活补丁管理模块,进行补丁分发。或者发出工单,呼唤专家介入,对该新资产进行安全加固。

上述三个过程基于策略和规则来自动完成,将发现风险“异动”、产生告警到响应弥补之间的时间窗口减小到最小,将整个过程的人工干预减到最小,大幅节省管理员和主管的精力,使他们可以有时间进行体系规划、策略优化、问题攻关等。

4 综述

层出不穷的安全漏洞和海量的安全事件是当前安全风险管理活动中最具有挑战性的两个领域。如何提高安全风险管理的实时性,减小关键资产面临的脆弱时间窗口是两个重要的课题。安全总控中心提供了大范围的各种主流的第三方安全产品的覆盖,不但包括事件级的集成,还包括多数国际主流安全产品的策略和配置级集成。同时,具备内置的资产发现模块、实时升级的漏洞库和补丁库、安全工单和流程管理系统,能够提供强大的风险控制和管理能力。

本文提出了一种实现实时的安全风险管理的模型和架构,针对典型的安全风险“异动”,从资产、威胁、脆弱性三个方面计算相应的安全风险变化,基于策略的进行实时响应,最大限度地提高安全防御体系的效果和效率。



【老文章】安全管理中心建设中易犯的9个错误

February 8th, 2004 No comments

发表于通信世界,总结了安全管理中心建设过程中的一些心得。
URL= http://www.cww.net.cn/Industry/Article.asp?id=10723
赵 粮
博士,冠群电脑(中国)有限公司
2004-2-18

网络安全正在受到越来越高的关注,其中一个最为热烈的话题就是安全管理中心的建设。安全管理中心(SOC),或者叫作安全总控中心(SCC),通过一个中央管理平台,收集整合来自各种各样安全产品的大量数据,并且从海量数据中提取用户关心的数据,呈现给用户,帮助用户对这些数据进行关联性分析和优先级分析。除此之外,安全管理中心还能够提供相当程度的集中“控制”和“管理”能力,可以帮助提供实时、准实时的安全风险管理能力。

目前,国内外的多家安全公司都提出了安全管理中心的产品或解决方案,移动、电信、联通等多家运营商都正在酝酿该方向的建设项目,几家省公司已经成为先行者。笔者有幸从开始酝酿、设计、建设等整个环节负责、参与了若干个安全管理中心项目,希望将自己的一些体会和经验教训与大家分享。前面已有一篇讨论基于安全管理中心的实时安全体系的讨论,本文从容易出现的九个错误的角度来讨论安全管理中心的建设。

1 错误或者失衡的资源分配和投资比例。

[separator]
我们知道,在绝大多数情况下,安全建设本身不是目的,而是为了保护企业的核心业务和资产。这样从投资的角度讲,投资回报率是必须考虑的。对于一个典型的网络管理中心(NOC)或者计费中心来讲,大约有数十台设备,主要包括各种层面的服务器和工作站,以及存储系统。而经过历次的安全建设和采购后,我们经常可以发现,中心连同分布在各地的防火墙、入侵检测、反病毒,它们的管理器和数据库等,在数量上也达到了数十个,与业务系统的规模相差不大,甚至数量上还可能会超出。虽然单个安全设备的维护工作量比高端服务器要低一些,但是总体上的保护体系和被保护的资产在维护资源上的投入失去了适当的比例。该现象的另外一个表现是大部分省公司、甚至总部还没有专门的安全管理员,IT系统的管理员兼职来维护管理安全设备,再没有足够精力的情况下,安全管理维护方面会被简化、忽略调,不能充分发挥安全投资的效率,间接地降低了安全体系的效果。
另外,可以认为,安全体系由两大类组件组成,其一是功能组件,例如访问控制、身份和认证管理、入侵检测、反病毒等,其二是管理性组件,事件收集和展现、知识管理、工单管理等。管理性组件的目的是提升功能组件的效率,减小相应的管理员人工成本。这个比例在典型安全体系设计中,国际上的比例大概是在10- 30%左右,换句话说,应该注意管理与功能投入上面的平衡。
通过上面的分析,我们知道,过多的功能性组件会导致管理成本过高,管理不利,效果不好;而过多的管理组件投入,又容易功能覆盖不到位,管理组件成为空中楼阁,无源之水。

2 错误的架构、不匹配的组织。
准确地讲,安全管理中心并不只仅仅是某个产品,或者某些产品的集成,它还是一种安全管理形式,需要相应的企业管理组织来负责运营,技术架构和组织架构再设计伊始必须互相匹配,运行的效率才有可能达到令人满意的程度。所以,在总部或者某个省电信公司考虑设计安全管理中心时必须考虑到自己当前的IT管理结构、预期的改变、安全管理的模式。首先在组织结构方面达成共识,再来考虑技术架构,考虑产品的可扩展性,未来是否可以平滑过渡,适应未来的组织结构改变。如下图所示,对于当前的几个主要电信公司来说,都是两级管理体制,省一级实现了集中管理。值得注意的是,安全管理中心并不必然地导向一个对立运作的实体,它可以和网络管理中心合署办公,也可以与企业信息化部或者IT部门合为一体,这依赖于建设需求方管理层参与设计,在建设和运营路线最终达成一致的思路。关键的一点是在开始规划选型时,考虑好以后的接口和平滑过渡,才可以更好地保护投资。

图:安全管理中心架构示意图

3 认为SOC的建设主要是产品安装,对建设中项目风险认识不足。
安全管理中心需要对以前存在的、现在建设中的、甚至规划中可能出现的安全产品进行管理,对多种多样的应用和设备进行事件审计和策略配置,另外,每个建设方对安全管理中心的功能定义也会进行增减,所以,建设过程中往往会涉及到多个厂家的许多产品(包括安全设备和其它)。另外,各个建设方情况千差万别,通常纯粹的安全管理产品很难很好地满足要求,必然会涉及到大量地定制和开发服务,这些对于项目管理来讲,背后都蕴涵着大量风险。需要很好地评估项目风险,并且通过仔细考察集成商和供货商的资质、质量体系和成功经验,慎重选择。

4 设计建设SOC时设施的特点没有考虑IT基础。
各个总部和省公司的IT系统各不相同,不同拓扑结构、不同的网络业务架构、不同的网管系统、不同的集成商、不同的安全防护水平。从IT服务管理(ITSM)的角度来看,它们具有不同的成熟度。从BS7799角度来看,10个安全领域的重视程度又不同。有些省公司已经建设有成熟的帮助台(Service Desk)和流程管理系统,IT系统网管实现了集中监控和集中的事件管理。SOC和NOC在许多方面有共同的特点,可以分享许多建设运营经验,以及IT组件。并且,在许多情况下,在事件管理、流量监视等方面,SOC和NOC共享的程度越高,安全保护的效果就会越好。

5 定义了不适当的项目目标。
一般来说,参照下图所示,安全管理分为四个层次,或者能力成熟度,越高的层次表示安全管理的成熟度越高,残余的安全风险就越低,但是通常来说,要求的安全投入也会较高。第一层是集中审计,能够对全网范围内的关键安全事件做到集中的、统一的收集和审计;第二层是集中监视,除了事件审计之外,还需要对安全防御体系自身的健康状况进行监视,对威胁情况进行监视;第三层是集中管理,在前面两层的基础上,能够对整体安全体系制定安全策略,集中分发配置,与IT基础设施的管理可以无缝集成,实现良好的实时风险管理;第四层是战略防御,除了自身安全体系的审计、监视和管理之外,强调了网络对抗和取证分析能力,针对性的实时优化安全策略。每个层次有不同的特性和实现手段,对于特定的建设环境来讲,并不一定意味着越高的层次就越好,而是应该量体裁衣,具体问题具体分析。可以在四个层次中选择适合自己的特性来分期建设,分步实现目标,达到最高的投资回报。

图:安全管理成熟度示意图

6 集成商和原厂家的技术支持力度不够。
这个问题应该属于项目风险控制范围之内,单独拿出来的目的是想强调一下:一定要慎重考察注意集成商和所选择产品的原厂家的技术支持力度,特别是本地技术支持力度。因为SOC建设中有大量的定制开发和服务,不可避免地需要频繁、有效地技术支持。很大程度上会影响整个项目的质量效果。

7 对选择SOC产品的可扩展性、健壮性、性能没有透彻的了解。
SOC与NOC建设相似,产品更换替代的成本很高,一般会采取升级、扩容、融合等进行发展,全天候7×24运行,越是遭到攻击、产生大量事件和网络负载的情况下越需要SOC的服务,所以在一开始的产品选择阶段要特别注意可扩展性、健壮性和性能的指标。这里的扩展性指能否层次化布署、能否顺利融合部门级的 SOC、是否可以通过硬件升级来实现更高的系统容量等。健壮性和性能是指在遭到大规模攻击、大量事件冲击的情况下,系统能否正常工作,表现如何?系统是否支持高可用性布署等

8 没有设计好相应的管理和应急流程。
我们已经知道,SOC建设远远不只是产品采购,还有许多定制服务。此外,SOC与NOC一样,需要相应的管理和应急处理流程,这些流程制度是整体安全策略的组成部分,应该纳入严格的配置和变更管理之下,并且做好相应的宣传和培训,定期进行演练,使得每个角色和相关人员都明白自己的责任和相关流程。管理和应急流程应该尽可能多地依靠自动化手段实现,并带有质量保证措施和考核措施。在流程设计和建设上面,可以参考ITSM中成熟的服务台技术和产品,充分结合 NOC的流程制度。

9 认为SOC建设完、验收结束就大功告成。
SOC是一种统一集中管理形式,是安全风险管理的最高级形式-实时风险管理。它的建设验收只是实现了第一步。接下来还需要及时地维持并更新、升级知识库(资产库、漏洞库、补丁库等),经常性的优化安全策略,演练应急流程的有效性,审计安全制度的执行落实情况。

安全管理中心是继网络管理中心(NOC)后的又一类引人注目的管理系统,它综合了许多国际标准、安全模型、IT管理技术,属于安全领域的新生事物,无疑需要众多从业者的关注和研究实践,分享SOC发展过程中的经验和教训,更好地指导后面的建设。本文希望能够抛砖引玉,以期获得更多的宝贵讨论。

【老文章】安全管理中心与事件升级制度

December 26th, 2003 1 comment

发表于通信世界,讨论安全管理中心运行过程中流程设计,引入了ITIL
URL= http://www.cww.net.cn/Technique/Article.asp?id=10474

赵 粮
2003-12-26

1 安全事件升级流程
我们已经知道,安全管理中心(SOC),或者说安全总控中心(SCC),是一种安全集中管理的形式,它包含远端安全设备(事件发生)、安全事件收集、事件分析、状态监视、展现报表等重要组件。除技术之外,SOC还有一个重要组成部分就是运行人员、应急小组和专家队伍。所以,SOC与网络管理中心(NOC)一样,需要相应的管理制度和应急处理流程,在应急处理流程中还应该包括明确的事件升级(Escalation)制度。应急处理的每个环节应该定义明确的最大延迟时间,在最大延迟时间内采取有效处理措施。在超过最大延迟时间还没有采取相应措施的情况下,应该立即进行事件升级,进入到更高级别处理。

[separator]
这些制度和流程是整体安全策略的组成部分,应该纳入严格的配置和变更管理之下,并且做好相应的宣传和培训,定期进行演练,使得每个角色和相关人员都明白自己的责任和相关流程。管理和应急流程应该尽可能多地依靠自动化手段实现,并带有质量保证措施和考核措施。

安全事件处理流程的设计是SOC建设的一个重要环节。本文尝试着讨论适用于电信企业的安全事件升级流程的一般内容和形式。

2 安全流程与ITIL
虽然典型类企业在IT系统的结构组织、设备类型、安全风险等方面有许多共同特点,但是各个总部和省公司的IT系统依然有许多不同之处,不同拓扑结构、不同的网络业务架构、不同的网管系统、不同的集成商、不同的安全防护水平。另外,除了上面这些“硬”环境,从IT管理的国际最佳实践库 - IT基础设施库(ITIL)的角度来看,它们还具有不同的能力成熟度。有些省公司已经建设有成熟的帮助台(Service Desk)和流程管理系统,有些系统网管还建立了较为先进的NOC,实现了集中监控和集中的事件管理,而有些电信公司的流程系统和集中监控系统还正在建设或者规划中。

根本上说,SOC的应急处理流程和NOC的原理是共同的,在最高效率处理紧急事件的同时,尽可能少的使用资源,最大限度地发挥各种资源的优势。所以,我们可以分享NOC的许多建设运营经验,以及IT组件。甚至可以说,在事件管理、流量监视等方面,SOC和NOC信息共享的程度越高,安全保护的效果就会越好。

ITIL是当前最为流行、最有权威性的IT管理“标准”。作为一种以流程为基础、以客户为导向的IT服务管理指导框架,它摆脱了传统IT管理以技术管理为焦点的弊端,实现了从技术管理到流程管理,再到服务管理的转化。这种转化具体体现为,ITIL非常强调各服务管理流程与组织业务的整合,以组织业务和客户的需求为出发点来进行IT服务的管理。

下面我们参考IT基础架构库(ITIL)中较为成熟的服务台、事件处理和问题处理最佳实践,并结合NOC运行中的流程制度,设计的一个较为典型的安全应急处理流程框架。

3 安全管理中心的流程设计
从处理方法上来看,安全事件可以分为两种,一是曾经发生过,并且明确知道原因、后果和处理办法的;一种是没有明确的书面记载(问题管理的知识库),没有立即解决办法的。前者可以在网络运行值班层面予以解决,后者则需要按照事件优先级引入临时解决方案,同时进入问题处理流程;在问题处理过程中,安全专家发现了问题的根源,找到了解决方案,则将其进入知识库,同时在适当时机进行发布,更新或者修改安全策略或者配置。

同时,我们知道,事件升级由两种形式,一种是技能性的,平行的,例如普通运行值班人员,到后台技术支持,再到专家队伍,最后到研发实验室等;另一种是管理性的,垂直的,例如运行值班人员,到值班主任,再到负责运维的副总经理,甚至到公司的老总。在事件处理的升级制度中,应该明确定义上述两种事件升级的条件、角色责任、处理方式等,并与工单流程的定义保持一致,保持及时更新。

考察电信企业的实际情况,除SOC所隶属的行政汇报线(垂直升级路线)外,在技能性方面,建议设置三级安全事件响应体系,第一级是安全运行值班人员,可以是网运中心值班人员兼任,负责7×24小时的安全事件监视,按照安全事件的处理手册和知识库处理已知的安全告警事件;第二级是安全应急技术小组,由企业内部安全专家和网络专家组成,负责对第一级发现提交的不明事件(或问题)进行分析判断,完成绝大多数安全事件的处理,对不能及时找到彻底解决方案,需要在将该问题提交第三级以外,还必须及时提出临时解决方案。负责撰写安全问题处理指南,用以指导第一线值班人员的工作;第三级是集团一级的安全实验室和专家小组,负责针对重大安全隐患和网络攻击进行会诊和复现,具备相当的网络对抗能力。同时负责撰写安全问题分析报告,提交安全策略和配置的变更建议。流程框架示意图如下图:

在必要时在第三级可以引入专业安全服务公司的资源。考虑到电信企业信息资产和业务的关键性,笔者不建议在第一级和第二级引入外部资源,而应该自足自我,从集团到省公司一级都能够培养至少2名安全专家。保证可以做到依靠自己的力量可以提出安全建设的需求和规划、总结安全事件和安全问题的处理经验,优化安全策略,能够处理大多数的安全事件。

工单产生后,进入第二级安全技术专家处理的同时,工单系统会通知SOC的运行主任。第二级经过深入分析,根据对业务的影响成都,判定优先级。在规定时间内,没有发现有效解决方案,必须提出临时解决办法,并通知请示运行主任,批准后,与第一级值班人员一起,实施处理办法。实施完毕后,记录工单处理结果。并在规定时间内,撰写报告,呈送公司负责生产运行的副总经理。

在这种情况下,第二级的安全技术专家应该提交安全问题请求,要求第三级安全实验室和其它支持人员、包括服务提供商和国家、地区的计算机事件紧急响应组织等的支持。第三级的安全实验室应该根据问题的严重程度,对安全问题进行模拟和复现,寻求有效问题根源和解决方案。在完成后,更新安全知识库,并负责对第二级和第一级进行知识转移。第二级在接到工单后,经过研究,及时发现了事件根源和解决方案的情况下,也应该及时更新知识库,并对第一级和第三级进行知识转移。

第二级和第三级的安全专家基于安全事件和问题的分析和处理结果,在必要的情况下,需要按照变更管理的制度和流程,提出对受影响的其它类似系统、甚至整体安全体系的安全配置改变,例如策略修改、打补丁等。并保持安全资产库或者配置管理数据库(CMDB)的更新和一致性。

值得注意的是,在第一级值班人员将安全事件向上一级提交后,并不是转移了该事件的所有者(Owner),这里应该遵守“首问负责制”的原则,全程跟踪该事件的处理状态,知道事件和问题解决。事件和问题的移交是交接班的最为重要的内容之一。

知识库是安全管理中心的重要组成部分,它由典型安全事件处理经验、安全问题分析报告、安全脆弱性数据库和补丁库、以及各种技术和管理专题资料等组成。原则上它可以物理上分布在帮助台系统中、也可以是独立的数据库应用。

4 结束语
安全管理中心是当前电信企业安全体系建设过程中的一个热点话题,本文尝试着通过引入国际上成熟的IT服务管理标准和模型,来设计可以用于安全管理中心运行的一种事件升级制度,提高安全事件响应的效率和质量。