RFI_Attach A TRD_TIES Final_47QFRA23K0002_09062023.xlsx
XLSX spreadsheet 114 KB Posted
- Attached to
- Request for Information for Threat Intelligence Enterprise Services (TIES) Federal contract opportunity
- Solicitation number
- 47QFRA23K0002
About this file
This document outlines platform requirements for a Threat Intelligence Enterprise Services (TIES) tool. The tool must support ingestion, enrichment, correlation, visualization, and sharing of cyber threat intelligence data from a variety of sources for multiple government tenants. It must integrate with security tools and data sources including SIEM, SOAR, EDR, firewalls, vulnerability databases, and network sensors. The tool architecture requires scalability, multi-tenancy, encryption of data at rest and in transit, and role-based access controls to segment data. The platform must provide APIs, custom workflows, alerting, and reporting functionality while adhering to data retention requirements.
View the file
Other files for this federal contract opportunity
| File | Type | Posted |
|---|---|---|
| RFI_Requirements Document_TIES Final_47QFRA23K0002_09062023.pdf | ||
| RFI_TIES Final_47QFRA23K0002_09062023.pdf |
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
read_me
| platform_reqs sheet | |
| This provides an overview of required functionality in the CTI tool. | |
| The text of the requirement is in column B. Column C provides additional detail to further describe the intent of the requirement. | |
| There are two priorities - MUST and SHOULD. These differentiate which requirements are part of the Minimum Viable Product (MVP), and which can be developed over time. | |
| MUST: | The CTI solution must perform this function as part of the MVP. These functions are the baseline capabilities that the solution is expected to perform. |
| For all requirements prioritized as MUST, additional evaluation criteria are provided in column D. These evaluation criteria will support evaluation of different vendor capabilities that meet the needs of the requirement. | |
| There are three ways these criteria are described: | |
| BINARY: | Vendor's ability to satisfy the requirement can be evaluated using binary, "meets/does not meet" criteria where requirements are more complex and require more nuanced evaluation, CORE and ENHANCED criteria are described. |
| CORE: | Describes essential vendor capabilities needed to meet requirement. A vendor that can meet the CORE capabilities needed for a requirement satisfies the baseline need described by that requirement. |
| ENHANCED: | Describes how a vendor's capabilities would be a differentiator and support functionality beyond the baseline need described by the requirement. |
| SHOULD: | The CTI solution should perform this function. The solution can operate without this capability, but this function is expected as part of the CTI tool roadmap and would need to be developed over time. |
| CTI User Interface and Collaboration (CTI-UIC-*): | This category provides an overview of tool functionalities, including collaboration needs, that should be available through a GUI. |
| CTI Generation (CTI-GEN-*): | This category & subcategories provide requirements for functionalities that support users in accessing, and gaining insight from, a broad array of CTI data types through capabilities for ingestion, export, enrichment, and tagging. |
| CTI-Generation-Data Collection (CTI-GEN-COL-*) | |
| CTI-Generation-Data Validation (CTI-GEN-VAL-*) | |
| CTI-Generation-Data Enrichment (CTI-GEN-ENR-*) | |
| CTI-Generation-Data Correlation (CTI-GEN-COR-*) | |
| CTI Visualization, Search, and Reporting (CTI-VIZ-*): | This category provides requirements for functionalities that support effective use of CTI data through search, query, and visualization capabilities. |
| CTI Sharing (CTI-SHR-*): | This category provides requirements for functionalities that support sharing of CTI between tenants and outside the CTI tool. |
| CTI Data Sources and Integrations (CTI-DSI-*): | This category provides requirements for functionalities that support ongoing user access to a comprehensive and current set of CTI data through capabilities for integrating, managing, and automating data from a wide variety of CTI data sources. |
| CTI Workflows and Alerting (CTI-WA-*): | This category provides requirements for functionalities that support the ability of user organizations to make timely and seamless use of CTI in their own tasking and decision-making processes. |
| Platform Architecture and Security (CTI-PAS-*): | This category provides requirements for system architecture and design that concurrently support secure operation, risk management, and future system growth. |
| Data Storage and Data Access (CTI-DSA-*): | This category provides requirements for functionalities that support secure storage and controlled access to data through encryption, data segmentation, and other capabilities. |
| User Identity and Authentication (CTI-IDA-*): | This category provides requirements for functionalities that support system security through multiple capabilities for limiting system access to authorized users. Included requirements also provide for customers to control access within their own organizations. |
| CTI Management-Alert & Event Management (CTI-MA-AEM-*): | This category provides requirements for functionalities that enable users to leverage CTI in alert generation and event investigation. |
platform_reqs
| New Requirement # | Requirement Text | Guidance | Evaluation Criteria | Priority |
| CTI-UIC-1 | The CTI tool shall provide a GUI interface for the management of and workflows associated with Cyber Threat Intelligence. | Capabilities that support CTI management and workflows include but are not limited to: data collection; data validation; data enrichment; data visualization, search, and reporting; data correlation; identity and access management; data sharing and collaboration; CTI workflows; and alert management. Interface includes the ability to collaborate with internal and external stakeholders on threat triage, analysis and response. Access to different functionality within the GUI will be granted/limited based on role- and attribute-based access controls. Additional specific requirements for elements made available in the GUI are captured in CTI-UIC-1, CTI-GEN-ENR-5-1, CTI-GEN-ENR-11, CTI-GEN-VAL-1-2, CTI-GEN-VAL-2-2, CTI-GEN-VAL-3, CTI-VIZ-1-1, CTI-VIZ-1-2, CTI-VIZ-1-3, CTI-VIZ-2-1, CTI-VIZ-3-1. Additionally, individual requirements throughout will state when a capability or feature is required as part of a GUI. |
Accessibility requirements include: universal design, inclusive language, alt text, color contrast, font display size, voiceover, zoom, full keyboard navigation, subtitles/captioning, ADA Web Accessibility Standards & Requirements, Web Content Accessibility Guidelines (WCAG).
| GUI design best practices include: preservation of context, protection user work, feedback to user in response to actions performed by user (i.e., buttons), visible system status, informative and actionable error messages | BINARY: The CTI tool must provide users with an interface that supports tool functionality. This includes ability to manage data ingestion, manually upload data, build visualizations and dashboards, search and query existing data, represent data in different formats as required, perform analyses and capture notes, enrichment, and context associated with data in the tool, and provide the ability for collaboration with other users of the tool. Access to different functionality within the GUI can be granted/limited based on role- and attribute-based access controls. | MUST | ||
| CTI-GEN-COL-1-1 | The CTI tool shall ingest CTI data from both internal and external data feeds automatically. | External data feeds includes from AIS feeds, other open source feeds, ISACs and ISAOs, commercial intelligence providers, and other CTI Exchange Platforms. This capability must support ingestion of incident data and indicator data. The CTI tool shall allow for tenants to configure internal IT security, SIEM, endpoint protection and management, and network tools to automatically feed data into their tenant for analysis alongside data that comes from 3rd party sources. These internal integrations are likely to vary across tenants, and must be configurable on a tenant-by-tenant basis. See DSI-7 for additional known required integrations that inform functionality needed from this requirement. | CORE: The CTI tool automatically ingests data from AIS feeds, ISACs, ISAOs, commercial intelligence providers, and other CTI Exchange Platforms. The CTI tool must also support ingestion of incident and indicator data from common sources (e.g. TAXII servers, other CTI tools). The CTI tool automatically ingests data from common internal sources (e.g. EDR, firewall, SASE, etc.) | |
| ENHANCED: The CTI tool automatically ingests data from uncommon sources (e.g. social media, RSS, email, custom tools etc.) | MUST | |||
| CTI-GEN-COL-1-2 | The CTI tool shall include the ability to manually import data from both internal and external sources. | Manual ingestion supports ad hoc ingestion of relevant external and internal data sources. This will include the ability to do bulk uploads of thousands of individual IOCs. Incident data may also require manual import. Manual ingestion supports ad hoc ingestion of relevant internal data sources. Manual ingestion will include the ability to do bulk uploads of thousands of individual IOCs. Incident data may also require manual import. | CORE: The CTI tool provides the analyst with at least one path to upload IOCs and other data from external sources (e.g. copy and paste into a GUI, file upload, API). | |
| ENHANCED: The CTI tool provides the analyst with all possible paths to upload IOCs and other data from external and internal sources (e.g. copy and paste into a GUI, file upload, API). | MUST | |||
| CTI-GEN-COL-1-3 | The CTI tool shall include the capability to do customizable polling of both internal and external data feeds. | This polling will be able to occur at customizable periodicities, and allows an analyst to fetch new data from across all data feeds. | CORE: The CTI tool provides the analyst with at the ability to set polling times for each data feed and the ability to fetch new data from across all data feeds. | |
| ENHANCED: The CTI tool provides the analyst with easy access to poll all feeds for new information on-demand. | MUST | |||
| CTI-GEN-COL-2-1 | The CTI tool shall have the ability to automatically parse Cyber Threat Intelligence data from structured data sources. | This includes data ingested from databases or connections to an API. | CORE: Ability to parse and ingest from databases and conventional API (e.g., SQL, REST API). | |
| ENHANCED: Ability to parse and ingest from custom data sources. | MUST | |||
| CTI-GEN-COL-2-2 | The CTI tool shall have the ability to automatically parse Cyber Threat Intelligence data from semi-structured data sources. | Semi-Structured formats include XML, JSON, and standards including but not limited to STIX 1.x, STIX 2.x , OpenIOC, CybOX , IODEF, custom. Other formats include HTTPS, REST API, RSS, email, SFTP, shared folders (SMB), YAML, CSV, TSV, PDF, DOCX, TXT, YARA rules, Sigma rules, Zeek signatures, Snort signatures, and Suricata Signatures, etc. |
| Supports CIRCIA REQs # 6,10,13,15,18,19,90,91 & IRWG REQs # 96,97,110, 112, 114, 115, 116 | CORE: Ability to parse and ingest XML, JSON, STIX 1.x, STIX 2.x , OpenIOC, CybOX , IODEF , custom, CSV data, YARA rules, Sigma rules, Zeek signatures, Snort signatures, and Suricata Signatures. | ||
| ENHANCED: Ability to parse and ingest HTTPS, RSS, email, SFTP, shared folders (SMB), YAML, TSV, PDF, DOCX, and TXT data. | MUST | ||
| CTI-GEN-COL-2-3 | The CTI tool shall have the ability to automatically parse Cyber Threat Intelligence data from unstructured data sources. | This includes PDF, WORD, EXCEL, emails, free text, browser plugins, social media, etc. The ability to intake data, such as characteristics and attributes, from other common CTI lifecycle tools like Analyst Notebook and Maltego is required. |
Natural Language Processing (NLP) capabilities are expected as part of this capability.
Optical Character Recognition (OCR) capabilities are expected as part of this capability
| Supports CIRCIA REQs # 6,10,13,15,18,19,90,91 & IRWG REQs # 96,97,110, 112, 114, 115, 116 | CORE: Ability to parse and ingest data from PDF, WORD, EXCEL, emails, free text, browser plugins, Twitter. | |||
| ENHANCED: Uses advanced Natural Language Processing (NLP) and Optical Character Recognition (OCR) to parse the data. | MUST | |||
| CTI-GEN-COL-3-1 | The CTI tool shall automatically assign scores and apply automated tagging/marking to Cyber Threat Intelligence data as it is ingested. | Data scoring gives analysts a summary that helps them evaluate individual pieces of data. Tags provide important context that further supports analyst prioritization of data that will be useful and relevant to their current intelligence work/investigative needs. These data scores/tags/markings will be able to be added at the attribute, event, source, or feed level. | CORE: Automatically assigned scores are on a per feed basis or the data is provided by the data feed. Applies tags/markings based upon information given to them from the feed. | |
| ENHANCED: Automatically assigned scores are on a per data element basis and the scores are generated or amended by the tool. Applies tag/markings based upon ML/AI models. | MUST | |||
| CTI-GEN-COL-3-2 | The CTI tool shall automatically assign a confidence score to each data point as it is ingested. | The confidence score describes how much value an analyst will put into the CTI data, based on a judgement of its reliability. This score may be calculated based on, for example: past reliability of the data source, number of data sources that contain the same IOC. |
| The variables used in score calculation will be flexible to incorporate methodology changes, as the prioritization approach may change over time. | CORE: Automatically assigned confidence scores are on a per feed basis or the data is provided by the data feed. The score is likely based on static data elements. | ||
| ENHANCED: Automatically assigned confidence scores are on a per data element basis and the scores are generated or amended by the tool. The score is likely derived by a ML/AI model. | MUST | ||
| CTI-GEN-COL-3-3 | The CTI tool shall automatically assign a severity score to each data point as it is ingested. | The severity score describes how much damage the CTI data has the potential to cause to the agency. Severity may be judged based on, for example: whether the CTI data point applies to any of an agency's designated high value assets, estimate of scale of disruption caused by the threat. | |
| The variables used in score calculation will be flexible to incorporate methodology changes, as the prioritization approach may change over time. | CORE: Automatically assigned severity scores are on a per feed basis or the data is provided by the data feed. The score is likely based on static data elements. | ||
| ENHANCED: Automatically assigned severity scores are on a per data element basis and the scores are generated or amended by the tool. The score is likely derived by a ML/AI model. | MUST | ||
| CTI-GEN-COL-3-4 | The CTI tool shall automatically assign a relevance score to each data point as it is ingested. | The relevance score communicates how the IOC is situated within the attack surface of interest. Relevance score can be determined based on, for example: whether the IOC is potentially present within an the attack surface of concern based on existence of specific infrastructure or vendor products; recency of certain types of IOCs. | |
| The variables used in score calculation will be flexible to incorporate methodology changes, as the prioritization approach may change over time. | CORE: Automatically assigned relevance scores are on a per feed basis or the data is provided by the data feed. The score is likely based on static data elements. | ||
| ENHANCED: Automatically assigned relevance scores are on a per data element basis and the scores are generated or amended by the tool. The score is likely derived by a ML/AI model. | MUST | ||
| CTI-GEN-COL-4-1 | The CTI tool shall store the collected Cyber Threat data in a common structured format. | Upon ingestion, the CTI tool will parse data where possible into a structured format in order to apply validation and the first level of data enrichment. This structured storage format helps analysts navigate the volume of data ingested into the tool. |
| The subrequirements for CTI storage in a structured format align with the latest STIX standard, but the CTI tool is required to be interoperable with other CTI standards. Custom fields will also be accepted as part of structured formats. See CTI-DSI-5-1 and CTI-DSI-5-2 for requirements on interoperability between standards. | CORE: The CTI data from structured sources with appropriate marking is assigned the correct data categories and retains all relevant information. Requires minimal analyst validation. Custom fields are accepted as part of structured data. Structured format must align with the latest STIX standard and be interoperable with other CTI standards. | |
| ENHANCED: The CTI data from semi-structured and unstructured sources with appropriate marking is assigned the correct data categories and retains all relevant information. Requires minimal analyst validation. | MUST | |
| CTI-GEN-COL-4-2 | The CTI tool shall have the ability to parse CTI and distill the information into STIX 2.1 Domain Objects, including: |
Attack Pattern Campaign Course of Action Grouping Identity Indicator Infrastructure Intrusion Set Location Malware Malware Analysis Note Observed Data Opinion Report Threat Actor Tool Vulnerability These data categories correspond with STIX 2.1 Domain Objects and are defined as follows:
Attack Pattern: A type of TTP that describe ways that adversaries attempt to compromise targets.
Campaign: A grouping of adversarial behaviors that describes a set of malicious activities or attacks (sometimes called waves) that occur over a period of time against a specific set of targets.
Course of Action: A recommendation from a producer of intelligence to a consumer on the actions that they might take in response to that intelligence.
Grouping: Explicitly asserts that the referenced CTI data have a shared context.
Identity: Actual individuals, organizations, or groups (e.g., ACME, Inc.) as well as classes of individuals, organizations, systems or groups (e.g., the finance sector).
Indicator: Contains a pattern that can be used to detect suspicious or malicious cyber activity.
Infrastructure: Represents a type of TTP and describes any systems, software services and any associated physical or virtual resources intended to support some purpose (e.g., C2 servers used as part of an attack, device or server that are part of defense, database servers targeted by an attack, etc.).
Intrusion Set: A grouped set of adversarial behaviors and resources with common properties that is believed to be orchestrated by a single organization.
Location: Represents a geographic location.
Malware: A type of TTP that represents malicious code.
Malware Analysis: The metadata and results of a particular static or dynamic analysis performed on a malware instance or family.
Note: Conveys informative text to provide further context and/or to provide additional analysis not contained elsewhere.
Observed Data: Conveys information about cyber security related entities such as files, systems, and networks.
Opinion: An assessment of the correctness of the information in a report produced by a different entity.
Report: Collections of threat intelligence focused on one or more topics, such as a description of a threat actor, malware, or attack technique, including context and related details.
Threat Actor: Actual individuals, groups, or organizations believed to be operating with malicious intent.
Tool: Legitimate software that can be used by threat actors to perform attacks.
| Vulnerability: A mistake in software that can be directly used by a hacker to gain access to a system or network. | CORE: The CTI data from structured sources with appropriate marking is assigned the correct data categories and retains all relevant information. Requires minimal analyst validation. The parsed CTI data categories at a minimum must include: Attack Pattern, Campaign, Course of Action, Grouping, Identity, Indicator, Infrastructure, Intrusion Set, Location, Malware, Malware Analysis, Note, Observed Data, Opinion, Report, Threat Actor, Tool, and Vulnerability. | ||
| ENHANCED: The CTI data from semi-structured and unstructured sources with appropriate marking is assigned the correct data categories and retains all relevant information. Requires minimal analyst validation. | MUST | ||
| CTI-GEN-COL-4-3 | The CTI tool shall be able to show/assign additional context by including relationship data. | These data categories correspond with STIX 2.1 Relationship Objects and are defined as follows: |
Relationship: Used to link together two components of CTI in order to describe how they are related to each other.
| Sighting: Denotes the belief that something in CTI (e.g., an indicator, malware, tool, threat actor, etc.) was seen. | CORE: The CTI data from structured sources with appropriate marking is assigned the correct data categories and retains all relevant information. All relationships are maintained. Requires minimal analyst validation. Data categories include relationships and sightings. | ||
| ENHANCED: The CTI data from semi-structured and unstructured sources with appropriate marking is assigned the correct data categories and retains all relevant information. All relationships are maintained. Requires minimal analyst validation. | MUST | ||
| CTI-GEN-COL-4-4 | The CTI tool shall be able to parse and store cyber data objects and associated metadata. | The ability to parse these objects allows for analyst interaction with specific indicators that will be present in data ingested into the tool. The tool will be able to parse and store the following cyber data objects: |
Artifact Autonomous System (AS) Directory Domain Name Email Address Email Message File IPv4 Address IPv6 Address MAC Address Mutex Network Traffic Process Software
URL
User Account Windows™ Registry Key X.509 Certificate CORE: The CTI data from structured sources with appropriate marking is assigned the correct data categories and retains all relevant information. Requires minimal analyst validation. The CTI tool shall at a minimum be able to parse the following fields: Artifact Autonomous System (AS), Directory, Domain Name, Email Address, Email Message, File, IPv4 Address, IPv6 Address, MAC Address, Mutex, Network Traffic, Process, Software, URL, User Account, Windows™ Registry Key, and X.509 Certificate
| ENHANCED: The CTI data from semi-structured and unstructured sources with appropriate marking is assigned the correct data categories and retains all relevant information. Can store custom artifacts. Requires minimal analyst validation. | MUST | ||
| CTI-GEN-COL-4-5 | The CTI tool shall be able to tag specific data elements, groups of data elements, and entire reports according to industry standards. | Standards for applying security markings to data must be supported by functionality within the tool. Data tagging within the tool will be able to support security marking requirements. The ability to tag data according to specific protocols supports analysts' ability to quickly make decisions on access and sharing requirements. The tool will be able to utilize the following: |
Traffic Light Protocol (TLP) Permissible Action Protocol (PAP) Information Exchange Protocol (IEP) Access Control Specifications (ACS) Automated Indicator Sharing (AIS) Terms of Use
| Custom | CORE: Ability to mark entire reports with the TLP, PAP, IEP, ACS, and AIS information or terms of use information or custom information. | ||||
| ENHANCED: Ability to mark down to the data element level. Has all marking standards. | MUST | ||||
| CTI-GEN-VAL-1-1 | The CTI tool shall validate all incoming data automatically. | The CTI tool will support automating the process of checking data for quality and accuracy before it is presented to users for additional enrichment and contextualization (e.g., date fields contain dates, IP address fields contain valid IP addresses, etc.). Whenever possible, machine-based processes for data validation will be supported for implementation. | BINARY: All incoming CTI data is validated. | MUST | |
| CTI-GEN-VAL-1-2 | The CTI tool shall provide a GUI that presents the raw report indicating fields that failed data validation. | The CTI tool shall support automating the process of checking data for quality and accuracy before it is presented to users for additional enrichment and contextualization. Whenever possible, machine-based processes for data validation should be supported for implementation. | CORE: Provides analyst with a GUI interface with a side by side view of the raw report and the processed data to support the preservation of the chain of custody associated with the data | ||
| ENHANCED: Identifies likely places where the tool has parsed incorrectly and displays it to the user. | MUST | ||||
| CTI-GEN-VAL-1-3 | The CTI tool shall support the ability to edit incorrect or missing CTI data post-ingestion. | See CTI-GEN-VAL-1-1 and CTI-GEN-VAL-1-2. | CORE: Allows the analyst to edit/create data in the side-by-side view as the analyst is performing the validation. | ||
| ENHANCED: Provides assistance in editing data to speed up the editing of the CTI data (e.g. Tool miss assigns a column in excel to "Campaign" instead of "Indicator". Analyst changes one row. Tool asks the analyst if they want to change the designation for all rows.) | MUST | ||||
| CTI-GEN-VAL-1-3.1 | The CTI tool shall provide a log of changes associated with processed data. | The tool will provide an audit trail of information that was added and is visible to users. | BINARY: The tool logs all changes and those changes are visible to users. | MUST | |
| CTI-GEN-VAL-2-1 | The CTI tool shall allow manual data validation by analysts. | The CTI tool will support the process of checking data for quality and accuracy before it is presented to users for additional enrichment and contextualization. | CORE: The CTI tool shall support the process of checking unstructured data for quality and accuracy before it is presented to users for additional enrichment and contextualization. Little data is automatically processed and most is done with analyst collaboration | ||
| ENHANCED: Most data is automatically parsed. Little is done with analyst collaboration. | MUST | ||||
| CTI-GEN-VAL-2-2 | The CTI tool shall allow an analyst to add contextual data to relevant CTI data. | The CTI tool will support the ability to add contextual information to CTI data that may have been sourced from other reports or that was found during an incident | CORE: Provides analyst with a GUI to add contextual information to a report during validation. | ||
| ENHANCED: Automatically correlates and suggests contextual information for the analyst to add. | MUST | ||||
| CTI-GEN-VAL-3 | The CTI tool shall reduce false positives. | This capability is needed to help reduce analyst workload around false positives that are often extracted from reports (e.g. the IP addresses from managed/public DNS providers showing up repeatedly as a malicious indicator.) Access to this capability will be highly restricted due to the implications of labeling a certain IOC as non-malicious. It is desirable if the tool is able to incorporate the deny-list and leverage it to improve data processing over time in a manner that reduces false positives extracted from data sources. The CTI tool will provide analysts with the ability to create a deny-list of IOCs that are understood to be non-malicious but still may show up in threat reporting. IOCs flagged as being part of the deny-list will still be visible to users within the GUI with an indication that it is a low-priority/low-confidence indicator. | CORE: Analyst can create a list of IOCs that will be marked as non-malicious and will be viewed during validation as a low confidence indicator. | ||
| ENHANCED: CTI tool suggests IOC additions to the list based upon a AI/ML model. | MUST | ||||
| CTI-GEN-VAL-4 | The CTI tool shall automatically de-duplicate threat information. | As data is ingested it will be validated to ensure that adding this information is adding new information and is not an exact duplicate of the same information. The CTI tool will have the ability to distinguish between duplicate data that is a new sighting and a repeat of data from different data sets. | CORE: Alerts an analyst to a duplicate IOC unless it is a new sighting in which case it updates the sighting information. | ||
| ENHANCED: Identifies non-exact matches with no value add in the new information. | MUST | ||||
| CTI-GEN-ENR-1 | The CTI tool shall automatically enrich Cyber Threat Intelligence data when ingested. | Data enrichment provides additional context on data taken in from multiple sources, and supports decision-making and situational awareness. Enrichment supports threat analysis, filtering, scoring, cross-correlation, and context development. |
| Automated enrichment will include but is not limited to: Whois, DNS, PassiveDNS, malware intelligence, sandbox, PassiveSSL. | CORE: Automated enrichment includes the required data sources for enrichment. Enrichment is always accurate. Enrichment is based on predefined correlation. | |||
| ENHANCED: Automated enrichment includes additional data sources for enrichment. Enrichment is based upon predefined rules and AI/ML correlation. | MUST | |||
| CTI-GEN-ENR-2 | The tool shall allow for specifying logic rule(s) that govern the application of enrichment data to the CTI data as it is ingested. | Because the enrichment data will change over time, these rules will be able to be changed/created on an ad-hoc basis. Enrichment modules will be extensible to meet ongoing changes in mission needs/guidance. The tool will provide the capability of using custom vocabularies (e.g. for TTPs and threat actors.) | CORE: Provide analysts with a rule framework that can add enrichment information. | |
| ENHANCED: Additionally, provide templates for common enrichment information. | MUST | |||
| CTI-GEN-ENR-3 | The CTI tool shall provide a platform for analysts to add enrichment information. | Enrichment information includes analysis associated with the data, representations of priority/confidence of an analysis or an IOC. The CTI tool will be able to conduct the aforementioned enrichment as a built-in capability or via integration with enrichment services including whois, DNS, PassiveDNS, PassiveSSL, malware intelligence and repositories, sandbox, geolocation, reputation services, public information leaks, darkweb related datasets, honeypots services, OSINT services, ASN information, vulnerability intelligence, etc. | CORE: Provides a platform for analysts to add enrichment information to CTI. | |
| ENHANCED: Provides suggestions to analysts about data sources that may be useful to use. | MUST | |||
| CTI-GEN-ENR-4 | The CTI tool shall have the ability for the system to automatically assign enrichment tags to CTI. | Additional information across multiple dimensions associated with data and CTI will be communicated via tags. These tags provide context on the data, and allow for data to be more easily searched, surfaced, and used by all users of the CTI tool. |
| Examples of types of automated tags include provenance, date/time, critical infrastructure sector (based on source of information). The ability to apply additional automatic tagging to communicate other details, such as IOCs, TTPs, and threat actor details, is also desirable. The types of desired automatic tags is anticipated to change over time, and the platform will allow flexibility to specify automatic tagging. | CORE: Automated tagging includes the required data elements for tags. Tagging is always accurate. Tagging is based on predefined rules. | |
| ENHANCED: Automated tagging includes additional data sources for tags. Tagging is based upon predefined rules and ML correlation. | MUST | |
| CTI-GEN-ENR-5-1 | The CTI tool shall provide a platform for analysts to manage tags for Cyber Threat Intelligence data via a GUI interface. Categories of required tags include: |
System Tags – attributes associated to the data by the system User Tags – attributes associated to the data by the user Multi-Tags – the ability the apply multiple tags to data Auto-tagging – the ability to add tags to data based on a set of user/system rules Tagging rule management – the ability to create/save/edit/delete tags Tagging hierarchy – the ability to nest tags as children and descendants of other tags The platform will have an ever-expanding list of required data tags. New tags need to be able to be created dynamically.
Actions for managing tags include:
Mass editing, or "find and replace" functionality for updating tags across many pieces of CTI, is necessary.
Apply and save tags to data, and these tags will persist when viewed by other users of the platform.
| Deletion of tags. This includes the ability to mass remove a certain tag wherever it is applied. | CORE: Provides a platform for analysts to add and remove tags to CTI. | ||||
| ENHANCED: Provides suggestions to analysts about tags that may be appropriate to apply. | MUST | ||||
| CTI-GEN-ENR-5-2 | The CTI tool shall provide the ability for analysts to create their own tags that designate data elements (and related hierarchies) and to have these tags be visible to only that analyst by default, or shared with a selected audience of other users. | Ongoing mission needs inform the need for a sandbox-like ability to define tags and data elements on an ongoing basis and have these used just by an individual analyst or within a shared group. | CORE: Ability to create and manage custom tags. Specified tags should only be shared with users as instructed by the author. | ||
| ENHANCED: Ability to manage all data enrichment sharing at a user level. | SHOULD | ||||
| CTI-GEN-ENR-6-1 | The CTI tool shall allow for specifying logic rule(s) that govern the application of tags to CTI data. | Rule frameworks for tag application provide a layer of human control and oversight to how tags are applied to data. This functionality is critical in order to comply with data sharing and handling protocols, such as TLP, PAP, IEP, and ACS. Because the list of necessary tags will change over time, these rules will be able to be changed/created on an ad-hoc basis. The tool will allow for specifying logic that governs the application of tags to data to ensure conflicting information is not communicated through tags. For example, one raw IOC will not be tagged with multiple TLPs, but one finished intel product might have multiple TLPs embedded in the data it contains. | CORE: Provide analysts with a rule framework that can apply tags automatically. | ||
| ENHANCED: Additionally, provide templates for tags. | MUST | ||||
| CTI-GEN-ENR-6-2 | The CTI tool shall provide predefined system logic rules for automated tagging of Cyber Threat Intelligence data. | The tool will have system rules on how tags are automatically applied to data. Initial desired capability includes the option to automatically tag data according to the latest STIX standard. The types of desired automatic tags is anticipated to change over time, and the platform will allow flexibility to specify rules on the how tags will be automatically applied. | BINARY: Predefined system rules for tagging information. | MUST | |
| CTI-GEN-ENR-6-3 | The CTI tool shall allow for customizeable logic rule(s) that govern the application of tags to CTI data. | This tool will have an expanding user base and a growing list of data sources with which it will integrate. Accordingly, the tool will allow for creation of new types of automated tagging rules in order to accommodate new data feeds and new categories of information. |
Existing tagging rules will be editable to allow for further refinement of how tags are applied to data.
Tagging rules will be saved and persist across data sources as needed.
| The tool must allow for tagging rules that are no longer needed to be deleted. | CORE: Provides a platform for analysts to create rules that will automatically assign tags to data. Tagging rules have the ability to persist across data sources, and can be edited/deleted. | ||||
| ENHANCED: Provides suggestions to analysts about rules that may be appropriate to create. | MUST | ||||
| CTI-GEN-ENR-6-4 | The CTI tool shall support tagging data according to data sensitivity, and those tags should serve to restrict the data's visibility in the CTI tool accordingly. | Data tags within the tool will support marking information according to, for example, TLP. Other marking standards (such as IEP and PAP) will be supported, and the tool will allow for flexibility to adjust data sensitivity tagging in order to comply with updated/revised policies over time. These tags will inform how data is shared within the tool as well. See CTI-SHR-3-4. | CORE: Automatically assigns tags that communicate information based upon the data sensitivity based upon the threat feed. Manual assignment is necessary for data that was not marked when ingested. | ||
| ENHANCED: Automatically assigns marking information based upon the data sensitivity for all data. Whether based on the threat feed or upon a ML model. | MUST | ||||
| CTI-GEN-ENR-6-5 | The CTI tool shall allow an analyst to import a file (.csv or Excel) that defines data types and tags. | To allow for flexible ingestion pipeline capability, users will have the ability to define their data elements and types in a CSV or spreadsheet, and to apply those data elements/tags to ingested data. These data types and tags will then be available for use in automated tagging workflows and/or applied to data manually by an analyst in the GUI. | BINARY: Meets requirement if an analyst can upload a file with data type and data tag definitions. Those definitions should be available for use in rule frameworks. | MUST | |
| CTI-GEN-ENR-7 | The CTI tool shall allow for multiple tags to be applied to Cyber Threat Intelligence data. | The tool must support one to many relationships between a piece of data and tags applied to it - multiple tags must be able to be applied to a single piece of data. Examples of desired information to be captured by tags includes: Campaigns, TTPs, internal operations, engagement (TLP), MITRE ATT&CK, DIAMOND analysis. For mission and internal reporting associations, attaching a specific indicator to an ATT&CK TTP, placing a specific vulnerability into the ATT&CK framework, and attaching a specific indicator to a threat actor are required. |
| Particularly with TLP tags, the possibility of multiple levels of sensitivity within a single intelligence product exists. The SOW outlines expectations regarding access controls. Please also see CTI-GEN-ENR-6-4. | BINARY: Meets requirement if the CTI tool allows for multiple tags to be applied to the same data element. | MUST | |
| CTI-GEN-ENR-8 | The CTI tool shall provide the ability to nest tags as children/descendants of other tags. | The tool will allow for the creation of a tagging hierarchy, that establishes relationships between tags so that some tags can be indicated to be nested within one another. Significant flexibility in creating and editing these relationship hierarchies will be required over time to keep pace with the operational environment. |
| One example of required functionality is the ability to group individual threat actors together as "children" under an overarching "parent" category (for example, under a single nation state) so that searches for the parent category will yield results associated with all the children. It is also desirable to be able to use this functionality to indicate where relationships between two tags is conflicting, and to have the tool prevent application of conflicting tags to a single piece of data. | CORE: Meets requirement if the CTI tool allows for tags have relationships with one another (e.g. children of tags). | ||
| ENHANCED: Automatically assigns appropriate relationships to tags. | SHOULD | ||
| CTI-GEN-ENR-9-1 | The CTI tool shall include tags that communicate sharing/sensitivity for CTI data ingested into the tool. | The tool will allow both automated and manual means of assigning data markings through tags. Security markings must align with at least the following standards: |
Traffic Light Protocol (TLP) Permissible Action Protocol (PAP) Information Exchange Protocol (IEP)
| Access Control Specifications (ACS) | CORE: Provides a platform to add and remove tags to CTI. | ||||
| ENHANCED: Provides suggestions to analysts about tags that may be appropriate to apply. | MUST | ||||
| CTI-GEN-ENR-9-2 | The CTI shall automatically assign sharing/sensitivity marking tags to data where security markings are not explicitly provided. | The tool will pull the marking from the data as ingested if applicable. If no data markings are found, the tool could use AI/ML models to provide data marking based upon similar information within the tool. | CORE: Automatically assigns tags that contain marking information based upon the data sensitivity. Manual assignment is necessary for data that was not marked when ingested. | ||
| ENHANCED: Automatically assigns marking information based upon the data sensitivity for all data, whether based on the threat feed or upon a ML model. | MUST | ||||
| CTI-GEN-ENR-9-3 | The CTI tool shall allow an analyst to design customizeable logic rules for applying sharing/sensitivity marking tags to data based upon the information available at ingestion. | The tool will use fields such a threat actor, threat feed, to provide marking information in an automated way. | CORE: Provides a platform for analysts to create rules that will automatically assign marking tags to data. Tagging rules have the ability to persist across data sources, and can be edited/deleted. | ||
| ENHANCED: Provides suggestions to analysts about rules that may be appropriate to create. | MUST | ||||
| CTI-GEN-ENR-9-4 | The CTI tool shall allow an analyst to manually edit sharing/sensitivity marking tags. | Analysts can edit sharing/sensitivity marking tags where the data has already been marked in either an automated or manual method. Additional pieces of information or other events may prompt an analyst to revisit a marking applied to data. Analysts will be able to adjust markings as more context is applied to a piece of CTI. | CORE: Provides a platform for analysts to add and remove tags to CTI. | ||
| ENHANCED: Provides suggestions to analysts about tags that may be appropriate to apply. | MUST | ||||
| CTI-GEN-ENR-9-5 | The CTI tool shall track changes to tags. In addition to tracking changes, a justification for the change shall be captured. | The tool will allow for checks and balances when certain types of tags (such as those that designate data security) are changed or revised. When an analyst makes a manual edits to a tag that designates data classification, the tool will prompt them to enter in a justification for this change. The tool will track these changes. It is desirable to have the tool supply some common reasons a tag might be changed (for example, "changed due to incorrect automatic tagging"), and to use that information to improve over time. | CORE: The tool allows for specification of tags that cannot be changed without capturing a justification. When an analyst changes a tag applied to a piece of data, the tool prompts them to enter in a justification for the change. All of these changes are tracked over time and can be viewed and audited. | ||
| ENHANCED: The tool supplies a customizable list of reasons a tag might be manually edited, and can demonstrate how this information is captured and used to improve automated tagging and other relevant functionality over time. | MUST | ||||
| CTI-GEN-ENR-10-1 | The CTI tool shall allow for specifying logic rule(s) that govern the scoring of reports and data. | To aid in sensemaking and prioritizing action on data contained within the CTI tool, various dimensions of report and data scoring are required. GEN-COL-3-1, GEN-COL-3-2, GEN-COL-3-3, GEN-COL-3-4 provide guidance for automated scoring requirements that inform first level prioritization of information ingested into the CTI tool. Analysts working within the tool will have the ability to revisit and revise automatically assigned scores, and will be able to assign scores to reports and data that are not automatically parsed and scored upon ingestion. The framework for scoring reports and data will be able to be created at the tenant level, to allow an individual agency to customize the tool according to their own priorities with respect to CTI data. | BINARY: Meets requirement if the platform provides a framework for scoring for data elements and in reports. Individual tenants can customize the default way that scoring is applied to data and reports. | MUST | |
| CTI-GEN-ENR-10-2 | The CTI tool shall provide predefined system logic rules for automated scoring of Cyber Threat Intelligence data. | GEN-COL-3-1, GEN-COL-3-2, GEN-COL-3-3, GEN-COL-3-4 provide guidance for automated scoring requirements that inform first level prioritization of information ingested into the CTI tool. To provide additional prioritization based on the analyst's needs, additional automated rules may be applied (for example, CTI associated with a particular attack type are always scored highly for certain users.) | BINARY: Predefined system rules for automated scoring of information. | MUST | |
| CTI-GEN-ENR-10-3 | The CTI tool shall allow for customizable logic rule(s) that govern the automated scoring of Cyber Threat Intelligence data. | Given the different priorities and perspectives of analysts, the ability to customize scoring is required. For example, an analyst focused on activity related to a specific threat actor may have different prioritization requirements than an analyst who prioritizes looking at information associated with a particular target, such as a critical infrastructure sector. | CORE: Provides a platform for analysts to create rules that will automatically assign scores. | ||
| ENHANCED: Provides suggestions to analysts about rules that may be appropriate to create. | MUST | ||||
| CTI-GEN-ENR-10-4 | The CTI tool shall allow an analyst to apply/change the score of Cyber Threat Intelligence data. | Additional pieces of information or other events may prompt an analyst to revisit a score applied to data. Analysts will be able to adjust scoring as more context is applied to a piece of CTI. | CORE: Allow an analyst to add a score or change a score within the data. | ||
| ENHANCED: Provide an analyst with suggestions of scores that should be reviewed. | SHOULD | ||||
| CTI-GEN-ENR-10-5 | The CTI tool shall allow for confidence score on reports to be captured and displayed to users viewing finished intelligence reports. | Confidence scoring on reports may be represented by data that has surfaced across multiple sources known to be reliable in the past, data that corresponds with confirmed activity "on the ground" in operational environments. | BINARY: Meets requirement if the platform allows for confidence scores (including supporting logic for the score assigned) to be shown to users in GUI and on intelligence reports. | MUST | |
| CTI-GEN-ENR-10-6 | The CTI tool shall allow for severity/priority scores to be captured and displayed on finished intelligence reports as well as on individual IOCs. | Prioritization scores help analysts know where CTI data will prompt action and in what order. For example, certain IOCs with short shelf lives are a priority when first discovered to enable immediate update of network defense tools. For IOCs associated with a threat actor known to be targeting certain sectors, these IOCs will be flagged as high priority/requiring quick action. Another example: if it is detected that vulnerability that is being actively exploited, but that vulnerability is not currently on the CISA's Known Exploited Vulnerability list, it will be flagged as high priority. | BINARY: Meets requirement if the platform allows for severity/priority scores to be shown to users in GUI and on intelligence reports. | MUST | |
| CTI-GEN-ENR-10-7 | The CTI tool shall display clear indications of impact and relevance of data sources. | Analysts using the CTI tool require the ability to evaluate data sources in their CTI work. The tool will provide features that make it straightforward to access, view, and evaluate data sources. Within the tool, an analyst will be able to readily access information such as how current a given data set is, a measure of accuracy (e.g. have the same IOCs appearing in other datasets recently). | BINARY: Meets requirement if the platform allows for relevance scores to be shown to users in GUI and on intelligence reports. | MUST |
| CTI-GEN-ENR-11 | The CTI tool shall provide a GUI interface for the management of enriching Cyber Threat Intelligence data. | Data tags are, mostly, metadata. CTI information, such as IOCs, TTPs, and threat actor profiles, will be tagged with additional information to provide context on the data that allows for it to be more easily surfaced and used by all users of the CTI tool. | CORE: All features described in CTI-GEN-ENR are available through the GUI interface. The GUI is 508 compliant. |
| ENHANCED: GUI is intuitive and reduces time for the analyst workflow. | MUST | ||
| CTI-GEN-COR-1 | The CTI tool shall allow for linkages and correlations to be made across datasets, so that relationships between vulnerabilities, campaigns, actors/groups, and reported activities can be captured in the tool throughout the lifecycle of CTI data. | The level of situational awareness enabled by the CTI tool will be driven in large part by its ability to enable analysts to make connections across different datasets - for example, vendor reports on a threat actor, incident reports containing TTPs associated with a threat actor, and examples where an organization's security controls were effective in blocking TTPs associated with a threat actor. Taking into account the complexity of the cyber domain, the tool will be able to (automatically) link brand new data to already existing data. |
When an analyst is investigating an event, the CTI tool will provide linkages to historical data relevant to the current investigation. The tool should have native functionality that assists analysts in finding information that is relevant and high priority. The analyst should have the ability to check multiple data sources against one another to increase confidence in a piece of information, ability to indicate what data points or sources of information yielded intelligence that was useful and applied within an operational environment, and the ability to associate incidents with particular pieces of intelligence and to feed that data back into the CTI tool. The CTI tool should be able to take the context provided by users and feed it back into the tool to inform future data recommendations to users.
| Data from past engagements (event or incident investigation) within a specific network environment that will aid in situational awareness in a current engagement will be readily surfaced for analyst's use. (For example, if a past incident investigation showed that a particular vulnerability needed to be resolved within an organization's environment, the CTI tool will prompt the investigating analyst with information about that past engagement and whether or not the vulnerability is still present. | CORE: CTI tool provides exact match correlations (e.g. IP address is seen in two separate events) across datasets present in the tool. |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .