Citizens and businesses expect the state to handle their personal data with confidence and protect them through a high level of IT security and best practices. The BMI therefore wants to further enhance IT security in the implementation of CSOs and, in cooperation with the BSI, has launched the ‘OZG Security Challenge 2023’, which developed the ‘OZG security rapid test’.

# OZG Security Challenge – Best Practice Scanner

In this repository, you can find the Best Practice Scanner developed as part of the CSO security challenge. The Best Practice Scanner is a tool that makes it possible to verify IT security and the implementation of best practices from websites.

## Background

With the increasing digitalisation of public administration, the importance of the underlying information security increases. Citizens and businesses expect the state to handle their personal data with confidence and protect them through a high level of IT security. The [Federal Ministry of the Interior and Home Affairs (BMI)] (https://www.bmi.bund.de/DE/startseite/startseite-node.html) therefore wants to further increase IT security in the implementation of CSOs and has launched the ‘OZG Security Challenge 2023’ in cooperation with the [Bundesamt für Sicherheit in der Informationstechnik (BSI)](https://www.bsi.bund.de/DE/Home/home_node.html). In this context, the OZG security rapid test and the associated Best Practice Scanner component have been developed.

## Features

​

— Examination of the level of implementation of the following best practices/security measures (**Beta**):

Responsible Disclosure: Pre-publishing vulnerability reporting
Transport Layer Security (TLS) 1.3: Up-to-date encryption of communication between citizens and CSOs
— Deactivate TLS 1.0 & 1.1: Deactivate obsolete encryption
— Http Strict Transport Security (HSTS): Ensuring encrypted communication between citizens and CSOs
Domain Name System Security Extensions (DNSSEC): Secure link between internet address and server address
Resource Public Key Infrastructure (RPKI): Protection against unauthorised diversion of traffic
— Examination of the level of implementation of the following best practices/security measures (**alpha**, tests may be flawed):

— Certificate Authority Authorisation (CAA)
— Certificate Transparency Logs
Content Security Policy (CSP)
— X-Content Type Options
— HSTS Preload
— Http to HTTPS redirection
— IPv6 Support
— Match of the host name in the certificate
— No mixed content
— Certificate not revoked
Secure session cookie
— Use of strong cipher suites
— Use of secure key exchange procedures (planned, not yet implemented)
Use of a strong private key
Use of strong signature procedures
Subresource Integrity
— Availability of TLS 1.2
— Validation of the certificate
— Validation of the certificate chain
— X-Frame options
— X-XSS protection
— DNS-based Authentication of Named Entities (DANE)
DomainKeys Identified Mail (DKIM)
Domain-based Message Authentication, Reporting and Conformance (DMARC)
Broadcast Policy Framework (SPF)
— STARTTLS
— Availability of an English version of the website

### API in sarif format

The Best Practice Scanner offers an API that issues the results in sarif format. The sarif format is a standard format for the output of static analytical results. It is supported by many tools and can be used in various tools for further analysis and visualisation.

An OpenAPI specification of the API can be found in the openapi.yaml.

Example of a call: ‘Curl http://localhost:8080/\?target\=example.com’

You can find an example answer in the example-response.json.

### Monitoring

By default, the application provides metrics through a Prometheus '/metrics’ endpoint. The following key metrics are collected:

​

— Scan Duration: Tracks the duration of each scan in seconds.
— Success or Failure Counts: Monitors the total number of successful or failed scans.
— Unscannable checks: Tracks the number of unscannable items found during scans.

#### Prometheus Monitoring

Metrics are exposed on the '/metrics’ endpoint, which can be scraped by Prometheus for monitoring and alerting purposes.

#### InfluxDB Monitoring

To enable InfluxDB monitoring, set the environment variable 'METRICS=influx’. When this is enabled, the following environment following variables must be configured:

​

— INFLUX\_URL: The URL of your InfluxDB instance.
— INFLUX\_TOKENS: The authentication token for InfluxDB.
— INFLUX\_ORG: The organisation in InfluxDB.
— INFLUX\_BUCKET: The bucket where metrics will be stored.

Once configured, metrics will be sent to your InfluxDB instance instead of Prometheus.

## Collaboration

Are you interested in further development? Do not hesitate to get involved in this repository, e.g. with proposals for amendments (Merge Requests) or through application questions/proposals. You can read more here: CONTRIBUTING.md.

## Local fast start

​

1. Clone the repository: ‘GIT clone git@gitlab.opencode.de:bmi/ozg framework architecture/ozgsec/ozg-best-practice scanner.git’
2. Create your local configuration: ‘cp.env.example.env’
3. Start the necessary services: ‘docker-Compose up -d' (optional, standalone mode)
4. Start the scanner: ‘make’
5. Go to the scanner: ‘Curl http://localhost:8080/\?target\=example.com’

#### Disable checks (optional)

Individual scanner checks can be activated. The check can be made in the ‘config.yaml’ file.

​

— ‘CP config.example.yaml config.yaml’

#### Preconditions

​

— Docker must be installed. (optional, standalone mode)
— Docker-compose must be installed. (optional, standalone mode)
— Make-up must be installed.
— Golang must be installed.

## Standalone mode

The scanner can be used in a standalone mode. If the InfluxDB (Monitoring), RabbitMQ (Queue) and Redis (Cache) services are not configured or reachable, the scanner is in standalone mode. The Redis cache is then replaced by an in-memory cache.

## Licence

This project is licensed under the EUPL-1.2 Licence.