ucoproject / uco Goto Github PK
View Code? Open in Web Editor NEWThis repository is for development of the Unified Cyber Ontology.
License: Apache License 2.0
This repository is for development of the Unified Cyber Ontology.
License: Apache License 2.0
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."
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.
Proposal:
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
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:
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 (%)?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.