Files
Orchestrator/bahn/project-audit/data/confluence-export/pages/299409491-Pruefung der Security Requirements.md
ankn a5f8fb49ab Migrate all repos into monorepo context folders
Bahn: aisupport, Analyse-O2C-C2S, awesome-bahn-mcp-servers, beam-mcp,
      Confluence_Bot, db-planet-mcp-server, O2C-Harness, project-audit,
      Projekt-KIQ-HP, teamlandkarte-mcp
Dhive: Jury-Voting
Privat: CV, NoteGraph (NOTE: NoteGraph needs complete redo after consolidation)
Shared: AI-Orchestrator, OrgMyLife, power_skills_and_more
Shared/references: symphony (read-only)

Bahn repos remain available as independent remotes - this monorepo
pulls them in via subtree, the originals are untouched.
2026-06-30 20:39:52 +02:00

50 KiB

Prüfung der Security Requirements

Confluence Page ID: 299409491 Version: 26 Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/Architekturrunde PathOS/Prüfung der Security Requirements Labels:


thttps://ass.gitpages.tech.rz.db.de/vorgaben/design-guideline-application-security/02_Requirements_by/08_all.html#_all_requirements | | Regel | Rückmeldung aus O2CCIB-4142 | Anmerkung | Zuständigkeit | Maßnahme(n) | | Defense in Depth A defence in depth uses multi-layered protections, similar to redundant protections. The intention is to create a reliable system using the multiple layers, rather than making any one layer perfectly reliable. This increases the resiliency of the application, because if one protection layer breaks the others are still working. | PR-DID: bisher nicht erfüllt da keine Authentifizierung zwischen den Services vorliegt (Kommunikation innerhalb Bestellsystem zu SV und AV ohne Authentifizierung) | Authentifizierung zwischen Services bereits als Thema in Arch aufgenommen | Architektur | zu klären mit Sec-Team, ob Envoy/Policy Agent zulässig ist das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CBS-263 | | Only Use the Least Privilege Possible "Every program and every privileged user of the system should operate using the least amount of privilege necessary to complete the job." - Jerome Saltzer, Communications of the ACM.

In cases where the application must run with elevated privileges, raise privileges as late as possible, and drop them as soon as possible. E.g. if a connection only reads data it must not have write privileges. | PR-LPRV: Ein ServiceAccount für Bestellsystem-Stage. Es sollte aus z.B. SV kein Zugriff auf AV-Secrets möglich sein. | geprüft | Architektur/Steam | Enabler für Steam das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-932 Finding zu Secrets: Alle Secrets (und ConfigMaps) werden der  einzelnen Anwendungskomponente als volumeMount bereitgestellt. Darüber hinaus ist den Anwendundungskomponenten kein Zugriff auf K8s-Secrets erlaubt, weder auf die eigenen noch auf die der anderen Komponenten. | | Minimize the Attack Surface Keeping the attack surface as small as possible. I.e. only run programs and services that are necessary for the business functions of the application. Remove all software features that are not necessary. For example shut down services you do not need. Only install features and options that are required. Uninstall all features and options that are not required. | PR-MATS: APIs und Funktionalitäten (z.B. Prometheus Actuator Endpoint) | | Alle Teams | Enabler: Endpoints durchgehen und prüfen; nicht benötigte Endpoints sperren das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-5147 das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-3192 das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C404-3086

Enabler: Open Telemetry Agent ausbauen (Container, Pipelines) das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-863

Enabler (404): Wiremock aus dem Deployment-Artefakt (Jar) ausbauen das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C404-3089 | | Implement Safe Updating If the application will utilize automatic updates, then use cryptographic signatures for your code and ensure your download clients verify those signatures. Use encrypted channels to transfer the code from the host server. | PR-ISUP: Camunda-Prozess-Update evtl. zutreffend? | | CIB | zunächst klären mit Sec-Team, ob für Camunda relevant, falls ja: Enabler (CIB): Prüfen, ob während der Laufzeit Prozess-Updates durchgeführt werden können/Signieren der Camunda-Prozess-Dateien | | Do Not Store Passwords in Strings When using programming languages where strings are immutable (e.g. Java), do not store passwords in string objects. Use byte arrays instead. String that are immutable can not be deleted or overwritten in memory, and may therefore be accessible to an attacker. | PR-NPST: Datenbank-Passwort wird in Java-String gespeichert | | Alle Teams | Da in benutzten Frameworks (Spring, Flyway) so umgesetzt, Risiko akzeptieren (klären mit Sec-Team) | | Protect the Application Against Race Conditions Utilize locking to prevent multiple simultaneous modifying requests or use a synchronization mechanism to prevent race conditions. If a resource is being modified, no other modification should take place to protect the resource from becoming inconsistent. All requests to modify a resource which is currently being modified must be rejected. After the modification is finished all subsequent request to alter the resource must take place on the latest version of the resource. | PR-PARC: Verdacht auf Race-Conditions bei Aktionen aus verschiedenen Richtungen (u.a. IFP) | | Alle Teams | Enabler: Weitere Reduktion der Wartezeiten in den KITs / Reduktion auch in Systemtests (IFP-Mock)

Separater Termin für Betrachtung und Ermittlung möglicher Race Conditions | | Security by Default Always use default configurations which are secure. After installation the software must be in a secure state by default. | PR-SEDE: Authentifizierter API-Zugriff als Default aktiv? | Außenkanten benötigen Auth; Authentifizierung zwischen Services bereits als Thema in Arch aufgenommen | Architektur | das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CBS-263 | | Deny Access by Default By default, access to the application, its functions and its data must be denied. There must be a protection scheme that identifies under which conditions access is permitted and to which extent. There must be no other way for a normal user to access the data. Deny all access if the application cannot access its security configuration information.

If an access control fails it must deny access. Access must never be allowed as a result of failure. Otherwise an attacker will construct a situation where access control will fail and would consequently be allowed access. | AZ-DACD: Haben wir noch nicht (vergleiche PR-SEDE) | siehe PR-SEDE | Architektur | das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CBS-263 | | Create an Access Control Policy Create an Access Control Policy to document an application’s business rules, data types and access authorization criteria and/or processes so that access can be properly provisioned and controlled. This includes identifying access requirements for both the data and system resources. | AZ-CACP: Haben wir nicht | Authentifizierung zwischen Services bereits als Thema in Arch aufgenommen | Architektur | das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CBS-263 | | Accounts Must Have the Least Privilege Possible Service accounts, technical accounts or accounts supporting connections to or from external systems must have the least privilege possible. | AZ-ALPP: vergleiche PR-DID | Authentifizierung zwischen Services bereits als Thema in Arch aufgenommen | Architektur | das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CBS-263 | | Authenticate Users on the Deepest Layer The authentication should not only take place on a very early layer, but on the most deepest layer (in most cases: your application server), so that bypassing a layer will not break your authentication scheme. In particular, do not rely on client authentication. | AZ-AUDL: Erfüllen wir nicht (Authentifizierung nur an Außenkante) | Authentifizierung zwischen Services bereits als Thema in Arch aufgenommen | Architektur | das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CBS-263 | | Authorization is Always Checked in the Application The authorization of access to the application’s data must take place within the application. In this case, the data for authorization may also be stored in databases and directory services that are part of the application. Authorization must be checked directly upon issue of the authorization data.

The assignment of all roles of all applications to groups within central directory services would require a very large number of groups. Administration within the application significantly reduces the number of groups in the central directory services.

It should not be possible to access protected information by knowing or guessing the references used. In the case of an account information query, for example, it should not be possible for unauthorized parties to access information such as that contained in an URL of type https://bank.example.com/account.cgi?account_number=123456. | AZ-AACA: Saubere Mandantentrennung aktuell nicht erfüllt - derzeit verlassen sich SV und AV komplett auf CI und BP | Zu diskutieren; mehr Infos benötigt | CIB/Zero | Enabler für CIB und Zero: Mandantentrennung durch geeignete Prüfungen sicherstellen das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-4695 das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-2612

Enabler für Zero: Bessere Validierung des Zertifikats (Common Name, Aussteller, Signatur)

das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-2613 | | Segregate Privileged Logic From Other Application All privileged operations must run as a separate process so that it will not be influenced by the application code that is under control of an attacker. | AZ-SPLA: Ist das Camunda-Cockpit Privileged Logic? | mehr Infos benötigt | CIB | Camunda als Standalone & Cockpit erreichbar nur durch PAN --> bei IFP anfragen, wie sie damit umgehen | | It Must be Possible to Disable or Delete Accounts The application must support disabling of accounts and terminating sessions when authorization ceases (e.g. Changes to role, employment status, business process, etc.). | AZ-ACDD: Kundennummern-Verwaltung existiert, aber kann bei BP eine Deaktivierung erfolgen? Passiert der Import schnell genug über KB? | | Zero | Enabler Team Zero: Verbesserte Partnerverwaltung im CI (Konzept) das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-2614 Enabler Team Zero: Blacklist für Sperrung von Accounts in der Kundendatenbereitstellung das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-2615 --> Klärung des Vorgehens mit Holger (wann sperren wir einen Account?) | | Use JSON Web Tokens correctly JWTs are JSON data structures containing a set of claims that can be used for access control decisions. A cryptographic signature or message authentication code (MAC) can be used to protect the integrity of the JWT.

Ensure JWTs are integrity protected by either a signature or a MAC. See RFC 7515 for additional information for Differences between Digital Signatures and MACs and RFC 7519 for JWT.

A relying party must verify the integrity of the JWT based on its own configuration or hard-coded logic. It must not rely on the information of the JWT header to select the verification algorithm. | AZ-UJWT: Validieren wir Token korrekt (bzgl. aller geforderter Parameter) | Prüfen | Team 404 | Enabler Team 404: Prüfen ob alle geforderten Parameter validiert werden das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C404-2701 | | Require Authentication by Default Require authentication for all forms, pages and resources, except those specifically intended to be public. | AC-REAU: bisher keine vollumfängliche Authentifizierung | Betrifft maßgeblich Service-to-Service-Auth | Architektur |

| | Enforce Password Rules The application may only use directory services where the passwords comply with a feasible password guideline.

The password guidelines must be enforced each time passwords are changed within the application. | AC-EPRL: Warum haben wir überhaupt Passwörter in der Camunda-Datenbank | | CIB | Enabler CIB: Zugänge über Passwort deaktivieren (-> Verwendung DB Azure AD über Keycloak) das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-5134 | | Use a Central Repository for Authentication During the login process, the user should be authenticated against a leading directory service (e.g. AD, LDAP) or one derived from this insofar as an appropriate directory service exists.

The user authentication for REST API Interfaces should be centralized in a Identity Provider (IdP), which issues access tokens.

A central, application independent directory service is recommended, ideally controlled by a central identity and access management system. The primary roles for authorizing users should also originate from this central source.

Note: This requirement creates the prerequisite for centrally locking or deleting user accounts and comparing them with existing user accounts in the HR system.

If the primary roles originate from a central directory service, it is also possible to align the roles centrally and possibly automatically when the area of responsibility of an employee is changed. For example: relocation, parental leave, change in role or activities. | AC-UCRA: Warum haben wir in der Camunda-Datenbank Passwörter (vergleiche AC-EPRL) | In Dev-Team zu behandeln | CIB | siehe AC-EPRL | | Remove All Unnecessary Accounts Remove all unnecessary accounts that are not needed. Such accounts are an easy way for attackers to get access to a system. | AC-RADA: Wofür brauchen wir den User camunda (z.B. in ieu) | In Dev-Team zu behandeln | CIB | siehe AC-EPRL | | Inactivate Unused User accounts It is forgotten time and again to remove user accounts from applications that are no longer valid.

A technical measure is possible to reduce the effects of this organizational flaw: A user account should be locked automatically if it has not been used for a specific time period.

The length of this time period depends on the importance and security level of the data and the anticipated frequency of logins to the application. This time period should be significantly shorter in the case of data with a very high security level than in the case of data with a low security level. It usually lies in the range of a few days to several weeks. | AC-IUUA: Deaktivieren wir User in Keycloak oder Camunda, die länger inaktiv sind? | | Architektur/CIB | - Klärung mit NuR bzgl. Verhalten bei externen Accounts

  • bzgl. Camunda vermutlich erledigt durch AC-EPRL | | Report Last Login The last use (successful or unsuccessful) of a user account should be reported to the user at their next successful login. | AC-RPLL: Camunda stellt die Info nicht bereit. Wie sieht es im BP aus? | | Architektur/404 | - bzgl. Portal-UI mit 404 klären
  • Akzeptieren für Camunda | | Delay or Block Login on Unsuccessful Login Attempts Following several unsuccessful authentication attempts, the user account must be locked either for a specific period of time or completely. | AC-DBUL: Ist das bei Keycloak umgesetzt? | Bei NuR/Azure AD prüfen | Architektur | - Klärung mit NuR bzgl. Verhalten bei Login
  • Camunda (siehe AC-EPRL) | | Confirm Critical Transactions Critical Transactions must not be performed by solely clicking one button to ensure that the actor is entitled to perform the transaction. This can be achieved by confirming the action. Depending on the business context this can be done by the same person e.g. by entering a (Time-Based) One-Time Password/Token or the confirmation by a different person (4 eyes principle).

In general, significant transaction data should always be presented as an inherent part of the transaction authorization process. Whereas the user experience should be designed to encourage users to verify the transaction data.

Each application must indentifiy what Critical Transactions are e.g. according to the business process. | AC-CCTA: Reicht das Verzögern des Transaktionsstarts im Frontend mit Abbruch-Möglichkeit für die Stornierung? Gibt es evtl. weitere solche Prozesse? | Kritische Transaktionen müssen zunächst definiert werden (fachliche Anforderung). Dann Umsetzung in UI. | PO/PM/404 | Weitergabe des Themas an Basil + Team 404 | | Reauthenticate Users for Critical Transactions Whenever a business criticial transaction is executed (e.g. password is changed), users must be reauthenticated, e.g. by entering their password or a TAN, even if they are working in a valid session. If the user forgets to log out and a third party has the opportunity to access this session as a result, the potential damage is restricted by means of this reauthentication.

This measure is also effective in cases where an attacker gains access to the user session as the result of a vulnerability in the application. It is a functional requirement that should ideally be taken into account as early as the UI design stage. | AC-RUCT: Falls es kritische Transaktionen gibt: Ist das umgesetzt? | Kritische Transaktionen müssen fachlich definiert werden. Dann Umsetzung in UI. | PO/PM/404 | siehe AC-CCTA | | Enforce 2nd Factor Authentication Applications which are exposed to the internet or are rated with a very-high protection-level need multi-factor authentication, as described in DBCK C3.0272.

In most cases a combination of something a user knows (e.g. password, PIN, answer to a secret question, etc.) and something a user possesses (key, security token, bank card, smartphone, etc.) is used, see OWASP - Multifactor Authentication Cheat Sheet.

We distinguish between two kinds of apps: Apps for DB employees (internal apps) and apps developed for the public (consumer apps) without a DB-User-Account. | AC-E2FA: Ist MFA in Keycloak aktiv? | Bzgl. NuR zu prüfen | Architektur | - NuR verwendet DB Azure AD (Vorgaben sind dort umgesetzt)

  • wenn AC-EPRL umgesetzt, gilt die Konfiguration von Azure AD auch in Keycloak/Camunda | | Use OpenID Connect for User Authentication For web or mobile applications user authentication must be performed using OpenID Connect, which is an authentication extension to the OAuth2 authorization protocol. At DB Systel our implementation of OpenID Connect is called "WebSSO". A server that provides OpenID Connect services is called an "identity provider" ("IdP" for short). | AC-UOID: Ist das überall richtig konfiguriert (z.B. BP)? | In Dev-Team zu behandeln | Team 404 | - OpenID Connect wird verwendet | | API Keys Public REST services without access control are exposed to the risk of a Denial of Service Attack. API keys can be used to mitigate this risk. However, when they are issued to third-party clients, they are relatively easy to compromise. With API keys it is for example possible to check and limit the number of requests per time unit per user.

The following rules are recommended:

Require API keys for every request to the protected endpoint.

Return 429 Too Many Requests HTTP response code if requests are coming in too quickly.

Revoke the API key if the client violates the usage agreement. | AC-APIK: Throttling / Rate-Limits nicht umgesetzt. | Wir verwenden keine API Keys | |

  • ISGW (SIPS-Team) fragen, ob dort Maßnahmen Throttling/Rate-Limits umgesetzt wurden/werden
  • Enabler: Throttling/Rate-Limits in Stammdaten-Bereitstellung umsetzen (ggf. Cloudfront; ggf. gibt es einen ADR dazu) das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-3424 | | Have a Patch Management Policy in Place Have a patch management and a vulnerability management policy in place. All software and hardware that is used in the system must be monitored for updates and patches and they have to be applied as soon, as possible. This relates especially to security updates. Ensure the versions in use are supported with security updates until the next check. To keep your software and hardware safe, always check for known vulnerabilities on National Vulnerability Database.

The up-to-dateness of the development environment also has a strong influence on the consequent consideration of security aspects. In general, the most recent environment should be used in order to be able to use the security features contained therein.

Your patch management policy should include rules for using or avoiding outdated methods or features.

Hints for developers: Many development environments, like Android Studio, explicity mark the usage of deprecated code. Tools like WhiteSource or Fortify will give hints in case this has an effect on the security of the code. | CM-PAMA: Keine Patchmanagement-Policy bekannt. Keine Scans der Pods zur Laufzeit bekannt? (z.B. Trivy-Operator) | Ist in Arbeit | Architektur |

| | Configure Log Level Per Stage Configure the log level in each stage appropriately. Production environments should not be configured by default with log levels below INFO. As a rule of thumb:

Production: INFO level for own code and WARN for third party libraries.

Test / Integration: DEBUG level for own code and WARN (or INFO if needed) for third party libraries

Development: Whatever makes sense.

Generally only use ERROR, WARN, INFO or DEBUG. | CM-LLPS: Wird bisher nicht unterstützt, weil Logging-Config nicht parametriert wird. | Logging Guidelines | Architektur/Alle Teams |

  • Enabler: Logging-Config pro Umgebung das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-5395 das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C404-3195 das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-3423 | | Check Configuration Before Deploying to Production Disable all unnecessary services in production environment that are not required. This refers to all software components under your responsibilty and may therefore affect the configuration of the operating system as well as the componetnts installed on top of it. For instance, switch off and remove all development and testing services. This includes ports, servlets, service Uis used for development and testing, e.g. SwaggerUI, and the like.

Please also refer to the CSIRT Secure Configuration Policies. | CM-DUSP: Warum ist in den Images Telemetrie eingebunden, obwohl es nicht genutzt wird bzw. nicht richtig konfiguriert ist? | zu klären | Architektur/Alle Teams | Enabler (ggf. PI 31): Entfernen von Test-Tools/Telemetrie etc. aus Jar, Images und Konfigurationen das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-863 | | Verify Integrity of Code and Configuration Files Use checksums or hashes to verify the integrity of interpreted code, libraries, executables, and configuration files | CM-VICC: Haben wir bisher nicht umgesetzt. | | Schick Schnack Schnuck |

  • CI/CD-Pipeline: Setzen von Container-Version und -Hash beim Deployment
  • Prüfung von helm-chart-Hashes? das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-833 | | Configure File Permissions Properly Improper file permission configuration may result in privilege escalation, information exposure, DLL injection, or unauthorized file access. Therefore, files permission must be properly configured with minium access permission by default. E.g. ensure application files and resources are read-only and passwords for technical users must be protected by restrictive file rights. | CM-CFPP: Zugriffsgrenzen für Secrets innerhalb des Namespace nicht realisiert | | Team Steam | Klären, was technisch machbar ist (ggf. verschiedene Kubernetes ServiceAccounts) | | Define Rules for Security Exception Detection With the help of attack detection metrics, rules should be created that signal exceptions to regular operations. In this way, it is possible to identify and react to potential attacks within the application. | CM-RSED: Für Zugriffe von innen (Bahn-Netz) nicht umgesetzt | | | Ggf. ISGW für Intranetzugriffe verwenden; EVU-abhängige Limits? | | Remove Unnecessary Code and Files Remove all unnecessary functionality, files, test code and any functionality not intended for production, prior to deployment. | CM-RUCF: Test-Endpunkte, Mocks, Inhalt des Basis-Images, Profiling... | | Alle Teams | siehe CM-DUSP | | Data Definitions Must be Static Data structures should not be defined by the application at runtime. Data structures should be defined statically and, for example, used as a configuration for installation or during an update. The most important application of this rule is in the use of DDL commands to define database schemas. The application may not use any DDL statements of a database, such as CREATE TABLE, at runtime. These commands from the DDL of a database must be delivered in a separate script that is only executed by an authorized user to install or update the software. | CM-STDD: Flyway läuft zur Zeit in der normalen Applikations-VM. | Flyway in CI/CD Pipeline extrahieren? | | Multi-Modul-Unterstützung benötigt (DDL-Skripte in gleichem Repository für Anwendung, aber separate Ausführung) das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-4958 das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-5067

Separater Schritt vor dem Deployment (helm install -> init job?) -> Enabler | | Limit Number of Transactions Limit the number of transactions a single user or device can perform in a given period of time. The transactions/time should be above the actual business requirement, but low enough to deter automated attacks. | CM-LNOT: Rate-Limiting fehlt | Fachliche Anforderungen bzgl. Limits definieren, danach umsetzen | PO/PM/Architektur/alle Teams | Ggf. EVU-abhängige Limits? (siehe CM-RSED) | | Configure Timeouts Appropriately Configure all timeouts in the application appropriate to be as long as needed. This is especially relevant when mitigating, e.g. DOS attacks relying on slow HTTP requests (aka slow loris), where the attacker sits and waits on open connection to the server and thus causes thread pool flooding. | CM-CTOA: Haben wir Timeouts für eingehende Verbindungen konfiguriert? Sind ausgehende Timeouts angemessen hinterlegt? | In Dev-Team zu behandeln; ggf. mit ISGW zu klären | Architektur/alle Teams | Prüfen der Anwendungen und Endpoints (eingehende und ausgehende Verbindungen) -> Enabler das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-5382 das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-3420 das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C404-3185

| | Management Endpoints Avoid publishing management endpoints for backend components, such as the database or the server, over the Internet. If such management endpoints need to be accessible over the Internet, ensure that users must use a strong authentication mechanism, such as multi-factor.

Make management endpoints available through HTTP ports or hosts that are different to the application and restrict access to these endpoints by using firewall rules or access control mechanisms.

Endpoints to administer the application itself, such as a Web Application having an Administrator User, may still be published over the Internet and secured by the authorization mechanisms of the application. | CM-MAEP: Zugriff auf Actuator-Endpoint derzeit nicht abgesichert. | | alle Teams | Actuator-Konfiguration für EVU-*-Umgebungen ggf. anpassen (deaktivieren) Zugriff auf Camunda-Management-Endpunkte (wie z.B. Cockpit) absichern/blockieren das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-5377 das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-3419 das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C404-3185 | | Use a Content Security Policy When building web applications return a Content Security Policy (CSP) HTTP header with every response from your server.

It can be used to detect and mitigate certain types of website related attacks like Cross-site scripting (XSS), clickjacking and data injections. These attacks are used for everything from data theft, to site defacement, to malware distribution. | CM-UCSP: Sind die CSPs konfiguriert und hinreichend abgesichert? Für SV nicht umgesetzt. | In REST-API nicht benötigt; Camunda Cockpit? | | Enabler f. Team 404 → CSP-Header setzen das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C404-3200

Enaber f. Team CIB: Prüfung nach der Umstellung auf Camunda 8; ggf. Nutzung von PAN-Client Enabler f. STeam: Prüfen von Grafana UI ob CSP-Header gesetzt werden, ggf. Support-Ticket an CNP → Grafana keine Bestellsystem-Applikation Keycloak (setzt CSP-Header), Kafka UI über PAN-Client | | Use Subresource Integrity When building web applications use Subresource Inegrity (SRI) for all resources which are fetched.

The browser calculates the hash value of the resource and compares it against the provided hash value. If they dont match, the resource was manipulated e.g. on the server. In this case the browser will refuse to execute the script or apply the stylesheet.

For SRI to be usable, the hashes of the fetched resources must be updated everytime the resource changes. If a resource changes on purpose and new hashes cannot be created immediately (e.g. referencing a latest-file), the check fails and the application may not work properly. In this case SRI cannot be used for this particular resource unless having stable/predictable responses. | CM-USRI: Ist das für BP umgesetzt? | | Team 404 | Enabler f. Team 404 → SRI-Flag beim Bauen setzen (ng build --subresource-integrity) das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C404-3201 | | Store Passwords in a Safe Way Passwords for user login to the application must not be stored in such a way within the application that the plain text password can be derived from them. Generally, it is not necessary to be able to view passwords in plain text. Passwords should be stored securely in the directory services. Only password hashes with "salt" and an iteration count, or cost factor are permitted.

While the "salt" is not confidential, a different "salt" must be used for each user. The use of one "salt" for all users of an application does not make sense and is not permitted. Also, the "salt" must not be chosen by the user but must be set by the application. A good "salt" would be a random string that is stored together with the hash value.

It is advisable to use a "pepper", as well, i.e. a part of the "salt" that is stored in the application. The real "salt" is a concatenation of the application-specific "pepper" and the user-specific "salt". Constructing the real "salt" this way an attacker can not know what the real salt is, if he steals the user database.

... | CY-SPSW: Salt für Camunda-User teilweise mehrfach vorhanden | | CIB | Enabler f. Team CIB → Salt-Verwendung prüfen und anpassen (nach Camunda 8-Migration) | | Sign On Message Level In addition to encryption using TLS or at transport protocol level, sensitive data should also be signed at message level (message level security).

This is particularly important if the message passes through intermediate locations where data with requirements pertaining to integrity or non-repudiability that are at least high is not processed, but simply forwarded. The consideration of whether to use message level security is based on specific attributes and depends on the transmission path and the value of the respective security attribute.

This signature must be created using one of the secure signature methods. The security of the private key used must be ensured accordingly.

The signature check should proceed in such a way that the trustworthiness of the sender’s certificate must first be checked. The signed element is then checked. This check must take place before the message is processed further. | CY-SML: Bisher nicht umgesetzt. | Anforderung zu klären | |

  • Enabler f. Team Zero: TAF/TAP-Nachrichten signieren u. Signatur prüfendas I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-3486
  • Separate Konzeptionsrunde für das Signieren von Nachrichten und Datenbankinhalten | | Sign Stored Data Data with high, or very high security requirements in the dimension of integrity must be protected from undetected changes. Data with very high security requirements should also be encrypted upon storage of data. | CY-SSD: Bisher nicht umgesetzt. In Camunda-Tabellen auch schwer bis nicht möglich einzubetten. | | |
  • Separate Konzeptionsrunde für das Signieren von Nachrichten und Datenbankinhalten | | Certificates Must be Checked If certificates are used, these must be checked thoroughly by means of recognized frame-works (certificate path must be valid, expiry date must not be reached, etc.). This check must not be disabled or omitted. | CY-CMC: Thema für Rest-Risiko-Deklaration (Load Balancer validiert keine Zertifikate) | | |

| | Provide Generic Error Messages and Use Custom Error Pages If an error occurs in a transaction, a functionally appropriate error text must be returned. Technical details of the error or sensitve information must not be transmitted. These details should only be stored in a log file (log) that can be accessed only by internal administrators. This applies both to error texts that are displayed to a user in an application and to API calls such as REST, SOAP or web services. There must not even be a mode provided for test purposes, in which the technical information is output in the event of an error. Such modes tend to be accidentally enabled in production, providing attackers with valuable clues.

In particular, it must not be specified for an invalid login attempt whether the user or the password were incorrect. It should only be confirmed that the login details were invalid. | EH-PGEM: Wie verhalten sich unsere Fehlermeldungen wenn technische Fehler auftreten (z.B. Wert, außerhalb der erlaubten Charsets, Datenbank oder anderer Endpunkt nicht erreichbar, Timeout…)? | | Alle Teams | Prüfung der Anwendungen vor dem nächsten Pentest. | | Separate Trusted and Untrusted Data The mixing of trustworthy data and unchecked data in one data structure wrongly encourages developers to trust unchecked data. For this reason, the designers of data structures must define "trust boundaries". Trust boundaries can be thought of as a line running through the program code.

Data structures containing data that can be trusted are located on one side of the line and those that contain data that is not to be trusted are located on the other. All data that crosses the boundary from the untrusted area to the trusted area must be validated during this transition. For example, the trust boundary should run between http request parameters and the session state: In principle, we trust the data in the session state and do not trust the data in the http request. This means, therefore, that data from the http request may not enter the session state without being checked. In other words, the trust boundary runs between the http request and the session state. | IV-STUD: Datenmodelle zwischen intern und extern nicht streng getrennt. | Validierung konsequent umsetzen | Alle Teams | Definition von Trust Boundaries und dort umfangreiche Validierung umsetzen. → Validierung externer Schnittstellen prüfen (Enabler erstellen für Prüfung) → wo nötig, weitere Validierungen implementieren | | Validate that Headers Contain Only ASCII Verify that header values in both requests and responses contain only ASCII characters. | IV-VHCA: Macht SpringBoot das Out-Of-The-Box? | Embedded Tomcat validiert die Header nach RFC 7230 and RFC 3986 | | Enabler f. Team 404 → Nginx Header-Validierung prüfen das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C404-3223 | | Validate Data from all Sources For applications with input and output interfaces, data validation must be performed at all interfaces in accordance with a risk assessment.

This involves performing syntactic and sematic checks such as validating the length, format, type, and value range of the data. Data sources include user inputs, parameters, URLs, header content, automated post backs from JavaScript and data that reaches the application via interfaces from other applications. Take care to also validate data from redirects. An attacker may submit malicious content directly to the target of the redirect, thus circumventing application logic and any validation performed before the redirect.

Use Schema Validation wherever possible to check all incoming data. All detected attempts to transmit invalid data must be logged.

... | IV-VDAS: Nicht umfänglich umgesetzt. | Validierung konsequent umsetzen | Alle Teams | Enabler f. alle Teams zusammen mit den Trust Boundaries (IV-STUD) | | Validate Data Early Data passed to your application from untrusted sources (e.g. a client on the web) should be validated as early as possible in the process. | IV-VDE: einige Validierungen erst in Steuerung-Vertrieb (Schema-Validierung existiert am Eingang ins Bestellsystem), teilweise auch nachgelagert | | Alle Teams | Enabler f. alle Teams zusammen mit den Trust Boundaries (IV-STUD) | | Validate Data Size Define a minimum and a maximum length for all parameters and requests and only process data which match these boundaries. Also check against functional requirements. This requirement protects against denial of service attacks by flooding the application with unexpectedly large data. | IV-VDS: Limits nicht hinterlegt, Status-Code 413 fehlt in Open-API-Dokumentation | | Alle Teams | Enabler f. alle Teams zusammen mit den Trust Boundaries (IV-STUD) | | Do Not Trust Uploaded Files Do not trust uploaded files: Code may be concealed in various file types. For example, both image and PDF files may contain scripts that are executed when the file is opened using the corresponding viewer. This code can often be removed by being converted into a different image or text type, possibly using the corresponding converter options. Such susceptible files should not, therefore, be processed further in their original version, but in a converted version. | IV-NTUF: Virenscan für hochgeladene Objekte in Buckets aktuell nicht vorhanden. | Fraglich, ob notwendig; S3 Buckets werden perspektivisch durch Kafka ersetzt | | Attachments in TAF/TAP?   | | Validation of XML The specifications for XML and XML schemas contain several security vulnerabilities. At the same time, these specifications provide the tools needed to protect XML applications.

XML Schemas are often used to enhance the security of XML documents. Unfortunately, however, they can be used for a variety of attacks: File retrieval, server-side request forgery, port scanning, or brute force.

Malformed XML documents and invalid XML documents are the two main vulnerabilities used to attack XML libraries or programs. | IV-XML: Ist die Validieren in CI so umgesetzt, dass keine Execution möglich ist? | | Team Zero | Enabler f. Team Zero: Prüfung der JAXB-Konfiguration das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-3487 | | Use Security Headers HTTP security headers enable security functions in the browser that are not used without explicit use of the headers.

Browser security headers help in the following scenarios: ➢ to determine whether to enable or disable a number of security features in the web browser. ➢ to strengthen the security of the web browser to defend against attacks and mitigate vulnerabilities. ➢ to defend against attacks on the client side (browser) such as clickjacking, injections, MIME sniffing (MIME = Multipurpose Internet Mail Extensions), Cross-Site Scripting (XSS = Cross-Site Scripting) etc. | IV-USHE: Haben wir das umgesetzt? | | Team 404 | Enabler f. Team 404: Prüfen, ob Security Header den aktuellen Empfehlungen entspricht das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C404-3239 | | Do not pass user supplied data into a dynamic redirect Do not pass user supplied data into a dynamic redirect. If this must be allowed, then the redirect should accept only validated, relative path URLs. Otherwise an attacker might be able to redirect his victim to a malicious site. | IV-USDR: Validierung intern prüfen | | Team 404 | Keine Redirects außer Oauth2 (redirect URL ist hier fest konfiguriert). | | Monitoring against Horizontal/Diagonal Password Guessing Attacks Implement monitoring to identify attacks against multiple user accounts, utilizing the same password. This attack pattern is used to bypass standard lockouts, when user IDs can be harvested or guessed.

However, brute force attacks exist in two variants that can also be combined. In a "vertical" password guessing attack, different passwords are tried in succession for one user account; this avoids the process described. In a "horizontal" password guessing attack, one password is tried for a number of different user accounts. Usually, these two types of attacks are combined. This is then referred to as a "diagonal" password guessing attack. Therefore, a user account may have to be (temporarily) locked or have a delay mechanism installed even if an incorrect password has been entered once only. | LA-MHPA: Ist das in Keycloak, sowie in Camunda (z.B. Cockpit) konfiguriert und mit Alarmen versehen? | | Architektur/Team CIB | In Keycloak prüfen, ob Brute Force Detection aktiviert ist. Weiterer Aufwand abhängig von Zugriff auf Camunda. Ggf. Logauswertung (häufigere Login-Fehlversuche) | | Obfuscate Client-Side Code Obfuscation is the process of transforming code and data to make it more difficult to comprehend. It is an integral part of every software protection scheme. What’s important to understand is that obfuscation isn’t something that can be simply turned on or off. Programs can be made incomprehensible, in whole or in part, in many ways and to different degrees.

... | DP-OCSC Obfuscate Client-Side-Code: Ist das bei BP umgesetzt? | | Team 404 | Enabler f. Team 404: Die Empfehlungen der TT-Web wurden in diesen Enabler umgesetzt: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C404-3161 | | Use HTTPS Use HTTPS with HSTS and disable HTTP.

The use of "HTTP Strict Transport Security" helps prevent man-in-the-middle attacks on encrypted connections in which the attacker foists an unencrypted HTTP connection on the browser. This can take place by means of an attack on bookmarks or by spam mail, for example. The browser notes that for a duration defined by the server, connections to certain addresses must take place by means of HTTPS. Unencrypted HTTP connections to the defined addresses during the defined period are rejected. | SP-UHTS: Warum ist dort allowSubdomains aktiv? | | Team 404, Team Zero | Enabler f. Team 404 + Team Zero: Header "HTTP Strict Transport Security" in Response setzen (mit includeSubDomains) → Header wird von ISGW gesetzt | | Only Use HTTP Methods That are Absolutely Necessary Some of the HTTP methods can potentially pose a security risk for a web application, as they allow an attacker to modify the files stored on the web server and, in some scenarios, steal the credentials of legitimate users. More specifically, the methods that should be disabled are the following:

PUT: This method allows a client to upload new files on the web server. An attacker can exploit it by uploading malicious files (e.g.: an asp file that executes commands by invoking cmd.exe), or by simply using the victim’s server as a file repository.

DELETE: This method allows a client to delete a file on the web server. An attacker can exploit it as a very simple and direct way to deface a web site or to mount a DoS attack.

CONNECT:  This method could allow a client to use the web server as a proxy.

TRACE: This method simply echoes back to the client whatever string has been sent to the server, and is used mainly for debugging purposes. This method, originally assumed harmless, can be used to mount an attack known as Cross Site Tracing. TRACE must therefore never be implemented and must always be answered with an error page.

... | SP-OUNH: Ist das bei BP abgesichert? | Konfigurierbar in Spring Security -> Dev Teams | alle Teams |

  • Whitelist in ISGW für benötigte Methoden
  • APIs prüfen, dass eindeutige HTTP-Methoden hinterlegt sind
  • Deaktivieren von CONNECT + TRACE in Spring Security Config | | Use CORS for External Web Elements Web applications should be structured in such a way that it is not necessary to circumvent the same-origin policy of the browser in order to be able to provide a specific function. For cases in which it is nevertheless necessary to avoid the same-origin policy, cross-origin resource sharing (CORS) should be used. The use of other procedures such as e.g. JSONP is not permitted. When CORS is used, it is particularly important to ensure that the permitted origins are defined as broadly as necessary and as narrowly as possible.

The HTTP response header properties (access-control-allow-origin, etc.) must be chosen so that only legitimate web pages can send requests to the server. | SP-CORS: Warum gibt es keine eigene Domain für Bestellsystem, damit die Cookies nur darauf berechtigt sind? | | |

| | Cookies Must Only be Used with the Attribute "HttpOnly" Cookies must only be used with the attribute HttpOnly. This means that they can no longer be read from a JavaScript program. This makes it difficult for an attacker to access the session ID. Applications that are only accessible via HTTPS should also use the secure attribute in addition to the HttpOnly attribute and should only deliver cookies via HTTPS. | SP-HTPO: Warum sind bei SV Cookies im Einsatz ohne HttpOnly-Flag? | | Team CIB |

| | Use a Page Token Access to URLs that change data within the application may only originate from the application itself. To guarantee this, a token, which is checked each time data is transferred, must be added to each screen as a "hidden form field" or an URL component. The token must have the following characteristics:

  • The token must be generated anew each time a new form is show.
  • It must be generated using a cryptographically secure random number generator.
  • It must be removed after use.
  • It may only be valid for a defined period of time. If the input originates from the user, a check must be carried out to ascertain whether the token transferred by the user corresponds to that of the server. The input is only processed if this is the case. If no token is available or it does not correspond, a general error message regarding impermissible access must be displayed. The token is discarded following the check. A new token is then generated for a new screen or repeated representation of the same screen. | SP-UPTK: Gibt es das bei BP? | Angular kommuniziert über REST | |

| | Use the right HTTP Return Code Different status codes are defined in HTTP. When you design a REST API, do not simply use 200 for success or 404 for error. Always use the semantically appropriate status code for the response. A list of HTTP status codes can be found in RFC 9110. | SP-UTRH: Warum gibt es in den APIs so oft Status-Code 400 für Fehler? Dieser besagt, dass die Form ungültig ist - aber sagt nichts über den Inhalt aus. | | Alle Teams |