View source for RedZone

Assume that attacks and breaches are unavoidable; focus on how to
make systems resilient in spite of them. For instance, extend Recovery
Oriented Computing (ROC) ideas to apply to the security infrastructure. What
if instead of a company or country running services on servers, having
them run on virtual machines (cf. what Amazon offers with its EC2
service) that run on farms and can be brought up and down at will? If
something is attacked, we just bring it down and spawn another
pre-configured virtual machine hosting exactly the same services... In
sort, combine virtualisation and ROC for security infrastructure.

Recent moves in security infrastructure could already be interpreted under this light.
DNS root servers have started adopting anycast, in which case traffic from a compromised
server will automatically switch to a standby server via BGP. 

Coming back to virtualisation, imagine we have an infrastructure that can host
fully configured services; e.g., an image of a DNS server, or e-mail server, etc. 
The server itself runs as an instance of that image. When the image is attacked or
compromised, you just bring up another image. This requires:

* A substrate on which the virtual machines will run
* A way to configure virtual machines and package them, so as to be ready for deployment
* A way to interact with the substrate and the virtual machines in order to control their operation

==Cons==

The marriage of virtualisation and security is not exactly new, see [http://www.virtualization.info/2006/07/security-by-virtualization.html] and [http://en.wikipedia.org/wiki/Bitfrost Bitfrost].

== Cover Letter==

'''ACRONYM'''

'''NAME'''

===Description===

'''STREP proposal (FP7/ICT)'''

'''Strategic Objective: ICT-SEC-2007.1.7: Critical Infrastructure Protection (Joint Call between ICT and Security Themes FP7-ICT-SEC-2007-1)'''

Critical infrastructures comprise a large number of complex, interconnected systems, where software plays an important role. Failures of critical infrastructure software components can have far-reaching impact; such failures may be the result of malicious intent (i.e., attacks, viruses, etc.) or they may be the result of lurking software bugs. For certain critical components, shutting down the malfunctioning part is not an option, as even decreased quality of service is better than complete service disruption – consider air traffic control systems, or even an online auction site. This has led to an increased interest in the area of self-adapted and self-healing systems. At the same time, legal frameworks, security and auditing concerns, demand that, especially in malfunctions, data is captured and made available for security forensics.

The proposed project aims at self-adaptability, self-healing, and security forensics enablers. Specifically, we plan to develop techniques that will allow systems to continue running even in the presence of faults (accidental or malicious). These techniques will reduce the likelihood of unnecessary infrastructure service termination, and provide a better understanding of the infrastructure failure, or the factors that led to that failure. In order to do that, we will pursue research in the following areas:

* ''Profiling critical infrastructure software components'': In order to diagnose a malfunction, we need to be able to distinguish normal from abnormal behaviour. We will investigate methods that will allow us to derive and specify the normal behaviour of software components. If, later, during operation a software infrastructure component deviates from the expected behaviour, we will be alerted that it has moved beyond its accepted operational parameters, its ''normal operational envelope''.

* ''Allow controlled execution outside the operational envelope'': We define an area outside the normal operational envelope, which we call the ''red zone''. If a software component enters the red zone, we know that it has moved beyond its normal behaviour, but we do not know the cause and the severity of the problem. Rather than terminating or suspending the component, we place it into an appropriate container and we enter an increased state of readiness. We allow the component to continue to run, taking actions to limit the damage caused. In parallel, we collect any data that may be of use in tracing the origin of the malfunction.

The software component profiling, and the controlled execution in the red zone, will be performed in the context of properly adapted virtual machines that will host the critical components. The proposed project will therefore build on the latest trends in virtualisation, and we will research on using virtual machines as an important component for building reliable, resilient, and always available information infrastructures.

The project's software deliverables will be available for internal use by the project's partners and in the future could become part of or form the basis of novel products and business solutions. Scientific contributions will be exploited by means of journal articles and conference publications. Licensing and commercial exploitation of research results will be discussed during the proposal preparation phase.

===What we need from you===

This project is a research proposal being submitted for the first time. We plan to carry out the major parts of the write-up using our own resources, although help from partners will be greatly appreciated. We expect our partners to contribute their opinions in areas of their particular expertise and to formally review the proposal before it is submitted.

===Further information and communication===

This proposal is initiated by the Software Engineering and Security Group of the Information Systems Technology Laboratory, directed by Diomidis Spinellis (http://www.dmst.aueb.gr/dds/), hosted by the Department of Management Science and Technology at the Athens University of Economics and Business.

Our website: http://istlab.dmst.aueb.gr.

Contact us by email at louridas@aueb.gr .


==Possible Partners==

* Ericsson

* University of Cambridge (if we use VMs and specifically Xen)

* Cyprus Telecommunication Authority (but we may end up Eurovision-style)