Privacy preserving information sharing

Abstract

There is provided an incident reporting method comprising: receiving encrypted attributes of at least one incident; aggregating the encrypted attributes based on an incident taxonomy to provide an aggregated report; and providing access to the aggregated report based on an accessor satisfying an access policy, wherein the aggregated report provides a summary of the encrypted attributes.

Description

[0001] PRIVACY PRESERVING INFORMATION SHARING

[0002] Field of the Invention

[0003] Aspects of the present disclosure relate generally to systems and methods for incident reporting, such as incidents of cybersecurity, and more specifically to privacy preserving information sharing.

[0004] Background of the Invention

[0005] The sharing of information around an incident such as a cyber-attack provides analytics which can be used to analyze future threats. A drawback of information sharing is the disclosure of sensitive data related to said cyber-attack. In some cyber-attack cases, for example ransomware attacks, there is typically low rates of reporting of the cyber-attack incident to law enforcement agencies, threat analysis reports, and the generation of evidence-based statistics (e.g., for the benefit of the Cyber insurance industry).

[0006] There are many barriers related to the sharing of information. Said barriers may include legal / data protection barriers, and where personally identifiable information (PH) may be contained in data. Barriers often relate to the impact of data privacy acts, such as the General Data Protection Regulation (GDPR) and Health Insurance Portability and Accountability Act (HI PAA).

[0007] Another barrier related to sharing information is interoperability and / or compatibility issues between different systems (e.g., systems operated by different law enforcement agencies, cybersecurity service providers and / or insurance providers). While standardization does exist around threat sharing with systems such as trusted automated exchange of intelligence information (TAXI I) and structured threat information expression (STIX), there exists a lack of general usage of these methods.

[0008] An aspect of information sharing is trustworthiness of the information, or data, provided in the collaborative environment. While collaboration is typically positive, contributors to the sharing infrastructure typically expect fair sharing. Issues can occur when there is a lack of reciprocity or from so called “free-riders”.

[0009] Although open data systems and crowd-sourced data platforms often provide a good source of data provision, there can often be issues around the licensing of data. This might include restricting use to academic research purposes or for other non-commercial reasons. There may also be ethical and / or moral restrictions attached to the use of the data.Accordingly, there is a desire for improved methods for the handling of cybersecurity incidents e.g., to promote reporting and information sharing.

[0010] Summary of the Invention

[0011] In a first aspect there is provided an incident reporting method comprising: receiving encrypted attributes of at least one incident; aggregating the encrypted attributes based on an incident taxonomy to provide an aggregated report; and providing access to the aggregated report based on an accessor satisfying an access policy, wherein the aggregated report provides a summary of the encrypted attributes.

[0012] In some examples, the method may comprise encrypting the attributes of the at least one incident using homomorphic encryption.

[0013] In some examples, the method may comprise storing the encrypted attributes in a database according to the incident taxonomy.

[0014] In some examples, the access policy may be an attribute-based access policy.

[0015] In some examples, the attributes may comprise any of time, location, and / or the ability to provide a recognized proof of identity.

[0016] In some examples, the access policy may be dynamically updated.

[0017] In some examples, the taxonomy may comprise a formalized definition of the incident.

[0018] In some examples, the access policy may be based on a key based encryption method. In some examples, the step of providing access may be performed within a trusted environment.

[0019] In some examples, the incident may be any of a security incident, cybersecurity incident, insurance and / or criminal incident.

[0020] In a second aspect, there is provided a data storing method comprising; receiving data related to an incident; encrypting the data according to a first encryption method; aggregating the data according to a data type to provide aggregated data; and encrypting the aggregated data according to a second encryption method.

[0021] In some examples, the data type may be defined based on a predetermined incident taxonomy.

[0022] In some examples, the incident is any of a security incident, cybersecurity incident, insurance and / or criminal incident.

[0023] In some examples, the first encryption method is homomorphic encryption.In some examples, the second encryption method is key based encryption.

[0024] In some examples, the key based encryption is based on attributes of an entity accessing the data.

[0025] In a third aspect, there is provided a computer readable medium comprising instructions stored thereon such that when executed by a processor cause an electronic device comprising said processor to carry out the method according to the first aspect and / or the second aspect. In a fourth aspect there is provided an electronic computing device comprising: a memory storing instructions thereon and at least one processor configured to perform the method of the first aspect and / or the second aspect.

[0026] Brief Description of the Drawings

[0027] Figure 1 depicts an example of data flows according to some embodiments ; and

[0028] Figure 2 depicts a ransomware taxonomy according to some embodiments.

[0029] Detailed Description

[0030] Aspects of the present disclosure relate to defining a taxonomy for cybersecurity incidents that may facilitate the processing of data around said cybersecurity incident, e.g., by law enforcement agencies and the like. Aspects of the present disclosure further relate to an anonymization method which allows incidents of cybersecurity to be reported on without revealing sources of or sensitive information gathered from said incident of cybersecurity . The disclosed methods may allow for a searcher to define search criteria and then for a data processor to perform a search for target attributes. This will then return the data elements which match the search criteria without revealing sensitive information around the contents of those attributes. The protection of each record is defined using a cipher policy where the revealing of the data requires proof of attributes.

[0031] In some examples, a method of homomorphic authentication with key integration (known herein as HAWK) is provided, comprising the matching of data elements that have been collected and privacy protected within a cybersecurity incident, and matching the protected data elements to a policy for the consumption of said data elements (e.g., by law enforcement agencies, insurance providers and the like). The proposed method may comprise employing a privacy-enhancing method to protect source data gathered from cybersecurity incidents, and an attribute based access policy governing the access and usage of the data, controlling how the data is delivered within aggregated searches.In some examples, homomorphic encryption is used to provide said privacy enhancement. Homomorphic encryption may be used to provide a shortlist of search entries from data records, the access of which is protected using an attribute-based policy. In some examples, attributes may relate to any of time, location, and / or the ability to provide a recognized proof of identity.

[0032] In some examples, a cybersecurity incident taxonomy may be defined for a cybersecurity incident (e.g., a ransomware incident), which may comprise a formalized definition of a cybersecurity incident.

[0033] In a specific example related to a ransomware incident, an evidence bag may, for example, include elements of a ransomware payment method, operating system details (e.g., type and / or version), and an attack mechanism. An element of real-time reporting of ransomware incidents is the capture of evidence from incidents. A complete taxonomy will depend on the requirements of the incident.

[0034] Further aspects of the present disclosure relate to cyber-incident reporting taxonomy and access control on cyber-incident attributes with a contract binding (i.e. , attribute based access policy).

[0035] Each data element of the cyber-incident attribute may be encrypted using homomorphic encryption for integer values. Access to the homomorphically encrypted values may be governed by attributed-based encryption (ABE). For example, a user wishing to access e.g., data related to how many operating systems of a particular type were infected in particular time range may only be granted access to said data if they meet a certain location requirement (e.g., based in the USA).

[0036] By employing ABE, a trusted agency (e.g., a law enforcement agency) may define access attributes required to reveal a homomorphically encrypted value. The access attributes thus define the access policy for accessing the homomorphically encrypted data.

[0037] In a non-limiting example, the John Doe Law Enforcement Agency may define that only USbased agencies are allowed to reveal the target operating system of a system involved in a cyber-incident. In this example, a trusted access attribute may be GPS coordinates of a registered location of a data processor associated with an accessing electronic device. In other examples an access policy may be determined based on the credential of a user accessing the data. Additionally or alternatively, a time attribute may be applied wherein data may only be used and / or accessed within a time range specified by the trusted agency.

[0038] As described previously, in some examples an access policy may be set by e.g., a law enforcement agency, national cybersecurity body (e.g., Government CommunicationsHeadquarters (GCHQ)) and the like. In other examples, an access policy may be updated dynamically. For example, access to certain data may be provided based on a case status of a related incident, a duration of time passed since an incident report, changes in national legislation, interdepartmental or inter-agency policy changes and the like.

[0039] In any or all examples, data accessed, e.g., by a user satisfying said access policy, is encrypted data. That is, a user is provided access to a numerical summary of incident data in accordance with the access policy, (e.g., a report of number of infections per day etc.) but the data accessed via the access policy is anonymised (e.g., identification of core original incident data such as data that may identify an infected party, is not possible). Advantageously, incident data is protected by a double layer of encryption, thus improving the protection of sensitive data.

[0040] Figure 1 provides an overview of data flows according to the presently disclosed method. Targets A-C (e.g., targets of a cybersecurity incident) may report an incident to a trusted agency 250a-250c, for example to a law enforcement agency, insurer and / or the like. A trusted evidence gatherer from the trusted agency 250a-250c (e.g., a law enforcement officer) may document data 210a-210c related to the incident, i.e. , gather a so-called digital evidence bag 220a-220c. The digital evidence bag 220a-220c may be logged (e.g., on a police database) as part of a criminal incident, tallied with an insurance company and so on.

[0041] In some examples, the incident may be any of a cybersecurity incident, security incident (i.e., non-cyber based), criminal incident and / or insurance incident. That is, any incident that may comprise attributes that may be represented with digital records. For example, acts of fraud may be committed offline, but may have attributes (e.g., target type, location, time range) that can be logged digitally and thus be the subject of a digital evidence bag.

[0042] In some examples, the digital evidence bag may comprise an electronic token, which may verify the data 210a-210c that has been gathered. The electronic token may include an incident ID, indicator of the type of incident, number of files that have been encrypted, and a digital signature (i.e., of the evidence bag).

[0043] The trusted agency 250 may encrypt the gathered evidence using a form of encryption that converts the gathered evidence data into an encrypted form that can be analyzed and operated on as if it were still in its original form, e.g., using homomorphic encryption. The encrypted data 230a-230c may be tagged and stored in e.g., a database 240, according to an incident taxonomy. Advantageously, the gathered evidence 220a-220c may be aggregated (e.g., from different evidence bags) and analyzed in encrypted form, without revealing any sensitive information related to the original evidence data 210a-210c (e.g., details that may serve to identify any of targets A-C).Aggregated data 260 may be provided to a user 280 (e.g., threat hunters, law enforcement, regulatory bodies, insurance providers and the like) for analysis. In some examples, aggregated data is provided based on a search performed by said user 280.

[0044] As described previously, access to said aggregated data 260 is based on a user 280 satisfying an access policy. In some examples, the user may only access the aggregated data 260 through a trusted environment 270, also known as a secure enclave.

[0045] The database 240 and trusted environment 270 may be hosted by a trusted agency (e.g., any of trusted agencies 250a-250c) or a trusted third party 255. That is, a trusted agency (e.g., any of trusted agencies 250a-250c) that gathers and encrypts evidence data 210a-210c may also host database 240, provide access to aggregated data 260 (i.e. , through the determining of access policies) and host the trusted environment 270 (e.g., through different departments of the same law enforcement agency). In other examples, the database 240 and trusted environment 270 may be provided by a trusted third party 255, separate from the trusted agency 250a-250c (as depicted in Figure 1).

[0046] Thus, database 240 may receive privacy-preserved data from digital evidence bags which is aggregated to produce searchable results. Access to the aggregated data is locked within a data contract which restricts the access to data.

[0047] The privacy preserved data (i.e., encrypted evidence data 210a - 210c) may be received by a trusted agency 250a-250c (e.g., from a trusted third party 255) and / or the privacy preserved data may be determined and encrypted by the trusted agency.

[0048] In some examples, reporting according to the methods disclosed herein may integrate privacypreserving incident data with other threat-hunting information, such as provided by Shodan, Open Source Scanning, and / or the like.

[0049] Accordingly, in a first aspect, there is provided an incident reporting method comprising: receiving encrypted attributes of at least one incident; aggregating the encrypted attributes based on an incident taxonomy to provide an aggregated report; and providing access to the aggregated report based on an accessor satisfying an access policy, wherein the aggregated report provides a summary of the encrypted attributes.

[0050] The method may comprise encrypting the attributes of the at least one incident using homomorphic encryption.

[0051] The method may further comprise storing the encrypted attributes in a database according to the incident taxonomy.

[0052] The access policy may be an attribute-based access policy, wherein the attributes comprise any of time, location, and / or the ability to provide a recognized proof of identity.In some examples, the access policy may be dynamically updated.

[0053] The taxonomy may comprise a formalized definition of the incident, and in some examples the access policy is based on a key based encryption method.

[0054] The step of providing access may be performed within a trusted environment.

[0055] Said incident may be any of a security incident, cybersecurity incident, insurance and / or criminal incident.

[0056] Incident Taxonomy

[0057] As described previously, on the reporting of an incident, an evidence gatherer may gather information about said incident. Data flows during incident reporting may comprise the reporting of the incident by a victim to law enforcement, to audit trails for insurance purposes and crime reports, and from law enforcement agencies to threat reporting and searching. A record may be defined as a single reporting entity related to an incident. Additional data related to the incident may be added as an investigation progresses.

[0058] There is often a lack of structure within the evidence gathered from incidents such as cybersecurity incidents, which may lead to reduced opportunities to link and cross-correlate data fields. In order to solve this problem, there is proposed an incident taxonomy for logging (encrypted) incident data.

[0059] Figure 2 defines an overview of a purely exemplary taxonomy for a ransomware incident response.

[0060] In order to integrate with the privacy-aware data analysis as provided herein, each of the data elements in the evidence bag may be tagged against said taxonomy.

[0061] The following example (Figure 2) is related to an incident of ransomware. It will be understood by the skilled person that the following is merely an example and that the presently disclosed methods may be applied to cybersecurity incidents of different types, which will have their own taxonomy defined accordingly.

[0062] Further, although some embodiments described herein are directed to the field of cybersecurity, the methods disclosed herein are not limited to the treatment and reporting of cybersecurity incidents. That is, the presently disclosed methods may be suitable for reporting on any incident that would benefit from the enhanced security methods described (i.e., enabling privacy preserving information sharing), e.g., non-cyber related crimes, security incidents, insurance incidents and / or the like.Thus, a purely exemplary outline of attribute data fields for a ransomware incident may comprise any of the following:

[0063] INCIDENT

[0064] Examples of an Incident field 210 may comprise:

[0065] A Report field may relate to recordable data elements that define the details of recorded incidents, including report date, time, location, and the like.

[0066] A Type field may define the type of ransomware classification used, such as a Locker, Crypto ransomware, Master Boot Record, and the like.

[0067] A Family field may define a family which best matches the ransom, such as Jigsaw, NotPetya, Ryuk, and the like.

[0068] A Delivery Mechanism Field may define a mechanism used in the actual delivery of the ransomware, such as Phishing, Malicious URL, Backdoor, Remote Desktop, Worm, Compromised Web sites, and the like.

[0069] A Platform field may define a core platform and version. This may include Microsoft Windows, Mac OS, Linux, and the like.

[0070] A Toolkit filed may define a toolkit that is used to implement the ransomware, such as Node.js, Crypto library, Customized, and the like.

[0071] A Payment field may define details of a payment mechanism used and associated links. RANSOMWARE ENCRYPTION A Ransomware Encryption field 220 is where fields may be defined for the generation of cryptographic artefacts, such as keys and salts, which are used by ransomware in encrypting files using cryptographic algorithms. These may comprise any of:

[0072] • Command and Control.

[0073] • Hard coded encryption key.

[0074] • Key from execution.

[0075] • No key.

[0076] • Hybrid.

[0077] A mixture of encryption methods may be used, including symmetric key or asymmetric key methods used to encrypt data. Typical identifiers may comprise any of:

[0078] • Data Encryption Type. This defines the algorithm used in encrypting files and the associated mode.• Key Pairs. If public key encryption is used to protect a symmetric key, this field will record the public key used.

[0079] • Salt Integration. This defines the method of generating the salt value and its size. • Key Generation method. This relates to the method of creating the ransomware symmetric key.

[0080] RANSOMWARE COMMAND AND CONTROL A Ransomware Command and Control field 230 may define the command and control channels that are used for the transmission of keys from a controller to the ransomware executing on a victim’s device and / or for communicating details of the victim’s device, such as a generated ID, to the controller. For the Ransomware Command and Control field, there are three types of command and control communication enumerations:

[0081] • Static Domain.

[0082] • No Channel.

[0083] • Dynamic Domain Generation.

[0084] OBFUSCATION

[0085] For obfuscation techniques, an OBFUSCATION field 240 may be defined which relates to the targeting of files. Obfuscation is used by malware authors, making detection of the executable by software programs such as virus checks more difficult.

[0086] RANSOMWARE FILE

[0087] The Ransomware File field 250 may relate to the targeting of files, and may comprise any of:

[0088] • Normally, with ransomware, the files are encrypted, and their file extension is changed.

[0089] These may be stored with SEARCH_EXTENSIONS.

[0090] • With encrypted file extensions, the field extension(s) is added to the encrypted file.

[0091] This field may be defined as EXTENSION.

[0092] • In addition to ransomware families using fixed file extensions, others generate user / device ID extensions and include tags at the end of the encrypted file to check whether the file is unencrypted. This field may be defined as TAGS.

[0093] • Folders are less commonly targeted as file system structures are generally user- defined. Thus, ransomware frequently recursively iterates through folders starting from the highest level to identify potential targets. Under, for example, the Windows operating system, files in ’My Documents’ folders are commonly targeted. This field may be defined as FOLDERS.

[0094] • Excluded folders are folders that enable the operating system to perform standard operations that are usually not encrypted by ransomware. Examples of such folders indevices using the Windows operating system are c:\Windows\system32. This field may be defined as EXFOLDERS.

[0095] • With excluded files, there are files that are essential for a device to operate but not in excluded folders and are not encrypted so that a ransom note can be displayed. Examples of such files in devices using the Windows operating system include boot.ini, and ntuser.dat. This field may be defined as EXFILES.

[0096] RANSOMWARE DISABLEMENT A Ransomware Disablement field 260 may relate to the disabling of prevention and recovery techniques. Malware authors typically ensure that the ransomware runs to completion. The following lists typical types of protection and prevention used in ransomware:

[0097] • Ransomware commonly terminates programs that might impede ransomware operation, such as anti-virus. This field may be defined as PROCESS_TERM I NATION and stored within a semi-colon-separated list.

[0098] • Deleting shadow copies that might otherwise be used to recover from encryption are commonly disabled. This field may be defined as SHADOW_COPY and may be stored as a Boolean in some examples.

[0099] RANSOMWARE EXFILTRATE A Ransomware Exfiltrate field 270 may relate to the ransomware attackers extracting data from a target prior to encryption. Data is typically extracted to an external device managed by the attackers through communications protocols. This field may be defined as PROTOCOL and may comprise:

[0100] • Using HTTP

[0101] • Using HTTPS

[0102] • Using SSH

[0103] • Using RDP

[0104] • Using FTP

[0105] CAMPAIGN

[0106] Examples of a Campaign field 280 may comprise:

[0107] • Message displayed

[0108] • Vulnerability: CVE Number

[0109] • Threat Actor

[0110] Cybersecurity attack reports (i.e. , as accessed by user 280) may contain summaries of data sources corresponding to elements described in the taxonomy definition. Source data privacyis achieved through restricted report access (attribute based access policies) and preventing access to source data (through encryption).

[0111] Each of the above mentioned attributes of an incident record may formally matched to a ransomware taxonomy which may comprise encrypted versions of the data. Each taxonomy element is matched with an arithmetic value. This allows integration of a privacy-preserving infrastructure where encrypted date and e.g., location of searching entities may be used to provide access to incident records (and related attributes).

[0112] Thus, aspects of the present disclosure provide for a double-locking data storing method comprising homomorphic encryption of the protection of cybersecurity incident parameters and attribute based encryption to protect access.

[0113] For privacy, core source data is not revealed within the privacy-preserving (i.e., encrypting) process. By using homomorphic encryption, source data summary information is available without compromising the source data (i.e., revealing sensitive / private information).

[0114] Restricted report access protecting data elements is maintained by enforcing policies that restrict access to specific data elements and summarized data sources. An access policy may be enforced through the application of attribute-based encryption to data elements (i.e., encrypted incident data).

[0115] Incident data may be provided through homomorphically encrypted data records. In some examples, each record may be digitally signed by a trusted agency and may have an integrated access policy on the access to the records. The access policy may define the entities (e.g., user 280) that may access the records and also the range of searches that the records can be used within. Processes of the records from multiple trusted agencies (e.g., trusted agency 21 Oa-210c) may be run within a trusted environment (e.g., trusted environment 270).

[0116] Data elements exposed (e.g., aggregated data 260) from trusted data sources are protected by search access rights. If an entity (e.g., user 280) does not have the right to perform a search, the search will not be allowed. In this way, the trust infrastructure creates a whitelist of searches, and which are tied to the rights of those providing data records.

[0117] Each search may have a core element and sub-elements. Two of the most fundamental core elements are time and location, which may be converted into numerical values and encrypted with homomorphic encryption. A search on time ranges thus may involve a homomorphic subtraction of the encrypted time stamps, which may return a series of incidents within a given range. Once these are short-listed, sub-elements may be searched, for example a search for the operating system type for a compromised system.For example, data may be captured, encrypted and logged relating to an operating system type from a Microsoft Windows environment. Homomorphic encryption may be used to count the number of occurrences for a given time window.

[0118] In some examples, elements of a search can support the usage of zero-knowledge proofs (ZKPs). An example of this is providing proof of a given country without revealing the specific location of the infection.

[0119] Thus, in accordance with aspects of the present disclosure, there is provided a data storing method comprising; receiving data related to an incident; encrypting the data according to a first encryption method; aggregating the data according to a data type to provide aggregated data; and encrypting the aggregated data according to a second encryption method.

[0120] The data type may be defined based on a predetermined incident taxonomy as disclosed herein, and the incident may be any of a security incident, cybersecurity incident, insurance and / or criminal incident.

[0121] The first encryption method may be homomorphic encryption and / or the second encryption method may be a key based encryption.

[0122] Said key based encryption may be determined based on attributes of an entity seeking to access the data.

[0123] In a specific, non-limiting example, a ransomware record from an incident may be considered. For record number m, the record may be named RECm. RECm may contains fields (Fn) and where each of the fields is encrypted with cipher policy - attributed based encryption (CP-ABE). The field element then becomes CP (Fn), and an associated policy is then stored with the field or associated with the record (Pn).

[0124] In order to decrypt the field element, the accessor must gather the required attributes to generate a key required to decrypt the fields and / or the record.

[0125] In a purely exemplary scenario, the setup of CP-ABE may comprise any of the following steps: Setup: A setup step may generate public parameters (PK) and a master key (MK).

[0126] Encrypt(PK, M, A): An encrypt step may comprise the inputs PK, and a message (M), along with an access structure for all the attributes (A). The output will be some ciphertext (CT) and which embeds A, so that when a user satisfies the required attributes, they will be able to decrypt the ciphertext.

[0127] Key Generation(MK, S). A key generation step may comprise the inputs master key (MK) and a number of attributes that define a key (S), and output a private key (SK).Decrypt(PK, CT, SK). A decrypt step may comprise the inputs PK, the cipher text (CT) which contains the access policy), and the secret key (for a given set of attributes S). The decrypt step may further comprise an attempt to decrypt the ciphertext. If successful, message (M) is received back.

[0128] Delegate(SK, S~). If required, a delegate may take the private key (SK) and return a secret key (S~K) for a given set of attributes (S~).

[0129] The description provided herein may be directed to specific implementations. It should be understood that the discussion provided herein is provided for the purpose of enabling a person with ordinary skill in the art to make and use any subject matter defined herein by the subject matter of the claims.

[0130] It should be intended that the subject matter of the claims not be limited to the implementations and illustrations provided herein, but include modified forms of those implementations including portions of implementations and combinations of elements of different implementations in accordance with the claims. It should be appreciated that in the development of any such implementation, as in any engineering or design project, numerous implementation-specific decisions should be made to achieve a developers’ specific goals, such as compliance with system-related and business-related constraints, which may vary from one implementation to another. Moreover, it should be appreciated that such a development effort may be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having benefit of this disclosure. For example, the presently disclosed systems and methods may be implemented in parallel or in combination with other substrate characterization methods including, for example, the use of camera technologies.

[0131] Reference has been made in detail to various implementations, examples of which are illustrated in the accompanying drawings and figures. In the detailed description, numerous specific details are set forth to provide a thorough understanding of the disclosure provided herein. However, the disclosure provided herein may be practiced without these specific details. In some other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure details of the embodiments.

[0132] It should also be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and, similarly, a second element could be termed a first element.The first element and the second element are both elements, respectively, but they are not to be considered the same element.

[0133] The terminology used in the description of the disclosure provided herein is for the purpose of describing particular implementations and is not intended to limit the disclosure provided herein. As used in the description of the disclosure provided herein and appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. The term “and / or” as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. The terms “includes,” “including,” “comprises,” and / or “comprising,” when used in this specification, specify a presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof.

[0134] While the foregoing is directed to implementations of various techniques described herein, other and further implementations may be devised in accordance with the disclosure herein, which may be determined by the claims that follow. Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

Claims1. An incident reporting method comprising:receiving encrypted attributes of at least one incident;aggregating the encrypted attributes based on an incident taxonomy to provide an aggregated report; andproviding access to the aggregated report based on an accessor satisfying an access policy, wherein the aggregated report provides a summary of the encrypted attributes.

2. The method of claim 1 , further comprising encrypting the attributes of the at least one incident using homomorphic encryption.

3. The method of claim 1 or claim 2, further comprising storing the encrypted attributes in a database according to the incident taxonomy.

4. The method of any previous claim, wherein the access policy is an attribute-based access policy.

5. The method of claim 4, wherein the attributes comprise any of time, location, and / or the ability to provide a recognized proof of identity.

6. The method of any previous claim, wherein the access policy is dynamically updated.

7. The method of any previous claim, wherein the taxonomy comprises a formalized definition of the incident.

8. The method of any previous claim, wherein the access policy is based on a key based encryption method.

9. The method of any previous claim, wherein the step of providing access is performed within a trusted environment.

10. The method of any previous claim, wherein the incident is any of a security incident, cybersecurity incident, insurance and / or criminal incident.

11. A data storing method comprising;receiving data related to an incident;encrypting the data according to a first encryption method;aggregating the data according to a data type to provide aggregated data; and encrypting the aggregated data according to a second encryption method.

12. The method of claim 11, wherein the data type is defined based on a predetermined incident taxonomy.

13. The method of claim 11 or claim 12, wherein the incident is any of a security incident, cybersecurity incident, insurance and / or criminal incident.

14. The method of any of claims 11 to 13, wherein the first encryption method is homomorphic encryption.

15. The method of any of claims 11 to 14, wherein the second encryption method is key based encryption.

16. The method of claim 15, wherein the key based encryption is based on attributes of an entity accessing the data.

17. A computer readable medium comprising instructions stored thereon such that when executed by a processor cause an electronic device comprising said processor to carry out the method according to the any previous claim.

18. An electronic computing device comprising:a memory; andat least one processor;configured to perform the method of any of claims 1 to 16.

Images