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.
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.
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.
The ASTRID concept brings far more dynamicity, scalability, robustness, and self-adaptability than any other approach proposed so far:
|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.|