ucoproject / uco Goto Github PK

To support broader cyber investigation use cases, we should add a new Alert object to uco-investigation.

It would be defined as "A report of one or more Events believed to be suspicious along with some explanation of why the activity is believed to be suspicious"

The Alert object would be a derivation of uco-core:Grouping.
The "context" property of uco-core:Grouping would be sub-typed to change its name from "context" to "alertContext".
The "alertContext" property would specify the context of why the activity is believed to be suspicious.

There is currently no properties defined to enable the expression of a geolocation map datum.

Is the "key" property intended to be the name of the key?
If so, it seems like it would be more appropriate to use the "name" property of the object in conformance with the standard practice used throughout UCO.

Is the "key" property intended to be a list of the subkeys within the key?
If so, then it should not be a string or of singular cardinality.
It would be more appropriate to be of CyberItem type and 0..* cardinality.
There is also the question of whether this sort of relationship should be captured with external relationships according to the UCO default or embedded as a property.
I can see arguments for either side but am dubious that this case would meet the "indelible" requirement for it to be embedded. It seems like the set of subkeys within a key could easily change over time. Given this it seems like external relationships are more appropriate.
If consensus is that external relationships are the appropriate approach then this property should be removed.

v0.1.0 currently does not define any properties to convey mobile device specific properties such as IMEI.

Properties should be added to convey this information.

UCO currently lacks capability to characterize magnetic stripe card track2 info

The current name for the concept/class ForensicAction is too narrowly scoped to digital forensics to adequately support the broader cyber investigation domain.

This class should be changed to be named InvestigativeAction.
The accompanying definition should be modified to "An investigative action taken as part of a cyber investigation."

Get an error when opening the MagicDraw Project in uco/model/uco-1.0-draft.uml.mdzip in MagicDraw v18.5:

"Cannot find the used project 'BasicTypes.uml.xmi'. Do you want to select it manually?"

The mftResident property within the mftRecord property bundle seems to be relevant for a single attribute of a single file rather than for the file itself as a whole.
This would appear to make it out of scope for the mftRecord property bundle intended to provide properties of a single file record within a Master File Table.

Suggest it be removed.

v0.1.0 currently has GPSCoordinates and LatLongCoordinates facets for conveying a specific geolocation point.

There are many in-scope use cases that call for the ability to convey a geolocation area scoping rather than just a point. This could include shapes such as quadrilateral, circle, polygon, etc.

One or more facets should be added to convey this form of information.

Current description of a NetworkConnection hides the fact that several protocols (not HTTP based) contain information in the timing of packets, or groups of packets (e.g. typing "ls\n" and its response in a SSH session.

UCO currently lacks capability to characterize credit card specific info

UCO currently lacks capability to characterize magnetic stripe card track1 info

To keep the model more simple for now, I would suggest we remove the HasIdentity, HasLocation and RelatedIdentity specializations on Relationship.

It would be useful to be able to convey external (non-UCO) identifiers for any UcoObject.
This property would need to have cardinality 0..* and each entry would at a minimum consist of the a property for the identifier itself and a property to convey the context of the identifier.
This could be done as a native property of UcoObject or could simply be defined as a facet/property-bundle.

For example, something like the following as a native property:

{
  "@id": "identity-a5b2df87-bc86-491d-837c-0dc18e4b6f15",
  "@type": "Identity",
  "name": "AT&T Inc.",
  "externalID": [
    {
      "@type": "ExternalId",
      "externalIDValue": "18",
      "externalIDContext": "NSRLMfgCode"
    }
  ]
}

OR something like the following as a facet/property-bundle:

{
  "@id": "identity-a5b2df87-bc86-491d-837c-0dc18e4b6f15",
  "@type": "Identity",
  "name": "AT&T Inc.",
  "facet": [
    {
      "@type": "ExternalId",
      "externalIDValue": "18",
      "externalIDContext": "NSRLMfgCode"
    }
  ]
}

CellID
Local Area Code (LAC)

Add a new property to UcoObject named "tag" or "label" to capture basic tagging/labeling of any UCO object content.

This would also then include removing the "tag" property from Annotation once it is present on UcoObject.

v0.1.0 currently does not define any properties to convey active geolocation properties such as bearing and velocity.

Properties should be added to convey this information.

I originally asked whether a single "modificationTime" property could be shared for every file system type and file system structure that tracks what is semantically a modification timestamp. From the call this morning (between me, Sean, and Harm), we concluded it would be best to use different names within the context-specific property bundles. However (Sean, please correct me if I misremembered), a file property bundle can retain a simply-named "modificationTime" property, abstracted out from file system contexts according to normal expectations.

For example, NTFS can have many mtimes associated with a file; the two that can come from the MFT entry are in the Standard Information and Filename attributes. The CASE NTFS property bundle records the potentially-different mftFileNameModifedTime. A CASE file would report the standard info. mtime as its mtime, as that is the typical user experience in NTFS; but other timestamps would be available for inspection with the context-specific names.

There is currently a Relationship identity facet that conflicts with uco-core.Relationship in name.
The identity facet needs a more purpose-specific name.

See the attached PDF below for details on the proposal, and then vote on the subsequent comment with a thumbs up or thumbs down (click on the emoji icon in the top right of the post).

Representing Content Extracted from Network Traffic using CASE UCO 4April2018.pdf

v0.1.0 currently does not define any properties to convey Android mobile device specific properties such as AndroidID.

Properties should be added to convey this information.

The mftDeletionCount property within the mftRecord property bundle seems to be a property of an overall Master File Table rather than to any single file record within that table.
This seems to make this property inappropriate within the mftRecord property bundle.

Suggest that it be removed.

v0.1.0 currently does not define any properties to convey SIM Card device properties such as ICCID.

Properties should be added to convey this information.

v0.1.0 currently does not define any properties to convey mobile service account properties such as IMSI and MSISDN.

Properties should be added to convey this information.

To support broader cyber investigation use cases, we should add a new Event object to uco-investigation.

The Event object would be a direct derivation of uco-core:ContextualCompilation.

It would be defined as "An occurence of some activity characterized by the observables indicating such action occured."

See the attached PDF below for details on the proposal, and then vote on the subsequent 2 comments with a thumbs up or thumbs down (click on the emoji icon in the top right of the post).

Representing Network Connections using CASE UCO 4April2018.pdf

So, after looking at the Contact property bundle in-depth I see we have several problems.

• We are duplicating the content of SimpleName inside another property bundle unnecessarily.
• We have a separate contactName property that is a simple combination of other properties (firstName + lastName) which is redundant.
• The emailAddress list and phoneNumbers list are all strings rather than associations to accounts.
• We have no way to associate the contact type (Home, Work, etc.) with the email addresses or phone numbers.
• We have a screenName property that is semantically the same as the displayName property in the DigitalAccount property bundle.

Proposal:

1. Change screenName to displayName in Contact PB
2. Remove the firstName and lastName properties from Contact property bundle. Utilize a SimpleName property bundle on the trace to convey this information.
3. Remove emailAddress and phoneNumbers properties from Contact PB
4. Create a new property bundle called something like ContactAccountEntry to capture a single contact mechanism (phone number, email address, etc) for a Contact.
   4.1 Containing the following properties:
   4.1.1 contactAccountLabel (ControlledVocabulary type). This could enumerate/constrain values like Home, Work, etc for individual contacts or Sales, Service, etc for organizational contacts or something custom for edge cases
   4.1.2 contactAccountType (ControlledVocabulary type). This could enumerate/constrain values like Email, Phone, IM, etc.
   4.1.3 contactAccount (UcoObject reference type). This would be a reference to a Trace object for the account in question
5. Unsure what to do about contactName. Is it really needed? It doesn’t seem so to me but there may be a reason to capture it forensically. If I recall I think it came from mapping from Hansken?

So, basically:

• You would convey a phonebook app or other container for contacts using a Trace with the Application (and maybe other) PBs

• You would convey a single Contact entry (the overall info, not just a single phone number of email address) using a Trace with the Contact PB

  • Identity information would be conveyed on the trace with PBs such as SimpleName, BirthInformation, etc.
  • Location information (address, etc) would be conveyed on the trace with PBs such as SimpleAddress
  • Information on specific contact mechanisms (phone numbers, email addresses, etc) for the contact would be conveyed on the Trace using any number of ContactAccountEntry PBs

• This resolves the name property duplication issue in an explicit, consistent and effective manner

• This resolves the issue of associating context to a given contact type (phone, email, etc.)

• This provides a consistent yet flexible approach for any other (or future) types of contact vectors (other than phone, email, IM, etc)

• I don’t think we need explicit external “has-account” relationships between the contact and the accounts as they are already explicitly and clearly specified as references within the Contact Trace.

What is the intended meaning of the ntfsInitializedSize property within the mftRecord property bundle?

Which of the following is it meant to capture:

• the Allocated_Size_Of_File property within the $FILE_NAME structure within the $Standard_Information attribute
• the Actual_Size_Of_File property within the $FILE_NAME structure within the $Standard_Information attribute
• something else

v0.1.0 currently does not define any properties to convey a row count for a database.

Properties should be added to convey this information.

Locations found can have various sources, these sources have different accuracies. E.g. cell-towers transmit to overlapping area's. Connection with a Cell-tower antenna gives a global hint on the location.
Typical cell planning information is cell-tower location and azimuth of antenna.

Azimuth?
Radius?
Ellipsoid?
Curve?
Certainty interval (%)?