Application-level simulation for network security

Rainer Bye, Stephan SchmidtKatja Luther and Sahin Albayrak1

DAI-Labor, Technische Universität Berlin{rainer.bye, stephan.schmidt, katja.luther, sahin.albayrak}@dai-labor.de

ABSTRACTWe introduce and describe a novel network simulation tool calledNeSSi (Network Security Simulator). NeSSi incorporates a vari-ety of features relevant to network security distinguishing it fromgeneral-purpose network simulators. Its capabilities such as profile-based automated attack generation, traffic analysis and interfacesupport for the plug-in of detection algorithms allow it to be usedfor security research and evaluation purposes. NeSSi has been uti-lized for testing intrusion detection algorithms, conducting networksecurity analysis, and developing distributed security frameworksat the application level. NeSSi is built upon the agent component-ware framework JIAC [5], resulting in a distributed and easy-to-extend architecture. In this paper, we provide an overview of theNeSSi architecture and briefly demonstrate its usage in three exam-ple security research projects. These projects comprise of evalu-ation of stand-alone detection unit performance, detection devicedeployment at central nodes in the network and comparison of dif-ferent detection algorithms.

Categories and Subject DescriptorsI.6.3 [Simulation and modeling]: Applications

General TermsSecurity, Design

KeywordsNetwork simulation, network security

1. INTRODUCTIONIn contemporary communication infrastructures, IP-based com-

puter networks play a prominent role. The deployment of thesenetworks is progressing at an exponential rate as different kindsof participants such as corporations, public authorities and indi-viduals rely on sophisticated and complex services and communi-cation systems. With regard to information security, this leads tonew challenges as large amounts of data, which may hold mali-cious content such as worms, viruses, or Trojans, are transferred

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.SIMUTools March 03 - 07, 2008, Marseille, FranceCopyright 2008 ACM ISBN 978-963-9799-20-2 ...$5.00.

over open networks. Network security measures dealing with thesethreats can be implemented in the network itself as well as at hostsconnected to access routers of the network. The host-based ap-proach has its merits, especially with respect to the scalability of aresulting security framework; for example, placing security capa-bilities such as firewalls or virus scanners on individual hosts doesnot inhibit the traffic travelling through the network. However, asthe hosts are generally not under the control of network operators,there is no way of ensuring a certain network-wide security policy.

A consequence for network service providers (NSPs) strivingto offer improved security features to their customers as a value-adding feature is to devise a security framework in which detec-tion devices are placed within the network. Before doing so, theNSP must take into account that it is not desirable to make frequentchanges or experiment with various security feature deploymentsin the network infrastructure of a production system. For this rea-son, network operators can greatly profit from a network simula-tion tool in which various features of the security architectures canbe tested in order to ensure maximum attack detection efficiencybefore the actual physical deployment. The advantage over con-ventional testbeds is the low cost and ease at which tests can becarried out. The presented Network Security Simulator NeSSi (seeFigure 1) allows NSPs to experiment with different network-centricsecurity framework setups and algorithms in order to evaluate andcompare intrusion detection efficiency and operational costs. Inthis fashion, a devised security framework can be tested in a real-istic simulation environment before the actual detection units arephysically deployed in the network.

In the following section, we provide an overview of existing net-work simulation tools with focus on security evaluation capabili-ties. We then describe the general software architecture of NeSSiin Section 3, focus on the security features in Section 4 and subse-quently demonstrate how it can be used for the setup and executionof realistic attack scenarios. Finally, an outlook on future exten-sions of NeSSi is given in Section 6.

2. CONTRIBUTIONIn recent years, the research community has used various net-

work simulation tools for the verification of new algorithms, theinvestigation of design and interaction behavior of newly devel-oped protocols as well as the examination of performance issuesencountered in large-scale network architectures. The most popu-lar general-purpose software tool in the research community is theopen-source network simulator ns2 [15]. Ns2 performs networksimulation using a discrete event model. This approach has sev-eral advantages regarding application performance and scalability.These important issues are discussed for example in [10] and [8].Discrete simulation allows very cost-efficient exploration and ex-

perimentation with real-life network topologies and architectures.In many areas involving network analysis, ns2 is a powerful tool;however, it also poses certain limitations to the user. Concerningthe aspect of simulation efficiency for large networks, ns2 does notout-of-the-box support a parallel execution model. It does not sup-port generic sockets, but protocols have to be rewritten for the us-age in ns2. Moreover, the script language interface is not intuitiveto use for novice users. Alternatives to ns2 are for example theQualNET simulator [13] or the Georgia Tech Network SimulatorGTNetS [12], which, in contrast to ns2, also offers parallel execu-tion support for large-scale simulation.

However, all these simulators have limitations in standard sup-port of real-world network security evaluation. A lot of work hasbeen done in the limited area of worm simulation, as described ex-tensively by Wei et al. [16]. In this work, the authors note thatexisting simulators are mostly single-machine tools and hence donot scale to model realistic attack mechanisms in real-world large-scale networks. They propose a distributed approach termed PAWS,which is nevertheless not a comprehensive tool but limited to wormsimulation only. Another security evaluation tool is RINSE, whichis described by Liljenstam et al. in [7]. It focuses on support-ing real-time large-scale simulations and allows for realistic emu-lation of CPU and memory effects within the simulation. However,there is no mention of application-level simulation capabilities inRINSE. The same drawback exists in the solution presented in [17],although it allows model-driven attack tree-based simulation in areusable object-oriented software architecture.

With NeSSi, we aim to provide a network simulation tool specif-ically tailored to meet the needs of security experts and networkadministrators. This target group will be able to test and evaluatethe performance of commonly available security solutions as wellas new research approaches. As a distinguishing feature to the pre-vious tools described above, NeSSi provides extensive support ofcomplex application-level scenarios on top of a faithful simulationof the TCP/IP protocol stack. Simulated networks are modeled toreflect real-world network topologies by supporting subnet-layermodeling and different node types with varying capabilities (Coreand Access subnets, wireless networks etc.). In particular, NeSSifollows a strict object-oriented design pattern and fosters the inte-gration of third-party applications via a standardized socket inter-face. Furthermore, it provides a comprehensive Detection API forthe integration and evaluation of predefined as well as external de-tection units. In particular, special common attack scenarios aresupported and can be simulated, for example worm-spread scenar-ios, botnet-based DDoS attacks (see Figure 4) and many more. Inaddition, customized profiles expressing the node behavior can beapplied within the simulation.

The application layer simulation capabilities in NeSSi are pro-vided by distributed software agents, introducing another layer ofcomplexity. In order to maintain scalability, a parallel executionmodel is used in conjunction with a discrete event model. In thiscontext, the agent platforms are running on multiple parallel ma-chines and connect independently to a central database module. Agraphical user front-end allows for real-time inspection and config-uration of scenarios.

3. THE FEATURES OF NESSINeSSi is designed to extend conventional network simulation

tool features by supporting detailed examination and testing op-portunities of security-related network algorithms, detection unitsand frameworks. The main focus of NeSSi is to provide a realisticpacket-level simulation environment as a testbed for the develop-ment of new detection units as well as existing ones. We use de-

tection unit as an abstract term for any algorithm or tool employedfor the purpose of detecting malicious activity such as intrusion orservice degradation attempts. As a foundation for the simulation ofsecurity scenarios, we first describe in this section the key featuresof NeSSi related to general network simulation tasks.

3.1 JIAC agent frameworkNeSSi is built upon the JIAC framework [5]. JIAC is a service-

centric middleware architecture based on the agent paradigm. With-in NeSSi, agents are used for modeling and implementing the net-work entities such as routers, clients, and servers. The underlyingJIAC agent framework provides a rich and flexible basis for im-plementing and testing of various security deployments and algo-rithms in NeSSi. Moreover, building upon an agent framework al-lows combining the partial knowledge of the agents residing in thenetwork in a cooperative approach for identifying and eventuallyeliminating IP-based threats. For example, this may be achieved bymonitoring the structure of the encountered IP traffic and the be-havior of potentially compromised target systems. For an illustra-tive example where we successfully utilized the agents’ cooperativefeatures, refer to Section 4.

Although the software agents provide powerful application-levelcapabilities, their complexity unfortunately also affects the scala-bility of the simulation. Notwithstanding, we mitigate this prob-lem by building upon a parallel-execution model (cf. Section 3.4).Additionally, in the distributed simulation context the agents areemployed as managing entities of different parts of the simulatednetwork domain.

3.2 Network Simulation CapabilitiesAt the foundation of NeSSi are standard network simulation fea-

tures such as network and traffic generation. We will introduce thenetwork model features in the next section, followed by a descrip-tion of the traffic generation capabilities in NeSSi.

3.2.1 Network Model FeaturesNetwork topologies can be created by choosing network ele-

ments such as routers and different kinds of end devices such asweb clients, mail servers etc. and adding them to the network edi-tor tab via drag-and-drop (cf. Figure 1). In the simulation, agentsrealize the behavior of the nodes. The node modeling occurs intwo layers; the first layer reflects their role in the network (client,server, switch or router). This is further refined according to theirapplication-level role (such as web clients, mail clients, IRC serveretc.) and inherent functionality.

The network is hierarchically structured by dividing it into sub-nets. For example, a large-scale network usually consists of a corearea, a number of distribution networks (for example university ormetropolitan area networks) and access networks, i.e. companynetworks. In the central network editor window of Figure 1, sucha network with a hierarchical structure is displayed. It is also pos-sible to automatically generate networks by specifying various pa-rameters such as the number of individual subnets and their types,node degree, topology (star, ring etc.), average link bandwidth inthe core, distribution and access subnets and many more.

These subnets and their individual network elements such asrouters and links and their properties, i.e. routing tables, networkinterfaces etc., are modeled using the Eclipse Modeling Framework(EMF1) which also allows automated source code generation. Con-sequently, the model can easily be extended to include new featuresor adapted to match new requirements. Supported standard de-vice properties are processing speed, packet queuing mechanisms1http://www.eclipse.org/emf

Figure 1: Graphical user interface of NeSSi

and supported routing protocols; link properties include delay andbandwidth.

NeSSi supports static and dynamic routing protocols which canbe selected by the user. At the moment, static and dynamic proto-cols are implemented. A static routing protocol based on the Di-jkstra algorithm centrally computes the shortest paths as the net-work is loaded and each time the topology changes. The result-ing routing tables are subsequently loaded onto the individual net-work nodes. On the other hand, IS-IS (Intermediate-System-to-Intermediate-System) has been implemented which relies on a de-centralized algorithm during which routers exchange informationabout their link states and gather topology information locally. Inan iterative fashion, the routing tables at the individual nodes areupdated through control message exchange.

3.2.2 Traffic GenerationNetwork traffic in form of IP packets, complete with header and

body, can be generated by different means. A straightforward wayis to simply select a client and request a web page to be transferred(web client), or an e-mail to be sent (mail client) from a specifiedserver. Implementing the TCP/IP protocol stack, NeSSi features anapplication layer module which is based on standard Java socket

implementations. In this fashion, NeSSi can easily be extended tosupport a variety of other applications (see Section 3.3). In addi-tion, the concept of node profiles is incorporated in NeSSi. Nodeprofiles allow the customization of network node behavior in orderto automatically generate traffic adhering to well-defined charac-teristics and using various distribution models (standard, binomialetc). According to a virtual system-wide timer, so-called profile el-ements can be scheduled for one-time or repeated execution. Pro-file elements are elementary actions, like sending single UDP pack-ets or issuing HTTP requests. Each action contains a time stamp aswell as specific context information depending on the used proto-col. For example, for a HTTP request the name of the web serverand the requested URL are stored in the profile element. Figure 2shows the creation of a profile containing a HTTP request profileelement.

After defining a profile, it can easily be attached to several clientsby enabling it in the respective clients’ context menu. This conceptallows representing inherent system behavior or explicit user ac-tions and results in the automatic generation of traffic. This alsoincludes automated attack generation for the purpose of examin-ing security-related network features. Several adversary modelsare supported, among others worm spread and DDoS attack mod-

Figure 2: Detailed behavior of attached clients for custom traffic generation can be configured and scheduled

els. Automated attack generation has been successfully employedfor the generating simulation data in the research of the cooperativedetection approach (cf. Section 4). In the resulting paper [9], trafficstatistics of captured real traffic data were mapped to node profiles.

3.3 Protocol Stack and Socket-based APIThe TCP/IP reference model is the de-facto standard for Internet

communication. Due to its importance, NeSSi also offers an im-plementation for it. The routers as well as the end devices in thesimulation contain a Network Layer; end devices also exclusivelyhave a Transport and an Application Layer.

At the Network Layer, IPv4 is realized with the key featuresglobal addressing, routing and fragmentation support. Moreover,TCP/IP model implementation allows containing several protocolsin each layer; hence, we also provide IPv6 support in NeSSi. Forthe fault management, TTL (Time to live) and header checksumssupported and the ICMP protocol has been implemented for failurenotification. Network Layer communication is realized directly onthe drop-tail queues that are located at the network interfaces.

On the next level, the Transport Layer is comprised of UDP andTCP. TCP in NeSSi offers a reliable and in-order delivery of data.Sockets represent the interface to the Application Layer, i.e., appli-cations can set up several stream sockets as well as the correspond-

ing server sockets. In this fashion, third-party Java libraries caneasily be integrated in the simulation by substituting Java socketswith NeSSi sockets. As a proof-of-concept, the JavaMail API 2 hasbeen successfully adapted in NeSSi.

All applications that are run in NeSSi follow a common interfacethat abstracts from their specific behavior but allows a standardizedway of executing them. Currently, the HTTP, SMTP and IRC pro-tocols are integrated in NeSSi. Furthermore, the Application Layeroffers an environment allowing the simultaneous execution of sev-eral application instances.

Generated traffic in NeSSi can also be exported to files in thepcap3 format in order to inspect the data with standard traffic in-spection tools such as wireshark4. Several tests have been con-ducted with the traffic exported from NeSSi, verifying that the gen-erated traffic is well-formed. Wireshark is able to reconstruct theapplication data stream without errors if all corresponding IP pack-ets are in the exported file. The generated traffic can be analyzedeither offline, for example with the aforementioned tools, or onlinewithin the application itself, for example by displaying a graphical

2http://java.sun.com/products/javamail3http://www.tcpdump.org4http://www.wireshark.org

summary (cf. Figure 1).

3.4 Parallel-execution modelSimulations in large-scale networks are very costly in terms of

processing time and memory consumption. Therefore, NeSSi hasbeen designed as a distributed simulation, allowing the subdivisionof tasks to different computers and processes in a parallel-executionmodel. NeSSi introduces an additional layer of abstraction at thelevel of network design by explicitly modeling subnets 1, which inturn contain the end devices or routers (for example seen in Fig-ure 2). In NeSSi, the handling of subnets is distributed to severalprocesses on different individual machines, allowing the simula-tion to scale better with increasing network size. Figure 3 showsthe architecture of the distributed simulation. On the agent level,the simulation workload distribution is as follows:

Subnet Agent (SA) A subnet agent is responsible for managing anindividual subnet. During execution, the SA receives eventsfrom the PCA (see below) indicating that a new tick hasstarted. It performs all relevant operations such as packetforwarding and application handling that need to be executedfor the current tick (an atomic time frame in the discrete eventmodel). Once all events have been handled, the SA reportsback to the PCA that the tick has been successfully executed.

Platform Coordination Agent (PCA) On a single platform, dif-ferent subnet agents are created, configured and controlledby a platform coordination agent (PCA). A platform is meantas a software environment for agents running on one compu-ter. The number of subnet agents handled by the PCA isdependent on the available computing resources. The PCAreceives events from the NCA and relays them to all the SAsresiding on its platform. As soon as all SAs have reportedback that a tick has been executed successfully, the PCA isresponsible for forwarding the packets traveling from onesubnet to another subnet on a different platform to the re-spective target PCA. Subsequently, it informs the NCA thatthe platform has finished the requested task. The platformalso sustains a connection to the database, where simulationresults and history can be stored (see Section 3.5).

GUI Agent The GUI agent acts as a mediator between the soft-ware agent environment and the graphical user interface. Ittransmits control information from the GUI to the agents andin turn receives data from the agents which can be displayedin the GUI, for example statistical data on traffic and encoun-tered malware.

Network Coordination Agent (NCA) The entire network simu-lation is controlled by the network coordination agent (NCA).The NCA coordinates the distribution of the subnets at thebeginning of a simulation as well as the synchronization ofthe platforms. The NCA receives its network model datafrom the GUI agent. The GUI can also trigger the beginningand determine the end of the simulation, but the NCA doesnot depend on a GUI agent to be present once it has beenstarted. This architecture allows the distributed network sim-ulation. In addition, the graphical user interface can be dis-connected from the simulation environment and later recon-nect to it even from another computer. Figure 3 is a graphicalrepresentation of the distributed agent architecture.

3.5 Persistent Session ManagementIn NeSSi, we refer to a scenario where we generate traffic via

pre-defined profiles (cf. Section 3.2.1) on a single network over a

certain amount of time as a session. The accurate reproduction of asession enables users to use different detection methods or variousdeployments of detection units for the same traffic data set. Thisallows the comparison of performance and detection efficiency ofdifferent security framework setups.

For these purposes, we use a distributed database in which thetraffic generated during a session is stored. The database designis based on the session concept; each session consists of all trafficdata that occurs in a simulated scenario between a start and end timeusing a dedicated network model. The network model is saved in aXML file. This network file is stored and annotated with a versionnumber based on its hash code in order to link a network uniquelyto a session. Additionally, attack related events can be stored in thedata base for evaluation purposes. Those events are explained morein detail in section 4.3.

3.6 Graphical User InterfaceThe graphical user interface is a Rich Client Platform (RCP) ap-

plication based on the Eclipse framework. It comprises of a mainnetwork editor window grouped with a variety of different viewswhich provide additional information pertaining to the element cur-rently selected in the network editor. A selection of these views is:

Console Here, network status information and logged events aredisplayed. The desired level of verbosity can be configured.

Browser The browser view serves for displaying HTML resourceswhich were manually retrieved by executing the respectivecommand in the network editor.

Routing Table When a network node, i.e. a client, server or router,is selected, the respective routing table is displayed. For eachreachable target machine, it contains the IP addresses of thegateway, the subnet mask and the hop count.

Properties Displays and allows editing a number of properties forthe selected element. Among other information, device nameand device type are displayed for nodes; for links, bandwidth,latency and maximum transfer unit (MTU) is available.

Chart The Chart View serves as a graphical depiction of aggre-gated statistical data collected on the network traffic for theselected link. This data is received from the PCA’s databasesand updated periodically.

Sniffed Packets Supplementing the chart view, individual packetscan be displayed in a separate Sniffed Packets View. Packetsare color-coded according to their protocol type and sortedby the link they were captured on. Furthermore, a summaryof important information is given, such as source and desti-nation IP address and fragmentation offset.

The user interacts with the application via context-sensitive ac-tions. For more complex operations, the user is supported by wiz-ards. For example, when an IRC server is drag-and dropped on thenetwork editor, a context-menu action is dynamically created forthis node which allows executing a pre-defined IRC exploit sce-nario. When the user selects it, a wizard appears, describing thescenario and guiding the user through the process.

Simulation execution can be started, paused and stopped at anytime. Once a scenario was run successfully, the user can start anew scenario, opt to replay the same traffic with different detectionunits or deployments. When a scenario is not running, the user canalso change the network topology by adding and deleting links andnodes.

Figure 3: Architecture for distributed Simulations with NeSSi

4. SECURITY FEATURESIn the previous sections, we described the basic network model

and traffic generation features of NeSSi as well as other aspects re-garding general network simulation. The distinguishing feature ofNeSSi is the focus on network security framework and algorithmevaluation. Figure 5 provides a conceptual view on NeSSi the Net-work Security Simulator. The bottom layer shows some of the im-portant technologies that NeSSi uses. This includes the JIAC agentframework used for representation of the different entities in thesimulation, EMF for the network data model and Eclipse RCP forthe plug-in-based NeSSi application. On top of the bottom layer,several concepts realized in NeSSi can be found. These are theaforementioned general network simulation components like traf-fic modeling via node profiles, a parallel execution model, discreteevent simulation and the visualization. Additionally, tailored to theneeds of security experts, NeSSi incorporates the modeling of at-tacks and the security infrastructure (c.f. Section 4.2). Moreover,the Detection Unit API presented in section 4.1 offers the integra-tion of detection algorithms and the applied Reporting Engine andMeta Event model enable the user to generate sophisticated statis-tical evaluations.

4.1 Detection Unit APIForemost, NeSSi provides a Detection Unit API for the devel-

opment of new detection algorithms as well as the integration ofexisting ones. The architecture for this purpose is shown in figure6. It consists of four main components whose activation dependson the configuration of the detection approach; the Packet Captur-ing component is mandatory and processes incoming traffic from adata source. This is usually a link in the NeSSi simulation but canalso be file system streams or a database connection. Here, pack-ets are selected according to filter rules and a sampling policy (like“every tenth packet”) to narrow down the processing overhead. Ac-cordingly, the packets are associated with time stamps.

Several detection algorithms, e.g. behavior based approaches,

do not only process packets but also generate related statistical in-formation. As an example, the well-known SYN Flood attack ischaracterized by a massive amount of open TCP connections. Inthis case, the Packet Processing component offers the constructionof IPFIX5 data flows based on the packet data. The flow specifi-cation is open to the developer by configuration files. To this end,a tree structure of the flow is defined by providing key attributesand optional data fields. A data flow representing distinct TCP ses-sions must have at least a source IP address, destination IP address,source port, destination port and a protocol flag as key attributes.

Moreover, the Packet Post Processing component generates theactual input to the detection units. This input can also be specifiedby a detection unit which ranges from raw packets for signature-based schemes like virus scanners, to complex ratios of traffic statis-tics based on the flow data; for example in the case of a SYN Floodattack, the ratio of half-open TCP connections to all TCP connec-tions can be specified.

Finally, the detection units may be well-known security solu-tions as contemporary commercial virus scanner software or newtools developed in scientific research projects. In NeSSi, both canbe incorporated as long as they adhere to a specified interface. Theconfiguration of a detection unit and the required components arestored in a template. Furthermore, additional properties like Inlin-ing, i.e. synchronous packet processing, can be set. This allowsthe application of counter measures. A processing interval for adetection algorithm is another option that can be set here.

4.2 Attack and Security-InfrastructureThe simulation setup in NeSSi is not only comprised of network

creation (c.f. section 3.2.1) and attachment of traffic profiles (c.f.section 3.2.2), but additionally security related settings can be con-figured. When a security framework composed of several detectionunits is to be tested, profiles can also be used in NeSSi to simulate

5http://www.ietf.org/html.charters/ipfix-charter.html

Figure 4: Simulating a DDoS attack in an IRC scenario

attacker behavior and attack patterns. Accordingly, NeSSi providesout-of-the box support for various attack scenarios such as bot net-works initiating DDoS attacks. Here, infected end device nodes,“zombies”, are controlled by the bot net commander via the Inter-net Relay Chat application. The commander is capable of initiatingdifferent kinds of DDoS attacks like the SYN Flooding or UDPStorm. To this end, the attacker connects to an IRC communicationserver and sends attack commands to a chat channel all the bots arelistening to. As a result, the bots execute the desired attack.

Besides, worm propagation schemes are supported. Here, thebehavior of the SQL Slammer worm and the Blaster worm hasbeen realized exemplarily in NeSSi. In general, a worm propaga-tion scheme as well as the SIR model (Susceptible Infected Recov-ered) as an epidemiological model is included in NeSSi. The wormpropagations scheme can be configured in different ways: on theone hand there exist configuration files defining the number of ini-tial propagators and where in the network the outbreak should takeplace. Additionally, the spreading scheme, i.e. which IP addressesto attack and delays in between, can be set.

On the other hand, the worm application model itself can eitherbe extended or a new one can seamlessly be integrated via the ap-plication interface provided in NeSSi (cf. 3.3). In the second step,newly developed or pre-configured detection units can be deployedon a set of links in the simulation. Therefore, analogous to thetraffic profiles, detection profiles can be created. Those detectionprofiles consist of one or more detection units and can be deployed

on end devices, links or routers. Details of how these deploymentsare evaluated with regard to their efficiency can be found in Sec-tion 5.2. The tools used for these evaluation tasks are described inthe next section.

4.3 Reporting and EvaluationNeSSi allows the simulation of various security scenarios. Ad-

ditionally, there is a huge diversity in network security evaluationmetrics. Here, the developer of a detection algorithm respectivelyof a special security infrastructure set-up may not only be inter-ested in detection rates, but also in the economical assessment of ascenario.

Hence, the gathering of simulation results and the evaluation hasto be very flexible. Here, we apply an event-based approach, theso-called Meta Attack Events. Already included events incorporatedropped packets, infected flows, compromised machines, unavail-able services etc. Those events are stored in the database at run-time. Events belonging to the same attack refer to a global ID todifferentiate between the impacts of different attacks. The databaseassociates those events with a time stamp in the simulation as wellas a device and/or transmitted packets related to that specific event.

Furthermore, we apply BIRT6 (Business Intelligence and Re-porting Tools) for visualization and analysis of results. BIRT iscomprised on the one hand of a graphical report designer capa-ble of creating report templates. In those templates, different input6http://www.eclipse.org/birt/phoenix

NeSSi- Network Security Simulator

Design Environment Simulation Core Evaluation of Results

Attack Modelling

Network and Security Infrastructure

Traffic Modelling Distributed Simulation

Eclipse RCP JIAC EMF

Visualization

Statistical Evaluation Component

Reporting EngineDiscrete Event Simulation

Detection Unit API

Figure 5: NeSSi, the Network Security Simulator is comprised of several components presented in the middle layer. The conceptscharacterizing NeSSi as a security simulation environment are accented. The bottom layer depicts some of the main used technolo-gies.

sources like databases, simple Java objects or XML files can be de-clared. Additionally, BIRT allows standard statistical operations onthe data and enables the choice of several chart types to display theresulting data series. More complex preprocessing can easily becarried out by adding Java or JavaScript code.

On the other hand, BIRT offers an environment for the gener-ation of the reports at runtime. In this case, a report template isloaded and the actual selected data source, in the example of NeSSiusually a simulation session is bound to the report. Subsequently,an HTML document containing the desired report is generated andcan be shown in any Internet Browser. Figure 7 shows an exam-ple report created in the NeSSi environment. It compares detectionrates of different algorithms; the detection rate is measured as de-tected number of infections in comparison to the total number ofinfections (sensitivity). In the following section, practical relevanceof the presented concepts is shown in some examples.

5. CASE STUDIESNeSSi has already demonstrated its value in recent research and

was employed as a test framework for various network-centric se-curity approaches.

5.1 Artificial Immune SystemFor example, a distributed and collaborative Artificial Immune

System (AIS) was implemented in NeSSi for testing an anomaly-based detection algorithm [9]. In this scenario, anomaly detectionunits on different hosts compute the probability of an anomaly byan AIS component. The idea of AIS is to compute the possibilityof an anomaly by comparing the actual status of the system to a setof detectors created by negative selection [4]. This algorithm is ametaphor of the biological negative selection taking place duringthe maturation of the immune cells. The detectors are producednearly randomly and compared to the normal data; if a detector

is similar to a normal feature vector, it is deleted and a new oneis created, this is done until no detector is similar to the normalfeature vector set (training set).

The data processed by the AIS is statistical in nature and ob-tained by a monitoring component on the host agent. Here, theprobability of an anomaly constitutes the status of a client. Thecooperation between the clients takes place by sharing these sta-tus levels and computing new status level information based on theincoming status of others and its own status. The tests results, ver-ified in NeSSi, indicated a very good performance of the AIS ingeneral while the false positive rate (the main problem of anomalydetection systems) was lowered significantly. The communicationbetween the AIS clients described in [9] has been implemented inNeSSi via a customized peer-to-peer protocol to avoid the singlepoint-of-failure of a central server. This peer-to-peer protocol al-lows the combination of AI Systems into detection groups.

As an extension, a scheme for the decentralized detector set gen-eration was presented by Bye et al. [3]. Here, the overall featurespace is partitioned in several sub spaces administrated by AIS-enabled nodes. As a result, the individual computational load foreach node is decreased. Nevertheless, by the application of com-binatorial design techniques like Symmetric Balanced IncompleteBlock Design or Generalized Quadrangles a controlled level ofoverlap between the detector sets is realized and sets are exchangeddeterministically via a peer-to-peer system. Finally, this results ina trade-off between the aforementioned computational task on theone hand and a guaranteed level of redundancy on the other hand.

5.2 Detection Device PlacementAs a second use-case scenario, we studied various detection de-

vice placement approaches. To this end, we used a number of iden-tical detection units in order to ensure comparability. The typeof detection unit to use can be selected prior to starting the de-

Detection Units

ANOMALY-BASED DU

SIGNATURE-BASED DU

CLASSIFICATION

AGGREGATION

Packet ProcessingPacket Post Processing

SELECTION

DU-DATA-GENERATION

FILTERING

FILTERING

SELECTION

Packet Capturing

TIMESTAMP

INLININGInput Source

Figure 6: The components of the Detection API and thepacket/data flow between them. The Packet Processing com-ponent is not necessary for all detection algorithms.

vice placement scenario in NeSSi. Furthermore, the configurationdialog allows selecting how many total detection devices may beplaced, representing a total sampling budget. The objective is thento maximize the detection efficiency subject to the budget con-straints. Several algorithms are supported for computing sensi-ble deployment strategies, for example Betweenness Centrality [2],Traffic Betweenness Centrality [1] or a selection of game-theoreticapproaches [6, 14].

In NeSSi, we have already successfully evaluated two of theseapproaches, namely node selection algorithms using the Between-ness Centrality paradigm as well as a monitor placement game de-scribed in [14]. The Betweenness Centrality algorithm originatesfrom social network theory and indicates the importance of a nodein the overall network communication. It is run in NeSSi in an Ex-ecutorService after a change to the network topology occurs andreturns a numerical value for every node indicating its centralityindex. Subsequently, detection devices are placed on the devicescorresponding to the nodes with the largest values as an optimal de-ployment. We then ran a test with default traffic generation profileson all clients for a fixed number of execution cycles. For compari-son, we subsequently fed the same traffic in the same network butdeployed the detection units randomly. The results indicate the su-periority of deploying on nodes with high Betweenness Centralityindex. We assume that in case traffic is not uniformly distributed inthe network, i.e. there are clients who generate considerably moretraffic than others, the Traffic Betweenness Centrality [1] approachwould be even more suitable.

In the second study, a game-theoretic approached was employedwhere the attackers and the IDS are modeled as adversaries in atwo-person game. We were able to demonstrate the existence of amixed-strategy saddle-point equilibrium and computed its value for

Figure 7: Reporting in NeSSi: This report shows an evaluationof the detection ratio (sensitivity) of different detection algo-rithms

two example networks. The adversaries are modeled as Runnablesin NeSSi. Upon starting the simulation, the respective threads arestarted simultaneously, and elementary player actions from the stra-tegy matrix are selected using a random number generator. It waspossible to verify the game-theoretic optimality and measure theperformance of the obtained strategies to the devised network se-curity game.

5.3 Detection Algorithm EvaluationIn a university graduate class, NeSSi was used to produce data

for evaluating detection algorithms implemented by students with-out any knowledge of the simulator. When it is not required to an-alyze simulation data at runtime, NeSSi allows to store simulationdata, e.g. the IP packets, in the database. In the anomaly detectionclass, NeSSi was used to simulate "normal" traffic, a DDoS attackand a worm attack. The students were tasked with implementingan anomaly detection algorithm and comparing detection resultsbetween different algorithms, attack types and detector placementswithin in NeSSi. All these different experiments were based on thesimulation data stored in the NeSSi database.

6. CONCLUSION AND OUTLOOKWe have presented and described the Network Security Simula-

tor NeSSi. Based on agent technology and discrete event simula-tion, it is a highly-scalable, platform-independent network simula-tion tool with special features for evaluating security solutions. Inparticular, the plug-in-based API allows security experts to writetheir own detection unit plug-ins and test them in NeSSi.

Network simulation is a very wide and complex area in softwareengineering. There is an abundance of features existing in real-life networks; moreover, standards are changing and new standardsare introduced continuously at a rapid rate. Hence, keeping NeSSiup-to-date with the latest trends in network technology is a greatchallenge. The following is a list of features we plan to focus on inthe further development of NeSSi. For comparison, a list of features

for the next generation of ns-2 (some of them are already supportedin NeSSi) can be found in [11].

Usability In order to appeal to a greater audience, the usability ofthe simulator can be improved. This includes role-based userinterface perspectives dependent on experience level (noviceor expert).

Scenarios More default attack scenarios will be supported. Wewill extend the already realized Bot Net infrastructure capa-ble of executing DDoS-attacks (cf. Figure 4) by peer-to-peerprinciples. Peer-to-peer bot nets are regarded as an emergingimportant threat in Network Security.

Open-source We plan to publish NeSSi under an open-source li-cense.

Acknowledgement: The authors would especially like to thanktheir scientific advisors Ahmet Camtepe and Tansu Alpcan for theirinvaluable support and their fellow colleagues Thorsten Rimkus,Sebastian Linkiewicz, Marcus Lagemann and Joël Chinnow fortheir dedicated work on this project.

7. REFERENCES[1] M. Bloem, T. Alpcan, S. Schmidt, and T. Basar. Malware

filtering for network security using weighted optimalitymeasures. In Proc. of 2007 IEEE Multi-conference onSystems and Control. IEEE, 2007. to appear.

[2] U. Brandes. A faster algorithm for betweenness centrality.Journal of Mathematical Sociology, 25(2):163–177, 2001.

[3] R. Bye, K. Luther, S. A. Çamtepe, T. Alpcan, SahinAlbayrak, and B. Yener. Decentralized Detector Generationin Cooperative Intrusion Detection Systems. InS. Masuzawa, Toshimitsu; Tixeuil, editor, Stabilization,Safety, and Security of Distributed Systems 9th InternationalSymposium, SSS 2007 Paris, France, November 14-16, 2007Proceedings, Lecture Notes in Computer Science , Vol.4838. Springer, 2008.

[4] S. Forrest, A. S. Perelson, L. Allen, and R. Cherukuri.Self-nonself Discrimination in a Computer. In Proceedingsof the IEEE Symposium on Research in Security and Privacy,pages 202–212. IEEE Computer Society Press, 1994.

[5] S. Fricke, K. Bsufka, J. Keiser, T. Schmidt, R. Sesseler, andS. Albayrak. Agent-based telematic services and telecomapplications. Communications of the ACM, 44(4):43–48,April 2001.

[6] M. Kodialam and T. Lakshman. Detecting network intrusionsvia sampling: A game theoretic approach. In ProceedingsIEEE INFOCOM 2003. Twenty-Second Annual JointConference of the IEEE Computer and CommunicationsSocieties, volume 3, pages 1880–1889, Apr. 2003.

[7] M. Liljenstam, J. Liu, D. Nicol, Y. Yuan, G. Yan, andC. Grier. Rinse: The real-time immersive network simulationenvironment for network security exercises. PADS,00:119–128, 2005.

[8] B. Liu, D. Figueiredo, Y. Guo, J. Kurose, and D. Towsley. Astudy of networks simulation efficiency: Fluid simulation vs.packet-level simulation. In INFOCOM 2001. TwentiethAnnual Joint Conference of the IEEE Computer andCommunications Societies. Proceedings. IEEE, volume 3,pages 1244–1253, 2001.

[9] K. Luther, R. Bye, T. Alpcan, S. Albayrak, and A. Müller. ACooperative AIS Framework for Intrusion Detection. In

Proceedings of the IEEE International Conference onCommunications (ICC 2007), 2007.

[10] D. M. Nicol, M. Liljenstam, and J. Liu. Advanced conceptsin large-scale network simulation. In M. E. Kuhl, N. M.Steiger, F. Armstrong, and J. A. Joines, editors, WinterSimulation Conference, pages 153–166. ACM, 2005.

[11] ns-3 project. NS-3 network simulator.http://www.nsnam.org/docs/architecture.pdf.

[12] G. F. Riley. The Georgia Tech Network Simulator. InProceedings of the ACM SIGCOMM workshop on Models,methods and tools for reproducible network research, pages5–12. ACM Press, 2003.

[13] Scalable Network Technologies Inc. Qualnet.http://www.scalable-networks.com.

[14] S. Schmidt, T. Alpcan, S. Albayrak, and A. Müller. AMonitor Placement Game for Intrusion Detection. In Proc. ofCRITIS, 2nd International Workshop on Critical InformationInfrastructures Security, Lecture Notes in Computer Science.Springer, 2007. to appear.

[15] USC Information Sciences Institute. NS-2 network simulator2.31. HTTP://WWW.ISI.EDU/NSNAM/NS/DOC/NS_DOC.PDF.

[16] S. Wei, J. Mirkovic, and M. Swany. Distributed wormsimulation with a realistic internet model. PADS, 00:71–79,2005.

[17] J. B. Yun, E. K. Park, E. G. Im, and H. P. In. A scalable,ordered scenario-based network security simulator. InSystems Modeling and Simulation: Theory and Applications,volume 3389/2005 of Lecture Notes in Computer Science(LNCS), pages 487–494. Springer-Verlag, 2005.