Cloud-based applications (including NFV services) are increasingly designed as “graphs” or “chains” of simple applications (often called micro-services), connected by virtual (network) links, and deployed over a virtualised set of computing, storage, and networking resources, indicated as the “execution environment.” The need to dynamically adapt the software to the evolving context is leveraging software orchestration to automate deployment and life-cycle management operations. Starting from a topological model, a set of deployment constraints, and a set of management policies, orchestration takes care of resource provisioning, image booting, software installation and configuration, and run-time modifications of the service graphs to tackle failures, workload variations, user movements, and so on.



The need for ever-more agility and adaptability to the evolving context at both the infrastructure and service layer is pushing towards self-adaptability in execution environments and self-awareness in programs. Fully-automated software and environments will evolve and morph during run-time to learning and cognition, without the explicit control of software engineers. From a security perspective, this new practice is now revealing the substantial inadequacy of legacy security appliances to effectively protect distributed, heterogeneous, and mutable systems against cyber-threats. Since valuable ICT assets cannot be easily enclosed within a trusted physical sandbox any more, there is an increasing need for a new generation of pervasive and capillary cyber-security paradigms over distributed, multi-domain, and geographically-scattered systems.

Today responses to attacks to virtualised services often come late because of the need for human intervention. Following the wave for more automation in the management of cloud applications, the general approach of ASTRID is tight integration of security aspects in the orchestration process. Starting from the descriptive and applicative semantics of a Security Model, orchestration is expected to deploy and manage the life-time of the service, by adapting the awareness layer of individual components and the whole service graph according to specific needs of detection algorithms.



ASTRID will leverage service orchestration to automatically a) interpret security policies, b) configure the execution environment, c) collect data, measurements, and events both from single functions and whole service graphs; d) react to threats and attacks according to specific strategies.

The purpose is to get more details for critical or vulnerable components when anomalies are detected that may indicate an attack, or when a warning is issued by cyber-security teams about new threats and vulnerabilities just discovered. The intermediate orchestration layer enables also reaction and mitigation actions, hence shortening the time to respond to attacks. For instance, it can dynamically update or replace an application that has been found vulnerable to a specific threat with another one, which may perform the same job but it not vulnerable to that threat. Or, when an attack is detected and pinpointed, it can reinforce protection by instantiating traffic filtering rules in front of the victim service, which discards most of the unwanted traffic. Or, when an application has been compromised, it can either disconnect it (so that the attacker cannot go anywhere) or keep it isolated and use it as honeypot, but passing “fake” traffic to cheat the attacker and collect useful information about his behaviour.

Orchestration automates the deployment and life-cycle management of virtual services, but must act according to specific intention and needs of users. Many recent orchestrators use policies to drive the orchestration process. Policies are sets of operating rules, usually in the form ‘on event, if condition, then action’, that reflect the resource owner’s intention of adequately protecting valuable resources. Policies are typically specified separately to the system implementation to allow them to be easily modified without altering the system. ASTRID will design complex policy based decision considering that:

• specific customization of the service towards the goals – the missing part of all the NVF based architectures is that the “clones” which are deployed for each tenant are not properly customized for the usage resulting into very uniform security deployments not appropriate for the service usage;
• being a complex system, multiple events will be received from multiple entities requiring different types of decisions for the orchestration. In order to mitigate these multiple decisions a new mechanism for ensuring the security of the system, goal oriented, is proposed in which the events themselves will not be treated immediately, but instead will be mitigated in a correlated manner in order to reach a specific goal in terms of system security, considering the parallel discovery and mitigation of other vulnerabilities. This would bring more scalability in even the largest services (e.g., carrier’s large scale virtual networks, and worldwide mass applications as social nets);
• targeted mitigation system providing the means to execute orchestrated set of actions in a specific order including the development of means to adapt the service graph and to adapt the usage of the service by specific subscribers while communicating with the “in-environment” security components. This adaptation will enable the security operations to remain transparent to the service itself while at the same time to respond in a proper manner across the distributed environment.

The Infrastructure-as-a-Service (IaaS) model is a very effective and agile paradigm that provides computing, storage, and networking resources corresponding to physical instances (servers, switches, disk arrays, network links). Although de-coupling software from the underlying infrastructure brings immediate benefits in terms of elasticity, portability, automation and resiliency, the intermediate hypervisor tier also raises new security concerns about the mutual trustworthiness between those two layers and the potential threats in the virtualization substrate. The objective impossibility to apply the legacy security perimeter model to emerging software architectures has boosted an increasing interest in the development of security and privacy solutions for the new paradigms. This effort has resulted in commercial and open-source security appliances for the cloud, including distributed firewalls, antivirus, intrusion detection systems, and identity/privacy management, often implemented in the hypervisor layer (infrastructure-centric cyber-security framework). Virtual security functions can be easily “plugged” into service graphs, leveraging the large correspondence with physical infrastructures that is present in this case (service-centric cyber-security framework). However, application to other cloud models is not straightforward, especially when some software components are shared among multiple tenants (i.e., Service-as-a-Service), they should run on resource-constrained devices (i.e., the fog or IoT), or the service topology changes over time (e.g., for scaling, discovery of new components, failures). In addition, given the lack of standard APIs and control interfaces, data collection, harmonization, and correlation may be very difficult.

The distinctive aspect of the ASTRID approach is that no explicit additional instances of security appliances are added and deployed in the execution environment, which is the typical approach of some recent proposals in this field. The main concept is the disaggregation of cyber-security appliances into business logic (i.e., detection algorithms) and data plane (i.e., monitoring and inspection tasks), mediated by orchestration logic and proper security models. Instead of overloading the execution environment with complex and sophisticated threat detection capabilities, efficient processing capabilities are embedded in the execution environment that create events and knowledge; algorithms for detection of threats and vulnerabilities are moved upwards and process such data in a coordinated way for the whole execution environment (embedded service-centric cyber-security framework).

The vision of ASTRID is therefore a transition from infrastructure-centric to embedded service-centric cyber-security for virtualised applications. To achieve this objective, ASTRID envisions a multi-tier architecture, where multiple programmable hooks are present in the virtualisation container (in the OS kernel, in system libraries, and in the virtual function code), to monitor and inspect what happens inside. An intermediate layer decouples programmable hooks from orchestration (the Security Model), which gathers data and feeds algorithms for detection of threats, anomalies, vulnerabilities, attacks. This approach split the main detection logic from monitoring and inspection.



Programmable hooks include logging and event reporting capability developed by programmers into their software, as well as monitoring frameworks built in the kernel and system libraries that inspect network traffic and system calls.

The Security Model uses specific semantics to describe what security functions the component provides, e.g., logging, event reporting, filtering, deep packet inspection, system call interception. Through the Security Model, Orchestration knows what kinds of operations can be carried out on each component, collect data and measurements, and feed the detection logic that analyse and correlated information at graph level to detect threats.

Decoupling the detection logic from inspection and monitoring operation brings the following advantages:

• shift complex processing tasks to high-performance dedicated infrastructures (e.g., cloud installations with big data paradigms – Hadoop or Spark), while relying on pervasive and capillary lightweight operations for monitoring and inspection tasks (hence enabling re-usage of the same information for multiple purposes). This approach represents a disruptive evolution from deployment of security appliances in service graphs;
• facilitate the integration with a set of continuous risk-assessment and management mechanisms able to evaluate in real-time the existing risks and propose the appropriate mitigation actions, along with a set of data mining, analysis and threat intelligence mechanisms for getting advanced insights with regards to security aspects and support application of analytics-driven security mechanisms;
• the “in-environment” embedding of security and the ability to deploy multiple networks in parallel, give the ability to run in parallel a “honey-pot” network which is able in real time to detect the types of attacks on the system and to add new signature attacks to the orchestration system;
• reduced overhead on graph execution and attack surface, since most of the detection logic typically integrated in security instances is shifted outside the service graph.

Many protection tools already collect traffic information and measurements from network devices, by using protocols like OpenFlow, NetFlow, sFlow, IPFIX. In addition, the concept of distributed firewall has recently been proposed for virtualisation environments, to integrate packet inspection and filtering in hypervisors. A distributed firewall removes the need for traffic steering (all network packets go through the hypervisor, which is part of the firewall) and IP-based rule structures (through the notion of logical “containers” or “security groups”). This approach is currently used for enforcing filtering rules, but does not have the flexibility to provide deep inspection capability tailored to the specific needs for detecting threats and on-going attacks.

More than 80% of all new malware and intrusion attempts are exploiting weaknesses in applications, as opposed to weaknesses in networking components and services, hence rules have evolved from memoryless simple string matching to stateful automata (such as regular expressions). Also, the increase in the complexity of protocols makes modelling their normal behaviour increasingly difficult; as a result, more computing cycles per packet are required either checking against more elaborate rules, or trying to detect sophisticated anomalous behaviours. As a matter of fact, basic in-line DDoS detection capabilities of network devices such as load balancers, firewalls or intrusion prevention systems may have once provided acceptable detection when attacks were smaller but complex volumetric attacks, leveraging on the weak security posture and proliferation of IoT devices, can easily overwhelm these devices since they utilize memory-intensive stateful examination methods. Stateful operation in network switches is the new research frontier for more efficient processing and less overhead on the control plane; however, current implementations allow the switch to run only simple Finite State Machines (FSMs), where transitions are limited to a change of state. As a consequence, the detection process, which consists in comparing values against some thresholds, cannot be implemented inside the switch at the current stage of development.

ASTRID develops a flexible data plane well beyond the basic monitoring capability today envisioned by flow-level reporting, which includes stateless and/or stateful inspection criteria on flows and/or packets, aggregation and storing capabilities. ASTRID defines the data plane as the logical layer between the user-requested service and the external word, including the virtualization system, network processing elements (e.g., software switches), and hypervisor/operating systems internals (e.g., system calls). Thanks to this broad definition, ASTRID may exploit multiple and advanced programmability features of the data plane to perform monitoring, inspection and enforcing tasks, ranging from applications running in VMs or containers (e.g., LXC), OpenFlow rules, IOVisor and/or P4-based applications. Furthermore, as the data plane is not intended only as the transport layer for network traffic, the above monitoring/inspection/enforcing element can operate on a larger extent of information such as any data that is actually being generated in the virtualized environment, which can be captured and distilled to the control layer. ASTRID leverages the eBPF to design and develop a powerful data plane software.

ASTRID extends the eBPF technology (i) to support more powerful programs, which can operate according to the split data/control plane paradigm; (ii) to support more powerful actions on the data in transit, which enable to implement some proactive security actions (e.g., drop network traffic, modify packet information, craft ad-hoc packets for specific purposes) that go beyond simple monitoring.

Current security tools (a.k.a. appliances) are mostly monolithic and cannot support the efficient processing according to the split data/control plane paradigm. This affects the performance of whole service, as the traffic is forced to traverse security applications that may not be optimized for speed. Furthermore, current applications are mostly oriented to process network-related events, while the eBPF technology offers a wider range of options.