Cyrus - Automated CYbeR secUrity teSting for Cyber Physical System

Architecture

The Cyrus platform is the Ethical Hacker’s companion which allows to gather and store all the information about the system under test (SUT) during the Cyrus test process.

Components of the Cyrus platform

An important part of the Cyrus test process is performed with the help of external, community-driven tools:

NodeRED, a flow-based development platform running flows (scripts) that scan the SUT and send their output to the Cyrus platform. Creating flows is rather easy thanks to available flows and they can easily be shared. Site https://nodered.org/

Greenbone/OpenVAS, a vulnerability scanner for physical systems that testers use to scan the SUT and import the vulnerabilities proposed by Greenbone/OpenVAS into Cyrus afterwards. Site https://www.greenbone.net/

Kiwi TCMS (Test Control and Monitoring System), a test case management system commonly used for test management of all types (functional, performance, etc…) where the testers create and run pentests against the SUT to confirm or infirm the presence of the vulnerabilities. They later import the test results into Cyrus. Site https://kiwitcms.org/

Robot Framework, a test automation framework that runs tests using a specific file format describing test cases and can be launched from Kiwi TCMS. Site https://robotframework.org/

Jasper Report, a report generator tool, allows you to retrieve all the information gathered during the process and customize the reports without requiring any programming. Site https://www.jaspersoft.com/

To secure the Cyrus API backend another external tool is used:

Keycloack (open-source authentication server). Site https://www.keycloak.org/

The Cyrus platform contains the following components that were developed for the platform:

• Cyrus APIs (Application Programming Interface), a Python/Django backend server exposing the Cyrus data model as REST-based endpoints, representing the test process, and connected to a PostgreSQL database;
• Cyrus UI (User Interface) developed using Drupal (an open-source content management system, https://www.drupal.org/) offering a user-friendly interface to view and record the important data through Cyrus APIs;
• Cyrus OpenVAS broker, a Python/Django backend presenting APIs to interface with Greenbone/OpenVAS for Cyrus APIs component;
• Cyrus Kiwi broker, a Python/Django backend presenting APIs to interface with Kiwi TCMS for Cyrus APIs component.

A set of NodeRED flows and Robot Framework test case files are provided by the Cyrus platform, ready for use.

Deployment of the Cyrus platform

The platform is deployed in the following way:

• a virtual machine specific to the test project, running the Cyrus APsI backend server, the Cyrus UI server, the database server, the Keycloack server, the Kiwi TCMS server and Jasper Report server;
• a machine running a Kali Linux distribution (https://www.kali.org/) that allows a physical connection to the SUT, necessary for the NodeRED, OpenVAS and Robot Framework tools, and also allows to go to the field with that machine and connect to the project’s server to upload data.

The Cyrus platform is bundled as Docker images and deployed with Docker Compose so that all the components use the same container running the PostgreSQL server:

• Cyrus API;
• Drupal;
• Jasper Report;
• Keycloack;
• Kiwi TCMS.

The diagram below presents the whole set of softwares and how they connect to each other in the Cyrus platform.

Cyrus platform: set of softwares and their connections

Platform usage

This chapter describes the different interfaces that the platform offers to the user (tester) and how they are used to perform activities of the generic test process defined by the Cyrus project. As mentioned in the first article, the Cyrus generic test process is divided into several parts:

Inputs / Project Kick-Off
In this initial phase, the owner of the system to be tested comes with all the inputs necessary to start the cyrus test process. Some are mandatory:

• the SUT (System Under Test) which is the system or product the owner wants to be tested;
• its objectives and scope regarding the tests : confirming countermeasures efficiency, evaluating the global level of security, …

and some are optional:

• the documentation and source code is useful for white or grey box testing;
• a risk analysis if it exists, can help guide the test on critical parts.
  For the Cyrus platform, this phase implies multiple actions :
• If the owner of the SUT is a new one, it means that a new instance of the Cyrus VM will be created;
• When the owner’s instance is available, the SUT, its version and inputs such as the risk analysis will be entered in the Cyrus UI.

The definition of the SUT and the Risk Analysis is depicted in Figure 1.

The other information such as the documentation or source code are not directly entered in the platform but are used in the next phase : information gathering.

Information gathering
The information gathering groups multiple actions for the user such as :

• Examine the SUT;
• Read the documentation;
• Check the source code.

All these actions will provide information on the elements that make the SUT and how they communicate. This information also needs to be entered into the Cyrus UI.
Parts of the SUT are called assets in the Cyrus UI and they can be of 2 types:

• Components are functional blocs : a camera, a processing unit, a PLC (Programmable Logic Controller), etc…
• Interfaces are communications between these blocs : an https rest api, bluetooth communication, etc…

For each asset, different types of information can be gathered and stored in the Cyrus platform. To simplify this part, they are stored in a table of “parameters” that can be any deemed useful information : IP address, Provider of the component, Frequency used, TLS version, etc…
The assets and their parameters in the Cyrus platform are depicted in Figure 2.

Reconnaissance
The reconnaissance phase is the first part that needs a connection between the Cyrus Test Environment and the SUT. Reconnaissance can be done manually but the main tools are automated using flows. These flows can be launched from the Cyrus UI, they can use information already gathered previously and they will automatically push the result back to the Cyrus platform. The flows are depicted in Figure 3.

The flow results pushed in Cyrus appear in the flow executions and the associated logs can be visualized directly from the Cyrus platform (see Figure 4).

Vulnerability assessment
The Vulnerability assessment phase is about using all the information collected before to get possible vulnerabilities on the SUT. There are 2 ways to interface with the Cyrus platform for this :
Either manually, searching through known vulnerabilities databases based on the information gathered and entering them in the Cyrus platform. This method is depicted in Figure 5.

Or by using Greenbone/OpenVas to automatically try to find vulnerabilities on the system. This method is not exhaustive but can quickly provide useful vulnerabilities.
This method is depicted in Figure 6.

Tests
The test phase is managed between 2 tools interconnected inside the Cyrus platform. For each vulnerability that we want to test in the system, we will create a test case in the Cyrus UI. The creation of this test case will also create a test case in the Kiwi tool.
The Kiwi tool will be used here to manage our penetration tests through test runs and test plans. It will also be used to store the test results and the comments of the tester. See Figure 7.

Reporting and Recommendations
This part will conclude a cycle of the Cyrus test process by doing the last two necessary actions : writing recommendations regarding events that occurred during the process and generating the test report.
The user will have to write recommendations for each confirmed vulnerability and each test which is in error in the Cyrus UI. This is a very important step as it will define the actions that need to be performed to either improve the security of the SUT or improve the tests for a new cycle of the process.

After the recommendations, the user can now generate the test report containing all information on what happened during the test process. For this, the test platform will first import all information entered in the Kiwi platform and then open JasperReport server. JasperReport will generate the report based on a predefined template that can be totally customized and all the information that the Cyrus test platform stores about the test process : The assets, the vulnerabilities, their link with the tests, etc…

Conclusion

In this second part dedicated to the Cyrus project, we wanted to show the architecture of the Cyrus test platform and how to use it. This platform allows the generic test process presented in the first article to be executed. In the 3rd and last article of this series, we will present its use with a concrete use case that allowed us to validate the choices of architecture described here.