Concept

The growing adoption of virtualization technologies and micro-services architectures (e.g., for cloud computing and network function virtualization) is re-shaping the traditional security paradigms for running software appliances. As a matter of fact, such services are usually 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”. 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.

 

Concept

Unlike the legacy approach, where many appliances are usually delivered with a predefined, verified, and static stack of software on well-known hardware, emerging software development paradigms are increasingly making use of third-party services available in public marketplaces, which are then deployed in public virtualization infrastructures. Virtualization is responsible to provide isolation between computing, networking, and storage resources of different tenants, but cloud users substantially rely on the third-party operation. Similar to well-established practice in physical installations, security appliances like Intrusion Prevention/Detection Systems, Firewalls, and Antivirus can be applied within each sandbox, by integrating them in service graph design, in order to inspect software, network traffic, user and application behaviour. This approach usually brings a large overhead on service graph execution, the need for more resources (CPU, memory), and a tight integration between service designers and security staff (which is not always simple to achieve in current development processes). Additionally, these components are built in the classic fashion, protecting the system only against outside attacks, while the most of the cloud attacks are now done through the compromising of the network functions themselves using tenant networks running in parallel with the compromised system.

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. This means that monitoring operations, types and frequency of event reporting, level of logging is selectively and locally adjusted to retrieve the exact amount of knowledge, without overwhelming the whole system with unnecessary information. 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.

project-concept

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 vision of ASTRID is a transition embedded service-centric security frameworks, which decouples monitoring/inspection capability in the virtual functions and their containers from algorithms for detection of threats, anomalies, vulnerabilities, attacks. A Security Model represents the abstraction between the two layers. It uses specific semantics to describe what security functions are implemented by programmable security hooks that are present in the virtualisation container (in the OS kernel, in system libraries, and in the virtual function code), 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.

project-concept-02

The ASTRID concept brings far more dynamicity, scalability, robustness, and self-adaptability than any other approach proposed so far:

  • Programming of the data plane requires far less time than deploying, removing, or migrating security appliances within the service graph
  • 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.
  • 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.
  • Pulling security appliances out of service graph design makes them independent from the chaining and orchestration models, hence common solution may be developed for different domains (e.g., cloud and NFV).
  • The targeted set of actions provide the means to dynamically adapt the system based on the type of attack using the elasticity properties of the cloud infrastructure.
  • The capability to deploy in parallel transparent honeypots which enable the monitoring of attacks in a safe environment provides the means to dynamically adapt and improve the attack signatures which not requiring additional networks.
  • The centralization of log information and the possibility of duplication and inspection of the data traffic makes possible for the orchestration to execute complex forensics operations which are the only possible solution to determine vulnerabilities in a complex multi-tier environment such as the cloud.
Objectives
ASTRID seeks novel cyber-security frameworks for

  1. improving situational awareness of virtualised services, including both each single component (i.e., each specific micro-service or virtual function) as well as the service as a whole (i.e., the entire service graph), and
  2. facilitating (possibly automating) the detection and reaction to sophisticated cyber-attacks. Specific challenge will be the ability to detect vulnerabilities, threats and attacks not only from the canonical input/output channel of the services, but also internally to the service.

    3. Specific objectives to implement the above Concept include:

  3. Objective I – Decouple the service business logic from the (necessary) security management. Security management of service graphs is a very challenging task, since the context continuously changes (e.g., scaling and life-cycle management). Integrating security appliances in service graph design is not the best solution, since it usually requires manual operations; instead, security should be described at a very “abstract” level, by defining policies and constraints that describe “what” is required rather than “how” to implement it. ASTRID shifts security appliances away from service graph design. In ASTRID, security properties of each graph component as well as the whole service are defined by proper models and policies, which are then used at deployment time to properly configure the execution environment. The developer specifies security requirements and policies for the protection of the graph, without the need for deep technical understanding of the underlying technology.
  4. Objective II – To automate security management and response to threats, security incidents, attacks. Today, responses to attacks often come late because of the need for human intervention. Following the wave for more automation in the deployment phase, a new framework is required to deploy and configure security agents according to the defined models and policies, and to undertake mitigation actions according to specific security strategies. 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.
  5. Objective III – Reduce the run-time overhead of security processing. Most security appliances require monitoring and inspection operations (on network packets, software behaviour, system calls) that consume CPU cycles and may deteriorate the overall service performance, especially in virtualised environment where hardware acceleration is rarely available; in addition, security appliances are not totally immune to attacks, so they increase the attack surface. In this case, the objective is two-fold: a) increase the processing efficiency of (at least) the most frequently executed portion of monitoring and detection tasks, and b) to protect security appliances from attacks. ASTRID will split security appliances in two layers: the data plane and the detection logic. Instead of overloading the execution environment with complex and sophisticated threat detection capabilities, efficient processing capabilities are provided 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. The data plane is expected to carry out both packet inspection as well as software vulnerability assessment. It also provides logical isolation between the external environment and the detection logic; the latter is kept in a secure and controlled environment with proper computing power, hence reducing the attack surface. Finally, with respect to objective (b), this efficient data plane can be effectively used to filter malicious traffic directed to the security appliances themselves (e.g., in case of a DDoS), hence protecting them from attacks targeting security appliances.
  6. Objective IV – To support legal and forensics investigation in virtualised environments. The growing number of virtual applications and services is also expected to be subject to illegal usage and cyber-crimes. Specific technical mechanisms are therefore required to facilitate forensics investigation for identification of crimes and criminals. – Means to achieve. ASTRID will support lawful investigation by providing the following technical features:

    1) extraction of unencrypted traffic streams from the service graph;

    2) real-time and offline access to events, measurements and other information collected throughout the service graph.
Work Packages
Work Package Title Leader Description of Work
WP1 Reference Architecture Orazio Toscano (ETI)
orazio.toscano[at]ericsson.com		 This WP embeds the activities related to the overall definition of the ASTRID framework in terms of relevant applicative scenarios, functional requirements, architectural components and internal interfaces.
WP2 Secure Orchestration Platform Fulvio Valenza (Polito)
fulvio.valenza[at]polito.it		 This WP will define the models required to build the ASTRID Secure Orchestration Platform, and it will design and implement all the infrastructure-level components that are required to achieve the project objectives.
WP3 Detection and Management of Vulnerabilities, Threats and Anomalies Stefan Covaci (TUB)
stefan.covaci[at]tu-berlin.de		 This WP includes the design of algorithms and tools that enable ASTRID stakeholders to assess the security properties of their services, to detect, to manage, and to react to vulnerabilities, threats, attacks and anomalies. This will occur based either on inputs coming from ASTRID stakeholders and/or events generated by the virtualized infrastructure (at large). In addition, this WP will include also the capability to statically assess the robustness of the application software.
WP4 Integration, Demonstration and Validation Alessandro Carrega (CNIT)
alessandro.carrega[at]cnit.it		 This WP includes the activities aimed to define and build ASTRID demonstrators for the experimental validation of the technologies and tools developed during the Project.
WP5 Communication, Dissemination, Exploitation Athanasios Giannetsos (DTU)
atgi[at]dtu.dk		 This WP pursues the wider visibility for ASTRID vision, objectives, activities and achievements. It also investigates how the project results could be exploited by partners. Key issues will be advertising and disseminating the projects activities without harming the partners’ interests. All the activities in this WP will be planned and documented in joint Communication, Dissemination and Exploitation deliverables, released at the beginning, intermediate review, and end of the project with an iterative process.
WP6 Project Management Orazio Toscano (ETI)
orazio.toscano[at]ericsson.com		 This WP carries out management, coordination and administration of the whole Project, and provides internal collaboration tools to all partners.