{"push_id":1414755090,"size":24,"distinct_size":1,"ref":"refs/heads/master","head":"3c24ef0e8ec2dc473c45d77bf2de9d91711b375a","before":"8c6c8fb3515657b27cceea6579b23bb93b914ee4","commits":[{"sha":"64110b66c34d0aaf50bedb0c5f5dd4303e532441","author":{"name":"Barnum, Sean D","email":"4492a3be2f2c6bec2c62f17442b754b7334ed209@mitre.org"},"message":"On PhoneCall, “sender” and “participants” do not seem appropriate. “from” and “to” seem much more appropriate. This is what the model has.","distinct":false,"url":"https://api.github.com/repos/casework/case/commits/64110b66c34d0aaf50bedb0c5f5dd4303e532441"},{"sha":"6f772ca6e1712c3f1ee01e0a454ea6b278fcca85","author":{"name":"Barnum, Sean D","email":"4492a3be2f2c6bec2c62f17442b754b7334ed209@mitre.org"},"message":"- On ComputerSpecification, the model now contains significantly more than just bios, cpu, ram after taking into account other inputs such as CybOX.\n    - bios is now biosVersion (there are several other bios related properties available as well).\n    - ram is now totalRam (availableRam is also an optional property now)\n- We had discussed that NetworkLocation was unnecessary and would be scoped out. We had discussed simply using  separate DomainName and IPv4Address property bundles.","distinct":false,"url":"https://api.github.com/repos/casework/case/commits/6f772ca6e1712c3f1ee01e0a454ea6b278fcca85"},{"sha":"5bb69f8a1992896db5f01f95e0f9ff51eed89991","author":{"name":"Barnum, Sean D","email":"4492a3be2f2c6bec2c62f17442b754b7334ed209@mitre.org"},"message":"- Why is this example titled “email”. It looks to be focused on associating an identity to accounts associated with that identity rather than with email\n- Property fields on Identity are done via property bundles for various types of information.\n    - firstName is givenName and lastName is familyName and both are part of the SimpleName property bundle.\n    - birthday is birthdate and is part of the BirthInfo property bundle\n    - Other objects such as accounts are not embedded as references within Identity. They are expressed as external Relationship objects with kindOfRelationship=“has-account\"\n- Accounts are expressed as Trace objects not as Identity objects.\n    - We have discussed this at length on more than one occasion and reached consensus. We did agree that there was value in capturing account profile info that resembled identity info. This can be accomplished through use of the identity property bundles (defined within core) on the Trace object\n        - For more account type specific profile property info (e.g. LinkedIn) not covered by the identity property bundles a new property bundle would need to be defined and used.\n    - As described above, associated accounts are expressed via Relationship objects rather than embedded references.\n    - displayName goes on DigitalAccount rather than Account as it is really a digital relevant property. In the model it was on UserAccount but I have moved it now to DigitalAccount as it seems more appropriate.\n    - On the ApplicationAccount property bundle, the property field is just “application” not “fromApplication\"\n    - The google account shows multiple values for accountLogin. Is this intentional? I am not aware that google or really any other digital account lets you use more than one accountLogin/username. The model has this property as 0..1. Do we need to change the multiplicity? I left it as is in the example for now but we need to revisit.","distinct":false,"url":"https://api.github.com/repos/casework/case/commits/5bb69f8a1992896db5f01f95e0f9ff51eed89991"},{"sha":"22d7e6968bd83fb144dc883b589142970d225e14","author":{"name":"Barnum, Sean D","email":"4492a3be2f2c6bec2c62f17442b754b7334ed209@mitre.org"},"message":"- I modified the file related traces to match the FileStructure approach I have asserted is appropriate. These may need tweaked once we make final decision.\n- I have modified the Hash property bundle to align with the model\n- We agreed that RasterImage would be renamed RasterPicture to avoid confusion with forensic images.\n- Modified Actions to properly utilize ActionRefs property bundle\n- forensic_action7 is a ForensicAction rather than just an Action","distinct":false,"url":"https://api.github.com/repos/casework/case/commits/22d7e6968bd83fb144dc883b589142970d225e14"},{"sha":"7acae444e50b326689ad5a1fab066338248abaf2","author":{"name":"Barnum, Sean D","email":"4492a3be2f2c6bec2c62f17442b754b7334ed209@mitre.org"},"message":"- On the Application property bundle, the model did not initially have a property for the ApplicationID. I have now added it as applicationIdentifer.\n- Relationship can have multiple sources but only one target. I’ve inverted the source/target for application_objects1 to be valid but I would also suggest that grouping them all (especially the accounts) together like the example has them is likely not all that useful.","distinct":false,"url":"https://api.github.com/repos/casework/case/commits/7acae444e50b326689ad5a1fab066338248abaf2"},{"sha":"9a4f19ff7d141fe24c38759806b954f617917fef","author":{"name":"Barnum, Sean D","email":"4492a3be2f2c6bec2c62f17442b754b7334ed209@mitre.org"},"message":"- On case1,\n    - the startTime and endTime property names needed fixed and the values to be made timestamps\n    - I added a “focus” property to Investigation with the brief description \"Specifies the topical focus of an investigation.”. I used this field for the SuspectedOffense property in the original example. We need to remember that Investigation will be used for more than just criminal investigation and needs to stay a little more general.\n    - A while back we discussed and settled on an approach where Investigation (like ForensicRecord) would have a single general “object” property containing a list of referenced objects related to the Investigation rather than a series of purpose-specific reference properties (e.g. forensicActions). I have modified the Investigation to utilize this approach.\n- For each of the ForensicActions,\n    - I moved the ref fields under the appropriate ActionRefs property bundle.\n    - I modified most of the “performer” values from Role2-Role4 to align with other role objects already in scope (e.g., :”examiner1”)\n    - Changed the values of the “object” property to be the specific Traces acted on rather than the ambiguous Provenance_Record abstraction\n    - Changed action names to be present tense rather than past\n    - Modified several of the performer property values to reference specific roles already referenced by Investigation\n    - I would strongly suggest that forensic_action5 and forensic_action6 should be restructured. Firstly, “executed” does not look like a useful forensic action to me. Just saying toolX was run does not really offer the information that should be provided. The forensic action should identify what sort of action the tool is performing (e.g., carve, query, extract, decrypt, parse, etc.) regardless of what specific tool was actually used. Secondly, it does not make sense to me that forensic_action5 would take in both the android image and the sd card image. It seems there should be a separate forensic action for each of these.\n    - I would suggest that the Process property bundle on forensic_action5 should actually go on the tool3 object as it is characterizing the tool used for the action.\n        - Similarly, it seems like the PlasoArguments property bundle may be unnecessary. I may be misunderstanding it due to my lack of experience with Plaso but the configFile property seems like a reference to a config file used for that use of the tool (which should therefore be characterized on the tool object) and the analysisReport, storageFile and logFile properties seem to be referring to outputs of the action that should be captured and then referenced by the appropriate ProvenanceRecord.\n    - I would suggest that each ForensicAction should typically have a single ProvenanceRecord that references all of the objects (Traces, Relationships, Actions, Annotations, etc) coming out of the action rather than a separate ProvenanceRecord for every object resulting from the ForensicAction.\n    - lifecycle_phase6??\n- I suggest we establish the following guidance in relation to ForensicActions and ProvenanceRecords\n    - A ForensicAction MUST specify a “name\"\n    - A ForensicAction SHOULD specify a “startTime\" and an “endTime\"\n    - A ForensicAction SHOULD specify a single “performer” as an ID reference to a Role or Identity object\n    - A ForensicAction SHOULD specify an “instrument” property with one or more ID references to Tool or\n    - A ForensicAction SHOULD specify an “object’ property containing ID references to one or more specific Trace objects acted on\n    - A ForensicAction SHOULD specify a “result” property containing ID references to\n        - one or more ID references to forensically independently relevant ProvenanceRecord objects\n        - one or more ID references to ForensicAction objects characterizing actions triggered by the results or the current ForensicAction\n    - A ForensicAction SHOULD specify a “location” property containing an ID reference to a Location object characterizing the location at which the action occurred\n    - A ForensicAction SHOULD specify an “environment” property containing an ID reference to a Trace object characterizing the technical environment in which the action occurred.\n    - A ForensicAction SHOULD specify an “authorizationType” and “authorizationIdentifier” (via an Authorization property bundle on the ForensicAction) for any relevant authorization info (e.g. warrant)\n    - A ProvenanceRecord SHOULD specify an “object” property containing one or more ID references to Trace, Relationship, Action, or Annotation objects resulting from a given ForensicAction\n        - A separate ProvenanceRecord object should be created for each forensically independently relevant set of objects resulting from a ForensicAction","distinct":false,"url":"https://api.github.com/repos/casework/case/commits/9a4f19ff7d141fe24c38759806b954f617917fef"},{"sha":"db1495915ad447d79d12151d98471fcf1b3bd21c","author":{"name":"Barnum, Sean D","email":"4492a3be2f2c6bec2c62f17442b754b7334ed209@mitre.org"},"message":"- Removed the schema.org external type and custom property field and utilized the appropriate SimpleAddress property bundle from the model (made a couple tweaks to property names).\n- Added a LatLongCoordinates property bundle to location2 to show how it can be used.","distinct":false,"url":"https://api.github.com/repos/casework/case/commits/db1495915ad447d79d12151d98471fcf1b3bd21c"},{"sha":"44611e7742d72e3e3dabda317c44f99419cd1f57","author":{"name":"Barnum, Sean D","email":"4492a3be2f2c6bec2c62f17442b754b7334ed209@mitre.org"},"message":"- Removed the application_objects1 object\n    - account traces contain ref properties to the application trace\n    - message traces contain ref properties to the application trace\n    - thread traces contain ref properties to all the associated message traces\n        - Should thread have its own application ref property or is it adequate to link through the messages\n    - Added account objects to show relationship between accounts and applications\n- On MessageThread objects,\n    - Is a message thread an actual data construct within messaging apps?\n        - We had never discussed needing “identifier”, “displayName” or “participants” properties for a thread. As such, they are not currently in the model. If a message thread is an actual data construct within messaging apps and they assign them properties like  “identifier”, “displayName” and “participants\" then we should add them. If not, then I’m not sure why we would. “participants” seems particularly odd and like it would be especially simple to derive and unusual to capture explicitly on the thread.\n    - We never discussed having the “message” property set of values be ordered. The model currently just has them as a set. It seems like the ordering should be easily derived from the timestamps on the messages referenced under the “message” property for the thread. Do messaging apps maintain actual data constructs for threads with explicit ordering? If so, then we should make the “message” property ordered.\n- On all Message traces, changed “sender” to “from” and “participant” to “to\"\n- On post1, removed account3 from “to” list as it seems odd to include the sender on the recipient list\n- On message1, removed account1 from “to” list as it seems odd to include the sender on the recipient list\n- On message1, the “mimeType” and “size” properties are not valid on the Attachment property bundle. It looks like the concept/structure or attachments on messages needs to be further discussed and explored.","distinct":false,"url":"https://api.github.com/repos/casework/case/commits/44611e7742d72e3e3dabda317c44f99419cd1f57"},{"sha":"1de7d8b8e1b083ae678e9c1118d6c1258b7c4b2b","author":{"name":"Barnum, Sean D","email":"4492a3be2f2c6bec2c62f17442b754b7334ed209@mitre.org"},"message":"- Modified the “data container” relationship to the new consensus approach.\n    - Created a new digital_photograph1 object and a relationship0 object","distinct":false,"url":"https://api.github.com/repos/casework/case/commits/1de7d8b8e1b083ae678e9c1118d6c1258b7c4b2b"},{"sha":"cbe5e8d0b2af3045b751a6c39636eaae86ee1b7e","author":{"name":"Barnum, Sean D","email":"4492a3be2f2c6bec2c62f17442b754b7334ed209@mitre.org"},"message":"- On sms_action1,\n    - Added “name”: “Send Message” and removed description\n    - Moved properties to ActionRefs property bundle as appropriate\n- On sms_message1,\n    - Added application ref property\n    - Changed “sender\" to “from\" and “participant” to “to” as appropriate\n- On actor1,\n    - Broke identity properties into SimpleName property bundle\n    - Removed account refs and added them as “has-account” Relationship objects\n- On phone_account1,\n    - Added Account property bundle with accountType of Phone and moved isActive to this bundle as appropriate","distinct":false,"url":"https://api.github.com/repos/casework/case/commits/cbe5e8d0b2af3045b751a6c39636eaae86ee1b7e"},{"sha":"95e5f6ee341e86a9154b1768e805cdb9dcbfb3db","author":{"name":"Barnum, Sean D","email":"4492a3be2f2c6bec2c62f17442b754b7334ed209@mitre.org"},"message":"Aligned to latest discussions.","distinct":false,"url":"https://api.github.com/repos/casework/case/commits/95e5f6ee341e86a9154b1768e805cdb9dcbfb3db"},{"sha":"cd422a05437fbba9c4d62722e7a925e1d6c62acd","author":{"name":"Barnum, Sean D","email":"4492a3be2f2c6bec2c62f17442b754b7334ed209@mitre.org"},"message":"Merge branch 'master' into draft1-review-revision\n\n# Conflicts:\n#\texamples/exif_data.json\n#\texamples/file.json\n#\texamples/raw_data.json","distinct":false,"url":"https://api.github.com/repos/casework/case/commits/cd422a05437fbba9c4d62722e7a925e1d6c62acd"},{"sha":"81cb32e11f4fc737aa0eeb6099bbcc2dae0f488d","author":{"name":"Barnum, Sean D","email":"4492a3be2f2c6bec2c62f17442b754b7334ed209@mitre.org"},"message":"Added missing ActionRefs type","distinct":false,"url":"https://api.github.com/repos/casework/case/commits/81cb32e11f4fc737aa0eeb6099bbcc2dae0f488d"},{"sha":"6e60aef4ed8f72b532a882db66ddde9e3f1adb45","author":{"name":"Barnum, Sean D","email":"4492a3be2f2c6bec2c62f17442b754b7334ed209@mitre.org"},"message":"Changed \"object\" to \"source\" in lifecycle_phase1","distinct":false,"url":"https://api.github.com/repos/casework/case/commits/6e60aef4ed8f72b532a882db66ddde9e3f1adb45"},{"sha":"d2a04b7e8cbb13aed401b659dc2d90797ef5c88f","author":{"name":"casework","email":"3c11e49b9379afeac60e90ffcd02f5b491b93a2f@gmail.com"},"message":"Changed message properties 'recipient' and 'sender' to 'to' and 'from'. (Kept 'participant' property).","distinct":false,"url":"https://api.github.com/repos/casework/case/commits/d2a04b7e8cbb13aed401b659dc2d90797ef5c88f"},{"sha":"6e06ff3bbc8df014f937ef9452ae900a45658c7f","author":{"name":"casework","email":"3c11e49b9379afeac60e90ffcd02f5b491b93a2f@gmail.com"},"message":"Update ComputerSpecification properties. Changed SupportingClasses to be a type of PropertyBundles to allow us to use them (like DomainName) as a PropertyBundle.","distinct":false,"url":"https://api.github.com/repos/casework/case/commits/6e06ff3bbc8df014f937ef9452ae900a45658c7f"},{"sha":"2e3f69e523d967ab5de77be925655a13f30ad3c1","author":{"name":"casework","email":"3c11e49b9379afeac60e90ffcd02f5b491b93a2f@gmail.com"},"message":"Add SimpleName, SimpleAddress, BirthInformation, and LatLongCoordinates","distinct":false,"url":"https://api.github.com/repos/casework/case/commits/2e3f69e523d967ab5de77be925655a13f30ad3c1"},{"sha":"ca6b33cb45a39e3ae6837181d3fa4cb5175de0de","author":{"name":"casework","email":"3c11e49b9379afeac60e90ffcd02f5b491b93a2f@gmail.com"},"message":"Remove 'associatedAccount' Identity property.","distinct":false,"url":"https://api.github.com/repos/casework/case/commits/ca6b33cb45a39e3ae6837181d3fa4cb5175de0de"},{"sha":"43e8719ae85c1e0a7f4cf0d0f9b6a3b3d9a157a0","author":{"name":"casework","email":"3c11e49b9379afeac60e90ffcd02f5b491b93a2f@gmail.com"},"message":"Added ActionRefrences propertybundle to ontology. Fixed up file.json and email.json examples.","distinct":false,"url":"https://api.github.com/repos/casework/case/commits/43e8719ae85c1e0a7f4cf0d0f9b6a3b3d9a157a0"},{"sha":"25ac4253e389b9fb6985fde1e906fb691c9bbd7d","author":{"name":"casework","email":"3c11e49b9379afeac60e90ffcd02f5b491b93a2f@gmail.com"},"message":"Fix message.json and forensic_lifecycle.json examples.","distinct":false,"url":"https://api.github.com/repos/casework/case/commits/25ac4253e389b9fb6985fde1e906fb691c9bbd7d"}]}
{"actor":{"display_login":"casework"}}