ℹ️
AddreSsing ThReats for virtualIseD services
💡
Leveraging software orchestration for reshaping the service graph
📔
Security orchestration is the core element of the ASTRID conceptual architecture, including both service management and situational awareness.
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.
💡
Decoupling detection from monitoring and inspection
📔
ASTRID pursues a transition from infrastructure-centric to embedded service-centric cybersecurity frameworks.
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 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.
💡
In-kernel processing for fast inspection & effective enforcement
📔
In-kernel processing for fast inspection and effective enforcement
ASTRID designs and develops a software data plane leveraging eBPF and related frameworks. The target is 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 world, 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.
📌
Main responsibilities
- LEADER of WP4 “Integration, Demonstration and Validation”.
- Management of WP2 “Secure Orchestration Platform”.
- LEADER of T4.4 “ASTRID Software Framework”.
- LEADER of T2.2 “Programmable Components and Context Models”.
- Management of T2.1 “Programmable Components and Context Models”.
- Management of T1.5 “Reference Framework and System Architecture for Situational Awareness”.
- LEADER of D2.1 “Programmable Components and Context Models”.
- LEADER of D4.2 “Final release of the ASTRID framework”.
- Management of D1.3 “Final ASTRID architecture”.
- Management of D2.5 “Public release of the secure orchestration components”.
