基于UML模型的NGN业务安全分析

相比传统的电信网，NGN面临着众多的安全威胁，NGN的业务安全也面临着巨大的挑战。业务的开发和部署需要考虑到更多的安全特性和安全功能。利用UML安全扩展UMLsec对NGN中的业务安全需求进行分析建模，提出了一种细粒度的安全需求分析方法，通过抽象出安全功能抽象类说明NGN业务的安全特性需求。并通过用例讨论了基于安全应用接口的安全需求实现，使得各种安全特性能够更方便、更灵活地集成到业务中。

下一代网络(NGN)是基于分组网络的、多业务融合并开放网络能力的电信网络。其基于分组交换的核心网络为业务融合提供了传输基础设施;其网络能力的开放提高了业务的扩展性，为第三方业务提供者进入电信业务市场提供了良好的契机。但NGN中相对于传统电信网而言松耦合的、开放的业务结构特性和丰富的业务功能恰好与NGN基于通用计算平台和IP传输网络的基础设施在安全架构上形成了矛盾。采用基于IP的分组网络作为业务的承载网络使得许多针对IP网络的攻击行为在电信网络中成为可能，采用通用计算设备作为网络中的控制实体将计算机的安全问题引入到网络中的各个节点[1]。网络能力和业务能力的开放也带来了一系列业务层特有的安全问题。

目前，已经有众多的安全机制用于保证网络和计算设备的安全，但这些安全机制都是针对某一个或某几个特定安全问题和特定的环境设计的，如密钥分配、实体认证、机密性保护、完整性保护等，NGN业务针对不同的业务特征和业务执行环境有着不同的、综合的安全需求。如何理清业务的安全需求，并尽量通过已有的网络安全能力是业务开发者面临的一个问题。

鉴于业务开发过程面临的复杂的安全需求，本文提出使用形式化建模语言UMLsec[3，4]对业务安全需求进行分析，利用建模语言将业务所需的安全特性抽象成安全感知的类，通过这些类表达细粒度的安全功能，通过这些类的组合表达业务的安全需求。这些类的功能通过安全应用接口实现，如GSS-API[5]、NGSS-API[6]，从而将安全特征集成到业务中。以便业务开发者在业务开发过程中摆脱安全机制实现细节的困扰，并且使得开发出来的业务安全特征具备可移植性。

一、NGN业务安全需求分析

1.UMLsec扩展

UMLsec是基于UML标准扩展机制的一个UMLprofile，通过在UML元模型中增加安全相关的约束、标签、定型等建模元素，使用UML图来表达安全相关的语义和系统需求与约束。但目前的UMLsec是基于计算机网络的环境定义的，将其用于NGN业务安全分析中来还需要进行相应的扩展。主要的扩展在于在UMLsec的元素中增加具备与NGN环境相关的定义，使其能够更明确、更有针对性地表达NGN业务的特点与需求。本文中将业务的承载、执行节点定义为NGN中业务的基础架构，并在UML元模型中对这些元素进行定义，如图1所示。

图1 NGN基础架构模型扩展

该扩展针对Link和Node和两个元类增加了NGN中关于承载和节点的定型。可以根据需要对该模型作进一步扩展，如可以增加关于接入网承载的定型等。

2.基于UMLsec的威胁分析

针对图1中定义的定型以及对网络安全构成威胁的攻击者的类型，可以定义出威胁函数TheatA(s)。其中A表示攻击者类型，这里假定攻击者为具备一般能力的外部攻击者，即其可以窃听到广播信道上的数据流量，并可以插入或删除数据流量，能够利用系统漏洞入侵系统;表示为模型中定义的定型威胁函数的值域为{delete，read，insert，access}。根据NGN中承载网络和计算节点的特性，我们可以得出如下威胁函数，如表1所示。

表1 NGN基础架构的威胁函数

攻击者对于IP承载的数据能够执行读写和删除操作，故其能够针对IP承载的业务进行攻击。如攻击者可以修改正常的SIP消息以改变呼叫的路由，发出BYE等SIP消息拆除正常的SIP会话，通过截获RTP承载的语音包并解码以实现窃听，可以在IP网络中插入大量数据降低VoIP的QoS实现DoS攻击，等等。

软设备通常基于通用的操作系统、数据库等软件。这些通用软件以及协议栈的实现都可能具备能被攻击者利用的漏洞。通过这些安全漏洞，攻击者可以对这些设备发起拒绝服务攻击(DoS)或获得设备的访问权。

由于NGN的基础设施针对一般攻击者的攻击函数值通常都不为空，因此需要在业务开发和部署时利用安全机制来保证业务的安全。

3.业务的安全需求分析

业务的安全需求可能包括用户信息的机密性、完整性、业务本身的可用性等方面。NGN中不同类型的业务有着不同的安全需求，如会话类业务的主要安全需求是可用性，消息类业务的主要安全需求是完整性。同一类型的业务其安全需求应该也是可以根据业务场景定制的，如普通两方呼叫要求即使在网络中出现入侵的情况下也应保证呼叫的正确路由，并确保语音流的服务质量。而如果用户要求呼叫需被保密，则还需保证信令消息的机密性和语音流的机密性，需要对信令和语音流进行加密处理。不同业务的安全需求是安全特性的组合。利用建模语言，业务所需要的安全特性可以抽象成为安全感知的类来表示。这些类中的功能可以使用安全应用接口提供的安全能力实现，而业务的安全需求则表示为类的组合。为了清晰表达业务的安全需求，并便于业务安全需求的实现，本文将业务的安全需求抽象为细粒度的安全功能类，每个安全功能类表达了业务对其各个组件(如信令、媒体、业务功能等)的不同安全特性(如机密性、完整性、认证等)的需求。

下面以基于SIP的两方会话为例说明如何使用UMLsec描述业务安全需求。假定两方呼叫发生在同一SIPProxy辖域的两个用户之间，要求保证用户UA与SIPProxy之间的信令的完整性，不能被非法入侵者篡改。该场景的用例图和部署图分别如图2、图3所示。

图2 信令完整性用例图

图3 信令完整性保护部署图

图3中的UA代表UserA或UserB的UA，因为两个UA的信令交互需要通过Proxy，且其安全需求是一致的，故在图中只表现出一方。UA和Proxy均是基于通用计算平台的节点，其访问控制需要受到保护，故对其标记上定型《guardedaccess》。UA中除处理信令外，还需处理媒体流的编解码与控制，这个用例中只涉及信令的安全性，故在UA中只关注进行信令控制的组件。UA与Proxy之间的通信基于IP承载，根据表1定义的威胁函数：ThreatA(IP Carrier)={delete，read，insert}，信令的完整性在攻击下可能遭到破坏，需要采用相应的安全机制对信令交互加以保护。

Sender类和Receiver类是通过对通信安全功能的抽象而得出的两个类。这两个类具备保证发送方和接收方之间消息传送的完整性的安全能力。通过在UA的信令控制功能和Proxy的呼叫控制功能中聚合这两个类，可以在高层的需求层面上满足UA和Proxy通信的信令完整性需求。

AccessGuard类是用于隔离对保护对象的访问的类，通过在被保护对象上标识{guard=AccessGuard}标记，所有的对保护对象的访问请求需先提交给AccessGuard类，AccessGuard类根据具体的访问控制机制和访问控制策略进行访问权限的判定后，访问请求才能在被保护对象上执行。

Sender类和Receiver类可以针对业务对安全需求的不同控制粒度进一步细化，通过对send()方法的重载加以实现。如在调用send()方法时可以使用QoP[5，7](QualityofProtection)参数说明业务对安全功能的保护级别的需求。QoP体现了处理安全问题的开销与安全保护需求之间的动态平衡。某一级别的QoP可以对应于某一具体安全机制中所采用的加密算法强度、密钥长度、认证机制强度等。但目前QoP的定义还依赖于具体的安全机制，且具有一定的随意性，没有一个客观的标准。

来源：天极网