Systems and methods for security intelligence exchange

Abstract

Improving cybersecurity protections across a plurality of entities by identifying or collecting, incident data corresponding with a cybersecurity incident. Recording the incident data in a distributed

Description

[0310] Referring now to FIG. 25, a block diagram depicting an implementation of a system 4200 for improving cybersecurity protections across the plurality of entities. In some implementations, the interface circuit 116 of the client device 110 within the system 100 may include a security tool 4202 and an interface system 4204. As described herein, the library 114 may include the interface circuit 116. The security tool 4202 of the interface circuit 116 may include a plurality of features to enhance the security of the client device 110 or the application 112. The plurality of features may include antivirus software, firewalls, instruction detection systems, vulnerability scanners, endpoint security software, and the like. The security tool 4202 may monitor, secure, or protect the interface system 4204 by executing the plurality of features. Using aspects of the technical solution described herein, may improve the cybersecurity protection of the client device 110, the third party device 150, and the data sources 160.

[0311] The interface system 4204 may collect or identify the incident data associated with the cybersecurity incident. During the claims process of the claim handling system 400, the interface system 4204 may monitor and collect the incident data at every step of the process. For example, the interface system 4204 may collect incident data from the environmental data of the entity during the modeling of the plurality of cybersecurity protection plans. The incident data from the environmental data may correspond anomalies or potential cybersecurity incidents in the entity’s environment. In some arrangements, the interface system 4204 may identify incident data from the reports of the claim handling system 408. In some arrangements, the interface system 4204 may collect incident data from the questionnaire 428 generated by the analysis circuit 136. For example, the questionnaire 428 may gather information related to the incident or the claim submitted. From the information, the interface system 4204 may extract incident data associated with the claim.

[0312] The interface system 4204 may collect the incident data to satisfy a threshold or upon the reception of a signal from the analysis circuit 136. For example, the interface system 4204 may identify incident data from the application 430, the questionnaire 428, proof of readiness 428, or other components within the analysis circuit 136. The threshold may increase or decrease based on the submitted claim or incident. Responsive to the interface system 4204, the interface system 4204 may record the incident data within the distributed ledger of the analysis circuit 136.

[0313] Referring now to FIG. 25 and FIG. 26, FIG 26 depicts a block diagram 4300 depicting a passport and controls (PC) system 4206. The analysis circuit 136 may include the passport and controls (PC) system 4206 and a modeler 4208. The PC system 4206 may include a first passport data package 4302, a ConfigLock data package 4304, and a second passport data package 4206. In some implementations, the PC system 4206 may generate a decentralized identity passport for each entity in the plurality of entities. The decentralized identity passport may be located with the passport data package 4302. The decentralized identity passport may be built from a distributed ledger and stored within a blockchain network, as shown in FIG. 26. Each decentralized identity passport may include a decentralized identifier to ensure each identify passport is distinct.

[0314] In some implementations, the PC system 4206 may attach or embed a plurality of proof of controls to the corresponding decentralized identity passport of one entity in the plurality of entities. The plurality of proof of controls may be based on one or more cybersecurity protection actions implemented by the entity. For example, a first entity may use mitigation strategies as a cybersecurity protection action, whereas a second company may use firewalls as a cybersecurity protection action.

[0315] The analysis circuit 136 of response system 130 of FIG. 25 may monitor environmental data of the third-party devices 150 (e.g., computing devices) of an entity. To monitor for environmental data, the analysis circuit 136 may detect interactions between an end-user and a computing device. The computing devices may be servers, laptops, tablets, phone, and the like associated with an entity of the decentralized identity passport. The interactions may reveal or indicate compliance corresponding to the cyber protections of the entity. For example, a first end-user may access a website blocked by a firewall on the computing device of then entity. The analysis circuit 136 may flag the interaction as out of compliance with the cyber security protection.

[0316] When the analysis circuit 136 flags an interaction, the entity may receive an indication that the entity is out of compliance with a cybersecurity parameter from the analysis circuit 136. The indication may be at least one of an alert, a notification, or a message. For example, after the analysis circuit 136 flags the interaction, the analysis circuit 136 may transmit the indication to the entity to notify the entity of the lack of compliance. The indication may include a recommendation to update the one or more cybersecurity protection actions. Updating the one or more cyber security protection actions may including updating the security tools 4202 of the client device 110.

[0317] Each time an entity executes at least one proof control of the plurality of proof controls, the PC system 4206 may embed the proof control within the decentralized identity passport. The proof control may indicate that the entity executed the one or more cyber security protection actions in response to a cyberthreat. For each attached proof control, the PC system 4206 may record or store the proof control within the data sources 160 or the distributed ledger. When on the distributed ledger, each block corresponding to the attached proof control may link to the decentralized identity passport as one or more exchanges. In some implementations, the analysist system 136 may validate the one or more cyber security protections for each entity. The database 140 may include a collection of cyber security protections for each entity. The analysis circuit 136 may match the cybersecurity protection action with the stored cybersecurity action in the database 140 to validate the one or more cybersecurity protections. Upon validation of the one or more cybersecurity protections, the analysis circuit 136 may record the validation in the distributed ledger or within the data sources 160 as a new exchange linked to the decentralized identity passport.

[0318] The PC system 4206 may identify a plurality of level 1 (LI) or first level configurations corresponding to at least one operational or security action performed on the plurality of client devices 110 of the entity. The LI configurations may include at least one of network settings, security tool settings, access control lists, endpoint protection settings, or encryption keys. The LI configurations may include system-level operations or security actions performed on the plurality of computing systems. In some implementations, the PC system 4206 may include a plurality of level 2 (L2) configurations that include secondary or maintenance operations or security actions on the plurality of computing systems.

[0319] The PC system 4206 may tokenize the plurality of LI configurations within the ConfigLock data package 4304. The ConfigLock data package 4304 may include the plurality of L2 configurations. To tokenize the plurality of LI configurations, the PC system 4206 may digitize and represent the plurality of LI configurations on a blockchain. The PC system 4206 may execute one or more smart contracts to tokenize the LI configurations. For example, the PC system 4206 may execute a first smart contract to tokenize one or more LI configurations and a second smart contract to tokenize one or more L2 configurations. Upon tokenizing the LI configurations, the PC system 4206 may store or record the LI and L2 configurations on the distributed ledger or a data source 160 as show in FIG. 26.

[0320] In some implementations, the PC system 4206 may provide a recovery key to the entity. The recovery key may be configured to allow the recovery of the tokenized LI configurations. In some embodiments, the interface circuit 116 may receive the recovery key and provide the plurality of LI configurations from the distributed ledger or data source 160. The interface circuit 116 may detokenize or decrypt the plurality of LI configuration using the recovery key.

[0321] The modeler 4208 may be an artificial intelligence (AI) or machine learning (ML) model designed to identify, detect, and respond to incidents, claims, or cyber threats. The modeler 4208 may include a data collection layer to gather incident data from the interface system 4204. The modeler 4208 may include a preprocessing layer and a feature engineering layer. The modeler 4208 may use a model training layer to train the modeler 4208 to model the incident data by using one or more training data sets within the database 140. In some implementations, the modeler 4208 may include a model evaluation layer to evaluate the trained model using one or more validation data sets within the database 140. In some implementations, the modeler 4208 may execute heuristic analysis, pattern identification, anomaly identification, or threat projections.

[0322] In some arrangements, the modeler 4208 can generate verifiable credentials, designed to encapsulate and validate the cybersecurity efforts of entities. Utilizing statistical analysis and correlation techniques, the modeler 4208 can analyze, correlate, and cross-reference datasets to identify patterns indicative of potential security threats or vulnerabilities. This process can employs algorithms capable of detecting anomalies in network traffic, unauthorized access attempts, and the presence of malicious software by comparing observed behaviors against established norms. For example, the modeler 4208 can evaluate an organization’s security posture by analyzing both historical incident data and existing cybersecurity measures. This thorough assessment aids in the stratification of security priorities. The verifiable credentials generated as a result encapsulate the evaluated security posture, offering entities a means to demonstrably showcase their cybersecurity diligence to partners, regulators, and other stakeholders. Moreover, the modeler 4208 can integrate domain-specific heuristic analysis to bolster its predictive analysis capabilities. This provides the generation of verifiable credentials that are broad in scope and also customized to address the unique threats pertinent to an entity’s operational domain. Additionally, the incorporation of regulatory compliance tracking into the modeler’s 4208 analytical framework provides that the generated verifiable credentials also reflect adherence to legal and industry standards.

[0323] Using the modeler 4208, the analysis circuit 136 may model the incident data to generate one or more verified intelligences corresponding to at least one cybersecurity threat. For example, the modeler 4208 may model the incident data by generating a cyberthreat and transmit the generated cyberthreat to the analysis circuit 136. Responsive to receiving the generated cyberthreat, the analysis circuit 136 may use the generated cyberthreat to generate one or more verified intelligences to address the cyberthreat. The one or more verified intelligences may include at least one of threat indicators, vulnerability patches, or mitigation strategies corresponding to the at least one cybersecurity threat. In some implementations, the generated one or more verified intelligences may be a plurality of steps, a process, or a method to protect against the cyber threat.

[0324] The analysis circuit 136 may determine the one or more verified intelligences by using the generated cyberthreat. In some implementations, the one or more verified intelligences may correspond to at least one of firmographic data, identified security gaps, or existing protection guards. For example, the one or more verified intelligences may be based on firmographic data of the cyberthreat. In another example, the one or more verified intelligences may be based on identified security gaps of the cyberthreat. The firmographic data, the identified security gaps, and the existing protection guards may correspond to an entity profile of each of the plurality of entities.

[0325] To determine the one or more verified intelligences, the analysis circuit 136 may monitor interactions between an end-user and the interface system 4204. The interactions may reveal that the end-user executed intelligences stored within the database 140. For each executed intelligence, the analysis circuit 136 may identify the verified intelligence if the executed intelligence corresponds to the cyberthreat. For example, an entity may execute a mitigation strategy to protect against a cyberthreat. The analysis circuit 136 may detect the mitigation strategy and determine or identify the mitigation strategy as verified intelligence.

[0326] The analysis circuit 136 may decode the one or more verified intelligences into entity specific data formats of one entity in the plurality of entities. In this manner, the analysis circuit 126 may automatically generate the one or more verified intelligences in a format of one entity. For example, a first entity may need seven verified intelligences, whereas a second entity may need eight verified intelligences. Each of the verified intelligences for the first entity and each of the verified intelligences for the second entity may differ based on the protections of the first entity and the second entity.

[0327] During the decoding of the one or more verified intelligences, the analysis circuit 136 may translate the one or more verified intelligences into formats compatible with the security tool 4202. The format may define the configuration for the security tool 4202. For example, the format may be an API in the programming language of the security tool 4202. The format for a first entity may differ from the format for a second entity to ensure the security tools 4202 of each entity are not the same.

[0328] The analysis circuit 136 may configure or reconfigure the security tool 4202 of the respective entity. The analysis circuit 136 may transmit a configuration to the security tool 4202 to modify, adjust, or change the API of the security tool. The configuration may enable the security tool 4202 to protect the entity again the cyberthreat. In some implementations, the analysis circuit 136 may transmit a subsequent configuration that may include the first configuration. The subsequent configuration may update the security tool 4202 to protect again a subsequent cyberthreat and the first cyber threat. In this manner, the analysis circuit 136 may continuously update each security tool 4202 from each entity to protect the respective entity from the cyberthreat.

[0329] Still referring to FIGS. 42-43, the modeler 4208 can be configured to generate of a decentralized identity passport (e.g., passport data package 4302 and 4306) for each entity (or sub-entity, such as group or subsidiary of an entity or company). The generation by the modeler 4208 can include collecting and integrating cybersecurity-related actions and measures performed and executed by these entities into their respective identity passports. These actions can be encapsulated in proofs of control, which demonstrate the entity’s adherence to prescribed cybersecurity practices and measures. Once generated, these proofs are linked with the entity’s decentralized identity passport and recorded on a distributed ledger or data source. Accordingly, the cybersecurity action by an entity can be transparently and immutably documented.

[0330] Upon attaching or embedding the proofs of control to the decentralized identity passports, the modeler 4208 can validate the cybersecurity measures for each entity. This validation process determines the efficacy and adherence of the implemented cybersecurity actions against established benchmarks or standards. After successful validation, the modeler 4208 can record this validation as a new exchange on the distributed ledger or data source, linked to the entity’s decentralized identity passport. This recorded validation acts as a verifiable badge of cybersecurity compliance, enhancing the entity’s credibility and trustworthiness within a digital ecosystem. Continuously monitoring environmental data across computing systems of the registered entities, the modeler 4208 can uphold one or more cybersecurity standards. This monitoring can be used to identify deviations or non-compliance with cybersecurity parameters. In response to any detected discrepancies, the modeler 4208 can issue alerts to the entities involved, advising them on updating their cybersecurity measures.

[0331] In some arrangements, the modeler 4208 can identify a plurality of first-level configurations corresponding to operational or security actions performed on computing systems of an entity. The modeler 4208 can encrypt or tokenize these configurations and record them on a distributed ledger or data source. For example, the modeler might encrypt network settings adjustments made to enhance security, ensuring that such changes are securely documented and verifiable. That is, the verifiable configurations can be stored in a ConfigLock Data package 4304. For example, ConfigLock Data package 4304 can be encrypted and compartmentalized into segments, each representing different dimensions or areas of the entity’s cybersecurity framework, such as network configurations, access controls, and endpoint security settings. Furthermore, the ConfigLock Data package 4304 can then be indexed and timestamped. This process ensures that changes to configurations are auditable and resistant to tampering.

[0332] In some arrangements, the modeler 4208 can provide a recovery key to the entity, allowing for the recovery of encrypted or tokenized first-level configurations. For example, a client device 110 (particularly the security tool 4202) can use the recovery key to receive the first-level configurations from the distributed ledger based on decrypting or detokenizing with the recovery key by the modeler 4208. The modeler 4208 can regenerate the recovery key upon detecting a potential compromise or at predefined intervals. For example, in the case of a security breach, the modeler 4208 could regenerate the recovery key to maintain the integrity of the stored configurations.

[0333] In some arrangements, the configurations of the plurality of first-level configurations can be system-level operations or security actions, while a plurality of second-level configurations pertain to secondary or maintenance operations. For example, the modeler differentiates between the application of a critical security patch (first-level) and routine software updates (second-level), ensuring each is appropriately categorized and documented. In some arrangements, the first-level configurations include network settings, security tool settings, access control lists, endpoint protection settings, or encryption keys. For example, the modeler 4208 could record changes to firewall rules or the deployment of new antivirus definitions, capturing essential details for security management.

[0334] In some arrangements, the configurations can be a level of configuration such as, cryptographic proof of provenance (e.g., Level 4 or L4), with subsequent levels corresponding to validations (e.g., Level 3 or L3), documented evidence of actions (e.g., Level 2 or L2), and commitments made by the entity (e.g., Level 1 or LI). For example, the modeler 4208 could verify a new encryption key’s provenance through digital signatures, then document its deployment across the network as an action taken. It should be understood the various levels of configuration are described herein but should not be limited to hierarchical categorizations, as configurations may also be interdependent or require cross-validation for security assessments. In particular, the flexibility of the modeler 4208 allows for dynamic adaptation to emerging security challenges and technological advancements, ensuring that the modeler 4208 remains effective in a rapidly evolving cybersecurity landscape.

[0335] In some arrangements, the highest or best configuration level can be for cryptographic proof of provenance obtained by the modeler 4208 directly from the entity and programmatically. For example, the modeler 4208 could derive and encode the cryptographic proof of provenance for software updates directly from development logs and code repositories, ensuring that only verified updates are applied to the entity’s systems. In another example, the modeler 4208 could programmatically attest to the integrity of third-party components by validating their cryptographic signatures against trusted certificate authorities, bolstering supply chain security.

[0336] In some arrangements, the second highest or second best configuration level can be validation by one or more authorized entities. For example, validation could include crossreferencing the digital signatures of installed applications with a database of verified publishers to confirm authenticity. In another example, validation might include checking the conformity of network configuration changes against industry-standard security protocols, ensuring that the entity’s network remains resilient against known vulnerabilities.

[0337] In some arrangements, the third highest or third best configuration level can be documented evidence of an action. For example, documented evidence could include logging the sequence of steps taken to apply a security patch, complete with timestamps and system snapshots. In another example, it might involve retaining change logs that detail the rationale and implementation details of new access control policies, providing a clear audit trail for security audits.

[0338] In some arrangements, the fourth highest or fourth best configuration level can be commitments made by the entity. For example, commitments made by the entity could be encapsulated in a policy document that outlines the entity’s approach to data encryption, specifying the algorithms and key management practices to be adhered to. In another example, commitments might be demonstrated through the publication of a regular security newsletter that details the entity’s ongoing efforts to maintain and enhance its cybersecurity posture, fostering transparency and accountability.

[0339] In some arrangements, the identifying process includes acquiring and verifying cryptographic proof of provenance based on digital signatures and transaction records. For example, the modeler 4208 could use digital signatures to confirm the authenticity of a newly implemented access control list before recording it. In some arrangements, the modeler 4208 updates second, third, or fourth-level configurations in response to updates in operational or security actions. For example, if an entity revises its data retention policy, the modeler 4208 could update the relevant configurations to reflect this change, ensuring the ledger remains current and accurate.

[0340] In some arrangements, the passport and controls (PC) system 4206 can prepare and report cyber incidents according to various governmental regulations. In some arrangements, the PC system 4206 can determine when a cyber incident is substantial based on a government regulation, which could range from significant losses in the confidentiality, integrity, or availability of information systems, to serious impacts on operational safety, disruptions in business activities, or unauthorized access stemming from third-party compromises. Upon identifying such incidents, the PC system 4206 can gather a set of data necessary for reporting. This data collection can encompass all correspondence with threat actors, indicators of compromise, relevant log entries, forensic artifacts, network data, and information on how the threat actor compromised the system, among others. Additionally, the PC system 4206 can track and document all details related to any ransom payments, including the amount, the decision process, and the aftermath of the payment.

[0341] For example, a substantial cyber incident can lead to one or more of the following: a substantial loss of confidentiality, integrity or availability of a covered entity’s information system or network, a serious impact on the safety and resiliency of a covered entity’s operational systems and processes, a disruption of a covered entity’s ability to engage in business or industrial operations, or deliver goods or services, unauthorized access to a covered entity’s information system or network, or any nonpublic information contained therein, that is facilitated through or caused by a: compromise of a cloud service provider, managed service provider, or other third-party data hosting provider; or supply chain compromise.

[0342] Furthermore, in some arrangements, the PC system 4206 can also be configured to manage and submit follow-up reports as required. This can include generating supplemental reports when new or different information about a cyber incident becomes available or if additional ransom payments are made. Thus, the PC system 4206 can provide all relevant data such that it is accurately preserved and maintained for a minimum period (e.g., set at two years), following the submission of the most recent report. This data preservation can include the initial detection of a compromise to the full resolution and analysis of the incident, including any payments made and the identification of exploited vulnerabilities.

[0343] In some arrangements, the operational framework of the PC system 4206 aligns with the need for timely and detailed incident reporting and data preservation to assist organizations in maintaining compliance with regulatory requirements. By automating the process of collecting, preserving, and reporting detailed information about cyber incidents and ransom payments, the PC system 4206 reduces the manual effort required and enhances the accuracy of the information reported. This approach can be used to fulfil legal and regulatory obligations and strengthen the overall cybersecurity posture of organizations by ensuring a structured response to incidents and facilitating continuous improvement through detailed incident analysis and feedback.

[0344] In some arrangements, the preservation requirement of the PC system 4206 can include all correspondence with the threat actor, regardless of the forum or method; indicators of compromise; relevant log entries; relevant forensic artifacts; network data; data and information that may help identify how a threat actor compromised or potentially compromised an information system; system information that may help identify exploited vulnerabilities; information about exfiltrated data; all data or records related to the disbursement or payment of any ransom payment; and any forensic or other reports concerning the incident, whether internal or prepared for the covered entity by a cybersecurity company or other third-party vendor. Verified Intelligence

[0345] FIG. 27 depicts a flowchart of a method 4400 for improving cybersecurity protections across the plurality of entities. At least the computing / security architecture shown and described regarding FIG. 25 can perform method 4400 according to present implementations.

[0346] In a broad overview of method 4400, at block 4410, the one or more processing circuits (e.g., response system 130 of FIG. 25) can identify incident data. At block 4420, the one or more processing circuits can record incident data in a distributed ledger. At block 4430, the one or more processing circuits can model the incident data utilizing a cybersecurity model to generate a verified intelligence. At block 4440, the one or more processing circuits can determine the verified intelligence correspond to an entity. At block 4450, the one or more processing circuits can decode the verified intelligence into one or more entity-specific data formats. At block 4460, the one or more processing circuits can configure or re-configure at least one security tool of the entity. In some embodiments, some, or all operations of method 4400 may be performed by one or more processors executing on one or more computing devices, systems, or servers. In various embodiments, each operation may be re-ordered, added, removed, or repeated.

[0347] At block 4410, the processing circuits identify or collect incident data corresponding with a cybersecurity incident. In some arrangements, the processing circuits can scan network traffic and log files for abnormal patterns. For example, identifying can include parsing security logs for unauthorized access attempts. In another example, collecting can include aggregating data from intrusion detection systems. Furthermore, the cybersecurity incident may include a detected breach or unauthorized data access attempt. Additionally information related to identifying and collecting incident data is described above with reference to FIGS 22-24.

[0348] At block 4420, the processing circuits record the incident data in a distributed ledger or data source. In some arrangements, the processing circuits can record the incident data in the distributed ledger (e.g., WEB3 data source) by encrypting and hashing the data to ensure integrity and confidentiality. For example, the process could include generating a unique cryptographic hash for each incident record. In some arrangements, the processing circuits can record the incident data in the data source (e.g., WEB2 data source) by structuring the data into predefined formats for consistency and easy retrieval. For example, the data could be formatted according to JSON or XML schemas. Furthermore, recording can include timestamping each incident entry to establish a chronological order of events.

[0349] At block 4430, the processing circuits can analyze the incident data utilizing a cybersecurity model to generate one or more verified intelligences corresponding to at least one cybersecurity threat. In some arrangements, the cybersecurity model includes at least one of heuristic analysis, pattern identification, anomaly identification, or threat projections. For example, the processing circuits can apply machine learning techniques to the incident data to identify patterns indicative of specific types of cyber threats. For example, heuristic analysis could be employed to compare incident data against known threat signatures. In another example, anomaly detection algorithms might identify deviations from baseline network behavior as potential threats. In yet another example, threat projections could be generated by extrapolating current data trends. The cybersecurity model can be executed by processing circuits in response to the cybersecurity incident. That is, the model can dynamically adjust its parameters based on the nature and severity of the incident. For example, the model could prioritize incident data indicating a zero-day vulnerability.

[0350] In some arrangements, the one or more verified intelligences include at least one of threat indicators, vulnerability patches, or mitigation strategies corresponding to the at least one cybersecurity threat. For example, the verified intelligence might include a digital signature of a malware file for antivirus software to block. In another example, it could recommend specific configuration changes to firewall rules to prevent similar incidents. Additionally, the firmographic data, the identified security gaps, and the existing protection guards can correspond to an entity profile of each of the plurality of entities. In some arrangements, an entity profile can detail the technological infrastructure and software dependencies of an entity. For example, it can list all network endpoints and their respective security statuses. Furthermore, the verified intelligences can guide the refinement of entity-specific cybersecurity measures. For example, they might suggest enhancements to encryption practices based on identified vulnerabilities.

[0351] At block 4440, the processing circuits can determine the one or more verified intelligences corresponds to at least one of the plurality of entities based on at least one of firmographic data, identified security gaps, or existing protection guards. In some arrangements, the generated verifiable intelligence can be cross-referenced and analyzed against entity data to determine, for example, if the cybersecurity threat is exploitable or could present a cyber vulnerability to one or more entities. For example, matching the threat indicators to specific network architectures or operating systems prevalent within the target entities. In another example, correlating vulnerability patches to software versions identified in the firmographic data of entities. That is, the processing circuits can use incident data collected during the claims process with a distributed ledger and automation to automatically determine the correct verified intelligence for the correct businesses who need it, based on firmographic, gaps, and safeguard matching, with technology translated and usable data that can auto-change configurations of security tools to defend against these verified relevant threats. For example, automation to automatically determine can include analyzing historical breach data against current entity profiles to predict susceptibility. That is, determining the correct business includes evaluating entity-specific IT environments against the threat model to ensure relevance. For example, comparing the unique digital footprint of each entity against the incident pattern to identify potential targets.

[0352] In some arrangements, the firmographics of the entity can include, but is not limited to, industry sector, size, geographical location, and technology stack. For example, the verified intelligence can be determined for an entity using the firmographics when matching industryspecific threats to entities within the same sector. Additionally, the gaps of the entity can include, but is not limited to, outdated software, missing patches, or weak encryption protocols. For example, the verified intelligence can be determined for an entity using the gaps when identifying entities running software versions vulnerable to a newly discovered exploit. Furthermore, the safeguards of the entity can include, but is not limited to, firewalls, antivirus software, and intrusion detection systems. For example, the verified intelligence can be determined for an entity using the safeguard when matching mitigation strategies to existing security infrastructure. Accordingly, the various data of the entity can be matched to the verified intelligence to customize cybersecurity advice and action plans, ensuring that recommendations are actionable and directly address the entity’s specific security needs.

[0353] At blocks 4450 and 4460, the processing circuits can decode the one or more verified intelligences into one or more entity-specific data formats of the at least one of the plurality of entities and configure or re-configure at least one security tool of the at least one of the plurality of entities. For example, configuration or re-configuration can include protecting the at least one of the plurality of entities from the at least one cybersecurity threat. Additionally, decoding into the one or more entity-specific data formats can include translating the one or more verified intelligences into formats compatible with the at least one security tool of the at least one of the plurality of entities. For example, decoding could include converting threat indicators into firewall rule updates to block malicious IP addresses. In another example, decoding could include translating vulnerability patches into specific update commands for antivirus software. That is, decoding transforms threat data into actionable security measures tailored to each entity’s systems and protection tools.

[0354] In some arrangements, configuring the security tool of an entity can include setting up intrusion detection systems to monitor for specific patterns of malicious activity identified in the verified intelligence. For example, adjusting sensitivity levels of the detection algorithms based on the severity of the threat. In another example, configuring could include updating access control lists to restrict traffic from suspect sources. In some arrangements, reconfiguring the security tool of an entity can include modifying existing firewall rules to address new vulnerabilities revealed by the verified intelligence. For example, adding or removing rules to better protect against the identified threats.

[0355] In some arrangements, the processing circuits can automatically generate and apply patches or updates to the at least one security tool. Generating can include creating custom patches for proprietary software based on the specific vulnerabilities identified. For example, compiling code changes that neutralize a newly discovered exploit. In some arrangements, applying the patches or updates can include remotely pushing updates to endpoint protection tools across the entity’s network. For example, automating the deployment of patches during off-peak hours to minimize disruption. That is, the security tool can be kept up-to-date with the latest defenses against emerging threats. For example, ensuring all devices and software within the entity’s network are equipped with the latest protective measures. Passport Data Package

[0356] In some arrangements, method 4400 can further include a method for generating passport data packages (e.g., passport data package 4302 and 4306 of FIG. 26) with decentralized proof of controls attached for the entities proof of performance. It should be understood that the generation of passport data packages described with reference to method 4400 can be executed and completed independently of method 4400. For ease of understanding, the generation of passport data packages will be referred to in steps.

[0357] Generally, the passport data package can be a digitally encrypted fde encapsulating the entity’s identity and its cybersecurity practices. For example, the passport data package can include embedded digital certificates and cryptographic proofs. Furthermore, the passport data package can be used as a verifiable credential for demonstrating compliance with cybersecurity standards and practices to partners and regulators.

[0358] In some arrangements, at step 1, the processing circuit can generate a decentralized identity passport for each of a plurality of entities. Generation can include compiling a record of the entity’s cybersecurity protocols and identity verification documents. For example, incorporating business registration documents and cybersecurity policy documents into the passport. Alternatively or in combination, generation can include digitally signing the compiled documents to ensure authenticity and integrity. For example, using SHA-256 for hashing and RSA for digital signatures. In some arrangements, generating the decentralized identity passport includes using a public-private key pair unique to each entity of the plurality of entities. For example, the public key can be recorded on the distributed ledger and the private key remains confidential to the entity.

[0359] At step 2 of the generation of the passport data package, the processing circuits can attach or embed a plurality of proof of controls to the decentralized identify passport of an entity of the plurality of entities, the plurality of proof of controls corresponding to one or more cybersecurity protection actions implemented by the entity. In some arrangements, attaching could include digitally linking cybersecurity protection actions documentation to the passport. For example, appending metadata of security audits and certifications to the passport. Furthermore, the processing circuits can sign the plurality of proof of controls using a digital signature scheme before attaching the plurality of proof of controls to the decentralized identity passport. For example, employing ECDSA for digital signatures. In some arrangements, embedding could include integrating QR codes or unique identifiers that link to detailed proofs of control hosted securely online. For example, QR codes that direct to encrypted online repositories containing audit logs. The cybersecurity protection actions could include network encryption enhancements and multi-factor authentication implementation. That is, the entity can demonstrate compliance with industry security standards. Furthermore, the proofs of control are verified and timestamped to ensure their validity.

[0360] In some arrangements, the processing circuits can validate the one or more cybersecurity protections of each of the plurality of entities and record the validation on the distributed ledger or data source as a new exchange linked to the decentralized identity passport. That is, validating the one or more cybersecurity protections can include comparing the one or more cybersecurity protection actions to a predefined set of security standards or benchmarks. In some arrangements, the predefined set of security standards or benchmarks can include ISO / IEC 27001 and NIST cybersecurity frameworks. For example, comparing entity’s cybersecurity measures against these frameworks to ensure compliance. In some arrangements, recording can include encrypting and hashing the validation data before storage. For example, using blockchain technology to immutably store the validation results. That is, the new exchange linked to the decentralized identity passport can include a timestamped record of the validation, along with references to the specific standards or benchmarks used for validation. For example, a blockchain transaction containing validation metadata and outcomes.

[0361] At step 3 of the generation of the passport data package, the processing circuits can record the plurality of proof of controls on a distributed ledger or data source as one or more exchanges linked to the decentralized identity passport. In some arrangements, recording the proof of controls on the distributed ledger can include creating a smart contract for each proof of control, ensuring traceability and non-repudiation. For example, deploying smart contracts on Ethereum to represent each proof of control. In some arrangements, recording the proof of controls on the data sources can include utilizing secure cloud storage services with access control lists tailored for privacy and security. For example, storing proofs of control in buckets with encrypted data transfer. Additionally, linking to the decentralized identity passport can include assigning a unique identifier to each proof of control that corresponds to the passport’s digital identity. For example, using UUIDs to link proofs of control to the specific passport within the distributed ledger. In another example, creating hyperlinks within the passport document that lead directly to the recorded proofs of control on the ledger.

[0362] In some arrangements, the processing circuits can monitor environmental data of a plurality of computing systems of the plurality of entities with the decentralized identity passport. For example, utilizing network monitoring tools to detect and record changes in firewall settings or antivirus software updates. That is, the decentralized identity passport can be used by the processing circuits to authenticate and authorize access to monitored data. For example, the environmental data can correspond to the decentralized identity passport by mapping network traffic patterns and system performance metrics to the passport’s unique identifier. The environmental data monitored can include at least one, but is not limited to, network traffic, system performance metrics, software integrity, or security event logs corresponding with the plurality of computing systems. For example, monitoring can include analyzing logs for indicators of compromise or unauthorized access attempts.

[0363] In some arrangements, in response to determining at least one of the plurality of entities out of compliance with a cybersecurity parameter, the processing circuits can issue an alert to at least one of the plurality of entities including a recommendation to update the one or more cybersecurity protection actions. In some arrangements, the alert can specify the non-compliance issue and provide detailed steps for remediation. Furthermore, the recommendation can include best practices for updating security protocols or installing specific software patches. For example, the recommendation can be generated based on real-time threat intelligence and tailored to the entity’s specific infrastructure and previously recorded cybersecurity actions.

[0364] In some arrangements, the processing circuits can update the decentralized identity passport to include additional proof of controls based on successful validation of a newly implemented cybersecurity protection actions by the entity of the plurality of entities. In some arrangements, an update to the decentralized identity passport can include appending new proofs of control and re-validating the passport’s overall security status. For example, adding digital records of recently passed security audits or newly implemented security measures. Additionally, the additional proof of controls can be determined by assessing the impact and effectiveness of the newly implemented measures. For example, successful validation of a newly implemented cybersecurity protection actions by the entity of the plurality of entities can include conducting a thorough review of the updated security protocols, supported by external audit findings and internal performance metrics. In another example, updating the entity’s cybersecurity profile within the passport to reflect the latest security posture and compliance status.

[0365] In some arrangements, the passport data package can serve as a dynamic, verifiable credential for entities to demonstrate their cybersecurity posture and compliance with relevant standards. Entities could present the passport data package, which includes digital certificates, cryptographic proofs, and a detailed record of cybersecurity controls, to partners, regulators, or clients. Upon presentation, the recipient could verify the authenticity and integrity of the passport using public keys recorded on a distributed ledger, ensuring the digital signatures and cryptographic hashes match the entity’s reported cybersecurity measures. Verification could involve checking the digital signatures against the public keys and ensuring the cryptographic proofs align with the stated security controls and actions. This process can be facilitated by software or digital platforms capable of reading and validating the contents of the passport data package, ensuring the entity adheres to the claimed security practices and standards. Such verification could support trust in digital transactions, enable secure partnerships, and streamline compliance audits by providing a transparent, immutable record of an entity’s cybersecurity efforts. ConfigLock Data Package

[0366] In some arrangements, method 4400 can further include a method for generating ConfigLock data packages (e.g., ConfigLock data package 4304 of FIG. 26) to store configs decentralized to recover, for example during an incident affecting the entities computing structure or network. It should be understood that the generation of ConfigLock data packages described with reference to method 4400 can be executed and completed independently of method 4400. For ease of understanding, the generation of ConfigLock data packages will be referred to in steps.

[0367] Generally, the ConfigLock data package can be a secure, encrypted container for storing various configuration settings and proofs of compliance. For example, the ConfigLock data package can include embedded digital signatures and cryptographic hashes to ensure the integrity and authenticity of the data. Furthermore, the ConfigLock data package can be used as a means to quickly restore system configurations to a known secure state in the event of a cybersecurity incident, facilitating rapid recovery and minimizing downtime. 10368] In some arrangements, at step 1, the processing circuit can identify a plurality of first level configurations corresponding to at least one of an operational or security action performed on the a plurality of computing systems of an entity of a plurality of entities. Identifying can include scanning and analyzing system logs and configuration files for changes. For example, an operational action can be an update to server software. In another example, a security action can be the application of a new firewall rule.

[0369] In some arrangements, identifying of step 1 can include (1) accessing one or more data channels of a plurality of computing systems of an entity of a plurality of entities, (2) identifying, by the one or more processing circuits, at least one of an operational or security action performed on the plurality of computing systems of the entity of the plurality of entities, and (3) modelling the at least one of an operational or security action using a cryptographic proof of provenance model to generate a plurality of first level configurations. Specifically, accessing can include connecting to system and application logs, network traffic analyses, and security event management systems. For example, aggregating data from endpoint detection and response (EDR) systems and security information and event management (SIEM) solutions. Additionally, identifying the operation or security action can include parsing and categorizing event logs based on predefined criteria. For example, classifying actions as routine maintenance or security enhancements or verifying the cryptographic proof of provenance based on one or more digital signatures. Furthermore, modeling can include applying algorithmic analysis to establish the chronological sequence and interdependencies of actions. That is, employing data science techniques to discern patterns that validate the authenticity and integrity of the actions. For example, utilizing blockchain technology to create an immutable record of configurations. In another example, applying machine learning models to predict the impact of configuration changes on system security. In some arrangements, the cryptographic proof of provenance model can be a heuristic algorithm or artificial intelligence model that evaluates the reliability and security implications of each action. For example, assessing the compatibility of new software updates with existing security protocols. In some arrangements, the cryptographic proof of provenance model can be a statistical analysis algorithm configured to identify outliers in configuration changes that may indicate unauthorized or malicious alterations. In some arrangements, the cryptographic proof of provenance model can be a cybersecurity analysis algorithm configured to assess the efficacy of new security configurations against emerging threat vectors. For example, simulating attack scenarios to evaluate the resilience of firewall settings.

[0370] In some arrangements, a first level configuration can be system-level operations or security actions performed on the plurality of computing systems, and a second level configurations can be secondary or maintenance operations or security actions on the plurality of computing systems. For example, a first level configuration could be the implementation of a new network encryption protocol. That is, the first level configurations can include at least one of network settings, security tool settings, access control lists, endpoint protection settings, or encryption keys. In another example, a second level configuration could pertain to the scheduling of regular system backups. Accordingly, the configurations can ensure comprehensive security and operational efficiency across the entity’s computing systems.

[0371] Alternatively or in combination, the configurations can be hierarchical according to the type of proof provided by the entity. For example, a first level configuration can be cryptographic proof of provenance obtained by the one or more processing circuits directly from the entity and programmatically. In this example, the proof of provenance might verify the source and integrity of a new software application before installation. Additionally, a second level configuration can be a validation by one or more authorized entities, for example, through third-party security audits. Furthermore, a third level configuration can be documented evidence of an action, for example, logs showing the successful application of a security patch. Moreover, a fourth level configuration can be commitments made by the entity, for example, a pledge to adhere to specific data protection standards. Generally, the processing circuits can prioritize or weight the first level or better level configurations to emphasize their importance in maintaining system integrity. That is, configurations at higher levels could receive more scrutiny during the verification process.

[0372] In some arrangements, the processing circuits can verify the cryptographic proof of provenance based on one or more digital signatures and transaction records stored within the distributed ledger or data source. For example, verifying the digital signature of a critical software update to confirm its authenticity. Furthermore, the processing circuits can generate the cryptographic proof of provenance for the plurality of first level configurations. That is, the generation can include creating a secure hash of the software package. For example, using SHA-256 to ensure the integrity of the configuration data.

[0373] In some arrangements, the processing circuits can update at least one of the plurality of second level configurations, the plurality of third level configurations, or the plurality of fourth level configurations, in response to an update in the operational or security action performed on the plurality of computing systems of the entity. For example, adjusting firewall settings in response to new threat intelligence. In another example, updating access control lists to restrict access to sensitive data following a policy change. That is, updates can include the recalibration of security measures to align with the latest security landscape and entity policies.

[0374] At step 2 of the generation of the ConfigLock data package, the processing circuits can encrypt or tokenize the plurality of first level configurations. In some arrangements, encrypting can include using AES-256 to secure configuration data against unauthorized access. For example, encrypting network configuration settings to prevent tampering. In some arrangements, tokenizing can include converting configuration settings into tokens stored on the blockchain, ensuring confidentiality and integrity. For example, representing access control settings as tokens. Accordingly, the ConfigLock data package can be securely stored and readily accessible by entities possessing the correct decryption or detokenization keys.

[0375] At step 3 of the generation of the ConfigLock data package, the processing circuits can record the plurality of first level configurations on the distributed ledger or data source. For example, recording the configurations on a distributed ledger can include hashing each configuration setting and storing it on a blockchain to ensure tamper-proof records. In another example, recording the configurations on a data source can include saving them in a secure, encrypted database with restricted access.

[0376] In some arrangements, the processing circuits can providing a recovery key to the entity. For example, the recovery key can configured to allow the recovery of the encrypted or tokenized plurality of first level configurations by the entity. That is, the recovery key can facilitate secure and controlled access to the stored configurations. For example, a recovery key can be generated by the processing circuits by employing a secure key generation algorithm. For example, using RS A encryption to create a unique recovery key for each entity. In another example, distributing the recovery key to authorized personnel through a secure channel.

[0377] In response to receiving the recovery key, the processing circuits can provide the plurality of first level configurations from the distributed ledger or data source based on decrypting or detokenizing the plurality of first level configurations using the recovery key. In some arrangements, providing or transmitting the configurations can include securely sending the decrypted or detokenized configurations over a secure communication channel. For example, using TLS to protect the transmission of configuration data. That is, the configurations allow the entity to restore its systems to a secure state following an incident. In some arrangements, the processing circuits can regenerate the recovery key based on a detection of a potential compromise or at predefined intervals. For example, automatically updating the recovery key annually or following the detection of a security breach. In another example, implementing a multi-factor authentication process for recovery key regeneration to enhance security.

[0378] In some arrangements, to restore from a ConfigLock data package, the entity could first authenticate using a pre-determined recovery key to access the encrypted package. Upon successful authentication, the entity could decrypt the package, which contains serialized configuration settings, digital signatures, and cryptographic hashes of the original state of system configurations. These configurations could include network settings, firewall rules, access control lists, and software version information. The restoration process could include deserializing the configuration data and programmatically applying it to the respective systems and devices, ensuring that each component is reverted to its verified secure state. This process could include automated scripts or configuration management tools that validate each setting’s integrity using the included cryptographic hashes before applying them, ensuring the restoration does not inadvertently introduce vulnerabilities.

[0379] In some arrangements, an NFT can be minted for each Passport Data Package or ConfigLock Data Package, encapsulating a unique digital representation of an entity’s cybersecurity credentials or configuration settings. The minting process can include the processing circuits generating a digital hash of the package’s contents, including digital certificates, cryptographic proofs, and configuration details, and embedding this hash within the NFT. Following the minting, the processing circuits can record the NFT on a distributed ledger, assigning a unique identifier to each NFT that correlates directly with the respective Passport or ConfigLock Data Package. Furthermore, the processing circuits facilitate the verification of the NFT by external parties, allowing for the authentication of the encapsulated data against the blockchain to confirm its validity and integrity. This mechanism enables entities to prove compliance with cybersecurity standards and the secure status of their system configurations in a decentralized, tamper-proof manner. Accordingly, by integrating NFT technology with method 4400’s framework and leveraging insights from FIG. 28, the processing circuits can utilize blockchain to enhance cybersecurity management.

[0380] In some arrangements, generative AI can be employed in creating and validating both Passport Data Packages and ConfigLock Data Packages within the framework of method 4400. Initially, generative AI can automate the compilation of an entity’s cybersecurity protocols and identity verification documents. This automation can include parsing through databases to extract relevant information, synthesizing cybersecurity policy documents, and integrating business registration documents. Furthermore, generative AI can assist in digitally signing these compiled documents, employing cryptographic algorithms to ensure their authenticity and integrity. During the second steps, generative AI can be used in attaching or embedding a plurality of proof of controls to the decentralized identity passport. The generative AI can analyze the cybersecurity protection actions implemented by the entity, generating detailed metadata for each action. This metadata can then be digitally linked to the passport or embedded as QR codes or unique identifiers, directing to encrypted online repositories containing audit logs and certifications. Moreover, generative AI can optimize the digital signature process, selecting a secure and efficient digital signature scheme based on the latest advancements in cryptographic technology. The AI can also dynamically update these proofs of control based on new cybersecurity actions or validations, ensuring that the passport data package remains current and reflective of the entity’s compliance status. In validating the cybersecurity protections of entities, generative AI can compare the documented cybersecurity protection actions against a predefined set of security standards or benchmarks, such as ISO / IEC 27001 and NIST frameworks. This can include an analysis of the entity’s cybersecurity measures, utilizing machine learning algorithms to identify discrepancies or areas of non-compliance. Following validation, GAI can automate the recording of this data on a distributed ledger or data source, encrypting and hashing the validation results for security.

[0381] To safeguard the integrity and confidentiality of Passport Data Packages and ConfigLock Data Packages against potential future quantum computing threats, the processing circuits can implement quantum-resistant cryptographic algorithms. These algorithms can be designed to withstand the decryption capabilities of quantum computers, ensuring that digital signatures, cryptographic proofs, and the encryption of data remain secure. By incorporating post-quantum cryptography into the encryption process, the processing circuits secure the data against advanced computational attacks, maintaining the long-term viability and security of the stored information. The processing circuits can also integrate decentralized identity verification mechanisms to enhance the security and efficiency of verifying Passport Data Packages. Utilizing blockchain technology, this approach can be used by entities to prove their identity and the authenticity of their digital credentials autonomously, without the need for centralized verification authorities. Through this mechanism, the processing circuits facilitate a secure, privacy-preserving method of identity verification, allowing entities to manage their digital identities and associated proofs of control directly on a blockchain. In some arrangements, the processing circuits can execute machine learning and statistical modeling to improve anomaly detection capabilities within the cybersecurity framework. These systems can be used to analyze datasets in real time, detecting unusual patterns that may indicate cybersecurity threats or vulnerabilities. By employing algorithms that learn from historical data, the processing circuits equip entities with dynamic monitoring tools that adapt to new and evolving threats.

[0382] Referring now to FIG. 45, a block diagram depicting a cyber threat intelligence (CTI) model 4500 to modify security tools, according to some embodiments. The response system 130 of FIG. 25 can be configured to perform the various actions and functions described in FIG. 45. At block 4502, a processing circuit of the response system 130 can be configured to determine various cyber threats such as phishing attacks, ransomware, and DDoS attacks. For example, the depiction of a locked processor with an explanation point could indicate. Additionally, the processing circuits can determine one or more conditions. For example, the cyber threat intelligence (CTI) model 4500 depicts the condition that “In the last 7 days, Conti has attached 15 manufacturers with 50-1 OOM in revenue in Chicago. The vector is KB4B4834.” In this example, the affected sector is manufacturing, and the impact location is Chicago. In particular, the vector could be a specific malware signature or attack methodology.

[0383] Next, at block 4504, the processing circuits of the response system 130 of FIG. 25 can determine or model one or more trigger actions to perform on the security tools of companies, security vendors, and insurers / brokers. The security tools can be firewalls, intrusion detection systems, and antivirus software. In some arrangements, the trigger actions can be, but are not limited to, TTPs, changes, notices, and so on. The processing circuit of the response system 130 can model and determine trigger actions by analyzing threat intelligence and predicting likely attack vectors. For example, the processing circuits can determine TTPs of the security tools to address emerging threats identified through real-time data analysis. In another example, the processing circuit can determine changes of the security tools to enhance their responsiveness to specific threat indicators. In yet another example, the processing circuits can generate notices to be provided to the security to inform about necessary updates or patches. At 4506, the security tools of the various entities can implement the trigger actions. For example, automatic updates to threat definitions. In yet another example, configuration changes to optimize threat detection and response. In some arrangements, the TTPs can be provided to an entity, the changes can be provided to a vendor, and notices can be provided to a protection entity.

[0384] For example, in the context of the CTI model’s scenario, Conti, a cybercriminal group, has launched targeted attacks against 15 manufacturing companies within the Chicago area, all of which report revenues between 50 to 100 million dollars. This selection indicates Conti’s preference for industries with significant financial turnovers but potentially weaker cybersecurity measures compared to larger conglomerates. The vector, identified as KB4B4834, would indicate a specific malware or attack methodology that has been previously associated with Conti’s operations, for example, exploiting vulnerabilities that these mid-sized entities have overlooked. This incident can be modeling by the processing circuits to customize cybersecurity responses that are predictive, leveraging real-time threat intelligence to anticipate and mitigate such targeted attacks. The use of a vector such as KB4B4834 enables cybersecurity systems (e.g., response system 130 of FIG. 25) to trace the attack pattern back to its source, allowing for a more directed and efficient countermeasure implementation. In this example, the cybersecurity model’s is used to provide actionable intelligence based on firmographic data and specific threat vectors for the affected manufacturing entities in Chicago.

[0385] In some arrangements, FIG. 28’s CTI model 4500 can incorporated into method 600 through its functionality for dynamically adapting security tools in response to cyber threat intelligence. Method 600 outlines a process for capturing, verifying, and updating the cybersecurity capabilities of an organization, including configurations and technologies in use. The CTI model 4500, as part of this method, can determine the nature of cyber threats (e.g., phishing, ransomware) and model trigger actions for security tool adjustments. This is similar to method 600’s steps of receiving capabilities, verifying their state, and adjusting configurations based on identified needs. In the framework of method 600, the CTI model 4500’s can be shown in the analysis and application phases where cyber threats are analyzed, and appropriate responses are formulated. This include the CTI model providing real-time threat intelligence that informs the process of verifying the state of cybersecurity capabilities and deciding on necessary adjustments. When the CTI model 4500 identifies a threat, such as a specific malware vector, method 600’s mechanisms for changing state or configuration can be executed, allowing for an immediate and informed response to the identified threat. Thus, the integration of CTI model 4500 within the broader scope of method 600 enhances the capability to dynamically adapt cybersecurity measures. It does so by leveraging threat intelligence to inform the verification and adjustment steps of method 600, ensuring that security configurations and technologies remain effective against current cyber threats. SUMMARY OF CONCEPTS

[0386] Some arrangements relate to a method of improving cybersecurity protections across a plurality of entities, the method including identifying or collecting, by one or more processing circuits, incident data corresponding with a cybersecurity incident. The method further including recording, by the one or more processing circuits, the incident data in a distributed ledger or data source. The method further including analyzing, by the one or more processing circuits, the incident data utilizing a cybersecurity model to generate one or more verified intelligences corresponding to at least one cybersecurity threat. The method further including determining, by the one or more processing circuits, the one or more verified intelligences corresponds to at least one of the plurality of entities based on at least one of firmographic data, identified security gaps, or existing protection guards. The method further including decoding, by the one or more processing circuits, the one or more verified intelligences into one or more entity-specific data formats of the at least one of the plurality of entities. The method further including configuring or re-configuring, by the one or more processing circuits, at least one security tool of a computing system of the at least one of the plurality of entities, the configuration or re-configuration corresponds to protecting the at least one of the plurality of entities from the at least one cybersecurity threat.

[0387] In some arrangements, the one or more verified intelligences include at least one of threat indicators, vulnerability patches, or mitigation strategies corresponding to the at least one cybersecurity threat, and wherein the firmographic data, the identified security gaps, and the existing protection guards correspond to an entity profile of each of the plurality of entities.

[0388] In some arrangements, the decoding into the one or more entity-specific data formats includes translating the one or more verified intelligences into formats compatible with the at least one security tool of the at least one of the plurality of entities.

[0389] In some arrangements, the cybersecurity model includes at least one of heuristic analysis, pattern identification, anomaly identification, or threat projections, and wherein the cybersecurity model is executed by the one or more processing circuits in response to the cybersecurity incident.

[0390] In some arrangements, wherein configuring includes automatically generating and applying, by the one or more processing circuits, patches or updates to the at least one security tool.

[0391] In some arrangements, the method further includes generating, by the one or more processing circuits, a decentralized identity passport for each of the plurality of entities, attaching or embedding, by the one or more processing circuits, a plurality of proof of controls to the decentralized identify passport of an entity of the plurality of entities, the plurality of proof of controls corresponding to one or more cybersecurity protection actions implemented by the entity, and recording, by the one or more processing circuits, the plurality of proof of controls on the distributed ledger or data source as one or more exchanges linked to the decentralized identity passport.

[0392] In some arrangements, the method further including validating, by the one or more processing circuits, the one or more cybersecurity protections of each of the plurality of entities and recording, by the one or more processing circuits, the validation on the distributed ledger or data source as a new exchange linked to the decentralized identity passport.

[0393] In some arrangements, the method further including monitoring, by the one or more processing circuits, environmental data of a plurality of computing systems of the plurality of entities with the decentralized identity passport in response to determining at least one of the plurality of entities out of compliance with a cybersecurity parameter, issuing, by the one or more processing circuits, an alert to at least one of the plurality of entities including a recommendation to update the one or more cybersecurity protection actions.

[0394] In some arrangements, the method further including identifying, by the one or more processing circuits, a plurality of first level configurations corresponding to at least one of an operational or security action performed on the a plurality of computing systems of an entity of the plurality of entities, encrypting or tokenizing, by the one or more processing circuits, the plurality of first level configurations, and recording, by the one or more processing circuits, the plurality of first level configurations on the distributed ledger or data source.

[0395] In some arrangements, the method further including providing, by the one or more processing circuits, a recovery key to the entity, the recovery key configured to allow the recovery of the encrypted or tokenized plurality of first level configurations by the entity, receiving, by the one or more processing circuits, the recovery key, providing, by the one or more processing circuits, the plurality of first level configurations from the distributed ledger or data source based on decrypting or detokenizing the plurality of first level configurations using the recovery key, and regenerating, by the one or more processing circuits, the recovery key based on a detection of a potential compromise or at predefined intervals.

[0396] In some arrangements, the plurality of first level configurations correspond to systemlevel operations or security actions performed on the plurality of computing systems, and wherein a plurality of second level configurations correspond to secondary or maintenance operations or security actions on the plurality of computing systems.

[0397] In some arrangements, the plurality of first level configurations include at least one of network settings, security tool settings, access control lists, endpoint protection settings, or encryption keys.

[0398] In some arrangements, the plurality of first level configurations correspond to cryptographic proof of provenance obtained by the one or more processing circuits directly from the entity and programmatically, wherein the plurality of second level configurations correspond to a validation by one or more authorized entities, wherein a plurality of third level configurations correspond to documented evidence of an action, and wherein a plurality of fourth level configurations correspond to commitments made by the entity.

[0399] In some arrangements, the identifying further includes acquiring and verifying, by the one or more processing circuits, the cryptographic proof of provenance based on one or more digital signatures and transaction records stored within the distributed ledger or data source and generating, by the one or more processing circuits, the cryptographic proof of provenance for the plurality of first level configurations.

[0400] In some arrangements, the method further including updating, by the one or more processing circuits, at least one of the plurality of second level configurations, the plurality of third level configurations, or the plurality of fourth level configurations, in response to an update in the operational or security action performed on the plurality of computing systems of the entity.

[0401] Some arrangements relate to a response system for improving cybersecurity protections across a plurality of entities, the response system including one or more processing circuits including memory and at least one processor configured to identify or collect incident data corresponding with a cybersecurity incident. The at least one processor further configured to record the incident data in a distributed ledger or data source. The at least one processor further configured to analyze the incident data utilizing a cybersecurity model to generate one or more verified intelligences corresponding to at least one cybersecurity threat. The at least one processor further configured to determine the one or more verified intelligences corresponds to at least one of the plurality of entities based on at least one of firmographic data, identified security gaps, or existing protection guards. The at least one processor further configured to decode the one or more verified intelligences into one or more entity-specific data formats of the at least one of the plurality of entities. The at least one processor further configured to configure or re-configure at least one security tool of a computing system of the at least one of the plurality of entities, the configuration or re-configuration corresponds to protecting the at least one of the plurality of entities from the at least one cybersecurity threat.

[0402] In some arrangements, the one or more verified intelligences include at least one of threat indicators, vulnerability patches, or mitigation strategies corresponding to the at least one cybersecurity threat, and wherein the firmographic data, the identified security gaps, and the existing protection guards correspond to an entity profile of each of the plurality of entities.

[0403] In some arrangements, the decoding into the one or more entity-specific data formats includes translating the one or more verified intelligences into formats compatible with the at least one security tool of the at least one of the plurality of entities. 10404] In some arrangements, the cybersecurity model includes at least one of heuristic analysis, pattern identification, anomaly identification, or threat projections, and wherein the cybersecurity model is executed by the one or more processing circuits in response to the cybersecurity incident, and wherein configuring includes automatically generating and applying patches or updates to the at least one security tool.

[0405] Some arrangements relate to a non-transitory computer readable medium (CRM) including one or more instructions stored thereon and executable by one or more processors to identify or collect incident data corresponding with a cybersecurity incident, record the incident data in a distributed ledger or data source, analyze the incident data utilizing a cybersecurity model to generate one or more verified intelligences corresponding to at least one cybersecurity threat, determine the one or more verified intelligences corresponds to at least one of the plurality of entities based on at least one of firmographic data, identified security gaps, or existing protection guards, decode the one or more verified intelligences into one or more entity-specific data formats of the at least one of the plurality of entities, and configure or reconfigure at least one security tool of a computing system of the at least one of the plurality of entities, the configuration or re-configuration corresponds to protecting the at least one of the plurality of entities from the at least one cybersecurity threat. Configuration of Exemplary Embodiments

[0406] While this specification contains many specific implementation details and / or arrangement details, these should not be construed as limitations on the scope of any inventions or of what may be claimed, but rather as descriptions of features specific to particular implementations and / or arrangements of the systems and methods described herein. Certain features that are described in this specification in the context of separate implementations and / or arrangements can also be implemented and / or arranged in combination in a single implementation and / or arrangement. Conversely, various features that are described in the context of a single implementation and / or arrangement can also be implemented and arranged in multiple implementations and / or arrangements separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

[0407] Additionally, features described with respect to particular headings may be utilized with respect to and / or in combination with illustrative arrangement described under other headings; headings, where provided, are included solely for the purpose of readability and should not be construed as limiting any features provided with respect to such headings.

[0408] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In some cases, the actions recited in the claims can be performed in a different order and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results.

[0409] In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the implementations and / or arrangements described above should not be understood as requiring such separation in all implementations and / or arrangements, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0410] Having now described some illustrative implementations, implementations, illustrative arrangements, and arrangements it is apparent that the foregoing is illustrative and not limiting, having been presented by way of example. In particular, although many of the examples presented herein involve specific combinations of method acts or system elements, those acts, and those elements may be combined in other ways to accomplish the same objectives. Acts, elements and features discussed only in connection with one implementation and / or arrangement are not intended to be excluded from a similar role in other implementations or arrangements.

[0411] The phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The use of “including” “including” “having” “containing” “involving” “characterized by” “characterized in that” and variations thereof herein, is meant to encompass the items listed thereafter, equivalents thereof, and additional items, as well as alternate implementations and / or arrangements consisting of the items listed thereafter exclusively. In one arrangement, the systems and methods described herein consist of one, each combination of more than one, or all of the described elements, acts, or components.

[0412] Any references to implementations, arrangements, or elements or acts of the systems and methods herein referred to in the singular may also embrace implementations and / or arrangements including a plurality of these elements, and any references in plural to any implementation, arrangement, or element or act herein may also embrace implementations and / or arrangements including only a single element. References in the singular or plural form are not intended to limit the presently disclosed systems or methods, their components, acts, or elements to single or plural configurations. References to any act or element being based on any information, act or element may include implementations and / or arrangements where the act or element is based at least in part on any information, act, or element.

[0413] Any implementation disclosed herein may be combined with any other implementation, and references to “an implementation,” “some implementations,” “an alternate implementation,” “various implementation,” “one implementation” or the like are not necessarily mutually exclusive and are intended to indicate that a particular feature, structure, or characteristic described in connection with the implementation may be included in at least one implementation. Such terms as used herein are not necessarily all referring to the same implementation. Any implementation may be combined with any other implementation, inclusively or exclusively, in any manner consistent with the aspects and implementations disclosed herein.

[0414] Any arrangement disclosed herein may be combined with any other arrangement, and references to “an arrangement,” “some arrangements,” “an alternate arrangement,” “various arrangements,” “one arrangement” or the like are not necessarily mutually exclusive and are intended to indicate that a particular feature, structure, or characteristic described in connection with the arrangement may be included in at least one arrangement. Such terms as used herein are not necessarily all referring to the same arrangement. Any arrangement may be combined with any other arrangement, inclusively or exclusively, in any manner consistent with the aspects and arrangements disclosed herein.

[0415] References to “or” may be construed as inclusive so that any terms described using “or” may indicate any of a single, more than one, and all of the described terms. 10416] Where technical features in the drawings, detailed description or any claim are followed by reference signs, the reference signs have been included for the sole purpose of increasing the intelligibility of the drawings, detailed description, and claims. Accordingly, neither the reference signs nor their absence have any limiting effect on the scope of any claim elements.

[0417] The systems and methods described herein may be embodied in other specific forms without departing from the characteristics thereof. Although the examples provided herein CM 00 CM relate to controlling the display of content of information resources, the systems and methods described herein can include applied to other environments. The foregoing implementations and / or arrangements are illustrative rather than limiting of the described systems and methods. Scope of the systems and methods described herein is thus indicated by the appended claims, rather than the foregoing description, and changes that come within the meaning and range of equivalency of the claims are embraced therein.

Claims

1. A method of improving cybersecurity protections across a plurality of entities, the method comprising:identifying or collecting, by one or more processing circuits, incident data corresponding with a cybersecurity incident;recording, by the one or more processing circuits, the incident data in a distributed ledger or data source;analyzing, by the one or more processing circuits, the incident data utilizing a cybersecurity model to generate one or more verified intelligences corresponding to at least one cybersecurity threat;determining, by the one or more processing circuits, the one or more verified intelligences corresponds to at least one of the plurality of entities based on at least one of firmographic data, identified security gaps, or existing protection guards;decoding, by the one or more processing circuits, the one or more verified intelligences into one or more entity-specific data formats of the at least one of the plurality of entities;configuring or re-configuring, by the one or more processing circuits, at least one security tool of a computing system of the at least one of the plurality of entities, the configuration or re-configuration corresponds to protecting the at least one of the plurality of entities from the at least one cybersecurity threat;generating, by the one or more processing circuits, a decentralized identity passport for each of the plurality of entities;attaching or embedding, by the one or more processing circuits, a plurality of proof of controls to the decentralized identify passport of an entity of the plurality of entities, the plurality of proof of controls corresponding to one or more cybersecurity protection actions implemented by the entity; andrecording, by the one or more processing circuits, the plurality of proof of controls on the distributed ledger or data source as one or more exchanges linked to the decentralized identity passport.

2. The method of claim 1, wherein the one or more verified intelligences comprise at least one of threat indicators, vulnerability patches, or mitigation strategies corresponding to the at least one cybersecurity threat, and wherein the firmographic data, the identified security gaps, and the existing protection guards correspond to an entity profile of each of the plurality of entities.

3. The method of claim 1, wherein the decoding into the one or more entity-specific dataformats comprises translating the one or more verified intelligences into formats compatible with the at least one security tool of the at least one of the plurality of entities.

4. The method of claim 1, wherein the cybersecurity model comprises at least one of heuristic analysis, pattern identification, anomaly identification, or threat projections, and wherein the cybersecurity model is executed by the one or more processing circuits in response to the cybersecurity incident.

5. The method of claim 1, wherein configuring comprises: automatically generating and applying, by the one or more processing circuits, patches or updates to the at least one security tool.

6. The method of claim 1, further comprising:validating, by the one or more processing circuits, the one or more cybersecurity protections of each of the plurality of entities; andrecording, by the one or more processing circuits, the validation on the distributed ledger or data source as a new exchange linked to the decentralized identity passport.

7. The method of claim 6, further comprising:monitoring, by the one or more processing circuits, environmental data of a plurality of computing systems of the plurality of entities with the decentralized identity passport; andin response to determining at least one of the plurality of entities out of compliance with a cybersecurity parameter, issuing, by the one or more processing circuits, an alert to at leastone of the plurality of entities comprising a recommendation to update the one or more cybersecurity protection actions.

8. The method of claim 1, further comprising:identifying, by the one or more processing circuits, a plurality of first level configurations corresponding to at least one of an operational or security action performed on the a plurality of computing systems of an entity of the plurality of entities;encrypting or tokenizing, by the one or more processing circuits, the plurality of first level configurations; andrecording, by the one or more processing circuits, the plurality of first level configurations on the distributed ledger or data source.

9. The method of claim 8, further comprising:providing, by the one or more processing circuits, a recovery key to the entity, the recovery key configured to allow the recovery of the encrypted or tokenized plurality of first level configurations by the entity;receiving, by the one or more processing circuits, the recovery key;providing, by the one or more processing circuits, the plurality of first level configurations from the distributed ledger or data source based on decrypting or detokenizing the plurality of first level configurations using the recovery key; andregenerating, by the one or more processing circuits, the recovery key based on a detection of a potential compromise or at predefined intervals.

10. The method of claim 8, wherein the plurality of first level configurations correspond to system-level operations or security actions performed on the plurality of computing systems, and wherein a plurality of second level configurations correspond to secondary or maintenance operations or security actions on the plurality of computing systems.

11. The method of claim 10, wherein the plurality of first level configurations comprise at least one of network settings, security tool settings, access control lists, endpoint protection settings, or encryption keys.

12. The method of claim 8, wherein the plurality of first level configurations correspond to cryptographic proof of provenance obtained by the one or more processing circuits directly from the entity and programmatically, wherein the plurality of second level configurations correspond to a validation by one or more authorized entities, wherein a plurality of third level configurations correspond to documented evidence of an action, and wherein a plurality of fourth level configurations correspond to commitments made by the entity.

13. The method of claim 12, wherein the identifying further comprises:acquiring and verifying, by the one or more processing circuits, the cryptographic proof of provenance based on one or more digital signatures and transaction records stored within the distributed ledger or data source; andgenerating, by the one or more processing circuits, the cryptographic proof of provenance for the plurality of first level configurations.

14. The method of claim 12, further comprising:updating, by the one or more processing circuits, at least one of the plurality of second level configurations, the plurality of third level configurations, or the plurality of fourth level configurations, in response to an update in the operational or security action performed on the plurality of computing systems of the entity.

Images