Management and Service-aware Networking Architectures (MANA) for Future Internet Position Paper: System Functions, Capabilities and Requirements

Future Internet (FI) research and development threads have recently been gaining momentum all over the world and as such the international race to create a new generation Internet is in full swing: GENI, Asia Future Internet, Future Internet Forum Korea, European Union Future Internet Assembly (FIA). This is a position paper identifying the research orientation with a time horizon of 10 years, together with the key challenges for the capabilities in the Management and Service-aware Networking Architectures (MANA) part of the Future Internet (FI) allowing for parallel and federated Internet(s)

Validation of the Parlay API through prototyping

The desire within the telecommunications world for new and faster business growth has been a major drive towards the development of open network API. Over the past 7 years several (semi) standardization groups have announced work on network API, including TINA-C, JAIN, IEEE P1520, INforum, 3GPP, JAIN, Parlay. The Parlay group seems most successful in attracting industry awareness with their API, called the Parlay API. The rational behind the Parlay API is that it attracts innovation from third parties that are outside the network operator's domain to build and deploy new network-hosted applications. This also means that the public telecommunication network is opened for niche and short-lived applications as well as for applications that possibly integrate telephones with other terminals such as PC. The Parlay group has successfully passed the first two phases of success, namely publishing their API on the right moment in time and attracting a critical mass within the telecommunication industry with their results. Prototyping the API on a real network execution platform is the only way to show its technical feasibility. Such an exercise was executed internally within Lucent Technologies and raised a number of questions as well as recommendations on both the technical and the semantical behavior for systems that will be interconnected via the Parlay API. We share these results, showing the drawbacks and advantages as well as challenges for this AP

Incident Analysis & Digital Forensics in SCADA and Industrial Control Systems

SCADA and industrial control systems have been traditionally isolated in physically protected environments. However, developments such as standardisation of data exchange protocols and increased use of IP, emerging wireless sensor networks and machine-to-machine communication mean that in the near future related threat vectors will require consideration too outside the scope of traditional SCADA security and incident response. In the light of the significance of SCADA for the resilience of critical infrastructures and the related targeted incidents against them (e.g. the development of stuxnet), cyber security and digital forensics emerge as priority areas. In this paper we focus on the latter, exploring the current capability of SCADA operators to analyse security incidents and develop situational awareness based on a robust digital evidence perspective. We look at the logging capabilities of a typical SCADA architecture and the analytical techniques and investigative tools that may help develop forensic readiness to the level of the current threat environment requirements. We also provide recommendations for data capture and retention

ARIES WP3 – Needs and Requirements Analyses

Information and communication technologies have increasingly influenced and changed our daily life. They allow global connectivity and easy access to distributed applications and digital services over the Internet. This report analysis security requirements on trust establishment and trust evaluation based on two different use case scenarios: "Trusted Communication using COTS" and "Trust Establishment for Cross-organizational Crises Management". A systematic needs analysis is performed on both scenarios which haver resulted in a large and well documented set of requirements. This is the first step in a large effort to define a security architecture for the two use case scenarios.