Skip to content

Home

Jump to bottom
Vik Hari edited this page Mar 5, 2019 · 120 revisions

NOTE

CASE has had updates that are not merged into the case.ttl file in the master branch of the CASE repository yet. We are working on merging the cyberinvestigationexpress and sbarnum branches.

Github has a new level of notifications for repository releases. Go to the Watch button in the top right to select Releases Only.

Table of Contents

What is CASE and why use it?

Cyber-investigation Analysis Standard Expression (CASE) is a community-developed specification language, which is intended to serve the needs of the broadest possible range of cyber-investigation domains, including digital forensic science, incident response, counter-terrorism, criminal justice, forensic intelligence and situational awareness.

The primary motivation for CASE is interoperability - to advance the exchange of cyber-investigation information between tools and organizations. CASE aligns with and extends the Unified Cyber Ontology (UCO), constraining or renaming components as appropriate. CASE is specified at a semantic level and supports various serializations, but the default serialization for CASE is JSON-LD (LD here not to be confused with DL as in OWL-DL).

Its uses cases include:

  • Exchanging a large and diverse set of cyber-investigation information in standardized form while avoiding duplication
  • Interoperability between systems and tools, allowing for automation, normalization, combination, and correlation
  • Maintaining provenance at all phases of cyber-investigation lifecycles, including chain of custody
  • Enhancing tool testing and validation of their results
  • Controlling access to privileged, proprietary, and personal information (via data markings)
  • Support for custom or non-standardized structures (enabling tools containing these to still use and share information)
  • Providing structure to enhance intelligent analysis (e.g. pattern recognition, machine learning, visualization, etc.)

The project roadmap, updated quarterly as progress is made, is shown below (PDF available here).

CASE-UCO Roadmap

Navigation of ucoProject

Websites & Email

  • Links are in the right sidebar of this page (but if you have a question first read this)

Framework Tools

  • Python API - use for adoption
  • RDFDiff - use to compare glossary terms between CASE and custom data models (must be ingestible into Python rdflib)

Mappings

Proof-of-Concept Tool Integrations

  • Plaso (not currently ontology-compliant)
  • Volatility (not currently ontology-compliant)

Ontological Exploration Tools

Determine scope and get started:

It is unnecessary to know everything about the ontology if focused on domain-specific ontology refinement, or mapping/adoption concerning a specific tool. Determine your scope below and then read the pertinent guide to further understand the details, organization, and workflow of participating in the CASE community under that role.

If not familiar with ontology, this Wikipedia page and this Ontology 101 document will help create a conceptual foundation that will enable better communication with the community/teams and clarify the layers of abstraction present between the ontology's specification (structure/design), it's content (vocabulary, encoded in Turtle or other formats), and the Python API (usage of the defined vocabulary to create validated objects for import/export into JSON-LD).

Afterward, request to join the community by emailing [email protected]. You will be added to the respective Github Team and resources.

Ontologists

  • Responsibilities
    • Have a deep understanding of the goals of CASE and how representing information differently best achieves them
    • Collaborate with individuals/organizations who have domain-specific knowledge to draft proposals
    • Create and review Github issues to propose ontology changes to the objects/properties in the Natural Language Glossary based on gaps, ambiguities, and improvements noted by Mappers
      • Proposals have a default voting duration of 2 months for the CASE community to vote on which option they support for the data representation
  • Ontology Guide

Mappers

  • Responsibilities
    • Have an understanding of which CASE objects should be used to represent which types of information and when unsure consult Ontologists
    • Collaborate with Adopters to note inadequacies for Ontologists to review
    • Map internal/proprietary objects from Adopters' tools to the correct CASE objects (while guiding namespace usage)
    • Create Github issues for inadequacies so that CASE community discussion can occur
      • Discussions continue until possible options are identified for representing the data, then a proposal is put forth by the Ontologists team
  • Mapping Guide

Adopters

  • Responsibilities
    • Have an understanding of their use cases
    • Collaborate with Mappers to map objects in their tools to CASE objects
    • Integrate the CASE API into their tool
    • Create Github issues for bugs in the CASE API and supporting tools, or that are tool-specific
      • Partake in discussions on Github issues concerning data representation as CASE community members
      • If a member of your organization is contributing to CASE ontology development because of domain-specific knowledge they should do this via emailing [email protected] to join the Ontologists team, or discuss one-on-one so that Ontologists and Mappers can shepherd the concept through (only Mappers or Ontologists should make Github issues for something not tool-specific)
  • Adoption Guide

Discussion

  • Core/active members should've read the above for understanding roles and workflow/organization. However, if desiring to simply add your two-cents to ontology evolution please visit the Issues tab and filter on the Community-FeedbackNeeded and Community-Vote labels (all labels found here)

I have a question!

Before you post a Github issue or send an email ensure you've done this checklist:

  1. Determined scope of your task. It is not necessary for most parties to understand all aspects of the ontology, mapping methods, and supporting tools.

  2. Familiarize yourself with the labels and search the Issues tab. Typically, only light-blue and red labels should be used by non-admin Github users while the others should be used by CASE Github admins. All but the red Project labels are found in every ucoProject repository.

Governance/licensing

Formalization of licensing is in the works as well as a Governing Model. At this time Apache2 license is planned to be used.

Clone this wiki locally