Cyber Resilience Act (CRA) & Cybersecurity at INOSOFT

Security as an Integral Part of Our Products

[Translate to English:] Europaflagge aus Binärcode mit geschlossenem Vorhängeschloss als Symbol für den Cyber Resilience Act

Cybersecurity is an essential part of the development and operation of our solutions. The Cyber Resilience Act (CRA) of the European Union requires manufacturers of products with digital elements to meet security requirements throughout the entire product life cycle.

INOSOFT supports its customers in developing and operating secure, future-proof solutions.

Further information on the Cyber Resilience Act is available on the website of the European Commission.

REPORT A VULNERABILITY (PSIRT)

Our Cybersecurity Services

As a manufacturer of products with digital elements, INOSOFT is committed to developing and supplying VisiWin 7, our current HMI and SCADA software, in accordance with the requirements of the EU Cyber Resilience Act.

Cybersecurity is taken into account throughout our entire development process: from planning and requirements analysis, through design, development and testing, to deployment and operation of the software.

Secure Software Development Lifecycle
Secure Software Development Lifecycle (click to enlarge)

As part of a security analysis and threat modeling exercise, we have defined the following general security requirements for our products:

  • User Authentication and Authorization
    Whenever functions and data are accessed via public interfaces, it must be ensured that the accessing user or system is known and authorized to do so.
  • Encrypted Data Transmission
    Data transmitted over a public network must be encrypted.
  • Logging
    Both authorized and unauthorized interventions in the software must be logged.
  • Tamper Protection
    System components and their configuration and log data must be protected against external manipulation.
     
  • Protection Against Overload
    To ensure availability, system components must be protected against overload, e.g. from denial-of-service events.
  • Least Privilege
    System components must be configured to provide only those functions, ports and protocols that are strictly necessary for their specific purpose.
  • Secure by Default
    All security measures are enabled by default.

Our secure product development process ensures that these security requirements are met and that the result is continuously improved.
 

Reporting Vulnerabilities (PSIRT)

INOSOFT welcomes the responsible reporting of vulnerabilities in our products, services and publicly accessible systems. Our Product Security Incident Response Team (PSIRT) assesses incoming reports confidentially and coordinates their further handling.

Security Contact

REPORT BY E-MAIL

psirt(at)inosoft.com

Availability/review of incoming reports:
Monday to Thursday: 9:00 a.m. – 4:00 p.m. (CET/CEST)
Friday: 9:00 a.m. – 1:00 p.m. (CET/CEST)
Excluding public holidays

Information We Need:

Name (optional)
Company (optional)
E-mail address
Affected product/service
Version
Severity (optional)
Description of the vulnerability
Steps to reproduce
Attachments/screenshots/log files
Consent to be contacted

Vulnerability Disclosure Policy

Our Commitments to Reporting Parties

Where security research is conducted within the scope of this policy, we consider these activities authorized and a valuable contribution to improving the security of our products and services.

Provided that reporting parties observe the rules set out below (Requirements for a Valid Vulnerability Report, Code of Conduct for Security Researchers, Prohibited Activities):
reports will be treated confidentially,

  • personal data will be processed in accordance with the GDPR,
  • no information will be passed on without the consent of the reporting party,
  • we aim to provide an initial response within five working days,
  • no legal action will be taken in respect of good-faith security research.

All parties involved are required to comply with applicable laws and regulatory requirements.

 

Requirements for a Valid Vulnerability Report

A report should contain at least the following information:

  • Description of the vulnerability
  • Affected product
  • Affected version
  • Potential impact
  • Steps to reproduce
  • Proof of concept (if available)
  • Contact details for follow-up questions

The following also applies:

  • The vulnerability must relate to INOSOFT products.
  • The information must not already be publicly known.
  • Automated scan results without verifiable documentation will not be considered.

 

Code of Conduct for Security Researchers

We ask all reporting parties to observe the following rules:

  • Demonstrate vulnerabilities only to the extent necessary.
  • Stop all further testing immediately after a successful proof of concept.
  • Do not modify, delete or extract any data.
  • Do not use malware.
  • Do not publish or distribute exploit tools.
  • Do not impair the availability of services.

 

Prohibited Activities

  • Social engineering
  • Phishing
  • Denial-of-service (DoS) or distributed denial-of-service (DDoS) attacks
  • Attacks on third-party customer systems
  • Attacks on network and infrastructure components outside the approved test scope

If these rules are breached inadvertently, please contact us immediately.

 

How Security Reports Are Handled

1. Receipt of the report
Once a report has been received, we review the information provided and confirm receipt. Following an initial investigation, we report notifiable incidents to the CSIRT designated as coordinator and to ENISA via the EU Single Reporting Platform.

2. Initial assessment
An initial response is provided within five working days.

3. Detailed analysis
Within ten working days, we provide information on:

  • the status of the report,
  • validation of the vulnerability,
  • planned measures,
  • any additional information required.

4. Remediation and communication
Once the analysis has been completed, appropriate measures are taken:

  • Fixing the issue
  • Risk mitigation
  • Customer notification
  • Publication of a security advisory

5. Closure
A case is considered closed once:

  • no vulnerability has been identified,
  • the vulnerability has been remediated,
  • risk mitigation has been implemented,
  • a security advisory has been published.

The reporting party will be informed accordingly, provided that consent to be contacted has been given.