A selection of existing features
Attack Modelling. The simulation setup in NeSSi˛ is not only comprised of network creation and attachment of traffic profiles, but additionally security related settings can be configured. When a security framework composed of several detection units is to be tested, profiles can also be used in NeSSi
Detection Unit API. The main focus of NeSSi˛ is to provide a realistic packet-level simulation environment as a testbed for the development of new detection units as well as existing ones. The term detection unit is to understand as an abstract term for any algorithm or tool employed for the purpose of detecting malicious activity such as intrusion or service degradation attempts. NeSSi˛ provides a Detection Unit API for the development of new detection algorithms as well as the integration of existing ones. The architecture consists of four main components whose activation depends on the configuration of the detection approach. The Packet Capturing component is mandatory and processes incoming traffic from a data source. This is usually a link in the NeSSi˛ simulation but can also be file system streams or a database connection. Here, packets are selected according to filter rules and a sampling policy (like “every tenth packet”) to narrow down the processing overhead. Several detection algorithms, e.g. behavior based approaches, do not only process packets but also generate related statistical information. In this case, the Packet Processing component offers the construction of IPFIX (IP Flow Information Export) data flows based on the packet data. The flow specification is open to the developer by configuration files. Moreover, the Packet Post Processing component generates the actual input to the detection units. This input can also be specified by a detection unit which ranges from raw packets for signature-based schemes like virus scanners, to complex ratios of traffic statistics based on the flow data. Finally, the detection units may be well-known security solutions as contemporary commercial virus scanner software or new tools developed in scientific research projects. In NeSSi˛, both can be incorporated as long as they adhere to a specified interface. The configuration of a detection unit and the required components are stored in a template. Furthermore, additional properties like Inlining, i.e. synchronous packet processing, can be set. This allows the application of counter measures. A processing interval for a detection algorithm is another option that can be set here.
Evaluation of Results
NeSSi˛ allows the simulation of various security scenarios. Additionally, there is a huge diversity in network security evaluation metrics. Here, the developer of a detection algorithm respectively of a special security infrastructure set-up may not only be interested in detection rates, but also in the economical assessment of a scenario. Hence, the gathering of simulation results and the evaluation has to be very flexible. Here, we apply an event-based approach, the so-called Meta Attack Events. Already included events incorporate dropped packets, infected flows, compromised machines, unavailable services etc. Those events are stored in the database at runtime. Events belonging to the same attack refer to a global ID to differentiate between the impacts of different attacks. The database associates those events with a time stamp in the simulation as well as a device and/or transmitted packets related to that specific event. Furthermore, NeSSi˛ provides various charts for visualization and analysis of results.
Technologies used by NeSSi˛
JIAC. NeSSi˛ is built upon the JIAC framework. JIAC is a service-centric middleware architecture based on the agent paradigm. Within NeSSi˛, agents are used for modeling and implementing the network entities such as routers, clients, and servers. The underlying JIAC agent framework provides a rich and flexible basis for implementing and testing of various security deployments and algorithms in NeSSi˛. Moreover, building upon an agent framework allows combining the partial knowledge of the agents residing in the network in a cooperative approach for identifying and eventually eliminating IP-based threats. For example, this may be achieved by monitoring the structure of the encountered IP traffic and the behaviour of potentially compromised target systems. Although the software agents provide powerful application-level capabilities, their complexity unfortunately also affects the scalability of the simulation. Additionally a parallel-execution model allows dividing the usage of a simulation to many distributed platforms, administrated by software agents.
Eclipse RCP. The graphical user interface is a Rich Client Platform (RCP) application based on the Eclipse framework. It comprises of a main network editor window grouped with a variety of different views which provide additional information pertaining to the element currently selected in the network editor. For more complex operations, the user is supported by wizards.
Eclipse Modeling Framework. Most of the network elements with their properties used in NeSSi˛ such as router, routing tables, links, etc. are modeled using the Eclipse Modelling Framework (EMF) which also allows automated source code generation. Consequently, the model can easily be extended to include new features or adapted to match new requirements.
