SPHINX User Interface Functional Requirements & Guidelines: 3rd Parties API & Common Cybersecurity Toolkit
The SPHINX System interacts with the user in order to develop cyber awareness concerning risks, vulnerabilities and incidents within the IT network and connected devices. Moreover, it allows the user to perform vulnerability assessment and certification of devices. In this regard, the user interface needs to be designed according to the user’s needs and expectations to ensure the utility of SPHINX.
Continue from Part IV.
3rd Parties Application Programming Interface (API)
The SPHINX Application Programming Interface for Third Parties, (S-API) enables third-party solution providers to access and interact with the SPHINX Platform and its components. S-API exposes advanced cyber security functionalities implemented by SPHINX components, such as device/application certification, threat registry notification and anomaly detection. Moreover, S-API allows third parties to access device certification functionalities.
S-API implements its own third-parties’ user management functions (e.g., create, modify and delete accounts) subject to acceptance by the S-API administration user. Third-parties might also be limited in access and usage, depending on the selected subscription plan.
S-API provides to third parties a web portal, as shown in the snapshot below, allowing them to fill in their profile, select their subscription plan, retrieve service authentication keys and see usage statistics.
Common Cyber Security Toolkit (CST)
Common Cyber Security Toolkit (CST) enables users to select the security services that best match their needs, to use within the SPHINX ecosystem. It allows users to plug cyber security services into their existing connectivity services and configure/adapt them according to their security needs
The next snapshot shows CST dashboard which presents information about total services installed and existing, including statistical information about their category.
Information about each SPHINX service can also be visualised, including name, version, deployment status, as depicted below.
The user can also visualise “Best Practices” information that includes the list of Attack Patterns existing in the SPHINX Knowledge Base (KB), containing information concerning their creation date, severity and actions, that is, a description for each attack pattern and the courses of action that are linked with the specific attack pattern, as shown in the following snapshot.
More information about the Functional Requirements and Guidelines of SPHINX can be found in Deliverable 2.10 that is publicly available here.