# PALANTIR: An NFV-Based Security-as-a-Service Approach for Automating Threat Mitigation
## 6 Validation
### Qualitative Evaluation
#### 6.2.4 Security Orchestrator Prototype Implementation  
The SO provides an extra logic orchestrating layer that eases the management of the security mechanisms, via its deployment and configuration, as well as its monitoring and the overseeing of the whole workflow. To that end, it favours the principles of (i) compliance with standards' specifications and (ii) the maintainability and extensibility.  
To meet the former, the SO relies on its integration with OSM (an ETSI NFV-compliant MANO) to manage all security enactments. Therefore, specifications such as ETSI GS NFV-IFA 031 [61], regulating the interfaces (reference points) for the NFV MANO, are already considered by OSM and also indirectly complied with by the SO, specifically, in its southbound interface. The SO, in its central position to the security enforcement, partially aligns with the ETSI GS NFV-SEC 013 [21] specification. On one hand, it does so by acting as the NFV Security Manager (NSM) that cooperates with the MANO and adds extra logic to operate on virtualised services, such as Virtualised Security Functions (VSFs) and NFV-based Infrastructure Security Functions (ISFs). On the other hand, it also relates to the workflow, since it is designed to internally (i) introduce few of security decisions during the security planning stage (i.e., isolation of physical server); (ii) convey security policies and configuration changes to the NS instances; as well as (iii) introduce extra monitoring that can be used by other components in the PALANTIR architecture to plan further security actions. In addition to this, the SO also interacts with the VIM and xNFs using the expected reference points, laid out in the architecture.  
As per the latter, the SO seeks to follow best practices not only from the NFV environment, but also from the cloud, partially disaggregating its implementation into multiple interconnected services, yet preserving some common elements to maintain a compromise between resource usage and data consistency (a shared database for all related services) against decoupling. Summing up, it combines practices from the microservices and Service-Oriented Architecture (SOA) approaches. The chosen hybrid design results in the better separation of concerns, which eases the extension and maintenance efforts to developers and operators, as they can more quickly identify the location of specific logic, be it to extend with a new development or to trace the execution of the software. Likewise, the implementation choices promote widely used languages (Python 3.8.14), and the intra-service communication using RESTful APIs (via Python's Flask, version 2.0.2) and inter-service communication using both RESTful APIs (via Python's FastAPI, version 0.73.0) and message brokers (through Python's Kafka, version 2.0.2). The deployment techniques also consider both development (Python's venv--or virtual environments in version 20.0.17) and production-ready environments (Docker-based deployments in the latest version with docker-compose in version 1.29.2), with both tools being widely used and documented by the community. Finally, the design of the SO considers multi-tenancy, whose implementation will allow adaptation to the different deployment models and multiple deployment locations for the SO.