OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti] CybOX Datatype Refactoring/Deprecation


I fully agree that people will need to do this and will want to do this... I also agree that it is done today... I am just not sure why the language needs to support something special to say that it was done...  I do not see how that extra information is going to change a automated processes and work flows.

In paper-land, if you get handed a redacted document, you see that it is redacted, but there is no special flag on each paragraph or sentence or word to say that something was redacted or obfuscated.  You can simple see that is was redacted by the fact that the content is blacked out.  Also, if you send me some STIX with some content that is ##REDACTED##, how is my work flow going to change with a flag on the data versus just seeing that the content is not there?  Maybe it would be best handled via a best practice of just using "##REDACTED##"

Help me understand how automated work flows would operate differently with the inclusion of a flag, the way i see it, all of the items that would normally be redacted or obfuscated will be bubbled up to a human anyway.  

Another thought I had is I am not sure that everyone will want to call out that the intel was obfuscated or redacted... They may just want to do it, so at best case any fields indicating as such would need to be optional.

Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Mar 25, 2016, at 12:22, Patrick Maroney <Pmaroney@Specere.org> wrote:

I hesitate to jump in, but will describe the Use Cases for Obfuscation, Tokenization, Redaction.  Please note that this is not an attempt to advocate here/now for same.

When sharing Attacker TTPs, especially in a real-time community of trust within a given sector/target group, providing the detailed log events on the Attacker targeting patterns and timing are very valuable for (1) targeting analysis: Did all of the targets attend a specific conference, are they all members of a specific professional organization, are they all in similar fields/roles, (2) Attribution: Actor X has used the same exact multi-organizational distribution list/ordering for the last n Campaigns, (3) Attacker Tool Set Fingerprinting: Tool "x" sends  each email separately, Tool "y" sends each email in blocks of 128 addressees, Tool "z" sends one email every 10 seconds, (4) Early warning Identification of new campaign by actor "x".

Since these detailed logs contain specific Employee, Infrastructure, Organizational target details, most organizations will need to redact, tokenize, obfuscate portions of the detailed logs before externally sharing.

 John.Smith@bigco.com ==> <Redacted>


These are deep topics on the "Implementation details" side of the house and I'm not trying to go down this rabbit-hole.  The objective is to outline scenarios where Obfuscation, Tokenization, Redaction Object Properties might provide value.




Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk: (856)983-0001
Cell: (609)841-5104
Email: pmaroney@specere.org

_____________________________
From: John-Mark Gurney <jmg@newcontext.com>
Sent: Friday, March 25, 2016 1:32 PM
Subject: Re: [cti] CybOX Datatype Refactoring/Deprecation
To: Jason Keirstead <jason.keirstead@ca.ibm.com>
Cc: 'cti@lists.oasis-open.org' <cti@lists.oasis-open.org>, Kirillov, Ivan A. <ikirillov@mitre.org>


Jason Keirstead wrote this message on Tue, Mar 22, 2016 at 10:54 -0400:
> I understand the encoding one, but not the obfuscated one. If someone wants
> to obfuscate (either reversibly or irreversibly) an email or URL before
> publishing it, we can't prevent that. I am not sure what is meant by
> "support" in this case.

I could possibly see a flag that lets the consumer know that this value
was changed from the original,

but IMO, there isn't much value in obfuscating things... You don't want
to obfuscate TTP or Campaigns, etc. You don't want to obfuscate an
Indicator...

The only things I can think of that you'd want to obfuscate is
Observations, but in that case, we have sightings, so you can instead
sight it and just not publish it.

> From: "Kirillov, Ivan A." <ikirillov@mitre.org>
> To: "'cti@lists.oasis-open.org'" <cti@lists.oasis-open.org>
> Date: 03/22/2016 11:29 AM
> Subject: Re: [cti] CybOX Datatype Refactoring/Deprecation
> Sent by: <cti@lists.oasis-open.org>
>
>
>
> Now that we’ve voted to not support defanging, the question remains as to
> whether we should support obfuscation and capture of observed encoding on
> CybOX Object fields:
> Obfuscation example: XXXX@yahoo.com or YYYY@comcast.com. Also used
> for URLs.
> Observed encoding: utf-8, etc. Mostly relevant for malware analysis
> and attribution, e.g., if an actor is known to use a particular
> encoding in their comment strings.

--
John-Mark

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]