Differences

This shows you the differences between two versions of the page.

--- kb:bestpractices:codingconventions:cybersecurity [2026/05/07 09:31] – joerg.hampel
+++ kb:bestpractices:codingconventions:cybersecurity [2026/10/06 13:16] (current) – joerg.hampel
@@ Line 1: / Line 1: @@
-====== 08 Cybersecurity ======
+====== 09 Cybersecurity ======
-//As the EU Cyber Resilience Act (CRA) *has already entered into force in 2024, and the first legal requirements must be fulfilled starting in September 2026, we are now explicitly collecting tips, tricks, and best practices related to the topic here.//
+<WRAP left round tip 60%>
+**[[kb:bestpractices:wow:methodology#security_by_design|Security by Design]] is one of the guiding principles here at HSE.**
-Cybersecurity is part of software quality and maintainability. Secure systems should be deterministic, understandable, and explicit in their behavior.
+</WRAP>
 ===== General Principles =====
-  * Treat all external input as untrusted.
+  * Treat all external input as untrusted
-  * Prefer simple and explicit architectures.
+  * Prefer simple and explicit architectures
-  * Fail safely and log security-relevant failures.
+  * Fail safely and log security-relevant failures (log level WARNING)
-  * Minimize attack surface and unnecessary dependencies.
+  * Minimize the attack surface by exposing only the functionality that is actually required
-  * Apply the principle of least privilege.
+  * Keep third-party dependencies as few as possible and up to date
+  * Apply the principle of least privilege (both when developing and in the final product)
+  * Do not reinvent the wheel (use existing encryption algorithms etc)
+  * Review security implications during code reviews and design reviews, not only during testing
 ===== Secrets and Credentials =====
+  * Choose secure defaults
   * Never hardcode:
-    * passwords,
+    * passwords
-    * API keys,
+    * API keys
-    * certificates,
+    * certificates
-    * tokens,
+    * tokens
-    * database credentials.
+    * database credentials
   * Do not store secrets in:
-    * block diagram constants,
+    * block diagram constants
-    * typedef defaults,
+    * typedef defaults
-    * test VIs,
+    * test VIs
-    * screenshots,
+    * screenshots
-    * source-controlled config files.
+    * source-controlled config files
-  * Use external configuration or secure credential storage.
+  * Do not log sensitive information
-  * Never log sensitive information.
+  * Solutions
+    * "AES" VI Package by VIGods
+    * Better: Store secrets in a place the regular user cannot access
 ===== Networking =====
-  * Prefer encrypted communication:
+  * Prefer encrypted communication (TLS, HTTPS, SSH)
-    * TLS,
+  * Avoid plaintext credentials and insecure protocols
-    * HTTPS,
+  * Validate remote peers (eg using certificates)
-    * SSH,
+    * restrict access on a network level (IP ranges etc)
-    * SFTP,
+  * Use existing protocols
-    * OPC UA security.
-  * Avoid plaintext credentials and insecure protocols.
-  * Validate certificates and remote peers.
   * Explicitly document:
-    * timeout behavior,
+    * timeout behavior
-    * reconnect strategy,
+    * reconnect strategy
-    * retry handling.
+    * retry handling
-===== LabVIEW-Specific Guidelines =====
+===== Databases and SQL =====
+  * Use parameterized queries whenever possible
+  * Avoid dynamically concatenating SQL strings from user input
+  * Validate and sanitize externally provided data before database operations
+  * Restrict database permissions to the minimum required access
+  * Never store database credentials directly in source code
+  * Log database failures without exposing sensitive query data
+  * Explicitly handle connection loss and timeout behavior
+===== LabVIEW Misc =====
 ==== VI Server ====
-  * Disable VI Server if not required.
+  * Disable VI Server if not required
-  * Restrict network access and permissions.
+  * Restrict network access and permissions
-  * Never expose unrestricted VI Server access on production systems.
+  * Never expose unrestricted VI Server access on production systems
 ==== Dynamic VI Loading ====
-  * Only load trusted plugins or VIs.
+  * Only load trusted plugins or VIs
-  * Avoid loading VIs from user-writable directories.
+  * Avoid loading VIs from user-writable directories
-  * Use strict connector pane contracts and versioning.
+  * Use strict connector pane contracts and versioning
-==== System Exec =====
+==== System Exec ====
-  * Treat all command line input as untrusted.
+  * Treat all command line input as untrusted
-  * Avoid constructing shell commands from unchecked user input.
+  * Avoid constructing shell commands from unchecked user input
-  * Document all external tool dependencies.
+  * Document all external tool dependencies
 ==== File Handling ====
-  * Validate file paths and filenames.
+  * Validate file paths and filenames
-  * Avoid path traversal vulnerabilities.
+  * Avoid path traversal vulnerabilities
-  * Restrict writable and executable locations.
+  * Restrict writable and executable locations
 ===== DQMH and Modular Architectures =====
-  * Encapsulate queues, references, and communication resources.
+  * Encapsulate queues, references, and communication resources
-  * Avoid exposing internal module resources.
+  * Avoid exposing internal module resources
-  * Validate message payloads and typedef compatibility.
+  * Validate message payloads and typedef compatibility
-  * Keep security-related blocking operations outside the EHL.
+  * Keep security-related blocking operations outside the EHL
 ===== Logging and Error Handling =====
   * Log security-relevant events:
-    * failed authentication,
+    * failed authentication
-    * rejected certificates,
+    * rejected certificates
-    * malformed packets,
+    * malformed packets
-    * permission violations.
+    * permission violations
   * Logs should include:
-    * timestamps,
+    * timestamps
-    * module names,
+    * module names
-    * severity,
+    * severity
-    * connection information.
+    * connection information
-  * Avoid excessive logging in real-time loops.
+  * Avoid excessive logging in real-time loops
 ===== Deployment =====
-  * Remove development tooling from production systems.
+  * Remove development tooling from production systems
-  * Avoid unnecessary administrator privileges.
+  * Avoid unnecessary administrator privileges
-  * Keep dependencies updated.
+  * Keep dependencies updated
-  * Prefer signed installers and executables.
+  * Prefer signed installers and executables
+===== Resources =====
+  * [[kb:cs:cra|EU Cyber Resilience Act (CRA)]]
-===== Recommended =====
+----
-  * Encapsulated modules
+<block 100%:0:#FFF8FF;#800080;1px dotted #800080;Arial, Helvetica, sans-serif/10ptrounded>**[[https://createbettersoftware.com|The HSE Way of Working]]:** \\
-  * Explicit APIs
+A set of guidelines that recommend programming style, better practices, and methods for all our LabVIEW projects. We ask all our peers to follow these guidelines to help improve the readability of our shared source code and make software maintenance easier.</block>
-  * Typed message payloads
-  * Centralized configuration
-  * Deterministic error handling
-  * Sanitized logging
-  * Secure communication protocols
-===== Avoid =====
+|< 100% 50% >|
+|[[kb:bestpractices:codingconventions:database|<< 08 Databases]]  |  [[kb:bestpractices:codingconventions:sharedlibraries|11 Shared Libraries (DLLs) >>]]|
-  * Hardcoded credentials
-  * Global mutable state
-  * Disabled certificate validation
-  * Unvalidated external input
-  * Arbitrary dynamic VI loading
-  * Logging secrets
-  * Silent failure handling