Extracting information from reports using large language models

Abstract

To provide a method for extracting information from reports, such as security reports or medical records, using machine learning-artificial intelligence (ML-AI) models.SOLUTION: A computer-implemented method for extracting and mapping structured information to a data model includes a step of acquiring text data from one or more unstructured data sources. Rephrased text data is determined using a Large Language Model (LLM), a preprocessing prompt, and the text data. Extracted data is determined using the LLM, an extraction prompt, the data model, and the rephrased text data. The extracted data is mapped to the data model. The method can be applied, for example, to medical use cases or cyber threat detection, among others, to improve the data models and support decision making.SELECTED DRAWING: Figure 3

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS Priority is claimed to U.S. Provisional Patent Application No. 63 / 471,532, filed June 7, 2023, the entire disclosure of which is incorporated herein by reference.

[0002] The present invention relates to methods, systems, and computer-readable media for extracting information from reports, such as security reports or medical records, using machine learning - artificial intelligence (ML-AI) models. [Background technology]

[0003] Cyber ​​threat intelligence (CTI) provides security practitioners with the information they need to protect against cyber threats and respond to attacks. When CTI is structured in a standard format, such as structured threat information expression (STIX), it can be used with automated tools and for efficient search and analysis. However, while many sources of CTI are structured and include indicators of compromise (IoCs), such as internet protocol (IP) address block lists and malware signatures, useful CTI is typically presented in unstructured formats, such as text reports or articles.

[0004] This form of CTI can be useful to security practitioners as it contains information about the attackers (threat actors) and victims (targets) and how the attacks are carried out, i.e. the tools (malware) and attack patterns. Ultimately, this is information that can enable threat hunting activities. Summary of the Invention [Means for solving the problem]

[0005] In an embodiment, the present invention provides a computer-implemented method for extracting and mapping structured information to a data model. Text data is obtained from one or more unstructured data sources. Paraphrased text data is determined using a Large Language Model (LLM), pre-processing prompts, and text data. Data to be extracted is determined using the LLM, extraction prompts, data model, and paraphrased text data. The extracted data is mapped to the data model. The method may be applied, for example, to medical applications or cyber threat detection, among other things, to improve the data model to aid in decision making.

[0006] The embodiments of the present invention are described in more detail below based on the exemplary drawings. The present invention is not limited to the exemplary embodiments. All features described and / or illustrated herein may be used alone or in different combinations in the embodiments of the present invention. The features and advantages of the various embodiments of the present invention will become apparent by reading the following detailed description in conjunction with the attached drawings showing: [Brief description of the drawings]

[0007] [Figure 1] FIG. 1 illustrates an example of a manual pipeline for extracting structured CTI. [Diagram 2] FIG. 1 illustrates an example of a pipeline employed for automatic CTI extraction. [Diagram 3] FIG. 1 illustrates an example of a global system in accordance with one or more embodiments of the present invention. [Figure 4] FIG. 2 illustrates another example of a global system in accordance with one or more embodiments of the present invention. [Diagram 5]FIG. 1 illustrates a large-scale language model (LLM) agent in accordance with one or more embodiments of the present invention. [Figure 6] FIG. 2 illustrates a portion of a STIX ontology in accordance with one or more embodiments of the present invention. [Figure 7] FIG. 13 is a diagram showing an example of a published security report. [Figure 8] FIG. 8 illustrates a STIX bundle representing the security report of FIG. [Figure 9] FIG. 1 is a block diagram of an example processing system that may be configured to perform any and all operations disclosed herein in accordance with one or more embodiments of the present invention. [Figure 10] FIG. 2 illustrates a schematic diagram of a structured CTI information extraction tool in accordance with one or more embodiments of the present invention. [Figure 11] A diagram illustrating the performance of malware entity extraction of a structured CTI information extraction tool according to one or more embodiments of the present invention compared to other tools. [Figure 12] FIG. 13 illustrates the performance of threat actor entity extraction of a structured CTI information extraction tool in accordance with one or more embodiments of the present invention compared to other tools. [Figure 13] FIG. 1 illustrates the performance of target entity extraction of a structured CTI information extraction tool according to one or more embodiments of the present invention compared to LADDER. [Figure 14a] FIG. 1 illustrates the total number of attack patterns extracted by a structured CTI information extraction tool according to one or more embodiments of the present invention compared to other tools. [Figure 14b] FIG. 1 illustrates the performance of attack pattern entity extraction of a structured CTI information extraction tool according to one or more embodiments of the present invention compared to other tools. [Figure 15] FIG. 1 illustrates the ablation of a structured CTI information extraction tool for malware extraction according to an embodiment of the present invention. [Figure 16]FIG. 1 illustrates ablation of a structured CTI information extraction tool for threat actor extraction in accordance with an embodiment of the present invention. [Figure 17] FIG. 1 illustrates an ablation of a structured CTI information extraction tool for attack pattern extraction according to an embodiment of the present invention. [Figure 18] FIG. 13 illustrates the performance of malware entity extraction of a structured CTI information extraction tool using heuristics according to one or more embodiments of the present invention compared to other tools. [Figure 19] FIG. 13 illustrates the performance of threat actor entity extraction of a structured CTI information extraction tool using heuristics according to one or more embodiments of the present invention compared to other tools. [Figure 20] FIG. 1 illustrates the performance of relationship extraction of a structured CTI information extraction tool according to one or more embodiments of the present application compared to other tools. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] The present invention provides machine learning systems and methods that accompany advances based in the field of computer processing, specifically in the field of machine learning. For example, in some variations, the present invention may not require specific training of the model to accurately extract information, saving computational resources and training time. In addition, the present invention may be adapted to the specific tasks of security experts, thus improving flexibility and usability. By improving the functionality of cybersecurity procedures, the present invention also contributes to improving data security and privacy. Moreover, the present invention may reduce the computational power required to implement cybersecurity procedures and programs, for example by improving the extraction of information for cybersecurity procedures, saving computational resources. The present invention may also provide higher performance than state-of-the-art models, improving accuracy, computational capabilities, and computational resource usage. For example, by reducing the creation and / or storage of duplicate or multiple model-specific data sets, computational resources (e.g., processing demands, memory demands) may be conserved.

[0009] By using large-scale language models (LLMs), embodiments of the present invention can provide a system capable of extracting important information from cybersecurity reports with minimal human intervention.

[0010] Given the importance of CTI, even with limited resources, security analysts spend a large amount of time manually processing CTI sources to structure the information in a standard format. In fact, this effort is large enough that companies can organize organizations to share the structured CTI and the costs of producing it. For example, the Cyber ​​Threat Alliance (CTA) provides a platform for sharing CTI among its members in the form of STIX bundles, and its members are more than 30 large companies, such as CISCO, MCAFEE, SYMANTEC, SOPHOS, and FORTINET. To help with this effort, the security community is actively researching ways to automate the process of extracting information from unstructured CTI sources, which has led to the development of several methods and tools.

[0011] While these strategies help reduce the burden on analysts, to date, their focus has been limited to extracting indicators of compromise, which are relatively easy to identify using pattern-matching methods (e.g., regular expressions). Only recently have advances in natural language processing (NLP) using deep learning allowed the development of methods that can extract more complex information (e.g., threat actors, malware, targets, and attack patterns). Nevertheless, the performance of these strategies is still limited. One problem is the way in which these machine learning strategies work. They are often specialized general-purpose NLP machine learning models that have been fine-tuned for the cybersecurity domain. Fine-tuning is done by providing the machine learning model with a training dataset that is built by manually labeling a large number of reports.

[0012] However, these AI models may be specifically designed to perform tasks such as named entity recognition (NER), which is close to but crucially different from what security analysts want. In fact, these AI models may not consider the importance of the extracted information. For example, a report describing the use of a new malware may mention other known malware in a general introduction because they were used in similar attacks in the past. Although these mentions are unrelated to the current attack described in the report, a typical NER model may still extract and classify them as malware. However, a security analyst compiling a structured CTI report would ignore such irrelevant mentions when extracting information about the attack. That is, the generation of a structured CTI report may require the extraction of only important named entities (e.g., malware).

[0013] In a first aspect, the present disclosure provides a computer-implemented method for extracting and mapping structured information to a data model. Text data is obtained from one or more unstructured data sources. Paraphrased text data is determined using a large language model (LLM), pre-processing prompts, and the text data. Data to be extracted is determined using the LLM, the extraction prompts, the data model, and the paraphrased text data. The extracted data is mapped to the data model.

[0014] In a second aspect, the disclosure provides a method according to the first aspect, further comprising the steps of outputting the extracted data to a user interface for user review, receiving user input about the extracted data, determining a corrected extraction prompt based on the user input, and determining further extracted data using the LLM, the corrected extraction prompt, the data model, and the paraphrased text data, wherein the further extracted data is used as the extracted data that is mapped to the data model.

[0015] In a third aspect, the present disclosure provides a method according to the first or second aspect, wherein the one or more unstructured data sources include security reports and the text data includes cyber threat intelligence (CTI) information regarding security incidents.

[0016] In a fourth aspect, the present disclosure provides a method according to any of the first to third aspects, further comprising obtaining further text data from an internet source based on a determination that the text data does not contain sufficient information to be processed by the LLM, and wherein determining the paraphrased text is based on the text data and the further text data.

[0017] In a fifth aspect, the present disclosure provides a method according to any of the first to fourth aspects, wherein the textual data and / or further textual data are obtained by parsing one or more unstructured data sources and / or internet sources based on entities defined by the data model.

[0018] In a sixth aspect, the disclosure provides a method according to any of the first to fifth aspects, wherein determining the paraphrased text data comprises obtaining one or more text chunks from the text data based on an input capacity of the LLM, and inputting the preprocessing prompt and a first text chunk of the one or more text chunks into the LLM to obtain summarized paraphrased text data for the first text chunk as the paraphrased text data, wherein the summarized paraphrased text data comprises less text data than the first text chunk, and determining the data to be extracted is based on the summarized paraphrased text data.

[0019] In a seventh aspect, the present disclosure provides a method according to any of the first to sixth aspects, further comprising inputting a further preprocessing prompt and a second of the one or more text chunks into the LLM to obtain second summarized paraphrased text data for the second text chunk, the second summarized paraphrased text data comprising less text data than the second text chunk, and the step of determining the data to be extracted is further based on the second summarized paraphrased text data.

[0020] In an eighth aspect, the present disclosure provides a method according to any of the first to seventh aspects, wherein determining the paraphrased text data further comprises inputting the preprocessing prompts and the text data into an LLM to obtain an expanded paraphrased text for the text data, the expanded paraphrased text comprising an expansion of the text data, and determining the data to be extracted is further based on the expanded paraphrased text data.

[0021] In a ninth aspect, the present disclosure provides a method according to any of the first to eighth aspects, in which the augmentation of the text data comprises at least a portion of the text data and new text indicating a different description of information from the text data.

[0022] In a tenth aspect, the present disclosure provides a method according to any of the first to ninth aspects, the method further comprising the steps of outputting the paraphrased text data to a user interface for user review, receiving user input about the paraphrased text data, determining a corrected preprocessing prompt based on the user input, and determining further paraphrased text data based on using the LLM, the corrected preprocessing prompt, and the text data source, wherein the further paraphrased text data is used as the paraphrased text data in determining the data to be extracted.

[0023] In an eleventh aspect, the present disclosure provides a method according to any of the first to tenth aspects, further comprising obtaining entities of a data model using an extraction prompt and an LLM. The extraction prompt queries the LLM to extract entities of the data model from the paraphrased text data. The data model is a Structured Threat Intelligence Description Format (STIX) data model. Mapping the extracted data to the data model further comprises mapping the extracted entities to the data model and outputting the mapped data model to a user via a user interface.

[0024] In a twelfth aspect, the present disclosure provides a method according to any of the first to eleventh aspects, wherein the text data comprises cyber threat intelligence (CTI) information and the entities comprise one or more of malware, threat actors, targets, and vulnerabilities; or the text data comprises medical records and the entities comprise one or more of patients, doctors, treatments, hospitals, and medicines.

[0025] In a thirteenth aspect, the present disclosure provides a method according to any of the first to twelfth aspects, the method further comprising: determining further paraphrased text data using the LLM, a further preprocessing prompt different from the preprocessing prompt, and a text data source; and / or determining further extracted data using the LLM, a further extraction prompt different from the extraction prompt, the data model, and the paraphrased text data; and determining that the further paraphrased text data is the same as or substantially similar to the paraphrased text data or that the further extracted data comprises the same extracted entities as the extracted data.

[0026] In a fourteenth aspect, the present disclosure provides a computer system for extracting and mapping structured information to a data model, the computer system comprising one or more hardware processors configured, alone or in combination, to effect execution of a method according to any of the first to thirteenth aspects.

[0027] In a fifteenth aspect, the present disclosure provides a tangible, non-transitory computer readable medium for extracting and mapping structured information to a data model, the non-transitory computer readable medium having instructions that, when executed by one or more hardware processors, alone or in combination, effect performance of a method according to any of the first to thirteenth aspects.

[0028] Embodiments of the present invention provide an adaptive system for automatically extracting information from CTI reports written in free-form text and presenting that information in a structured manner by using an LLM. For example, embodiments of the present invention may use an LLM agent that queries (e.g., generates and / or provides) the LLM by using prompt templates.

[0029] Once in a structure (e.g., STIX), the suspicion, compromise, and attribution aspects from the CTI can be clearly expressed through object and descriptive relationships. STIX information can be represented visually for analysts or stored so that it can be quickly read by machines (e.g., as JavaScript Object Notation (JSON)). However, STIX information may have to be extracted from the CTI text before the information can be represented in a STIX structure.

[0030] 1 illustrates an example of a manual pipeline 100 (e.g., manual extraction) for extracting structured CTI. In this process, one or more security analysts 102 read large amounts of unstructured data 104 (e.g., CTI text reports), select relevant information, and convert it into a desired structured representation 106, such as STIX.

[0031] As a result, one or more security analysts 102 may be responsible for generating a structured representation 106 from unstructured data 104 (e.g., CTI text reports) and may need to use their knowledge in selecting relevant information and spend time reading the CTI text reports and converting the relevant information into a structured representation 106.

[0032] 2 illustrates an example embodiment of a pipeline 200 employed for automated CTI extraction. There may be several problems with the pipeline 200 approach. Automated methods for extracting CTI rely on various machine learning (ML) techniques, such as NLP. However, current automated methods may have several significant limitations that severely limit their application.

[0033] First, the pipeline 200 may require the use of multiple pipelines to extract various types of information found in structured reports. In Figure 2, two separate pipelines are illustrated: an entity and relationship pipeline 204 for extracting entities and relationships (e.g., malware, threat actors, and / or attack victims), and an attack pattern pipeline 206 for extracting and classifying attack patterns (e.g., sentences describing actions performed by an attacker according to a particular taxonomy) from the unstructured data 202. These pipelines 204, 206 consist of multiple ML components, each of which may require a unique annotated dataset.

[0034] For example, the entity and relationship pipeline 204 may include a NER model 208 to locate, classify, and / or extract named entities mentioned in the unstructured data 202 into predefined categories (e.g., person names, organizations, locations, time entities). The entity and relationship pipeline 204 may also include a relationship model 210 to locate, classify, and / or extract information and object relationships (e.g., relationships between named entities extracted by the model 208) in the unstructured data 202. The model 208 may utilize an annotated dataset 214 as an input from which to extract the named entities of the unstructured data 202, and the model 210 may utilize an annotated dataset 216 as an input from which to extract relationships from the unstructured data 202. Moreover, the model 208 and the model 210 may each require a separate annotated dataset.

[0035] Similarly, the attack pattern pipeline 206 may include a sentence selection model 220 for identifying and extracting sentences that contain answers to a given question, and a sentence classification model 222 for classifying sentences into predefined groups. Model 220 may utilize an annotated dataset 224 as an input from which to extract named entities of the unstructured data 202, and model 222 may utilize an annotated dataset 226 as an input from which to extract relationships from the unstructured data 202. Moreover, model 220 and model 222 may each require a separate annotated dataset.

[0036] An expert or analyst 212 (e.g., a cross-domain expert) may be required to generate annotated dataset 214, annotated dataset 216, annotated dataset 224, and / or annotated dataset 226, either separately or simultaneously, possibly from different datasets of unstructured data 202.

[0037] The datasets 214, 216, 224, and / or 226 may be generated explicitly for each task (e.g., for each model 208, 210, 220, 222). The datasets may be aligned with the final structured format 230 used to represent the extracted information and may involve several cross-domain experts 212. The output 228 of these pipelines 204, 206 may still require validation, filtering, and selection by a human operator (e.g., analyst 232) because the components may not understand the significance of the extracted information.

[0038] An example of an excerpt from a cybersecurity report is as follows:

[0039] "We also discovered a YouTube account associated with the actor... In another video, we observed the threat actor submitting a Lockbit 2.0 sample on the Cuckoo sandbox and comparing the results with another, presumably LockBit 2.0... At this time, we do not believe x4k is associated with LockBit 2.0 activity..."

[0040] Although LockBit 2.0 is malware, it is not related to the attacks described in the example excerpts of the reports. Previous methods may still extract and classify LockBit 2.0 as malware, in some cases requiring a human operator to read the text reports and filter out irrelevant information.

[0041] Some previous methods can utilize heuristics to automatically filter such cases, but they can often result in misclassification.

[0042] Finally, any modifications to the classifications or data models used to represent the reporting of unstructured data 202 in a structured format 230 may not be made directly by the analyst 232. Instead, modifications may require relabeling the datasets 214, 216, 224, and / or 226 used to train the pipeline components. For example, changing the classification of LockBit from malware to ransomware may require changing the associated labels. As a result, the CTI analyst may not be able to directly adjust the pipelines 204, 206 to conform the classification to the desired output 228.

[0043] Embodiments of the present invention can provide a remedy to these limitations. First, embodiments of the present invention can utilize a single model for all components of the pipeline, eliminating the need for uniquely annotated datasets or task-specific training. Instead, the single model can be commanded to perform a task without explicit training. Second, the inference capabilities of the single model can be leveraged to automatically filter and select important information. Unlike traditional methods that rely solely on classification, the inference capabilities of the single model can enable the model to understand the context and importance of the extracted information.

[0044] Third, embodiments of the present invention may eliminate the need for dedicated cross-domain experts to customize pipelines for specific tasks. Unlike previous approaches that required domain-specific experts to program the pipeline, embodiments of the proposed model may allow the CTI analyst to directly interact with the model. The CTI analyst can compare the model's output (e.g., Fig. 3, Fig. 9) with what he would have manually generated (e.g., Fig. 1) and, if necessary, provide instructions directly to the model. This flexibility allows the CTI analyst to adapt and fine-tune the pipeline according to specific requirements without necessarily relying on external experts.

[0045] 3 describes a global system 300 according to one or more embodiments of the present invention. For example, in a first step, a security expert and / or user 302 provides as input 304 to the system 300 (e.g., a user interface 306 of the system 300) a report that the user 302 wants summarized and / or some terms (e.g., malware names) and a desired data model (e.g., STIX) that indicate a topic that the user 302 is interested in.

[0046] For example, in one embodiment of the invention, the user interface 306 may receive data and information from the report without any processing by the user 302. The user interface 306 may receive the report unstructured (e.g., HTML source, textual representation), for example, in the format in which the data was originally generated, advantageously reducing the burden on the user 302 to structure the security report themselves.

[0047] In a second step, the user interface 306 can send (e.g., provide and / or input) information from the input 304 to the data acquisition module 308 (e.g., a data acquisition device). The data acquisition module 308 can determine whether the information is sufficient for the LLM 312 to generate a response (e.g., an accurate or useful response) or whether the data acquisition module 308 is required to look for additional information on the Internet 314 (e.g., for acquisition and analysis). This can be done, for example, by the data acquisition module 308 ensuring that the LLM agent 310 receives a text report rather than a simple, short set of terms about a topic that the user 302 is interested in. For example, when the user interface 306 has already provided a report, the data acquisition module 308 can determine that additional material or information is not needed. When the user interface 306 has merely specified (e.g., provided) some terms that indicate a topic of interest (e.g., the name of malware), the data acquisition module 308 can download additional information from the Internet 314. This information may come from search engines or links provided by the user interface 306 and / or the user 302 (e.g., websites of well-known organizations and agencies that publish cybersecurity reports on their websites and provide search engines).

[0048] In a third step, the data acquisition module 308 analyzes the content 316 (e.g., the text of the report 304 and / or a representation of the text of the report 304) from the input 304 provided by the security expert or the download 302. In some cases, the data acquisition module 308 is required to search on the Internet 314 to supplement the analyzed information. In such cases, the data acquisition module 308 then analyzes new information from the Internet 314 and follows links either provided by the expert 302 or provided by the search (e.g., using a search engine). To analyze various sources, the data acquisition module 308 may have (e.g., may include) various plug-ins specialized for specific websites / formats.

[0049] Multiple plug-ins may be available to handle individual formats of unstructured reports (e.g., HTML source, textual representation). Using these plug-ins, the data acquisition module 308 may retrieve and parse important information from various sources of input reports, and after parsing the various sources, the information provided by these various sources may be supplemented by further information retrieved from the Internet. For example, there are well-known organizations and agencies that publish cybersecurity reports on their websites, and each website may have a different structure and format. Using plug-ins, the data acquisition module 308 may extract human-readable plain text from the HTML pages of the websites, which may later be further processed (e.g., by the LLM agent 310 and the LLM 312). The data acquisition module 308 may also utilize more sophisticated plug-ins designed for each source (e.g., source domain) that may strip out unnecessary information from the pages (e.g., headers, footers, and menus) that are common to all reports from that website / domain and may not contain the actual content of the reports.

[0050] In a fourth step, the data acquisition module 308 passes (e.g., transmits and / or sends) the parsed information to the LLM agent 310, and the LLM agent 310 receives the parsed information and determines (e.g., determines) the query to be made (e.g., provided and / or entered) to the LLM 312.

[0051] For example, in an embodiment of the present invention, the LLM agent 310 can form (e.g., determine and / or generate) a query (e.g., a prompt) for the LLM 312 by selecting a portion (e.g., a chunk) of the parsed information (e.g., text data from a text data source) that the LLM agent 310 receives from the data acquisition module 308 that fits (e.g., coincides with or fits within) a context window of the LLM 312, and a request to summarize the selected portion. The LLM agent 310 can provide the selected portion and the prompt to the LLM 312, which can summarize the selected portion according to the prompt request (e.g., reduce the amount of text data in the selected portion so that the LLM has to process fewer tokens). The user 302 can provide instructions that can supplement (e.g., incorporate) important information into the summary generated by the LLM 312. When more than one selection from the parsed information is made and summarized, the summaries can be integrated together and input to the LLM 312 (e.g., for extraction of entities by the LLM 312).

[0052] In an embodiment of the present invention, the LLM agent 310 can form a query (e.g., a prompt) for the LLM 312 by selecting a portion (e.g., a chunk) of the parsed information (e.g., text data from a text data source) that the LLM agent 310 receives from the data acquisition module 308 that fits (e.g., coincides with or falls within) a context window of the LLM 312, and a request to further describe the selected portion (e.g., identify important facts in the selected portion and / or find information connections in the text). The LLM agent 310 can provide the selected portion and the prompt to the LLM 312, which can describe the selected portion according to the prompt request. The user 302 can provide instructions that can supplement (e.g., incorporate) important information into the description generated by the LLM 312.

[0053] In a fifth step, the LLM agent 310 may execute (e.g., provide and / or input) some queries to the LLM 312 to pre-process and extract information. More information about the LLM agent 310 is provided below.

[0054] For example, in one embodiment of the present invention, the LLM agent 310 may input (e.g., provide and / or send) to the LLM 312 a desired data model including entities and relationships to be identified, previously generated summaries and / or descriptions, and / or parsed information that the LLM agent 310 received from the data acquisition module 308, and further prompts. The further prompts may request the LLM 312 to extract entities from the provided input, including providing entities in a specified format (e.g., for easy structuring into a desired ontology), and / or to answer specific questions (e.g., "What malware is being used?").

[0055] In a sixth step, the LLM agent 310 can receive the information output from the LLM 312, parse the received information, and format it in a desired data ontology (e.g., STIX).

[0056] In a seventh step, the user interface 306 returns the desired information 318 (e.g., the output of the LLM agent 310) to the security expert or user 302. For example, the expert 302 can look at the ontology (e.g., STIX bundle) generated by the LLM agent 310 and determine whether the STIX bundle accurately reflects the information in the input 304 (e.g., entities such as targets, malware, patterns, etc.).

[0057] In an eighth step, the user 302 can provide feedback to the LLM agent 310 (e.g., the LLM agent 310 can receive feedback from the user 302). For example, after receiving the output of the LLM agent 310, the user 302 can determine changes to the output of the LLM agent 310 and provide the determined changes to the user interface 306. The user interface 306 can then send the determined changes to the LLM agent 310, which can receive the determined changes directly or indirectly (e.g., via a further processing component or entity) from the user interface 306.

[0058] In a ninth step, the LLM agent 310 can modify and / or add prompt templates (e.g., queries). For example, after receiving the user's 302 feedback, the LLM agent 310 can modify the prompt templates and / or add them to the prompt templates provided to the LLM 312, and these modifications and / or additions can be made based on the received feedback of the user 302.

[0059] In one embodiment of the present invention, a formatting component of the LLM agent 310 can map information obtained from the LLM 312 and / or user 302 feedback into a desired ontology (e.g., STIX).

[0060] This process may be repeated. For example, this process (e.g., steps 1 through 9) may begin again based on the information 318 not being good enough for the security expert 302 and / or not being successful. In an embodiment, the user 302 may receive the information 318, evaluate the information 318, and provide feedback to the user interface 306. The user interface 306 may send the feedback, directly or indirectly, to the LLM agent 310, which may modify and / or add to the prompt template. The LLM agent 310 may then query the LLM 312 using the modified or additional template, if necessary, and provide output, directly or indirectly, to the user interface 306. The user interface 306 may then provide the information to the expert 302. The expert 302 may again evaluate the information 318 and provide feedback to the user interface 306, which again provides feedback to the LLM agent 310 for modification and / or addition to the query template. The LLM agent 310 can again query the LLM 312 using modified and / or additional query templates to provide information 318 to the user interface 306 for review by the expert 302 .

[0061] 4 is a simplified block diagram illustrating an LLM agent system 350, in accordance with one or more embodiments of the present invention. For example, the LLM agent system 300 includes, but is not limited to, a security expert or user 302, a user interface 306, a data acquisition module 308, and an LLM agent 310. The user 302 can receive information from the user interface 306 and can evaluate the information provided by the user interface 306 (e.g., the user 302 can determine whether the information 318 is sufficient). The user 302 can then provide input to the user interface 306 (e.g., provide feedback about the information 318).

[0062] The user interface 306 can receive input from the user 302 and send the input to another component of the LLM agent system 300. For example, the user interface 306 can receive feedback about the input 304 or information 318 from the user 302 and send them to the LLM agent 310 and / or the data acquisition module 308. For example, if the user interface 306 receives feedback about the information 318 from the user 302, the user interface 306 can send (e.g., provide) the feedback to the LLM agent 310 for further processing. If the user interface 306 receives input 304 from the user 302, the user interface 306 can send (e.g., provide) the input 304 to the data acquisition module 308.

[0063] The user interface 306 can receive information from the LLM agent 310 and display the received information to the user 302. For example, the LLM agent 310 can provide output to the user 302 (e.g., displaying the information received from the LLM agent 310). The user 302 can review the information and accept or reject the information generated by the LLM agent 310, e.g., can provide or not provide feedback to the user interface 306. As mentioned above, when the user 302 provides feedback about the information generated by the LLM agent 310, the user interface 306 can provide this feedback to the LLM agent 310.

[0064] The data acquisition module 308 may include a processor 358. The processor 358 may be any type of hardware and / or software logic, such as a central processing unit (CPU), a RASPBERRY PI processor / logic, a controller, and / or logic, that executes computer-executable instructions to perform the functions, processes, and / or methods described herein. The processor may communicate with other components of the LLM agent system 350 (e.g., the user interface 306, the LLM agent 310, the network interface 360). The data acquisition module 308 may receive input 304 from the user interface 306 using the processor 358. As described above, the data acquisition module 308 may evaluate (e.g., analyze) the input 304 received from the user interface 306 (e.g., using an evaluation process of the processor 358 and memory 362) and may use the processor 358 to forward (e.g., send and / or provide) information from the input 304 and / or the input itself to the LLM agent 310. When the data acquisition module 308, using the processor 358, determines (e.g., determines) that the input 304 does not have enough and / or good enough information for the LLM agent 310, the data acquisition module 308, using the processor 358, can access the Internet 314 through a network interface 360 ​​and query sources on the Internet 314. The processor 358 of the data acquisition module 308 can send (e.g., provide) queries to the Internet 314 and receive information from the Internet 314 (e.g., in response to the provided queries).

[0065] The data acquisition module 308 may include a memory 362. The memory 362 may include processes (e.g., programs and / or scripts) used by the processor 358 to evaluate the input 304 provided by the user interface 306 to determine whether the input 304 includes sufficient information for the LLM agent 310, as described above. For example, the processor 358 may input the input 304 received from the user interface 306 into a process in the memory 362 to determine whether sufficient information has been provided for the LLM agent 310 to form a prompt template for the LLM 312. These processes may be stored and maintained in the memory 362 and / or updated or stored in the memory. In some examples, the memory 362 may be and / or include a computer usable or computer readable medium, such as, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor computer readable medium. More specific examples (e.g., a non-exhaustive list) of computer-readable media may include tangible media such as an electrical connection having one or more wires, a portable computer diskette, a hard disk, a time-dependent access memory (e.g., RAM), a ROM, an erasable programmable read-only memory (EPROM or flash memory), a compact disc read-only memory (CD-ROM), or other tangible optical or magnetic storage device. The computer-readable media may store computer-readable instructions / program code for implementing aspects of the present application. For example, when executed by the processor 358, the computer-readable instructions / program code may implement operations of the present application, including determining whether sufficient information for the LLM agent 310 has been provided by the user interface 306.

[0066] The LLM agent 310 may include a processor 356. The processor 358 may be any type of hardware and / or software logic, such as a central processing unit (CPU), a RASPBERRY PI processor / logic, a controller, and / or logic, that executes computer-executable instructions to perform the functions, processes, and / or methods described herein. The processor 356 may communicate with other components of the LLM agent system 350 (e.g., the user interface 306, the data acquisition module 308, and, when present, the network interface 364). The processor 356 of the LLM agent 310 may receive information from the user interface 306. For example, the processor 356 of the LLM agent 310 may receive feedback that the user 302 inputs (e.g., provides) to the user interface 306 by receiving information sent by the user interface 306. The LLM agent 310 may also use the processor 356 to provide (e.g., send) information to the user interface 306, which may be received and displayed to the user 302. For example, the processor 356 of the LLM agent 310 can repeatedly receive feedback provided by the user 302 to the user interface 306 (e.g., feedback about information generated by the LLM agent 310), correct the generated information (e.g., correct the generated LLM prompt template), and send the corrected information to the user interface 306 for review by the user 302. This process can continue for a set number of times (e.g., limited by a processing threshold or a predetermined threshold) and / or upon input by the user 302 (e.g., upon the user 302 acknowledging the input).

[0067] The LLM agent 310 may include memory 354. The memory 354 may include processes (e.g., programs and / or scripts) used by the processor 356 to evaluate information received from the data acquisition module 308 to determine and / or generate prompt templates for the LLM 312 and / or for review by the user 302, as described above. For example, the processor 356 may input information received from the data acquisition module 308 into processes in the memory 354 to determine and / or generate prompt templates for the LLM 312 and / or for review by the user 302. These processes may be stored and maintained in the memory 354 and / or updated or stored in the memory. The LLM agent 310 may interact with one or more LLMs 312 provided (e.g., as a service through an application programming interface (API)). In some examples, the memory 354 may be and / or include a computer usable or computer readable medium, such as, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor computer readable medium. More specific examples (e.g., a non-exhaustive list) of computer readable media may include tangible media, such as an electrical connection having one or more wires, a portable computer diskette, a hard disk, a time-dependent access memory (e.g., RAM), a ROM, an erasable programmable read-only memory (EPROM or flash memory), a compact disk read-only memory (CD-ROM), or other tangible optical or magnetic storage device. The computer readable medium may store computer readable instructions / program code for implementing aspects of the present application.For example, when executed by the processor 356, the computer readable instructions / program code can perform operations of the present application, including determining and / or generating prompt templates for the LLM 312 and / or for review by the user 302, as described above.

[0068] The LLM agent 310 can use the processor 356 to send (e.g., provide and / or input) information (e.g., prompts) to one or more LLMs 312. In an embodiment of the invention, the processor 356 of the LLM agent 310 can send prompts to one or more LLMs 312 (e.g., LLMs 312 stored outside of the memory 354) using a network interface 364 (when present). The processor 356 of the LLM agent 310 can also receive output from the LLMs 312, and in an embodiment of the invention, the processor 356 of the LLM agent 310 can receive output from the LLMs 312 via the network interface 364 (when present).

[0069] LLM is a type of artificial intelligence (AI) model that is trained on large amounts of natural language data to generate text that is indistinguishable from human-generated text. These models can use deep learning techniques to learn the underlying language patterns and structures, and can be fine-tuned to perform specific NLP tasks such as language translation, question answering, or text completion.

[0070] LLMs can be characterized by a large number of parameters, which can range from tens of millions to hundreds of billions, and a large amount of data used to train those parameters, which can include the Internet corpus or entire books. These models have revolutionized the field of NLP, allowing applications such as language translation, content generation, and conversational interfaces to achieve unprecedented levels of accuracy and sophistication. They can be programmed by using prompts.

[0071] An LLM prompt is the initial input given to the LLM to generate a response. It can be a short sentence, a question, or a set of keywords that provide context for the LLM to generate a coherent and meaningful text response. The prompt serves as a starting point for the model to generate text based on learned patterns and structures from the training data.

[0072] For example, a prompt for a language translation LLM may be a sentence in one language that needs to be translated into another language. The LLM uses the prompt as a guide to generate a translation that accurately reflects the meaning and intent of the original sentence. Similarly, in a text completion task, the prompt may be a partial sentence or phrase that the LLM uses to generate a complete sentence that fits the given context.

[0073] The quality and specificity of the prompt can have a significant impact on the quality and validity of the responses generated: well-crafted prompts can help LLMs generate more accurate and appropriate responses, whereas vague or unclear prompts can result in less consistent or valid output.

[0074] LLM Agent (e.g., LLM Agent 310 shown in FIGS. 3 and 4): In an exemplary embodiment of the present invention, LLM Agent 500 is composed of three subsystems as shown in FIG. 5. For example, with reference to FIGS. 3 and 4, in some embodiments, LLM Agent 500 may be LLM Agent 310. This LLM Agent (e.g., 310 and / or 500) may be composed of three subsystems (e.g., pre-processing component 504, information extraction component 506, and formatting component 508) that perform functions (e.g., processing, information extraction, and / or formatting).

[0075] The pre-processing component 504 is responsible for selecting significant text from the unstructured input report (e.g., data 502). In some embodiments, this allows for two different types of inference (e.g., summarization and filtering and expansion, described below).

[0076] Summarization and filtering: The first type is used to filter and select important information that is clearly contained in the text. The larger context may be considered to remove unimportant information and select important information. In some embodiments, one limitation of LLMs may be their context window, since LLMs can only process a limited amount of text at a time. To overcome this limitation, the preprocessing step and preprocessing component 504 may involve selecting the largest chunk of text that fits into the input capacity of the LLM. The text may then be summarized, incorporating important information based on instructions provided by the CTI analyst in the prompt. For example, the input capacity of the LLM may be a fixed value given by the particular LLM model chosen. The input capacity may be represented in tokens, where a token is a single word or part of a word. For example, the LLM model may limit the total size of the input and output to 4000 tokens (approximately 3000-3500 words), which may limit the type of input the LLM model can process. The LLM agent 310 input capacity selection is responsible for splitting the input text in chunks based on the number of tokens that correspond to each chunk of text and the constraints of the LLM model on the tokens.

[0077] An example of a summary and filtering prompt is provided below. Write a brief summary below, including all information about the {filter}: {text} Short summary:

[0078] The above example embodiment represents the prompt template used for summarization and filtering. All text chunks can undergo the same summarization and filtering process. They may then be merged together into a single text, which is then passed through the extraction component 506 for the extraction step. This approach can help ensure that the generated text provides a global context for evaluation and extraction of important information.

[0079] Extension: The second type is utilized to clarify information that is only hinted at in the text. In this case, the preprocessing step involves extensions to concepts described in the text, possibly generating new text that provides a different description of the information contained in the original text. The amount of new text generated can be controlled to ensure that it fits within the context window.

[0080] Attack pattern descriptions are an example of implicit information that is typically included in CTI reports: these descriptions outline actions performed by an attacker or malware, and CTI typically processes the reports to classify these actions according to a specific taxonomy.

[0081] Below is an example paragraph describing the use of attack pattern T1573 “Encrypted Channels” extracted from the report:

[0082] "The January 2022 version of the PlugX malware utilizes RC4 encryption with a hard-coded key that is dynamically constructed. For communication, data is compressed before sending to the command and control (C2) server, then encrypted, and the same process is performed in reverse for data received from the C2 server. Below is the RC4 key "sV!e@T\#L\$PH\%" as it is being communicated with the encrypted data. The data is compressed and decompressed via LZNT1 and RtlDecompressBuffer. During the January 2022 campaign, the delivered PlugX malware samples communicated with the C2 server 92.118.188[.]78 over port 187."

[0083] The use of encrypted channels for communications with command and control is not explicitly stated in the text.

[0084] The following prompts can be used to stimulate extended reasoning about the text above. Describe the important facts in the following text step by step: {text} Key Facts:

[0085] This is the corresponding output. "The January 2022 version of the PlugX malware uses RC4 encryption with dynamically constructed keys for communication with command and control (C2) servers."

[0086] The summarized, filtered and enhanced text may then be passed from the pre-processing component 504 as input to the extraction component 506 for the information extraction step.

[0087] The information extraction component 506 uses the output of the pre-processing component 504. At this point, the resulting text can fit into the context window of the LLM being used. Again, using prompt templates, the LLM agent can query the LLM to obtain the various information required.

[0088] The LLM agent 500 (eg, the extraction component 506) can support several extraction methods and provide a list of information to be extracted. From the text below, extract all {NER_str} entities. Classify the entities and print them according to the given format. ==== Format ==== Malware: <comma separated list> or N / A Threat Actors: <Comma separated list> or N / A Or ask a direct question. Use the context below to answer the last question. {context} Question: Who / what is the target of the described attack?

[0089] In both cases, further filtering of the information to be extracted can be specified, for example by inserting a filter directly into the question, by restricting the list to only the set of entities to be extracted: "What malware was used in the attack? Do not consider backdoors as malware" or "What organizations were victims of the attack? Include the victims' home countries."

[0090] After extraction by the extraction component 506, the information extraction module (e.g., the information extraction component 506) may perform an additional verification step, querying the LLM to verify that the extracted information is present in the original text and reporting an error if there is a mismatch.

[0091] Further, the extraction component 506 can provide the extracted information to a formatting component 508. The formatting component 508 can map the retrieved information to a required ontology. For example, a user can provide a desired data model 512 for which information should be extracted, and the desired data model 512 provided by the user can include entities according to the STIX standard. The formatting component 508 can then map the extracted information to the desired data model 512 to generate the graph representation 510.

[0092] In this case, the extracted information may be represented as a STIX bundle that includes a graph format 510, which may contain all the extracted entities (e.g., explicit instantiations of the types of entities requested by the user).

[0093] In one or more embodiments, a method for extraction of structured CTI information from unstructured data sources, such as cybersecurity reports, may comprise the following steps. 1) Acquiring and parsing significant textual data sources that integrate input reports (when available) and additional information from the Internet (when required) (data acquisition block 308 in FIG. 3). 2) Defining a pipeline of prompts to automatically process CTI information by interacting with the LLM while taking into account the importance of the information, ignoring what is not important for the analyst's task. a) Pre-processing prompts to select only important CTI information (malware, threat actors, targets, attack patterns, etc.) and rephrase any text content to improve performance of the following operations (Pre-processing block 504 of FIG. 5 ); b) Extraction prompts (information extraction block 506 of FIG. 5 ) for extracting important CTI information (e.g., malware, threat actors, targets, attack patterns, etc.) from the provided text based on a CTI data model specified by the user (here, “important” may be understood as important to the end user (e.g., a CTI analyst) rather than important to the domain in a general sense (e.g., any malware mentioned in the report)). 3) Mapping the extracted information to a desired data model, e.g., an ontology (formatting block 508 of FIG. 5). For example, the STIX ontology defines entities such as malware, threat actors, attack patterns, and vulnerabilities. 4) Optional refinement of information pre-processing and extraction steps based on user feedback.

[0094] Embodiments of the present invention can provide many advantages. For example, a pre-processing step and specific prompts can be used to reason about the context of information contained in the text for the task of extracting CTI information. The pre-processing step improves the performance of subsequent steps (e.g., information extraction). This step can be used to: a. Summarization and filtering: making inferences about the broader context in which the information is found (all text reports) and selecting what is important and what is not according to the instructions received. b. Expansion: Reasoning about the detailed steps implicit in the attack description and generating new / additional descriptions of explicit steps required to carry out the attack.

[0095] In some embodiments of the invention, prompts may be used to directly specify which information to extract from the CTI report, to extract them, and / or ultimately to verify correct extraction.

[0096] In some embodiments of the invention, a CTI analyst may be allowed to be directly involved in the feedback loop by having a system that produces outputs that match those produced manually, and that are programmable by giving simple commands.

[0097] Embodiments of the present invention advantageously provide higher performance than existing techniques, as they do not require specific training of models and can be adapted to the specific tasks of security experts, while also saving training time and computational resources.

[0098] Embodiments of the present invention may also be applied in the field of medicine and healthcare (e.g., applied to medical reports). For example, many steps of the pipeline (e.g., filtering or augmentation) are applicable to other domains. For example, by tailoring and / or adapting the prompts utilized by the LLM agent 310 and processed by the LLM 312 to the desired task and type of source document (e.g., medical reports), embodiments of the present invention may provide AI tools to assist them in the field of medicine and healthcare. For example, medical related documents may contain important information in images, while in other cases the input documents may only contain text, and in some cases may contain both images and text information, and the expert 302, user interface 306, data acquisition module 308, LLM agent 310, and LLM 312 may all be adapted to process and extract important image and / or text information from these reports depending on the relevant information and the ultimate task. Thus, as used herein, a "report" may refer to a source document that may contain text and / or images, and an "incident" refers to an event or entity of interest in the relevant domain.

[0099] 9, processing system 900 may include one or more processors 902, memory 904, one or more input / output devices 906, one or more sensors 908, one or more user interfaces 910, and one or more actuators 912. Processing system 900 may represent each computing system disclosed herein.

[0100] Processor 902 may include one or more separate processors, each having one or more cores. Each of the separate processors may have the same or different architecture. Processor 902 may include one or more central processing units (CPUs), one or more graphics processing units (GPUs), circuitry (e.g., application specific integrated circuits (ASICs)), digital signal processors (DSPs), etc. Processor 902 may be mounted on a common substrate or on multiple different substrates.

[0101] The processor 902 is configured to perform (e.g., to implement the performance of) a function, method, or operation at least when one of one or more of the separate processors is capable of performing operations embodying the function, method, or operation. The processor 902 can perform operations embodying a function, method, or operation by executing code stored in the memory 904 (e.g., interpreting scripts) and / or trafficking data through one or more ASICs. The processor 902, and thus the processing system 900, can be configured to automatically perform any and all functions, methods, and operations disclosed herein. Thus, the processing system 900 can be configured to implement any (e.g., all) of the protocols, devices, mechanisms, systems, and methods described herein.

[0102] For example, when this disclosure states that a method or device performs (or that task "X" is performed), such a statement should be understood as disclosing that processing system 900 can be configured to perform task "X." Processing system 900 is configured to do at least as much as processor 902 is configured to perform a function, method, or operation.

[0103] Memory 904 may include volatile memory, non-volatile memory, and any other medium capable of storing data. The volatile memory, non-volatile memory, and any other type of memory may each include multiple different memory devices located in multiple separate locations and each having a different structure. Memory 904 may include remotely hosted (e.g., cloud) storage.

[0104] Examples of memory 904 may include RAM, ROM, flash memory, non-transitory computer readable media such as EEPROM, any type of optical storage disk such as DVD, Blu-Ray® disk, magnetic storage, holographic storage, HDD, SSD, any medium that can be used to store program code in the form of instructions or data structures, etc. Any of the methods, functions, and operations described herein may be embodied entirely in tangible form and / or in non-transitory machine readable code (e.g., interpretable script) stored in memory 904.

[0105] The input-output devices 906 may include any components for trafficking data, such as ports, antennas (e.g., transceivers), printed conductive paths, etc. The input-output devices 906 may enable wired communication via USB, DisplayPort, HDMI, Ethernet, etc. The input-output devices 906 may enable electrical, optical, magnetic, and holographic communication with the appropriate memory 904. The input-output devices 906 may enable wireless communication via WiFi, Bluetooth, cellular (e.g., LTE, CDMA, GSM, WiMax, NFC), GPS, etc. The input-output devices 906 may include wired and / or wireless communication paths.

[0106] The sensors 908 can capture physical measurements of the environment and report them to the processor 902. The user interface 910 can include a display, physical buttons, a speaker, a microphone, a keyboard, etc. The actuators 912 can enable the processor 902 to control mechanical forces.

[0107] The processing system 900 may be distributed. For example, some components of the processing system 900 may reside on a remotely hosted network service (e.g., a cloud computing environment), while other components of the processing system 900 may reside on a local computing system. The processing system 900 may have a modular design such that some modules include multiple features / functions illustrated in FIG. 9. For example, an I / O module may include volatile memory and one or more processors. As another example, individual processor modules may include read-only memory and / or a local cache.

[0108] Below, further background and description of exemplary embodiments of the present invention are provided in further detail, which may overlap with some of the information given above. To the extent that the terminology used to describe the following embodiments may differ from the terminology used to describe the preceding embodiments, those skilled in the art will understand that some terms correspond to each other in different embodiments. Features described below may be combined with features described above in various embodiments.

[0109] CTI plays a crucial role for organizations in assessing risk and improving security. However, the process of extracting critical information from unstructured text sources can be expensive and time-consuming. Empirical experience to date shows that existing tools for the automated extraction of structured CTI have performance limitations. Moreover, the current community lacks a common benchmark to quantitatively assess their performance.

[0110] It is recognized in the present invention that these gaps can be filled by providing a new large-scale open benchmark dataset and an embodiment of the present invention, a structured CTI information extraction tool called "aCTIon". The dataset contains 204 real-world publicly available reports and their corresponding structured CTI information in STIX format. The dataset was curated by three independent groups of CTI analysts over several months of work. The dataset is two orders of magnitude larger in size than previously published open source datasets. aCTIon was then designed to leverage recently introduced LLMs (e.g., Generating Pre-training Transformer 3.5 (GPT3.5)) in the context of two custom information extraction pipelines. aCTIon was compared to 10 policies presented in previous studies, and implementations were provided for those policies when no open source implementations existed.

[0111] aCTIon outperforms previous work on structured CTI extraction, improving F1 scores by 10% to 50% points across all tasks.

[0112] CTI provides security practitioners with the information they need to protect against cyber threats and respond to attacks. When structured in a standard format such as STIX, CTI can be used with automated tools and for efficient search and analysis. However, while many sources of CTI are structured and include IoCs such as Internet Protocol (IP) address block lists and malware signatures, most CTI data is usually presented in unstructured formats, for example text reports or articles. This form of CTI has proven useful to security practitioners as it typically contains information about the attacker (threat actor) and victim (target), and how the attack is carried out, i.e., the tools (malware) and attack patterns. This is the information that typically enables threat hunting activities.

[0113] Given the importance of CTI, even with limited resources, security analysts may spend a large amount of time manually processing sources of CTI to structure the information in a standard format. In fact, this effort is large enough that companies can organize organizations to share the structured CTI and the costs of producing it. For example, the CTA provides a platform for sharing CTI among its members in the form of STIX bundles, and its members are more than 30 large companies such as CISCO, MCAFEE, SYMANTEC, SOPHOS, and FORTINET.

[0114] To aid in this effort, the security community has been actively researching ways to automate the process of extracting information from unstructured CTI sources, which has led to the development of several methods and tools. While these methods help reduce the burden on analysts, to date, their focus has been limited to the extraction of IoCs, which are relatively easy to identify using pattern matching methods (e.g., regular expressions). Only recently have advances in NLP using deep learning enabled the development of methods that can extract more complex information (e.g., threat actors, malware, targets, and attack patterns). Nevertheless, the performance of these methods is still limited.

[0115] It is recognized in embodiments of the present invention that one of the problems may be the way these ML strategies work. That is, they are often general-purpose NLP machine learning models that have been specialised and fine-tuned for the cybersecurity domain. Fine-tuning is done by providing the machine learning model with a training dataset that is built by manually labelling a large number of reports. However, these AI models are specifically designed to perform tasks such as NER, which are closer to what security analysts want, but are still different. For example, a report describing the use of a new malware may mention other known malware in a general introduction. Although these malware would be extracted by a common NER model, security analysts would ignore them when putting together a structured report. That is, the generation of structured CTI reports requires the extraction of only important named entities. To make matters worse, the current security community lacks large labelled datasets that can serve as a benchmark for evaluating these tools. Indeed, the current state of the art is mostly evaluated using metrics that belong to the NLP domain, which essentially evaluate subtasks instead of the end-to-end tasks performed by security analysts.

[0116] Embodiments of the present invention can provide a means for evaluating existing and future tools for the extraction of structured CTI information and a route to improving the state of the art.

[0117] First, a labeled dataset containing 204 reports collected from well-known CTI sources and their corresponding STIX bundles is provided. These reports vary in content and length, containing an average of 2133 words and a maximum of 6446 words. Trained security analysts scrutinized the reports over several months and defined the corresponding STIX bundles. This process required, among other things, classifying the attack patterns (tactics, techniques, procedures) using the MITRE ATT&CK matrix, which contains more than 340 detailed entries. To make a correct classification, analysts need to know these techniques and understand whether the cases described in the reports fit any of them.

[0118] Next, the results of 10 recent studies are replicated, providing implementations when these were not available and using benchmark datasets to evaluate them. The evaluation shows that improvements in NLP techniques have had an impact on the performance of the tools, which have improved significantly over time with the inclusion of NLP techniques such as transformer neural networks (e.g., BERT). At the same time, the evaluation shows that there are gaps, with the best-performing tools achieving average recall / precision across all reports below 50% for any given type of information extracted (e.g., malware, threat actors, targets, and attack patterns).

[0119] Finally, inspired by the recent evolution of LLMs such as GPT3, a new approach from an embodiment of the present invention, aCTIon, is provided using the zero-shot prompting and in context learning capabilities of LLMs. This approach addresses some of the main shortcomings and limitations of the current generation of LLMs in the constrained environment of use cases, especially hallucination and small context windows. To do so, a novel two-step LLM querying procedure is introduced in place of recent approaches used in the design of LLM-based generative AI agents. In the first step, the input report is preprocessed to extract and condense information into text that can fit within the constraints of the target LLM. In the second step, extraction and self-validation prompts are defined for the LLM, which finally selects and classifies the extracted information. There are several alternative variants of the general approach above, and an embodiment of aCTIon is able to outperform the state of the art by increasing the F1 score by 15-50% points for malware, threat actor, and target entity extraction, and about 10% points for attack pattern extraction.

[0120] This improvement from past research was beyond expectations, and aCTIon embodiments were immediately tested internally for daily CTI operations. A human study of the results was performed to examine failure cases. From manual analysis and experience, it was inferred that aCTIon's performance is comparable to that of trained security analysts. There is inherent semantic uncertainty when structuring CTI information (e.g., what is considered to be an important entity by analysts may vary). However, this finding may not be confirmed without different teams of security analysts re-labeling the dataset and measuring their agreement with the labels already provided. To aid further research in this area, we will make the dataset containing the reports and labels publicly available.

[0121] The Life and Tribulations of a CTI Analyst: A huge amount of valuable CTI is shared in unstructured formats, including open-source intelligence (OSINT), social media, the dark web, industry reports, news articles, government intelligence reports, and incident response reports.

[0122] Unstructured CTI is difficult to use because it cannot be efficiently stored, categorized, and analyzed, and can force security experts to fully read and understand lengthy reports. As a result, one of the tasks of security analysts is to convert large amounts of unstructured CTI information into a format that simplifies further analysis and use.

[0123] STIX is an example of a standard format for CTI that has been widely adopted by the industry. In STIX, each report (or bundle in STIX terminology) is a knowledge graph, a set of nodes and relationships that describes, for example, a security incident or a significant event. The STIX ontology describes all the entities and relationship types, and Figure 6 shows a subset of the STIX ontology that includes all the entities and relationships that are included at least once in the dataset. The ontology includes several conceptual entities, such as threat actor, malware, vulnerability, attack pattern, and indicator. In addition, it also defines relationships between these entities to capture their interactions, such as uses and targets.

[0124] Example reports are provided to demonstrate how analysts extract structured STIX bundles from text reports. The most common information extracted by analysts is: - Who carried out the attack (e.g., the threat actor), - Against whom it was perpetrated (e.g. the identity indicated by the target relationship), and - How the attack was carried out (e.g. malware and attack patterns) It is.

[0125] This subset of the STIX ontology is the most common set of information included in the reports: for example, in our dataset, 75% and 54% of reports contain at least malware and threat actor entities, respectively. Additionally, and perhaps more importantly for an unbiased evaluation of the state of the art, this subset is consistently supported across existing tools and previous research, allowing for comprehensive comparisons between approaches.

[0126] Structured CTI Extraction: A technical blog post by Palo Alto Networks, part of which is presented in Figure 7, illustrates the task of structured CTI extraction. The report describes the attribution of the HelloXD ransomware to a threat actor known as x4k, including a set of tactics, techniques, and procedures associated with them. The report is approximately 3700 words long and contains three tables with a list of 24 different images, different information, and compromise indicators (located in a dedicated section at the end of the report). It first describes the functionality of the HelloXD ransomware, which in turn reveals several clues that link the ransomware to the threat actor x4k. Furthermore, the post describes the threat actor's modus operandi and infrastructure.

[0127] Structured CTI extraction is performed to define a STIX bundle 800 representing the report, such as the one shown in Figure 8. The bundle includes a set of attack pattern entities (e.g., Attack Patterns 810, 812) that describe the threat actor 802 (x4k), the malware (HelloXD), and various targets (e.g., WINDOWS and LINUX systems 804), tactics, techniques, and procedures, as well as indicators (e.g., IoC #1 808, IoC #154 806) extracted from the final portion of the report.

[0128] Defining these bundles is a time-consuming task that requires security knowledge and experience. Extracting a structured STIX bundle from a report can take 5-10 hours. For example, the authors mention that it took three full-time annotators five months to label 133 reports. Similarly, it took a team of CTI analysts several months to annotate the 204 reports in the database.

[0129] As explained above, Figure 7 shows an example of a collection of materials for a report published by PALO ALTO NETWORKS. While IoCs are collected at the end of the report and are easy to extract, extraction of threat actors, malware, attack patterns, and other STIX entities may require security experts to perform manual analysis. Figure 8 shows a STIX bundle that describes the report from Figure 7.

[0130] To understand why this task is time consuming and difficult to automate, an embodiment of how an analyst identifies important entities and a sample report example are described below.

[0131] Malware, threat actors, and identities come first: An analyst can start by identifying malware, threat actors, and identities. While this may seem like a simple task at first glance, security reports tend to be semantically complex and include issues such as: Information is represented ambiguously, e.g., threat actors and malware are referred to by the same name; Aliases are used to describe the same entity, e.g., malware is referred to by multiple name variants; Attribution of attacks is uncertain, e.g., a report may confidently attribute some attacks to a threat actor, while other attacks may only be mentioned as possibly related to that threat actor but are not confirmed. These are just a few examples of nuances that can make the process time-consuming and difficult to automate.

[0132] Example: The sample report specifically discusses HelloXD ransomware. However, it is not common for malware to be deployed and utilized alongside other malicious software. Therefore, understanding which malicious software is substantially described in the attack helps understand which malware nodes should be included in the STIX bundle. There are references to two other malware besides HelloXD in the report, namely LockBit 2.0 and Babuk / Babyk. However, these malware should not be included in the bundle. For example, LockBit 2.0 is mentioned because it utilizes the same communication methods used by HelloXD (see quote below). Nevertheless, LockBit 2.0 is not directly related to HelloXD infections and should not be included.

[0133] The ransom note also instructs victims to download Tox and provides a Tox Chat ID to contact the threat actors. Tox is a peer-to-peer instant messaging protocol that offers end-to-end encryption and has been observed being used by other ransomware groups for negotiations. For example, LockBit 2.0 utilizes Tox Chat for communication with threat actors.

[0134] Attack Pattern 2: The analyst can identify attack patterns, e.g., descriptions of tactics, techniques, and procedures, and attribute them to entities identified in the previous step. This brings additional challenges: attack patterns are behaviors that are usually described over several paragraphs of a report, which are collected and classified in a standard taxonomy, such as the MITRE ATT&CK Matrix. The MITRE ATT&CK Matrix contains more than 340 detailed techniques and more than 450 subtechniques. The analyst can refer to them when building the bundle and identify which of the classified techniques are included in the text report. This task may require both understanding of the report and extensive domain expertise.

[0135] Example: The sample report contains 18 different attack patterns. For example, the quote provided above relates to technology T15732, which is described as follows:

[0136] "Adversaries may utilize known encryption algorithms to hide their command and control traffic rather than relying on the inherent protections offered by communications protocols..."

[0137] Importance throughout the process: Analysts can use their experience to make decisions about what to exclude from the bundle. This decision usually involves considering the reliability and detail of the information described in the report. For example, the sample report describes other activities for threat actor x4k, such as the deployment of Cobalt Strike Beacons and the development of a custom Kali Linux distribution. The analyst must decide whether to include this information. In this example, these other activities are only mentioned and may not be relevant (contain sufficient detail) to the main topic of the report and therefore should not be included.

[0138] Pursuing Automation: Given the complexity of the task, several approaches have been proposed to help automate structured CTI extraction. Previous work has either addressed individual problems, such as attack pattern extraction, or automating the entire task. Nevertheless, all previous tools may still require significant human effort to be performed. An empirical study of a team of CTI analysts supports this assertion, and the evaluation disclosed herein corroborates this.

[0139] One of the reasons why existing approaches do not meet the expectations of CTI analysts may be the lack of benchmarks that properly represent the structured CTI extraction task with its nuances and complexities. Specifically, since previous research relies heavily on ML methods for NLP, it is quite common to rely on typical NLP evaluation methods. However, since NLP tasks are a conceptual subset of end-to-end structured CTI extraction tasks, the majority of proposed benchmarks do not evaluate CTI metrics.

[0140] To illustrate this problem, we start with NER, an NLP task of automatically identifying and extracting important entities in a text. When evaluating the NER component, NLP metrics can count how many times a word representing an entity is identified. For example, if the malware HelloXD is mentioned and identified 10 times, a normal NER evaluation would consider it 10 independent correct samples. This technique is called word-level labeling. For simplicity of explanation, the term "word-level" is used instead of the more appropriate "token-level". However, in structured CTI extraction, the interest is to extract malware entities regardless of how many times they appear in the report. This can lead to an overestimation of the method's performance. More subtly, as seen in the Lockbit 2.0 malware example, some entities that would be correctly identified by a NER tool are not necessarily important for the CTI information extraction task. However, such entities are usually counted as correct when the evaluation employs normal NLP metrics. The same problem applies to more complex attack pattern extraction methods. In fact, those methods are commonly evaluated on a sentence classification task, which assesses the method's ability to recognize whether a given sentence is an attack pattern and assign it to the correct class. This approach is called sentence-level labeling. However, such metrics do not fully capture the performance of the method in terms of CTI metrics, which entails identifying all the important attack patterns in a given report and correctly attributing them to the relevant entities.

[0141] [Table 1]

[0142] Table 1 summarizes the datasets from the literature that are utilized in the evaluation of each previous study. The table considers the extraction of attack pattern entities separately, given that attack pattern entities are more complex compared to other entities (e.g., malware, threat actors, identities). Some of these studies use significantly larger datasets to evaluate the extracted information in terms of NLP performance (e.g., number of entities extracted). Unfortunately, they often include much smaller data subsets to validate the methods in terms of CTI metrics. One reason often cited for the small size of such data subsets is the inherent cost of performing manual annotation by expert CTI analysts.

[0143] The NLP metrics SecIE, ThreatKG, and LADDER all employ datasets with word-level or sentence-level labeling. Similarly, CASIE provides a large-scale word-level labeled dataset and does not cover attack patterns. TRAM and rcATT provide sentence-level labeled attack pattern datasets.

[0144] CTI Metrics: Several studies provide labeled data that captures CTI metrics correctly. TTPDrill and AttacKG perform manual labeling of 80 and 16 reports per report, respectively, but unfortunately do not share them. Also, they only cover attack pattern extraction. SecBERT evaluates its performance on a large-scale sentence-level dataset, but provides only six reports with CTI metrics. Similarly, as part of its evaluation, LADDER also includes an attack pattern extraction task using CTI metrics, but only for five reports (which are not shared publicly).

[0145] Dataset: The lack of an open and sufficiently large dataset focusing on structured CTI extraction can make it difficult to evaluate existing approaches and stably improve the state of the art. To fill this gap, embodiments of the present invention created a new large-scale dataset containing 204 reports and their corresponding STIX bundles, as extracted by an expert team of CTI analysts. The dataset represents real-world CTI data, as processed by security experts, and therefore focuses exclusively on CTI metrics. The dataset has been made publicly accessible.

[0146] Information about how the dataset was created is disclosed herein, and high level statistics about the data are introduced.

[0147] Methodology: The organization includes a dedicated team of CTI analysts whose primary task is to perform structured CTI extraction from publicly available sources of CTI. A methodology is established to leverage the expertise of that team to collect a set of 204 unstructured reports and their corresponding extracted STIX bundles. The structured CTI extraction is performed manually by multiple CTI analysts organized into three independent groups with different roles as outlined below:

[0148] Group A selects unstructured reports or sources of information for structured CTI extraction. This selection is based on the analyst's expertise and is often informed by both observed global trends and unique internal requirements. For example, a report focused on a threat likely to affect the organization and its customers.

[0149] Group B performs a first pass of structured CTI extraction from the selected sources. This group makes extensive use of existing tools to simplify and automate information extraction, such as tools like TRAM. Note that this set of tools overlaps with the tools mentioned in Table 1 and assessed later in the evaluation. The actual structured CTI extraction is performed in multiple processing steps. First, the reports are processed using an automatic parser, for example to extract text from web sources. Second, the retrieved text is fragmented into a group of sentences. These sentences are then manually analyzed by an analyst, who may further split, combine, or remove sentences to properly capture concepts and / or remove noise. The final result is a set of paragraphs. Third, the analyst applies an automated tool to pre-label important named entities, and then performs a manual analysis on each single paragraph that flags entities that are deemed correct and possibly adds entities that were not detected. Fourth, a second analysis is performed on the same set of paragraphs, this time to extract attack patterns. Also in this case, the analyst uses a tool like TRAM to perform pre-labeling and identification of attack patterns, then performs manual analysis to flag correct labels and add missing ones. Finally, the analyst uses a visual STIX bundle editor (a GUI built inside) to validate the bundle and ensure any correct attributions, e.g., definition of relationships between entities.

[0150] Group C performs an independent review of the work performed by Group B. This review involves a single-step manual examination performed by Group B, with the goal of accepting or rejecting the extracted STIX bundle.

[0151] The above process is further aided by a software infrastructure specially developed by the organization to simplify the task of manual structured CTI extraction. Analysts connect to a web application and are provided with a convenient pre-established pipeline of tools. Furthermore, the web application tracks their interactions and roles (e.g. analyst vs reviewer) and additionally tracks the time spent for each sub-step of the process. This allows an estimation of the time spent to perform structured CTI extraction for the reports (excluding the work of group A). ​​For the dataset presented herein, an average of 4.5 hours per report is observed, with the majority of the time spent by group B (around 3 hours).

[0152] Using this methodology, 204 reports and their corresponding STIX bundles were collected to create the basis of the dataset. Additional manual processing steps were then performed to ensure accuracy and completeness. First, only reports that were publicly available on the Internet were selected, and the reports were checked to ensure that all information in the STIX bundle was included in the original report. This is a safety check to ensure that analysts do not include entities or relationships that may be inferred from their own experience. This step further ensured that no sensitive information was shared in the dataset. The structured CTI extraction task places a large cognitive burden on the analyst. A fatigued analyst may include information that is read from a similar source and is not necessarily included in the processed report. Second, any spelling errors in the named entities of the STIX representation were verified and corrected. Since malware and threat actor names can be complex, spelling errors may occur even after the review of Group C. For manual processing of structured CTI, this is not a big problem because analysts can easily recognize spelling errors. Nevertheless, for automated benchmarking, these errors may lead to erroneous results. Third, a list of synonyms for each named entity in the report was extracted. This was done because the same malware or threat actor may be referred to using different names in the same report. This information is not officially included in the STIX standard and may be included or represented differently depending on the entity processing the report. However, it is essential for a correct evaluation, since synonymous references should be considered correct extractions.

[0153] Dataset Summary: The resulting dataset comprises 204 STIX bundles, which contain a total of 36,100 entities and 13,600 relationships. Figure 6 presents a STIX ontology 600 derived based on the dataset, which includes nine unique entity types (e.g., identity 602, tool 604, course-of-action 606, vulnerability 608, attack-pattern 610, indicator 612, threat-action 614, campaign 616, and malware 618) and five unique relationship types (e.g., targets 620, uses 622, mitigates 624, attributed to 626, indicates 628). Figure 6 also illustrates a set of allowable types of relationships between certain pairs of entity types.

[0154] [Table 2]

[0155] Table 2 reports data statistics by report and is divided into four sections: word and sentence counters, total number of STIX objects and relationships, number of STIX objects by type, and number of STIX relationships by type. For the last two sections, the last column provides the quota of reports that contain an entity of a given type at least once. For example, 75% of bundles contain malware entities and 54% contain threat actors. This highlights the prevalence of these important components in the dataset and clarifies their importance in the context of CTI extraction and analysis.

[0156] This is where aCTIon comes in: The dataset introduced makes it possible to quantify the performance of existing tools for structured CTI extraction. Those results will be presented in detail later, but here we expect that the empirical experience so far will be confirmed, i.e. the performance of previous studies for structured CTI extraction is still limited. For example, the best performing tools in the state of the art provide at best an F1 score of only 60% when extracting entities such as threat actors or attack patterns.

[0157] Considering the pressure to reduce the cost of structured CTI extraction in organizations, and the constraints of the state of the art, an embodiment of the present invention called aCTIon, a structured CTI extraction framework, has been developed. This embodiment attempts to completely replace the information extraction step from a task, e.g., the work of Group B, and leave only the bundle review step to the CTI analyst.

[0158] Since aCTIon builds on the recent emergence of powerful LLMs, a brief background on this technology is provided before detailing aCTIon's design goals and decisions.

[0159] LLM Primer: LLMs are a family of neural network models for text processing, generally based on transformer neural networks. Unlike past language models, which are trained on task-specific labeled datasets, LLMs are trained using unsupervised learning on large amounts of data. While their training goal is to predict the next word, given an input prompt, the scale of the models combined with the large amount of ingested data allows LLMs to solve a multitude of previously unseen tasks and acquire emergent behaviors. For example, LLMs can translate from / to multiple languages, perform data analysis and extraction, classification, summarization, etc. More remarkably, these emergent capabilities include creative language generation, reasoning and problem solving, and domain adaptation.

[0160] From a system builder's perspective, perhaps the most interesting emergent capability of LLMs is their ability to learn in context and follow instructions: users can program the behavior of LLMs and prompt them with specific natural language instructions. This can eliminate the need to collect specific training data for each task, allowing for their flexible inclusion in the system design. For example, a prompt such as "Summarize the text below" is sufficient to generate a high-quality summary.

[0161] Although LLMs have great potential, there are other considerations. First, their training can be expensive, so they can only be retrained infrequently. This can prevent LLMs from keeping up with current knowledge. Second, their prompt inputs and outputs can be limited in size. LLM inputs can be first tokenized and then provided to the LLM. A token can be considered a part of a word. For example, a model may limit the total size of inputs and outputs to 4000 tokens (approximately 3000-3500 words), which limits the types of inputs that can be processed. Finally, LLMs can generate incorrect outputs, a phenomenon sometimes called hallucination. In such cases, the answers generated by the LLM are inaccurate, incorrect, or even completely false, despite what may appear to be confident statements at first glance.

[0162] aCTIon - Design: Figure 10 shows the overall architecture 1000 of an embodiment of the aCTIon framework as a high-level architecture, which may comprise three main components. The downloader and parser 1004 converts unstructured input reports 1002 in various formats, e.g. HTML, into text-only representations (e.g. raw text 1006) in various formats. It includes plugins to handle the formats of certain well-known CTI sources, as well as a fallback default mode in case no plugin is available for the desired source. The second component 1006 is the core of the aCTIon framework and consists of two different pipelines. The pipeline 1008 extracts most of the entities and relationships, while the second pipeline 1010 specifically deals with attack pattern extraction. Both pipelines 1008, 1010 implement a two-stage process and leverage the LLM at different stages. These two stages include preprocessing (P) 1012 to select important text from the unstructured input report, and extraction (E) 1014 to select and classify target entities.

[0163] The LLM 1016 can be provided as a service through API access. Although in principle different providers are possible (including self-hosting), aCTIon currently supports the entire GPT family from OpenAI. In one embodiment of the invention, it is possible to focus on the GPT-3.5-turbo model. When present, the CTI analyst 1022 can customize and correct the output of the LLM 1016 and / or the prompts for the LLM agent 1024.

[0164] Finally, a data exporter 1020 parses the output of the pipeline (e.g., the extracted data 1018) to generate a desired output format 1024, e.g., a STIX bundle.

[0165] Design Challenges and Decisions: aCTIon’s two-stage pipeline can be designed to address two main challenges faced during the design phase. First, one concern was related to the handling of hallucinations of the LLM, such as bogus malware names. To minimize the occurrence of such situations, the LLM can be used as a reasoner rather than relying on its search capabilities. That is, the LLM can be instructed to use only information contained in the input it is given. For example, a definition of the entities to be extracted can be provided even if the LLM has in principle acquired knowledge of such entity definitions during training. Still, this approach may not provide strong guarantees on the output produced, since it may rely only on prompt engineering. Therefore, additional steps can be introduced with the aim of validating the LLM’s answers. These steps can be of various types, including a second interaction with the LLM to perform self-checking activities. The LLM can be prompted with different requests for the same task with the aim of validating consistency. Finally, the CTI analyst can be kept in an output validation loop, including in the procedure of the STIX bundle review step.

[0166] A second challenge may relate to input size constraints. An embodiment of the present invention may support a sharing of 4000 tokens between the input and output sizes. This amount of tokens may be sufficient for (i) instruction prompts, (ii) any definition of what is a malware entity, etc., (iii) the entire unstructured input text, and (iv) the generated output. Considering that reports in the dataset may be over 6000 words long, methods may be introduced to extract information from the unstructured text before performing information extraction. One approach is to introduce a pre-processing step in the pipeline to summarize and select text from the unstructured input for filtering purposes. As in the case of self-check activities, LLMs may be leveraged to perform text selection and summarization.

[0167] Entity and Relationship Extraction Pipeline: For the entity and relationship pipeline, the preprocessing step can perform iterative summarization. First, the input text may be split into chunks of sentences, and then each chunk may be summarized using LLM, with the following preprocessing prompts:

[0168] Write a brief summary of:

[0169] {text}

[0170] Short summary:

[0171] The generated summaries can be strung together in a new text that is small enough to fit into the LLM input. This process can be repeated iteratively, although a single iteration may be sufficient.

[0172] The extraction stage takes as input the summarized report and can execute as many prompts as there are entities / relationships to be extracted. Each given prompt may contain (i) a definition of the entity to be extracted, and / or (ii) a direct question naming such an entity. A (partial) example of an entity extraction prompt is as follows:

[0173] Use the context below to answer the last question.

[0174] {context}

[0175] Question: Who / what is the target of the described attack?

[0176] After extraction, the pipeline can perform a verification step, querying the LLM to verify that the extracted entities / relationships are present in the original text and reporting an error in case of a mismatch. The verification step may not report any errors.

[0177] Attack Pattern Extraction Pipeline: Extracting attack patterns is very different from extracting simpler entities. As introduced before, the task can be about identifying behaviors described in the text and associating them with behavior definitions according to the MITRE ATT&CK Matrix taxonomy. Considering the potentially large number of attack patterns in the MITRE ATT&CK Matrix, it can be inefficient (and expensive) to directly query the LLM for each attack pattern definition and group of sentences in the input report. If a report has 10 paragraphs to be investigated, considering that there are more than 400 techniques described in the MITRE ATT&CK Matrix, more than 4000 LLM requests can be used for a single report.

[0178] Another approach can be relied upon: the similarity between embeddings of the report sentences and embeddings of examples of attack pattern descriptions can be checked. Embeddings are encodings of sentences generated by a language model. The language model can be trained so that sentences with similar meanings have close embeddings according to some distance metric (e.g., cosine similarity). Thus, the extraction stage of the pipeline can compare the similarity between embeddings of the report sentences and embeddings generated for examples of attack patterns provided by MITRE.

[0179] However, unlike the state of the art, the pre-processing stage may be designed with the goal of generating various descriptions for attack patterns that may be the same as those included in the report. Here, an observation may be that attack patterns may be described in very heterogeneous ways. Thus, for pre-processing, the goal may be to generate multiple descriptions of the same attack pattern and increase the ability to discover similarities between such descriptions and taxonomy examples. Specifically, three different description generation strategies may be introduced:

[0180] The first strategy can prompt the LLM to extract blocks of raw text or sentences that clearly contain a formal description of the attack pattern. The output of this strategy can typically be a paragraph, or possibly a single sentence. Below is a prompt for an exemplary attack pattern extraction preprocessing strategy #1:

[0181] Use the following portion of a long document to see if any of the text is important to answer the question. Return any significant text word for word.

[0182] {text}

[0183] Question: What techniques are being used by the attackers? Report only the significant text, if any.

[0184] The second strategy can leverage the reasoning capabilities of the LLM to prompt the LLM to describe the attacker's events step by step and attempt to identify implicit descriptions. The output of the second strategy can be a paragraph. Below is an example Attack Pattern Extraction Preprocessing Strategy #2 prompt:

[0185] Describe the important facts in the following text step by step:

[0186] {text}

[0187] Key Facts:

[0188] Finally, the third strategy can apply sentence segmentation rules to the input text and provide a single sentence as output.

[0189] All three selection strategies' outputs can be passed to an extraction step where they can be individually checked for similarity with MITRE taxonomy examples. A similarity threshold can be empirically determined, after which the scrutinized text blocks can be assigned to the attack pattern classification of the corresponding MITRE taxonomy example.

[0190] Evaluation: The desire to reduce the effort of CTI analysts in organizations led to the testing of many approaches and previous research. An evaluation of the inventive embodiment of aCTIon is presented herein in comparison with such approaches, which are considered as a performance baseline. First, the baseline implementations (which have not always been available in open source) and evaluation metrics are presented, and then the results and ablation studies on the deployed dataset are presented.

[0191] Selection and implementation of baselines: For the implementation of the baselines, the following principles were followed. First, an attempt was made to include at least one representative method for each family of NLP algorithms used in the literature. Second, whenever possible, the original open source implementation of the method was used. When this was not possible, we relied on the original implementation of the underlying NLP algorithm. Third, where possible, all methods were trained or fine-tuned using the same dataset. The tested NLP-based methods can be exploited in two different ways. One approach can be to train them on generic data and use them directly (later called domain agnostic models). Another approach can be to further fine-tune them on CTI-specific data before using them. Finally, default hyperparameters can be used as described. The measures taken are disclosed herein with the embodiments of the invention focusing on generic entity and relationship extraction, and with the embodiments of the invention dealing with attack pattern extraction.

[0192] Entity and Relationship Extraction: NER strategies are a fundamental building block of previous research. The three main families of models used for state-of-the-art NER tasks are convolutional neural networks (CNNs), BiLSTMs, and transformers. Among previous work targeting structured CTI extraction, GRN relies on CNNs, ThreatKG and CASIE are based on BiLSTMs, and FLERT and LADDER are based on transformers. For CNN and BiLSTM methods, the models can be trained end-to-end specifically for the entity extraction task. Instead, transformer-based methods may rely on pre-trained language models that are trained on either a general-domain corpus or a corpus that contains both general and domain-specific documents. These models can then be fine-tuned on a labeled dataset for the entity extraction task. For all methods, a word-level CTI dataset can be used. This dataset may consist of a CTI corpus, in which individual words in sentences have been annotated with tags that identify named entities according to a particular CTI ontology and a particular format, such as the BIO format.

[0193] Labeling for this task can be complex and time-consuming and may require cross-domain expertise. CTI experts may also need to be familiar with NLP annotation techniques, which may make the generation of such a dataset difficult. Therefore, publicly available datasets can be relied upon. All selected models may be trained on the same dataset, using the same training / testing / validation set split to ensure a fair comparison. In an embodiment of the present invention, a word-level dataset may be used, which has also been used in previous studies. This dataset may be chosen because it is the largest open source dataset available and is labeled according to an ontology that can be easily mapped to STIX. The trained methods and tools can then be run using the chosen dataset, since it may focus on CTI metrics.

[0194] For CNN-based NER, the original open-source implementation of GRN may be used. For BiLSTM-based models, a domain-independent open-source implementation may be used. Indeed, ThreatKG may not provide open-source versions of their models, and CASIE does not provide an open-source implementation, which may not be directly adaptable to the datasets used to train other models. Also, those datasets are labeled according to ontologies that may differ significantly from STIX and therefore cannot be used for a fair comparison. Finally, for transformer-based models, two baselines are presented: one is the original implementation of LADDER as a domain-specific tool, and the other is a domain-independent NER implementation based on FLERT using an open-source implementation.

[0195] Attack Pattern Extraction: For the attack pattern extraction task, a wide range of methods can be evaluated: template matching (TTPDrill, AttacKG), ML (rcATT, TRAM), LSTM (cybr2vec LSTM), and transformers (LADDER, SecBERT). All baselines can provide either pre-trained models or their own datasets to run the training on.

[0196] The methods can utilize datasets based on the same taxonomy (e.g., MITRE ATT&CK) and extracted directly from the same source, either MITRE attack pattern descriptions or samples of MITRE attack pattern descriptions (both provided by MITRE). Given the high similarity of the datasets in this case, each model can be trained using their unique dataset. The methods can be evaluated using their initial open source implementations.

[0197] Performance Metrics: Each method can be compared against the ground truth (GT) from the dataset using the following metrics: Recall: The percentage of unique entities in the GT that were correctly extracted. Precision: The percentage of unique extracted entities that are correct (e.g., part of the GT) F1 score: the harmonic mean of precision and recall

[0198] For clarity, in the remainder of this section, "entities" can refer to both entities and attack patterns, e.g., the results of the two extraction tasks. From a high-level perspective, recall indicates how well GT entities are covered by the method for a given report. Precision is not, and is affected by incorrect (e.g., false positive) extracted entities, e.g., those that are extracted as the wrong type or that the human annotator has not selected as important enough. Conversely, true positives refer to entities that are correctly identified as the appropriate type and with the same text as in GT. Finally, false negatives refer to entities that are present in GT but missed by the method at hand.

[0199] A tool that extracts all possible entities of a given type may have a very high recall but a very low precision. Another tool can balance both metrics, for example when used to help a human operator with the annotation task, who would otherwise spend a lot of time on confirmation results with many false positives. To further explore this aspect, the number of entities reported by each tool can be provided and compared with the numbers from GT. Based on a brief analysis on GT, the above investigation can be performed for the attack pattern extraction task, since attack patterns are an order of magnitude more numerous than other types of entities, making this issue particularly important.

[0200] In the following subsections, these metrics can be calculated for malware, threat actors, identities pointed to by target relationships (which can be called targets), and attack patterns. The same methodology can be employed to calculate the metrics for each report and then provide aggregate statistics. Given the nature of GT (where some reports only have 0 or 1 entity of a given type), some metrics show a bimodal distribution across reports, e.g., they can be either 0 or 1. Violin plots were chosen instead of box plots to make the underlying distribution of values ​​more visible. Nevertheless, both the average across reports (with markers) and the 25th and 75th percentiles (as vertical bars) are reported to show the data range at a glance.

[0201] Entity Extraction: Figures 11 and 12 show the results of aCTIon against the baselines for malware and threat actor entities, respectively. aCTIon outperforms the other baselines in terms of recall, precision, and resulting F1 scores for both entity extraction tasks. aCTIon achieves average recall, precision, and F1 scores of 77%, 71%, and 72% for malware entity extraction, and 84%, 78%, and 80% for threat actor entity extraction, respectively. This is an improvement of over 25 percentage points for malware and about 20 percentage points for threat actors compared to the F1 score of the best performing baseline (LADDER). To explain this performance difference, baseline failures were investigated and two main cases were identified: (i) baselines may fail to understand when an entity is not important to the target STIX bundle, and (ii) baselines may be prone to erroneously including entities that are conceptually close to the entity of interest (e.g., selecting named software instead of malware).

[0202] For example, when considering the example report, the baseline may identify HelloXD as malware, resulting in the same recall performance (for this particular report) as achieved by aCTIon. However, the precision may be much lower. This is because the baseline method may include entities such as Lockbit 2.0 and x4k (the threat actor's name and several of its aliases) in the detected malware. In addition, the baseline method may also include a wide range of legitimate applications such as Tox, UPX, Youtube, and ClamAV. For example, in the following extract, the baseline identifies ClamAV as malware in contrast to aCTIon:

[0203] "We are led to believe that ransomware developers may prefer to use the ClamAV brand for their ransomware."

[0204] Figure 13 shows the results for extracting target entities, with aCTIon outperforming LADDER in recall, precision, and F1 score. This type of entity is more challenging because it may require understanding both the named entities and their relationships. LADDER and aCTIon support the extraction of this type of entity, which may involve assessment of relationships between entities. Consider the extraction of the following:

[0205] "HelloXD is a ransomware family conducting double extortion attacks that emerged in November 2021. During our research, we identified multiple variants affecting Windows and Linux systems."

[0206] The above sentence describes the targets of the attack "Windows and Linux systems". In STIX, they may be classified by a general identity class, which may include classes of individuals, organizations, systems, or groups. To correctly identify the target entity, it may be necessary to understand whether an identity node is an object of the "target" relationship.

[0207] Of the baselines considered, LADDER is able to extract this type of entity since it is equipped with a relationship extraction model in addition to the NER component.Despite the complexity of this task, aCTIon demonstrates its effectiveness by again significantly outperforming LADDER (F1 score about 50% points higher).

[0208] Attack Pattern Extraction: For attack pattern extraction, we focused on a subset of 127 reports that did not contain a list or table of MITRE techniques in the well-defined Txxx format in the text. For AttacKG, results were reported for 120 reports, as processing of each of the remaining seven was discontinued after more than 24 hours, which is significantly longer than any manual analysis. T1573 refers to the MITRE Technique Encrypted Channel.

[0209] Attack patterns reported in such a well-formed format can be extracted with regex-based techniques and thus potentially detected.

[0210] Figures 14a and 14b: Attack pattern extraction. aCTIon achieves good precision while outperforming other methods on recall, thereby obtaining an improvement of about 10 points on F1 score compared to the best performing baseline. The first plot in Figure 14a reports the number of attack patterns extracted from each report by the various methods (except LADDER, the baselines are different from those used in the previous task). The plot in Figure 14b reports instead the performance metrics of recall, precision, and F1 score. From a high-level perspective, the baseline methods can be divided into two groups. The first group can include "conservative" methods, e.g., methods that tend to limit the number of attack patterns extracted from each report, resulting in a lower average number compared to GT, i.e., rcATT, LADDER, TRAM, and cybr2vec LSTM. The first violin plot in Figure 14a shows the actual number of techniques per report. This group is characterized by the recall values ​​being much smaller than the precision values. The second group may instead include methods with a higher average number of extracted attack patterns than GT and similar recall and precision, namely TTPDrill, AttacKG, and SecBERT. In the first group, TRAM performs best (F1 score), while in the second group, SecBERT performs best overall.

[0211] In addition to being the best within their respective groups, these two methods may represent two different approaches to attack pattern extraction. Indeed, the former, TRAM, is a framework designed to assist experts in manual classification, and since its output should be reviewed by experts, for example, it may be important to keep the precision high and the number of attack patterns to be verified low. This may be achieved, for example, by increasing TRAM's minimum confidence score from 25% (its default value) to 75%. On the other hand, the latter, SecBERT, may be designed to be fully automated.

[0212] aCTIon outperforms all baselines by about 10 percentage points in terms of overall performance (F1 score). The recall is higher than any other approach, and the average precision is about 50%. These results make manual validation by CTI analysts manageable. The average number of extracted attack patterns per report is 25 (see Figure 14a).

[0213] Ablation studies: Ablation studies were performed on the pre-processing steps for both the entity extraction and attack pattern extraction pipelines. In practice, this is useful to understand how information is selected and filtered in this step.

[0214] For entity extraction, a configuration in which the preprocessing step was included (aCTIon) can be compared to one in which it was omitted (aCTIon(w / o PP)). When omitted, the input report was provided in separate chunks if it was larger than the available input size. Figures 15 and 16 show the performance of the two different configurations when extracting malware and threat actor entities, respectively. A drop in precision was expected for aCTIon(w / o PP) since non-critical information was still present in the text during processing. In addition, the drop in performance was more pronounced for malware entities since usually only a few threat actors are present in the same report.

[0215] It is noteworthy that the preprocessing step does not result in any loss of recall, indicating that important information is not lost in the summaries produced by LLM.

[0216] In addition, for malware entities, the recall is even slightly higher for preprocessed text. Thus, reorganizing and summarizing concepts during preprocessing can aid the extraction process.

[0217] In the case of attack pattern extraction, a preprocessing module may be utilized to select and enrich text extractions that are likely to contain descriptions of attack patterns. The goal of the ablation study may be to probe how different preprocessing strategies contribute to identifying such descriptions. Four variants of the method corresponding to different preprocessing configurations may be presented.

[0218] The first configuration, aCTIon(VTE), can select verbatim text excerpts (e.g., strategy #1 mentioned above) that may contain attack patterns. This can yield several attack patterns per report with high precision (around 67%). However, this can result in lower recall, since it is not usual for all attack patterns to be explicitly described in the text. In the second configuration, aCTIon(SBSA) (e.g., strategy #2), the preprocessing can be configured to describe step-by-step actions performed during an attack, aiming to capture implicit or non-obvious descriptions of attack patterns. Using this configuration, the overall performance (F1 score) can be comparable to the best state-of-the-art method (SecBERT), but the output attack patterns per report are on average 14.4, which is half of those produced by SecBERT, on average. In the third configuration, aCTIon(VTE+SBSA) can use both preprocessing strategies together, resulting in improved performance. In addition, it shows that the proposed preprocessing methods extract non-overlapping and complementary information. Finally, the fourth preprocessing configuration, aCTIon(VTE+SBSA+OT), was chosen in Figure 14 and labeled as aCTIon, and may be reported here again. As can be seen in Figure 17, these four configurations performed to different degrees, with the fourth configuration showing the best recall and F1 score, and the first configuration showing the best precision.

[0219] Discussion: The evaluation focused on malware, threat actor, target, and attack pattern entities. This is because these entities allowed for direct comparison with previous work, whereas other entities, for example, were not widely supported by other tools. As a result, the evaluation did not cover relationship extraction extensively. Target extraction can be compared with LADDER, which includes and supports relationship extraction (of type target) (see Figure 13). However, aCTIon is able to extract any relationship defined in the STIX ontology, so performance is also assessed in that respect. For example, for all relationships between malware, threat actors, and identities, e.g., relationships of type targets and uses, aCTIon achieves an average recall of 73% and precision of 88%. The second aspect is aCTIon's ability to handle languages ​​other than English. Indeed, the chosen dataset contains 13 additional reports in languages ​​other than English, e.g., Chinese, Japanese. For such reports, aCTIon works stably and produces reported results.

[0220] Benefits of implementation: In addition to performance results, ease of deployment and maintenance may be considered in real-world environments. Compared to previous works, aCTIon relies on LLMs, which may eliminate the need to collect, annotate, and maintain datasets for various components of the pipeline of previous works (e.g., NER components). Furthermore, previous works, e.g., LADDER, may extensively use human-created heuristics (e.g., allow lists of known non-malicious software) to groom and filter the classification output. The heuristics also require continuous maintenance and adaptation. In contrast, aCTIon does not necessarily require the collection and annotating of datasets, nor the use of human-created heuristics.

[0221] Advantageously, aCTIon enables the proper use and integration of LLMs in information extraction pipelines. For structured CTI extraction, trials with this technology have given us confidence that tools like aCTIon can already do most of the heavy lifting for CTI analysts. Performance can continue to improve with the development of more powerful LLMs (e.g., GPT4) that enable larger input sizes and higher inference capabilities. Thus, recall and precision metrics can be further improved without major changes to aCTIon.

[0222] Other issues: aCTIon's current precision and recall rates are in the range of 60%-90% for most entities. This can already rival the performance of CTI analysts, and unlike human analysts, aCTIon maintains stable performance over time without suffering from fatigue. Indeed, many misclassifications may be artifacts of the ambiguous semantics associated with CTI and related standard ontologies. For example, what different analysts consider to be important entities may differ. Defining clear semantics for CTI data remains a clear challenge.

[0223] Related Work: Related work on LLM and structured CTI extraction is incorporated herein by reference below, and other work also leverages structured information. As mentioned, structured CTI can enable investigation and monitoring of activities within an organization, e.g., threat hunting, based on, e.g., TTPs. However, there are other important applications as well. Specifically, trend analysis and prediction of threats for proactive defense can utilize structured CTI. Adversary emulation tools such as MITRE CALDERA can also benefit from structured CTI, since they are typically fed with adversarial techniques based on, e.g., MITRE ATT&CK.

[0224] Conclusion: A dataset can be introduced to benchmark the task of extracting structured CTI from unstructured text, and our embodiment aCTIon can provide a strategy to automate the task.

[0225] The dataset may be the result of several months of work by CTI analysts and can provide structured STIX bundles for each of the 204 reports included. At the time of filing, the dataset is 34 times larger than any other publicly available dataset for structured CTI extraction and is the only dataset to provide complete STIX bundles.

[0226] An embodiment of the present invention, aCTIon, can be introduced, which in this embodiment is a framework that can leverage recent evolutions of LLM to automate structured CTI extraction. To evaluate aCTIon, we can select 10 different tools from the latest prior research and re-implement them if no open source implementation is available. Evaluation on the proposed benchmark dataset shows that aCTIon significantly outperforms previous approaches. Currently, aCTIon is being tested for daily production deployment.

[0227] In recent years, there has been a flurry of security product announcements based on LLMs to analyze and process CTI. However, the security community still lacks benchmarks that allow the evaluation of such tools for specific CTI analyst tasks. Furthermore, there is a lack of information on how LLMs can be exploited in this field for the design of systems. The work disclosed herein can provide both a method for benchmarking such new tools with datasets and a first set of insights on the use of LLMs in CTI tasks.

[0228] [Table 3]

[0229] Baselines with heuristics: Three additional baselines are considered, where the same post-processing heuristics are applied by LADDER to each one of the other three baselines, e.g., BiLSTM, GRN, and FLERT. These new baselines are named BiLSTM++, GRN++, and FLERT++, respectively. Post-processing heuristics were used by LADDER to remove noisy entities and resolve some ambiguities created by the NER module. As shown in Figures 18 and 19, the heuristics can increase precision because they can remove some unimportant entities. However, at the same time, the recall decreases, suggesting that the heuristics also erroneously discard some important information. Notably, when extracting malware entities, FLERT++ can reach the F1 score performance of LADDER, but LADDER is still the best-performing baseline for both types of entities.

[0230] Multilingual support: Not all CTI sources are written in English. For example, the dataset contains 13 additional reports (e.g., other than the 204 mentioned above) written in languages ​​other than English, e.g., Chinese, Japanese, and Korean. This can be problematic for analysts who not only have to have cybersecurity domain expertise, but also need to understand more than one language fluently. Automated tools can be used if they are specialized in multiple languages, but this is usually not the case. Among the baselines, LADDER includes a multilingual model (XLM-RoBERTa) that can work on reports other than English. However, this is true for the NER component in the entity extraction task. In fact, when considering a three-stage attack pattern extraction pipeline, all three stages (based on RoBERTa and Sentence-BERT) support English, which may make them unsuitable for other languages. An embodiment of the present invention is based on LLM, which is exposed during training to a large corpus of text containing various languages ​​and is therefore able to process reports in languages ​​other than English.

[0231] The performance of aCTIon was evaluated against LADDER for the entity extraction task, and the average performance across 13 reports is reported in Table 3. Overall, aCTIon and LADDER show performance differences (between 9 percentage points and 35 percentage points) comparable to those seen when analyzing English reports. For attack pattern extraction, aCTIon is able to produce usable results, with performance comparable to that obtained for English reports.

[0232] Relationship Extraction: Evaluating a relationship extraction task can be more complex than trivial entity extraction. In fact, it can be useful to include negative examples of relationships to verify that the classifier can not only confirm the presence of relationships between entities, but also their absence. Generating random non-existent syntactically correct connections is a commonly adopted approach in the state of the art.

[0233] Therefore, a benchmark is defined to evaluate aCTIon performance in extracting STIX relations between entities. As positive samples (e.g., existing relations between existing entities), all relations of malware entities, threat actor entities, and identity entities that were present in the STIX representation of the report (e.g., as extracted by the CTI analyst) are used. As negative samples (e.g., non-existent relations between existing entities), a set of randomly generated relations between entities present in the text is used. This set may also include entities extracted by the entity extraction task but removed in the final STIX representation by the CTI analyst (e.g., Lockbit 2.0 in the HelloXD report). The positive and negative samples form the evaluation dataset.

[0234] Furthermore, since the scope of the test is to benchmark only the relationship extraction capabilities, the entities extracted by aCTIon (which would automatically remove some negative samples) are not used, and this dataset is built directly from the STIX representations provided by the CTI analysts. aCTIon is configured to preprocess the text using the same compression techniques described herein and is prompted to extract relationships between the two entities using direct questions. Figure 20 shows the results for all aCTIon relationships between malware, threat actor, and identity entities, e.g., relationships of type targets and uses. On average, aCTIon achieves a recall of 73%, a precision of 88%, and an f1 score of 86%.

[0235] The above documents are incorporated herein by reference.

[0236] 2023, AttacKG GitHub repository. https: / / github.com / li- zhenyuan / Knowledge-enhanced-Attack-Graph. [Online; accessed 13-April-2023].

[0237] 2023, BiLSTM-CNN-CRF GitHub repository. https: / / github.com / UKPLab / emnlp2017-bilstm-cnn-crf. [Online; accessed 13- April-2023].

[0238] 2023, Cyber Threat Alliance (CTA). https: / / www. cyberthreatalliance.org / . [Online; accessed 13-April-2023].

[0239] 2023, FLAIR GitHub repository. https: / / github.com / flairNLP / flair. [Online; accessed 13-April-2023].

[0240] 2023, GRN GitHub repository. https: / / github.com / microsoft / vert-papers / tree / master / papers / GRN-NER. [Online; accessed 13-April-2023].

[0241] 2023, Hazy Research - From Deep to Long Learning? https: / / hazyresearch.stanford.edu / blog / 2023-03-27-long-learning. [Online; accessed 13-April-2023].

[0242] 2023, Introducing AI-powered insights in Threat Intelligence. https: / / cloud.google.com / blog / products / identity-security / rsa-introducing-ai-powered-insights-threat-intelligence. [Online; accessed 04-May-2023].

[0243] 2023, Introducing Microsoft Security Copilot. https: / / www.microsoft.com / en-us / security / business / ai-machinelearning / microsoft-security-copilot. [Online; accessed 04-May- 2023].

[0244] 2023, Introducing Recorded Future AI: AI-driven intelligence to elevate your security defenses. https: / / www.recordedfuture.com / introducing-recorded-future-ai. [Online; accessed 04-May-2023].

[0245] LADDER GitHub repository. https: / / github.com / aiforsec22 / IEEEEuroSP23. [Online; accessed 13-April-2023].

[0246] MITRE ATT&CK. https: / / attack.mitre.org / . [Online; accessed 13-April-2023].

[0247] MITRE CALDERA GitHub repository. https: / / github. com / mitre / caldera. [Online; accessed 13-April-2023].

[0248] OpenAI API. https: / / platform.openai.com / docs / api- reference. [Online; accessed 13-April-2023].

[0249] OpenAI GPT-3.5. https: / / platform.openai.com / docs / models / gpt-3-5. [Online; accessed 13-April-2023].

[0250] rcATT GitHub repository. https: / / github.com / vlegoy / rcATT. [Online; accessed 13-April-2023].

[0251] SecBERT GitHub repository. https: / / github.com / dessertlab / cti-to-mitre-with-nlp. [Online; accessed 13-April- 2023].

[0252] TRAM GitHub repository. https: / / github.com / center-for- threat-informed-defense / tram / . [Online; accessed 13-April-2023].

[0253] TTPDrill GitHub repository. https: / / github.com / SkyBulk / TTPDrill-0.3. [Online; accessed 13-April-2023].

[0254] Ehsan Aghaei, Xi Niu, Waseem Shadid, and Ehab Al-Shaer. 2023, SecureBERT: A Domain-Specific Language Model for Cybersecurity. In Security and Privacy in Communication Networks: 18th EAI International Conference, SecureComm 2022, Virtual Event, October 2022, Proceedings. Springer, 39-56.

[0255] Alan Akbik, Tanja Bergmann, Duncan Blythe, Kashif Rasul, Stefan Schweter, and Roland Vollgraf. 2019, FLAIR: An easy-to-use framework for state-of-the-art NLP. In Proceedings of the 2019 conference of the North American chapter of the association for computational linguistics (demonstrations). 54-59.

[0256] Rawan Al-Shaer, Jonathan M Spring, and Eliana Christou. 2020, Learning the associations of mitre att & ck adversarial techniques. In 2020 IEEE Conference on Communications and Network Security (CNS). IEEE, 1-9.

[0257] Md Tanvirul Alam, Dipkamal Bhusal, Youngja Park, and Nidhi Rastogi. 2022, Looking Beyond IoCs: Automatically Extracting Attack Patterns from External CTI. arXiv preprint arXiv:2211.01753 (2022).

[0258] Andy Applebaum, Doug Miller, Blake Strom, Chris Korban, and Ross Wolf. 2016, Intelligent, automated red team emulation. In Proceedings of the 32nd Annual Conference on Computer Security Applications. 363-373.

[0259] Yejin Bang, Samuel Cahyawijaya, Nayeon Lee, Wenliang Dai, Dan Su, Bryan Wilie, Holy Lovenia, Ziwei Ji, Tiezheng Yu, Willy Chung, et al. 2023, A multitask, multilingual, multimodal evaluation of chatgpt on reasoning, hallucination, and interactivity. arXiv preprint arXiv:2302.04023 (2023).

[0260] Sean Barnum. 2012, Standardizing cyber threat intelligence information with the structured threat information expression (stix). Mitre Corporation 11 (2012), 1-22.

[0261] Rishi Bommasani, Drew A Hudson, Ehsan Adeli, Russ Altman, Simran Arora, Sydney von Arx, Michael S Bernstein, Jeannette Bohg, Antoine Bosselut, Emma Brunskill, et al. 2021, On the opportunities and risks of foundation models. arXiv preprint arXiv:2108.07258 (2021).

[0262] Matt Bromiley. 2016, Threat intelligence: What it is, and how to use it effectively. SANS Institute InfoSec Reading Room 15 (2016), 172.

[0263] Tom Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared D Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, et al. 2020, Language models are few-shot learners. Advances in neural information processing systems 33 (2020), 1877-1901.

[0264] Hui Chen, Zijia Lin, Guiguang Ding, Jianguang Lou, Yusen Zhang, and Borje Karlsson. 2019, GRN: Gated relation network to enhance convolutional neural network for named entity recognition. In Proceedings of the AAAI Conference on Artificial Intelligence, Vol. 33. 6236-6243.

[0265] Veronica Chierzi and Fernando Merces. 2021, Evolution of IoT Linux Malware: A MITRE ATT&CK TTP Based Approach. In 2021 APWG Symposium on Electronic Crime Research (eCrime). IEEE, 1-11.

[0266] Alexis Conneau, Kartikay Khandelwal, Naman Goyal, Vishrav Chaudhary, Guillaume Wenzek, Francisco Guzman, Edouard Grave, Myle Ott, Luke Zettlemoyer, and Veselin Stoyanov. 2019, Unsupervised cross-lingual representation learning at scale. arXiv preprint arXiv:1911.02116 (2019).

[0267] Roman Daszczyszak, Dan Ellis, Steve Luke, and Sean Whitley. 2019, Ttp-based hunting. Technical Report. MITRE CORP MCLEAN VA.

[0268] Peng Gao, Xiaoyuan Liu, Edward Choi, Sibo Ma, Xinyu Yang, Zhengjie Ji, Zilin Zhang, and Dawn Song. 2022, ThreatKG: A Threat Knowledge Graph for Automated Open-Source Cyber Threat Intelligence Gathering and Management. arXiv preprint arXiv:2212.10388 (2022).

[0269] Peng Gao, Xiaoyuan Liu, Edward Choi, Bhavna Soman, Chinmaya Mishra, Kate Farris, and Dawn Song. 2021, A system for automated open-source threat intelligence gathering and management. In Proceedings of the 2021 International Conference on Management of Data. 2716-2720.

[0270] Peng Gao, Fei Shao, Xiaoyuan Liu, Xusheng Xiao, Zheng Qin, Fengyuan Xu, Prateek Mittal, Sanjeev R Kulkarni, and Dawn Song. 2021, Enabling efficient cyber threat hunting with cyber threat intelligence. In 2021 IEEE 37th International Conference on Data Engineering (ICDE). IEEE, 193-204.

[0271] Jerry L Hintze and Ray D Nelson. 1998, Violin plots: a box plot-density trace synergism. The American Statistician 52, 2 (1998), 181-184.

[0272] Ghaith Husari, Ehab Al-Shaer, Mohiuddin Ahmed, Bill Chu, and Xi Niu. 2017, Ttpdrill: Automatic and accurate extraction of threat actions from unstructured text of cti sources. In Proceedings of the 33rd annual computer security applications conference. 103-115.

[0273] Yong-Woon Hwang, Im-Yeong Lee, Hwankuk Kim, Hyejung Lee, and Donghyun Kim. 2022, Current status and security trend of OSINT. Wireless Communications and Mobile Computing 2022 (2022).

[0274] Ziwei Ji, Nayeon Lee, Rita Frieske, Tiezheng Yu, Dan Su, Yan Xu, Etsuko Ishii, Ye Jin Bang, Andrea Madotto, and Pascale Fung. 2023, Survey of hallucination in natural language generation. Comput. Surveys 55, 12 (2023), 1-38.

[0275] Jacob Devlin Ming-Wei Chang Kenton and Lee Kristina Toutanova. 2019, BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding. In Proceedings of NAACL-HLT. 4171-4186.

[0276] Takeshi Kojima, Shixiang Shane Gu, Machel Reid, Yutaka Matsuo, and Yusuke Iwasawa. 2022, Large language models are zero-shot reasoners. arXiv preprint arXiv:2205.11916 (2022).

[0277] Viet Dac Lai, Nghia Trung Ngo, Amir Pouran Ben Veyseh, Hieu Man, Franck Dernoncourt, Trung Bui, and Thien Huu Nguyen. 2023, ChatGPT Beyond English: Towards a Comprehensive Evaluation of Large Language Models in Multilingual Learning. arXiv preprint arXiv:2304.05613 (2023).

[0278] Nayeon Lee, Wei Ping, Peng Xu, Mostofa Patwary, Pascale N Fung, Mohammad Shoeybi, and Bryan Catanzaro. 2022. Factuality enhanced language models for open-ended text generation. Advances in Neural Information Processing Systems 35 (2022), 34586-34599.

[0279] Valentine Legoy, Marco Caselli, Christin Seifert, and Andreas Peter. 2020. Automated retrieval of att&ck tactics and techniques for cyber threat reports. arXiv preprint arXiv:2004.14322 (2020).

[0280] Zhenyuan Li, Jun Zeng, Yan Chen, and Zhenkai Liang. 2022, AttacKG: Constructing technique knowledge graph from cyber threat intelligence reports. In Computer Security-ESORICS 2022: 27th European Symposium on Research in Computer Security, Copenhagen, Denmark, September 26-30, 2022, Proceedings, Part I. Springer, 589-609.

[0281] Swee Kiat Lim, Aldrian Obaja Muis, Wei Lu, and Chen Hui Ong. 2017, Malwaretextdb: A database for annotated malware articles. In Proceedings of the 55th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). 1557-1567.

[0282] Pengfei Liu, Weizhe Yuan, Jinlan Fu, Zhengbao Jiang, Hiroaki Hayashi, and Graham Neubig. 2023, Pre-train, prompt, and predict: A systematic survey of prompting methods in natural language processing. Comput. Surveys 55, 9 (2023), 1-35.

[0283] Yinhan Liu, Myle Ott, Naman Goyal, Jingfei Du, Mandar Joshi, Danqi Chen, Omer Levy, Mike Lewis, Luke Zettlemoyer, and Veselin Stoyanov. 2019, Roberta: A robustly optimized bert pretraining approach. arXiv preprint arXiv:1907.11692 (2019).

[0284] Xuezhe Ma and Eduard Hovy. 2016, End-to-end Sequence Labeling via Bi-directional LSTM-CNNs-CRF. In Proceedings of the 54th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). 1064-1074.

[0285] Sadegh M Milajerdi, Birhanu Eshete, Rigel Gjomemo, and VN Venkatakrishnan. 2019, Poirot: Aligning attack behavior with kernel audit records for cyber threat hunting. In Proceedings of the 2019 ACM SIGSAC conference on computer and communications security. 1795-1812.

[0286] Kris Oosthoek and Christian Doerr. 2019, Sok: Att&ck techniques and trends in windows malware. In Security and Privacy in Communication Networks: 15th EAI International Conference, SecureComm 2019, Orlando, FL, USA, October 23-25, 2019, Proceedings, Part I 15. Springer, 406-425.

[0287] Vittorio Orbinato, Mariarosaria Barbaraci, Roberto Natella, and Domenico Cotroneo. 2022, Automatic Mapping of Unstructured Cyber Threat Intelligence: An Experimental Study:(Practical Experience Report). In 2022 IEEE 33rd International Symposium on Software Reliability Engineering (ISSRE). IEEE, 181-192.

[0288] Ankur Padia, Arpita Roy, Taneeya W Satyapanich, Francis Ferraro, Shimei Pan, Youngja Park, Anupam Joshi, and Tim Finin. 2018, UMBC at SemEval-2018 Task 8: Understanding text about malware. UMBC Computer Science and Electrical Engineering Department (2018).

[0289] Youngja Park and Taesung Lee. 2022, Full-Stack Information Extraction System for Cybersecurity Intelligence. In Proceedings of the 2022 Conference on Empirical Methods in Natural Language Processing: Industry Track. 531-539.

[0290] Lance A Ramshaw and Mitchell P Marcus. 1999, Text chunking using transformation-based learning. Natural language processing using very large corpora (1999), 157-176.

[0291] Nils Reimers and Iryna Gurevych. 2017, Reporting Score Distributions Makes a Difference: Performance Study of LSTM-networks for Sequence Tagging. In Proceedings of the 2017 Conference on Empirical Methods in Natural Language Processing. 338-348.

[0292] Nils Reimers and Iryna Gurevych. 2019, Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks. In Proceedings of the 2019 Conference on Empirical Methods in Natural Language Processing and the 9th International Joint Conference on Natural Language Processing (EMNLP-IJCNLP). 3982-3992.

[0293] Kiavash Satvat, Rigel Gjomemo, and VN Venkatakrishnan. 2021, Extractor: Extracting attack behavior from threat reports. In 2021 IEEE European Symposium on Security and Privacy (EuroS&P). IEEE, 598-615.

[0294] Taneeya Satyapanich, Francis Ferraro, and Tim Finin. 2020, Casie: Extracting cybersecurity event information from text. In Proceedings of the AAAI conference on artificial intelligence, Vol. 34. 8749-8757.

[0295] Stefan Schweter and Alan Akbik. 2020, Flert: Document- level features for named entity recognition. arXiv preprint arXiv:2011.06993 (2020).

[0296] Y. Sharma, E. Giunchiglia, S. Birnbach, and I. Martinovic. [n. d.]. To TTP or not to TTP? Exploiting TTPs to improve ML-based malware detection. In 2023 IEEE International Conference on Cyber Security and Resilience (CSR).

[0297] Ashish Vaswani, Noam Shazeer, Nicky Parmar, Jacob Uszkoreit, Llion Jones, Aidan N Gomez, Lukasz Kaiser, and Illia Polosukhin. 2017. Attention is all you need. Advances in Neural Information Processing Systems 30 (2017).

[0298] Thomas D Wagner, Khaled Mahbub, Esther Palomar, and Ali E Abdallah. 2019, Cyber ​​threat intelligence sharing: Survey and research directions. Computers & Security 87(2019),101589.

[0299] Jason Wei, Yi Tay, Rishi Bommasani, Colin Raffel, Barrett Zoph, Sebastian Borgeaud, Dani Yogatama, Martin Bosma, Denny Zhou, Donald Metzler, et al. 2022, Emerging abilities of large language models. arXiv preprint arXiv:2206.07682 (2022).

[0300] Jeff Wu, Long Ouyang, Daniel M Ziegler, Nisan Stiennon, Ryan Lowe, Jan Leike, and Paul Christiano. 2021, Recursively summarizing books with human feedback. arXiv preprint arXiv:2109.10862(2021).

[0301] Bishan Yang, Wen-tau Yih, Xiaodong He, Jianfeng Gao, and Li Deng. 2015, Embedding entities and relations for learning and inference in knowledge bases. In 3rd International Conference on Learning Representations (2015).

[0302] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. 2022. ReAct: Synergizing Reasoning and Acting in Language Models. arXiv preprint arXiv:2210.03629 (2022).

[0303] While the subject matter of the present disclosure has been illustrated and described in detail in the drawings and the foregoing description, such illustration and description should be considered as illustrative or exemplary, and not limiting. Since the invention is defined by the claims, any statements made herein that characterize the invention should be considered as illustrative or exemplary, and not limiting. It will be understood that changes and modifications may be made by those skilled in the art that are within the scope of the following claims, which may include any combination of features from the various embodiments described above.

[0304] The terms used in the claims should be considered to have the widest reasonable interpretation consistent with the foregoing description. For example, the use of the articles "a" and "the" in introducing elements should not be interpreted as excluding a plurality of elements. Similarly, the word "or" should be interpreted as inclusive, so that the word "A or B" does not exclude "A and B" unless it is clear from the context or the preceding description that only one of A and B is intended. Furthermore, the word "at least one of A, B, and C" should be interpreted as one or more of the group of elements consisting of A, B, and C, and should not be interpreted as requiring at least one of each of the listed elements A, B, and C, regardless of whether A, B, and C are related as a category or otherwise. Moreover, the word "A, B, and / or C" or "at least one of A, B, or C" should be interpreted as including any singular entity from the listed elements, e.g., A, any subset from the listed elements, e.g., A and B, or the entire list of elements A, B, and C. [Explanation of symbols]

[0305] 100 Manual Pipelines 102 Security Analyst 104 Unstructured Data 106 Structured Expressions 200 Pipeline 202 Unstructured Data 204 Entity and Relationship Pipeline 206 Attack Pattern Pipeline 208 NER model 210 Relationship Model 212 Cross-Domain Experts 214 Annotated Dataset 216 Annotated Datasets 220 Text Selection Model 222 Text Classification Model 224 Annotated Dataset 226 Annotated Dataset 228 Output 230 Structured Format 232 Security Analyst 300 Global System 302 Security Experts and / or Users 304 Input 306 User Interface 308 Data Acquisition Module 310 LLM Agents 312 LLM 314 Internet 316 Contents 318 Information 350 LLM Agent System 354 Memory 356 processors 358 processor 360 Network Interface 362 Memory 364 Network Interface 500 LLM Agents 502 Data 504 Pre-processing Component 506 Information Extraction Component 508 Format Components 510 Graphical Representation 512 Data Model 602 identity 604 tool 606 course-of-action 608 vulnerability 610 attack pattern 612 indicator 614 threat-action 616 campaign 618 malware 620 targets 622 uses 624 mitigates 626 attributed to 628 indicates 900 Processing System 902 Processor 904 Memory 906 Input / Output Devices 908 Sensor 910 User Interface 912 Actuator 1000 Architecture 1002 Unstructured Input Report 1004 Downloader and Parser 1006 Raw Text 1008 Pipeline 1010 Pipeline 1012 Pretreatment 1014 Extracted 1016 LLM 1018 Extracted Data 1020 Data Exporter 1022 CTI Analyst 1024 LLM Agents

Claims

1. 1. A computer-implemented method for extracting and mapping structured information to a data model, comprising: obtaining text data from one or more unstructured data sources; determining paraphrased text data using a large-scale language model (LLM), preprocessing prompts, and the text data; determining data to be extracted using the LLM, extraction prompts, the data model, and the paraphrased text data; mapping the extracted data to the data model.

2. outputting the extracted data to a user interface for user review; receiving user input regarding the extracted data; determining a revised extraction prompt based on the user input; and determining additional data to be extracted using the LLM, the corrected extraction prompt, the data model, and the paraphrased text data; The method of claim 1 , wherein the further extracted data is used as the extracted data that is mapped to the data model.

3. The method of claim 1 , wherein the one or more unstructured data sources include security reports and the textual data includes cyber threat intelligence (CTI) information regarding security incidents.

4. 2. The method of claim 1, further comprising: based on a determination that the text data does not contain sufficient information to be processed by the LLM, obtaining additional text data from an internet source, and determining the paraphrased text is based on the text data and the additional text data.

5. The method of claim 4 , wherein the textual data and / or the further textual data are obtained by parsing the one or more unstructured data sources and / or the Internet sources based on entities defined by the data model.

6. determining said paraphrased text data, obtaining one or more text chunks from the text data based on an input capacity of the LLM; 2. The method of claim 1 , further comprising: inputting the preprocessing prompts and a first text chunk of the one or more text chunks into the LLM to obtain summarized paraphrased text data for the first text chunk as the paraphrased text data, the summarized paraphrased text data comprising less text data than the first text chunk, and wherein determining the data to be extracted is based on the summarized paraphrased text data.

7. inputting further pre-processing prompts and a second text chunk of the one or more text chunks into the LLM to obtain second summarized paraphrased text data for the second text chunk, the second summarized paraphrased text data comprising less text data than the second text chunk; The method of claim 6 , wherein the step of determining the data to be extracted is further based on the second summarized paraphrased text data.

8. determining said paraphrased text data, inputting the pre-processing prompts and the text data into the LLM to obtain an expanded paraphrased text for the text data, the expanded paraphrased text comprising an expansion of the text data; The method of claim 1 , wherein determining the data to be extracted is further based on the extended paraphrased text data.

9. The method of claim 8 , wherein the expansion of the text data comprises at least a portion of the text data and new text that indicates a different description of information from the text data.

10. outputting the paraphrased text data to a user interface for user review; receiving user input regarding the paraphrased text data; determining a revised pre-processing prompt based on the user input; determining additional paraphrased text data based on using the LLM, the corrected pre-processing prompts, and the text data source; The method of claim 1 , wherein the further paraphrased text data is used as the paraphrased text data in determining the data to be extracted.

11. obtaining entities of the data model using the extraction prompt and the LLM, wherein the extraction prompt queries the LLM to extract the entities of the data model from the paraphrased text data; the data model is a Structured Threat Intelligence (STIX) data model; 2. The method of claim 1 , wherein mapping the extracted data to the data model further comprises: mapping the extracted entities to the data model; and outputting the mapped data model to a user via a user interface.

12. the text data includes cyber threat intelligence (CTI) information, and the entities include one or more of malware, threat actors, targets, and vulnerabilities; or The method of claim 11 , wherein the text data comprises medical records and the entities comprise one or more of: patients, doctors, treatments, hospitals, and medicines.

13. determining additional paraphrased text data using the LLM, a further preprocessing prompt different from the preprocessing prompt, and the text data source; and / or determining additional extracted data using the LLM, a further extraction prompt different from the extraction prompt, the data model, and the paraphrased text data; determining that the additional paraphrased text data is the same as or substantially similar to the paraphrased text data or that the additional extracted data comprises the same extracted entities as the extracted data.

14. 1. A computer system for extracting and mapping structured information to a data model, said computer system comprising, alone or in combination: obtaining text data from one or more unstructured data sources; determining paraphrased text data using a large-scale language model (LLM), preprocessing prompts, and the text data; determining data to be extracted using the LLM, extraction prompts, the data model, and the paraphrased text data; and mapping the extracted data to the data model 23. A computer system comprising one or more hardware processors configured to effect the execution of

15. A tangible, non-transitory computer readable medium for extracting and mapping structured information to a data model, the non-transitory computer readable medium, when executed by one or more hardware processors, comprises, alone or in combination: obtaining text data from one or more unstructured data sources; determining paraphrased text data using a large-scale language model (LLM), preprocessing prompts, and the text data; determining data to be extracted using the LLM, extraction prompts, the data model, and the paraphrased text data; and mapping the extracted data to the data model 16. A non-transitory computer-readable medium having instructions for effecting the execution of

Images