Responses to CSO Questions.pdf

Responses to CSO Questions

1. In order to generate an appropriate scoping/pricing guide, how many individuals in the organization would require access to the Application Monitoring Tool in a non-user/viewer capacity?

Less than 25

2. Regarding the optional cloud transition, on what timeframe is such a transition being considered? Is there an opportunity to conduct the cloud transition as part of the initial phase of work?

Dependent on the solution chosen, and the DEAMS situation at the time of implementation

3. What is the data security level for this system? (IL4, IL5, or beyond?)

IL4

4. What quantities of existing data will need to be transferred to the new system, and how in what format is this data stored currently?

Would not expect to transfer data, unless new system requires it. Would expect to maintain historic and move forward with new solution.

5. Are there additional details on the current DEAMS server architecture and compatibility requirements for the new solution?

Need a product that will support reporting off Sparc Solaris Super Cluster, Windows and Linux. Production is located on premise at DISA and Development is located on OCI.

6. When does the existing Oracle tool reach “end-of-life?” Will there be a requirement to simultaneously support both Application Monitoring Tools for a time before cutting over to the new system?

GRC end of life is May 2025

7. Is there an opportunity to include Generative AI or Agentic AI capabilities in support of audit, reporting, and approvals functionality in the solution?

Yes

8. Software Functionality 1 -- What types of configurations (e.g., hardware, software, network settings) need to be baselined?

Software Configurations related to setup configurations, profile options, and master data

9. Software Functionality 2 -- What specific data points (e.g., user, timestamp, change details) need to be tracked for each configuration change? How granular should the audit trail be (e.g., every change or only specific types)?

Software configurations/Master Data need to track detailed changes, unlike oracle storing simply the creation date/created by and last_updated_by and last_updated_by, there needs to be a complete listing of updates.

10. Software Functionality 3, 4 and 5 - How should configurations changes between baseline, environment, and master data be presented (e.g., visual differences, tables)? Could you provide an example report of each?

Should be able to generate reports between our dev/test/production environments that show differences.

As a user/reporter, I want to access the key configuration setups mentioned in multiple instances in DEAMS; The system shall be configured to provide software configuration reports (i.e., current status of the system) across multiple instances of DEAMS

11. Software Functionality 8 - What are the security requirements for accessing and storing reports (e.g., encryption, access controls)?

There needs to be access controls so output is accessible only to authorized resources.

12. Software Functionality 9 - Are there examples of current tagging practices you want to replicate or improve?

No, this is a new requirements in order to help facilitate reporting

As a user, I want to associate the key configuration reports to a risk, control, audit, ticket, and/or tag; Provide a solution where common themes or tags can be used easily associate risks, controls, and audits; and allow users to be able to search these common themes or tags

As a user, I want to be able to easily search for associate risks, controls, audits, tickets, and/or tags; Provide a solution where common themes or tags can be used easily associate risks, controls, and audits; and allow users to be able to search these common themes or tags

13. Software Functionality 11 - How complex are the approval workflows (e.g., single approver, multi-step, conditional)?

Fairly simple workflows, when requests are made to modify configurations, a workflow will be initiated with a 1 to 2 approvers.

14. Software Functionality 12 - What does "analyze patching" entail (e.g., patch compliance, missing patches, patch impact analysis)?

Standard Oracle Patch Analysis requires a technical knowledge to understand the implications of the patching. Patch analysis should allow for non technical resources to review output detailing the impacted processes, responsibilities, concurrent programs in standard oracle and custom RICEW objects.

15. Software Functionality 13 - Are there required metrics/KPIs that would be relevant for the Dashboard?

Monitor Configuration Changes (by application, by user, additional filters)

Monitor Master Data Changes (by application, by user, additional filters)