Authors : Dheeraj Kumar Krishan & Ann Maria Manuel
What is FISMA ??
FISMA refers to the Federal Information Security Management Act of 2002, a U.S. federal law that mandates federal agencies and their contractors to secure information systems. Compliance with FISMA is crucial for organizations handling sensitive government data. It encompasses the practices and controls required to ensure that federal information systems are adequately monitored and protected against security threats through comprehensive logging and auditing mechanisms.
FISMA in Cloud Pak for Business Automation
Cloud Pak for Business Automation can now use an Audit Logging service to be ready for Federal Information Security Modernization Act (FISMA) requirements. The service logs user activities and system events in a Cloud Auditing Data Federation (CADF) standardized format, and provides retention and protection of the data.
By default, the Audit Logging service is not enabled to minimize the impact logging has on the cluster footprint. You can configure the CP4BA custom resource (CR) to enable the Audit Logging service for selected CP4BA capabilities to construct and send audit records
The audit log records all have a similar structure, which includes the following data:
- The outcome field identifies the result of the action, which can be success, pending, failure, or unknown. The return code is provided by the reason field.
- The action field identifies the action that triggers the audit record in the format serviceName.objectType.action.
- The severity can be normal, warning, or critical.
- The initiator section provides information about who initiated the action.
- The target and attachments fields identify the resource that the action is taken on. For example, it might give the name of the pod of the affected resource.
- The requestData section always contains the path and type fields but can contain other fields when the type of action is different.
By default, the Audit Logging service is not enabled to minimize the impact logging has on the cluster footprint. You can configure the CP4BA custom resource (CR) to enable the Audit Logging service for selected CP4BA capabilities to construct and send audit records. Before enabling the Audit Logging service, ensure that a Security Information and Event Management (SIEM) tool is set up to collect data from various sources and detect and block threats through real-time analysis. This approach mitigates the risk of losing audit records due to potential pod failures.
How FISMA logging can be enabled in CP4BA
The logging of audit-able activities and events of a CP4BA production deployment can be enabled after installation by setting the sc_audit_logging.enabled custom resource (CR) parameter to true. An audit event is any activity that manages or manipulates sensitive data. Information about the activity provides accountability, traceability, and regulatory compliance of data access, data modification, and data security.
Note :- CP4BA 25.0.0 Content pattern – FISMA is supported for CPE, CMIS, ICN & Zen only
Known limitation for CMIS in 25.0.0 - When you attempt to log in to IBM CMIS for FileNet Content Manager using any supported authentication mechanism, the authentication events are not recorded in the FISMA audit log files. This limitation arises because CMIS does not directly handle authentication logic. IBM CMIS does not have visibility or control over authentication outcomes. As a result, these events cannot be logged within the CMIS FISMA audit framework(https://ibmdocs-test.dcs.ibm.com/docs/en/cloud-paks/cp-biz-automation/25.0.0?topic=notes-known-limitations)
Procedure to enable Audit logging for CPE, CMIS, Navigator
To enable the Audit Logging service for CPE, CMIS & Navigator, change the value of the sc_audit_logging.enabled CP4BA CR parameter to true.
Method 1: Under shared_configuration in CR file, sc_audit_logging param can be added with a value true value
(In this case, Audit logging is enabled for all the capabilities in the CP4BA deployment)
Method 2: Within the CR file, add the audit_logging parameter with a value true at the component level under ecm_configuration for CPE and CMIS, and under navigator_configuration for Navigator
(The example CR parameters enables audit logging for CPE, CMIS, and Navigator)
CPE audit logging requires additional steps:-
Step 1: Confirm that the “ xxx-cpe-audit-deploy” pod has been successfully deployed
Step 2 : Login to ACCE using your LDAP credentials to access audit configuration settings
Step 3 : Enable audit logging on the specified object store
Step 4: Create a new audit definition for document class as below:
a) Log in to the Administrative Console for Content Platform Engine.
b) Navigate to your target Object Store.
c) Go to Data Design → Classes → Documents.
d) Click on Audit Definitions.
e) Select New to begin creating a definition.
f) In the form that appears, enter your audit definition details, matching the sample provided
g) Save the new audit definition when finished.
This configures audit logging for CPE
Procedure to enable audit logging for Zen:
a) Navigate to Workloads-->Secrets --> zen-audit-secret .
b) Edit this secret by uncommenting the following section
c) Restart the zen-audit pod.
This configures audit logging for Zen
Procedure to enable audit logging for IM Service :
Step 1: Configure Audit Settings via the OpenShift Console
a) Log in to the OpenShift Container Platform console
b) From the navigation menu, click Workloads > Config Maps.
c) Select All projects form dropdown
d) Search for platform-auth-idp.
e) Click --> Edit Config Map.
f) Set the following attribute values to true:
g) AUDIT_ENABLED_IDPROVIDER: 'true'
h) AUDIT_ENABLED_IDMGMT: 'true'
Step 2: Restart the platform-identity-management and platform-identity-provider pods
Step 3: Check platform-identity-management and platform-identity-provider pods if Audit is enabled or not by running below command in terminal window
How to view logs for each component:
When the audit-logging parameter is enabled via the CR either during or after CP4BA deployment, the corresponding audit log records can be seen.
CPE, CMIS & Navigator audit logging
a) In the OCP Console, Navigate to Workloads --> Pods --> then locate the following pods:
CPE Pod
Look for the pod named similar to “xxx-cpe-audit-deploy”
To find it via CLI : oc get pods -n <namespace> | grep cpe-audit
CMIS pod
Look for the pod named similar to “ xxx-cmis-deploy”
To find it via CLI: oc get pods -n <namespace> | grep cmis-deploy
Navigator Pod
Look for the pod named similar to “xxx-navigator-deploy”
To find it via CLI: oc get pods -n <namespace> | grep navigator-deploy
b) Navigate to the terminal view for this pod
c) Change the directory to the /audit-logging directory
d) Audit log files are created in the audit-logging folder with the names audit_<pod name>.log
ZEN & IM logging
Reference –
https://www.ibm.com/docs/en/cloud-paks/cp-biz-automation/25.0.0?topic=records-zen-service-audit-log
https://www.ibm.com/docs/en/cloud-paks/foundational-services/4.12.0?topic=guide-auditing-im-service
Navigate to Workload --> Pods --> zen-audit pod --> Click on logs to view the Zen audit logs
This completes the steps to configure and view the Audit logging service in CP4BA 25.0.0.
For more information, see the IBM Docs (https://www.ibm.com/docs/en/cloud-paks/cp-biz-automation/25.0.0?topic=automation-release-notes) for the latest updates and interim fixes.
We would like to thank the people who helped us review and publish this blog - Nusaiba K K, Binoy MV, Todd Deen, Adam Davis, Jason Kahn & Justin Wang