S. Erfani, ECE Dept.

, University of Windsor 0688-590-18 Network Security

Security Functional Architecture

1. INTRODUCTION
Computer network security comprises a set of complex procedural, logical and physical
measures (at different levels of the network interfaces and different layers of network
protocols). Such measures are used to prevent, detect and correct known (and some
unknown) threats along with the tools to install, operate and maintain these measures.

Security services are remedies and countermeasures by which security threats are
countered. Each security service uses one or more security mechanisms to counter
security attacks or threats. In today’s network, various stand-alone security servers
and/or proxies are used to provide some sort of piecemeal security, such as an
authentication server or an authorization and access controller.

Traditional security systems implementing one single security service and relying on
rigid conventional encryption techniques and mechanisms simply cannot address security
needs of the evolving enterprise networks of today's when the data travels across public
networks. The key to a successful security system design is to consider the security
management as an evolving integrated process.

In this chapter, we propose to use a layered functional architecture approach to design a

Security Management System (SMS) for enterprise networks. The proposed SMS
architecture is a logical function architecture that is modular and whose specifications of
the interconnections and interoperability of security services makes it possible to
compose software applications from products developed and/or modified by different
suppliers at different times. The design goals of this modular security management
architecture are to achieve the following features:
a) Many security services
b) Many security mechanisms with different efficiency and different level of
security
c) Wide-range of management functions
d) Full integration with Network Management Systems (NMS)
e) Security policies access from NMS
f) Abbreviated security management from NMS
g) Efficiently utilizing different security mechanisms by different security
services
h) Transparent to users and applications
i) Easily applicable to any type of operational environment
j) Designed and structured in a modular way to be used by larger customer base
k) Flexible, expandable, and adaptive to network changes, enhancements, and
new policies
l) Adaptive to new mechanisms and new security services

Security mechanisms are effective techniques and schemes used to implement a given
security service with different degrees of complexity. For example, an abstract service
like data confidentiality might be implemented using either the secret key data encryption
mechanism or public key data encryption scheme.

Sep. 11, 2003 1

 S. Erfani, ECE Dept., University of Windsor 0688-590-18 Network Security

In most practical cases, a combination of security mechanisms is needed for

implementing an effective security service. For example, an authentication service can
be implemented with either strong mechanisms or with weak mechanisms (low, medium,
or high security). In practice, it is quite common that more than one security service use
the same mechanism. Table 1 indicates applicable mechanisms that may be used to
implement a service.

Table 1. Security Mechanisms for Implementing Security Services

CONFIDENTIALITY INTEGRITY & ACCESS NON-REPUDIATION AUTHENTI-

SERVICE & PRIVACY PROTECTION CONTROL & & CATION
AVAILABILIT ACCOUNTABILITY
MECHANISM Y
Access Control Y Y Y
Mech.
Digital Y Y Y
Signature
Encryption Y Y Y Y
Mech.
One-Way Hash Y
(OWH)
Certification Y Y Y
Password Y Y Y Y
Techniques
MAC Y Y Y Y
Key Exchange/ Y Y Y
Generation

Note: Y means "yes," it applies.

In Section 2, we describe the SMS functional architecture. Section 3 describes the

modular design of each functional layer, and Section 4 defines a Security Management
Information Base (SMIB) for SMS. Security protocols and interfaces are discussed in
Section 5. Finally, we conclude the chapter by summarizing the results in Section 6.

2. SECURITY MANAGEMENT FUNCTIONAL ARCHITECTURE

The proposed functional architecture is a logical security management system (SMS)
architecture that provides multiple security services for multiple applications in a
multiple operation environment. This structured approach to security provides flexible
and multilevel security services for enterprise-wide security.

Basic architectural elements of SMS, as shown in Figure 1, are: 1) Functional Layers to

accommodate security functions required, 2) Security Management Information Base
(SMIB), and 3) Security Protocols and Standards-Based Interfaces.

This way, a total security functional set is provided, which supports many aspects of
security across the enterprise network and security perimeter. The structure provides a

Sep. 11, 2003 2

 S. Erfani, ECE Dept., University of Windsor 0688-590-18 Network Security

security management system that can accommodate anticipated security services,

extensions, and enhancements. The proposed layered architecture provides flexibility to
respond to new security concerns as they arise and to upgrades as new technologies
become available and cost-effective.

A fundamental property of SMS is to be used as a comprehensive autonomous security

server, as it may provide security to multiple applications at the same time. Because the
format of exchanging messages and data used by various applications tends to vary from
application to application, in the SMS, a protocol handling function is provided across all
the five layers for communication with the users, agents, and the operation environment.

SMIB
Security
Policy
Layer 5 Security Policy and Business Requirements SMIB segments

Security

Layer 4 Security Management Management

SMIB segments

Security
Services
Layer 3 Security Service SMIB segments

Security
Layer 2 Security Mechanism Mechanisms
SMIB segments

Primitive
Layer 1 Security Primitive Modules Module
s segments
SMIB

Figure 1. Security Management System Architecture

3. FUNCTIONAL LAYERS OF SECURITY MANAGEMENT

At the highest-level of abstraction, a security management functional architecture that
conforms to the SMS architecture provides software applications either for one or more
of the five logical layers, or for the infrastructure. Each layer is made of one or more
well-defined, deployable, and interoperable functional units called "modules" with well-
defined interfaces. Interactions among modules in a layer need to be defined. In this
case, any module can communicate with any other module. Modules use the services of
an infrastructure of independent lower-layer functions to support their own offered
functions and to communicate among themselves. A physical realization of the SMS
architecture can contain multiple modules at each layer.

Sep. 11, 2003 3

 S. Erfani, ECE Dept., University of Windsor 0688-590-18 Network Security

3.1 Layer 5 - Security Policy and business requirements

The uppermost layer in designing an enterprise security system is security policy and
business requirements function. This function determines the general goals for each level
of security, as set by the overall user/corporation security vision.

Once this layer is defined, multiple security policy modules can be attached to address
policy requirements and to support the many aspects of security across the enterprise
network. In general, this function layer contains enterprise-wide security assessment and
plans. This layer can also include physical security aspects like security guards, closed-
circuit TV, and card-key entry systems. In addition to the above defined generic
functions, it can include various individual modules such as prevent and detect security
violations, disaster recovery, personnel risk analysis, legal views and actions, as shown
in Figure 2.

Prevent and detect Disaster Personnel

Security Violations Recovery Risk Policy

Enterprise-wide Legal Views

Risk Policy and Actions

Figure 2. Layer 5 - Security Policy and Business Requirements

Note that rule-based techniques can be used as part of the security violation detection and
prevention module to detect intrusion by observing events and applying a set of rules to
make a decision whether a given pattern of activities is suspicious. Rules can also be
defined that identify suspicious behavior. Clearly, "security violation detection" and
"security violation prevention" modules can benefit from expert system technology a lot.
Rule-based threat detection does not require knowledge of security vulnerabilities within
security domain -- it is based on observing the past pattern and assuming that the future
will be like the past! However, past experience, shows that a large number of rules
required implementing this approach effectively.

3.2 Layer 4 - Security Management Function

This layer is concerned with security aspects which are outside normal scope of security
services, but which are needed to support and control security services and mechanisms.
Security management function involves:

a) Provision of security services, control and distribution of security-related

information in real-time and per pre-specified schedules.
b) Event logging, both for normal and abnormal situation.

Sep. 11, 2003 4

 S. Erfani, ECE Dept., University of Windsor 0688-590-18 Network Security

c) Administration and management of various modules in lower layers, e.g.,

parameter management for security mechanisms like cryptographic keys.
d) User interface management.
e) Security monitoring for various security services.
f) Key and Security (state) recovery in case of violation.
g) Interaction establishment between different security management systems
through use of appropriate security management protocol(s).

Control and Event Logging Parameter

Monitoring
Distribution Management
Service Mechanism
User Interface Management Management Recovery

Figure 3. Layer 4 - Security Management Function

Each of the above tasks may be implemented via a corresponding module in this layer, as
shown in the Figure 3.

3.3 Layer 3 - Security Service Function

This layer provides a platform to implement various security services. Each security
service can be designed and implemented as an autonomous self-contained functional
module to provide the "plug-and-play" capability. Although, nothing prevents
interactions among various service modules, when it calls for. Each module is called
using appropriate protocols and procedures. In Figure 4, most widely-used security
services are shown. ISO standards defines the following six basic security services:

1. Confidentiality Service - is the protection of transmitted information from

passive attacks.
2. Integrity Service - generally provides protection against message
modification for connectionless communications, and provides protection
against duplication, insertion, modification, reordering, or replay for
connection-oriented communications.
3. Access Control Service - is the ability to limit and control the access to host
systems and applications via communication links.
4. Non-repudiation and Accountability Service - prevents either sender or
receiver from denying a transmitted message.
5. Authentication Service - is concerned with assuring that a communication is
authentic.
6. Availability and Non-denial-of-Service - is concerned with assuring that
prescribed authorized services are available to authorized users.

Sep. 11, 2003 5

 S. Erfani, ECE Dept., University of Windsor 0688-590-18 Network Security

These are generic groups of services, since each service may be applied in different
variations to different entities, situations, and resources. All security services can be
implemented in a form of a security library, interfacing to the upper applications by the
corresponding Application Programming Interfaces (APIs). In addition, security services
such as packet filtering, firewalling, and intrusion detection may be needed to be
implemented as an autonomous server in different part of a network.

Authentication Confidentiality Intrusion

Service Service Detection
Service
Non-denial
Integrity Non-repudiation of Service Access Control
Service Service Service
Figure 4. Layer 3 - Security Service Function

3.4 Layer 2 - Security Mechanism Function

As mentioned before, there is no single mechanism that will provide all the functions
required for the security services. In fact, as the number of security services in layer 3
increases, a variety of mechanisms come into play.

This layer of the SMS architecture implements various security mechanisms with
different efficiencies, degrees of security and computational complexities. For instance,
some services may use weak but efficient mechanisms; others may use strong but slower
mechanisms. It is also possible to make certain mechanisms mandatory, and others
optional. However, cryptographic techniques underlie most of the security mechanisms
in use.

This layer can include various generic common modules to be used by the security
service function (layer 3). Examples of these modules, as shown in Figure 5, are:
1. Public-Key Encryption: RSA, ECC, Rabin, ElGamal algorithms
2. Symmetric One-Key Encryption: DES, Triple DES, FEAL, IDEA, RC2, RC4,
SKIPJACK techniques
3. Message Authentication Code: CBC-MAC, MAA, RIPE-MAC
4. Password techniques, Biometrics mechanisms
5. Digital Signature: DSA mechanism
6. Access Control: access control matrix (ACM), access control list (ACL),
conditional access mechanism

The sequence of executing security services and mechanisms, depending on the

operational environment and the security perimeter, may be different and results in
different security considerations. For example, a digital signature can be generated for a
given plaintext message and pretended to the message. Then, the plaintext message plus
signature can be encrypted using a particular session key. This sequence can easily be

Sep. 11, 2003 6

 S. Erfani, ECE Dept., University of Windsor 0688-590-18 Network Security

reversed. Alternatively, the plaintext message can be encrypted first and then generate a
digital signature for the encrypted message. Thus, the order of applying encryption and
digital signature mechanisms to the message is dependent on security requirements. SMS
provides this flexibility for an end-user or an application.

Cryptographic mechanisms are also included in this layer. They include key-exchange,
public-key encryption, and symmetric-key encryption, and deserve to be treated as a sub-
layer because a number of security service modules (and mechanisms on this layer) relay
on the use of conventional encryption. For example, public key certification is a
mechanism that required for certificate authorities, and key-exchange/generation, is the
fundamental technique required for establishing a session encryption key.

CBC-MAC RSA Diffie-Hellman

MAA ElGamal Preshared
RIPE-MAC Elliptic Curve Key Public/Secret Key Gn.
DSS Key
Ex./
Exchange/Generation
MessageAuth. Code Digital Signature

Public Key
One-Key
Simple Cond X. 509V.x
Access ECC
Handsha Acc. Cont. List DNS
ke Rabin
Biom Acc. Cont. M.
Certificate
W3C Dsig
Password
Techniques et Access Control
Mechanism
Encryption

Figure 5. Layer 2 - Security Mechanism Function

Each mechanism, in turn, can contain various algorithms and schemes to be used, based
on different mode of operation. For example, a typical MAC module may contain a
Cipher Block Chaining MAC (CBC-MAC), MAA, and RIPE-MAC, as shown in Figure
5.

3.5 Layer 1 - Security Primitive (Mathematical) Function

This is the lowest layer of the SMS functional architecture. This layer provides a
platform to implement basic mathematical operations and algorithms that are used in
conjunction with cryptographic techniques. Layer 1 contains elementary atomic
modules, as shown in Figure 6. These modules are needed for cryptographic algorithms
and special protocols. Examples of these general-purpose modules are:
1) One-Way Hash (OWH): MD5, SHA-1, MDC2, MDC4, RIPE-MD methods
2) Public Key Fundamental Modules: Fast Exponential, Pseudorandom Number
Generator, Test for Primality
3) Math Library Modules: Chinese Reminder Theorem, Multipicative Inverse,
Modular Multiplication, and other operations with large numbers
4) Encryption Fundamental Modules: DES, Triple DES, IDEA, AES,
RC2/RC4/RC5, FEAL

Sep. 11, 2003 7

 S. Erfani, ECE Dept., University of Windsor 0688-590-18 Network Security

Fast Exponentiation Chinese Remainder Theorem DES/Tri-DES

MD4/MD5
Multiplicative Inverse IDEA
Prime Number Testing SHA-1
Random Number AES
Modular Multiplication RIPE-MD
Generators RC2/RC4/RC5
Math Library One-Way Hash Fundamental
Modules FEAL
Encryption Fundamental Modules

Figure 6. Layer 1 - Security Primitive (Mathematical) Function

3.6 PGP Realization
PGP (Pretty Good Privacy) is a freeware providing compatibility, compression, and
segmentation for electronic mails. In addition, PGP provides confidentiality and
authentication services. To illustrate usefulness of the layered model, and also, how a
security service can be implemented (or threaded through) the above layers consider PGP
application using SMS.

Let us consider both confidentiality and authentication services are applied to the same
message using SMS. In this case, the sender first signs the message with its own private
key, then encrypts the message with a session key, and then encrypts the session key with
the recipient's public key, as described in the following steps:

1. The sender invokes SMS authentication service in Layer 3 for a created message.
2. The SMS authentication service calls on the SMS Message Authentication Code
mechanism in Layer 2 to use the MD5 fundamental security module in Layer 1 in
order to generate a 128-bit hash code of the message.
3. The message digest is encrypted with RSA digital signature mechanism in layer 2
(see Figure 7), using the sender's private key, and the result is prepended to the
message.
4. Note that, RSA, in turn, uses Fast Exponentiation (FE) and Chinese Remainder
Theorem (CRT) in the Math Library module of Security Primitive (Mathematical)
Modules layer for computation.
5. The SMS confidentiality service in Layer 3 is used to invoke the Key-
Exchange/Generation mechanism in Layer 2 to generate a random 128-bit number to
be used as a session key for the signature and plaintext message.
6. The Key-Exchange/Generation module of Layer 2 needs to invoke Public Key
Fundamental Modules in Layer 1 for random number key generation and testing.
7. The SMS confidentiality service encrypts the plaintext message plus signature using
IDEA (in Encryption Fundamental Modules in Layer 1) with the generated session
key. The session key is encrypted using RSA in Layer 2.

The interactions between functional modules are shown in Figure 7.

Sep. 11, 2003 8

 S. Erfani, ECE Dept., University of Windsor 0688-590-18 Network Security

Security
Policy
Security Policy Levels SMIB segments

Control and Distribution Parameter Management Security

Management
User Interface Management SMIB segments
Security Management Layer Mechanism Management Service Management

Integrity Service
Security
Data, Message and Traffic Flow
Services
Confidentiality Service Non-Repudiation SMIB segments
Data, Message and Traffic Flow
Service

Diffie Hellman
Mechanisms

DSS

One-Key Encryption Mechanisms

Security
Public/Secret Key Mechanisms
Encryption RSA Exchange/generation SMIB segments
Key-Exchange/Generation
Key-Exchange
Digital Signature

Fast Exponentiation Chinese Remainder Theorem Fundamental

Multiplicative Inverse Security
IDEA MD5 Prime Number Testing
Random Number Modules
Modular Multiplication SMIB segments
Generators

SMIB
Figure 7. PGP Realization Using SMS Functional Architecture

4. SECURITY MANAGEMENT INFORMATION BASE (SMIB)

An important component of SMS, or any security management architecture for that
matter, is its security management information model. SMS will include a Security
Management Information Base (SMIB). The conceptual segments of an SMIB are IDs for
network secured resources, user profiles and privileges, secure associations, access
control list, and security logs. Note that this concept does not suggest any content or
form for the storage of information, its implementation or usage, other than emphasizing
the security data needs. Clearly, SMIB must be structured to support implementation of
all security services and mechanisms in a computing environment or a communication
environment. Also, SMIB must work in a manager/agent relationship to support other
MIBs in use.

Sep. 11, 2003 9

 S. Erfani, ECE Dept., University of Windsor 0688-590-18 Network Security

SMIB

X.500 Elements
for Identification

X.509 Recommendation
for Authentication

Extended X.500
Information Base

SMIB Segment

Figure 8. SMIB

As mentioned above, the SMIB is a repository of all control information and parameters
necessary for normal functioning of the security system. The SMIB contains the security
profiles of the system/network, security parameters, and logical associations among
security entities. At least, a combination of the X.500 and X.509 recommendations could
be used as shown in Figure 8.

5. SECURITY MANAGEMENT SYSTEM INTERFACES

There are interactions amongst the SMS functional layers as well as between the
functional layers and the security environment and the SMIB. As shown in Figure 9,
there are at least three types of transactions present in the SMS:
a) message interactions,
b) protocols, and
c) interfaces.

Message Interaction - In order to cooperate, modules in functional layers must mutually

communicate. One possibility is that for the communicating layers to send direct
instructions to each other and receive the return status. Another high-end possibility
would be to use a well-defined protocol between modules in different layers. Therefore,
depending on implementation environment, this inter-function communication can be as
simple as a "function call" in C Language or an inter-object message, or can be as
complicated as a secure protocol requiring full-fledge protocol definition. In either case,
message sets must be clearly defined.

Security Protocol - Security protocols are generally defined as interactions between the security function
modules and the securing entities (users, applications, other security modules, etc.). The SMS needs
security protocols for communication with i) user, ii) security domains, i.e., LAN, WAN, managing
applications, Network Management Systems (NMS) stack, etc., iii) SMIB, and iv) host operating
system. Note that we did not include security protocols in functional architecture of SMS, because they are
means to implement security services rather than tasks to implement security. However, if a module uses

Sep. 11, 2003 10

 S. Erfani, ECE Dept., University of Windsor 0688-590-18 Network Security

services of one or more security protocols, security protocol handling capabilities need to be provided in
that layer.

Interface - The SMS must be able to interface with various applications and operations environments.
The interfaces should be designed between SMS and SMIB, between SMS and other (NMSs) and
applications, and for host machines. It is important to notice that the SMS should be accessible from any
layer of communication protocol that needs security services. For example, it is possible for Transport
Layer to request data encryption services from SMS. This type of interface requirements can be
implemented using an appropriate API. This API module need to be so designed as to be able to handle
these requests and put them into the format required by the SMS. Typically, the API modules for various
applications and operational environment will differ, so each application needs its own interface module to
the SMS.

Provisioning for appropriate interfaces and API modules add extra complexity to the SMS functional
architecture and will not be discussed here.

Security
Security Policy and Business requirements Interface
Policy
SMIB segments
Layer 5
Interactions
NMS Stack Security
Management
Security Management
Protocols

Interface SMIB segments

Layer 4
Interactions
Host OS Security
Services
Layer 3
Security Service Interface SMIB segments

Interactions

Security
Security Mechanism Interface
Mechanisms
SMIB segments
WAN Layer 2
Interactions

Mathematical
Layer 1 Security Primitive Modules Interface Modules
SMIB segments

LAN SMIB

Figure 9. SMS Interfaces and Interactions

Sep. 11, 2003 11