RFI_Twistlock.xlsx
XLSX spreadsheet 22 KB Posted
- Attached to
- FA8307_RFI_Twistlock_Alternatives
- Solicitation number
- HNCKP_Platform_One_FY25_Twistlock
About this file
This is a Request for Information (RFI) spreadsheet seeking alternative solutions to Palo Alto Twistlock for the Department of Air Force's Platform One (P1). The RFI focuses on capabilities related to container security, Kubernetes defense, runtime security, and vulnerability analysis.
The document contains detailed requirements across four main categories: General Requirements (17 items), Runtime Security (17 items), Vulnerability Analysis (24 items), and Compliance Scanning (4 items). Key requirements include Kubernetes node defense, container protection, machine learning-based anomaly detection, vulnerability scanning, and compliance monitoring. The RFI requests information about alternative licensing models, pricing structures (including base year with up to four one-year options), transition costs, training requirements, and additional features. Vendors must indicate whether capabilities are available on day one or provide estimated timelines for future implementation. The RFI particularly emphasizes RBAC capabilities, SSO/SAML integration, API functionality, and comprehensive vulnerability management features.
View the file
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
RFI Excel version of Word sheet
| Alternative License Types: | |
| 1 | What alternate licensing models or solutions do you offer for Palo Alto Twistlock? |
(Please provide details on available options, such as enterprise, cloud-managed, or open-source/community editions. For each licensing option/solution set, please provide how it differs from the listed license.)
2 For each licensing option/solution set, please provide how it is similar from the listed license.
(Specify any feature restrictions, scalability limitations, or support differences among the licenses (e.g., data retention, search query limits, or alerting capabilities)
3 For each licensing option/solution set, please provide how it meets the above requirements.
(Identify core features or capabilities that are shared across all options, such as log aggregation, visualization tools, and monitoring capabilities, regardless of the license type.)
4 For each licensing option/solution set, clarify how it meets the above requirements for our logging and monitoring needs.
(Please highlight specific ways in which each licensing tier can address our operational, security, and compliance needs, particularly in areas like multi-environment visibility, role-based access control, and support for compliance auditing.)
| Pricing Information: | |
| 1 | For each license, please provide estimated transition and training costs and schedule for both transitioning to and from your proposed solution. |
(Include details on onboarding costs, consulting, or configuration support required for a smooth transition. Specify any training options available, such as workshops, online courses, or documentation resources, and their associated costs.)
2 For each license, please provide any price plans associated such as monthly, trial, annual.
(Indicate if discounts are offered for longer-term contracts or high-volume deployments. For cloud-managed options, provide cost breakdowns for storage, query processing, and other usage-based charges.)
| Other Considerations: | |
| 1 | Are there any additional features or benefits associated with the different licenses that we should consider? |
For example, are advanced analytics, machine learning-based anomaly detection, or pre-built integrations with other monitoring tools included at higher licensing tiers? - Clarify any value-added services, such as dedicated account support, proactive health checks, or best-practice workshops, that come with certain licenses.
2 Is your company willing to enter into contracts with a base year with up to four one-year options? If not, how many years is your company willing to agree to?
(For longer-term contracts, specify any guarantees on pricing, renewal terms, or opportunities to adjust the contract scope to accommodate potential changes in our data volume or monitoring requirements.)
Requirements Capability Sheet
| Palo Alto Twistlock ALTERNATIVE: | [PUT NAME HERE] | ||||
| Instructions: | Please select Y/N | Please select Y if Yes, N if no plans, or N/A if ready on day 1 | Please insert # of days from award to build capability or a date if known | Please insert comments, questions, or concerns for each requirement if needed | |
| Requirements: | Ready on Day 1 | Future Capability | Estimated date of Capability | Comments | |
| GENERAL | |||||
| 1 | Defends Kubernetes nodes | ||||
| 2 | Defends containers deployed via kubernetes | ||||
| 3 | Defends any node with an agent installed | ||||
| 4 | Blocking/preventing can be enabled for policies to actively stop suspected malicious activity or non-compliance | ||||
| 5 | Log scrubbing: optionally removes sensitive information from logs based on predefined rules and custom regex | ||||
| 6 | Automatically rescans assets based on defined hourly interval | ||||
| 7 | Alert profiles provide capability to send events to external handlers using custom webhooks to handlers requiring authentication | ||||
| 8 | Has REST API to configure application and provide reporting | ||||
| 9 | Policies can be written in the user interface or via API calls | ||||
| 10 | Policies can be scoped based on specific clusters, images, and namespaces (with wildcards) | ||||
| 11 | Events can be viewed and filtered in user interface | ||||
| 12 | Events can be downloaded as JSON | ||||
| 13 | RBAC with the ability to make custom roles for fine grained control | ||||
| 14 | Supports SSO / SAML logins | ||||
| 15 | API calls are logged for auditing purposes | ||||
| 16 | All policies report the last time they were modified and who modified them | ||||
| 17 | Is able to be deployed via Big Bang charts sourcing Iron Bank images |
| Runtime Security | |
| 1 | Uses ML to provide anomaly detection for deployed assets |
| 2 | Anomalies can be detected based on file, network, and process activity |
| 3 | Container models can be audited |
| 4 | Container models can be relearned on demand |
| 5 | Container models can be overridden by custom policy |
| 6 | Threat feeds update signature based malware detection |
| 7 | Suspicious Kubernetes behavior is alerted |
| 8 | Suspicious processes (started from modified binaries, SUID, reverse shell, etc) are alerted |
| 9 | DNS activity by domain, ports, and IP addresses can be whitelisted and blacklisted |
| 10 | Suspicious network activity is alerted (started from modified binaries, port scanning, etc.) |
| 11 | Web Application Firewall protects hosts and containers |
| 12 | Container runtime policies can be created based on runtime models |
| 13 | Custom runtime rules can be created in policies |
| 14 | Malware and Suspicious activity controls are customizable per policy |
| 15 | Provides event forensics (network connections, process information, file writes) |
| 16 | Hashes are reported for executed files |
| 17 | Events repeated at a high rate are aggregated |
| Vulnerability Analysis | |
| 1 | Scans container registries and reports on vulnerabilities |
| 2 | Registry scan scope can use specific image repos or GitLab group/project IDs within a registry |
| 3 | Scans deployed nodes and reports on vulnerabilities |
| 4 | Scans deployed images and reports on vulnerabilities |
| 5 | Vulnerability feed provides CVEs for operating system software and packages |
| 6 | Vulnerability feed provides advisories (pre CVE) for operating system software and packages |
| 7 | Vulnerability database can be inspected via UI or API to confirm if it has latest information regarding a concern |
| 8 | Can filter on and exclude base image vulnerabilities |
| 9 | Policy options for alerting include risk factors (e.g., available exploit POC, exploited in wild, severity, vendor fix available) |
| 10 | Policies can be set for individual packages that are commonly used |
| 11 | Policy exceptions (e.g., whitelisting) can be performed on an individual policy level |
| 12 | Policy exceptions (e.g., whitelisting) can be performed on a global level |
| 13 | Policy exceptions can be set with an expiration date |
| 14 | Policy exceptions include descriptions or can be linked to an external work ticket (e.g., Jira ticket or GitLab issue) |
| 15 | Reports all unpackaged binaries with their hashes |
| 16 | Reports all packages installed with their associated versions, file paths, and findings |
| 17 | Provides a full software inventory in a standard SBOM format (e.g., cyclone DX) |
| 18 | Prioritizes vulnerability issues based on risk factors (severity, complexity, vector, remove exec, fix available, exploit in wild, environmental and resource compliance factors) and percentage impacted resources |
| 19 | Provides risk score for resources |
| 20 | Reports vulnerabilities associated with each image layer |
| 21 | Reports images layer commands and dates |
| 22 | Reports image labels |
| 23 | Provides dashboard that highlights a prioritized list of concerns (findings, resources) and shows risk levels over time |
| 24 | Base image vulnerabilities can be excluded from reporting calculations |
| Compliance Scanning | |
| 1 | Policy sets are customizable down to the individual command run |
| 2 | Provides dashboard that highlights a prioritized list of concerns (findings, resources) and shows compliance levels over time |
| 3 | Reports all packages installed with their associated findings |
| 4 | Reports and alerts on untrusted assets in inventory (e.g., images) |
| HIGHLY DESIRED | |
| General | |
| 1 | Policies can be written declaratively (CaC) |
| Compliance Scanning | |
| 1 | Remediations required are clearly reported |
| DESIRED | |
| General | |
| 1 | Defends serverless and cloud |
| 2 | Defends multiple clusters / environments reporting to a single console |
| 3 | Alert profiles provide capability to send events to Jira |
| 4 | Ships metrics to prometheus for high level reporting and status |
| 5 | Policies can be scoped based on Kubernetes labels |
| 6 | Shows graphical view of all deployed resources with known network ports, and highlights issues |
| 7 | Reporting includes full Kubernetes hierarchy (Helm release, deployment, pod, containers) |
| 8 | Events can be exported to CSV |
| 9 | Supports multitenancy for centralized RBAC of multiple groups |
| 10 | All policies maintain a complete changelog history to include comments/justifications |
| Runtime Security | |
| 1 | Container models can be edited |
| 2 | Behaviorally scans malware in a sandbox |
| 3 | Forensics can be automatically forwarded to external handler (e.g., SIEM/SOAR) during detected incident |
| 4 | Forensics include full network capture (PCAP) |
| 5 | Correlates events to MITRE ATT&CK framework to aid in prioritization |
| 6 | Provides incident queue that includes forensic snapshots |
| 7 | Container filesystems can be browsed from the user interface and includes noted observables (permissions, size, name, executed, opened, used) |
| 8 | Noisy events can be immediately silenced for a selected duration (e.g., 1 hour, 1 day) |
| 9 | Temporarily suppressed events are clearly identified and can be audited |
| Vulnerability Analysis | |
| 1 | Provides a culled software inventory of files and packages observed to have been used |
| 2 | Risk score calculation is known and modifiable according to risk tolerance |
| 3 | Vulnerability dashboard factors in (can be filtered) risk factors of interest and software observed to be used |
| 4 | Includes CIS benchmarks and STIGs for kubernetes, docker containers, and operating systems |
| 5 | Includes appplication level STIGs |
| 6 | Can import compliance policy sets (i.e., benchmarks and STIGs) |
| 7 | Code changes (e.g., Docker file, helm chart, build script) required for remediations are reported |
| 8 | Scan results show the actual command ran during the check and its output |
| 9 | Can export data to eMASS |
Leave Blank
| Y | Y |
| N | N |
| N/A |
File details come from the government source that posted it. Updated .