SaaS SIEM RFI Questions and Responses.pdf
PDF 122 KB Posted
- Attached to
- DOJ Software as a Service (SaaS) log management / Security Information and Event Management (SIEM) solution
- Solicitation number
- DOJRFI-1
About this file
This file is a Questions and Answers document for the Department of Justice (DOJ) SaaS SIEM Request for Information (RFI). It provides clarification on 44 questions submitted by potential vendors regarding a cloud-based Security Information and Event Management (SIEM) platform acquisition.
The RFI addresses a planned migration from the DOJ's existing on-premises Splunk Enterprise environment to a unified SaaS SIEM solution capable of ingesting 60TB+ per day with 6+6 month retention requirements (searchable hot storage for six months plus cold storage for an additional six months). Vendors must provide a single-vendor, unified SaaS platform delivering core SIEM capabilities including ingestion, search, analytics, detection, investigation, and Security Orchestration and Automation Response (SOAR) functions without separate third-party procurement, though vendor-integrated open-source components and government-owned data pipeline layers are permitted. The solution must support FedRAMP High authorization (with FedRAMP High-Ready or in-process authorization with defined sponsorship timelines acceptable during the RFI phase), accommodate 120,000 scheduled searches and 2,000 concurrent searches within a single tenant, and process data across all FIPS 199 security categorization levels including Criminal Justice Information from FBI and other DOJ components. Key evaluation criteria include search performance benchmarks at enterprise scale, migration approach minimizing operational disruption, AI/ML capabilities with explainable intelligence, tamper-evident log provenance with cryptographic verification, alignment with FedRAMP 20x initiatives, natively managed data collection agents, and flexible licensing models beyond volume-based pricing. The DOJ has not finalized acquisition strategy decisions regarding small business set-asides, phased implementation approaches, or specific technical implementation preferences, indicating this RFI serves to inform market research and subsequent acquisition planning.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| SaaS SIEM Request for Information.pdf |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
DOJ SaaS SIEM RFI — Questions and Answers
Section 1. Accreditation Status
Question 1: Will the Government consider sources holding FedRAMP High-Ready or in-process authorization with an identified agency-sponsorship path and defined timeline, or is a completed Authorization to Operate required at the time of any future proposal submission?
Answer: The Government may consider sources holding FedRAMP High-Ready or are in process authorization with an identified agency-sponsorship path and defined timeline.
Question 2: Is FedRAMP High Authorization mandatory, or are FedRAMP High Ready and FedRAMP Moderate acceptable?
Answer: See Question 1 above.
Section 2. Ingest Volume and Scalability
Question 3: Ingest volume basis. Is the stated 60TB+/day figure current-state or projected, and does it include log sources not yet centralized (e.g., EDR, identity, secure web gateway, and network device logs planned for onboarding)?
Answer: The stated 60TB should be treated as a planning estimate volume. Vendors should describe their ability to scale to and beyond the planning estimated volume without material degradation in service.
Question 4; Are the 60TB/day requirements enterprise-wide averages, peaks, or design thresholds?
Answer: See Question 3 above.
Question 5: Is 60TB/day measured raw or post-reduction, average or peak, and does the 6+6 month retention apply to the full daily volume or a defined subset?
Answer: See Question 3 above. The full daily ingest volume is subject to the required retention period.
Section 3. Migration Source Environment
Question 6: Can the Government clarify whether the migration source is Splunk Enterprise (on-premises), Splunk Cloud, or hybrid, and the approximate volume of knowledge objects and scheduled searches to be migrated?
Answer: The primary migration source is the DOJ’s existing on-premises Splunk enterprise environment. Vendors should describe their approach for migrating or recreating applicable searches, detections, dashboards, alerts, data integrations, knowledge objects, and other operational SIEM capabilities. The Government is interested in approaches that minimize operational disruption and reduce manual migration effort.
Question 7: Is coexistence with Splunk expected during migration only, or permanently
Answer: The Government requires vendors to ensure continuity of operations during the migration. Parallel operations with current SIEM are expected during the migration phase to validate data integrity, detection coverage, and operational continuity. Vendors should provide architecture plans and approaches that deliver measurable benefits and cost savings.
Section 4. Single-Vendor Solution
Question 8: Does "single-vendor solution without third-party solutions" refer to solutions requiring separate third-party procurement or licensing by DOJ, or does it also exclude vendor-integrated open-source components delivered and supported entirely under the vendor's single subscription?
Answer: The Government defines a “single-vendor solution” as a unified vendor-provided SaaS SIEM platform in which the core capabilities required by the RFI are delivered, operated, supported, and maintained as an integrated platform under a single vendor offering.
Question 9: Does the “single-vendor solution” requirement apply to the application/service layer, or does it also restrict use of a FedRAMP-authorized underlying cloud infrastructure provider (e.g., a hyperscale IaaS/PaaS environment that the offered SaaS solution is built upon)?
Answer: See Question 8 above.
Question 10: Must every required capability be native to a single product, or may vendor-owned modules within the same platform be used?
Answer: See Question 8 above.
Question 11: RFI discourages third-party solutions. How does DOJ define "single-vendor solution" and are alliance-partner/OEM delivery models acceptable?
Answer: See Question 8 above.
Question 12: Given the RFI's requirement for a complete, single-vendor solution without reliance on third-party tools, how does the Department intend to evaluate the operational risk, added latency, and potential integration failure associated with orchestration and automation capabilities that depend on a separate, third-party tool rather than being native to the platform, particularly during active threat containment?
Answer: The DOJ has not made a final acquisition strategy determination. Responses to this RFI will inform market research and acquisition planning.
Question 13: The RFI identifies Cribl LogStream by name (p. 11) among technologies the solution should integrate with. If the Department currently operates, or plans to operate, a data pipeline or log routing tier as Government-furnished infrastructure, will the Government confirm whether capabilities delivered through that Government-owned tier would be considered part of the Department's environment rather than a third-party solution under the Performance Objectives on p. 2?
Answer: The “single-vendor” restriction applies only to the proposed SaaS SIEM solution itself and does not include any Government-owned data-pipeline or log-routing tiers. These Government-furnished layers are treated as part of the Department’s environment and do not change the requirement that the vendor provide a unified, fully supported single-vendor SIEM platform.
Section 5. Search Performance
Question 14: Can DOJ clarify whether this requirement seeks a contractual SLA tied to query execution time, or whether documented performance benchmarks and service availability commitments are acceptable for market research purposes?
Answer: For the purposes of this RFI, vendors should provide representative performance benchmarks at enterprise scale, including search latency, concurrent searches, historical data search performance, data volume assumptions, and any factors that materially affect query performance.
Question 15: Are the 120,000 scheduled searches and 2,000 concurrent searches expected simultaneously within a single tenant?
Answer: These requirements are intended to represent the expected operational capacity within a single tenant. Vendors should describe their solution’s ability to scale to these volumes, including any architectural considerations, resource allocation mechanisms, and controls for managing search concurrency and scheduled search limits by role or user.
Question 16: What is the evaluation for a vendor's ability to enforce performance isolation at the query execution layer, so that resource-intensive, ad hoc investigations conducted by parent tenant analysts do not degrade real-time alerting for External Federal Agency (EFA) tenants operating on the same platform?
Answer:
The DOJ has not made a final acquisition strategy determination. Responses to this RFI will inform market research and acquisition planning.
Section 6. SaaS Updates and Change Management
Question 17: Can DOJ clarify what level of control or approval is required for SaaS service updates? Specifically, is advance notification, testing in a non-production environment, scheduled deployment windows, or formal Government approval expected prior to service enhancement rollout?
Answer: The DOJ does not intend to prevent routine SaaS maintenance, security updates, or standard service enhancements inherent to a commercially operated SaaS offering.
Vendors should describe their change management process, customer notification mechanisms, maintenance windows, release transparency, rollback capabilities, and mechanisms available to minimize impacts to the DOJ’s mission. Changes that materially affect DOJ's security, interoperability, data handling, or mission operations should include appropriate advance notification and coordination.
Question 18: "...allows the DOJ to have control and/or approval prior to any system upgrades or enhancements that change user experience, system capability, or system performance." Will advance release notification, DOJ-defined maintenance windows, and a non-production tenant for pre-release validation satisfy this?
Answer: See Question 17 above.
Section 7. Ingestion / Search — RTM ID ING-017
Question 19: Can DOJ clarify how "indefinite retry logic" should be interpreted? Does DOJ require unlimited retention and retry capability regardless of outage duration, or would documented queueing, buffering, and configurable retry periods satisfy this requirement?
Answer: The intent is to prevent avoidable data loss during ingestion, collection, network and or service disruptions. Vendors should describe their queuing, buffering, persistent storage, retry, backfill, failure notification, and recovery capabilities, including configurable limits and mechanisms for identifying unrecoverable logging gaps.
Section 8. Data Pipeline — RTM ID ING-024
Question 20: "Provide automated verification of log provenance (including cryptographic signing, chain-of-custody preservation, or hash-linking) to ensure logs used in investigations remain tamper-evident and immutable." Can DOJ clarify whether this requirement calls for native cryptographic signing of every individual log record, support for evidentiary chain-of-custody processes, immutable storage capabilities, or another specific implementation approach?
Answer: Vendors should describe the technical controls used to provide tamper evidence, immutability, integrity validation, chain of custody support, cryptographic verification, access auditing, and protection against unauthorized modification and or deletion.
Section 9. Accreditation / Security — RTM ID SEC-003
Question 21: "The vendor shall describe how the proposed SaaS SIEM solution aligns with FedRAMP 20x initiative…" Can DOJ identify the specific FedRAMP 20x objectives, success criteria, or evaluation factors that will be used to assess vendor responses to this requirement?
Answer: The Government is seeking industry information regarding how proposed solutions align with the objectives and evolving requirements associated with the FedRAMP 20x initiative. Vendors should describe current participation or alignment, automation of security validation and evidence, continuous monitoring capabilities, machine readable security artifacts, and their roadmap for maintaining alignment as FedRAMP 20x requirements mature.
Section 10. AI / ML Capability Requirements — Agentic SOC
Question 22: "Agentic SOC capabilities to independently triage and investigate security alerts." Can DOJ clarify whether human-in-the-loop workflows satisfy this requirement, or whether DOJ expects fully autonomous triage and investigation actions without analyst approval?
Answer: Vendors should clearly distinguish between fully autonomous capabilities, analyst approved actions, and capabilities requiring direct analyst execution, including the safeguards and auditability associated with all.
Question 23: "Provide explainable Artificial Intelligence (XAI), or Interpretable AI, or Explainable Machine Learning (XML) capabilities…" Can DOJ clarify its minimum expectation for explainability — for example, explanation of contributing factors, confidence scores, rationale for detections, model transparency, or other explainability artifacts?
Answer: Vendors should describe available contributing factors, evidence, confidence or risk scoring, detection rationale, model transparency, auditability, and mechanisms allowing analyst to understand why a particular user, entity, event, or behavior was identified as anomalous or malicious.
Question 24: Are AI features mandatory or desired? Will DOJ require all AI processing to remain inside FedRAMP-authorized boundaries?
Answer: The DOJ has not made a final acquisition strategy determination. Responses to this RFI will inform market research and acquisition planning. All AI processing must remain inside FedRAMP-authorized boundaries.
Section 11. FIPS 199 Security Categorization
Question 25: What is the FIPS 199 security categorization (Confidentiality, Integrity, Availability) of the data types this system is expected to ingest and process?
Answer: This system is expected to ingest and process data across all FIPS 199 security categorization levels: Low, Moderate, and High for Confidentiality, Integrity, and Availability.
Vendors should describe how their solution will accommodate data from systems with varying impact levels, ensuring appropriate safeguards and compliance measures are in place for each category. The platform must be capable of supporting the full range of federal information, from routine operational logs to highly sensitive records, and vendors are expected to outline their approach for handling, protecting, and processing data at each impact level.
Question 26: Will Criminal Justice Information (CJI), as defined by the FBI CJIS Security Policy, be present within the data ingested by this system?
Answer: Vendors should plan to treat all data as eligible for ingestion from all DOJ Components including FBI. Solutions must be capable of accommodating the full range of data types and security categorizations present across DOJ organizations, ensuring appropriate safeguards and compliance measures are applied consistently.
Section 12. SOAR Requirements
Question 27: Regarding the Security Orchestration and Automation Response (SOAR) requirements described in Scope: does the Department require these capabilities to be delivered through a dedicated, native SOAR module within the solution, or will equivalent orchestration, automation, and response outcomes — achieved through alternative approaches such as AI-driven automation, extensible APIs, or workflow integrations — satisfy this requirement?
Answer: The Government is seeking industry information regarding how proposed solutions deliver Security Orchestration and Automation Response (SOAR) capabilities. Vendors should describe whether their solution provides a dedicated, native SOAR module or achieves equivalent orchestration, automation, and response outcomes through alternative approaches such as AI-driven automation, extensible APIs, or workflow integrations.
Section 13. Retention
Question 28: OMB M-26-14 calls for a minimum of six months of searchable retention with an additional six months in cold storage. How does the Department intend to evaluate platforms that restrict real-time alerting, reduce search functionality, or introduce additional licensing costs once data moves beyond an initial, shorter retention window?
Answer: The DOJ has not made a final acquisition strategy determination. Responses to this RFI will inform market research and acquisition planning.
Question 29: What retention period beyond the stated 12 months should respondents assume for pricing and architecture planning
Answer: Vendors should provide references that best outline their retention capabilities and pricing models for periods beyond 12 months, referencing prior implementations that align with Government’s anticipated data volumes and operational requirements.
Question 30: "...stores data in (1) a fast-searchable (i.e. 'hot') high-speed repository, (2) a less-fast-searchable (i.e. 'cold') less-expensive repository and (3) archive (i.e.
'frozen') repository." Will DOJ accept a single high-performance tier that keeps the full 12-month retention immediately searchable?
Answer: Vendors should provide references that best outline their retention capabilities and pricing models for required retention period requirements.
Question 31: Will the Department consider it a limitation if a platform requires a restore or rehydration process, introducing delay, before analysts can query cold or archived data during an active threat hunting investigation, and will the Department require that cold and archive storage tiers remain natively and directly queryable within minutes without provisioning additional local storage or compute?
Section 14. Licensing and Pricing
Question 32: As the Department works toward higher OMB M-26-14 logging maturity levels, which will increase the volume of data ingested over time, will the Department consider licensing and pricing models that are not based solely on the total volume of data ingested, and how does the Department intend to evaluate the budgetary risk to agencies under a purely volume-based pricing structure as ingestion scales?
Section 15. Data Collection Agents
Question 33: Will the Department give weight to platforms with natively managed agents capable of centrally and remotely deploying policy updates and software upgrades across a distributed enterprise, and how does the Department intend to evaluate the maintenance burden and operational risk associated with agents or data collection pipelines that depend on separate, third-party software requiring independent lifecycle management?
Section 16. Data Collection Methods
Question 34: How does the Department intend to evaluate data collection methods that rely on lightweight, user-space telemetry techniques such as Extended Berkeley Packet Filter (eBPF) as compared to methods that require heavier, kernel-level drivers, particularly with respect to the stability and performance risk that kernel-level drivers may introduce within non-persistent Virtual Desktop Infrastructure (VDI) environments?
Section 17. Unified Data Engine
Question 35: Will the Department give weight to solutions built on a single, unified data engine for log management, SIEM, and analytics, and how does the Department intend to evaluate the additional latency and analyst workload created by solutions that require manually correlating data across separate, disconnected backend systems during incident response?
Section 18. Natively Managed Agents
Question 36: Will the Department give weight to platforms with natively managed agents capable of centrally and remotely deploying policy updates and software upgrades across a distributed enterprise, and how does the Department intend to evaluate the maintenance burden and operational risk associated with agents or data collection pipelines that depend on separate, third-party software requiring independent lifecycle management?
Answer:
The DOJ has not made a final acquisition strategy determination. Responses to this RFI will inform market research and acquisition planning.
Section 19. References
Question 37: For the government-reference requirement, will the Government accept commercial references and/or a demonstrated pilot in lieu of federal production references for emerging solutions?
Answer:
Vendors should provide references that best demonstrate successful performance at scale and complexity comparable to the Government’s objectives.
Question 38: Does DOJ require demonstration using DOJ-sized datasets?
Answer: Vendors should provide references that best demonstrate successful performance at scale and complexity comparable to the Department's objectives.
Question 39: Are Government references required to be active Federal customers?
Answer: Vendors should provide references that best demonstrate their successful use cases. This may include both current and past customers, federal or otherwise, as long as the reference highlights relevant experience and capability.
Section 20. Acquisition Approach
Question 40: Is a small-business set-aside under consideration for any resulting requirement, and would the Government entertain a phased approach (assessment/pilot, coexistence with the incumbent during migration, then cutover)?
Section 21. Certificate Authority / PKI Management
Question 41: The Accreditation / Security section (p. 9) requests a solution "that can manage internal certificate and certificate distribution management (i.e., Certificate Authority Management solution)." Will the Government clarify its intent for this requirement? Specifically, does the Government seek a log management / SIEM solution that itself functions as a certificate authority and performs enterprise certificate issuance and distribution, or is the intent that the solution interoperate with the Department's existing PKI and certificate management infrastructure for authentication?
Answer: The Government seeks a solution that interoperates with existing DOJ PKI services, uses DOJ-issued certificates for authentication, and can manage certificate distribution only to the extent necessary for secure operation within the SIEM ecosystem, not one that serves as a standalone enterprise Certificate Authority.
Section 22. Response Format and Administrative Requirements
Question 42: Response Instruction B establishes a 15-page limit "including a two-page Capability Statement." Response Instruction C requires "a table of SLAs, performance metrics of the single-vendor solution," and Response Instruction D requires respondents to "provide demonstration on the capabilities of the offered solution and how it meets each requirement." Given that the Scope of this RFI contains approximately 190 discrete requirement statements, will the Government clarify:
a. Whether appendices, including the required SLA table and any requirements traceability matrix, count against the 15-page limit
b. Whether the Government permits Response Instruction D to be presented as a table or appendix excluded from the page count, or if an alternative demonstration method (such as an in-person or recorded video presentation) is intended.
Answer: The 15-page limitation applies to the substantive technical response. The cover page and required Service level Agreement (SLA) table will not count toward the page limit.
Vendors are encouraged to keep supplemental information directly relevant to the Government’s objectives.
Question 43: Page 17 – “Response Instructions” - (B) "No more than 15 pages in length, including a two-page Capability Statement." | (D) "Must provide demonstration on the capabilities of the offered solution and how it meets each requirement" Are the requirements traceability matrix, the SLA/performance-metrics table, and technical appendices excluded from the 15-page limit?
Answer: See Question 42 above.
Section 23. Sizing, Scale, and Performance
Question 44: To support accurate sizing and pricing under Section D, will the Government provide the following information regarding the current environment:
a. Anticipated annual growth rate over the expected period of performance
b. Approximate number of distinct data source types currently onboarded
c. Approximate distribution of current daily ingest volume by major source category, for example endpoint and EDR telemetry, network and firewall, identity and authentication, cloud and SaaS audit logs, operating system and host logs, application logs, and operational technology or IoT
d. Approximate distribution of alert and detection dispositions, for example confirmed true positive, benign true positive or expected activity, false positive, duplicate or correlated to an existing case, and closed without disposition
e. Approximate number of cases or incidents formally opened per week, and average analyst time expended per alert triaged and per case worked
Answer: At this stage of the market research process, the Government is not providing detailed operational metrics such as ingest distribution by source category, alert disposition patterns, or SOC case-handling volumes. These data elements may be shared, as appropriate, during subsequent acquisition phases, consistent with operational security requirements and applicable acquisition regulations.
Vendors are encouraged to describe architectural scalability, performance resilience, and cost-model flexibility sufficient to accommodate workloads in the estimated 60TB-per-day ingest range, as identified in the RFI. Approaches that demonstrate elasticity, efficiency at scale, and predictable performance under high-volume conditions will help inform the Government’s evaluation during later phases.
File details come from the government source that posted it. Updated .