This came up when it was mentioned to me a data dictionary for insider threats. Coming from data governance I had only considered these being about databases, tables and columns, when this was more about building a library of information around past incidents so that information can be used to help with insider threats in the future, build models, etc.
Searching for information around this I ran into Sarah Miller’s (Software Engineering Institute, Carnegie Mellon University, CERT) presentation, titled Leveraging Insider Threat Incident Data and Information Sharing for Increased Organizational Resiliency, which is a great primer and lead me to further information.
Still learning here but there are a few things I need to do further research on:
- Cyber Observable eXpression (CybOX): is a standardized language for encoding and communicating high-fidelity information about cyber observables.
- Structured Threat Information eXpression (STIX) is a standardized XML programming language for conveying data about cybersecurity threats in a common language that can be easily understood by humans and security technologies.
- Trusted Automated eXchange of Indicator Information (TAXII) is a protocol used to exchange cyber threat intelligence (CTI) over HTTPS.
- OpenIOC
OpenIOC is an open framework, meant for sharing threat intelligence information in a machine-readable format. It was developed by the American cybersecurity firm MANDIANT in November 2011. It is written in eXtensible Markup Language (XML) and can be easily customized for additional intelligence so that incident responders can translate their knowledge into a standard format. Organizations can leverage this format to share threat-related latest Indicators of Compromise (IoCs) with other organizations, enabling real-time protection against the latest threats.
https://cyware.com/educational-guides/cyber-threat-intelligence/what-is-open-indicators-of-compromise-openioc-framework-ed9d
OpenIOC is about sharing information. In some cases I think it would be beneficial to store this information privately if it contains sensitive information to particular breaches that happened to your organization, that you may not want to publicize, but still use for anticipating future incidents in your organization. While sharing outside the organization is ideal, some information must of course be held back.
The others listed above seem to be all protocols or language/syntax to convey this information and not actual tools of databases containing libraries of incidents.
Next step, further research, especially Splunk.