MUSES HACKATHON – DESCRIPTION OF PROJECTS

Server performance upgrade of the corporate security system MUSES

Description

The MUSES server shall provide a stable and secure connection for many users. The goal of this performance upgrade is to ensure that the MUSES server can handle standard requirements for such a service.

Using a specially developed tool, the MUSES server performance can be tested and key communication parameters can be measured. The tool will simulate the client behavior e.g. it can repeatedly send requests to the server which is useful for stress testing.

A container like Tomcat will spawn multiple threads (one for each client/connection if necessary) in order to be able to serve multiple clients at the same time. Once a program is required to be thread-safe, special care needs to be taken otherwise the program will run slow or even crash/halt. Access to shared resources between several threads needs to be handled properly. In some cases shared resources can be the cause of bottlenecks. According to Amdahl’s Law the speed up of a program (in an ideal scenario) is limited to the sequential fraction of the program.

Area of Work
  • Apache Tomcat – There might be some configurations that can be done in order to gain more parallelization but contributing to the Apache Tomcat project is definitely not one of the tasks.
  • JSP Servlet – Tomcat can spawn threads for handling each instant of a servlet/JSP. So shared resources between different instances of servlets are worth looking at among other things.
  • MUSES Connection manager
Requirements
  • The server shall be able to handle a reasonable number of connections per minute. Measure and do some benchmarking using the client simulator. Analyze and discuss the results. Monitor the processor, bandwidth and memory allocations on the server while multiple users are connected. Are the numbers reasonable?
  • The Response time should also be reasonable. More importantly it should not scale linearly with the number of connected clients.
  • Access to shared resources between several threads needs to be handled properly e.g. there is potential for deadlock/livelock when accessing more than one shared resource at the same time.
  • Do some benchmarking and analyze the result before jumping into coding. Find some potential bottlenecks e.g. exclusive access to shared resource can hurt performance. Don’t micro optimize parts that give small gains (Pareto principle).
  • Some optimizations might require large changes to the code base/architecture. In those cases just discuss the benefits of the change rather than changing the entire architecture.

Muses server web based user interface

Description

To be able to use MUSES in a company environment, an intuitive and precise user interface is needed for the server. The Server UI allows the CSO to configure and control MUSES, and access the MUSES feedback.

The MUSES server data is accessible through MySQL.

Configuration
  • Users / Devices / Password
  • Assets / Confidentiality
  • Rules
  • Policies
  • Privacy Settings
  • Server settings
  • Communication settings
Feedback
  • Potential Security incidents
  • Refined rules
  • Suspicious events or Event frequency
  • User feedback frequency
Requirements
  • Web based interface
  • User authentication

Command signature and verification component

Description

Any incoming command from MUSES Server to Client, is required to be signed in order to effectively ensure that any incoming command is originated from the corporate MUSES Server.

Importance

The received data will usually be instructions sent to the MUSES Client. No data privacy is needed but we must be sure of its authenticity to be sure that the server hasn’t been impersonated.

Requirements
  • The received instructions by the MUSES client must be signed in order to be sure that the sender is the legitimate one and the instructions were not tampered.
  • The received data is signed with the private key only available for the server and verified by public key available for all the clients.
  • The TLS certificate could be reused, but it’s advisable to be different in the case of one of the certificates gets compromised.

 Android public key data encryption component

Description

Data storage in the MUSES Client (Android version) must be encrypted with public key, in order to ensure that the information cannot be retrieved in case the device is stolen or lost.

Importance

The data collected by MUSES is considered private and highly sensitive. Only theMUSES server should be allowed to understand it. Additionally, we need to maintain the minimum amount of data stored on the device. But sometimes it’s impossible because of temporal lack of connectivity. All the new OS support data isolation, file system encryption. They also provide a wide array of algorithms for protecting data using cryptography. However, it should be kept in mind that in this case the information is protected by the device unlock key, then its security is dependent on the security of the device unlock code.

Requirements
  • MUSES will store sensitive data on the server instead of the client-end device. This is based on the assumption that secure network connectivity is sufficiently available and that protection mechanisms available to server side storage are superior.
  • The solution is to store the data encrypted with public key so only the server with the corresponding private key can decrypt it. The data collected by the sensors must be encrypted before being sent or stored for later sending. In the Android prototype it’s possible to use RSA public key cryptography.

Data Mining applied to security-based data: Analysis and Visualization tools

Description

Starting from a database storing event-related data, we have to extract useful patterns to be processed by Data Mining and Machine Learning tools. We will implement and/or apply some data analysis and visualization methods, such as clustering techniques, which can be used to identify interesting patterns or relationships among the data.

Importance

This will be useful for the Chief Security Officer (or the human controller of MUSES), who could check how the information in the system is distributed/related, i.e. more frequent events/actions, relationships between them, and even detect suspicious patterns or behaviours, among other utilities.

Requirements
  • State of the art over data visualization tools, especially for event-type of data.
  • Visualization outputs (cluster images)
  • Strange/Suspicious pattern identification
  • A tool to show this useful information to the CSO

 

European Commission logo

 MUSES – Multiplatform Usable Endpoint Security
This project has received funding from the European Union’s Seventh Framework Programme for research, technological development and demonstration under grant agreement No. 318508 
The overall purpose of MUSES is to foster corporate security by reducing the risks introduced by user behaviour.