Institutionen för systemteknik
Department of Electrical Engineering
Master of Science Thesis
Supervision of Equipment in O&M Infrastructure
Master thesis performed in information theory
byLove Thyresson
LITH-ISY-EX--07/3988--SE
Linköping 2007
TEKNISKA HÖGSKOLAN
LINKÖPINGS UNIVERSITET
Department of Electrical Engineering Linköping University
S-581 83 Linköping, Sweden
Linköpings tekniska högskola Institutionen för systemteknik 581 83 Linköping
Supervision of Equipment in O&M Infrastructure
Master thesis in information theory
at Linköping Institute of Technology
by
Love Thyresson
LITH-ISY-EX--07/3988--SE
Supervisor: Mats Gustafsson Examiner: Viiveke Fåk
Presentation Date
2007-06-04
Publishing Date (Electronic version)
Department and Division
Department of Electrical Engineering Information theory
URL, Electronic Version
http://www.ep.liu.se/exjobb/isy/07/3988
Language
X English
Other (specify below)
52 Number of Pages Type of Publication Licentiate thesis X Degree thesis Thesis C-level Thesis D-level Report
Other (specify below)
ISBN
ISRN: LITH-ISY-EX--07/3988--SE Title of series
Series number/ISSN (Licentiate thesis)
Publication Title
Supervision of Equipment in O&M Infrastructure
Author(s)
Love Thyresson
Abstract
The COMInf network is the infrastructure part of the operation and management system used for guarding the radio access networks developed by Ericsson. This thesis investigates the Ericsson COMInf network; identifies problems covering both functional as well as security aspects of the network and its current monitoring solution, and also presents a set of requirements and recommendations for a future network surveillance solution.
As this thesis shows, the COMInf network today has limited functions regarding both network and security supervision. However, implementations of such solutions are possible due to the standardized components used in the network today. To improve the COMInf network, this thesis defines requirements and recommends a network surveillance solution which fulfills these requirements. It is also recommended to update some of the hardware currently in place for the COMInf network.
Abstract
The COMInf network is the infrastructure part of the operation and management system used for guarding the radio access networks developed by Ericsson. This thesis investigates the Ericsson COMInf network; identifies problems covering both functional as well as security aspects of the network and its current monitoring solution, and also presents a set of requirements and recommendations for a future network surveillance solution.
As this thesis shows, the COMInf network today has limited functions regarding both network and security supervision. However, implementations of such solutions are possible due to the standardized components used in the network today. To improve the COMInf network, this thesis defines requirements and recommends a network surveillance solution which fulfills these requirements. It is also recommended to update some of the hardware currently in place for the COMInf network.
Acknowledgements
During the course of this thesis work I have had help from a number of people.
I would like to thank my supervisor at Ericsson, Mats Gustafsson for helping me with contacts and feedback throughout this thesis project. Of course, I would like to thank Viiveke Fåk, my examiner at the University of Linköping for providing valuable insight on my report and guiding me in the right direction. To Stefan Werna, my manager; a big thank you for giving me the opportunity to do my thesis project at Ericsson. Also, Mark Brocklebank deserves much credit for giving me great insight into the work being carried out at Ericsson UK.
Naturally, I would also like to thank Fredrik Lindholm, my opponent, and last but not least, I would like to thank Shreya Pallavi who has been a constant pick-me-up during the many days of this project.
TABLE OF CONTENTS
1. INTRODUCTION ...1
1.1. ABOUT THIS THESIS...1
1.2. PURPOSE...1 1.3. PROBLEM DESCRIPTION...1 1.4. CONTRIBUTIONS...2 1.5. PRIOR WORK...2 1.6. SCOPE...3 1.7. OUTLINE...3 1.8. READING INSTRUCTIONS...3 2. COMPUTER SECURITY ...5 2.1. BACKGROUND...5 2.2. THE CIAMODEL...5 2.3. TRUST...5 2.4. THREATS...6 2.5. SOFTWARE SECURITY...6 2.6. SECURITY AWARENESS...7 3. NETWORK SECURITY ...9
3.1. ANALYZING AN ATTACK:THE FIVE P:S...9
3.2. INTRUSION DETECTION SYSTEM...10
3.3. INTRUSION PREVENTION SYSTEM...11
3.4. IDS AND IPSDETECTION...11
4. NETWORK MANAGEMENT ...13
4.1. REQUIREMENTS FOR A NETWORK SURVEILLANCE SYSTEM...13
4.2. FCAPS ...13
4.3. SIMPLE NETWORK MANAGEMENT PROTOCOL...15
5. COMMON OPERATIONS AND MAINTENANCE INFRASTRUCTURE ...19
5.1. OVERVIEW...19
5.2. SERVICES...20
5.3. AUTHENTICATION SERVICES...20
5.4. NETWORK INFRASTRUCTURE...21
6. ANALYZING THE COMINF NETWORK...23
6.1. COMINF NETWORK COMPONENTS...23
6.2. COMINF SERVERS...25 6.3. SECURITY MECHANISMS...25 6.4. CONCLUSION...26 7. REQUIREMENTS ...27 7.1. BACKGROUND...27 7.2. RISK ASSESSMENT...28 7.3. DRAFT REQUIREMENTS...28
7.4. RATING THE REQUIREMENTS...31
7.5. ANALYZING THE REQUIREMENTS...36
7.6. FINAL REQUIREMENTS...36
7.7. SECURITY CONSIDERATIONS...40
7.8. REQUIREMENT CONCLUSIONS...41
8. EVALUATION OF CANDIDATE SYSTEMS ...43
8.1. EVALUATION CRITERIA...43
8.2. EVALUATION CONCLUSIONS...44
9.1. RECOMMENDATIONS...47 9.2. FUTURE WORK...48 10. GLOSSARY ...49 11. BIBLIOGRAPHY...53 11.1. REFERENCES...53 11.2. LINKS...54
Chapter 1 - Introduction
1. Introduction
This chapter gives a brief overview of the structure and purpose of this thesis. It also includes reading instructions which can be found in section 1.8.
1.1. About This Thesis
This Master of Science thesis has been carried out as the final part of the author’s masters’ degree in computer science at the University of Linköping in spring/summer of 2007, Linköping, Sweden.
1.2. Purpose
Ericsson AB is the worlds leading developer and provider of mobile radio networks. These radio networks may cover large areas and are often an important part of a nation’s infrastructure. Because of the extreme demands regarding system uptime; supervision and security are both very important factors in preventing different kinds of system failure.
As a provider, Ericsson needs to be able to guarantee system uptime, i.e. avoid outage and downtime because of failure related either to the systems itself, or due to external threats. In order to meet these requirements Ericsson uses a operation and maintenance system called Operations Support System, Radio and Core (OSS-RC). A specific part of this system is the Common Operations and Maintenance Infrastructure (COMInf).
The primary tasks of COMInf are:
• To provide infrastructure services to OSS-RC and radio access networks • To provide a strong security separation between the radio access networks and
the mobile operators
In critical systems such as OSS-RC, all system maintenance and configuration must be carried out during system operation. Ericsson has the ambition to guarantee a 99.999% system uptime. This corresponds to approximately 5 minutes downtime a year, including planned system upgrades.
Since COMInf is such a vital component to keep the radio network operational, Ericsson is interested in ways to supervise COMInf operation.
1.3. Problem
Description
COMInf is an essential part of the Operations and Maintenance (O&M) section of the radio networks, weather it be second generation Groupe Spécial Mobile (GSM) or third generation Universal Mobile Telecommunications System (UMTS). The purpose of the COMInf network is to provide services and infrastructure components for the O&M network.
Chapter 1 - Introduction
COMInf in itself is made up of a variety of servers, often deployed in a redundant fashion. The COMInf network can be deployed in several different ways depending on customer requirements.
In order to ensure the stability of the radio access network, the stability and security of the COMInf network is important. In case of failure of the COMInf network, either by failure during normal operations, or due to unauthorized modification of the system, the functionality and stability of the radio access network is at risk.
Today, the hardware and software versions in the COMInf network may differ between installations. Even though the initial versions deployed are based on an official Ericsson release, software may be patched and/or upgraded based on customer requirements. Because of the variance in COMInf setups, maintenance, as well as ensuring network stability, grows increasingly difficult.
To simplify maintenance of the COMInf network, it is desired to automate the process of making software and hardware version inventory. It is also desired to get real time status for the hardware and software processes running in the COMInf network. As the COMInf network is critical for the O&M of the radio access network, security aspects are also essential.
1.4. Contributions
This thesis investigates solutions to the problems identified in chapter 1.3. It formulates a set of system specific requirements and develops a rating system for measuring these requirements.
Finally, this report presents a list of recommendations for both a network surveillance solution as well as future work.
1.5. Prior
Work
Solutions for monitoring and analyzing networks exist today. The predominant underlying technology used is Simple Network Management Protocol (SNMP), SNMP is a technology for supervision and control of network devices. This protocol has been standardized by the Internet Engineering Task Force (IETF) and is currently at version 3. SNMP is explained in more detail in chapter 1.
While there exist solutions for security supervision, none of them are as standardized as the surveillance solutions that exist for the network devices. Security supervision is still an area under rapid development. An overview of some of the existing solutions is presented in chapter 3.
Chapter 1 - Introduction
1.6. Scope
This thesis will be limited to supervision and security aspects of the Ericsson COMInf network. It does not cover network setup and/or design, nor shall it be used as a general guide for either network surveillance or network security.
1.7. Outline
This thesis is divided into 11 chapters.
Chapter 1 presents the goal of this thesis project, its purpose, scope, outline and reading instructions. Chapter 2, 3 and 4 provides theory on both computer and network security as well as network management while chapter 5 presents a common COMInf setup.
Chapter 6 moves on to analyze the COMInf network and in chapter 7 requirements for a network surveillance solution is presented. Chapter 8 begins to evaluate some candidate systems. Finally, chapter 9 concludes this thesis project and gives some future recommendations for future COMInf development.
Chapter 10 and 11 provides glossary and bibliography for the terms and references used throughout this report.
1.8. Reading
instructions
For staff within Ericsson and more specifically within COMInf development chapters 1, 7, 8 and 9 might be of interest.
For people interested in network management and security in general, suggested reading is the complete report.
Chapter 2 - Computer Security
2. Computer Security
To be able to understand the different terms and aspects of computer security, primarily in the field of network surveillance, this chapter provides fundamental definitions frequently used in this topic.
2.1. Background
As a basis for this rapport, this thesis uses the definition from “Computer Security – Second Edition” by Dieter Gollmann, [3].
2.2. The
CIA
Model
To main three values that need to be protected in a computer system are: • Confidentiality
The task of preventing harm from unauthorized disclosure of information. • Integrity
The task of preventing harm from unauthorized and accidental modification of information and provide consistency.
• Availability
The task of preventing unauthorized withholding of information or resources. The different areas of the CIA model correspond to the three main values in computer security. Sometimes, a fourth aspect is mentioned:
• Non-repudiation
This deals with the problem of proving that some specific individual has indeed performed a certain task, e.g. a bank transfer. However, for the scope of this thesis, the definition used only includes the CIA aspects.
2.3. Trust
Computer security is based on the notion of trust, or rather, lack of trust. Systems are secured using different techniques to eliminate the need for trust in hardware, software and users – and ultimately provide all of the three CIA aspects.
Security in computer systems can be defined using a chain of trust. The chain of trust has to cover everything from the hardware and software installed on the machine to the person using the machine. If any of these trusted sources fail in some way, the chain of trust will be broken and hence, the system can not be considered secure. As all users of a system have to be trusted to be able to provide security, this makes multi user systems an especially difficult area to protect as every single user has to be trusted. Today, this task is most difficult, due to the exposed environment in which most computers exist, i.e. the Internet. This does in turn force computer systems to eliminate the trust in the user by the use of secure hardware and software.
Chapter 2 - Computer Security
2.4. Threats
Kerry & Greg categorize an attack on a network based on its origin; intrusions, insider attacks and abuse, [1]. It is important to distinguish between these three types as the protective measures required often are quite different. The different techniques used are explained in more detail in the following chapter.
2.4.1. Intrusion
A typical example may be an individual trying to breach into a company’s computer system to steal sensitive information. This person has no prior access to the company’s systems and has to penetrate everything from the firewall protecting the network to individual servers inside the network to accomplish his/hers goal. This is by far the easiest attack to spot using modern intrusion detection techniques.
2.4.2. Insider Attack
In this scenario, the individual may be an employee at the targeted company and hence, already has some sort of access. Often this access is restricted to a specific set of resources. It is when this individual accesses resources he or she is not supposed to access, possibly by circumventing security features, that the attack occurs. This is an insider attack and this is more difficult to detect.
2.4.3. Abuse
This is the kind of attack that is, by far, the most difficult one to detect. In opposite to an insider attack, here, the individual performing the attack is actually authorized to access both the system and the resources. It is when this individual abuses the trust he or she has been given and accesses information with the intent to give it to a third party, that this is a case of abuse.
2.5. Software
Security
Most, if not all, products on the market today are likely to have security vulnerabilities. The demands from the consumer market industry as well as financial interest drive companies to release products (i.e. software and hardware releases) even faster. As products are forced to be developed at such a rapid pace, security purposes are overlooked and not tested. This combined with the difficulties of testing for errors resulting in vulnerabilities often lead to increasing amounts of bugs and exploits in software, either by off-the-shelf software products or by firmware within hardware. In order to keep a system as secure as possible, it’s necessary to keep software in the system up to date. The balance between updating a system to provide increased security and not updating the system and maintaining stability is often a problem for networking staff; this is often solved by using a test system which delays security critical updates while the updates are evaluated in terms of stability and reliability. This might, of course, differ between systems as some systems have high demands regarding availability and other ones on security. It is however important to keep a track on security updates. Good sources for security related matters are the web sites of Securityfocus, Securitytracker, CERT and SANS, see chapter 11.2.
Chapter 2 - Computer Security
2.6. Security
Awareness
One method commonly used to obtain sensitive information is social engineering. Social engineering is the task of tricking an individual in to handing out sensitive information (this is often a password or a login) and this is actually a very common method of gaining access to systems today.
According to a survey, [4], 34 percent of users would be willing to hand out their password if someone asked them, and 70 percent would say no to the first question, but agree if they were given a bar of chocolate.
Security awareness does not only include protection from social engineering attacks. It is just as important to educate users in areas such as safe internet browsing, etc.
Chapter 2 - Computer Security
Chapter 3 - Network Security
3. Network Security
To fully be able to understand the security measures in place in the COMInf network today as well as future recommendations presented in this report, this chapter explains the different stages of an attack as well as a description of systems commonly used to protect against network attacks.
3.1. Analyzing an Attack: The Five P:s
In order to get a better overview of an attack it can be good idea to divide it into different parts. The anatomy of an attack can be divided into five steps; Probe, Penetrate, Persist, Propagate and Paralyze, [1]. These five P:s will be briefly explained below. These different stages will be used to describe the security mechanisms later in this chapter.
• Probe
Here, the attacker tries to find vulnerabilities of the targeted system or systems. This is often accomplished by port scanning a range of IP addresses to find open ports and determine what services and software versions are running. Even if there are instances when an attacker targets a specific system this is highly unlikely.
• Penetrate
In this phase the attacker tries to penetrate the system. This can be done in a variety of forms ranging from bringing a system down using a DoS attack, to gaining administrative privileges by exploiting a known vulnerability in a service running on the targeted system.
• Persist
Launching an attack repeatedly against the same system seriously increases the risk for detection. Therefore, an attacker often tries to establish some kind of backdoor into the system to be used for future intrusions. One common example is for the attacker to add an administrative level user, or brute force the password file in the system to gain the password of an existing user. Later on, such accounts can be used for system access. There is also the possibility of adding a service to the system, e.g. by installing a backdoor service on a port already open in the firewall. As the attacker needs to cover his or her tracks, log files are often deleted and/or modified in the compromised systems to erase any sign of intrusion.
• Propagate
Once an attacker has established his or her presence on a machine, the next step is to try to propagate the attack through the network. That is, scan for and attack other machines in the vicinity of the compromised system. In the case of single sign-on systems used in many organizations today, the attacker can potentially access systems he or she would never have gained access to from the outside. Potentially, this includes company trade secrets.
• Paralyze
Chapter 3 - Network Security
sensitive information, destruction of data or even shutting down entire systems. The goal of the attack is often to reach the company’s most sensitive information, often concentrated to database servers.
3.2. Intrusion Detection System
Intrusion Detection Systems (IDS:s) is a type of system used to monitor network traffic and raise an alarm upon intrusion. There are mainly two different IDS deployments. One is called Network IDS, NIDS, and the other one Host-based IDS, or HIDS. In section 3.2.1 and 3.2.2 a brief overview of the two technologies is presented.
3.2.1. Network IDS
A typical NIDS is setup according to Figure 3-1.
Figure 3-1: A typical NIDS setup
A NIDS, like the name implies, listens to network traffic and analyzes all information passing by (it does not even need its own network address). Based on some predefined ruleset it classifies the passing traffic as either an attack or normal network activity. This ruleset (in many cases) is usually handed out by the IDS vendor. However, as large corporations often do not wish to wait for the IDS vendor to issue new rulesets; it is quite common that system administrators develop their own rules in order to be protected from what is commonly known as zero-day attacks. Zero-day attacks is an attack that takes place after an exploit has been made public and before a fix has been issued.
IDS:s have to be configured very specifically to their target environment. If not carefully tuned to the specific network they are protecting, they will generate just as many (if not more) false positives as they will be identifying real threats and attacks to a system.
Chapter 3 - Network Security
3.2.2. Host-based IDS
While a HIDS may listen on network traffic, it only listens on the host it resides at. The main difference is that since a HIDS has the advantage of actually residing on the host it’s protecting, it can also be installed to monitor the information flow within the operating system also covering log files, memory etc. A HIDS can have quite a lot of similarities with modern antivirus software in this fashion, they both monitor calls to and from the kernel, and they both compare these to some sort of signature database. 3.2.3. NIDS vs. HIDS
There are important differences between a NIDS and a HIDS to be aware of. For one, a HIDS mostly has access to unencrypted information while a NIDS can de defeated if the passing data has been encrypted. Today, this is a quite common scenario as end-to-end encryption increases rapidly in applications, especially when it comes to security critical applications such as connecting to an online bank using HTTPS. This is an example of how one mechanism used to provide security also make the NIDS, which is actually there to protect the same users, blind.
Both HIDS:s and NIDS:s may incorporate various forms of behavioral systems in order to distinguish normal system behavior from abnormal behavior that may indicate an attack. However, these systems are still mostly experimental and may have severe problems in distinguishing between an attack and an unexpected change in system information. Installing new software on a server might, from the IDS point of view, generate abnormal system calls or traffic that can be interpreted as malicious content.
3.3. Intrusion Prevention System
Although the theory differs between writers, the most common description of an Intrusion Prevention Systems (IPS:s) is an IDS with prevention measures.
An example of an IPS action can be to shut down a port in a firewall, blocking an IP-address or even execute countermeasures such as launching a counter attack.
Because IPS:s actually do take action, it makes configuration of such devices extremely important. When an IDS might classify valid traffic as an attack (false positive), all that really happens is that an alarm goes of. An IPS on the other hand will take action, possibly blocking this connection, leaving an employee or customer without the access to which they are entitled. Hence, a misconfigured IPS may leave the company in a denial-of-service situation.
3.4. IDS and IPS Detection
By port scanning a system, an attacker can establish the ports on a target system that are open for an attack. Port scanning a system is often the first stage (Probe) of an attack. As tools for port scanning is available for free on the Internet this is probably the most common attack used today. IDS:s systems today are very competent at detecting this kind of attack pattern. However, as an IDS only detects and warns about
Chapter 3 - Network Security
the potential threat, it is still up to the system administrator to block the malicious traffic. An IPS might on the other hand be able to block the traffic with the downside of blocking permitted traffic based on false positives.
As for the remaining stages, all but the last stage (Paralyze) can be detected. However, this is only true if the IDS or IPS is setup to also monitor the internal network. Preferably one IDS/IPS is used to guard the external network and firewall setup while another one is in place to guard the internal network. Remember, an IDS/IPS can be just as effective in protecting from insider attacks as it is in protecting from intrusion.
Chapter 4 - Network Management
4. Network Management
Regarding network management; Mauro and Schmidt makes the following definition:
“Network management is a general concept that employs the use of various tools, techniques, and systems to aid human beings in managing various devices, systems, or networks”, [5].
This chapter describes basic principles for a network surveillance system and the FCAPS model.
4.1. Requirements for a Network Surveillance System
In order to implement a network surveillance system, it is important to have a thorough understanding of the target network before implementation begins. This can lead to a study of inventory.
In many organizations, there has to be a financial basis for implementation. This financial investigation is often accomplished by performing a risk assessment analysis where the cost of implementation and maintenance is carefully weighed against the cost for a successful intrusion or system malfunction. While a network surveillance solution cannot prevent system malfunction on its own, it does provide the tools and mechanism which can aid system administrators in preventing problems with either network devices, or individual servers and/or services and primarily, it can help system administrators to be aware of the problem a lot sooner.
In some cases, e.g. bank systems, the cost for system intrusion and/or failure might be so high as to motivate nearly any cost of prevention.
4.2. FCAPS
Network management can be based on a model called FCAPS, Fault management, Configuration management, Accounting management, Performance management, and Security management. The model was originally developed by International Telecommunication Union – Telecommunications branch, or ITU-T, and is a defined in the standard M.3400 – Telecommunications Management Network: Management functions, [6].
The definition used in this thesis is taken from Douglas R. Mauro and Kevin J. Schmidt, [5], and has been adapted to better suite the telecommunications industry. 4.2.1. Fault Management
Fault management plays a very important role in helping the operator to quickly and efficiently act on faults which occur in equipment. This contributes to minimizing system downtime. Fault management can be described as detecting, logging and notifying users, systems and networks of problems.
Chapter 4 - Network Management
1. Isolate the problem by using tools to determine symptoms. 2. Resolve the problem.
3. Record the process that was used to solve the problem.
In practice, the last step is often omitted. This does in turn often lead to waste of resources as engineers could have followed a simple guideline instead of performing steps 1 and 2 all over again.
4.2.2. Configuration Management
Configuration management handles monitoring and supervision of the network itself, but also of the machines on the network. This is carried out in order to track changes in the hardware and software versions within the network and to identify possible problems.
As a network administrator, the following system configuration parameters are usually of interest:
• Operating system and version of the OS • Service versions of different software • Hardware specifications (CPU, RAM, etc.)
This information is often stored in a centralized database for easy access and can be most helpful during trouble shooting. What is classified as interesting information differs greatly from system to system as well as between network administrators. .
4.2.3. Accounting Management
The goal of accounting management is to ensure that computing and network resources are distributed more evenly in accordance with their actual requirements, e.g. by the use of disk quotas, etc. This does in turn often reduce network problems by minimizing the risk for congestion due to a more efficient use of resources.
4.2.4. Performance Management
Performance management is used to see how resources are used and handles measuring and reporting on deviations from, what is considered to be, normal network or system performance. The three steps often associated with performance management are:
1. Collection of performance data.
2. Establishing baseline levels for normal system and/or network performance. 3. Establishing performance thresholds. When these thresholds are exceeded, it
is likely that a problem requires attention.
Performance management can be most helpful in detecting problems before they escalate into system failure. An example could be an Internet Service Provider (ISP) which monitors the response time of its mail servers.
Chapter 4 - Network Management
4.2.5. Security Management
Security management can be divided into two sections. First, it handles resource access control to networks and hosts. Second, it handles network supervision and aids in detecting potentially malicious network traffic. In some cases it even handles prevention of attacks; this is described in more detail in chapter 3.
Attacks on the network can lead to failure with respect to one or more of the three CIA aspects. Most often this includes Denial of Service attacks (DoS), but in more severe cases it may also result in attackers gaining access to important systems and/or stealing sensitive data.
Security management does not only apply to network and host security, but also to physical security. This could be access control to enter a building, server room, etc. The goal here is to ensure that access to vital systems is only handed out to those who really need it to perform their duties.
Today, network security is often accomplished using various controls. Some examples of these controls might be:
• Firewalls
• Intrusion Detection Systems • Intrusion Prevention Systems • Antivirus systems
• Policy management and enforcement systems
Security management often integrates with configuration management through the use of the Simple Network Management Protocol (SNMP).
4.3. Simple Network Management Protocol
The Simple Network Management Protocol is, despite the name, a quite advanced and powerful protocol. It exists in a variety of versions ranging from the original SNMPv1 to SNMPv2c and SNMPv3. It is an Internet standard protocol for managing IP devices on IP networks.
4.3.1. Area of use
Today, most network devices acting in an IP environment support SNMP. The way SNMP can be used ranges from fairly simple tasks such as monitoring the health of routers, switches, printers and other pieces of network hardware, to more complex tasks such as actually controlling the devices in the network, raising alarms upon deviation from performance thresholds and in some cases even execute actions.
4.3.2. Managers and Agents
In the world of SNMP, there are two types of entities; managers and agents. A manager is a server running some kind of software that can handle management tasks for a network. Managers are often referred to as Network Management Stations (NMSs). The purpose of the NMS is to collect data from agents and using traps and polling techniques. Traps and polling represents two different aspects of communication within SNMP. A trap is a way for an agent to let the manager know something has happened, while a poll is a way for the manager to query an agent on
Chapter 4 - Network Management
specific values, e.g. the speed of a network interface. Two different polling techniques are used, internal polling and external polling. This is described in more detail in section 4.3.6.
Figure 4-1 describes a typical example of a relationship between a manager and an agent.
Figure 4-1: Relationship between a manager and an agent
4.3.3. Structure of Management Information
SNMP use a notation called Structure of Management Information (SMI). SMI is a subset of Abstract Syntax Notation One (ASN.1) and a part of SNMP to define managed objects and their behavior. The three defined types are MIB modules, compliance statements and capability statements.
NMS
(Manager)
Agent
Trap sent to NMS
Query sent to the agent
Chapter 4 - Network Management
4.3.4. Management Information Base
A Management Information Base (MIB) is a collection of information that is hierarchically organized. A MIB is constructed using the SMI syntax and describes some particular object. This can be everything from the system administrators name to the number of IP packets that has passed through a routers interface.
Root-Node
Root-Node
ccit(0)
ccit(0)
iso(1)
iso(1) joint(2)joint(2)
org(3) org(3) dod(6) dod(6) internet(1) internet(1) directory(1)
directory(1) mgmt(2)mgmt(2) experiminetal(3)experiminetal(3)
private(4) private(4) mib-2(1) mib-2(1) system(1) system(1) interfaces(2) interfaces(2) at(3) at(3) ip(4) ip(4) icmp(5) icmp(5) tcp(6) tcp(6) udp(7) udp(7) egp(8) egp(8) snmp(11)snmp(11) transmission(10) transmission(10)
Figure 4-2: An OID structure including the MIB-II MIB
The MIB structure allows for a generic way to control (set) and monitor (get) network devices and agents.
4.3.5. Accessing SNMP agents
In order to access an SNMP agent and its localized MIB objects, a special form of naming scheme is used called Object Identifier (OID). OID:s are globally unique and used in everything from SNMP to specific enterprise naming schemes. As described in Figure 4-2 the MIB is organized hierarchically and the objects are accessed using their identity. The ID can be expressed using either their name (e.g. iso) or their corresponding OID (in the case of iso, this is 1), using dots to indicate hierarchy. An example could be iso.org.dod.internet.mgmt.mib-2.ip (bold in the figure) or simply 1.3.6.1.2.1.4 which is the corresponding decimal notation. This refers to the IP part of the MIB-II MIB.
Chapter 4 - Network Management
4.3.6. Extensible Agents
In some cases, the standard agent might not provide all the functionality needed. At that time, it is possible to use an extensible agent. An extensible agent is an agent which is extended by adding or changing its current MIB definition. This way it is possible to adapt the agent to its environment. An example of an extensible agent is the System Management Agent (SMA) by Sun, see section 7.4.4. An extensible agent makes it possible to retrieve values based on output from system commands or shell scripts. This can be helpful when it comes to monitoring of system specifics, e.g. process status, disk space utilization, etc.
4.3.7. Remote Monitoring
Remote Monitoring (RMON) is a special means of communication between managers and agents. It is a supplement to the MIB-II group (MIB-II is an SNMP specification for extensive IP interface information, see RFC 1213 in the section 11.2) and, if supported by the device’s SNMP agent, provides the ability to do both internal and external polling. This can be done either by letting the manager poll the agent, or by letting the agent poll the device itself continuously and then report errors as they occur. The second approach seriously decreases network load as no continuous polling will have to be done from manager to agent in order to raise alarms. Of course, external polling will still have to be performed in order to monitor network status.
Chapter 5 - Common Operations and Maintenance Infrastructure
5. Common Operations and Maintenance
Infrastructure
The main management system in the O&M network is called OSS-RC, a part of the Ericsson O&M network. A part of the OSS-RC product family is the COMInf network which provides infrastructure services to the radio access networks. The radio access networks can be either second generation GSM systems or third generation UMTS/WCDMA systems.
5.1. Overview
The COMInf network provides OSS-RC with services and infrastructure components, see Figure 5-1.
Chapter 5 - Common Operations and Maintenance Infrastructure
The purpose of the COMInf network is:
• To provide separation between the radio access network and the users of OSS-RC
• To provide infrastructure services to OSS-RC and ultimately to the radio access network
5.2. Services
COMInf supports a variety of services such as: • DHCP (Sun DHCP or Ericsson IPWorks)
A protocol used to hand out IP addresses to hosts. • DNS (BIND or Ericsson IPWorks)
A protocol used to translate domain names into IP-addresses. • NTP
A protocol used to synchronize time between computers. • SMRS
An Ericsson specific service used to provide storage functionality for easy distribution of upgrade packages to radio access base stations and radio network controllers in the radio access networks.
Note: Ericsson IPWorks is a suite providing both DHCP and DNS services.
5.3. Authentication
Services
The authentication services within COMInf include: • SLS – Single Login Server
Used to authorize users against the DS • DS – Directory Service
A database for storing users • PKS – Public Key Server
Used to provides certification authority functionality. • CAAS
Chapter 5 - Common Operations and Maintenance Infrastructure
5.4. Network
infrastructure
In addition to infrastructure components, the COMInf network provides important security features. This includes segmenting the COMInf network into different Virtual Local Area Networks (VLANs).
The COMInf infrastructure consists of: • Firewall
• O&M router • Network switch • X.25 O&M router
Note: The X.25 O&M router is only needed in case of GSM over X.25. Today, GSM
Chapter 6 - Analyzing the COMInf Network
6. Analyzing the COMInf Network
In this chapter, an analysis of the COMInf network is presented. The network is broken down into its infrastructure components and typical hardware used in COMInf is analyzed.
6.1. COMInf Network Components
The networking equipment used in COMInf varies between customers. There are, however, recommendations from Ericsson on specific networking equipment to use. The equipment described here is an example of the networking equipment used in a typical COMInf setup. It can also serve as a basis for understanding the type of management support typically found in products today.
6.1.1. Firewall Router
For GSM or small WCDMA networks Ericsson recommends Juniper Networks NetScreen 208 and for large WCDMA networks or WCDMA/GSM combinations the Juniper Networks NetScreen 500ES model is recommended. Data sheets for both models can be found in appendix A.
Features:
• VPN (Virtual Private Network) support • VLAN support
• Basic IPS Protection
• SNMPv1 and SNMPv2c with custom MIB support
Performance:
The NetScreen 208 is a 8 port firewall router/VPN solution supporting up to 100 Mbps (10/100 auto-sensing) on each port. It is capable of handling firewall routing at up to 375 Mbps, while dropping to 175 Mbps when 3DES or AES encryption VPN:s are used.
The NetScreen 500ES is a layer 3, 8 port firewall router/VPN solution with built in DoS protection. It is capable of handling firewall throughput at 700 Mbps while dropping to 250 Mbps when strained with 3DES or AES encryption using VPN.
Security:
A brief investigation of the security in these products reveals some security issues. Although all of them have already been addressed by Juniper Networks and supplied patches are available, it is critical that the customer actually install these updates. For instance, in ScreenOS (the operating system in these products) version 5.2 and earlier, it is possible to extract the username and password for administration of the products using brute force and man-in-the-middle (MITM) attacks, [7].
Note:
Chapter 6 - Analyzing the COMInf Network
• None of the routers support the security provided by SNMPv3.
6.1.2. O&M Router
For GSM networks Ericsson recommends the Juniper Networks M7i router while recommending the Juniper Networks M20 router for WCDMA and WCDMA/GSM combinations.
Features:
• VPN support • VLAN support
• SNMPv2c and SNMPv3 with custom MIB support
Performance:
The M7i has a total throughput of 8.4 Gbps in half duplex mode, or 4.2 in full duplex.
The M20 has a total throughput of 12.8 Gbps in half duplex mode or 6.4 in full duplex.
Security:
The entire range of M-series routers from Juniper Networks makes use of the JUNOS software. This also makes them vulnerable in case of flaws found in that software. At the time of writing, the latest flaw found was in June 2006 and provided a way to crash the router using a bug in the handling of IPv6 packets. Although the vendor has released a fix for the problem, this again demonstrates the importance of keeping software up to date, [8].
Note:
All versions of JUNOS released after 10 may 2006 contains the corrected code. 6.1.3. Network Switch
For small WCDMA or GSM networks Ericsson recommends the Extreme Networks Summit 5i while recommending the Extreme Networks Summit 7i for medium or large WCDMA or GSM networks.
Features:
• VLAN support • SNMPv3 support
Performance:
The Summit 5i supports a total of 16 ports at 100/1000 Mbps speeds, while the Summit 7i provides a total of 32 such ports.
Security:
A basic search on different security sites (see the links section in chapter 11) for security flaws reveals no exploits for the products.
Chapter 6 - Analyzing the COMInf Network
6.2. COMInf
Servers
The servers within COMInf make almost exclusive use of the Solaris operating system even though there might be a few servers running Windows (mainly Windows Application Server). This makes it easy to maintain supervision and monitoring of processes and services through the use of SNMP.
The security of both the Solaris and the Windows platform can only be guaranteed as long as the services they provide can be considered secure. It is therefore important that the machines stay updated with the latest security fixes.
6.3. Security
Mechanisms
The security in the COMInf network is focused on internal protection, primarily by preventing the OSS-RC users from directly accessing the COMInf servers and the OSS-RC master server. There is a strong separation between the users of OSS-RC and the servers, mainly by the use of firewalls. Secure SSL (Secure Socket Layer) tunnels are used to provide the integrity and confidentiality aspects of the connection to the citrix licensing servers. OSS-RC users are only permitted to access a set of servers designed for operational tasks and never come in direct contact with the master server, see Figure 6-1.
Chapter 6 - Analyzing the COMInf Network
6.4. Conclusion
This analysis of the COMInf network setup shows that all devices and servers are capable of supporting a surveillance solution utilizing SNMP. There are however some drawbacks, SNMPv3; the only version of SNMP to provide real security features, is not yet supported by all manufacturers. This does in turn force the surveillance system to rely on the security measures of SNMPv2Cm which are recognized to be inferior.
While SNMPv3 provides increased security, the only real difference between version 2 and version 3 is the ability to encrypt traffic between end-nodes, and secure authentication between managers and agents. As the COMInf network is quite isolated, the lack of security provided by SNMPv2c might not be such a critical factor as it would have been in case of a public network. However, one important aspect is to set all SNMP devices in a read-only mode, this makes the network devices less sensitive than if MIB updates are allowed.
With regards to redundancy, the COMInf network is deployed redundantly in almost all aspects. Single-points-of-failure are the network switch, firewall router, O&M router and possibly the X.25 router. That makes monitoring of these devices very important in a surveillance perspective.
As far as security is concerned, the security mechanisms in place today are aimed at separating the users of OSS-RC from accidentally damaging the system. External threats to the COMInf network are limited, primarily because the network is shielded from other networks by the use of firewalls and in some cases even physical connection. At the moment, these mechanisms provide a sufficient level of security.
Chapter 7 - Requirements
7. Requirements
To both make network and server administration easier, and to provide a better overview of the network itself, a surveillance solution is desired. This surveillance solution should provide functionality for both monitoring of servers and processes as well as networking equipment. It should cover functional as well as security aspects of the COMInf network.
In order to provide the best possible solution for supervision and monitoring of the COMInf network, it is desired to provide a set of requirements for evaluating different solutions. In this chapter, requirements are evaluated, discussed and rated according to a rating system developed for this thesis.
COMInf today uses no form of supervision, neither for monitoring of services and network status nor for security purposes. Since both the servers and the networking equipment that make up COMInf are critical for the functionality of OSS-RC, it is desired that the stability of the COMInf network can be monitored.
7.1. Background
Chapter 6 describes some typical hardware that is often used in a COMInf network. The only protocol supported by both hardware and software is SNMP and as no alternatives exist, this study is limited to SNMP.
As a first step towards generating requirements, some basic points of interest for monitoring and supervision are presented in the following sections.
In section 7.5 the derived requirements are analyzed and rated in order to finally rank these requirements in order of importance and total score. This later on serves as a basis for the candidate systems presented in chapter 8.
7.1.1. Infrastructure Components
This section presents some possible measurements that might be of interest: • O&M router
o Traffic flow per port o Total traffic flow
o Dropped/discarded packages o Temperature
• Firewall router
o Traffic flow per port o Traffic flow per VLAN o Total traffic flow
o Dropped/discarded packages o Temperature
Chapter 7 - Requirements
• Network switch
o Traffic flow per port o Traffic flow per VLAN o Total traffic flow o Interface speed o Temperature • X.25 router
o Inbound traffic (X.25) o Outbound traffic (IP)
o Dropped/discarded packages o Temperature
Note: The X.25 router only exists when interfacing with GSM over X.25.
7.1.2. COMInf Servers
The following section presents some measurements of interest for the servers in the COMInf network.
• Server uptime
• Network traffic in/out
• Number of processes running • Disk space utilization
• CPU utilization • Memory utilization
• Specific monitoring of individual processes (such as BIND, DHCP, etc.) • Temperature
7.2. Risk
Assessment
Because a risk assessment analysis depends very much on customer specific parameters (e.g. cost for downtime, cost for maintenance, etc.) a complete risk assessment analysis is not feasible.
Instead, this thesis presents some other threats that the COMInf network could face, using the knowledge and expertise of Ericsson personnel. Section 7.3 presents requirements based on both this information as well as the basic theory behind network surveillance systems.
7.3. Draft
Requirements
The requirements have been divided into two sections. The first section presents functional requirements for supervision and based on the existing theory, while the second one is based on contact with staff within Ericsson. The requirements are limited to system parameters. Physical requirements are not covered in this thesis project.
Chapter 7 - Requirements
In section 7.3.1 possible requirements based on theory of the subject are presented. Section 7.3.2 presents the requirements gathered from informal interviews with staff at Ericsson.
These requirements are analyzed and rated in section 7.4 and finally presented in chapter 7.5.
7.3.1. Draft Requirements Based On Theory
Theory on network surveillance predominantly covers company networks, ISPs etc. which can be private or public systems often connected to the Internet. The COMInf network is different in this respect as it is normally (this is up to the customer) shielded from the Internet.
However, the hardware and software in the network are still mostly standardized components and are as such subject to monitoring using existing network surveillance techniques. The requirements in this section have been derived using existing theory on network surveillance.
• Support for SNMP:
o SNMPv1 Not acceptable o SNMPv2c Required
o SNMPv3 Strongly recommended • Support for extensible agents
• Support for MIB-II
• Possibility to extend using open APIs (Application Programming Interface) • Generate traffic graphs for the traffic in the COMInf network; these should be
able to break down into VLAN traffic graphs • Raise an alarm if needed
• Monitoring of all servers in the COMInf network • Provide server information on:
o CPU utilization o Disk utilization o Memory utilization
o Virtual memory utilization o Number of running processes o Temperature
o Fan speed o UPS status
• Monitoring of the following services running on the COMInf servers: o DNS, either by BIND or Ericsson IPWorks
Version
Status (is it running?) Self-test
Chapter 7 - Requirements Version
Status (is it running?) Self-test
o NTP
Version
Status (is it running?) Self-test
o HTTP, Apache Version
Status (is it running both on 80 and 443 – HTTPS) Self-test
• Monitoring of the following information for the network switch: o Firmware version
o Traffic flow per port o Interface speed per port o Temperature
• Monitoring of the following information for the O&M router: o Firmware version
o Total traffic flow
o Erroneous/Discarded packages o Temperature
• Monitoring of the following information for the firewall router: o Firmware version
o Total traffic flow
o Erroneous/Discarded packages o Temperature
• Monitoring of the following information for the X.25 router: o Firmware version
o Total traffic flow
o Erroneous/Discarded packages o Temperature
7.3.2. Draft Requirements Based On Interview
The requirements presented in this section have been derived from interviews and mail conversations with employees at Ericsson. The interview subjects ranges from the staff within the COMInf development team to a solutions architect working in close cooperation with Ericssons customers.
As of the new release of OSS-RC, OSS-RC R5 the specification of the COMInf network is stricter than is has been in previous versions. This makes surveillance of the network and its servers easier since servers and processes are more well specified. However, the infrastructure components of the networking equipment (such as routers, switches, etc) are still not specified in the release documents (even though certain hardware is recommended).
Chapter 7 - Requirements
As potential single-point-of-failures it has been pointed out that the routers/switches/firewalls and server information in the COMInf network are essential to monitor. Particular points of interests are:
• Routers (Firewall, X.25, O&M) o Firmware version o Temperature • Switch o Firmware version o Temperature o Throughput • Servers
o Operating System version
o Log files (send SNMP traps upon match of specific text strings) o Hardware (send SNMP traps upon exceeding certain thresholds)
CPU DISK I/O RAM
o Monitor output from specific shell scripts
o Service information (send SNMP traps upon abnormal behavior) Version
Runtime information
o Make use of process accounting information • General information
o Store performance data in a centralized database o Export of performance data to Excel
o Produce graphs of system performance
o Installation flexibility (system installation directory should be configurable)
o Should work in both HA and non HA environments o Detailed IP interface statistics
o Work alongside OSS-RC UTRAN security solution without interference
7.4. Rating the Requirements
In this chapter the draft requirements from theory, and from staff within Ericsson will be interpreted and rated in two different aspects:
Chapter 7 - Requirements
• Importance The importance of the requirement.
• Cost The cost (e.g. implementation time) for the requirement. 7.4.1. Rating system
The rating system will rate the two difference aspects using a scale of 1-5 for importance, and 1-3 for cost. The importance rating is explained in Table 7-1.
Score Rating Explanation
1 Very low Does not provide any interesting information 2 Low Provides some interesting information
3 Medium Important information
4 High Very import information
5 Very high Essential for implementation Table 7-1: Explaination of importance rating
The cost rating in this thesis is based on the manager software HP Network Node Manager as well as the target systems default SNMP agent.
Score Rating Explanation
1 High Agent will have to be extended to support
functionality.
2 Medium Some extra configuration is necessary
3 Low Native support exists in both manager and agent Table 7-2: Explanation of cost rating
Finally the requirement will be given a total score using the formula:
Total Score = Importance score x Cost score
The formula yields a total score that ranks the requirements by giving an important and cheap requirement a high score, while giving an unimportant and costly requirement a low score. In chapter 7.5, the total score as well as the importance factor are used to prioritize the requirements.
Note: Although alternative rating systems exist, this particular system is often used
and can, if necessary, easily be translated into man-hours in a project model. 7.4.2. Routers (X.25, O&M, Firewall)
The really critical information to extract from these devices is the firmware version (version of OS in the products) and the temperature. This way it is possible to make sure the firmware is up to date and that the device itself does not overheat. The impact
Chapter 7 - Requirements
of a crashed router would be quite severe as it could bring down the COMInf network itself or its connection to the GSM and/or WCDMA networks.
Since all routers in this typical COMInf setup utilizes the JUNOS software it is straight forward to derive the costs for different routers, the scores are based on information found in “JUNOS Network Management Configuration Guide”, [9]. The agents these cost scores are based on are the default agents on the recommended routers by Ericsson; see section 6.1 for more information. Scores of requirements for the COMInf routers can be found in Table 7-3.
No. Service/Process Importance Cost Total Score
F-1 Router firmware version 5 3 15
F-2 Router temperature 4 3 12
F-3 Router throughput 2 3 6
F-4 Router erroneous packages 1 3 3
F-5 Router discarded packages 1 3 3
Table 7-3: Score for COMInf routers
It appears that introducing support for monitoring the necessary items in the COMInf routers would prove an easy task as native supports exists for all of the above requirements.
7.4.3. Network Switch
As explained earlier, OSS-RC R5 enforces hardware control as far as servers are concerned. This helps when determining the requirements for bandwidth. In versions previous to R5 however, this is not the case. For small networks it becomes important to continuously monitor the network traffic to be able to detect possible congestion in network traffic. The agent these cost scores is based on are the default agent on the recommended switch by Ericsson; see section 6.1 for more information. Table 7-4 shows the scores for the requirements of the COMInf network switch.
No. Service/Process Importance Cost Total Score
F-6 Switch firmware version 5 3 15
F-7 Switch temperature 4 3 12
F-8 Switch throughput per port 3 3 9
F-9 Switch transmission errors 2 3 6
F-10 Switch total throughput 1 3 3
Table 7-4 Score for COMInf network switch requirements
All requested information from the network switch can be obtained using both Juniper Networks own enterprise MIB and their implementation of MIB-II.
Chapter 7 - Requirements
7.4.4. Servers
As the COMInf network grows, more and more servers are being added to the network infrastructure. Redundant servers, new services on new machines and old services that had earlier coexisted with other services on one server may be deployed on separate machines in order to increase stability and capacity of the network.
On the servers, the default SNMP agent provided by Sun on Solaris 10 is used as a reference, this agent is called the SMA, or System Management Agent. This agent is based on the open-source agent Net-SNMP and has been extended to support the following MIBs, [10]:
• SNMP-COMMUNITY MIB Defined in RFC 2576.
• SNMPv2-TM (Transport Mappings) Defined in RFC 3417.
• SNMP-MPD-MIB (Message Processing and Dispatching) Defined in RFC 3412.
• SNMP-TARGET-MIB (Specification of targets for traps) Defined in RFC 3413.
• SNMP-NOTICATIONS-MIB (Trap filtering) Defined in RFC 3413.
• SNMP-PROXY-MIB (Trap forwarding) Defined in RFC 3413.
• SNMP-USED-BASED-SM-MIB (User based security model for SNMPv3)
Defined in RFC 3414.
• SNMP-VIEW_BASED-ACM-MIB (View based Access Control Model for SNMP) Defined in RFC 3415. • SNMPv2-MIB Defined in RFC 3418. • MIB II Defined in RFC 1213. • Host Resources MIB
Defined in RFC 2790. • SUN MIB
Related to migration from the Solstice SNMP agent used in previous versions of the Solaris operating system.
• UCD-DISKIO-MIB
MOB Module for disk I/O statistics.
It should be noted that the Net-SNMP agent is far superior to the Solstice agent running on Solaris 8 and 9. This makes this rating inaccurate for those operating systems. However, Net-SNMP can be installed on both Solaris 8 and 9 and also on the Windows Server platforms. All RFC documents can be found at IETFs web site, see chapter 11.2. It is still uncertain if the SMA from Solaris 10 will work on Solaris 8 and 9.
Chapter 7 - Requirements
F-11 Server runtime information (uptime, etc.)
5 3 HR 15
F-12 Server log file monitoring 5 1 EXTERNAL 5
F-13 Server service version 5 2 HR 10
F-14 Server service runtime information
5 2 HR 10
F-15 Server monitoring of output from specific shell scripts
5 1 EXTERNAL 5
F-16 Server data performance collection
5 2 HR/MIB-II 10
F-17 Server OS version 4 3 HR 12
F-18 Server CPU utilization 4 3 HR 12
F-19 Server RAM utilization 4 3 HR 12
F-20 Server disk I/O 3 3 HR/DISKIO 9
F-21 Server temperature 3 1 EXTERNAL 3
F-22 Server detailed IP interface statistics
3 3 HR/MIB-II 9
F-23 Server UPS status 3 1 EXTERNAL 2
F-24 Server fan speed 1 1 EXTERNAL 1
Table 7-5: Score for requirements of COMInf servers
Legend: HR Support exists in the Host Resources MIB. MIB-II Support exists in the MIB-II MIB.
DISKIO Support exists in UDC-DISKIO MIB.
EXTERNAL Support does not exist within the SMA. This agent will
have to be extended to support the required functionality.
7.4.5. General requirements
As for the entire network surveillance system, there are a few requirements that do not apply specifically to the monitoring process. These requirements are presented in Table 7-6 below. Because these requirements are mandatory, they are not rated.
Requirement Importance Cost Total Score
F-25 Store performance data in a centralized database
Mandatory N/A N/A
F-26 Export performance data into .xls (Microsoft Excel) format
Mandatory N/A N/A
F-27 Produce graphs of system performance
Mandatory N/A N/A
F-28 Agents should install in a user-configurable directory
Mandatory N/A N/A
F-29 Should work in both HA and non HA environments
Chapter 7 - Requirements
F-30 Work alongside the current security solution (UTRAN)
Mandatory N/A N/A
F-31 Make use of process accounting information
Mandatory N/A N/A
Table 7-6: Score for general requirements
7.5. Analyzing the Requirements
It is apparent that the limiting factor of the chosen network monitoring solution is the targets SNMP agent. Although most areas for the network switch and the routers have native support in the provided SNMP agents through their implementation of MIB-II, it is the servers which are most difficult to monitor.
By extending the SMA in Solaris 10, the required functionality can be obtained. There exist numerous agents that can cooperate with the SMA, either by acting as a slave agent to the SMA or by acting masters themselves and changing the SMA to act as slave. One possible extension is to implement another agent on the server machine.. Since most functionality is dependent on the agents within the servers, switches and routers, the functionality of the manager (discussed in chapter 8) is more associated with how this data is presented and stored for future use. As for requirements F-25 to F-30 in Table 7-6 with the exception of F-28, they are almost exclusively dependent on the SNMP manager.
7.6. Final
Requirements
In this section the requirements are presented in order of total score gained as well as by importance. To get a better comprehension of which requirements are most important, chapter 7.6.1 rates these requirements by their total score.
Chapter 7 - Requirements
7.6.1. Requirements by Total Score
0 2 4 6 8 10 12 14 16 Total Score F-1 F-6 F-11 F-2 F-7 F-17 F-18 F-19 F-13 F-14 F-16 F-8 F-20 F-22 F-3 F-9 F-12 F-15 F-21 F-23 F-4 F-5 F-10 F-24 Requirement Number
Requirements by Total Score
Figure 7-1: Requirements by total score
As we can see from Figure 7-1 and Table 7-7 the requirements that dominate the total score rating are easy to implement. Native support exists in the agents and it is up to the manager to present this data in a usable fashion.
Requirement Description Total Score
F-1 Router firmware version 15
F-6 Switch firmware version 15
F-11 Server runtime information (uptime, etc.) 15
F-2 Router temperature 12
F-7 Switch temperature 12
F-17 Server OS version 12
F-18 Server CPU load 12
F-19 Server RAM 12
F-13 Service version 10
F-14 Server service runtime information 10
F-16 Server data performance collection 10
F-8 Switch throughput per port 9
F-20 Server disk I/O 9
F-22 Server detailed IP interface statistics 9
F-3 Router throughput 6
F-9 Switch transmission errors 6
Chapter 7 - Requirements
F-15 Server monitoring of output from specific shell scripts
5
F-21 Server temperature 3
F-23 Server UPS status 3
F-4 Router erroneous packages 3
F-5 Router discarded packages 3
F-10 Switch total throughput 3
F-24 Server fan speed 1
Chapter 7 - Requirements 7.6.2. Requirements by Importance 0 0,5 1 1,5 2 2,5 3 3,5 4 4,5 5 Importance F-1 F-6 F-11 F-13 F-14 F-16 F-12 F-15 F-2 F-7 F-17 F-18 F-19 F-8 F-20 F-22 F-21 F-23 F-3 F-9 F-4 F-5 F-10 F-24 Requirement Number Requirements by Importance
Figure 7-2: Requirements by importance
Both Figure 7-2 and Table 7-8 shows a rating system where the cost for implementation has been ignored. As this thesis has used a simplified model for requirement evaluation, some requirements might not be implemented by only total score into account. This is due to the costly factor of some requirements that might still be very important, it is therefore recommended to also look at the requirements from an importance perspective and simply ignore the cost aspect.
Requirement Description Importance
F-1 Router firmware version 5
F-6 Switch firmware version 5
F-11 Server runtime information (uptime, etc.) 5
F-13 Service version 5
F-14 Server service runtime information 5
F-16 Server data performance collection 5
F-12 Server log file monitoring 5
F-15 Server monitoring of output from specific shell scripts 5
F-2 Router temperature 4
F-7 Switch temperature 4
F-17 Server OS version 4
F-18 Server CPU load 4
F-19 Server RAM 4
