Introduction
This blog post is the first in a series of articles about the Cyrus project and what will become the Cyrus platform. This article focuses on the initial activities of the Cyrus project: a state of the art about standards and tools leading to the development of a generic cybersecurity test process.
State of the art
The Cyrus project began with a state of the art on 2 subjects. The first topic is the main existing penetration test standards and the second, the test tools.
The state of the art on standards has shown the following results:
- The Penetration Testing Execution Standard (PTES) is the one that has most influenced the generic testing process by its phases and practical approach going as far as listing tools and techniques to use;
- The FDAM (Field Device Assessment Methodology) methodology was also a great influence as it is one of the few dealing specifically with cyber-physical systems;
- The web-oriented Open Web Application Security Project (OWASP) Standard testing guide is interesting for its penetration test scenarios as well as its broader vision encompassing the whole system life cycle;
- The NIST SP 800 115 (National Institute of Standards and Technology) is really intended to be a technical guide for performing security tests and less for defining a process;
- The ISSAF framework (Information Systems Security Assessment Framework) is also quite interesting because of its “Framework” approach, but the lack of active maintenance makes it a somewhat outdated and unclear standard;
- The OSSTMM-3 (Open Source Security Testing Methodology Manual version 3) methodology, although very interesting, is incompatible with other standards because of its anti-risk approach and has not been taken much into account.
The state of the art on tools has shown several difficulties in identifying the tools needed for penetration tests:
- There is a very large number of existing tools;
- There is a great deal of diversity among these tools :
- Many categories of tools exist and these categories overlap to some extent;
- Highly visible business tools can be just as useful as scripts shared on github, but the latter will be harder to find;
- Some of these tools have been developed for real attacks and therefore remain ’under the radar’;
- The fact that some of these tools are no longer maintained, even when useful.
The tools identified were classified into 17 categories:
- Toolbox: this category includes developments that include several types of tools;
- Network mapping with scanner: this category includes all tools for network discovery;
- Sniffing: this category includes tools to spy on interfaces: Ethernet, WiFi, CAN...;
- MITM: this category includes tools to spy on interfaces by inserting themselves into communications;
- Database Scan: this category includes all the tools to scan database vulnerabilities;
- Vulnerability analysis: this category includes all the tools to automatically scan for vulnerabilities;
- SAST: this category includes all the tools to search for vulnerabilities based on the source code of an application;
- SCA: this category includes all the tools to search the libraries linked to a software in order to search for the vulnerabilities associated with it;
- DAST & WAST: this category is close to the vulnerability analysis category, it includes all the tools to search for vulnerabilities by interacting with an application in nominal operation;
- Firmware Analysis: this category includes all the tools to decompile and analyze firmware;
- Fuzzing tools: this category includes all the tools to run fuzzing tests;
- Password attacks: this category includes all the tools to recover passwords by different methods: brute force, rainbow, hash-based...;
- Wireless attacks: this category includes all the tools to attack WiFi networks;
- Exploitation tools: this category includes all the tools to exploit vulnerabilities;
- Compliance assessment: this category includes all the tools to scan a machine in order to check its compliance with certain security rules;
- Hardware: this category includes hardware for certain types of attacks: wireless, CAN, Bluetooth…;
- Forensics: this category includes all the tools to analyze and investigate incidents or events.
Generic Test process
The generic testing process (see Figure 1) based on this state of the art is divided into several parts:
- Inputs that include all information that may be useful in the testing process:
- The test objectives;
- The type of test (White, Grey, Black) and the associated information (documentation, source code, etc.);
- The SUT (System Under Test) itself;
- Risk analysis and security requirements, if they exist;
- The “Information gathering/test environment creation” phase defines the often manual operations that make it possible to better understand the SUT and prepare it for the following phases;
- The reconnaissance phase which aims to capture more precise technical information on the SUT: ports, protocols, communication channels (in the broad sense), sensors, actuators, vulnerabilities, etc;
- The “Vulnerability Assessment” phase is used to list as many vulnerabilities as possible, based on the information collected earlier;
- Then comes the Test phase itself. Deep Dive and Exploitation for penetration testing and Functional Security testing if security functional requirements have been defined;
- Finally, the reporting phase, which makes it possible to generate a report adapted to the client based on all the information collected or generated during the test process.
- Figure 1: Generic Cyrus test process
Towards Cyrus Test Platform
To carry out this generic test process, several technical choices and developments have been carried out:
- The definition of a data schema adapted to the information expected in the generic test process;
- The implementation of this data schema in a PostgreSQL database;
- A demonstration interface based on a web application made in Django/Python;
- Creation of flows based on the Node Red platform for the recognition and vulnerability assessment phases;
- Robot Framework-based test scripts and a number of penetration testing tools for the Deep Dive and Exploitation portion;
- the creation of test reports based on the JasperReport tool that allows a thorough customization of the reports and the exploitation of all the information stored in the database.
A first more advanced architecture, incorporating these various elements, has also been defined:
- Figure 2 : CYRUS MVP architecture
Conclusion
In this first part dedicated to the Cyrus project, we wanted to show the preliminary steps that provided the building blocks of the future Cyrus test platform. The generic test process identifies the automated steps and the necessary tools or types of tools. The integration of the initial tools into a proof-of-concept allowed us to confirm or redefine some of the choices and needs concerning the future platform.
