Need Ability to Represent an Email System and Email System Facet Class and Properties

[vulnmaster]

Background

In the realm of cyber investigations, accurately capturing the state of an email within its service environment is crucial. Currently, UCO provides detailed structures for email content in observable:EmailMessageFacet, but UCO lacks specific attributes that reflect an email's system-level status. Introducing observable:EmailSystem and observable:EmailSystemFacet will enable a richer representation of these system-level properties, enhancing analysis capabilities in cyber forensic investigations.

With the introduction of the observable:EmailSystemFacet class in UCO, we achieve a more detailed and nuanced representation of email-related concepts for cyber forensic investigators and analysts. This matters because it enables these professionals to access critical system-level information about emails, such as whether they are archived, auto-forwarded, flagged, or read. Such information is pivotal in understanding the behavior and intent of users within a cyber investigation.

I am fine with my examples in this change proposal being transcribed and credited when others can re-use this content.

Requirements

Define observable:EmailSystem as a new class in UCO.
Define observable:EmailSystemFacet as a new class in UCO to encapsulate system-level email attributes.

Requirement 1

Include properties within observable:EmailSystemFacet: IsArchived, IsAutoForwarded, IsFlagged, IsFlaggedSpam, IsForwarded, IsRead.

Requirement 2

I think we need to integrate observable:EmailSystemFacet with observable:EmailMessageFacet to link email content attributes and system-level properties. I'm not exactly sure how to do this so need some assistance. It seems to me that Email Systems contain Email Messages.

Risk / Benefit analysis

Benefits

Provides a comprehensive view of an email's status within its system, crucial for detailed forensic analysis.
Enhances the granularity and accuracy of email-related data representation in UCO.

Risks

Implementation complexity and potential overlap with existing email-related classes.
Requires updates to existing UCO tooling and documentation.

Competencies demonstrated

Enhanced ability to analyze and interpret the status and handling of emails in cyber investigations.

Here's an example SPARQL query that searches for encrypted and auto-forwarded emails from vulnmaster@businessemail.com to vulnmaster@personalemail.com in the year 2023, using the proposed observable:EmailSystemFacet class and its properties:

PREFIX uco-observable: <https://ontology.unifiedcyberontology.org/uco/observable/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

SELECT ?email
WHERE {
  ?emailSystemFacet a uco-observable:EmailSystemFacet .
  ?emailSystemFacet uco-observable:IsAutoForwarded "true"^^xsd:boolean .
  ?email a uco-observable:EmailMessageFacet .
  ?email uco-observable:isEncrypted "true"^^xsd:boolean .
  ?email uco-observable:from "vulnmaster@businessemail.com" .
  ?email uco-observable:to "vulnmaster@personalemail.com" .
  ?email uco-observable:dateSent ?date .
  FILTER (YEAR(?date) = 2023).
}

Scenario
Vulnmaster has two email accounts: one for business (vulnmaster@businessemail.com) and one personal (vulnmaster@personalemail.com). Some emails are encrypted and auto-forwarded from the business to the personal account in 2023. The auto-forwarding of encrypted emails may be indicative of an employee who is stealing intellectual property from the company.

Ground Truth Positive Question
"Which emails from Vulnmaster's business account were encrypted and auto-forwarded to his personal account in 2023?"

Expected Result
Emails that meet all the criteria: sent from the business account, received at the personal account, encrypted, and auto-forwarded within the year 2023.

Ground Truth Negative Question
"Are there any emails from Vulnmaster's personal account that were auto-forwarded to his business account in 2023?"

Expected Result
No emails should be returned, as the auto-forwarding is set only from the business to the personal account, not vice versa.

These questions help validate the implementation of the observable:EmailSystemFacet class and its properties, ensuring the ontology accurately captures and queries the specific email transaction scenarios.

Competency 1

Enhanced ability to analyze and interpret the status and handling of emails in cyber investigations.

Competency Question 1.1

How can investigators determine the system-level state (like read status, archival status) of an email in a given investigation?

Result 1.1

With observable:EmailSystemFacet, investigators can effectively determine these states, providing a deeper understanding of the email data within its service context.

Solution suggestion

Define observable:EmailSystemFacet as a new class in the UCO ontology.

Add the proposed properties to this class to capture various system-level states of emails.

@prefix observable: <https://ontology.unifiedcyberontology.org/uco/observable/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

observable:EmailSystem
    a owl:Class ;
    rdfs:label "EmailSystem"@en ;
    rdfs:comment "Represents the system-level information about an email service."@en ;
    sh:targetClass observable:EmailSystem ;
    .

observable:EmailSystemFacet
    a owl:Class, sh:NodeShape ;
    rdfs:subClassOf core:Facet ;
    rdfs:label "EmailSystemFacet"@en ;
    rdfs:comment "A grouping of properties unique to an email within an email service. If the same email is sent to two different accounts, the users of those accounts may further classify or group emails with these properties so that their corresponding analytics results are different among the two email systems and accounts."@en ;
    sh:property
        [
            sh:datatype xsd:boolean ;
            sh:path observable:IsArchived ;
        ],
        [
            sh:datatype xsd:boolean ;
            sh:path observable:IsAutoForwarded ;
        ],
        [
            sh:datatype xsd:boolean ;
            sh:path observable:IsFlagged ;
        ],
        [
            sh:datatype xsd:boolean ;
            sh:path observable:IsFlaggedSpam ;
        ],
        [
            sh:datatype xsd:boolean ;
            sh:path observable:IsForwarded ;
        ],
        [
            sh:datatype xsd:boolean ;
            sh:path observable:IsRead ;
        ]
    ;
    sh:targetClass observable:EmailSystemFacet ;
    .

Here is an initial working draft example UCO json-ld that I developed showing a search result.

{
  "@context": {
    "uco-observable": "https://ontology.unifiedcyberontology.org/uco/observable/",
    "xsd": "http://www.w3.org/2001/XMLSchema#"
  },
  "@id": "kb:compilation-1234abcd-5678-efgh-9101-ijklmnopqrst",
  "@type": "core:Compilation",
  "contains": {
    "@id": "kb:emailsystemfacet-2345bcde-6789-fghj-0123-klmnopqrstuv",
    "@type": "uco-observable:EmailSystemFacet",
    "isAutoForwarded": true,
    "emails": [
      {
        "@id": "kb:email-3456cdef-7890-ghij-1234-mnopqrstuvwxyz",
        "@type": "uco-observable:EmailMessage",
        "from": "vulnmaster@businessemail.com",
        "to": "vulnmaster@personalemail.com",
        "dateSent": "2023-01-15T08:30:00Z",
        "isEncrypted": true,
        "observable:bodyRaw": "VGhpcyBlbWFpbCBjb250YWlucyBzdG9sZW4gaW50ZWxsZWN0dWFsIHByb3BlcnR5Lg=="
      },
      {
        "@id": "kb:email-4567def0-8901-hijk-2345-opqrstuvwxyzabcd",
        "@type": "uco-observable:EmailMessage",
        "from": "vulnmaster@businessemail.com",
        "to": "vulnmaster@personalemail.com",
        "dateSent": "2023-02-20T10:45:00Z",
        "isEncrypted": true,
        "observable:bodyRaw": "SGVyZSBpcyBhbm90aGVyIGV4YW1wbGUgb2Ygc3RvbGVuIGludGVsbGVjdHVhbCBwcm9wZXJ0eS4="
      }
    ]
  }
}

[ajnelson-nist]

@vulnmaster I can see the UCO-conceptual coverage gaps you noted in your motivating scenario, and agree they are worth representing.

First, I had thought UCO had a general concept for "System," e.g., a thing that would receive a system security plan in some organizations. Doing a quick check over the observable namespace, it seems we don't have that. If we did, EmailSystem would be a subclass of that. observable:Application might fulfill this need? Either it does, or a System is something that ties together several applications to provide some set of services. I'm leaning towards thinking UCO should have System as a class.
I suspect EmailSystem should be able to be a subclass of something else in UCO, rather than a "top-under-Observable" class.

Second, I think I agree with the set of new properties you suggest would tie to individual email objects. What's interesting to me is that some tie to emails only in the context of an email system. Rather than trying to use (extend?) the core:context property that so far applies to only core:Events, I think this suggests a more foundational pattern of inherence.

Take an organizational Microsoft Exchange¹ service with a user using a desktop Outlook client as an example. A monitoring service might be watching the Exchange server regularly, find an email that raises a review alarm, and then an investigation of that user's laptop might find a corresponding email. Those are two different email objects: One inheres in the Exchange service, one inheres in the Outlook application.

I could see the auto-forwarded property you suggested being the result of a rule stored in either a central email configuration, or of a client application. The client application can store different rules (pattern:LogicalPatterns?) that the central service might completely unaware of. What's not clear to me, just from own lack of experience analyzing email systems, is how auto-forwarding would be determined. I'm not sure how forwarding is recorded in a client application vs. a central store, and I'm also not sure whether forwarding having happened due to matching a rule would be recorded.

I think it's worth representing the impact of inherence on the recorded metadata in an email. What is the metadata that differs between an email on a client application vs. the central service?

I think it's also worth representing an email matching rule, so pattern:LogicalPattern can be further exercised. In the context of email (at least GMail, by my recollection), a pattern can be defined, but only applied non-retroactively. So, if "auto-forwarded" isn't recorded in a central email system or local application, determining "auto-forwarding" could require UCO to define a class of pattern-matches, likely something involving some subclass of core:Compilation. It would be interesting noting that emails matching a rule do not appear to be affected (e.g., archived) by that rule, which could be an indication of the time the rule was created and/or applied.

I can see a few more focused proposals getting spun off of this one.

Footnotes

1. Participation by NIST in the creation of the documentation of mentioned software is not intended to imply a recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that any specific software is necessarily the best available for the purpose. ↩

[ajnelson-nist]

I think, as currently spelled, Requirement 1 suggests a subclass of observable:Email is needed, to represent emails found in the context of system. Those do not appear to be properties of an overall EmailSystem. I don't think we can have a Requirements Review vote on this in January's meeting.

[aj-stein-nist]

First, I had thought UCO had a general concept for "System," e.g., a thing that would receive a system security plan in some organizations.

I too would welcome and support such an addition.