1 Data modelling language SRS-001
The data model of SATRAP SHALL be specified using a data modelling language based on description logics, such as OWL, or on type theory such as TypeQL.
Rationale
To enforce a rigorous logical model specification close to the conceptual model where the semantics of information are captured.
Acceptance criteria
See validation test case specification
Parent links: MRS-001 Semantic data model, MRS-015 Semantic relations preservation
Child links: ARC-001 System structure overview, TST-001 Verify data modelling artifacts, ARC-002 Logical view of SATRAP, ARC-004 ETL components
| Attribute | Value |
|---|---|
| type | A |
| urgency | 5 |
| vm | R |
| release | Alpha |
2 Database paradigm SRS-002
The SATRAP-DL system (i.e., SATRAP) SHALL rely on a database paradigm that allows for knowledge representation based on semantics as opposed to based on structure of the information. Possible candidates are the PERA model and the graph model implemented by TypeDB and, e.g., Neo4J respectively.
Rationale
To enable intrinsic semantic search capabilities and automated reasoning over the data model.
Acceptance criteria
See validation test case specification
Parent links: MRS-002 CTI knowledge base, MRS-015 Semantic relations preservation
Child links: ARC-001 System structure overview, TST-001 Verify data modelling artifacts, ARC-002 Logical view of SATRAP, ARC-004 ETL components
| Attribute | Value |
|---|---|
| type | A |
| urgency | 5 |
| vm | R |
| release | Alpha |
3 Semantic search SRS-003
The system SHALL support querying the CTI SKB based on semantic criteria.
Rationale
To enable users to perform meaningful searches and data manipulation based on semantics rather than just data structure.
Acceptance criteria
See validation test case specification
Parent links: MRS-002 CTI knowledge base
Child links: TST-001 Verify data modelling artifacts
| Attribute | Value |
|---|---|
| type | A |
| urgency | 5 |
| vm | R |
| release | Alpha |
4 Extensibility of the data model SRS-004
The data model of the CTI SKB SHALL be extensible to accommodate for the integration of new information (e.g., facts, entities, or relationships) without requiring a complete redesign.
Rationale
Extensibility of the data model allows for gradual enrichment of the CTI SKB by combining multiple threat frameworks, as CTI might not be expressible in a single one.
Acceptance criteria
See validation test case specification
Parent links: MRS-003 CTI SKB extensibility
Child links: TST-001 Verify data modelling artifacts
| Attribute | Value |
|---|---|
| type | A |
| urgency | 5 |
| vm | R |
| release | Alpha |
5 NoSQL data model SRS-005
The data model of the CTI SKB SHALL rely on either a NoSQL graph-based or a document-based database solution or a type-theoretic polymorphic entity-relation-attribute (PERA) data model to allow for the addition of new entities and relationships without requiring a schema migration.
Rationale
Flexibility enables further customization for specific domains, such as healthcare or military related ones.
Acceptance criteria
See validation test case specification
Parent links: MRS-004 SKB data model flexibility
Child links: TST-001 Verify data modelling artifacts, ARC-004 ETL components
| Attribute | Value |
|---|---|
| type | A |
| urgency | 5 |
| vm | R |
| release | Alpha |
6 Integration of common CTI SRS-006
As an administrator of SATRAP, I want to run an ETL pipeline that retrieves MITRE ATT&CK datasets published in STIX 2.1, transforms the content into an adequate format and loads this content into the CTI SKB, so that I have up-to-date, reliable and curated data available for automated reasoning and analysis.
For this purpose:
- I have a way to configure the MITRE ATT&CK STIX 2.1 source URL or local file
- I can run the integration process from the CLI of SATRAP
- SATRAP runs the ETL pipeline to downloads/reads the STIX 2.1 payload, transform STIX into the internal TypeQL load statements and insert them into the CTI SKB
- I get notified of API authentication failures, network errors, and invalid STIX payloads with clear error messages and appropriate exit codes
- I get a summary at the end the ETL process and can see the log for detailed information.
Rationale
For scenarios that deal with CTI generation and operation, we consider that a knowledge base requires information from at least three categories integrating both, public and internal threat landscapes. This requirement addresses the integration of common cybersecurity knowledge.
Acceptance criteria
See validation test case specification
Parent links: MRS-005 CTI SKB content: public CTI knowledge
Child links: ARC-003 ETL high-level design, ARC-004 ETL components, TST-008 Test setup + MITRE ATT&CK ingestion
| Attribute | Value |
|---|---|
| type | F |
| urgency | 5 |
| vm | T |
| release | Alpha |
7 Semantic data integrity SRS-007
The data model SHALL enforce semantic integrity ensuring that relationships and constraints adhere to the intended meaning. Semantic data integrity can be enforced by measures such as data validation with respect to schemas and relationships constraints, automated checks for data redundancy and inference powered with a reasoning engine.
Rationale
To ensure consistency, accuracy and reliability of data, preventing among others contradictory and repeated data to be stored.
Acceptance criteria
See validation test case specification
Parent links: MRS-008 CTI SKB data integrity
Child links: TST-020 Verify enforcement of semantic data integrity
| Attribute | Value |
|---|---|
| type | S |
| urgency | 5 |
| vm | R |
| release | Alpha |
8 ETL subsystem SRS-008
SATRAP SHALL contain a component in charge of integrating data from external sources into the CTI SKB. This component, referred to as the ETL (extract-transform-load) subsystem, is responsible of extracting datasets in STIX 2.1 from diverse sources, transforming them into the representation language of the CTI SKB and loading the transformed content into the CTI SKB.
Rationale
To provide a single means of data ingestion regardless of the data source, enforcing separation of duties and modularity in the design.
Acceptance criteria
See validation test case specification
Parent links: MRS-011 Ingestion of CTI in a standard format
Child links: ARC-001 System structure overview, ARC-002 Logical view of SATRAP, ARC-003 ETL high-level design, ARC-004 ETL components, TST-009 Verify ETL architecture
| Attribute | Value |
|---|---|
| type | A |
| urgency | 5 |
| vm | R |
| release | Alpha |
9 ETL Transformer SRS-009
The ETL subsystem SHALL have a component in charge of transforming data in STIX 2.1 format into the representation language of the the CTI SKB schema.
Rationale
To address data parsing enforcing separation of duties and modularity.
Acceptance criteria
See validation test case specification
Parent links: MRS-011 Ingestion of CTI in a standard format
Child links: ARC-003 ETL high-level design, ARC-004 ETL components, TST-009 Verify ETL architecture
| Attribute | Value |
|---|---|
| type | A |
| urgency | 5 |
| vm | R |
| release | Alpha |
10 Database manager SRS-010
The system SHALL have a component in charge of managing database operations and connections.
Rationale
To deal with database management enforcing separation of duties and modularity.
Acceptance criteria
See validation test case specification
Parent links: MRS-011 Ingestion of CTI in a standard format
Child links: ARC-001 System structure overview, ARC-002 Logical view of SATRAP, ARC-003 ETL high-level design, ARC-004 ETL components, TST-009 Verify ETL architecture
| Attribute | Value |
|---|---|
| type | A |
| urgency | 5 |
| vm | R |
| release | Alpha |
11 Ingestion of organizational CTI SRS-011
As a CTI analyst or SATRAP administrator, I want to have a configurable way to integrate CTI from MISP or OpenCTI into the CTI SKB so that our organization's internally-tracked threat intelligence is available for automated reasoning and analysis with other data in SATRAP.
For this purpose:
- I have a way to configure my TIP API credentials and endpoint URL.
- I can run the integration process from the CLI of SATRAP
- SATRAP programmatically extracts STIX 2.1 bundles from either platform (e.g., via PyMISP or the OpenCTI Python SDK) and inserts them into the CTI SKB via the ETL subsystem.
- I get notified of API authentication failures, network errors, and invalid STIX payloads with clear error messages and appropriate exit codes.
- I get a summary at the end the ETL process and can see the log for detailed information.
Rationale
For scenarios that deal with CTI generation and operation, we consider that a knowledge base requires information from at least three categories integrating both, public and internal threat landscapes. This requirement addresses the integration of organizational CTI (internal and shared with the organization).
Acceptance criteria
See validation test case specification
Parent links: MRS-040 CTI SKB content: organizational CTI
Child links: ARC-001 System structure overview, ARC-002 Logical view of SATRAP, ARC-003 ETL high-level design
| Attribute | Value |
|---|---|
| type | F |
| importance | 4 |
| urgency | 4 |
| vm | T |
| release | Beta |
12 Inference rules SRS-012
SATRAP SHALL implement inference rules that allow for the automated derivation of knowledge over existing relations in the CTI SKB.
Rationale
To address one of the major challenges for incident responders, namely, manual data correlation and contextualization of collected IoCs.
Acceptance criteria
See validation test case specification
Parent links: MRS-014 Automated CTI enrichment
Child links: ARC-001 System structure overview, TST-010 Verify CTI SKB inference rules
| Attribute | Value |
|---|---|
| type | F |
| urgency | 4 |
| vm | A |
| release | Alpha |
13 STIX 2.1 data model SRS-013
The data model of SATRAP SHALL be aligned with the data model of STIX 2.1.
Rationale
Such a design enables a direct mapping of the imported data into the concepts in the database and allows for the use of the integrity checks defined over the database model.
Acceptance criteria
See validation test case specification
Parent links: MRS-015 Semantic relations preservation
Child links: ARC-003 ETL high-level design, ARC-004 ETL components, TST-004 Verify STIX 2.1-based data model
| Attribute | Value |
|---|---|
| type | A |
| urgency | 5 |
| vm | A |
| release | Alpha |
14 Native reasoning engine SRS-014
SATRAP SHALL use a DBMS technology that integrates or has compatibility with a reasoning engine. The preferred solution is TypeDB.
Rationale
A native implementation of the KB and reasoning engine in one platform typically optimizes performance as it allows for the implementation of efficient data management strategies.
Acceptance criteria
See validation test case specification
Parent links: MRS-018 Automated reasoning
Child links: ARC-001 System structure overview, ARC-002 Logical view of SATRAP, TST-003 Verify STIX and reasoning engine
| Attribute | Value |
|---|---|
| type | A |
| urgency | 5 |
| vm | R, I |
| release | Alpha |
15 Jupyter Notebook frontend SRS-015
SATRAP SHALL implement an analysis frontend in the form of a set of Jupyter notebooks that make use of the CTI analysis toolbox SDK. This frontend SHALL showcase the usage of the functions in the SDK providing reusable blocks of code and playbooks for CTI investigations.
Rationale
For interoperability with the ecosystem, to enable the automation of the CTI lifecycle through the integration of multiple complementary solutions.
Acceptance criteria
See validation test case specification
Parent links: MRS-020 Interactive frontend, MRS-022 Storage of CTI investigations, MRS-023 Query parameterization, MRS-025 SATRAP-DL service, MRS-026 Query result viewer, MRS-027 Frontend query status, MRS-029 Frontend design, MRS-034 Frontend cross-platform support
Child links: ARC-001 System structure overview, ARC-002 Logical view of SATRAP, TST-011 Test Jupyter notebook frontend, TST-019 Verify layered architecture of SATRAP
| Attribute | Value |
|---|---|
| type | F |
| urgency | 3 |
| vm | T |
| release | Alpha |
16 API based on OAS SRS-016
The API of SATRAP SHALL comply with the OpenAPI Specification (OAS) standard.
Rationale
To enable automatic generation of documentation, automated API testing and validation, and a language-agnostic human and machine-readable specification.
Acceptance criteria
See validation test case specification
Parent links: MRS-038 Platform-independent API
| Attribute | Value |
|---|---|
| type | C |
| urgency | 2 |
| vm | R |
| release | FID |
17 Integration of behavioral data SRS-017
SATRAP SHALL implement a mechanism for retrieving data sourced by IDPS-ESCAPE from the CyFORT CTI repository (handled by an open-source TIP), via programmatic API access. Other SATRAP components can then adequately process and insert the information into the CTI SKB.
Rationale
For scenarios that deal with CTI generation and operation, we consider that a knowledge base requires information from at least three categories. This requirement addresses the integration of behavioral data.
Acceptance criteria
See validation test case specification
Parent links: MRS-039 CTI SKB content: from IDPS-ESCAPE
Child links: ARC-001 System structure overview, ARC-002 Logical view of SATRAP
| Attribute | Value |
|---|---|
| type | F |
| importance | 4 |
| urgency | 3 |
| vm | T |
| release | Beta |
18 Automated CTI analysis SRS-018
SATRAP SHALL provide an automated mechanism for running a knowledge derivation workflow:
- Data retrieval from the CyFORT CTI repository.
- Execution of predefined inference queries.
Such a mechanism SHALL support customizable settings, e.g., in a configuration file.
Rationale
For supporting automation of CTI maintenance processes, e.g, via a chron job that runs this script/program.
Acceptance criteria
See validation test case specification
Parent links: MRS-042 CyFORT CTI continuous analysis
| Attribute | Value |
|---|---|
| type | F |
| importance | 4 |
| urgency | 2 |
| vm | T |
| release | Beta |
19 CTI export to STIX 2.1 SRS-019
SATRAP SHALL provide a feature for obtaining the results of CTI analysis toolbox inference functions in STIX 2.1 format.
Rationale
For persistence of the analysis results in a standard human-readable format, and for enabling transfer of newly derived CTI into other tools (e.g., the CyFORT CTI repository).
Acceptance criteria
See validation test case specification
Parent links: MRS-019 Exporting inferred CTI
| Attribute | Value |
|---|---|
| type | F |
| importance | 5 |
| urgency | 4 |
| vm | T |
| release | Beta |
20 System configuration file SRS-020
SATRAP SHALL allow for customization of system parameters (e.g., logging severity: debug, info, warn, error; db connections; file paths) in a dedicated configuration file.
Rationale
In agreement with clean code and best practices for software development, to promote code maintainability.
Acceptance criteria
See validation test case specification
Parent links: MRS-044 Modular architecture
Child links: ARC-003 ETL high-level design, ARC-004 ETL components, TST-005 Verify centralized management
| Attribute | Value |
|---|---|
| type | Q |
| urgency | 3 |
| vm | I |
| release | Alpha |
21 Centralized logging SRS-021
The logs of the system SHALL be handled in a central location.
Rationale
In agreement with clean code and best practices for software development, to promote code maintainability.
Acceptance criteria
See validation test case specification
Parent links: MRS-044 Modular architecture
Child links: TST-005 Verify centralized management
| Attribute | Value |
|---|---|
| type | Q |
| urgency | 2 |
| vm | I |
| release | Alpha |
22 Centralized exception handling SRS-022
SATRAP SHALL manage exceptions in a centralized manner, e.g., by maintaining all the error codes in a configuration file.
Rationale
In agreement with clean code and best practices for software development, to promote code maintainability.
Acceptance criteria
See validation test case specification
Parent links: MRS-044 Modular architecture
Child links: TST-005 Verify centralized management
| Attribute | Value |
|---|---|
| type | Q |
| urgency | 5 |
| vm | I |
| release | Alpha |
23 CTI representation in STIX 2.1 SRS-023
SATRAP-DL SHALL use STIX 2.1 as the default standard format for CTI representation.
Rationale
For interoperability
Acceptance criteria
See validation test case specification
Parent links: MRS-045 STIX compliance
Child links: ARC-003 ETL high-level design, TST-003 Verify STIX and reasoning engine, ARC-004 ETL components
| Attribute | Value |
|---|---|
| type | C |
| urgency | 5 |
| vm | R, I |
| release | Alpha |
24 Design and implementation principles SRS-024
The design and implementation of SATRAP SHALL adhere to software best practices such as naming convention, clean code, SOLID principles, etc.
Rationale
Among others, for maintainability, security, reliability and robustness of code.
Acceptance criteria
See validation test case specification
Parent links: MRS-044 Modular architecture, MRS-046 C5-DEC compliance
Child links: TST-002 Verify software engineering practices, ARC-003 ETL high-level design, ARC-004 ETL components
| Attribute | Value |
|---|---|
| type | A, S, Q |
| urgency | 5 |
| vm | R |
| release | Alpha |
25 Code readability SRS-025
The source code of SATRAP SHALL be self explanatory and well documented.
Rationale
To support maintainability, extensibility and adoption of the software.
Acceptance criteria
See validation test case specification
Parent links: MRS-046 C5-DEC compliance
Child links: TST-006 Verify code clarity
| Attribute | Value |
|---|---|
| type | Q |
| urgency | 5 |
| vm | I |
| release | Alpha |
26 Public release SRS-026
The source code of SATRAP SHALL be released in a GitHub public repository.
Rationale
Open-source releases allow contributions and usage by the community, which in turn foster adoption and constant exchange of feedback.
Acceptance criteria
See validation test case specification
Parent links: MRS-051 Open-source releases
Child links: TST-018 Verify release and licensing
| Attribute | Value |
|---|---|
| type | C |
| urgency | 3 |
| vm | I |
| release | Alpha |
27 Open-source licensing SRS-027
Third-party libraries used in SATRAP-DL SHALL have open source licenses that do not restrict the privileges granted by the license selected for SATRAP-DL.
Rationale
To avoid the introduction of limitations in the distribution and use of SATRAP-DL derived from the use of third-party software.
Acceptance criteria
See validation test case specification
Parent links: MRS-051 Open-source releases
Child links: TST-018 Verify release and licensing
| Attribute | Value |
|---|---|
| type | C |
| urgency | 3 |
| vm | A |
| release | Alpha |
28 Input validation SRS-028
SATRAP components receiving input to the system SHALL validate the input and reject it in case the validation fails. The validation may include integrity checks, syntactic checks, semantic checks, parameter out-of-range checks, etc.
Rationale
To prevent code injection.
Acceptance criteria
See validation test case specification
Parent links: MRS-053 Secure programming compliance
Child links: ARC-003 ETL high-level design, ARC-004 ETL components, TST-007 Verify secure programming
| Attribute | Value |
|---|---|
| type | S |
| urgency | 5 |
| vm | I |
| release | Alpha |
29 Input sanitization SRS-029
SATRAP components SHALL perform sanitization of input and output (data passed across a trust boundary). Sanitization may include removing, replacing, encoding, or escaping unwanted characters.
Rationale
To prevent code injection.
Acceptance criteria
See validation test case specification
Parent links: MRS-053 Secure programming compliance
Child links: ARC-003 ETL high-level design, ARC-004 ETL components, TST-007 Verify secure programming
| Attribute | Value |
|---|---|
| type | S |
| urgency | 5 |
| vm | I |
| release | Alpha |
30 Resource management SRS-030
Network connections and other resources accessed SHALL be properly terminated when no further required.
Rationale
To prevent data leakage or DoS attacks.
Acceptance criteria
See validation test case specification
Parent links: MRS-053 Secure programming compliance
Child links: TST-007 Verify secure programming
| Attribute | Value |
|---|---|
| type | S |
| urgency | 5 |
| vm | I |
| release | Alpha |
31 Code static analysis SRS-031
The code of SATRAP SHALL be statically analyzed using an appropriate software to identify potential issues. The static analysis of Python code shall aim to detect:
- error handling
- commented-out code
- input validation
- code injection
- concurrency and race conditions (if applicable)
- canonical representation vulnerabilities
- minimum amount of dependencies
Rationale
To detect common security vulnerabilities in an automated way.
Acceptance criteria
See validation test case specification
Parent links: MRS-053 Secure programming compliance
| Attribute | Value |
|---|---|
| type | S |
| importance | 5 |
| urgency | 3 |
| vm | I, A |
| release | Alpha, Beta, FID |
32 Dependencies management SRS-032
All software dependencies including third-party libraries SHALL be listed and maintained in a configuration file.
Rationale
To enforce a centralized control over external dependencies.
Acceptance criteria
See validation test case specification
Parent links: MRS-053 Secure programming compliance
Child links: TST-007 Verify secure programming
| Attribute | Value |
|---|---|
| type | S |
| urgency | 5 |
| vm | I |
| release | Alpha |
33 Functional ETL events logging SRS-033
SATRAP SHALL log at least one timestamped event with an associated log level recording the ETL execution status (success/failure) per each phase, i.e., extraction, transformation, and loading.
Rationale
To provide information for security investigations.
Acceptance criteria
See validation test case specification
Parent links: MRS-053 Secure programming compliance
Child links: TST-012 Test ETL logging
| Attribute | Value |
|---|---|
| type | F |
| urgency | 3 |
| vm | T |
| release | Alpha |
34 Detailed event logging SRS-034
SATRAP logs SHALL be stored in a secure location and SHALL be accessible only to authorized personnel.
Rationale
To provide information for debugging purposes.
Acceptance criteria
See validation test case specification
Parent links: MRS-053 Secure programming compliance
| Attribute | Value |
|---|---|
| type | S |
| urgency | 3 |
| vm | T |
| release | FID |
35 Consistent logging format SRS-035
SATRAP logs SHALL be stored for at least X time duration according to a data retention policy.
Rationale
To generate human-readable and informative logs.
Acceptance criteria
See validation test case specification
Parent links: MRS-053 Secure programming compliance
| Attribute | Value |
|---|---|
| type | C |
| urgency | 1 |
| vm | T |
| release | FID |
36 Log validation SRS-036
Log strings SHALL be sanitized and validated before logging to prevent log injection attacks.
Rationale
To prevent log injection attacks.
Acceptance criteria
See validation test case specification
Parent links: MRS-053 Secure programming compliance
Child links: TST-007 Verify secure programming
| Attribute | Value |
|---|---|
| type | S |
| urgency | 4 |
| vm | I |
| release | Alpha |
37 Sensitive information SRS-037
SATRAP SHALL not log sensitive information such as passwords or entity identifiers.
Rationale
To avoid intended or unintended leakage of sensitive information.
Acceptance criteria
See validation test case specification
Parent links: MRS-053 Secure programming compliance
Child links: TST-007 Verify secure programming
| Attribute | Value |
|---|---|
| type | S |
| urgency | 5 |
| vm | I |
| release | Alpha |
38 Software identification SRS-038
The deployment build of SATRAP SHALL provide a way to retrieve its version and other identification details via the frontend.
Rationale
To inform the user of the specific version of the system that is being used, often required for consulting user manuals, reporting bugs, etc.
Acceptance criteria
See validation test case specification
Parent links: MRS-053 Secure programming compliance
| Attribute | Value |
|---|---|
| type | F,S |
| urgency | 3 |
| vm | T |
| release | Alpha |
39 TypeQL to STIX 2.1 transformer SRS-039
SATRAP SHALL have the capability of representing data expressed in the language of the CTI SKB (TypeQL), in terms of the STIX 2.1 data model.
Rationale
To provide the low-level components supporting SRS-019.
Acceptance criteria
None
Parent links: MRS-019 Exporting inferred CTI
| Attribute | Value |
|---|---|
| type | F |
| importance | 5 |
| urgency | 4 |
| vm | T,I |
| release | Beta |
40 Authentication and authorization SRS-040
For automated ingestion from and enrichment of the CyFORT CTI repository, SATRAP SHALL rely on the TIP built-in solution for user authentication and authorization, e.g., OpenCTI, MISP LDAP, or native user management.
Rationale
To enforce user identification and resource access authorization by building on well-established solutions.
Acceptance criteria
See validation test case specification
Parent links: MRS-056 Access control
| Attribute | Value |
|---|---|
| type | S, A |
| importance | 4 |
| urgency | 3 |
| vm | I |
| release | Beta |
41 Configuration management mechanism SRS-041
The system SHALL provide a configuration management mechanism with a set of predefined values for the user to adjust various system settings.
Rationale
To enforce a centralized user-configurable mechanism for managing system settings.
Acceptance criteria
See validation test case specification
Parent links: MRS-016 Configuration management, MRS-017 Conformance with user settings
Child links: TST-013 Inspect settings for CM
| Attribute | Value |
|---|---|
| type | F |
| urgency | 2 |
| vm | I |
| release | Alpha |
42 Command line interface (CLI) SRS-042
As a SATRAP administrator/CTI analyst, I want to interact with SATRAP via a command line interface so that I can set up the backend CTI SKB and launch the ETL pipeline without the need of a graphical user interface (GUI). Thus, I want the CLI to provide at least the following commands:
setup: Initialize the CTI SKB.etl: Launch the ETL pipeline.help: Display a list of available commands and their descriptions.
Rationale
To provide easy-to-use and efficient access to core data processing functionality for users who prefer command line tools.
Acceptance criteria
See validation test case specification
Parent links: MRS-020 Interactive frontend, MRS-033 File-based SKB update, MRS-034 Frontend cross-platform support
Child links: TST-014 Test command line interface (CLI)
| Attribute | Value |
|---|---|
| type | F |
| urgency | 5 |
| vm | T |
| release | Alpha |
43 TypeDB Studio SRS-043
The SATRAP-DL system SHALL adopt TypeDB Studio as a Graphical User Interface (GUI) for users to interact with the SATRAP CTI SKB using the native TypeQL query language.
Rationale
To provide the means to the user to execute queries in the native query language of the CTI SKB.
Acceptance criteria
See validation test case specification
Parent links: MRS-020 Interactive frontend, MRS-028 Native query execution, MRS-029 Frontend design, MRS-032 User-controlled CTI curation
Child links: TST-008 Test setup + MITRE ATT&CK ingestion
| Attribute | Value |
|---|---|
| type | F |
| urgency | 5 |
| vm | T |
| release | Alpha |
44 Open-source TIP integration SRS-044
SATRAP-DL SHALL adopt both MISP and OpenCTI as open-source TIPs (Threat Intelligence Platform) for central storage and management of threat intelligence data.
Rationale
To host and manage CTI data, by relying on stable and mature solutions, without reinventing the wheel. The choice of integrating a well-established open-source TIP would
- provide a solution capable of ingesting, storing, and distributing threat intelligence data from various sources, including open-source feeds, commercial feeds, and internal sources.
- provide a user-friendly interface for analysts to search, filter, and visualize threat intelligence data.
- support integration with other security tools and platforms, such as SIEM (Security Information and Event Management) systems, SOAR (Security Orchestration, Automation, and Response) platforms, and threat intelligence sharing platforms.
- support standardized formats for threat intelligence data, such as STIX (Structured Threat Information Expression) and TAXII (Trusted Automated Exchange of Indicator Information), to facilitate interoperability with other systems.
- support the ability to create and manage threat intelligence feeds, including the ability to schedule updates and manage data retention policies.
- support the ability to create and manage threat intelligence reports, including the ability to generate reports in various formats, such as PDF, HTML, and CSV.
- support the ability to create and manage threat intelligence dashboards, including the ability to customize the layout and content of the dashboards.
- support the ability to create and manage threat intelligence alerts, including the ability to configure alert thresholds and notification mechanisms.
Acceptance criteria
See validation test case specification
Parent links: MRS-012 CyFORT CTI repository, MRS-039 CTI SKB content: from IDPS-ESCAPE
Child links: TST-017 Verify open-source TIP integration
| Attribute | Value |
|---|---|
| type | A |
| urgency | 5 |
| vm | R |
| release | Alpha |
45 CTI analysis engine SRS-045
SATRAP SHALL have a component in charge of the CTI analysis operational logic, mediating the interaction between the service layer and the data layer.
Rationale
For separation of duties in SATRAP and to support automation of CTI analysis tasks.
Acceptance criteria
None
Parent links: MRS-024 CTI analysis
Child links: ARC-001 System structure overview, ARC-002 Logical view of SATRAP, TST-019 Verify layered architecture of SATRAP
| Attribute | Value |
|---|---|
| type | A |
| importance | 5 |
| urgency | 5 |
| vm | R,I |
| release | Alpha |
46 CTI analysis toolbox SRS-046
SATRAP SHALL have a component providing end-user functionality accessible programmatically via the frontend. This functionality consists primarily of parametrizable high-level CTI queries.
Rationale
For separation of duties in SATRAP and to support automation of CTI analysis tasks.
Acceptance criteria
None
Parent links: MRS-023 Query parameterization, MRS-025 SATRAP-DL service, MRS-037 SATRAP as software library
Child links: ARC-001 System structure overview, ARC-002 Logical view of SATRAP, TST-019 Verify layered architecture of SATRAP
| Attribute | Value |
|---|---|
| type | F,A |
| importance | 5 |
| urgency | 5 |
| vm | T,R |
| release | Alpha |
47 OSINT feeds configuration and catalog SRS-047
The CyFORT CTI repository instantiated by MISP and/or OpenCTI SHOULD ingest a pre-configured set of OSINT feeds, informed by a catalog documenting relevant feeds per application domain (e.g. energy sector, space sector, IT company, etc.).
Rationale
To integrate up to date relevant CTI in SATRAP according to the domain of interest. The catalog acts as a reusable knowledge base that supports the setup of new SATRAP deployments in diverse application domains.
Acceptance criteria
None
Parent links: MRS-013 OSINT ingestion
| Attribute | Value |
|---|---|
| type | F |
| importance | 4 |
| urgency | 2 |
| vm | R,I |
| release | FID |
48 Integration of security tools for automation SRS-048
As a SOAR operator, I want to integrate my SIEM and my case management systems with the CyFORT CTI repository, so that I can enable automated execution of workflows.
- I use Wazuh as a SIEM
- I use MISP for the CyFORT CTI repository
- I use Flowintel for case management
In particular, I want the alerts in my SIEM to be enriched with information from my CTI repository, and to be able to create cases in my case management system from either the SIEM, SATRAP-DL or the CTI platform/repository.
Rationale
To enable the creation of automated workflows for diverse threat scenarios.
Acceptance criteria
SATRAP-DL provides a mechanism/support for configuring communication channels between Wazuh, MISP, SATRAP and Flowintel, aimed at achieving a baseline for enrichment and the case creation described above.
Parent links: MRS-035 Integration with open-source tools for incident handling
| Attribute | Value |
|---|---|
| type | F |
| importance | 5 |
| urgency | 5 |
| vm | I,T |
| release | Beta |
49 Automated support for incident handling: phishing SRS-049
As a security manager, I want to have an automated pipeline that processes potential phishing incidents relying on SATRAP-DL's stack of open-source tools for incident handling, so that incident responders are automatically assigned only relevant cases based on predefined criteria. I want this pipeline to:
- Detect connections to potentially malicious URLs and create alerts in my SIEM
- Enrich the alerts with CTI available in my TIP
- Run an automated preliminary analysis on the alerts to decide whether the incident needs to be escalated
- Create a case in a case management tool if deemed necessary by the analysis
- Add relevant playbooks to the case for further interactive analysis, e.g., using SATRAP.
Rationale
To support automated incident handling, reducing alert fatigue and benefiting from inference-driven CTI.
Acceptance criteria
- The SIEM's dashboard shows identifiable alerts concerning the detection of suspicious URLs
- Such alerts contain additional information when compared to regular alerts; this information can be traced to the integrated TIP
- A case is automatically created for an identified malicious URL after the execution of the preliminary CTI analysis
- The created case includes pointers to predefined playbooks to run for a phishing scenario.
- A case is not created for a detected URL not evaluated as potentially malicious by the CTI analysis.
Parent links: MRS-058 Automated support for incident handling
| Attribute | Value |
|---|---|
| type | F |
| importance | 4 |
| urgency | 5 |
| vm | T |
| release | FID |