RQA customer-managed deployment best practices

Learn about the IBM® Engineering Requirements Quality Assistant (RQA) customer-managed deployment best practices.

Security and Privacy Overview
IBM RQA customer-managed is approved by the IBM Cloud Pak® Certification 2.0. The following aspects of security are considered and addressed by IBM RQA customer-managed:
  • Identity Management
  • Authorization and Authentication
  • Encryption (TLS)
  • Networking
  • Secret, key, and certificate management
  • Auditing
RQA performs security hardening by:
  • Performing extensive software scanning to identify and resolve the compile time, and runtime vulnerabilities.
  • Ensuring that the data in transit is encrypted by using Transport Layer Security (TLS) 1.2.
For more information, see Security configuration and security hardening.
Product Configuration for Security and Privacy
The following are the IBM RQA configurations for security and privacy:
  • Identity Management: Identity management is done by Jazz® Authorization Server (JAS) that is based on the IBM WebSphere® Liberty server. RQA recognizes the following identities:
    • IBM RQA administrator dashboard users
    • IBM RQA widget users for IBM Engineering Requirements Management DOORS® Next (DOORS Next).
  • Authorization and Authentication: Users can access the IBM RQA administrator dashboard and the RQA widget for DOORS Next by using the JAS single sign-on (SSO), which is based on OpenID Connect (OIDC) protocol for authentication. Users are authenticated by a third party, which is JAS that creates a JWT Bearer Token. This token is used by IBM RQA administrator dashboard and IBM RQA widget for DOORS Next for session management.
  • Encryption (TLS): IBM RQA ensures that the data in transit is encrypted by using Transport Layer Security (TLS) 1.2.
  • Networking: Network policies are defined to maintain the isolation policies. Ingress policies are used to specify which pods can accept traffic from which pods.
  • Secret, key, and certificate management: Sensitive information like DB credentials, JAS credentials are stored in secrets, which are encrypted and secure. It is recommended that customers must use valid Secure Sockets Layer (SSL) certificates when they install RQA.
  • Auditing: IBM RQA security events are captured in the audit logs and stored in the database. Examples of IBM RQA security events are login and logout of RQA widget, and RQA administrator dashboard, checking in and checking out of license tokens, addition, or deletion of RQA administrator dashboard users.
Data Life Cycle

IBM RQA uses the IBM Redis database to store the configuration and operational data. IBM Redis is used as an in-memory data store and cache. It is used as a messaging channel across the services.

Data Collection

IBM RQA administrator dashboard users manage the customer data for IBM RQA widget configuration and RQA administrator dashboard users management.

Customers can send the Teach Watson™ feedback through the IBM RQA widget for DOORS Next. They can send the feedback on the requirement guidance and scoring that is provided by RQA, and if shared with IBM, help improve the AI model accuracy. The Teach Watson feedback that customers want to provide to IBM is stored in the database. As of now, no provision is there to send the feedback automatically to IBM. The primary administrator must extract the Teach Watson feedback from the database, and contact and share the feedback with the IBM Offering Manager.

IBM RQA does not store any user credentials. Audit logs for security events are stored in the database.

Data Storage:

IBM RQA uses the IBM Redis database to store the configuration and operational data. Encryption of data at rest in IBM Redis is handled outside the database.

Data Access:

IBM RQA administrator dashboard users can access and manage the IBM RQA widget configuration data. They can also add or remove IBM RQA administrator dashboard users.

Feedback data and audit log data are not revealed to users through any of the product interfaces.

Data Processing:

IBM RQA widget configuration data that is managed through IBM RQA administrator dashboard is used to provide customized requirements quality analysis.

An SSO session timeout configured for the Jazz Authorization Server. Some times, users log in to the RQA widget or the RQA administrator dashboard, and forget to log out. If so, the inactivity for the session timeout period is recorded in the audit log data. As a result, the tokens that are checked out by them are checked back in so that other users can use them.

Data Deletion:

IBM RQA configuration and operational data is maintained during the IBM RQA lifecycle.

All the audit log data is retained for security compliance purpose. Also, the feedback data is retained.

Personal information (PI), such as email addresses and usernames of the RQA administrator dashboard users is deleted when the RQA administrator dashboard users are deleted by using the user management.

Data Monitoring:
IBM RQA maintains the audit log of the security events as follows:
  • Time stamps and user ID for each login and logout process
  • Time stamps and user ID for each token check out and check in process
The following user actions are written in the audit log:
  • Login and logout of the IBM RQA widget user
  • Login and logout of the IBM RQA administrator dashboard user
  • Check out and check in of license tokens
  • Addition or deletion of the RQA administrator dashboard user
  • Requirements analysis done by the RQA widget user
  • Submission of the feedback about RQA requirements scores and quality issues by the RQA widget user
Responding to Data Subject Rights

For RQA customer-managed, data resides in the IBM Redis database. Details about specific data are shared with customer upon request only.